pi-dev-team 0.2.0

package/docs/upstream/test-improve.md

@@ -0,0 +1,154 @@
+# `/test-improve`
+
+**File:** [`skills/test-improve/SKILL.md`](https://github.com/bdfinst/agentic-dev-team/blob/main/plugins/dev-team/skills/test-improve/SKILL.md)
+**Role:** orchestrator.
+
+`/test-improve` is the **consolidated** analyze-then-improve orchestrator for
+legacy or in-flight test suites, and one of the plugin's two multi-phase
+pipelines with inter-phase human gates (the other is [`/ship`](workflows.md#ship)).
+It defaults to lightweight ceremony, prompts for heavier capabilities
+(Gherkin extraction, mutation testing, refactor-for-testability) only on
+demand, and always baselines coverage (and mutation, when enabled) before any
+test change.
+
+This page is the canonical phase reference. For where `/test-improve` sits
+among the plugin's other commands see [workflows.md](workflows.md); for how it
+fits the wider agent architecture see
+[agent-architecture.md](agent-architecture.md#test-improvement-workflow-test-improve).
+
+![/test-improve ten-phase (0-9) workflow with human gates between each phase](diagrams/test-improve-flow.svg)
+
+## Phases
+
+Each phase writes a progress file to
+`.claude/memory/test-improve/<slug>/phase-<n>.md` so `/continue` (and `--from-phase`)
+can resume.
+
+**Execution order.** Phases keep their historical identity numbers (Phase 1
+is always Analyze, Phase 2 is always Baseline, etc.), but **Baseline (Phase 2)
+and Derive Gherkin (Phase 3) execute before Analyze (Phase 1)** so
+`/test-health` can use documented-but-untested Gherkin scenarios as a
+coverage signal: `0 → 2 → 3 → 1 → 4 → 5 → 6 → 7 → 8 → 9`. Phase 7 and Phase 8
+are **not alternatives** — when Phase 6 returns `[y]`, both run in sequence;
+otherwise Phase 8 follows Phase 6 directly. When the BDD binding mode is
+`none`, Phase 3 is skipped and the sequence becomes
+`0 → 2 → 1 → 4 → 5 → 6 → 7 → 8 → 9`. The list below follows this execution
+order, not numeric order. The phase-start banner prints a separate
+`Step <position>/<total> — Phase <N>: <name>` counter — `<position>` is a
+running count of phases printed so far this run (never a fixed per-identity
+slot), and `<total>` is computed per run (base 9, -1 when BDD binding mode
+is `none`, +1 once Phase 6 enters Phase 7) rather than a hardcoded 9 or 10.
+
+- **Phase 0 — Approach contract.** Batched prompt (Enter accepts all
+  defaults): mutation mode `[kill-loop]` (`off` / `kill-loop` /
+  `baseline+kill-loop`), BDD rubric `[none]`, refactor `[no-refactor]`,
+  quality targets, sink (`--parent <url>` vs local files), and the all-or-none
+  code-lookup install (explicit `y`/`n`, not part of Enter-accepts-all). An
+  Enter-through run now performs the mutant-kill loop by default. Go stack shows
+  the alpha go-mutesting advisory before the mutation prompt. Answers are
+  immutable for the run. A stated coverage target that is structurally
+  unreachable under `no-refactor` is surfaced here as `[w] waive / [s] switch
+  to refactor-allowed / [c] continue as-is`, computed by
+  `scripts/coverage_gap_ranking.py`; with no coverage report on disk yet the
+  check is recorded `deferred` and re-run at Phase 2 (#1787).
+- **Phase 2 — Baseline (before any test edit).**
+  `/coverage-baseline --workflow test-improve` unconditionally;
+  `/mutation-testing --baseline --workflow test-improve` only in
+  `baseline+kill-loop` mode (`off` and `kill-loop` take no baseline).
+  Go = advisory-only marker. Honest score = hard kills, timeouts separate.
+  Then `scripts/coverage_gap_ranking.py` writes
+  `data/coverage-gap-ranking.json` — per-module buckets ranked by uncovered
+  lines descending, each marked `seam: established|absent` — the targeting
+  input Phases 1, 4, and 5 read instead of mutation survivors (#1786), and the
+  place a deferred Phase-0 conflict check resolves.
+- **Phase 3 — Derive Gherkin (conditional).** `none` skips entirely (Phase 1
+  follows Phase 2 directly in that case); `xunit-with-annotations` writes
+  `.feature` files without a runner; `bdd-runner` wires the native parser.
+- **Phase 1 — Analyze.** Delegate to `/test-health` (sole worker). No
+  separate calls to `/cd-test-architecture`, `/test-design`,
+  `/mutation-testing`. Whenever a coverage percentage is a stated goal, the
+  improvement plan's coverage-driven items are ordered by
+  `coverage-gap-ranking.json` rank, never by mutation survivor count —
+  survivors order work only *within* a `seam: established` module (#1786).
+  Mutation section respects Phase-0 setting. A
+  separate, direct classification pass persists a before-snapshot of test
+  counts by MinimumCD type to `test-counts-before.json`. `--analyze-only`
+  runs Phase 0 then this phase directly, bypassing the Baseline/Derive-Gherkin
+  ordering above, and exits with no baseline captured.
+- **Phase 4 — Plan fixes.** `/issues-from-assessment --workflow test-improve`
+  partitions findings into `NO_REFACTOR` (Phase-5 Stories) /
+  `REFACTOR_REQUIRED` (deferred to Phase 7) / `LOW_VALUE` (advisory-only). The
+  NO_REFACTOR Story set is written in `coverage-gap-ranking.json` rank order
+  when a coverage percentage is a stated goal (#1786).
+- **Phase 5 — Improve without refactoring.** Per Story: `/build`
+  (no-refactor) → `/coverage-delta --workflow test-improve --story <id>` →
+  `scripts/coverage_delta_steering.py` (three consecutive near-zero-delta
+  Stories exit 3 and prompt `[t] re-check Phase-1 targeting / [c] continue`
+  mid-phase, #1790) → `mutation-kill` agent, dispatched once per module batch
+  (`--file <every story file in the batch> --max-rounds 3
+  --target-honest-score <Phase-0 mutation target>`, #2030; `[c/r/w/q]` on
+  residuals) → `scripts/mutation_yield_steering.py` at the batch boundary
+  (two consecutive batches killing fewer than the minimum net survivors exit
+  3 and prompt the same `[t] re-check Phase-1 targeting / [c] continue`,
+  #2033 — the #1790 mechanism ported to the more expensive lane, sharing its
+  status vocabulary and exit-code contract). End-of-phase review loop
+  dispatches `/code-review --since <base-sha> --internal` once — not a
+  separate `/test-design` dispatch in parallel with it; `test-review` and
+  `test-smell-review` (the two agents `/test-design` used to add) are
+  already in `/code-review`'s own roster for a test/seam-scoped diff, so
+  that dual dispatch was a duplicate and #1966/#1987 removed it — confirms
+  those two test lenses weren't dropped by the change-size gate, scores
+  Farley on the in-scope test files, `/apply-fixes` then a narrowed
+  re-confirmation (not a full re-dispatch), cap 2 iterations, `[r/w/q]`
+  escalation. See `references/review-loop.md` steps 1-5. Evidence in
+  `phase-5-review.json`.
+- **Phase 6 — Refactor decision prompt.** `[y] enter Phase 7 / [b] backlog
+  and skip to Phase 8 / [q] quit`. The letter `y` is deliberately chosen over
+  `r`, which is already claimed by mutation-kill's `[c/r/w/q]` (retry) and the
+  review loop's `[r/w/q]` (revise).
+- **Phase 7 — Refactor-for-testability (conditional).** Only when `[y]`.
+  Seam-only production-code changes; existing tests are immutable. Each Story
+  precondition-checks the paired Phase-5 baseline is closed and green. Same
+  end-of-phase review loop; evidence in `phase-7-review.json`.
+- **Phase 8 — Validate.** `/quality-targets-converge --workflow test-improve
+  --refactor-mode <value>` — threading Phase 0's `no-refactor`/
+  `refactor-allowed` value keeps the coverage-gap dispatch table from
+  proposing a `[Refactor-for-testability]` Story once no-refactor was
+  already chosen at Phase 6; it writes a `refactor-backlog.md` entry
+  instead. Mutation off = skipped (not waived). Go = advisory-only.
+  Coverage < 90% in no-refactor mode → `[y/n]` re-run-in-refactor-allowed
+  prompt lists backlogged items and records `coverage_reprompt_fired: true`
+  in `phase-8.md` (so Phase 9's close-out prompt below doesn't re-ask). The
+  identical classification pass from Phase 1 recounts test-by-type into
+  `test-counts-after.json`. `/handoff` is suggested here, and after Phase 1
+  and the Phase 5/7 review loops — the context-heaviest boundaries.
+- **Phase 9 — Executive-summary report.** Interpolates the shipped
+  [`templates/executive-summary.md`](https://github.com/bdfinst/agentic-dev-team/blob/main/plugins/dev-team/skills/test-improve/templates/executive-summary.md)
+  from the git-tracked `.dev-team-reports/test-improve/<slug>/data/`
+  directory plus `.claude/memory/test-improve/<slug>/` process/audit state to
+  `.dev-team-reports/test-improve/<slug>/report-<date>.md`. 10 numbered sections;
+  empty sections render "Not applicable" (never omitted). § 1 includes a
+  "Tests by type" table (Baseline/Achieved/Δ per MinimumCD type). § 7
+  foregrounds a seam-needed/behavior-gained/estimated-risk table sourced
+  from `refactor-backlog.md`. Parent tracker (or
+  `.claude/plans/test-improve/FEATURE.md`) is updated with a link to the report.
+  Report is regeneratable from memory. After Phase 9, if
+  `refactor-backlog.md` has entries and Phase 8's re-run prompt never fired
+  this run, a close-out `[y/n]` prompt asks whether to re-run with
+  refactor-allowed mode.
+
+## Arguments
+
+`/test-improve <repo-path> [--parent <url>] [--analyze-only] [--from-phase <n>] [--stack <id>]`
+
+| Flag | Behavior |
+| --- | --- |
+| `<repo-path>` | Positional. Path to the repository to improve (required). |
+| `--parent <url>` | Post progress and Stories to this tracker issue URL instead of local plan files. |
+| `--analyze-only` | Run Phase 0–1 only; skip improvement phases. |
+| `--from-phase <n>` | Resume from phase `n` (requires existing `.claude/memory/test-improve/<slug>/` files). |
+| `--stack <id>` | Override auto-detected stack identifier (e.g. `go`, `python`, `java`). |
+
+`/continue` resumes any phase from `.claude/memory/test-improve/<slug>/phase-<n>.md`;
+`--from-phase <n>` does the same explicitly and never re-prompts Phase 0.
+`--analyze-only` runs Phase 0 + Phase 1 and exits before baseline capture.

package/docs/upstream/triage-workflow.md

@@ -0,0 +1,282 @@
+# Triage Workflow: Discovery to Applied Fix
+
+How a defect or review finding travels from discovery to an applied fix. The
+pieces are three individual skills; this document is the lifecycle that
+connects them.
+
+> **Authoritative sources**: the skill specs at
+> [`skills/triage/SKILL.md`](https://github.com/bdfinst/agentic-dev-team/blob/main/plugins/dev-team/skills/triage/SKILL.md),
+> [`skills/code-review/SKILL.md`](https://github.com/bdfinst/agentic-dev-team/blob/main/plugins/dev-team/skills/code-review/SKILL.md), and
+> [`skills/apply-fixes/SKILL.md`](https://github.com/bdfinst/agentic-dev-team/blob/main/plugins/dev-team/skills/apply-fixes/SKILL.md). This
+> document is a reader-friendly walkthrough; where it and a skill spec
+> disagree, the spec wins.
+
+**On this page**: [Lifecycle at a glance](#the-lifecycle-at-a-glance) · [1. Intake](#1-intake-when-to-reach-for-triage) · [2. Investigation](#2-investigation-root-cause-before-recording) · [3. The triage record](#3-the-triage-record) · [4. Review-corrections flow](#4-the-review-corrections-flow) · [5. `/apply-fixes` flow](#5-the-apply-fixes-flow) · [6. Ownership of leftover corrections](#6-ownership-of-leftover-corrections) · [7. A worked example](#7-a-worked-example)
+
+## The lifecycle at a glance
+
+Two entry points feed one fix pipeline:
+
+- **A reported bug** enters through [`/triage`](https://github.com/bdfinst/agentic-dev-team/blob/main/plugins/dev-team/skills/triage/SKILL.md),
+  which investigates hands-off and writes a **triage record** to
+  `.dev-team-reports/triage/<slug>.md` with a TDD fix plan. It deliberately does **not** fix
+  the bug — the record hands off to `/plan`/`/build` or a direct fix.
+- **A review finding** enters through
+  [`/code-review`](https://github.com/bdfinst/agentic-dev-team/blob/main/plugins/dev-team/skills/code-review/SKILL.md), whose fix loop
+  auto-applies actionable issues and emits everything else as **correction
+  prompts** — self-contained JSON files in `corrections/` — which
+  [`/apply-fixes`](https://github.com/bdfinst/agentic-dev-team/blob/main/plugins/dev-team/skills/apply-fixes/SKILL.md) later consumes.
+
+```mermaid
+%%{init: {'theme': 'base', 'themeVariables': {'primaryColor': '#dbeafe', 'primaryTextColor': '#1e3a5f', 'primaryBorderColor': '#3b82f6', 'lineColor': '#64748b', 'secondaryColor': '#f1f5f9', 'tertiaryColor': '#e0f2fe', 'background': '#ffffff', 'mainBkg': '#dbeafe', 'nodeBorder': '#2563eb', 'clusterBkg': '#eff6ff', 'clusterBorder': '#bfdbfe', 'titleColor': '#1e3a5f', 'edgeLabelBackground': '#f8fafc'}}}%%
+flowchart TD
+    A[Bug report / error message] --> B[/triage/]
+    B --> C[.dev-team-reports/triage/&lt;slug&gt;.md<br/>triage record + TDD fix plan]
+    C --> D[/plan → /build, or direct fix/]
+    E[Code change] --> F[/code-review/]
+    F -->|actionable issues| G[Review-fix loop<br/>auto-applies]
+    F -->|suggestions, confidence: none,<br/>auto-fix failures| H[corrections/*.json<br/>correction prompts]
+    H --> I[/apply-fixes corrections/]
+    I --> J[Validated minimal fixes<br/>+ Fix Summary]
+    D --> K[Commit]
+    G --> K
+    J --> K
+    H -.->|branch merges<br/>unactioned| L[Orphaned file on main<br/>— the failure this policy prevents]
+```
+
+## 1. Intake — when to reach for `/triage`
+
+Use `/triage` when a defect arrives as a *report*: a bug description, an
+error message, a failing behavior someone wants investigated — anything
+phrased like "triage this", "investigate and write it up", or where you want
+a hands-off investigation that produces an actionable record instead of an
+immediate code change.
+
+Go straight to a fix (skip `/triage`) when the root cause is already known
+and the fix is small enough to implement immediately — a triage record adds
+no value if you would write it and then act on it in the same breath.
+
+**The one-question capture rule.** `/triage` takes the bug description from
+its arguments or the conversation. If no description is available, it asks
+EXACTLY one question — `What's the problem you're seeing?` — and stops. If a
+description *is* given, it asks nothing and starts investigating immediately.
+In practice: give the symptom, the error text, or the reproduction in the
+invocation and the entire investigation runs without further interaction.
+
+## 2. Investigation — root cause before recording
+
+`/triage` runs as a worker under three constraints:
+
+1. **Investigate and record; do not fix the bug.** The worker's boundary is
+   the record. Fixing happens later, under `/plan`/`/build` or a direct fix,
+   where tests and review gates apply.
+2. **Find root cause before recording; do not record on symptoms alone.**
+   The record exists to make the fix mechanical — a symptom description
+   without a cause is not a triage record.
+3. **Be concise.** Chat output is two lines (see
+   [the triage record](#3-the-triage-record) below), never the full record
+   body.
+
+The investigation applies the systematic debugging protocol from
+[`skills/systematic-debugging/SKILL.md`](https://github.com/bdfinst/agentic-dev-team/blob/main/plugins/dev-team/skills/systematic-debugging/SKILL.md):
+
+1. **Reproduce** — run the failing test or trigger the error.
+2. **Investigate** — trace data flow, check recent changes, find working
+   reference code.
+3. **Root cause** — form and test a hypothesis.
+
+Deep codebase exploration is delegated to an `Explore` sub-agent: related
+source files and dependencies, existing tests (covered vs missing), recent
+changes to affected files (`git log`), error handling in the code path, and
+similar patterns elsewhere that work correctly.
+
+## 3. The triage record
+
+The record is written to `.dev-team-reports/triage/<slug>.md` — YAML frontmatter (`id`,
+`created`, `status: open`) followed by four sections:
+
+| Section | Contents |
+| --------- | ---------- |
+| **Problem** | Actual behavior, expected behavior, reproduction steps |
+| **Root Cause Analysis** | The code path involved, why it fails, contributing factors — described as *modules and behaviors, not file paths*, so the record survives refactors |
+| **TDD Fix Plan** | Ordered RED-GREEN cycles (at least one), each a vertical slice: a specific test capturing the broken/missing behavior, then the minimal change to pass it, plus any post-green REFACTOR cleanup |
+| **Acceptance Criteria** | Root cause addressed (not just symptom), new tests pass, existing tests pass, no regressions |
+
+If no root cause was determined, the TDD Fix Plan body is exactly
+`Root cause not determined — manual investigation required` — the record
+still captures the investigation, but flags itself as incomplete.
+
+**Slug and collisions.** The slug is derived from the bug title by a
+deterministic normalization (lowercase, ASCII-only, hyphens, ≤ 60 chars, no
+split words; empty result falls back to `triage-YYYYMMDD`). If
+`.dev-team-reports/triage/<slug>.md` already exists, `-2`, `-3`, … up to `-99` is appended —
+an existing record is **never overwritten**. If `.dev-team-reports/triage/` cannot be written
+at all, the same content goes to a temp file and to chat so nothing is lost.
+
+**Why issue-tracker independent?** The record is a plain file in the repo,
+so it works with no tracker configured, travels with branches and worktrees,
+and can be pasted into any tracker later. Nothing in the workflow depends on
+GitHub, Jira, or anything else being reachable.
+
+**Handoff.** Chat output is exactly two lines: the record path
+(`triage-record: .dev-team-reports/triage/<slug>.md`) and a root-cause summary of at most 120
+characters. From there:
+
+- **Substantial fix** → feed the record to
+  [`/plan`](https://github.com/bdfinst/agentic-dev-team/blob/main/plugins/dev-team/skills/plan/SKILL.md); each RED-GREEN cycle maps to a plan
+  step, and [`/build`](https://github.com/bdfinst/agentic-dev-team/blob/main/plugins/dev-team/skills/build/SKILL.md) executes it under TDD.
+- **Small fix** → implement the cycles directly, in order — the plan is
+  already TDD-shaped.
+
+## 4. The review-corrections flow
+
+[`/code-review`](https://github.com/bdfinst/agentic-dev-team/blob/main/plugins/dev-team/skills/code-review/SKILL.md) classifies every finding by
+severity and confidence. The rubric decides what the **fix loop**
+auto-applies and what is report-only:
+
+| Severity | Confidence | Actionable? |
+| ---------- | ------------ | ------------- |
+| error or warning | high or medium | **Yes** — auto-applied by the fix loop |
+| error or warning | none | No — report only (human judgment) |
+| suggestion | any | No — report only, never auto-applied |
+
+After the report, `/code-review` writes one **correction prompt** per
+remaining issue — suggestion-severity findings, issues whose auto-fix failed,
+and anything else the loop did not resolve — as JSON files in `corrections/`.
+Each prompt carries `priority`, `confidence`, `category` (the reviewing agent),
+`instruction`, `context`, and `affectedFiles`; the full field schema is in
+[`skills/code-review/output-format.md`](https://github.com/bdfinst/agentic-dev-team/blob/main/plugins/dev-team/skills/code-review/output-format.md#correction-prompt-json).
+
+Severity maps to priority: error→high, warning→medium, suggestion→low.
+Correction prompts are only generated for `confidence: high` or
+`confidence: medium` findings — `confidence: none` findings appear in the
+review report only and must be resolved by a human.
+
+Each prompt is self-contained: it names the reviewing agent, the fix
+instruction, and the affected files, so it can be actioned in a later
+session with no memory of the review that produced it.
+
+## 5. The `/apply-fixes` flow
+
+[`/apply-fixes`](https://github.com/bdfinst/agentic-dev-team/blob/main/plugins/dev-team/skills/apply-fixes/SKILL.md) consumes a corrections
+directory and applies each prompt as a minimal, individually-validated fix:
+
+```bash
+/apply-fixes corrections/                # apply everything
+/apply-fixes corrections/ --dry          # preview without changing anything
+/apply-fixes corrections/ --skip-tests   # skip per-fix test runs
+/apply-fixes corrections/ --repo <path>  # target a different repository
+```
+
+Also available: `--skip-build`, `--skip-lint`, `--verbose`.
+
+It first loads the target repository's rules (`CLAUDE.md`, `.clinerules`,
+`.claude/rules/index.md`, `CONTRIBUTING.md`), then processes prompts sorted
+by priority (high first), then confidence (high before medium):
+
+- **`confidence: high`** — auto-applied.
+- **`confidence: medium`** — the suggested diff is shown and the user
+  confirms (`y/n/skip`); declined prompts are recorded as "skipped by user".
+  Running non-interactively (e.g. CI), medium is treated as high.
+
+Three constraints govern every fix:
+
+1. **Minimal fix** — apply exactly what the instruction says; no
+   refactoring or improvement beyond it.
+2. **Validate after each fix** — lint, build, and tests run after every
+   individual fix (unless skipped); a validation failure is reported and the
+   run moves on — no cascading fix attempts.
+3. **One concern per fix** — prompts are never combined or reordered.
+
+Results are reported as a Fix Summary table (Applied / Skipped / Failed /
+Validation Failed, per category), and successfully applied prompt files are
+moved to a `completed/` subdirectory so a re-run does not re-apply them.
+
+## 6. Ownership of leftover corrections
+
+`corrections/` is a **branch-scoped working artifact**. The policy:
+
+> **A `corrections/*.json` file must not outlive its branch unactioned.**
+> Before the branch merges, its author disposes of every correction prompt
+> in one of three ways — and the merged branch carries the disposition, not
+> the file.
+
+1. **Apply** — run `/apply-fixes corrections/`, review the diff, commit the
+   fixes. Delete the directory (including `completed/`) before merge; the
+   fix commits are the record.
+2. **Defer** — file a tracking issue that carries or links the findings,
+   then delete the file in the same change. The issue is now the record and
+   has an assignee.
+3. **Decline** — delete the file, recording why in the commit message
+   (e.g. `chore: decline stale corrections — superseded by refactor #NNN`).
+
+**If a `corrections/*.json` is found on `main` anyway**: the owner is the
+author of the commit that introduced it — find them with
+`git log --diff-filter=A -- corrections/<file>`. The owner's next action is
+one of the three dispositions above; when the findings cannot be evaluated
+quickly, default to **Defer** (file the issue, delete the file). Leaving the
+file in place "for later" is not a disposition — it is the failure mode this
+policy exists to prevent.
+
+That failure mode is real: the Issue-537 branch review left
+`corrections/issue-537-gherkin-persistence-suggestions.json` (14 findings,
+including two with correctness teeth) sitting on `main` for months — no
+tracking issue, nothing pointing at it — until it was noticed by accident
+and removed.
+
+## 7. A worked example
+
+One suggestion-severity finding, traced end to end. The subject is a real
+finding from the Issue-537 branch review (shown here in the canonical
+one-file-per-issue prompt shape).
+
+**Discovery.** During `/code-review` on the branch, `performance-review`
+reports that a directory-exclusion list misses Maven's `target/` — copied
+`.feature` resources in Maven builds would skew a detection signal. Severity
+`suggestion`, confidence `high`.
+
+**Classification.** Per the rubric, suggestion severity is report-only — the
+fix loop does not touch it. The finding appears in the review report tagged
+`[suggestion]`.
+
+**Correction prompt.** Step 8 of `/code-review` writes it to `corrections/`:
+
+```json
+{
+  "priority": "low",
+  "confidence": "high",
+  "category": "performance-review",
+  "instruction": "Extend VENDORED_DIR_NAMES with target, __pycache__, .tox, .next, out, coverage — target/ also matters for correctness. Add a fixture test per new exclusion.",
+  "context": "VENDORED_DIR_NAMES in plugins/dev-team/scripts/detect_bdd_convention.py",
+  "affectedFiles": ["plugins/dev-team/scripts/detect_bdd_convention.py"]
+}
+```
+
+**Applying.** The branch author runs:
+
+```bash
+/apply-fixes corrections/ --dry    # preview: 1 prompt, high confidence, auto-apply
+/apply-fixes corrections/
+```
+
+`/apply-fixes` reads the repository rules, applies the minimal edit (extend
+the exclusion list, add the fixture tests — nothing more), then runs lint,
+build, and tests.
+
+**Validation and commit.** Tests pass; the Fix Summary reports
+`Total: 1 | Applied: 1`, and the prompt file moves to
+`corrections/completed/`. The author reviews `git diff`, commits the fix
+conventionally, and deletes `corrections/` before merging — disposition
+**Apply**, leaving nothing to orphan.
+
+## Related documents
+
+- [Code Review Process](code-review-process.md) — the full `/code-review`
+  pipeline that produces correction prompts
+- [Top-level Workflows](workflows.md) — the multi-phase orchestrators
+  (`/ship`, `/test-improve`) that embed `/code-review` and `/apply-fixes`
+- [Skills reference](skills.md) — catalog of all slash commands
+- [`skills/triage/SKILL.md`](https://github.com/bdfinst/agentic-dev-team/blob/main/plugins/dev-team/skills/triage/SKILL.md),
+  [`skills/apply-fixes/SKILL.md`](https://github.com/bdfinst/agentic-dev-team/blob/main/plugins/dev-team/skills/apply-fixes/SKILL.md),
+  [`skills/code-review/output-format.md`](https://github.com/bdfinst/agentic-dev-team/blob/main/plugins/dev-team/skills/code-review/output-format.md)
+  — the authoritative specs