# Implement > End-to-end code implementation workflow. Classifies task risk, creates a branch, plans (Opus for SIGNIFICANT/HIGH-RISK), implements, writes tests, runs Opus code review, and performs post-session maintenance. Activated when the user prompt starts with "implement:". - Skill: `ihudak/implement` (Agent Skill) - Install (CLI): `npx skillmds@latest add ihudak/implement` - Raw SKILL.md: https://api.skillmd.com/api/skills/ihudak/implement/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: AI & ML - Author: ihudak (https://skillmd.com/u/ihudak) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/ihudak/implement --- Implement the following: the argument (text following the `implement:` trigger) --- ## Phase 0 — Load and classify inputs the argument (text following the `implement:` trigger) may contain free-text prose plus **zero or more `@path` tokens** (today's single-`@file` form is a subset). Resolve each `@path` relative to the current working directory. Classify each `@path` — and the current working directory — **by inspection, not by matching the path string**: | Detected as | Recognition rule | Handling | |---|---|---| | **Spec file** | a single `.md` file | read fully; use as the description/spec | | **Spec folder** | a directory containing `prompt.md` and/or a `*-design.md` | read all `.md` specs within; fold into the description | | **Jira ticket folder** | a directory containing a `*-index.md`, or ticket-key subdirectories each containing a `KEY.md` | hand to `jira-reader` in Phase 1.7 | | **Code repo** | a directory where `git -C rev-parse --is-inside-work-tree` succeeds (includes the cwd) | scan target in Phase 1.7 | **Jira-input resolution (shared front-end).** Before the per-`@path` classification above, run `~/.copilot/installed-plugins/ihudak-copilot-plugins/dev-workflows/skills/_shared/jira-input-resolution.md` against the argument (text following the `implement:` trigger). It unifies the input grammar with `document:`: a **JiraID** token (`^[A-Z][A-Z0-9]+-[0-9]+`) is discovered under `$VAULT_PATH/jira-products/` (Fallbacks A/B on miss); a directory that inspects as a **jira-export** is used as `jira_export_root`; a **spec-folder** contributes to `specs`; everything else is `direct` (free-text/`@file`, this command's existing flow). The classification table above is the directory branch of that front-end — a Jira ticket folder ↔ jira-export, a spec folder ↔ spec-folder, a code repo ↔ an `implement:`-only target. Carry `mode`, `jira_key`, `jira_export_root`, `focus_key`, and `specs` forward. **Epic-unit resolution (jira-driven).** `implement:` implements one Epic at a time. After the front-end resolves, when `mode: jira-driven`: - **`focus_key` set** (explicit ` `, a bare nested ``, or chosen in the picker below) → proceed for that Epic. The Jira read (Phase 1.7) and specs resolution both scope to it. - **`focus_key` null** → classify the target with a cheap `jira-reader` `depth: vi-plus-epics` read on `jira_export_root`, then follow `~/.copilot/installed-plugins/ihudak-copilot-plugins/dev-workflows/skills/_shared/jira-input-resolution.md` §"Progress-aware Epic picker": - the item is **itself an Epic** (stand-alone / top-level) → no picker; proceed directly (`focus_key` stays null; specs resolve at the item's top-level dir). - **VI with exactly 1 Epic** → no picker; set `focus_key` to that Epic and proceed. - **VI with ≥2 Epics** → render the picker. `implement:`'s **done-predicate is the Epic's Jira status** (`linked_items[].status`): map *done / closed / resolved* → ● (greyed, not default-selectable; selecting offers "implement anyway"), *in progress / in review* → ◐, anything else → ○; always show the raw status text beside each row so a lagging status can't mislead. If the export carries no status, degrade to a plain unstatused selection list. Include the explicit choice **"Implement one broad VI-level slice instead"** (`focus_key` stays null → specs resolve VI-level). Selecting an Epic sets `focus_key` and proceeds for **that Epic only** — there is **no "Next Epic?" loop** (code-writing is heavy and branchy; each `implement:` run targets one Epic). - **VI with 0 Epics** → offer: split with `epics:` first (then re-import), or implement one broad VI-level slice (`focus_key` stays null). When the picker (or the 1-Epic auto-path) sets `focus_key` that was initially null, **re-resolve `specs`** per the shared reference §Specs-resolution now that `focus_key` is set — the front-end's first pass resolved `specs` with `focus_key` null, so it must run again to pick up the Epic's nested per-Epic home. Rules: - The **primary description** is: the spec file if one was given → else the spec-folder design doc → else the inline prose. Echo `📄 Reading prompt from …` (or `from inline text`) and confirm `"Loaded prompt (N lines)."`. - **Design-doc open-question guard.** If the primary description is a **design doc** — a file named `design.md` or matching `*-design.md` (the `design:` output; distinct from a `specification.md`) — scan it for unresolved `- [ ]` open questions under its `## Open questions` heading. If any exist, **refuse to proceed**: `choices: ["Cancel — resolve the design's open questions in design: first (Recommended)", "Override and implement anyway (logged in the Phase 5 report)", "Other… (describe)"]` A design must be decision-complete before implementation (enforced upstream by `design-reviewer`; this is the cross-command backstop). **`specification.md`-level open questions are exempt** — they are the spec's way of flagging what the design phase resolves, and a design doc may legitimately incorporate a spec that still carries them. "Override" is the only escape and is recorded in the Phase 5 report's `### Assumptions & limitations`. - Multiple inputs of the same kind are allowed. - A referenced `@dir` that is missing, or is neither a recognized folder type nor a git repo, MUST be surfaced to the user immediately (do not silently skip) — then ask whether to continue without it or stop. This mirrors `~/.copilot/installed-plugins/ihudak-copilot-plugins/dev-workflows/skills/_shared/model-routing.md` §8.4. - Note any embedded images as "referenced image: ". - If a single `@file` cannot be read, stop and report the error immediately. - **Specs are required for jira-driven runs.** When `mode: jira-driven` and the front-end resolved `specs: []`, do not plan blind — prompt: `choices: ["Point me at a specs directory (you'll provide the path)", "Proceed without specs — not recommended", "Cancel"]` "Point me…" takes a path, classifies it as a spec-folder, and re-resolves `specs`. "Proceed without specs" is logged in the Phase 5 report's `### Assumptions & limitations`. Direct-mode runs (no Jira input) are exempt — the prompt/spec file is the instruction. **Specs-repo preflight.** Cite `~/.copilot/installed-plugins/ihudak-copilot-plugins/dev-workflows/skills/_shared/specs-repo-git.md` and execute its `specs-preflight` entry point (§3) inline: flush any leftover session artifacts from an earlier run, retry an artifact commit that failed to push, and settle the branch. This runs against `$SPECS_PATH` only — `git -C "$SPECS_PATH"`, never a `cd`, so the code/docs repo this run is working in is untouched (§1 rule 1). Prompt-free and silent when the specs repo is clean and on its default branch. If a guard fires, emit its §5 notice; if it returns `specs_git: blocked` (§3.3 G0), carry that flag for the whole run — the terminal `commit-artifacts` step skips on it. **Gate the in-scope specs on `$SPECS_PATH`'s main.** This runs after the cheap `focus_key`-null `jira-reader` classification above — a deliberate, bounded exception to `~/.copilot/installed-plugins/ihudak-copilot-plugins/dev-workflows/skills/_shared/phase-handoff.md` §5 rule 2's "before its first subagent dispatch", and structurally forced: this gate's `specs` set is derived from `focus_key`, which that dispatch resolves. The exception is bounded to that one read-only Epic-unit classification; every expensive step still follows the gate. (`epics:` records its own §5 rule 2 deviation the same way.) For each resolved `specs` path whose basename is `specification.md` or `design.md` — `implement:`'s **in-scope** spec/design files, the same set Phase 2B and the invariants section reference for the conformance dimension — execute `require-on-main` (`~/.copilot/installed-plugins/ihudak-copilot-plugins/dev-workflows/skills/_shared/phase-handoff.md` §3) against it, mapping its §3.7 return value by `stopped` first, never by `on_main` alone. Any stopping state → stop per §4.4, naming `$SPECS_PATH` explicitly — `implement:` stands in a **code** repo, so an unqualified stop message would point at the wrong repository. Otherwise (`stopped: false`): `pass`/`pass_amending` → proceed (on `pass_amending`, print §3.3's row-B message — reachable only when an **earlier** `implement:` run's Phase 4.5 handoff created the branch and `specs-repo-git.md` §3.5 B3 kept this run's preflight checkout on it — never this run's own Phase 4.5, which has not executed when this Phase 0 gate runs; `implement:` does not itself author `specification.md`/`design.md`, so a leftover `spec/`/`design/` branch left by an earlier `specify:`/`design:` run is never row B for this gate — it is row C/C′, and the stop/repair path above already covers it). `absent` → **only an in-scope spec is gated at all** — a direct-prompt run resolves none of these `specs` entries and is entirely unaffected, so do not stop; behave exactly as before this feature. `unmanaged` → behave exactly as before this feature. A spec/design supplied directly as a lone `@path` primary description — the Design-doc open-question guard's own input above, a separate mechanism from the `specs` list this gate reads — is **out-of-contract**: read where it sits, deliberately not gated here, the same rule this plan set for `create-vi: @`. --- ## Phase 0.5 — Readiness pre-flight (jira-driven only; advisory) **Jira mode only.** When `mode: direct` this phase is a **no-op** — skip it entirely (direct-mode runs are byte-identical to before). When `mode: jira-driven`, read the resolved item's declared Jira status (reuse the Phase 0 `vi-plus-epics` read if it ran, else a cheap Status-column read of `/-index.md`). Also, if `$SPECS_PATH` is set, check for a co-located `_readiness.md` in the item's specs dir. Surface a **one-line, non-blocking** recommendation to run `ready: []` first when EITHER: the status is below the readiness bar (VI below **Ready for Implementation**; Epic below **Refined**), OR a `_readiness.md` records **NOT-SUPPORTED** / **PARTIAL**. This NEVER blocks — proceed regardless; it is guidance only. If neither condition holds, say nothing and continue. --- ## Phase 1 — Clarification **Rule: Ask, don't guess. This rule is absolute.** Before producing a plan, analyze the description for: - Ambiguous scope or unclear boundaries - Missing constraints (performance, security, backwards-compatibility) - Multiple valid implementation approaches - Undefined integration points or dependencies - Missing acceptance criteria If **any** ambiguity exists, ask the user. Rules: - Use `choices` arrays for every question — never plain text questions - The **last choice** in every `choices` array MUST be `"Other… (describe)"` to allow free-text - When a clearly superior default exists, make it the first choice and label it `"(Recommended)"` - Group related decisions into a single question (minimize total questions) - Do **not** proceed until all questions are answered If **nothing** is ambiguous, skip directly to Phase 1.5. --- ## Phase 1.5 — Classify task complexity Load and follow the model-routing policy at `~/.copilot/installed-plugins/ihudak-copilot-plugins/dev-workflows/skills/_shared/model-routing.md`, then classify the task as exactly one of: - **SIMPLE** — local, trivial, clearly reversible; no mandatory Opus steps - **MODERATE** — bounded scope, few files, clear requirements; no mandatory Opus steps - **SIGNIFICANT** — risky in at least one dimension from the classification reference; Opus planning + Opus review are mandatory - **HIGH-RISK** — multiple risky dimensions, or security/migration/compliance scope; Opus planning + Opus review are mandatory and must be especially thorough State the classification and the specific criterion that triggered it. When in doubt between MODERATE and SIGNIFICANT, pick SIGNIFICANT. **Resolve the per-step routing.** Following `~/.copilot/installed-plugins/ihudak-copilot-plugins/dev-workflows/skills/_shared/model-routing.md` §9, record a `model_routing` block resolving each model against the fallback chains: ```yaml model_routing: classification: reason: current_model: # = the inline implementation coding detection_model: <§2.1 detection chain: claude-sonnet-4.6, fallback claude-sonnet-4.5/gpt-5.4> # jira-reader, code-scanner, Phase 2A exploration, test-writer, test-baseliner, review-fixer planning_model: <§2 Opus chain> # risk-planner (Phase 2B; SIGNIFICANT/HIGH-RISK only; dispatch-pinned to this chain, recorded, no override) review_model: <§2 Opus chain> # code-review (Phase 3B; dispatch-pinned to this chain, recorded, no override) implementation_model: <= current_model> # coding done inline by the orchestrator fixes_model: <= detection_model> # review-fixer (Phase 3B) opus_available: notes: ``` Each subagent dispatch below cites its chain (§9 role→chain map); mechanical steps pin `detection_model` via `model:`, and the dispatch-pinned Opus gates (`risk-planner`, `code-review`) are recorded but never overridden. **Detect task shape.** Inspect the description for defect signals (fix / bug / regression / broken / incorrect / wrong output / crash / fails). If bug-shaped, set `task_shape: bug`. `task_shape: bug` only affects the SIGNIFICANT / HIGH-RISK path (Phase 2B/3B); for SIMPLE / MODERATE it is guidance only (no extra question). On the SIGNIFICANT / HIGH-RISK path, if it is genuinely ambiguous whether this is a defect fix or new work, ask with a `choices` prompt (last choice `"Other… (describe)"`). Then choose the branch: - **SIMPLE / MODERATE** → continue to Phase 2A (standard planning) - **SIGNIFICANT / HIGH-RISK** → continue to Phase 2B (Opus-planned) --- ## Phase 1.6 — Input scale assessment From the Phase 0 classification, compute: - `repo_count` = number of code repos (cwd + referenced git-repo dirs) - `has_ticket_folder` = any Jira ticket folder present - `has_spec_folder` = any spec/design folder present Set `fan_out = (repo_count > 1) OR has_ticket_folder OR has_spec_folder`. - **`fan_out = true`** → the input is multi-source. Per `~/.copilot/installed-plugins/ihudak-copilot-plugins/dev-workflows/skills/_shared/model-routing.md` §1.1 (the multi-source trigger; see §8 for the fan-out policy) this floors the classification at **SIGNIFICANT** (raise it now if Phase 1.5 chose SIMPLE/MODERATE). Announce: `"Multi-source input detected () — flooring at SIGNIFICANT; this is overridable at plan approval."` Then run **Phase 1.7** (fan-out scan) and continue on the SIGNIFICANT/HIGH-RISK branch (Phase 2B). - **`fan_out = false`** → unchanged behavior; skip Phase 1.7 and proceed to Phase 2A or 2B exactly as the Phase 1.5 classification directs (the single-explorer path). --- ## Phase 1.7 — Multi-source exploration (only when `fan_out = true`) Runs after Phase 1.6 and replaces the single Phase 2B exploration subagent for multi-source input. Follows `~/.copilot/installed-plugins/ihudak-copilot-plugins/dev-workflows/skills/_shared/model-routing.md` §8. 1. **Read Jira ticket folders.** For each Jira ticket folder, invoke `jira-reader` (read-only): → task(agent_type: "dev-workflows:jira-reader", model: ``): > "Return the structured handoff for this brief — linked items, PR URLs (identifiers only — no fetching), and capability themes: > > jira_export_root: [the resolved jira_export_root (from the Phase 0 front-end), or the ticket-folder absolute path] > jira_key: [the resolved ] > depth: full" Run multiple `jira-reader` calls sequentially (it is fast and read-only). Collect the themes and PR references. When `focus_key` is set, scope the collected result to the focus Epic's subtree: keep the focus Epic plus the items linked beneath it (its Stories / Sub-tasks) and drop sibling Epics' subtrees before folding themes/PRs into the plan. `jira-reader` itself is not modified — the scoping is done here, mirroring `specify:`. 2. **Read spec/design folders inline.** Read each spec-folder `.md` and fold its content into the themes and primary description. 3. **Fan out `code-scanner` — one per repo, single response, cap 4 concurrent.** Spawn all repo scanners in **one** message (batch in groups of 4 if there are more than 4 repos). For each code repo: → task(agent_type: "dev-workflows:code-scanner", model: ``): > "repo_path: > capability_themes: > context: <3–5 sentences: the implementation goal and what the change must accomplish> > search_hints: " Wait for all scanners in the batch to return. A scanner returning `REPO_MISSING` — the path is not a directory — escalates per the `Repo missing (after resolution)` rule in `~/.copilot/installed-plugins/ihudak-copilot-plugins/dev-workflows/skills/_shared/escalation-rules.md`; `DIRTY_TREE` escalates per the `Dirty working tree` rule and `REFRESH_BLOCKED` per the `Refresh blocked` rule in the same file. None is ever hidden, and none is merely announced — each offers the user a way forward (§8.4). A scanner returning `prep.read_only: true` is not a failure — it scanned at `prep.scanned_ref`; escalate per the `Read-only mount — ref stale or diverged` rule in `~/.copilot/installed-plugins/ihudak-copilot-plugins/dev-workflows/skills/_shared/escalation-rules.md` only when `prep.ref_committed_at` is more than 14 days old or `prep.head_divergence.ahead > 0`, and cite evidence at `prep.scanned_ref`. **Round 2 — narrow and seeded (§8.5).** Apply `~/.copilot/installed-plugins/ihudak-copilot-plugins/dev-workflows/skills/_shared/model-routing.md` §8.5. A theme is **inconclusive** when its round-1 `classification` is `partial`, `absent`, or `error`, or when **two or more** scanners' per-theme `capability_map[].gap_summary` texts point at each other's repo in a cycle, or at a component/subsystem that no scanned repo covers — the shape that yields confident answers which together say nothing. For every inconclusive theme that round 1 left at least one evidence anchor for, dispatch `code-scanner` again on `` with `capability_themes` holding exactly **one** question — the single thing round 1 failed to settle, not the broad theme — and `search_hints.paths`/`.symbols`/`.keywords` seeded from that round's verified `evidence[].path` and `.symbols`; where an evidence entry carries `lines`, name the anchor as `:` in the `context` prose. Cap **4 dispatches, one round only** — there is no round 3. This matters more here than where §8.5 was first adopted: `idea:`'s summary feeds a grill with a human in it, while this one feeds a planner whose output becomes code. **A theme round 1 left with no evidence anchor never enters round 2** — it stays inconclusive with no round-2 attempt possible, and that absence of an attempt is not itself a resolution. 4. **Synthesize.** Combine the `jira-reader` output, all `code-scanner` reports, and the spec into a single **multi-source codebase summary** (per-repo: relevant files, existing capabilities, gaps; plus the cross-repo picture and the Jira themes/PR references). This summary is the codebase context for Phase 2B — do **not** also run the single Explore subagent. Write this summary to a temp file (`mktemp -t dw-impl-summary-XXXX.md` — **never inside a repo working tree**, so a captured `git diff` never picks it up) and record its absolute path as `summary_file`; Phase 2B receives this path, not the pasted summary. **Name what the scan did not settle.** The summary carries a `## Unresolved` section listing **every theme still inconclusive at the end of Phase 1.7** — this explicitly includes a theme that never entered round 2 because round 1 left no anchor to seed from, a theme classified `error`, and a mutual-deferral theme, whether or not either scanner logged an anchor. None of these becomes resolved merely by having had no round-2 attempt. Per `model-routing.md` §8.5 Bounds, name **why** each theme is unresolved — mutual deferral / scan error / partial-or-absent with no anchor — and give the repos-and-conclusions detail only where scanners actually disagreed. An inconclusive theme is **never** folded in as an ordinary gap: a gap asserts the capability is absent with no deferral outside the scanned set, an unresolved theme asserts only that the scan could not tell, and once flattened the two are indistinguishable to the planner. Omit the section entirely when nothing is unresolved. --- ## Phase 1.8 — Resolve applicable ARD (Jira mode; optional) Only when the run resolved a Jira key (VI/Epic) — i.e. NOT direct-prompt mode — resolve any ARD by citing `~/.copilot/installed-plugins/ihudak-copilot-plugins/dev-workflows/skills/_shared/ard-resolution.md` with the resolved ``, ``, and `$SPECS_PATH`. Direct mode (no Jira key) → treat as `status: none`. On `status: none`, **skip and proceed exactly as before**. On `status: unmerged`, **stop**, naming the returned `branch` and any `pr` and naming `$SPECS_PATH` explicitly (`implement:` stands in a code repo, not the specs repo, so an unqualified message would point at the wrong one) — per `ard-resolution.md`'s Output section, this state is unreachable when no ARD resolves. On `status: found`, carry the `invariants` as **implementation guardrails** (the implementer honors each `AD#N` `rule`; a necessary deviation is logged as an `- ARD deviation:` line in the Phase 5 report), and — in the SIGNIFICANT / HIGH-RISK path — pass them to `code-review` (Phase 3B) as `applicable_ard`. In the SIMPLE / MODERATE path there is no `code-review` gate, so the guardrails act as guidance only. --- ## Phase 2A — Standard Plan (SIMPLE / MODERATE only) **Codebase exploration** — Before writing the plan, spawn an exploration subagent to map the relevant parts of the codebase: → task(agent_type: "general-purpose", tools: view/glob/grep only — no bash, no edit, model: ``): "Given this implementation description: [paste the full implementation description from Phase 0 or Phase 1 here], find and return: - Relevant source files and their primary responsibility - Existing patterns and conventions used in this codebase - Test file locations and test naming conventions - Naming conventions (class names, method names, file names) Return a structured summary — no code changes, no file edits." **Wait for the agent's response before proceeding. If the agent returns no relevant files or fails, proceed with the plan using your own file reads to gather context. Do not begin writing the plan until the file map is returned or you have gathered context yourself.** → Use the returned file map as codebase context when writing the plan below. Produce a written implementation plan: 1. **Classification** — `SIMPLE` or `MODERATE` (with reason) 2. **Goal** — one-sentence summary of what will be built 3. **Approach** — chosen strategy and why 4. **Steps** — numbered, concrete implementation steps 5. **Files to create/modify** — list with brief rationale 6. **Tests** — what tests will be added or run 7. **Assumptions** — decisions made without user input (must be minimal) 8. **Out of scope** — explicitly list what is NOT being done Then ask: ``` "Implementation plan ready. What would you like to do?" choices: ["Approve & implement now (Recommended)", "Revise plan", "Cancel"] ``` - **Approve** → write the approved plan to a temp file (`mktemp -t dw-impl-plan-XXXX.md`, never inside a repo tree) and record its absolute path as `plan_file`; proceed to Phase 3A - **Revise** → ask what to change, update, re-show, re-ask - **Cancel** → stop and summarize what was planned --- ## Phase 2B — Opus-planned (SIGNIFICANT / HIGH-RISK) **Codebase exploration** — If Phase 1.7 ran (`fan_out = true`), use its **multi-source codebase summary** (already written to `summary_file` in Phase 1.7 step 4) as the codebase context and skip the single Explore subagent. Otherwise, run the same exploration subagent call as Phase 2A (same prompt, same fallback rule), then write the Explore agent's returned output to a temp file (`mktemp -t dw-impl-summary-XXXX.md`, never inside a repo tree) recorded as `summary_file`. Either way, `summary_file` holds an absolute path before the planner is dispatched. Once the file map is returned, delegate planning to Opus. When a `specification.md`/`design.md` is in scope, extract its **in-scope** `[Uxx]`/`[ACxx]`/`[TCxx]` IDs (reuse the specs resolved in Phase 0) into `in_scope_ids` for the review dispatch below. When `task_shape: bug`, the plan will lead with a repro step and a ranked-hypotheses section — surface them in the normal plan-approval gate (no extra interrupt) **when the ranking is present**. When the planner instead returns `Ranking withheld — no red-capable repro`, the withheld-repro branch below fires first and the normal gate does not run. → task(agent_type: "dev-workflows:risk-planner"): # planning_model — §2 Opus chain; dispatch-pinned to this chain, recorded in model_routing, no override added > "Produce the risk-weighted plan for the following brief: > > Task description: [substitute full description] > Classification: [SIGNIFICANT | HIGH-RISK] — reason: [the criterion from Phase 1.5, or the multi-source floor from Phase 1.6 when fan_out] > Codebase summary: read it from the file at [the `summary_file` absolute path] > Constraints: [any from clarification, plus runtime/version/deadline known] > Current state: branch = [git branch], uncommitted = [git status --short summary] > Specs in scope: [the resolved specification.md/design.md path(s) from Phase 0, or "none"] > Unresolved scan themes: [the summary's `## Unresolved` entries, or "none"] — each is a theme the scan could not settle, NOT a confirmed gap; carry every one into the plan's risks and never plan as though its location is known > task_shape: [bug | omit]" **Wait for the risk-planner to return.** Its output is one of: 1. A full plan in the risk-weighted format (the normal case). 2. A short `### Re-classification` section, if the planner decided on inspection that the task is actually `SIMPLE` or `MODERATE`. **If the return contains `### Re-classification`:** surface it to the user, ask for confirmation of the revised level with a `choices` prompt (`["Accept revised classification (Recommended)", "Override and stay SIGNIFICANT/HIGH-RISK", "Cancel"]`). If the user accepts, **fall back to Phase 2A** (standard plan) using the codebase context already captured above (the `summary_file` path) — the Phase 1.7 **multi-source codebase summary** when `fan_out = true`, otherwise the Explore summary — and do not re-run exploration. Accepting here is the user exercising the **plan-approval override** of the multi-source SIGNIFICANT floor (Phase 1.6); that is the sanctioned way to leave the fan_out floor. If the user overrides, re-invoke risk-planner with an additional constraint stating the classification is intentional; do not down-classify again. If the user cancels, stop and summarize. **If the return is a full plan whose `### Hypotheses (ranked)` section contains `Ranking withheld`:** the planner could not get a red-capable repro, so its hypotheses are absent by design and the rest of the plan rests on unverified theory. Do NOT fall through to the normal approval gate — its Recommended option is "Approve & implement now", which is exactly the proceed-on-a-guess outcome `~/.copilot/installed-plugins/ihudak-copilot-plugins/dev-workflows/skills/_shared/bug-diagnosis.md` step 1 forbids. Surface the planner's `Tried:` line verbatim and ask: ``` choices: ["Help construct a repro (you'll be prompted for what to try)", "Proceed without a repro (recorded in the Phase 5 report)", "Cancel"] ``` - **Help construct a repro** → take the user's suggestion, re-dispatch `risk-planner` with it carried in the brief, and re-enter this branch on the new return. - **Proceed without a repro** → record it in the Phase 5 report's `### Assumptions & limitations` as `No repro: ` and continue to the normal full-plan gate below. - **Cancel** → stop. **If the return is a full plan** (ranking present, or the user chose to proceed without a repro)**:** present it to the user verbatim and ask: ``` "Opus-planned. What would you like to do?" choices: ["Approve & implement now (Recommended)", "Revise plan", "Cancel"] ``` - **Approve** → write the approved plan to a temp file (`mktemp -t dw-impl-plan-XXXX.md`, never inside a repo tree) and record its absolute path as `plan_file`; proceed to Phase 3B - **Revise** → ask what to change, then re-invoke risk-planner with the **complete** brief plus the additional constraint merged in (never send just a delta — the planner refuses to plan without a full brief). Re-show, re-ask. - **Cancel** → stop and summarize --- ## Pre-Phase 3 — Create feature branch Before writing any file: 1. **Clean-tree check** — Run `git status --porcelain`. If the output is non-empty: - Show the user what is dirty (paste the `git status --short` output). - Ask: ``` choices: ["Stash changes and continue (Recommended)", "Proceed anyway — pre-existing changes will appear in the diff and review outputs", "Cancel"] ``` - **Stash**: run `git stash push -m "pre-impl stash"`, then continue. Record the resulting stash as `stash_ref` — Phase 4.6 names it in its outcome line, and never drops it (`~/.copilot/installed-plugins/ihudak-copilot-plugins/dev-workflows/skills/_shared/code-repo-handoff.md` §2.2 carve-out 2). - **Proceed**: note in the Phase 5 report that the working tree was dirty at implementation start, **and record the `git status --porcelain --untracked-files=all` paths as `pre_existing_dirty`**. A clean tree records `pre_existing_dirty: null` and `stash_ref: null` — the state Phase 4.6's precondition assumes. Phase 4.6 needs them to avoid sweeping somebody else's uncommitted work into this run's commit (`~/.copilot/installed-plugins/ihudak-copilot-plugins/dev-workflows/skills/_shared/code-repo-handoff.md` §2.2 carve-out 1); a run that does not record them here cannot honour that carve-out later. - **Cancel**: stop and summarize what was planned. 2. **Resolve the branch name** per `~/.copilot/installed-plugins/ihudak-copilot-plugins/dev-workflows/skills/_shared/branch-naming.md` — **the repo's own documented convention wins**. Read the target repo's `CONTRIBUTING.md`, `CONTRIBUTION.md`, `README.md`, `DOCUMENTATION-GUIDELINES.md`, `.github/copilot-instructions.md` (+ `.github/`) for a branch-naming section (§1.1); if one is found, classify its segments (§1.2) and fill them: an **identity** placeholder (``, ``, …) from the §2 ladder (`$GIT_USER_INITIALS` → `git config user.initials` → inference from existing branches → the §2.5 prompt), an **issue-key** segment from the `jira_key` resolved in Phase 0 (or the pattern's documented no-issue literal in direct mode), and the **description** segment from step 3's slug. A pattern with no identity segment gets none — never inject initials into a convention that does not ask for one. Only when the repo documents no convention (§1.4) build `/` with `` from the §2 ladder, whose fallback here is `feat/`. 3. **Generate slug** — derive from the implementation description: lowercase, hyphens, max 40 chars, strip punctuation and special chars. Example: "Add user authentication to login page" → `add-user-authentication-login-page`. When a `jira_key` is resolved and the chosen shape has no separate issue-key segment, prefix it: `-`. 4. **Check HEAD context** — if HEAD is NOT on the default branch (`main` / `master` / `develop`), check for ahead commits: `git log origin/HEAD..HEAD --oneline 2>/dev/null`. If output is non-empty (branch has commits ahead), ask: ``` choices: ["Branch from current position — continue on this work (Recommended)", "Branch from default branch — fresh start", "Cancel"] ``` 5. **Create and checkout** — `git checkout -b /`. If that name already exists, append the first 7 chars of HEAD's SHA: `/-`. --- ## Pre-Phase 3.5 — Capture test baseline Placed **after** branch creation (Pre-Phase 3), **before** any file edits. The `.5` numbering signals "inserted between step 3 and step 4 of the existing ordering" — it is its own phase, not a sub-step of Pre-Phase 3's branch-creation steps. Invoke the `test-baseliner` agent in capture mode: → task(agent_type: "dev-workflows:test-baseliner", model: ``): > "Run the agent in the following mode: > > Mode: capture > Project root: [absolute path of the current working directory]" Store the returned `## Test Baseline` block verbatim — it will be passed to `test-baseliner` again in verify mode at Phase 3.5 and to `test-writer` as the baseline snapshot. If `Framework: not detected`, note it in session memory but continue — Phase 3.5 will surface the missing-framework case to the user explicitly. --- ## Phase 3A — Implementation (SIMPLE / MODERATE) **Implement immediately. Do NOT ask "Should I implement?" or any variation.** 1. Work through each step in order 2. Make precise, surgical changes — do not modify unrelated code 3. Follow existing code style and LF line endings 4. Assume broad permissions; avoid unnecessary stops 5. If a **new ambiguity** emerges mid-implementation: STOP, ask with choices (last: `"Other… (describe)"`), resume after answer 6. **Run Phase 3.5 below** (test writing + regression verification) — do NOT run tests directly here; Phase 3.5 owns the lint/build/test sequence and the fix loop 7. Verify the outcome matches the approved plan 8. Proceed to Phase 4 (post-implementation maintenance). --- ## Phase 3.5 — Write and verify tests (SIMPLE / MODERATE) Runs after Phase 3A step 5 completes (all code changes written), before the outcome-verification step. 1. **Invoke `test-writer` agent.** First, at the orchestrator, capture the diff for the dispatch: write `git add -N . && git diff` (so new files are included) to a temp file (`mktemp -t dw-impl-diff-XXXX.patch`, never inside a repo tree) and record its absolute path as `test_diff_file`. `test-writer` has no shell tool — it can only `view` the path it is given. Then spawn: → task(agent_type: "dev-workflows:test-writer", model: ``): > "Write tests for this brief: > > Task description: [substitute full description] > Plan: read it from the file at [the `plan_file` path recorded at Phase 2A approval] > Diff: read it from the file at [the `test_diff_file` path] > Project root: [absolute path] > Baseline: [paste the ## Test Baseline block captured in Pre-Phase 3.5]" 2. **Handle a `test-writer` stop.** Check the report's first line before anything else. If it is `Diff: unreadable at `, the orchestrator's own `test_diff_file` could not be read — this is an orchestrator bug, not a user choice: surface the unreadable path to the user and **stop the run**; do not run the framework prompt below, and do not offer to skip tests (skipping would silently proceed past evidence that could not be read). Otherwise, if the report shows `Framework: not detected`, ask the user: ``` choices: ["Specify test command to use", "Skip tests for this run (document why in the final report — Phase 5 of the inherited implement: workflow)", "Cancel"] ``` - **Specify test command** → take free-text, use it as the test runner for step 4 below; continue. - **Skip tests** → take free-text rationale; record it in the Phase 5 `### Deferred items` section; skip steps 3–5 of Phase 3.5 and proceed to Phase 3A step 7 (Verify outcome). - **Cancel** → stop and summarize. 3. **Run linters and builds.** Use the project's standard lint/build commands as discovered in Phase 2A exploration. Do not run the full test suite here — that is step 4. 4. **Invoke `test-baseliner` in verify mode** against the baseline captured in Pre-Phase 3.5: → task(agent_type: "dev-workflows:test-baseliner", model: ``): > "Run the agent in the following mode: > > Mode: verify > Baseline: [paste the captured ## Test Baseline block] > Project root: [absolute path]" 5. **Fix loop** — if the verify report lists regressions or new failures: - The **session model** (not a subagent) applies fixes. No `review-fixer`-style indirection is used here — the scope is narrow and the context is already fully in-session. Use the `test-baseliner` verify report as the authoritative list of what broke. - After each fix attempt, re-capture the diff (`git add -N . && git diff`) and re-run `test-baseliner` in verify mode against the **original** baseline (never re-baseline mid-loop — a mid-loop re-baseline would silently absorb a regression as the new normal). - Cap at **2 fix attempts**. If regressions remain after the second attempt, surface to the user: ``` choices: ["Investigate further", "Accept regressions and proceed (document in Phase 5 report)", "Cancel"] ``` - **Investigate further** → stop the automated loop; the session model diagnoses manually and re-runs verify when ready. - **Accept regressions** → record each regression in the Phase 5 `### Deferred items` section with the user's rationale; proceed. - **Cancel** → stop and summarize. Once Phase 3.5 returns (passed, skipped, or accepted-with-regressions), return to Phase 3A step 7 (Verify outcome). --- ## Phase 3B — Implementation + Opus review (SIGNIFICANT / HIGH-RISK) Use the currently selected model or Sonnet for implementation itself. Opus is reserved for the review. For a long step list, apply `~/.copilot/installed-plugins/ihudak-copilot-plugins/dev-workflows/skills/_shared/context-management.md` — checkpoint at N, offload parallel-safe (`[P]`) steps to subagents, or decompose — so the run does not degrade as context fills. At each checkpoint, also consider suggesting **`/compact`** to free context before the next scope/Epic (per `~/.copilot/installed-plugins/ihudak-copilot-plugins/dev-workflows/skills/_shared/session-hygiene.md` §3 — mid-command → `/compact` only, never `/clear`; guidance only). 1. Work through each step in order 2. Make precise, surgical changes — do not modify unrelated code 3. Follow existing code style and LF line endings 4. If a **new ambiguity** emerges mid-implementation: STOP, ask with choices (last: `"Other… (describe)"`), resume after answer 4a. **Invoke `test-writer` agent** (inserted before the review diff capture in step 5 so the Opus review sees code and tests together — test adequacy is already a review dimension in `code-review.md`). First, at the orchestrator, capture the diff for the dispatch: write `git add -N . && git diff` (so new files are included) to a temp file (`mktemp -t dw-impl-diff-XXXX.patch`, never inside a repo tree) and record its absolute path as `test_diff_file`. `test-writer` has no shell tool — it can only `view` the path it is given. Then spawn: → task(agent_type: "dev-workflows:test-writer", model: ``): > "Write tests for this brief: > > Task description: [substitute full description] > Plan: read it from the …(truncated)