@danmoisan/drm-copilot-mcp 1.1.26 → 1.1.27

package/resources/claude-customizations/.claude/skills/invoke-csharp-engineer/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: invoke-csharp-engineer
-description: Invoke the csharp-typed-engineer worker to design, implement, and verify C# changes within typed repository boundaries. Applies CSharpier -> .NET Analyzers -> Nullable Analysis -> xUnit toolchain, the 1-3 production-file small-path budget, and zero-regression quality gates.
+description: Invoke the csharp-typed-engineer worker to design, implement, and verify C# changes within typed repository boundaries. Applies CSharpier -> .NET Analyzers -> Nullable Analysis -> MSTest toolchain, the 1-3 production-file small-path budget, and quality gates read from the single gate run.
 ---
 
 # Implement C# Skill
@@ -13,7 +13,7 @@ Use this skill when:
 
 - The user requests a C# code change, bug fix, refactor, or test addition.
 - Estimated scope fits the small path (1-3 production files plus corresponding tests).
-- The toolchain (CSharpier, .NET Analyzers, Nullable Analysis, xUnit) can be run in the current environment, or the user has explicitly authorized an unverified plan-only response.
+- The toolchain (CSharpier, .NET Analyzers, Nullable Analysis, MSTest) can be run in the current environment, or the user has explicitly authorized an unverified plan-only response.
 
 If the estimated scope exceeds the small-path budget, this skill defers to the orchestrated flow via `csharp-change-budget-router` instead of proceeding directly.
 
@@ -28,7 +28,7 @@ If the estimated scope exceeds the small-path budget, this skill defers to the o
 ## Output Paths
 
 - C# source and test files within the approved scope.
-- Baseline evidence under `<FEATURE>/evidence/baseline/<timestamp>/` and post-change evidence under `<FEATURE>/evidence/qa-gates/<timestamp>/` per `evidence-and-timestamp-conventions`.
+- Static baseline evidence under `<FEATURE>/evidence/baseline/<timestamp>/` and final gate evidence under `<FEATURE>/evidence/qa-gates/<timestamp>/` per `evidence-and-timestamp-conventions`.
 - This location is canonical per evidence-and-timestamp-conventions and is not overridable. See `.claude/skills/evidence-and-timestamp-conventions/SKILL.md` for the canonical evidence path authority.
 - Plan artifacts under the active feature folder when the task is feature-scoped.
 
@@ -37,10 +37,10 @@ If the estimated scope exceeds the small-path budget, this skill defers to the o
 The worker must return the following reporting block:
 
 1. Scope (exact file list).
-2. Baseline (CSharpier, .NET Analyzers, Nullable Analysis, xUnit, coverage status).
+2. Baseline (CSharpier, .NET Analyzers, and Nullable Analysis findings).
 3. Plan (design and test strategy).
 4. Diffs (patch-style or full-file replacements).
-5. QA Gate Results (CSharpier, .NET Analyzers, Nullable Analysis, xUnit, and coverage deltas, or clearly marked **unverified**).
+5. QA Gate Results (CSharpier, .NET Analyzers, and Nullable Analysis deltas, failures in the single gate run, and per-file coverage against the thresholds, or clearly marked **unverified**).
 
 ## Delegation Identity Lines
 

package/resources/claude-customizations/.claude/skills/invoke-powershell-engineer/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: invoke-powershell-engineer
-description: Invoke the powershell-typed-engineer worker to design, implement, and verify PowerShell changes within typed repository boundaries. Applies PoshQC format -> analyze -> test toolchain, the 1-3 production-file direct-mode budget with routing to the orchestrated large path above it, and zero-regression quality gates.
+description: Invoke the powershell-typed-engineer worker to design, implement, and verify PowerShell changes within typed repository boundaries. Applies PoshQC format -> analyze -> test toolchain, the 1-3 production-file direct-mode budget with routing to the orchestrated large path above it, and quality gates read from the single gate run.
 ---
 
 # Implement PowerShell Skill
@@ -27,7 +27,7 @@ If the estimated scope exceeds the direct-mode budget, this skill defers to the
 ## Output Paths
 
 - PowerShell source (`*.ps1`, `*.psm1`, `*.psd1`) and Pester test (`*.Tests.ps1`) files within the approved scope.
-- Baseline evidence under `<FEATURE>/evidence/baseline/<timestamp>/` and post-change evidence under `<FEATURE>/evidence/qa-gates/<timestamp>/` per `evidence-and-timestamp-conventions`.
+- Static baseline evidence under `<FEATURE>/evidence/baseline/<timestamp>/` and final gate evidence under `<FEATURE>/evidence/qa-gates/<timestamp>/` per `evidence-and-timestamp-conventions`.
 - This location is canonical per evidence-and-timestamp-conventions and is not overridable. See `.claude/skills/evidence-and-timestamp-conventions/SKILL.md` for the canonical evidence path authority.
 - Plan artifacts under the active feature folder when the task is feature-scoped.
 
@@ -36,10 +36,10 @@ If the estimated scope exceeds the direct-mode budget, this skill defers to the
 The worker must return the `powershell-qa-gate` reporting block:
 
 1. Scope (exact file list).
-2. Baseline (PSScriptAnalyzer, Pester, coverage status).
+2. Baseline (PSScriptAnalyzer findings).
 3. Plan (design and test strategy, including minimal DI seams and external executable wrapper mock strategy).
 4. Diffs (patch-style or full-file replacements).
-5. QA Gate Results (PSScriptAnalyzer, Pester, and coverage deltas, or clearly marked **unverified**).
+5. QA Gate Results (PSScriptAnalyzer delta, failures in the single gate run, and per-file coverage against the thresholds, or clearly marked **unverified**).
 
 ## Delegation Identity Lines
 

package/resources/claude-customizations/.claude/skills/invoke-python-engineer/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: invoke-python-engineer
-description: Invoke the python-typed-engineer worker to design, implement, and verify Python changes within typed repository boundaries. Applies Black -> Ruff -> Pyright -> Pytest toolchain, the 1-3 production-file direct-mode budget with routing to the orchestrated large path above it, and zero-regression quality gates.
+description: Invoke the python-typed-engineer worker to design, implement, and verify Python changes within typed repository boundaries. Applies Black -> Ruff -> Pyright -> Pytest toolchain, the 1-3 production-file direct-mode budget with routing to the orchestrated large path above it, and quality gates read from the single gate run.
 ---
 
 # Implement Python Skill
@@ -27,7 +27,7 @@ If the estimated scope is more than 3 production files, this skill defers to the
 ## Output Paths
 
 - Python source and test files within the approved scope.
-- Baseline evidence under `<FEATURE>/evidence/baseline/<timestamp>/` and post-change evidence under `<FEATURE>/evidence/qa-gates/<timestamp>/` per `evidence-and-timestamp-conventions`.
+- Static baseline evidence under `<FEATURE>/evidence/baseline/<timestamp>/` and final gate evidence under `<FEATURE>/evidence/qa-gates/<timestamp>/` per `evidence-and-timestamp-conventions`.
 - This location is canonical per evidence-and-timestamp-conventions and is not overridable. See `.claude/skills/evidence-and-timestamp-conventions/SKILL.md` for the canonical evidence path authority.
 - Plan artifacts under the active feature folder when the task is feature-scoped.
 
@@ -36,10 +36,10 @@ If the estimated scope is more than 3 production files, this skill defers to the
 The worker must return the `python-qa-gate` reporting block:
 
 1. Scope (exact file list).
-2. Baseline (Ruff, Pyright, Pytest, coverage status).
+2. Baseline (Ruff and Pyright findings).
 3. Plan (design and test strategy).
 4. Diffs (patch-style or full-file replacements).
-5. QA Gate Results (Ruff, Pyright, Pytest, and coverage deltas, or clearly marked **unverified**).
+5. QA Gate Results (Ruff and Pyright deltas, failures in the single gate run, and per-file coverage against the thresholds, or clearly marked **unverified**).
 
 ## Delegation Identity Lines
 

package/resources/claude-customizations/.claude/skills/orchestrate/SKILL.md

@@ -37,6 +37,12 @@ On every invocation, the main session must:
 3. If no checkpoint exists or the objective is new, begin the orchestration lifecycle from the start.
 4. **Checkpoint hygiene (issue #673).** When the checkpoint at `artifacts/orchestration/orchestrator-state.json` records an `issue-num` other than the item this invocation is about, move it to `artifacts/orchestration/handoff/orchestrator-state.issue-<issue-num>.<yyyy-MM-ddTHH-mm>.json` before writing a new checkpoint, rather than overwriting it or leaving it in place. Apply the same move when this session hands an item whose checkpoint it holds to another session or worktree. A checkpoint left at a session root is read by gates that resolve against that root, so a foreign one there is state a gate can answer from.
 5. **Required checkpoint keys (issue #798).** Every checkpoint write carries each top-level key listed in `.claude/rules/orchestrator-state.md` under `## Required Top-Level Keys`; plain validation reports each absent key as `Checkpoint missing required key: <key>` under every flag combination. The list includes `last_updated`, an ISO-8601 UTC date-time string (for example `2026-10-08T17:28:00Z`) that is rewritten on every checkpoint write: after every completed step and every state transition, including halts.
+6. **Stage timing (issue #1097).**
+   - At each transition where the checkpoint `last_updated` is rewritten, read the clock once (never compose a time) and use that reading as `last_updated`, as `ended_at` of the open `stage_timing` entry, and as `started_at` of the entry for the next stage; `attempt` is one more than the number of earlier entries for the same stage.
+   - `stage_timing` is a top-level list of `{ stage, attempt, started_at, ended_at }` entries with ISO-8601 UTC strings, and `ended_at` is null while a stage is open. The key is tolerated and unvalidated: no validator reads it.
+   - In the last commit before the merge, write the whole list to `FEATURE/evidence/other/stage-timing.<timestamp>.json` as a JSON object with `issue-num` (a string of decimal digits, or an integer of 1 or more; both are read as the same issue) and `stage_timing`, stamped with the UTC write time (`yyyy-MM-ddTHH-mm`); the file sits inside the feature folder, so the commit does not stale a concurrent review, and a re-written file carries a newer stamp, which the report prefers.
+   - A portable handoff archives the source checkpoint byte for byte, so the archive keeps `stage_timing`, but the destination projection copies no unknown key and starts without it; the committed evidence file is the record that spans a handoff.
+   - Print the report with `scripts/dev-tools/Get-StageTimingReport.ps1`. Figures are wall-clock time and include queueing; they are not agent time. The merge stage is not captured.
 
 ## Prepared-State Portable Handoff Intake
 
@@ -253,7 +259,7 @@ After each `feature-review` delegation returns:
 3. If the file exists, count lines matching `BLOCKING` or `Severity: Blocking` (case-sensitive). If count >= 1, enter the remediation loop. If count = 0, advance to the PR creation gate. This count rule applies unchanged when the file carries no `Review-Verdict:` line: a count of at least 1 is `REMEDIATION_REQUIRED` and every finding is treated as `autonomous`.
 4. If the file carries a `Review-Verdict:` line, recompute the verdict from the `Remediability:` lines of the blocking findings (a blocking finding block without a `Remediability:` line counts as `autonomous`): no blocking finding is `PASS`; any `autonomous` finding is `REMEDIATION_REQUIRED`; otherwise any `external_dependency`, `policy_hold`, or `human_decision_required` finding is `HALT_NON_REMEDIABLE`; otherwise `AWAITING_CI`. The `remediation-inputs` file is authoritative; the optional `review-status:` token in the review result is a cross-check.
 5. A mismatch between the declared and recomputed verdicts is a reviewer contract error: record it under `artifact_errors`, re-request the review once, and halt with `blocked_reason: "delegate_contract_incomplete"` if it persists.
-6. Append a `remediation_loop.review_outcomes[]` entry (`verdict` plus one `findings[]` object with `remediability` per blocking finding) for every review, including `PASS`.
+6. Append a `remediation_loop.review_outcomes[]` entry (`verdict` plus one `findings[]` object with `remediability` per blocking finding) for every review, including `PASS`. Each `findings[]` object also records `scope` from the finding's `Finding-Scope:` line when that line is present.
 7. Act on the verdict: `PASS` advances to the PR creation gate; `REMEDIATION_REQUIRED` enters the remediation loop with the plan scoped to the `autonomous` findings, carrying the non-remediable findings forward unchanged; `HALT_NON_REMEDIABLE` follows the halt branch; `AWAITING_CI` follows the wait branch.
 
 Halt branch (`HALT_NON_REMEDIABLE`): set `blocked_reason` to the highest-precedence halt class present, append one `human_interaction.requirements[]` entry with `response: "halt"` for each halt class present (`external_dependency`, `policy_hold`, `human_decision_required`) describing the human action needed, leave `remediation_loop.completed_attempts` unchanged, write no cycle, create no remediation plan, and stop. The precedence is:
@@ -268,10 +274,11 @@ A bounded loop consisting of five steps. The attempt count is `remediation_loop.
 
 Cycle accounting: a remediation attempt is complete when R3 execution finished (`execution_status: "complete"`) and the pre-R4 commit recorded a non-empty change set; only then set `candidate_applied: true` on that cycle and increment `completed_attempts`. A cycle that ends without a candidate (execution not started, execution failed, or an empty staged change set) records `candidate_applied: false` and consumes no number. It is followed by at most one re-plan under the same number when the executor output identifies an autonomous plan defect; otherwise reclassify the blocker (typically `external_dependency`) and halt. Two consecutive no-candidate cycles halt with `step6_status: "blocked_remediation_loop_limit"`. Local, CI-failure, merge-conflict, and parallel-drift cycles share the one count.
 
-Remediation mode. Before R1, the orchestrator writes exactly one line into the cycle's `remediation-inputs.<timestamp>.md`: `Remediation-Mode: proportionate` or `Remediation-Mode: design`. The classification rule: a cycle is proportionate when every `autonomous` finding can be fixed without changing a spec acceptance criterion, a public interface, or the item's file inventory beyond the files already in the branch diff plus their tests and mirrors; otherwise the cycle is design. CI-failure findings are normally proportionate.
+Remediation mode. Before R1, or before R3 for a light cycle, the orchestrator writes exactly one line into the cycle's `remediation-inputs.<timestamp>.md`: `Remediation-Mode: light`, `Remediation-Mode: proportionate`, or `Remediation-Mode: design`. The classification rule: a cycle is proportionate when every `autonomous` finding can be fixed without changing a spec acceptance criterion, a public interface, or the item's file inventory beyond the files already in the branch diff plus their tests and mirrors; otherwise the cycle is design. CI-failure findings are normally proportionate. `Remediation-Mode:` stays orchestrator-owned. The orchestrator writes `Remediation-Mode: light` only when the reviewer wrote `Remediation-Path: light` and every mechanically checkable condition holds: the finding count and classes, a `Finding-Scope: contained` line for each finding, a non-empty `## Light Fix Tasks` section and no other checkbox line, `opened_by_review` set, a prior cycle that was not light, and the detection rule below. Otherwise it writes `Remediation-Mode: proportionate` or `Remediation-Mode: design` by the rule above. It may move a cycle to a heavier mode and never to a lighter one, and CI-failure and merge-conflict cycles are never light. Each new cycle records `remediation_path` as `light` or `full`.
 
 - **Proportionate cycle.** R1 is one `atomic-planner` delegation that writes a short remediation plan carrying a `## Pre-Mortem` section and a final self-review task. R2 and R3 run as one `atomic-executor` delegation: the executor runs single-pass preflight with in-place trivial fixes (`### Single-Pass Preflight` in `atomic-plan-contract`) and then executes the plan. Record `preflight: {iterations: 1, final_status: "clear"}` on the cycle before `execution_status`. If preflight finds a substantive defect, the executor stops with `BLOCKED at preflight (before [P0-T1])`, a plan delta, and no checked task; the orchestrator rewrites the mode line to `Remediation-Mode: design` and the cycle continues as a design cycle with one planner revision. The pre-R4 commit, R4, and R5 are unchanged.
 - **Design cycle.** R1 to R5 run as listed below, and R2 follows the single-pass preflight and at-most-one-return rule.
+- **Light cycle.** The threshold is the reviewer's: at most 3 blocking findings, every one `autonomous` with `Finding-Scope: contained`; no change to a spec acceptance criterion, a public interface, or the file inventory beyond the branch diff plus tests and mirrors; no change to a validator contract, hook decision, or production logic beyond the finding's named location; a review-opened cycle; and a prior cycle that was not light. Detection: as the last step before the execution delegation, record the cycle truthfully (`plan_path` naming the inputs file, `remediation_path: "light"`, `opened_by_review`, `execution_status: "in_progress"`, and no `preflight`) and validate the checkpoint through the repository-local Python CLI `scripts.dev_tools.validate_orchestration_artifacts` with its `orchestrator-state` subcommand, run through Poetry in module form in the item worktree, or through the MCP tool where the repository has no such CLI. Installed MCP applies invariant 8 only after the extension release that carries it is installed; until then the checkpoint is validated through the Python CLI, and a failed MCP checkpoint call records no receipt and is not repaired by editing the cycle. On that validation, an error naming that cycle means the route lacks invariant 8, so remove `execution_status`, set `remediation_path: "full"`, rewrite the mode line to `Remediation-Mode: proportionate` or `Remediation-Mode: design`, and continue at R1, after which `plan_path` names the remediation plan. No fix work has run at that point, so the record stays true. R1 and R2 do not run. R3 is one `atomic-executor` delegation with the inputs file as its plan and no preflight directive. If the executor stops with `BLOCKED at preflight (before [P0-T1])` before the first checked task, rewrite the mode line to `Remediation-Mode: design`, set `remediation_path: "full"`, remove `execution_status`, and enter the design chain at R1; `plan_path` then names the remediation plan, and no attempt number is consumed. The pre-R4 commit, R4, R5, cycle accounting (`candidate_applied` and `completed_attempts`), and the termination guard are unchanged. The cycle after a light cycle is full.
 
 - **R1 — Remediation planning:** Delegate to `atomic-planner` with `remediation-inputs.<timestamp>.md` path as primary context. Receive `remediation-plan.<timestamp>.md` in the active feature folder.
 - **R2 — Preflight clearance:** Delegate to `atomic-executor` for precondition validation only (no implementation), with the preflight directive in the delegation prompt. Trivial defects are fixed in place. If the executor returns `PREFLIGHT: REVISIONS REQUIRED`, return to R1 once and re-delegate to `atomic-planner` with the full `PREFLIGHT-DEFECT:` list; if the following preflight still reports a substantive defect, record `final_status: "blocked_preflight_iteration_limit"` on the cycle and halt per `.claude/skills/remediation-handoff-atomic-planner/SKILL.md`. Only after `PREFLIGHT: ALL CLEAR` may the orchestrator advance to R3.
@@ -373,6 +380,21 @@ When S9 records `step9_status: "failed_remediation_required"` (a failed check; a
 4. CI-failure cycles share `remediation_loop.completed_attempts` with local-finding cycles; a CI-failure finding stays `autonomous`, and the active cycle number is `completed_attempts + 1`.
 5. The shared guard applies: after three completed attempts without a passing result, the orchestrator records `step9_status: "blocked_ci_loop_limit"`, does not write DONE, and halts. No further automation is attempted.
 
+## Concurrent Review and CI (review_mode)
+
+This section applies to a run whose checkpoint records `review_mode: "concurrent"` (issue #1097). The feature review and CI then run at the same time on an open pull request, and the merge waits for both. A run without that value is sequential and follows every other section of this skill unchanged.
+
+1. **New-run default.** The first checkpoint write of a new run records `review_mode: "concurrent"` when the route opens a pull request and the target worktree holds the guard file `.claude/hooks/enforce-epic-merge-gate-review.ps1`. Without that file the run stays sequential, because a skill newer than its hooks would otherwise stop at readiness.
+2. **Resume.** A run that resumes a checkpoint without the key stays sequential, and the key is never added on resume. A sequential run follows every other section unchanged.
+3. **Sequence.** The local parallel test run passes; commit, with the steps of `## Pre-Feature-Review Commit` running here, before the pull request; open the pull request; a run with a ledger entry commits the entry's pull-request number next, before reading `head_sha`; run the `feature-review` delegation and CI together; join; merge.
+4. **Recording.** Every `remediation_loop.review_outcomes[]` entry carries `head_sha`: the full lowercase head of the pushed branch, read before the review delegation.
+5. **Join.** The merge proceeds only when all of these hold: the last `review_outcomes[]` entry has verdict `PASS` at a current head; `ci_gate.conclusion` is `success` at the live head; and a `CI full run` check with conclusion `success` exists at the reviewed head, or at an ancestor of it whose diff to the reviewed head lists only `feature-folder` paths. A reviewed head is current when it equals the live head, or when it is an ancestor of the live head and the diff between them lists only `feature-folder` paths; this is the rule of the merge guard. The `CI full run` check is required because a docs-only head reports success without the heavy suites.
+6. **Moved conditions.** Conditions 1 and 2 of `## PR Creation Gate` apply at the join, not before the pull request. S9 steps 6 and 7, and DONE, run only after the join. A parallel child still never merges itself.
+7. **Re-entry.** Any code push after a `PASS`, including a CI fix or a merge of `origin/main`, is a stale head and requires a new review and a new S9 pass. Commits inside `feature-folder`, such as review artifacts and stage-timing evidence, do not. Ledger back-fills lie outside `feature-folder`, so they land before the review starts.
+8. **Portable handoff.** The destination projection is a closed key set and drops `review_mode`, so a concurrent run is not handed off between pull-request creation and the join.
+9. **Validators and deny codes.** Readiness stops rejecting `step7_status: pending` only under the key, and `require_complete` then requires the last `PASS` entry with `head_sha`. The TypeScript rule reaches the MCP validator only after an extension release. Until then installed MCP accepts a checkpoint that the PowerShell stop hook and the Python CLI reject, so check a concurrent checkpoint with the repository-local Python validator CLI, in its `orchestrator-state` mode with `--require-complete`. The merge guard denies with `REVIEW_GATE_NOT_PASSED`, `REVIEW_GATE_HEAD_STALE`, or `REVIEW_GATE_HEAD_UNRESOLVED`, each after the token `EPIC_MERGE_GATE_BLOCKED`. The merge is issued as its own Bash call, and any other form is denied with `REVIEW_GATE_HEAD_UNRESOLVED`.
+10. **Step order.** `completed_steps` stays in canonical order, because `.claude/hooks/enforce-checkpoint-monotonic.ps1` denies a checkpoint Write that lists `S8_create_pr` before `S7_feature_review`. When the review completes, insert `S7_feature_review` before the existing `S8_create_pr` entry; do not append it. A later review adds no second entry. `step8_status` is `in_progress` at pull-request creation, because readiness rejects `pending`, and it stays `in_progress` until the join, because `.claude/hooks/enforce-completion-consistency.ps1` reads `completed` there as a completion claim and denies a checkpoint Write whose `ci_gate.conclusion` is not `success`. A `completed` value would therefore deny the `ci_gate` write of every re-entry.
+
 ## PR Creation Gate
 
 The orchestrator must not create a PR, push a branch for PR purposes, or report work complete until all six conditions are simultaneously true:

package/resources/claude-customizations/.claude/skills/parallel-orchestrate/SKILL.md

@@ -427,6 +427,14 @@ Procedure, per item:
    re-delegate the child once to resume at the CI green gate, by the same re-delegation mechanism as
    `## Per-Item Merge-Conflict Handling`; a CI-failure cycle counts toward `remediation_loop`.
    Record `ci_green` only after that resumed run reports its CI green gate `passed`.
+   **Concurrent review.** When the child checkpoint records `review_mode: "concurrent"`, do not
+   record `merge_status: ci_green` and do not run `gh pr merge` until its last
+   `review_outcomes[]` entry is `PASS` at a current head, as the join in
+   `## Concurrent Review and CI (review_mode)` of `.claude/skills/orchestrate/SKILL.md` defines it;
+   keep `merge_status: pr_open` and treat the item as not done. Issue #1097 amends
+   `.claude/skills/orchestrate/SKILL.md` for every new run and adds no parallel-specific condition
+   to the child's PR Creation Gate. The merge gate reads the child through the item target, so
+   this step is the backstop when that target does not resolve.
 3. Execute `gh pr merge --merge <PR>` for that item's pull request, whose base is `main`.
    Do not pass `--delete-branch` or `--auto`. A zero exit status does not prove a merge: when
    `main` uses a merge queue, `gh pr merge` exits 0 after it enqueues the pull request or enables

package/resources/claude-customizations/.claude/skills/powershell-qa-gate/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: powershell-qa-gate
-description: Final QA gate for PowerShell changes. Executes the full PoshQC format -> analyze -> test toolchain (with coverage where enforced), compares against a captured baseline, enforces zero-regression deltas, and produces the required reporting block before the agent declares the change complete.
+description: Final QA gate for PowerShell changes. Executes the full PoshQC format -> analyze -> test toolchain (with coverage where enforced), compares static tool results against the static baseline, reads test and coverage results from the single gate run, and produces the required reporting block before the agent declares the change complete.
 ---
 
 # PowerShell QA Gate
@@ -12,14 +12,14 @@ Canonical procedure for the Phase D final quality gate that every PowerShell cha
 Use this skill when:
 
 - `powershell-typed-engineer` is about to declare a change complete.
-- An executor has finished applying a planned batch and must verify zero regressions against the baseline captured in Phase A.
+- An executor has finished applying a planned batch and must verify the static tools against the static baseline recorded in Phase A, and the tests in the single gate run.
 - A reviewer needs to confirm the toolchain was actually run and produced a clean pass.
 
 ## Required Inputs
 
 Before invoking this gate, the agent must have:
 
-- a baseline record produced in Phase A, containing PSScriptAnalyzer findings, Pester pass/fail status, and per-file coverage status for the in-scope files,
+- a static baseline record produced in Phase A, containing PSScriptAnalyzer findings for the in-scope files,
 - the exact list of touched production and test files,
 - a clean working tree (all planned edits committed to the working copy).
 
@@ -29,39 +29,38 @@ Run the full toolchain in this exact order. If any step fails or modifies files,
 
 1. `mcp__drm-copilot__run_poshqc_format`
 2. `mcp__drm-copilot__run_poshqc_analyze`
-3. `mcp__drm-copilot__run_poshqc_test`
-4. Coverage check (when enforced by task/repo flow) — use the Pester coverage output from step 3 or the repo coverage task.
+3. One `Invoke-PoshQCParallelTest` run, through the route in the `execution-environment` brief. Read `ExitCode` first.
+4. Coverage check (when enforced by task/repo flow) — use the Pester coverage output of the run in step 3.
 
 If the environment prevents running any tool, stop and report the change as **unverified**. Do not declare completion.
 
-## Delta Requirements (Zero-Regression Hard Gate)
+## Gate Requirements (Hard Gate)
 
-Compare the final results to the Phase A baseline. All of the following must hold:
+Compare the final static tool results to the static baseline recorded in Phase A, and read test and coverage results from the single gate run. All of the following must hold:
 
 - **PSScriptAnalyzer delta**: 0 new findings across the repository.
-- **Pester delta**: 0 new failing tests.
-- **Per-file coverage delta**: coverage for every touched file is greater than or equal to the baseline for that file.
-- **Overall coverage delta** (when the repo enforces it): overall coverage is greater than or equal to the baseline.
-- **New modules, classes, or methods**: line coverage >= 85% per the uniform tier rule (`.claude/rules/quality-tiers.md`). No tier-specific lower thresholds. No regression on changed lines. Pester measures command (instruction) coverage and line coverage only; branch coverage is not measurable for PowerShell, so no branch-coverage gate applies here (see `.claude/rules/powershell.md`). Command coverage is informational and carries no threshold.
+- **Pester gate**: zero failures in the single gate run.
+- **Per-file coverage**: every changed file meets the coverage thresholds, read from the single gate run, and new behavior is tested.
+- **New modules, classes, or methods**: line coverage >= 85% per the uniform tier rule (`.claude/rules/quality-tiers.md`). No tier-specific lower thresholds. Pester measures command (instruction) coverage and line coverage only; branch coverage is not measurable for PowerShell, so no branch-coverage gate applies here (see `.claude/rules/powershell.md`). Command coverage is informational and carries no threshold.
 
-If any delta check fails, the agent must revert or fix immediately and rerun the full toolchain. Do not proceed to reporting until all deltas are clean.
+If any check fails, the agent must revert or fix immediately and rerun the full toolchain. Do not proceed to reporting until all checks are clean.
 
 ## Required Reporting Block
 
 Every completion response must include the following sections:
 
 1. **Scope** — exact file list touched in this change.
-2. **Baseline** — PSScriptAnalyzer, Pester, and coverage status recorded in Phase A.
+2. **Baseline** — PSScriptAnalyzer findings recorded in Phase A.
 3. **Plan** — design and test-strategy summary, referencing the approved plan, including proposed script/module structure, minimal DI seams, Pester scenario-level test strategy, and external executable wrapper mock strategy.
 4. **Diffs** — patch-style or full-file replacements for scoped files only.
-5. **QA Gate Results** — PSScriptAnalyzer delta, failing-tests delta, per-file coverage delta, and overall coverage delta when applicable. If any step could not be run, mark the corresponding line **unverified** and state why.
+5. **QA Gate Results** — PSScriptAnalyzer delta, failures in the single gate run, and per-file coverage against the thresholds. If any step could not be run, mark the corresponding line **unverified** and state why.
 
 ## Evidence Storage
 
 Persist toolchain output according to `evidence-and-timestamp-conventions`:
 
-- store baseline outputs under `<FEATURE>/evidence/baseline/<timestamp>/`,
-- store post-change outputs under `<FEATURE>/evidence/qa-gates/<timestamp>/`,
+- store static baseline outputs under `<FEATURE>/evidence/baseline/<timestamp>/`,
+- store final gate outputs under `<FEATURE>/evidence/qa-gates/<timestamp>/`,
 - use ISO-8601 UTC timestamps in folder names.
 
 This location is canonical per evidence-and-timestamp-conventions and is not overridable.
@@ -73,5 +72,5 @@ The evidence paths must be referenced in the agent's completion message to satis
 
 - Do not disable, skip, or narrow any step of the toolchain to reach a clean result.
 - Do not add PSScriptAnalyzer rule suppressions (`[Diagnostics.CodeAnalysis.SuppressMessageAttribute]` or `PSScriptAnalyzer` suppression comments) or Pester `-Skip` / `-Pending` to mask new findings introduced by the change.
-- Do not report success based on partial or targeted runs alone. Targeted runs are allowed mid-batch, but the final gate requires a full-repo pass.
+- Do not report success based on partial or targeted runs. A focused run of one test file to debug a specific failure is debugging only; it is never a gate or evidence, and the final gate is the single gate run.
 - Do not mock `git`, `gh`, `actionlint`, or other executables directly; mock the wrapper function (for example `Invoke-GitExe`) per `.claude/rules/powershell.md`.

package/resources/claude-customizations/.claude/skills/python-qa-gate/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: python-qa-gate
-description: Final QA gate for Python changes. Executes the full Black -> Ruff -> Pyright -> Pytest toolchain, compares against a captured baseline, enforces zero-regression deltas, and produces the required reporting block before the agent declares the change complete.
+description: Final QA gate for Python changes. Executes the full Black -> Ruff -> Pyright -> Pytest toolchain, compares static tool results against the static baseline, reads test and coverage results from the single gate run, and produces the required reporting block before the agent declares the change complete.
 ---
 
 # Python QA Gate
@@ -12,14 +12,14 @@ Canonical procedure for the Phase D final quality gate that every Python change
 Use this skill when:
 
 - `python-typed-engineer` is about to declare a change complete.
-- An executor has finished applying a planned batch and must verify zero regressions against the baseline captured in Phase A.
+- An executor has finished applying a planned batch and must verify the static tools against the static baseline recorded in Phase A, and the tests in the single gate run.
 - A reviewer needs to confirm the toolchain was actually run and produced a clean pass.
 
 ## Required Inputs
 
 Before invoking this gate, the agent must have:
 
-- a baseline record produced in Phase A, containing Ruff, Pyright, Pytest, and per-file coverage status for the in-scope files,
+- a static baseline record produced in Phase A, containing Ruff and Pyright findings for the in-scope files,
 - the exact list of touched production and test files,
 - a clean working tree (all planned edits committed to the working copy).
 
@@ -30,39 +30,38 @@ Run the full toolchain in this exact order. If any step fails or modifies files,
 1. `poetry run black .`
 2. `poetry run ruff check .`
 3. `poetry run pyright`
-4. `poetry run pytest --cov --cov-report=term-missing`
+4. `poetry run pytest -n auto --cov-branch --cov-report=term-missing --cov`
 
 If the environment prevents running any tool, stop and report the change as **unverified**. Do not declare completion.
 
-## Delta Requirements (Zero-Regression Hard Gate)
+## Gate Requirements (Hard Gate)
 
-Compare the final results to the Phase A baseline. All of the following must hold:
+Compare the final static tool results to the static baseline recorded in Phase A, and read test and coverage results from the single gate run. All of the following must hold:
 
 - **Ruff delta**: 0 new findings across the repository.
 - **Pyright delta**: 0 new diagnostics across the repository.
-- **Pytest delta**: 0 new failing tests.
-- **Per-file coverage delta**: coverage for every touched file is greater than or equal to the baseline for that file.
-- **Overall coverage delta** (when the repo enforces it): overall coverage is greater than or equal to the baseline.
-- **New modules, classes, or methods**: line coverage >= 85% and branch coverage >= 75% per the uniform tier rule (`.claude/rules/quality-tiers.md`). No tier-specific lower thresholds. No regression on changed lines.
+- **Pytest gate**: zero failures in the single gate run.
+- **Per-file coverage**: every changed file meets the coverage thresholds, read from the single gate run, and new behavior is tested.
+- **New modules, classes, or methods**: line coverage >= 85% and branch coverage >= 75% per the uniform tier rule (`.claude/rules/quality-tiers.md`). No tier-specific lower thresholds.
 
-If any delta check fails, the agent must revert or fix immediately and rerun the full toolchain. Do not proceed to reporting until all deltas are clean.
+If any check fails, the agent must revert or fix immediately and rerun the full toolchain. Do not proceed to reporting until all checks are clean.
 
 ## Required Reporting Block
 
 Every completion response must include the following sections:
 
 1. **Scope** — exact file list touched in this change.
-2. **Baseline** — Ruff, Pyright, Pytest, and coverage status recorded in Phase A.
+2. **Baseline** — Ruff and Pyright findings recorded in Phase A.
 3. **Plan** — design and test-strategy summary, referencing the approved plan.
 4. **Diffs** — patch-style or full-file replacements for scoped files only.
-5. **QA Gate Results** — Ruff, Pyright, Pytest, and coverage deltas. If any step could not be run, mark the corresponding line **unverified** and state why.
+5. **QA Gate Results** — Ruff and Pyright deltas, failures in the single gate run, and per-file coverage against the thresholds. If any step could not be run, mark the corresponding line **unverified** and state why.
 
 ## Evidence Storage
 
 Persist toolchain output according to `evidence-and-timestamp-conventions`:
 
-- store baseline outputs under `<FEATURE>/evidence/baseline/<timestamp>/`,
-- store post-change outputs under `<FEATURE>/evidence/qa-gates/<timestamp>/`,
+- store static baseline outputs under `<FEATURE>/evidence/baseline/<timestamp>/`,
+- store final gate outputs under `<FEATURE>/evidence/qa-gates/<timestamp>/`,
 - use ISO-8601 UTC timestamps in folder names.
 
 This location is canonical per evidence-and-timestamp-conventions and is not overridable.
@@ -74,4 +73,4 @@ The evidence paths must be referenced in the agent's completion message to satis
 
 - Do not disable, skip, or narrow any step of the toolchain to reach a clean result.
 - Do not add Ruff `noqa`, Pyright `# type: ignore`, or test skips to suppress new findings introduced by the change.
-- Do not report success based on partial or targeted runs alone. Targeted runs are allowed mid-batch, but the final gate requires a full-repo pass.
+- Do not report success based on partial or targeted runs. A focused run of one test file to debug a specific failure is debugging only; it is never a gate or evidence, and the final gate is the single gate run.

package/resources/claude-customizations/.claude/skills/remediation-handoff-atomic-planner/SKILL.md

@@ -98,7 +98,7 @@ A comprehensive or final sweep in a remediation cycle covers that cycle's own pl
 
 - Phase headings: `### Phase N — <Title>`.
 - Tasks: `- [ ] [P#-T#]` with sequential per-phase IDs.
-- Phase 0 captures policy reads and baseline toolchain results per `policy-compliance-order` and `evidence-and-timestamp-conventions`.
+- Phase 0 captures policy reads and static baseline results per `policy-compliance-order` and `evidence-and-timestamp-conventions`.
 - Final phase runs the full toolchain QA loop in the order specified by `atomic-plan-contract` and records numeric coverage values where the repository policy requires coverage.
 - Evidence paths resolve to `<FEATURE>/evidence/<kind>/` per the non-overridable evidence path clause.
 - The plan is design-level per `## Design-Level Plan Contract (Mandatory)` in `atomic-plan-contract`, carries a `## Pre-Mortem` section, and ends with the final-phase self-review task. A proportionate plan covers only the listed findings and stays short.

package/resources/claude-customizations/.claude-variants/csharp-legacy/agents/csharp-typed-engineer.md

@@ -1,6 +1,6 @@
 ---
 name: csharp-typed-engineer
-description: Project-scoped worker that implements and verifies C# changes within typed repository boundaries. Applies the CSharpier -> .NET Analyzers -> Nullable Analysis -> MSTest toolchain, the 1-3 production-file small-path budget, and zero-regression quality gates.
+description: Project-scoped worker that implements and verifies C# changes within typed repository boundaries. Applies the CSharpier -> .NET Analyzers -> Nullable Analysis -> MSTest toolchain, the 1-3 production-file small-path budget, and quality gates read from the single gate run.
 tools:
   - Read
   - Grep
@@ -33,10 +33,10 @@ Follow the phased workflow defined by the preloaded skills:
 
 1. **Policy compliance** — apply `policy-compliance-order` to load mandatory repo policies before any change.
 2. **Routing and scope** — apply `csharp-change-budget-router` to estimate scope, select direct vs orchestrator handoff mode, and enforce the 3 production + 3 test per-batch cap.
-3. **Plan and baseline** — apply `atomic-plan-contract` for Phase 0 baseline capture and atomic plan structure. Delegate plan authoring to `atomic_planner` when no plan is supplied. Plans must include the proposed class and module structure, minimal DI seams, MSTest scenario-level test strategy, and Moq mock strategy.
-4. **Implement in batches** — apply the approved plan. After each batch, run targeted analyzer and nullable builds on touched projects plus targeted MSTest, and confirm per-file coverage.
-5. **Final QA gate** — apply `csharp-qa-gate` to run the full toolchain, enforce zero-regression deltas against the baseline, and produce the required reporting block before declaring completion.
-6. **Evidence and handoff** — store baseline and post-change evidence per `evidence-and-timestamp-conventions`. Trigger remediation via `remediation-handoff-atomic-planner` when deltas fail.
+3. **Plan and baseline** — apply `atomic-plan-contract` for Phase 0 static baseline capture and atomic plan structure. Delegate plan authoring to `atomic_planner` when no plan is supplied. Plans must include the proposed class and module structure, minimal DI seams, MSTest scenario-level test strategy, and Moq mock strategy.
+4. **Implement in batches** — apply the approved plan. After each batch, run targeted analyzer and nullable builds on touched projects. Test and coverage results come from the single gate run. A focused run of one test file to debug a specific failure is debugging only.
+5. **Final QA gate** — apply `csharp-qa-gate` to run the full toolchain, compare static tool results against the static baseline, read test and coverage results from the single gate run, and produce the required reporting block before declaring completion.
+6. **Evidence and handoff** — store static baseline and final gate evidence per `evidence-and-timestamp-conventions`. Trigger remediation via `remediation-handoff-atomic-planner` when a gate fails.
 
 ## Mode Marker Resolution
 
@@ -55,7 +55,7 @@ Stop implementation and return to the user when:
 
 - the scope estimate or an in-flight batch would exceed the 3-production-file cap in direct mode,
 - a file is above or would exceed the 800-line hard limit of the tiered file-size policy (split it before proceeding; at 500 lines look for a logical split, and at 700 lines split more aggressively),
-- any QA gate delta is non-zero after self-correction,
+- any QA gate check fails after self-correction,
 - the toolchain cannot be executed in the current environment (mark the change **unverified**),
 - orchestrator handoff mode is requested but the required context package is incomplete,
 - policy instructions conflict.

package/resources/claude-customizations/.claude-variants/csharp-legacy/skills/csharp-qa-gate/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: csharp-qa-gate
-description: Final QA gate for C# changes. Executes the full CSharpier -> .NET Analyzers -> Nullable Analysis -> MSTest toolchain, compares against a captured baseline, enforces zero-regression deltas, and produces the required reporting block before the agent declares the change complete.
+description: Final QA gate for C# changes. Executes the full CSharpier -> .NET Analyzers -> Nullable Analysis -> MSTest toolchain, compares static tool results against the static baseline, reads test and coverage results from the single gate run, and produces the required reporting block before the agent declares the change complete.
 ---
 
 # C# QA Gate
@@ -12,14 +12,14 @@ Canonical procedure for the Phase D final quality gate that every C# change must
 Use this skill when:
 
 - `csharp-typed-engineer` is about to declare a change complete.
-- An executor has finished applying a planned batch and must verify zero regressions against the baseline captured in Phase A.
+- An executor has finished applying a planned batch and must verify the static tools against the static baseline recorded in Phase A, and the tests in the single gate run.
 - A reviewer needs to confirm the toolchain was actually run and produced a clean pass.
 
 ## Required Inputs
 
 Before invoking this gate, the agent must have:
 
-- a baseline record produced in Phase A, containing analyzer findings, compiler/nullable diagnostics, MSTest pass/fail status, and per-file coverage status for the in-scope files,
+- a static baseline record produced in Phase A, containing analyzer findings and compiler/nullable diagnostics for the in-scope files,
 - the exact list of touched production and test files,
 - a clean working tree (all planned edits committed to the working copy).
 
@@ -36,35 +36,34 @@ Run the full toolchain in this exact order. If any step fails or modifies files,
 
 If the environment prevents running any tool, stop and report the change as **unverified**. Do not declare completion.
 
-## Delta Requirements (Zero-Regression Hard Gate)
+## Gate Requirements (Hard Gate)
 
-Compare the final results to the Phase A baseline. All of the following must hold:
+Compare the final static tool results to the static baseline recorded in Phase A, and read test and coverage results from the single gate run. All of the following must hold:
 
 - **Analyzer delta**: 0 new findings across the repository.
 - **Compiler / nullable delta**: 0 new diagnostics across the repository.
-- **MSTest delta**: 0 new failing tests.
-- **Per-file coverage delta**: coverage for every touched file is greater than or equal to the baseline for that file.
-- **Overall coverage delta** (when the repo enforces it): overall coverage is greater than or equal to the baseline.
+- **MSTest gate**: zero failures in the single gate run.
+- **Per-file coverage**: every changed file meets the coverage thresholds, read from the single gate run, and new behavior is tested.
 - **New modules, classes, or methods**: coverage >= 90% for each new unit introduced in the batch.
 
-If any delta check fails, the agent must revert or fix immediately and rerun the full toolchain. Do not proceed to reporting until all deltas are clean.
+If any check fails, the agent must revert or fix immediately and rerun the full toolchain. Do not proceed to reporting until all checks are clean.
 
 ## Required Reporting Block
 
 Every completion response must include the following sections:
 
 1. **Scope** — exact file list touched in this change.
-2. **Baseline** — analyzer, compiler/nullable, MSTest, and coverage status recorded in Phase A.
+2. **Baseline** — analyzer and compiler/nullable findings recorded in Phase A.
 3. **Plan** — design and test-strategy summary, referencing the approved plan.
 4. **Diffs** — patch-style or full-file replacements for scoped files only.
-5. **QA Gate Results** — analyzer, compiler/nullable, MSTest, and coverage deltas. If any step could not be run, mark the corresponding line **unverified** and state why.
+5. **QA Gate Results** — analyzer and compiler/nullable deltas, failures in the single gate run, and per-file coverage against the thresholds. If any step could not be run, mark the corresponding line **unverified** and state why.
 
 ## Evidence Storage
 
 Persist toolchain output according to `evidence-and-timestamp-conventions`:
 
-- store baseline outputs under `<FEATURE>/evidence/baseline/<timestamp>/`,
-- store post-change outputs under `<FEATURE>/evidence/qa-gates/<timestamp>/`,
+- store static baseline outputs under `<FEATURE>/evidence/baseline/<timestamp>/`,
+- store final gate outputs under `<FEATURE>/evidence/qa-gates/<timestamp>/`,
 - use ISO-8601 UTC timestamps in folder names.
 
 This location is canonical per evidence-and-timestamp-conventions and is not overridable.
@@ -76,4 +75,4 @@ The evidence paths must be referenced in the agent's completion message to satis
 
 - Do not disable, skip, or narrow any step of the toolchain to reach a clean result.
 - Do not add analyzer suppressions, `#pragma warning disable`, `#nullable disable`, or test `[Ignore]` attributes to suppress new findings introduced by the change.
-- Do not report success based on partial or targeted runs alone. Targeted runs are allowed mid-batch, but the final gate requires a full-solution pass.
+- Do not report success based on partial or targeted runs. A focused run of one test file to debug a specific failure is debugging only; it is never a gate or evidence, and the final gate is the single gate run.

package/resources/claude-customizations/.claude-variants/csharp-legacy/skills/invoke-csharp-engineer/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: invoke-csharp-engineer
-description: Invoke the csharp-typed-engineer worker to design, implement, and verify C# changes within typed repository boundaries. Applies CSharpier -> .NET Analyzers -> Nullable Analysis -> MSTest toolchain, the 1-3 production-file small-path budget, and zero-regression quality gates.
+description: Invoke the csharp-typed-engineer worker to design, implement, and verify C# changes within typed repository boundaries. Applies CSharpier -> .NET Analyzers -> Nullable Analysis -> MSTest toolchain, the 1-3 production-file small-path budget, and quality gates read from the single gate run.
 ---
 
 # Implement C# Skill
@@ -28,7 +28,7 @@ If the estimated scope exceeds the small-path budget, this skill defers to the o
 ## Output Paths
 
 - C# source and test files within the approved scope.
-- Baseline evidence under `<FEATURE>/evidence/baseline/<timestamp>/` and post-change evidence under `<FEATURE>/evidence/qa-gates/<timestamp>/` per `evidence-and-timestamp-conventions`.
+- Static baseline evidence under `<FEATURE>/evidence/baseline/<timestamp>/` and final gate evidence under `<FEATURE>/evidence/qa-gates/<timestamp>/` per `evidence-and-timestamp-conventions`.
 - This location is canonical per evidence-and-timestamp-conventions and is not overridable. See `.claude/skills/evidence-and-timestamp-conventions/SKILL.md` for the canonical evidence path authority.
 - Plan artifacts under the active feature folder when the task is feature-scoped.
 
@@ -37,10 +37,10 @@ If the estimated scope exceeds the small-path budget, this skill defers to the o
 The worker must return the following reporting block:
 
 1. Scope (exact file list).
-2. Baseline (CSharpier, .NET Analyzers, Nullable Analysis, MSTest, coverage status).
+2. Baseline (CSharpier, .NET Analyzers, and Nullable Analysis findings).
 3. Plan (design and test strategy).
 4. Diffs (patch-style or full-file replacements).
-5. QA Gate Results (CSharpier, .NET Analyzers, Nullable Analysis, MSTest, and coverage deltas, or clearly marked **unverified**).
+5. QA Gate Results (CSharpier, .NET Analyzers, and Nullable Analysis deltas, failures in the single gate run, and per-file coverage against the thresholds, or clearly marked **unverified**).
 
 ## Worker Routing
 

package/resources/claude-customizations/pack-manifests/core.json

@@ -39,6 +39,7 @@
     ".claude/hooks/enforce-epic-merge-gate-resolution.ps1",
     ".claude/hooks/enforce-epic-merge-gate-command.ps1",
     ".claude/hooks/enforce-epic-merge-gate-green-ci.ps1",
+    ".claude/hooks/enforce-epic-merge-gate-review.ps1",
     ".claude/hooks/enforce-epic-wave-barrier.ps1",
     ".claude/hooks/enforce-epic-worktree-removal-gate.ps1",
     ".claude/hooks/enforce-epic-worktree-removal-gate-resolution.ps1",
@@ -138,6 +139,12 @@
     ".claude/skills/discovery-workflow/SKILL.md",
     ".claude/skills/epic-orchestrate/SKILL.md",
     ".claude/skills/epic-plan/SKILL.md",
+    ".claude/skills/epic-progress-report/SKILL.md",
+    ".claude/skills/epic-progress-report/scripts/Get-EpicProgressReport.Logic.ps1",
+    ".claude/skills/epic-progress-report/scripts/Get-EpicProgressReport.Metrics.ps1",
+    ".claude/skills/epic-progress-report/scripts/Get-EpicProgressReport.Render.ps1",
+    ".claude/skills/epic-progress-report/scripts/Get-EpicProgressReport.State.ps1",
+    ".claude/skills/epic-progress-report/scripts/Get-EpicProgressReport.ps1",
     ".claude/skills/epic-run/SKILL.md",
     ".claude/skills/evidence-and-timestamp-conventions/SKILL.md",
     ".claude/skills/execute-hard-lock/SKILL.md",