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:

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 <VI> <Epic>, a bare nested <Epic>, 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 <file>… (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: <KEY> @<path>.

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 <jira_export_root>/<jira_key>-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: <VI> [<Epic>] 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:

model_routing:
  classification: <SIMPLE | MODERATE | SIGNIFICANT | HIGH-RISK>
  reason: <one-line>
  current_model: <the model this orchestrator is running under>   # = 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: <true if a §2 Opus model resolved, else false>
  notes: <any §2 / §2.1 fallback or degradation>

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 (<facts>) — 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: <detection_model — §2.1 detection chain>):

   "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: <detection_model — §2.1 detection chain>):

   "repo_path: capability_themes: <themes from steps 1–2 + the implementation spec> context: <3–5 sentences: the implementation goal and what the change must accomplish> search_hints: <symbols/paths/keywords derived from the spec, if any>"

   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 <detection_model — §2.1 detection chain> 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 <path>:<line> 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 <VI>, <EPIC>, 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: <detection_model — §2.1 detection chain>): "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: <what the planner tried> 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 (<your-name-or-initials>, <user>, …) 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 <prefix>/<slug> with <prefix> 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: <jira_key>-<slug>.

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 <prefix>/<slug>. If that name already exists, append the first 7 chars of HEAD's SHA: <prefix>/<slug>-<short-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: <detection_model — §2.1 detection chain>):

"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: <detection_model — §2.1 detection chain>):

   "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 <path>, 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: <detection_model — §2.1 detection chain>):

   "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: <detection_model — §2.1 detection chain>):

   "Write tests for this brief:

   Task description: [substitute full description] Plan: read it from the

…(truncated)