implement — build a change in an existing repo

Polymorphic on the input. Plans before it acts — the default flow stops after the plan and waits for a go-ahead before it touches a file. Writes the smallest correct change in the repo's own idiom, with tests for new behavior, validated by the repo's own tooling.

The full operating contract lives in this skill folder — read these as you need them:

Quick start

1. Read `dispatch.md` and classify the input. Resolve the requirement:

• Jira URL / `KEY-123` → fetch the issue via the Atlassian MCP (summary, description, acceptance criteria).
• GitHub issue URL / `#N` → gh issue view <url> --json title,body,labels,comments. (GitHub access is always the gh CLI — assume gh auth login is done.)
• Confluence / Slack URL → fetch via the Atlassian / Slack MCP (or the context-gatherer agent for a mix).
• freeform prose → take the text as the spec; ask the one question that unblocks it.

1. Read `persona.md` — adopt the smallest-correct-change implementer stance.
2. Run the workflow in `workflow.md`. Gather context → present 2-4 approaches → confirm the plan → execute (fan out via the Workflow tool for multi-file work) → validate at every checkpoint → report.
3. Validate with the repo's own typecheck + lint + narrow tests after each checkpoint. A failing gate stops you (rules.md).

Workflow is the default for real changes

"Always have a workflow." A change worth making gets the plan→act Workflow in workflow.md: gather → advise → confirm → execute → self-review → validate. For a multi-file change, fan out — spawn implementer to write the code, test-engineer to add tests, and code-reviewer / security-auditor to self-review the diff before you report. Skip the Workflow only for a one-file, single-concern edit — and say so.

Modes

• default (`--plan` then confirm then `--act`) — gather, present approaches, write the plan, stop and confirm, then implement + validate + report. The plan→act gate is always on unless the user opts out.
• `--plan` — stop after the plan. Produce the approach menu and the file-level change list; touch nothing.
• `--act` — skip the confirm gate and implement the recommended approach directly (still validates, still gated on shared-state writes).
• `-i` — walk each fork with the user (scope, approach, test strategy) before proceeding; cap 3 questions.
• `--deep` — use a stronger reasoning profile; auto-select for cross-module, migration-shaped, or security-sensitive changes.