@danmoisan/drm-copilot-mcp 0.0.1

package/resources/claude-customizations/.claude/skills/policy-audit-template-usage/SKILL.md

@@ -0,0 +1,49 @@
+---
+name: policy-audit-template-usage
+description: 'Policy audit template usage and output requirements. Use when creating policy-audit.<timestamp>.md artifacts from the repo templates.'
+---
+
+# Policy Audit Template Usage
+
+Shared rules for creating policy audit artifacts from the MCP-exposed bundled template assets.
+
+## When to Use This Skill
+
+Use this skill when:
+- An agent must create a `policy-audit.<timestamp>.md` file.
+- The MCP-exposed policy-audit template asset is required.
+
+## Template Source
+
+- Required template source: the MCP server tool `mcp__drmCopilotExtension__resolve_policy_audit_template_asset` with asset selector `template`.
+- The resolved MCP asset is authoritative even when a matching repo file also exists.
+- If MCP asset resolution fails, create a minimal policy audit artifact marked BLOCKED and document the missing template resolution.
+
+## Required Steps
+
+1) Resolve the policy-audit template through the MCP server tool `mcp__drmCopilotExtension__resolve_policy_audit_template_asset` with asset `template`, then copy the resolved asset to the target location using an ISO-8601 timestamp.
+2) Replace placeholders with actual values (component, date, files under test, commits).
+3) Remove any template usage instructions per template guidance.
+4) Mark each section PASS/FAIL/N/A using the template’s expected conventions.
+5) Preserve the canonical major sections from the template:
+   - `## Executive Summary`
+   - `## 1. General Unit Test Policy Compliance`
+   - `## 2. General Code Change Policy Compliance`
+   - `## 3. Language-Specific Code Change Policy Compliance`
+   - `## 4. Language-Specific Unit Test Policy Compliance`
+   - `## 5. Test Coverage Detail`
+   - `## 6. Test Execution Metrics`
+   - `## 7. Code Quality Checks`
+   - `## 8. Gaps and Exceptions`
+   - `## 9. Summary of Changes`
+   - `## 10. Compliance Verdict`
+   - `## Appendix A: Test Inventory`
+   - `## Appendix B: Toolchain Commands Reference`
+6) Run the `mcp__drmCopilotExtension__validate_orchestration_artifacts` MCP tool with `artifact_type: "policy-audit"` and `artifact_path: <path>` and fail closed on any non-zero result.
+
+## Invalid Outputs
+
+- A freeform summary note is invalid.
+- A policy audit that retains the template instruction block is invalid.
+- A policy audit that omits the canonical major headings is invalid.
+

package/resources/claude-customizations/.claude/skills/policy-compliance-order/SKILL.md

@@ -0,0 +1,40 @@
+---
+name: policy-compliance-order
+description: 'Repository policy compliance order and hard constraints. Use when an agent must read mandatory policy files, apply repo-wide constraints, or restate policy precedence without duplicating blocks across agents.'
+---
+
+# Policy Compliance Order
+
+Shared policy-compliance instructions to avoid duplicating the same policy order across multiple agents.
+
+## When to Use This Skill
+
+Use this skill when:
+- An agent must declare the repository’s mandatory policy reading order.
+- You need to reiterate non-negotiable constraints (e.g., no policy edits, no secrets, no silent skips).
+- Multiple agents share the same compliance preamble.
+
+## Required Policy Reading Order (Baseline)
+
+Claude Code auto-loads rules via path-scoped frontmatter in `.claude/rules/`. This ordering documents precedence when policies conflict:
+
+1) `CLAUDE.md` (standing instructions, always loaded)
+2) `.claude/rules/general-code-change.md` (cross-language code change policy)
+3) `.claude/rules/general-unit-test.md` (cross-language unit test policy)
+4) Language- or domain-specific rules based on files in scope:
+   - Python: `.claude/rules/python.md`, `.claude/rules/python-suppressions.md`
+   - PowerShell: `.claude/rules/powershell.md`
+   - TypeScript: `.claude/rules/typescript.md`, `.claude/rules/typescript-suppressions.md`
+   - C#: `.claude/rules/csharp.md`
+
+## Hard Constraints (Baseline)
+
+- Do NOT modify policy documents under `.claude/rules/` or `.github/instructions/`.
+- Do NOT create secrets or `.env` files unless explicitly requested.
+- Prefer repo-defined tasks/commands when running checks.
+- If information is missing, proceed with best-effort assumptions and document them.
+
+## Extensions (Agent-Specific)
+
+Agents may append additional requirements that are unique to their role (e.g., policy audit templates or epic docs), but should not duplicate the baseline order above.
+

package/resources/claude-customizations/.claude/skills/powershell-change-budget-router/SKILL.md

@@ -0,0 +1,49 @@
+---
+name: powershell-change-budget-router
+description: Budget-first routing contract for PowerShell work: estimate production-file scope, choose small vs large path, enforce direct-mode escalation to orchestrator, and use the VS Code extension command surface for promotion lifecycle steps when available.
+---
+
+# PowerShell Change Budget Router
+
+Canonical guidance for deciding whether work should execute directly in `powershell-typed-engineer` or be escalated to `powershell-orchestrator`.
+
+## When to Use This Skill
+
+Use this skill when:
+- Intake starts from a natural-language PowerShell request.
+- An agent must decide execution path before planning or implementation.
+- A direct implementation agent must reject over-budget requests and route to orchestrator.
+
+## Canonical Routing Rules
+
+1) Estimate rough change budget first based on likely **production PowerShell files** touched.
+2) Route:
+- `1-2` production files (+ corresponding tests) → **small path** (`powershell-typed-engineer` direct mode).
+- `>2` production files → **large path** (`powershell-orchestrator`).
+
+## Orchestrated Small-Path Requirements
+
+When routed through `powershell-orchestrator`, small path still requires lifecycle scaffolding before implementation:
+- invoke promotion/folder lifecycle steps through `vscode/runCommand` + extension access per `feature-promotion-lifecycle` when available; use script/CLI fallback only when direct extension command execution is unavailable,
+- promote potential item to GitHub issue with `--work-mode minor-audit`,
+- create active feature folder with `--work-mode minor-audit`,
+- delegate minimal-audit plan creation to `atomic_planner` with `DIRECTIVE: MINIMAL-AUDIT PLAN REQUIRED`,
+- require `atomic_executor` preflight until `PREFLIGHT: ALL CLEAR`,
+- execute Phase 0 only via `atomic_executor` before branching,
+- run reduced small-audit after implementation and QC.
+
+Direct invocation of `powershell-typed-engineer` remains implementation-focused and does not replace orchestrator lifecycle steps.
+
+## Direct-Mode Rejection Rule
+
+If `powershell-typed-engineer` is invoked directly and estimated scope is `>2` production files:
+- Stop before implementation.
+- Return explicit routing instruction to invoke `powershell-orchestrator`.
+
+## Documentation Expectations
+
+Record in response/logs:
+- estimated production file count,
+- chosen path (`small`/`large`),
+- rationale summary (1-3 bullets).
+

package/resources/claude-customizations/.claude/skills/powershell-orchestration-state-machine/SKILL.md

@@ -0,0 +1,58 @@
+---
+name: powershell-orchestration-state-machine
+description: Checkpoint schema and resume protocol for long-running PowerShell orchestration workflows.
+---
+
+# PowerShell Orchestration State Machine
+
+Canonical checkpoint and resume behavior for orchestration agents running multi-step PowerShell delivery flows.
+
+## When to Use This Skill
+
+Use this skill when:
+- A workflow spans multiple delegations and commands.
+- Execution may be interrupted and must resume deterministically.
+- An orchestrator must avoid repeating completed steps.
+
+## Canonical Checkpoint Location
+
+- `artifacts/orchestration/powershell-orchestrator-state.json`
+
+## Required Checkpoint Fields
+
+- `objective`
+- `change_budget_estimate`
+- `path_selected` (`small` or `large`)
+- `promotion-type`
+- `short-name`
+- `relativeFile`
+- `long-name`
+- `issue-num`
+- `feature-folder`
+- `work-mode` (`minor-audit`, `full-feature`, or `full-bug`; normalize legacy `full` to `full-feature` before persistence)
+- `plan-path` (minimal or full plan path)
+- `completed_steps`
+- `next_step`
+- `last_updated`
+
+For short-path runs, also persist:
+- `small_path_qc_summary`
+- `small_path_audit_artifacts`
+- `bootstrap_mode` (`manual-bootstrap` or `auto-small-dev`)
+- `phase0_execution_summary`
+- `resume_after_manual_bootstrap` (next step token)
+
+## Update Protocol
+
+- Write checkpoint after every completed orchestration sub-step.
+- Treat checkpoint as source-of-truth for progress state.
+- Never claim mission completion until checkpoint marks final state.
+
+## Resume Protocol
+
+On invocation:
+1) Read checkpoint if it exists.
+2) If incomplete, resume from `next_step` without re-running `completed_steps`.
+3) If missing or completed, start at phase-0 intake.
+4) If user explicitly requests restart, reset checkpoint and start phase-0.
+

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

@@ -0,0 +1,77 @@
+---
+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.
+---
+
+# PowerShell QA Gate
+
+Canonical procedure for the Phase D final quality gate that every PowerShell change must pass before completion is reported.
+
+## When to Use This Skill
+
+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.
+- 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,
+- the exact list of touched production and test files,
+- a clean working tree (all planned edits committed to the working copy).
+
+## Toolchain Execution Sequence
+
+Run the full toolchain in this exact order. If any step fails or modifies files, fix the issue and restart from step 1. Do not stop the loop until all steps complete without errors in a single pass.
+
+1. `mcp__drmCopilotExtension__run_poshqc_format`
+2. `mcp__drmCopilotExtension__run_poshqc_analyze`
+3. `mcp__drmCopilotExtension__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.
+
+If the environment prevents running any tool, stop and report the change as **unverified**. Do not declare completion.
+
+## Delta Requirements (Zero-Regression Hard Gate)
+
+Compare the final results to the Phase A baseline. 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**: 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.
+
+## 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.
+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.
+
+## 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>/`,
+- use ISO-8601 UTC timestamps in folder names.
+
+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.
+
+The evidence paths must be referenced in the agent's completion message to satisfy the `SubagentStop` completion-artifact gate.
+
+## Prohibited Shortcuts
+
+- 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 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/pr-author/SKILL.md

@@ -0,0 +1,50 @@
+---
+name: pr-author
+description: Write a GitHub-ready pull request body from the canonical PR-context bundle with strict verification and auto-close rules.
+allowed-tools:
+  - Read
+  - "Bash(git log *)"
+---
+
+# PR Author Skill
+
+Produce a GitHub-ready Pull Request description from the standard PR context files. The pull request must be in a copy / paste block so that it can be copied easily to the PR extension.
+
+## Inputs
+
+- `artifacts/pr_context.summary.txt` — PR context summary (primary)
+- `artifacts/pr_context.appendix.txt` — PR context appendix (full baseline diff, commits, changed files)
+- Optional user directives
+
+Only reference files that are listed under "Additional context files" in the context bundle. Do not cite or summarize files outside that enumeration.
+
+## Output Requirements
+
+1. Output only the PR text body in GitHub-flavored Markdown.
+2. Use clear headings, consistent structure, and concise bullets.
+3. Do not invent tests or results; if not in context, state "Not verified in this PR."
+4. If scope is large, include a Review Guide with suggested review order.
+5. The output is a PR body artifact or PR-ready body text only.
+
+## PR Body Structure
+
+Use these sections in this order:
+
+1. **Suggested title** — crisp, prioritizing the primary outcome
+2. **Summary** — 3–7 bullets, most important first; lead with the primary product/feature/architecture change
+3. **Why** — motivation, constraints, root cause; rely on embedded feature-doc excerpts and PR Intent fields only
+4. **What Changed** — grouped by theme (core feature, tooling/CI, tests, docs/templates)
+5. **Architecture / How It Fits Together** — short wiring description with components, entry points, control flow
+6. **Verification** — "Completed" (from context) and "Recommended" (commands to run)
+7. **Backward Compatibility / Migration Notes** — breaking changes, removals, renamed paths
+8. **Risks and Mitigations** — realistic risks with mitigations and rollback notes
+9. **Review Guide** — suggested order, noisy mechanical moves, large diffs
+10. **Follow-ups** — known TODOs, deferred cleanup, next PRs
+11. **GitHub Auto-close** — `- Closes #NNN` only from verified autoclose lists; do not invent issue numbers
+
+## Issue/PR Reference Rules
+
+- Only mention an issue/PR number if it appears verbatim in the provided context.
+- Do not treat PR numbers as issues.
+- Auto-close bullets must use exactly `- Closes #NNN` format, sourced only from "Issues to autoclose" or "Author-asserted autoclose issues."
+- If GitHub validation is unavailable/unverified, do not emit `Closes`; use the fallback `None` bullet.

package/resources/claude-customizations/.claude/skills/pr-base-branch-merge-base/SKILL.md

@@ -0,0 +1,56 @@
+---
+name: pr-base-branch-merge-base
+description: 'Resolve PRBaseBranch for mcp__drmCopilotExtension__collect_pr_context using merge-base ancestry. Use when orchestrators or review workflows need the correct comparison base branch and must select the branch with the most recent common ancestor commit with HEAD.'
+---
+
+# PR Base Branch (Merge-Base)
+
+Deterministic branch-selection rules for PR context collection.
+
+## When to Use This Skill
+
+Use this skill when:
+- running `mcp__drmCopilotExtension__collect_pr_context`,
+- delegating post-implementation review that depends on `PRBaseBranch`,
+- constructing PR context artifacts where the base must not be hard-coded.
+
+## Selection Contract
+
+`PRBaseBranch` MUST be resolved from git ancestry, not guessed.
+
+Definition of correct base:
+- choose the candidate branch whose merge-base with `HEAD` has the most recent commit timestamp,
+- this implements “find the branch with the most recent commit in common.”
+
+## Deterministic Procedure
+
+1. Enumerate candidate branches from local and remotes, excluding `HEAD` and detached refs.
+2. For each candidate `B`, compute merge-base commit `M = git merge-base HEAD B`.
+3. Compute `merge_base_epoch(B)` from `git show -s --format=%ct M`.
+4. Select branch with maximum `merge_base_epoch(B)`.
+5. Tie-breakers (in order):
+   - `development`
+   - `main`
+   - `master`
+   - lexical ascending branch name
+
+## Guardrails
+
+- Do not default to `main` unless merge-base resolution fails for all candidates.
+- If all candidates fail, surface explicit error context and use repository default branch only as last-resort fallback.
+- Persist chosen `PRBaseBranch` in orchestration state and reuse it within the same run.
+
+## Collector Invocation Rule
+
+When invoking PR context collection, pass the resolved base explicitly:
+
+- `mcp__drmCopilotExtension__collect_pr_context` with `base=<resolved-PRBaseBranch>`
+
+## Evidence Recommendation
+
+For auditability, include in logs/checkpoint:
+- selected branch name,
+- selected merge-base SHA,
+- selected merge-base timestamp,
+- top competing candidates with timestamps when available.
+

package/resources/claude-customizations/.claude/skills/pr-context-artifacts/SKILL.md

@@ -0,0 +1,30 @@
+---
+name: pr-context-artifacts
+description: 'PR context artifact locations and refresh rules. Use when generating, reading, or inlining pr_context summary/appendix artifacts.'
+---
+
+# PR Context Artifacts
+
+Canonical locations and usage rules for PR context artifacts.
+
+## When to Use This Skill
+
+Use this skill when:
+- You generate or refresh PR context artifacts.
+- You reference PR context summary/appendix as evidence.
+- You inline PR context artifacts into remediation handoffs.
+
+## Canonical Artifact Locations
+
+- Summary: `artifacts/pr_context.summary.txt`
+- Appendix: `artifacts/pr_context.appendix.txt`
+
+## Refresh Rule
+
+If the artifacts are missing or stale relative to the current branch state, re-generate them using the repo’s PR context collector.
+
+- When `PRBaseBranch` is supplied explicitly, use that exact branch for refresh.
+- When `PRBaseBranch` is missing or ambiguous, resolve it first with `pr-base-branch-merge-base` before running the collector.
+- Do not infer the refresh base from the repository default branch unless merge-base resolution fails for all candidates.
+- Treat an already-fresh artifact pair as authoritative; do not refresh solely because no explicit `PRBaseBranch` input was provided.
+

package/resources/claude-customizations/.claude/skills/python-change-budget-router/SKILL.md

@@ -0,0 +1,79 @@
+---
+name: python-change-budget-router
+description: Budget-first routing and batch-scope contract for Python work. Estimate production-file scope, choose small vs large path, enforce the 3 production + 3 test per-batch cap, and halt the agent for scope expansion approval when the estimate exceeds the budget.
+---
+
+# Python Change Budget Router
+
+Canonical guidance for deciding whether Python work stays on the small path (`python-typed-engineer` direct mode) or escalates to the full orchestration workflow, and for enforcing per-batch change budgets during execution.
+
+## When to Use This Skill
+
+Use this skill when:
+
+- Intake starts from a natural-language Python request.
+- An agent must decide the execution path before planning or implementation.
+- A direct-mode route must reject over-budget requests and switch to orchestrated flow.
+- An executor must confirm a batch fits within the 3 production + 3 test file cap before editing.
+
+## Canonical Routing Rules
+
+1. Estimate rough change budget first based on likely **production Python files** touched.
+2. Route:
+   - `1-3` production files (plus corresponding tests) → **small path** (`python-typed-engineer` direct mode).
+   - `>3` production files → **large path** (orchestration workflow with promotion, research, spec, planning, execution, and review).
+
+## Per-Batch Change Budget (Hard Gate)
+
+During Phase C execution:
+
+- A single batch may change at most **3 production files** and **3 test files**.
+- The default cap applies unless the user supplies an override of the form `budget: prod=<N>, test=<M>` in the initiating prompt.
+- A user override may be honored only if it complies with repo policy and approved scope. If the requested scope exceeds 3 production files overall, stop before execution and seek explicit approval.
+- If an override is requested, confirm compliance with repo policy before entering Phase C.
+
+## Scope Expansion Protocol
+
+When in-scope work is required beyond 3 production files, stop and return:
+
+- a one-paragraph justification for the additional files,
+- the exact additional file paths,
+- the smallest alternative that avoids expanding scope,
+
+and wait for explicit user approval before proceeding.
+
+Allowed minimal-seam exceptions (still within the 3-file cap) are:
+
+- introducing a minimal seam for testability (I/O boundary isolation, dependency injection),
+- typing changes required for Pyright cleanliness in the slice,
+- updating the smallest set of call sites needed to preserve a stable public API.
+
+## Direct-Mode Rejection Rule
+
+If `python-typed-engineer` is invoked directly and estimated scope is `>3` production files:
+
+- Stop before implementation.
+- Return an explicit routing instruction to invoke the orchestrated workflow.
+
+## Orchestrated Small-Path Requirements
+
+When routed through the orchestrator, the small path still requires lifecycle scaffolding before implementation:
+
+- invoke promotion and folder lifecycle steps through `vscode/runCommand` and extension access per `feature-promotion-lifecycle` when available. Use script or CLI fallback only when direct extension command execution is unavailable.
+- promote the potential item to a GitHub issue with `--work-mode minor-audit`,
+- create the active feature folder with `--work-mode minor-audit`,
+- delegate minimal-audit plan creation to `atomic_planner` with `DIRECTIVE: MINIMAL-AUDIT PLAN REQUIRED`,
+- require `atomic_executor` preflight until `PREFLIGHT: ALL CLEAR`,
+- execute Phase 0 only via `atomic_executor` before branching,
+- run the reduced small-audit after implementation and QC.
+
+Direct invocation of `python-typed-engineer` remains implementation-focused and does not replace orchestrator lifecycle steps.
+
+## Documentation Expectations
+
+Record in the agent response or logs:
+
+- estimated production file count,
+- chosen path (`small` or `large`),
+- rationale summary (1-3 bullets),
+- any requested budget override and its approval state.

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

@@ -0,0 +1,77 @@
+---
+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.
+---
+
+# Python QA Gate
+
+Canonical procedure for the Phase D final quality gate that every Python change must pass before completion is reported.
+
+## When to Use This Skill
+
+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.
+- 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,
+- the exact list of touched production and test files,
+- a clean working tree (all planned edits committed to the working copy).
+
+## Toolchain Execution Sequence
+
+Run the full toolchain in this exact order. If any step fails or modifies files, fix the issue and restart from step 1. Do not stop the loop until all four steps complete without errors in a single pass.
+
+1. `poetry run black .`
+2. `poetry run ruff check .`
+3. `poetry run pyright`
+4. `poetry run pytest --cov --cov-report=term-missing`
+
+If the environment prevents running any tool, stop and report the change as **unverified**. Do not declare completion.
+
+## Delta Requirements (Zero-Regression Hard Gate)
+
+Compare the final results to the Phase A baseline. 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**: 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.
+
+## 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.
+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.
+
+## 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>/`,
+- use ISO-8601 UTC timestamps in folder names.
+
+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.
+
+The evidence paths must be referenced in the agent's completion message to satisfy the `SubagentStop` completion-artifact gate.
+
+## Prohibited Shortcuts
+
+- 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.

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

@@ -0,0 +1,40 @@
+---
+name: remediation-handoff-atomic-planner
+description: 'Reusable remediation trigger and atomic_planner handoff steps. Use when audits require remediation inputs and a delegated remediation plan.'
+---
+
+# Remediation Handoff to atomic_planner
+
+Shared remediation workflow and handoff expectations for agents that delegate to `atomic_planner`.
+
+## When to Use This Skill
+
+Use this skill when:
+- Audit findings require remediation.
+- You must create remediation inputs and delegate plan creation to `atomic_planner`.
+
+## Trigger Conditions (Generic)
+
+Trigger remediation when any of these are true:
+- Audit artifacts contain FAIL or meaningful PARTIAL findings.
+- Toolchain checks fail.
+- Acceptance criteria are not met.
+
+## Required Remediation Inputs
+
+Create `remediation-inputs.<timestamp>.md` with:
+- Enumerated fix list with file paths, expected behavior, and verification commands.
+- A “do not do” list (no scope creep, no policy weakening, no silent skips).
+
+## Plan Creation and Handoff
+
+1) Create a remediation plan target file using the repo’s plan template.
+2) Delegate to `atomic_planner` with:
+   - `${spec}` pointing to remediation inputs (authoritative)
+   - `${file}` pointing to the remediation plan target file
+3) Require `atomic_planner` to output a deterministic, atomic plan with phases and `[P#-T#]` IDs.
+
+## Context Package (When Required)
+
+If the calling agent requires a context package, inline the specified audit artifacts, PR context artifacts, and any relevant plan files in the delegated prompt.
+