Latest Agent Skills

Refresh MoonMind services from git by fetching and pinning a branch snapshot, pulling compose images, then restarting changed containers with optional orchestrator inclusion.

Implement bounded remaining work for an issue-driven repository change after an authoritative verifier reports concrete gaps. Use when a workflow supplies an issue brief or assessment plus materialized gate-result and remaining-work evidence, and the existing candidate must be corrected without creating a MoonSpec feature packet.

Verify a completed implementation against the original instructions, a declarative source document, an issue brief, or an optional MoonSpec feature packet, plus AGENTS.md repo guidance and required tests. Use when the user asks to run or reproduce `/moonspec.verify`, perform a final read-only implementation check, audit unit and integration test evidence, classify requirement coverage, or decide whether more code or test work is needed.

Assess source acceptance coverage before MoonSpec planning.

Align a technical document with the actual code implementation and correct drift. Use when a user asks to update docs to match current behavior, audit a technical document against the repository, or fix stale architecture, API, workflow, or operator documentation.

Author a new docs-native canonical or working document by choosing the correct location, filename, viewpoint template, metadata header, stable claims, and embedded rationale without creating spec.md.

Provide the shared fan-out engine used by provider-specific Jira and GitHub batch presets to enqueue child workflows with inherited runtime and stable evidence.

Generate a one-story, TDD-first MoonSpec `tasks.md` from `spec.md`, `plan.md`, and design artifacts. Use when the user asks to run or reproduce `/moonspec.tasks`, create or update an executable task breakdown, map one MoonSpec story to implementation tasks, require unit and integration tests before code, preserve source-design traceability, or include final `/moonspec.verify` work.

Analyze and automatically remediate MoonSpec artifact inconsistencies across spec.md, plan.md, tasks.md, and related design files. Use when the user asks to run `/moonspec.align`, identify uncertainty, weigh tradeoffs in project context, edit artifacts without asking follow-up questions, resolve coverage gaps, or align generated MoonSpec documents before implementation.

Verify a GitHub pull request against a Jira issue's goals, requirements, and acceptance criteria, then post a PR comment with the findings. Use when a user asks Codex or MoonMind to compare a PR to a Jira story/task/bug, confirm whether a PR satisfies Jira requirements, audit implementation coverage from Jira, or publish a Jira-vs-PR verification summary.

Implement repository work from a Jira issue. Use when a user gives Codex a Jira issue key or URL and asks it to fetch the issue, pull relevant instructions, comments, linked context, and attachments, implement the requested code/docs/tests, verify the result, and report what changed.

Generate a MoonSpec implementation plan and design artifacts from a single-story spec. Use when the user asks to run or reproduce `/moonspec.plan`, create or update `plan.md`, produce `research.md`, `data-model.md`, `contracts/`, or `quickstart.md`, evaluate repo principles, define separate unit and integration test strategies, and perform repo-aware gap analysis before `/moonspec.tasks`.

Run Unreal Engine build and automation test workflows for Tactics through MoonMind's shared Docker backend, with a portable direct-Docker fallback outside MoonMind.

Generate one high-value follow-up workflow proposal when MoonMind execution quality issues are detected in a run.

Resolve GitHub PR feedback end-to-end for the branch you are on. Use when you need to fetch all comments on the branch PR, evaluate whether each comment still applies, decide whether it should be addressed, implement fixes, run compile/tests with retry-on-failure, then commit and push the result.

Master orchestrator to resolve a PR by diagnosing state and delegating to specialized skills.

Verify a Jira issue against the current repository state, then post a Jira comment with a PASS, PARTIAL, FAIL, or BLOCKED verdict. Works in two modes: (a) feature-branch mode, comparing a checked-out branch to its base ref; or (b) main/trunk mode, verifying that an issue is already implemented on the current default branch (typical for stories that have already merged). Use when a user asks whether a branch or merged change completes a Jira ticket, or needs a Jira-visible verification comment.

Fix continuous integration (CI) test or build failures for the current PR branch. Fetch CI failure logs, map them to local commands, reproduce the failures, fix the code, verify locally, and commit and push.

Agent tooling for Motion Canvas — seek, screenshot, scene graph inspection, settings control, and rendering via HTTP API. Requires a browser with the editor open.

Animation theory covering the 12 principles of animation and timing guidance. Use when designing motion, choosing easing approaches, or improving animation quality.

Motion Canvas framework reference covering project setup, core concepts (generators, signals, refs, scene hierarchy, timing, utilities), and 2D components (shapes, paths, text, media, layout, camera, transitions, custom components). Use when building or editing Motion Canvas scenes.

Readability Review

Incident Post-Mortem Builder

OI-3 spike harness — heavy consumer skill, BASELINE arm. Builds an incident post-mortem and sources the readability standard mid-workflow by reading a file directly, with NO Skill-tool call. Use only when explicitly invoked by the spike harness with a TRIAL_ID and data path.

OI-3 spike harness — the INLINE (non-forked) readability-guidance variant. Surfaces the shared readability standard into the calling skill's own context. Use only when a spike consumer skill invokes it.

OI-3 spike harness — the FORKED (context fork) readability-guidance variant. Same payload as the inline variant but declared to run in a forked context. Use only when a spike consumer skill invokes it.

OI-3 spike harness — heavy consumer skill, INLINE arm. Builds an incident post-mortem and sources the readability standard mid-workflow via an inline (non-forked) guidance skill. Use only when explicitly invoked by the spike harness with a TRIAL_ID and data path.

OI-3 spike harness — heavy consumer skill, FORKED arm. Builds an incident post-mortem and sources the readability standard mid-workflow via a forked (context fork) guidance skill. Use only when explicitly invoked by the spike harness with a TRIAL_ID and data path.

Internal harness probe for the OI-3 readability-guidance spike. Use only when explicitly told to invoke spike-probe. Verifies that a freshly-created project skill renders into a subagent's context via the Skill tool.

Creates or updates project documentation for a feature, system, or component and publishes it to a user-specified Confluence location. Use when the user wants feature or system documentation written to Confluence, posted to a Confluence space or page, or synced to a Confluence location. Requires a configured Atlassian MCP server. Does not document to local files only — use project-documentation for that. Does not publish an arbitrary existing markdown file — use markdown-to-confluence for that. Does not plan or specify a new feature to Confluence — use plan-a-feature-to-confluence for that. Does not create architectural decision records — use architectural-decision-record. Does not create coding standards — use coding-standard. Does not produce runbooks — use runbook.

Create, extract, or convert architectural decision records (ADRs) using a structured template, with project context discovery and evidence-based review.

Builds a feature specification from scratch with plan-a-feature and publishes it to a user-specified Confluence location, posting the spec as a parent page and each companion artifact (decision log, team findings, technical notes) as a child page beneath it. Use when the user wants a new feature planned, designed, scoped, or specified AND posted to a Confluence space or page. Requires a configured Atlassian MCP server. Does not plan to local files only — use plan-a-feature. Does not publish an arbitrary existing markdown file — use markdown-to-confluence. Does not refine or stress-test an existing plan — use iterative-plan-review. Does not document already-built features to Confluence — use project-documentation-to-confluence.

Produces a progressive-disclosure overview of unfamiliar code or a pull request's changes with code-overview and publishes the resulting overview to a user-specified Confluence location. Use when the user wants code or a PR explained, oriented, or made sense of AND the overview posted to a Confluence space or page. Requires a configured Atlassian MCP server. Does not produce the overview to a local file only — use code-overview. Does not publish an arbitrary existing markdown file — use markdown-to-confluence. Does not document an already-understood feature to Confluence — use project-documentation-to-confluence. Does not root-cause a bug to Confluence — use investigate-to-confluence. Does not plan or specify a new feature to Confluence — use plan-a-feature-to-confluence. Does not publish to Jira — use work-items-to-jira.

Creates and maintains project documentation for features, systems, and components. Use when documenting how a feature, system, or component works — including writing, updating, or organizing docs. Does not scan or detect the project's technology stack — use project-discovery for repository analysis and config detection. Does not create architectural decision records — use architectural-decision-record for ADRs. Does not create or update coding standards — use coding-standard instead. Does not generate PR descriptions — use update-pr-description for that. Does not produce runbooks for operational scenarios — use runbook for that. Does not rewrite existing prose for readability — use edit-for-readability for that. Does not produce an ephemeral, understand-now overview of code or a PR — use code-overview for that.

Runs an evidence-based investigation of a bug, failure, or unexpected behavior with investigate and publishes the resulting investigation report to a user-specified Confluence location. Use when the user wants something debugged, diagnosed, or root-caused AND the findings posted to a Confluence space or page. Requires a configured Atlassian MCP server. Does not investigate to a local file only — use investigate. Does not publish an arbitrary existing markdown file — use markdown-to-confluence. Does not document an already-understood feature to Confluence — use project-documentation-to-confluence. Does not plan or specify a new feature to Confluence — use plan-a-feature-to-confluence. Does not publish to Jira — use work-items-to-jira.

Surfaces Han's shared Human-Readable Output Standard — the readability rule and the writing-voice profile — into the calling skill's own context, so the caller drafts in voice and runs its self-check against the current standard sourced from one canonical copy. Use when a prose-producing skill needs the shared readability standard available in context before it drafts. Governs the shape of a written deliverable, where explanation-guidance governs what a run says to a person in a turn. Runs in the caller's context and hands control straight back; it does not produce a deliverable of its own, rewrite anything, or judge the caller's work. Does not run the adversarial rewrite pass — dispatch the readability-editor agent for that, or use edit-for-readability to rewrite an existing target. Does not cover explaining technical work to a reader who will not implement it — use explanation-guidance for that.

Surfaces Han's shared standard for explaining technical work to a reader who will not implement it into the calling skill's own context, so the caller writes its escalations, confirmation turns, and stops as a concrete outcome the reader could observe rather than as a mechanism. Use when a skill is about to ask a person a question, stop for an input, or explain a technical consequence to someone who will not open the code. Governs what a run says to a person in a turn, where readability-guidance governs the shape of a written deliverable. Runs in the caller's context and hands control straight back; it does not produce a deliverable of its own, rewrite anything, or judge the caller's work. Carries guidance only and adds no self-check step.

Applies Han's shared Human-Readable Output Standard to a target you already have — a file on disk, text pasted into the prompt, or a draft already produced in the conversation — by dispatching the readability-editor to rewrite its prose so the main point comes first, headings are descriptive, each paragraph carries one idea, and sentences stay short and active, while preserving every fact. Use when you want to make a document or draft readable, edit or polish prose for readability, clean up writing, tighten wording, or re-apply the readability standard to something already written. Rewrites prose only, leaving code, diagrams, and citation identifiers unchanged. Does not write new feature or system documentation — use project-documentation. Does not restructure code or review it — use refactor to restructure code and code-review to audit it. Does not judge the underlying work or raise findings; it only rewrites the writing.

Publishes a local Markdown file to a user-specified Confluence location, creating a new page or updating an existing one through the Atlassian MCP server. Use when the user wants to post, publish, push, or sync a Markdown file to a Confluence space or page. Requires a configured Atlassian MCP server. Does not write or generate the Markdown itself — point it at an existing file, or use project-documentation-to-confluence for the document-then-publish flow, or plan-a-feature-to-confluence for the plan-then-publish flow. Does not publish to Jira — use work-items-to-jira.

Sharpens and stress-tests an existing plan file through multiple codebase-grounded review passes, editing it in place and recording every finding and iteration in cross-referenced companion files. Use this skill whenever the user wants to iterate on, refine, tighten, or improve a plan. Also use it when the user asks to verify, validate, or confirm feasibility of an approach. Does not implement plan steps, write test plans, review code, or investigate bugs, and does not generate new plans from scratch — use plan-a-feature for a new plan. Runs its review rounds to completion without pausing between them; to review each round as it lands, use pairing.

Produce a standalone test plan by analyzing code for test coverage gaps and edge cases. Use when you need to create, generate, or draft a test plan for a branch, need to analyze test coverage, or need to identify what tests to write for specific files or directories. Does not produce a plain-language plan for a person to run tests by hand — use manual-test-planning for that. Does not write test code — use tdd to implement behavior test-first. Does not refine existing plans — use iterative-plan-review. Does not review code quality, security, or style — use code-review for full code review. Does not evaluate architectural testability or structural coupling — use architectural-analysis for architectural assessment.

Produces a plain-language stakeholder summary from an existing feature specification, for sharing with non-technical stakeholders before implementation kicks off. Use when the user wants to draft a stakeholder summary, executive summary, or business summary of a feature spec or PRD. Does not write the spec itself — use plan-a-feature. Does not sequence the build into phases — use plan-a-phased-build. Does not produce an implementation plan — use plan-implementation.

Run a full pull request review and post review comments directly to the current branch's GitHub PR. Requires the gh CLI to be installed and a PR to already exist for the current branch. Use when you want review feedback posted to GitHub as PR comments. For local code review without posting to GitHub, use code-review instead. Does not write or update PR descriptions — use update-pr-description for that.

Performs deep architectural analysis of a specified module, directory, or feature area by examining structural coupling, data flow, concurrency patterns, risk, and SOLID alignment. Use when the user wants to assess, evaluate, or review the architecture, design quality, dependency structure, coupling, cohesion, or technical debt of an existing part of the codebase. Not for investigating specific bugs, runtime errors, or failures — use investigate. Not for test planning — use automated-test-planning. Not for file-level code review — use code-review. Not for researching open-ended options, prior art, or how something works — use research. Not for designing a new interface or contract — use design-an-api. Not for writing documentation or architectural decision records.

Builds a new Claude Code skill from scratch through a relentless, evidence-based interview that walks the skill's design tree decision-by-decision — entity fit, use cases, name, description, workflow steps, tools, and progressive-disclosure layout — then reviews the finished skill against the plugin-building guidance and applies every fix it finds. Use when creating, authoring, scaffolding, designing, or drafting a new skill or slash command. Does not build an agent or subagent — use agent-builder. Does not serve, vendor, or refresh the authoring guidance itself — use guidance.

Builds a new Claude Code agent (subagent) from scratch through a relentless, evidence-based interview that walks the agent's design tree decision-by-decision — entity fit, domain focus and vocabulary, role identity, anti-patterns, description, model tier, tools, and self-containment — then reviews the finished agent against the plugin-building guidance and applies every fix it finds. Use when creating, authoring, scaffolding, designing, or drafting a new agent or subagent. Does not build a skill or slash command — use skill-builder. Does not serve, vendor, or refresh the authoring guidance itself — use guidance.

Builds a feature implementation plan from an existing feature specification (or equivalent context) through a facilitated team conversation. Use when the user wants to plan how to implement, build, deliver, or ship a feature that has already been specified. Does not specify what the feature should do — use plan-a-feature first. Does not design the contract for an interface — use design-an-api. Does not refine or stress-test an already-written plan — use iterative-plan-review. Runs its resolution rounds to completion and holds its questions until after they finish; to review each round as it lands, use pairing.

Splits a body of context into a sequence of vertical-slice build phases where each phase is independently demonstrable to a real user and each builds on the previous. Use when the user wants to plan, sequence, phase, slice, break down, or order the build of a feature, capability, system, or initiative, and produces a plain-language phased build outline. Does not produce implementation detail — use plan-implementation. Does not specify behavior that has not been decided — use plan-a-feature. Does not perform gap analysis between two artifacts — use gap-analysis. Does not break a plan into independently-grabbable work items — use plan-work-items.

Generate a PR description from the current branch's changes against a GitHub PR, using the gh CLI. Use when writing, drafting, or updating pull request descriptions, PR summaries, or PR bodies. Does not review code or post review comments — use code-review for local review or post-code-review-to-pr for posting a review to GitHub.

Break a work-items.md file (produced by /plan-work-items) into independently-grabbable Jira tickets, one per slice, in a single Jira project. Use when you want to turn a work-items file into Jira tickets, publish work items as Jira issues, or create implementation tickets that can be worked on and tracked in Jira. Requires a configured Atlassian MCP server. Does not produce the work-items file itself — use plan-work-items to break a plan into work items first. Does not post to GitHub — use work-items-to-issues for GitHub issues.

Update Han plugin documentation so every skill, agent, guidance doc, index, and cross-reference is current and accurate. On a non-default branch, scopes the pass to entities the branch actually touched. On the default branch, performs a full documentation sweep across the whole plugin. Use when updating, refreshing, syncing, auditing, or verifying Han's docs after changing skills, agents, references, or top-level guidance — including "update the docs", "doc sweep", "refresh documentation", "audit the docs", "make sure the docs are current". This is a repository-maintenance skill for the Han repo itself, not a general documentation skill — use /project-documentation to document features in arbitrary projects, /han-release to cut a release (and update CHANGELOG), and /update-pr-description for PR bodies.

Turn a work-items.md file (produced by /plan-work-items) into Linear issues, one per slice, in a single target Linear team. Use when you want to publish work items as Linear issues, create implementation tickets to track in Linear, or push a broken-down plan into a Linear team. Requires a configured Linear MCP server and a target team. Reads the team's real workflow states, labels, Projects, and members and resolves every option against them before creating anything; defaults each issue to the team's initial state, unassigned, uncategorized, with no parent or Project unless you ask. Links within-file `Depends on` relationships as native Linear "blocked by" relations and annotates the source file so re-runs resume cleanly. Does not produce the work-items file itself — use plan-work-items first. Does not post to Jira — use work-items-to-jira. Does not post to GitHub — use work-items-to-issues.

Break a work-items.md file (produced by /plan-work-items) into independently-grabbable GitHub issues, one per slice, in each slice's target repo. Use when you want to turn a work-items file into GitHub issues, publish work items as issue tickets, or create implementation tickets that can be worked on and tracked on GitHub. Does not produce the work-items file itself — use plan-work-items to break a plan into work items first. Does not review code or post pull request comments — use post-code-review-to-pr for that.

Produce a plain-language manual test plan from the context supplied to it — an executive summary, a high-level list of named tests, and a detail section per test with the steps a person follows by hand and the outcomes they should expect. Use when you want to create, draft, generate, or outline a manual test plan, manual QA steps, hands-on verification steps, or an acceptance walkthrough for a feature, change, branch, plan, or PR. When the plan holds more than five tests and at least two natural categories emerge, both the test list and the detail sections are organized under plain-language categories. When nothing in the supplied context can be manually tested, it says so and asks for more context instead of producing a document. Does not analyze code for automated test coverage gaps — use automated-test-planning. Does not write test code — use tdd. Does not review code quality — use code-review. Does not stress-test an existing plan — use iterative-plan-review.

Break a trusted implementation plan (or other provided context) into independently-grabbable, atomic work items, written to a single work-items.md file. Use when the user wants to convert a plan into work items, create implementation tickets or tasks, divide a plan into work units, or break the plan down into grabbable pieces. Do not use when there is no implementation plan yet or the plan is not yet trusted — use plan-implementation to produce the plan or iterative-plan-review to harden it first. Does not sequence work into demoable delivery phases — use plan-a-phased-build for that. Does not write code — use tdd to implement a work item.

Authoritative guidance for building Claude Code skills, agents, and plugins, plus init and update steps that install and refresh the plugin-building skills in the current repository. Use when you need the rules or best practices for a skill, agent, hook, or plugin — designing, reviewing, hardening, or checking one against the guidance. Run with `init` to vendor the guidance, skill-builder, and agent-builder skills into the current repository (so they run with no dependency on this plugin) plus a path-scoped rule index, or `update` to refresh an already-vendored copy. Does not run an interview to build a new skill or agent from scratch — use skill-builder or agent-builder. Does not write feature code, review application code, or build non-plugin features.

Builds a feature specification from scratch through a relentless, evidence-based interview that walks the design tree decision-by-decision, resolving dependencies as it goes. Use when the user wants to plan, design, scope, specify, or flesh out a new feature, capability, or system behavior before implementation. Produces a feature specification focused on system behaviors, not implementation detail. Does not refine or stress-test an existing plan — use iterative-plan-review. Does not document already-built features — use project-documentation. Does not design the contract for an interface — use design-an-api. Does not research open-ended options before there is a feature to specify — use research.

Walks a person through code changes one step at a time in conversation, starting at the entry point and following the flow that changes, showing a small chunk per step and explaining it in plain language. Defaults to the current branch's changes, and walks the code from the perspective of any context provided instead — a file, directory, symbol, pull request, plan, or ticket. Use when someone wants to be walked through, taught, paced through, or shown around code or a branch step by step, or to learn how a change works before reviewing or extending it. Stops after every step and waits, so the learner sets the pace. Paces through code that already exists and builds nothing — to build new work while being paced through it, use pairing. Does not produce a written overview to read alone — use code-overview. Does not review code quality — use code-review. Does not diagnose bugs — use investigate.

Convert a stakeholder summary markdown file into a single self-contained HTML executive report — bottom line and decision asks up front, supporting detail later — styled with a Test Double-derived palette and self-contained mermaid diagrams. Use when the user wants to turn a stakeholder summary, executive summary, or business summary into an HTML report, generate an HTML version of a summary doc, or produce a shareable HTML file from a summary markdown. Produces an HTML sibling file only; does not publish anything.

Discovers the core attributes of the current code repository and its projects — languages, frameworks, tooling, and where things live — and writes a concise reference section directly into the project's AGENTS.md or CLAUDE.md for other skills, agents, and hooks to consume. Use when scanning, analyzing, or detecting the project's technology stack, build tools, or repository structure. Does not create or update project documentation — use project-documentation for writing feature or system docs.