@danmoisan/drm-copilot-mcp 0.0.1

package/resources/claude-customizations/.claude/skills/feature-review-workflow/SKILL.md

@@ -0,0 +1,167 @@
+---
+name: feature-review-workflow
+description: 'Feature-branch review workflow for base-branch resolution, PR-context refresh, active feature folder selection, review artifact generation, validator gates, acceptance-criteria check-off, and remediation triggers. Use when authoring or executing PR-style feature reviews.'
+---
+
+# Feature Review Workflow
+
+Reusable workflow guidance for PR-style feature review.
+
+## Required Shared Skills
+
+Always apply:
+- `policy-compliance-order`
+- `evidence-and-timestamp-conventions`
+- `policy-audit-template-usage`
+- `pr-context-artifacts`
+- `pr-base-branch-merge-base`
+- `acceptance-criteria-tracking`
+- `remediation-handoff-atomic-planner`
+
+## Role
+
+- Review a feature branch relative to the correct base branch.
+- Produce audit artifacts, not implementation fixes.
+- Prefer deterministic evidence from canonical PR-context artifacts and exact diff anchors.
+- Trigger remediation planning when blockers or unmet acceptance criteria remain.
+
+## Workflow Contract
+
+### Baseline and evidence
+
+- Treat the review as a feature-vs-base audit, not an isolated file inspection.
+- Use `artifacts/pr_context.summary.txt` as the primary evidence source.
+- Use `artifacts/pr_context.appendix.txt` as the baseline-diff appendix for raw evidence and exact anchors.
+- If PR-context artifacts are missing or stale, refresh them per `pr-context-artifacts` using the resolved base branch.
+
+### Review artifact templates
+
+- When creating review artifacts from templates, use the MCP-exposed bundled assets instead of copying directly from repo template paths.
+- Resolve the templates through the MCP server tool `resolve_policy_audit_template_asset` with these selectors:
+  - `template` for `policy-audit.<timestamp>.md`
+  - `code-review-template` for `code-review.<timestamp>.md`
+  - `feature-audit-template` for `feature-audit.<timestamp>.md`
+- The MCP-resolved asset is the authoritative template source for review artifacts in this workflow.
+
+### No silent fixes
+
+- Do not clean up code during review.
+- If checks fail, document the failure and include exact remediation guidance.
+
+### Work-mode acceptance-criteria contract
+
+- Read the persisted marker from `issue.md` using one of:
+  - `- Work Mode: minor-audit`
+  - `- Work Mode: full-feature`
+  - `- Work Mode: full-bug`
+- Legacy compatibility: interpret `- Work Mode: full` as `full-feature`.
+- Acceptance-criteria sources by marker:
+  - `minor-audit`: only the explicit `## Acceptance Criteria` section in `issue.md`
+  - `full-feature`: `spec.md` and `user-story.md`
+  - `full-bug`: `spec.md`
+- Fail closed:
+  - if the marker is missing or malformed, use `full-feature`
+  - if `minor-audit` is selected and `issue.md` lacks `## Acceptance Criteria`, require remediation
+
+## Ordered Procedure
+
+1. **Resolve the base branch**
+   - Use the supplied base branch when it is present.
+   - Otherwise resolve `PRBaseBranch` with `pr-base-branch-merge-base`.
+   - Record the resolved branch, merge-base SHA, merge-base timestamp, and top competing candidates when available.
+
+2. **Load or refresh PR context**
+   - Load the canonical PR-context summary and appendix per `pr-context-artifacts`.
+   - Refresh only when the artifacts are missing or stale relative to the current branch state.
+
+3. **Determine the active feature folder**
+   - Prefer the active feature folder that corresponds to the primary changed scoping docs.
+   - If multiple active folders are present, prefer the one whose suffix matches the issue number in the branch name.
+   - Otherwise choose the folder with the most material scoping-doc changes.
+   - If no active feature folder exists, create `docs/features/active/<today>-feature-review/` and document the assumption.
+
+4. **Produce the policy audit**
+  - Use `policy-audit-template-usage` and the MCP `template` asset to drive the artifact structure.
+   - Include exact command references for the checks that were run.
+   - Validate the resulting `policy-audit.<timestamp>.md` immediately after writing it.
+
+5. **Run required checks**
+   - Prefer repo-defined, check-only commands.
+   - Default order:
+     1. formatting check
+     2. lint check
+     3. type check
+     4. tests
+     5. coverage (mandatory for every language that has changed files)
+        - TypeScript: `npm run test:unit:coverage` → artifact: `coverage/lcov.info`
+        - Python: `poetry run pytest --cov` → artifact: `artifacts/python/lcov.info`
+        - PowerShell: `mcp__drmCopilotExtension__run_poshqc_test` → artifact: `artifacts/pester/powershell-coverage.xml`
+        - C#: `vstest.console.exe <test-assembly-paths> /EnableCodeCoverage` → artifact: `artifacts/csharp/coverage.xml`
+        - Coverage thresholds:
+          - New code files (added in this feature): line coverage must be >= 90%. Flag as FAIL otherwise.
+          - Modified files (changed but previously existing): line coverage must show no regression relative to baseline and must remain >= 80%. Flag as FAIL otherwise.
+          - Repo-wide line coverage must remain >= 80% per language. Flag as FAIL otherwise.
+        - If coverage artifacts already exist from the executor run, inspect them instead of re-running.
+        - If no coverage artifact exists for a language that has changed files, flag as FAIL — coverage verification is mandatory for all languages with changed files.
+   - Run the smallest relevant subset first when the repo policy permits it.
+   - If a tool cannot run in the environment, mark the affected section unverified or partial with a concrete reason.
+
+6. **Produce the code review**
+  - Create the artifact from the MCP `code-review-template` asset.
+   - Write `code-review.<timestamp>.md` with:
+     - `## Executive Summary`
+     - `## Findings Table`
+     - a Markdown findings table header containing `Severity | File | Location | Finding | Recommendation | Rationale | Evidence`
+   - Include typed-Python review where Python files changed.
+   - Validate the artifact immediately after writing it.
+
+7. **Produce the feature audit**
+  - Create the artifact from the MCP `feature-audit-template` asset.
+   - Write `feature-audit.<timestamp>.md` with:
+     - `## Scope and Baseline`
+     - `## Acceptance Criteria Inventory`
+     - `## Acceptance Criteria Evaluation`
+     - `## Summary`
+     - `## Acceptance Criteria Check-off`
+   - Use the resolved base branch in the baseline section.
+   - Evaluate each criterion as PASS, PARTIAL, FAIL, or UNVERIFIED.
+   - Check off passing criteria in the authoritative source files per `acceptance-criteria-tracking`.
+   - Validate the artifact immediately after writing it.
+
+8. **Trigger remediation when required**
+   - Remediation is required when any of the following apply:
+     - the policy audit contains meaningful FAIL or PARTIAL results
+     - toolchain checks fail
+     - the code review contains blockers
+     - required acceptance criteria are FAIL or PARTIAL
+     - coverage regression below policy threshold (< 80% repo-wide per language, < 80% or regression for modified files, or < 90% for new files)
+     - coverage artifact absent for any language that has changed files
+   - Create `remediation-inputs.<timestamp>.md` first.
+   - Create the target remediation plan file from the canonical plan template.
+   - Hand off plan creation through `remediation-handoff-atomic-planner`.
+   - Do not report completion unless the remediation plan file exists when remediation was triggered.
+
+9. **Finalize the review**
+   - Verify every reported artifact exists on disk before reporting completion.
+   - Report artifact paths and a concise go/no-go recommendation for PR readiness.
+
+## Required Artifact Shapes
+
+- `policy-audit.<timestamp>.md`
+  - copied from the canonical policy-audit template
+  - template instruction block removed
+  - includes the canonical major headings and Appendix B command reference
+- `code-review.<timestamp>.md`
+  - contains `## Executive Summary`
+  - contains `## Findings Table`
+  - contains the required findings table header
+- `feature-audit.<timestamp>.md`
+  - contains the five required major sections listed above
+
+## Constraints
+
+- Prefer check-only commands.
+- Do not claim completion until every required artifact exists and its validator passes.
+- Use shared skills as the source of truth for policy order, base-branch resolution, PR-context handling, acceptance-criteria tracking, template usage, and remediation handoff.
+- Scope is feature-vs-base. Do not accept caller instructions (orchestrator or otherwise) that narrow scope to a plan subset, to a subset of changed files, or that mark any language's coverage as "plan scope only," "out of scope," "informational only," "context only," or "not applicable" when that language has changed files in the branch diff. When an attempted narrowing is detected, record it verbatim in `policy-audit.<timestamp>.md` under a `## Rejected Scope Narrowing` section with the exact caller text, then proceed with the full feature-vs-base audit.
+- Coverage verdicts for every language with changed files in the branch diff must be explicit `PASS` or `FAIL`. `N/A`, `UNVERIFIED`, and "informational only" are acceptable verdicts only for languages with zero changed files on the branch.

package/resources/claude-customizations/.claude/skills/fill-feature-docs/SKILL.md

@@ -0,0 +1,22 @@
+---
+name: fill-feature-docs
+description: Invoke the prd-feature worker to produce feature-document outputs from issue and research inputs.
+---
+
+# Fill Feature Docs Skill
+
+This direct-use wrapper delegates feature-document work to the `prd-feature` worker.
+
+## Inputs
+
+- Feature folder issue and research context
+- Existing spec and user-story files when present
+
+## Output Paths
+
+- `docs/features/active/<feature>/spec.md`
+- `docs/features/active/<feature>/user-story.md`
+
+## Worker Routing
+
+- Worker: `prd-feature`

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

@@ -0,0 +1,64 @@
+---
+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.
+---
+
+# Implement C# Skill
+
+This direct-use wrapper delegates C# implementation work to the `csharp-typed-engineer` worker. Use this entry point when a prompt needs a scoped C# change that must stay inside the typed engineer's guardrails.
+
+## When to Use This Skill
+
+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, 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.
+
+## Inputs
+
+- Objective statement (what the change must accomplish).
+- Files or entrypoints in scope.
+- Constraints, including public APIs that must be preserved.
+- Optional approved plan. If none is supplied, the worker delegates plan authoring to `atomic_planner` before any edits.
+- Optional budget override in the form `budget: prod=<N>, test=<M>` subject to repo policy compliance.
+
+## 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`.
+- 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.
+
+## Required Reporting Block
+
+The worker must return the following reporting block:
+
+1. Scope (exact file list).
+2. Baseline (CSharpier, .NET Analyzers, Nullable Analysis, MSTest, coverage status).
+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**).
+
+## Worker Routing
+
+- Worker: `csharp-typed-engineer`
+
+## Preloaded Contracts
+
+The worker operates under the following preloaded skills and rules:
+
+- `policy-compliance-order`
+- `csharp-change-budget-router`
+- `atomic-plan-contract`
+- `csharp-qa-gate`
+- `acceptance-criteria-tracking`
+- `feature-promotion-lifecycle`
+- `remediation-handoff-atomic-planner`
+- `evidence-and-timestamp-conventions`
+- `.claude/rules/csharp.md` (path-scoped for `**/*.cs` and `**/*.csproj`)
+- `.claude/rules/general-code-change.md`
+- `.claude/rules/general-unit-test.md`
+- `.claude/rules/tonality.md`

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

@@ -0,0 +1,65 @@
+---
+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-2 production-file direct-mode budget, the 3-production + 3-test per-batch cap, and zero-regression quality gates.
+---
+
+# Implement PowerShell Skill
+
+This direct-use wrapper delegates PowerShell implementation work to the `powershell-typed-engineer` worker. Use this entry point when a prompt needs a scoped PowerShell change that must stay inside the typed engineer's guardrails.
+
+## When to Use This Skill
+
+Use this skill when:
+
+- The user requests a PowerShell code change, bug fix, refactor, or test addition.
+- Estimated scope fits the direct-mode path (1-2 production PowerShell files plus corresponding tests).
+- The toolchain (PoshQC format, PSScriptAnalyzer, Pester with coverage where enforced) can be run in the current environment, or the user has explicitly authorized an unverified plan-only response.
+
+If the estimated scope exceeds the direct-mode budget, this skill defers to the orchestrated flow via `powershell-change-budget-router` instead of proceeding directly.
+
+## Inputs
+
+- Objective statement (what the change must accomplish).
+- Files or entrypoints in scope (exact script or module paths and corresponding `*.Tests.ps1` paths).
+- Constraints, including public function or module contracts that must be preserved.
+- Optional approved plan. If none is supplied, the worker delegates plan authoring to `atomic_planner` before any edits.
+- Optional budget override in the form `budget: prod=<N>, test=<M>` subject to repo policy compliance.
+
+## 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`.
+- 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.
+
+## Required Reporting Block
+
+The worker must return the `powershell-qa-gate` reporting block:
+
+1. Scope (exact file list).
+2. Baseline (PSScriptAnalyzer, Pester, coverage status).
+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**).
+
+## Worker Routing
+
+- Worker: `powershell-typed-engineer`
+
+## Preloaded Contracts
+
+The worker operates under the following preloaded skills and rules:
+
+- `policy-compliance-order`
+- `powershell-change-budget-router`
+- `powershell-orchestration-state-machine`
+- `atomic-plan-contract`
+- `powershell-qa-gate`
+- `acceptance-criteria-tracking`
+- `feature-promotion-lifecycle`
+- `remediation-handoff-atomic-planner`
+- `evidence-and-timestamp-conventions`
+- `.claude/rules/powershell.md` (path-scoped for `**/*.ps1`, `**/*.psm1`, `**/*.psd1`)
+- `.claude/rules/general-code-change.md`
+- `.claude/rules/general-unit-test.md`
+- `.claude/rules/tonality.md`

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

@@ -0,0 +1,64 @@
+---
+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 3-production + 3-test per-batch budget, and zero-regression quality gates.
+---
+
+# Implement Python Skill
+
+This direct-use wrapper delegates Python implementation work to the `python-typed-engineer` worker. Use this entry point when a prompt needs a scoped Python change that must stay inside the typed engineer's guardrails.
+
+## When to Use This Skill
+
+Use this skill when:
+
+- The user requests a Python code change, bug fix, refactor, or test addition.
+- Estimated scope fits the small path (1-3 production files plus corresponding tests).
+- The toolchain (Black, Ruff, Pyright, Pytest) 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 `python-change-budget-router` instead of proceeding directly.
+
+## Inputs
+
+- Objective statement (what the change must accomplish).
+- Files or entrypoints in scope.
+- Constraints, including public APIs that must be preserved.
+- Optional approved plan. If none is supplied, the worker delegates plan authoring to `atomic_planner` before any edits.
+- Optional budget override in the form `budget: prod=<N>, test=<M>` subject to repo policy compliance.
+
+## 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`.
+- 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.
+
+## Required Reporting Block
+
+The worker must return the `python-qa-gate` reporting block:
+
+1. Scope (exact file list).
+2. Baseline (Ruff, Pyright, Pytest, coverage status).
+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**).
+
+## Worker Routing
+
+- Worker: `python-typed-engineer`
+
+## Preloaded Contracts
+
+The worker operates under the following preloaded skills and rules:
+
+- `policy-compliance-order`
+- `python-change-budget-router`
+- `atomic-plan-contract`
+- `python-qa-gate`
+- `acceptance-criteria-tracking`
+- `feature-promotion-lifecycle`
+- `remediation-handoff-atomic-planner`
+- `evidence-and-timestamp-conventions`
+- `.claude/rules/python.md` (path-scoped for `**/*.py`)
+- `.claude/rules/general-code-change.md`
+- `.claude/rules/general-unit-test.md`
+- `.claude/rules/tonality.md`

package/resources/claude-customizations/.claude/skills/make-skill-template/SKILL.md

@@ -0,0 +1,147 @@
+---
+name: make-skill-template
+description: 'Create new Agent Skills for GitHub Copilot from prompts or by duplicating this template. Use when asked to "create a skill", "make a new skill", "scaffold a skill", or when building specialized AI capabilities with bundled resources. Generates SKILL.md files with proper frontmatter, directory structure, and optional scripts/references/assets folders.'
+---
+
+# Make Skill Template
+
+A meta-skill for creating new Agent Skills. Use this skill when you need to scaffold a new skill folder, generate a SKILL.md file, or help users understand the Agent Skills specification.
+
+## When to Use This Skill
+
+- User asks to "create a skill", "make a new skill", or "scaffold a skill"
+- User wants to add a specialized capability to their GitHub Copilot setup
+- User needs help structuring a skill with bundled resources
+- User wants to duplicate this template as a starting point
+
+## Prerequisites
+
+- Understanding of what the skill should accomplish
+- A clear, keyword-rich description of capabilities and triggers
+- Knowledge of any bundled resources needed (scripts, references, assets, templates)
+
+## Creating a New Skill
+
+### Step 1: Create the Skill Directory
+
+Create a new folder with a lowercase, hyphenated name:
+
+```
+skills/<skill-name>/
+└── SKILL.md          # Required
+```
+
+### Step 2: Generate SKILL.md with Frontmatter
+
+Every skill requires YAML frontmatter with `name` and `description`:
+
+```yaml
+---
+name: <skill-name>
+description: '<What it does>. Use when <specific triggers, scenarios, keywords users might say>.'
+---
+```
+
+#### Frontmatter Field Requirements
+
+| Field | Required | Constraints |
+|-------|----------|-------------|
+| `name` | **Yes** | 1-64 chars, lowercase letters/numbers/hyphens only, must match folder name |
+| `description` | **Yes** | 1-1024 chars, must describe WHAT it does AND WHEN to use it |
+| `license` | No | License name or reference to bundled LICENSE.txt |
+| `compatibility` | No | 1-500 chars, environment requirements if needed |
+| `metadata` | No | Key-value pairs for additional properties |
+| `allowed-tools` | No | Space-delimited list of pre-approved tools (experimental) |
+
+#### Description Best Practices
+
+**CRITICAL**: The `description` is the PRIMARY mechanism for automatic skill discovery. Include:
+
+1. **WHAT** the skill does (capabilities)
+2. **WHEN** to use it (triggers, scenarios, file types)
+3. **Keywords** users might mention in prompts
+
+**Good example:**
+
+```yaml
+description: 'Toolkit for testing local web applications using Playwright. Use when asked to verify frontend functionality, debug UI behavior, capture browser screenshots, or view browser console logs. Supports Chrome, Firefox, and WebKit.'
+```
+
+**Poor example:**
+
+```yaml
+description: 'Web testing helpers'
+```
+
+### Step 3: Write the Skill Body
+
+After the frontmatter, add markdown instructions. Recommended sections:
+
+| Section | Purpose |
+|---------|---------|
+| `# Title` | Brief overview |
+| `## When to Use This Skill` | Reinforces description triggers |
+| `## Prerequisites` | Required tools, dependencies |
+| `## Step-by-Step Workflows` | Numbered steps for tasks |
+| `## Troubleshooting` | Common issues and solutions |
+| `## References` | Links to bundled docs |
+
+### Step 4: Add Optional Directories (If Needed)
+
+| Folder | Purpose | When to Use |
+|--------|---------|-------------|
+| `scripts/` | Executable code (Python, Bash, JS) | Automation that performs operations |
+| `references/` | Documentation agent reads | API references, schemas, guides |
+| `assets/` | Static files used AS-IS | Images, fonts, templates |
+| `templates/` | Starter code agent modifies | Scaffolds to extend |
+
+## Example: Complete Skill Structure
+
+```
+my-awesome-skill/
+├── SKILL.md                    # Required instructions
+├── LICENSE.txt                 # Optional license file
+├── scripts/
+│   └── helper.py               # Executable automation
+├── references/
+│   ├── api-reference.md        # Detailed docs
+│   └── examples.md             # Usage examples
+├── assets/
+│   └── diagram.png             # Static resources
+└── templates/
+    └── starter.ts              # Code scaffold
+```
+
+## Quick Start: Duplicate This Template
+
+1. Copy the `make-skill-template/` folder
+2. Rename to your skill name (lowercase, hyphens)
+3. Update `SKILL.md`:
+   - Change `name:` to match folder name
+   - Write a keyword-rich `description:`
+   - Replace body content with your instructions
+4. Add bundled resources as needed
+5. Validate with `npm run skill:validate`
+
+## Validation Checklist
+
+- [ ] Folder name is lowercase with hyphens
+- [ ] `name` field matches folder name exactly
+- [ ] `description` is 10-1024 characters
+- [ ] `description` explains WHAT and WHEN
+- [ ] `description` is wrapped in single quotes
+- [ ] Body content is under 500 lines
+- [ ] Bundled assets are under 5MB each
+
+## Troubleshooting
+
+| Issue | Solution |
+|-------|----------|
+| Skill not discovered | Improve description with more keywords and triggers |
+| Validation fails on name | Ensure lowercase, no consecutive hyphens, matches folder |
+| Description too short | Add capabilities, triggers, and keywords |
+| Assets not found | Use relative paths from skill root |
+
+## References
+
+- Agent Skills official spec: <https://agentskills.io/specification>

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

@@ -0,0 +1,132 @@
+---
+name: orchestrate
+description: Route a repository request through the deterministic orchestration workflow for feature, bug, research, planning, execution, and review handoffs.
+argument-hint: "[objective]"
+---
+
+# Orchestrate Skill
+
+This skill frames work for the already-active main session, which serves as the orchestrator runtime for end-to-end feature or bug delivery.
+
+## Prerequisites
+
+Before proceeding, the orchestrator must:
+
+1. Read `CLAUDE.md` for repository tone policy and architectural context.
+2. Read applicable `.claude/rules/` files for the languages in scope.
+3. Read the policy files listed in the compliance reading order section of `CLAUDE.md`.
+
+## Checkpoint Handling
+
+On every invocation, the main session must:
+
+1. Read `artifacts/orchestration/orchestrator-state.json` to check for existing state.
+2. If a valid checkpoint exists with a matching objective, resume from the recorded `next_step`.
+3. If no checkpoint exists or the objective is new, begin the orchestration lifecycle from the start.
+
+## Delegation Model
+
+After reading `artifacts/orchestration/orchestrator-state.json`, the main session delegates work exclusively through configured workers:
+
+- `atomic-planner` — generates phased implementation plans
+- `atomic-executor` — executes approved plans task-by-task
+- `feature-review` — produces policy, code, and feature audit artifacts
+- `task-researcher` — performs deep research and writes findings to `artifacts/research/`
+
+The orchestrator does not perform deep implementation itself. It coordinates, tracks state, and enforces completion.
+
+## Evidence Location Authority
+
+All evidence artifacts produced during orchestration MUST comply with the canonical scheme defined in `.claude/skills/evidence-and-timestamp-conventions/SKILL.md`. Evidence MUST be written to `<FEATURE>/evidence/<kind>/` only.
+
+Permitted `artifacts/`-rooted sub-paths (non-evidence orchestration use only):
+- `artifacts/orchestration/` — orchestrator state and checkpoints
+- `artifacts/research/` — research outputs from task-researcher
+- `artifacts/pr_context` — PR context artifacts
+- `artifacts/reviews/` — review staging artifacts
+- `artifacts/status/` — status update artifacts
+- `artifacts/python/` — Python coverage and lcov outputs
+- `artifacts/pester/` — Pester coverage outputs
+- `artifacts/csharp/` — C# coverage outputs
+
+All other `artifacts/` sub-paths (e.g., `artifacts/baselines/`, `artifacts/qa/`, `artifacts/coverage/`, `artifacts/evidence/`) are FORBIDDEN for evidence output and will be blocked by the `enforce-evidence-locations.ps1` PreToolUse hook.
+
+## Completion Requirements
+
+The orchestrator must not report completion until:
+
+1. All required artifacts for the selected workflow path are present on disk.
+2. All validation gates (toolchain, acceptance criteria, audit artifacts) have passed.
+3. The checkpoint file at `artifacts/orchestration/orchestrator-state.json` reflects the completed state.
+
+## Pre-Feature-Review Commit
+
+Before delegating to the `feature-review` subagent, the orchestrator must:
+
+1. Stage all modified and new files: `git add -A`.
+2. Invoke the `commit-message` skill to generate a conventional commit message from the staged diff.
+3. Commit using the generated message: `git commit -m "<generated message>"`.
+4. Only after a successful commit may the orchestrator proceed to the `feature-review` delegation.
+
+The review subagent compares against a base branch; uncommitted changes are invisible to the diff tool and cannot be audited.
+
+## Post-Review Outcome Evaluation
+
+After each `feature-review` delegation returns:
+
+1. Locate `remediation-inputs.<timestamp>.md` in the active feature folder (match the highest ISO-8601 timestamp).
+2. If no such file exists, treat as zero blocking findings and advance to the PR creation gate.
+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.
+
+## Remediation Loop (R1–R5)
+
+A bounded loop consisting of five steps. The loop variable `remediation_pass` starts at 1 and increments at R5 before returning to R1.
+
+- **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). If the executor does not return `PREFLIGHT: ALL CLEAR`, return to R1 and re-delegate to `atomic-planner` with the required-changes output from the executor. Only after `PREFLIGHT: ALL CLEAR` may the orchestrator advance to R3.
+- **R3 — Remediation execution:** Delegate to `atomic-executor` with full execution authorization. Each task's toolchain loop (format → lint → type-check → test) is mandatory; no skipping.
+- **Pre-R4 commit:** Stage all changes (`git add -A`), invoke the `commit-message` skill to generate a commit message from the staged diff, commit with the generated message. Advance to R4 only after a successful commit.
+- **R4 — Re-audit:** Delegate to `feature-review` with the same inputs as the original review (resolved base branch, feature folder, refreshed PR context artifacts, acceptance-criteria source). No scope narrowing. The canonical issue number line must be included.
+- **R5 — Loop-exit decision:** If the re-audit produces zero blocking findings, exit the loop and advance to the PR creation gate. Otherwise, record `remediation_pass` increment in the checkpoint and return to R1.
+
+**Termination guard:** If `remediation_pass` reaches 3 without resolution, the orchestrator records `step6_status: "blocked_remediation_loop_limit"` in the checkpoint and halts. No further automation is attempted.
+
+## Issue Number Consistency
+
+The canonical issue number is derived once from the active feature folder name: extract the trailing integer from the folder base name (e.g., `2026-04-26-push-down-claude-customizations-162` yields `162`). Record as `issue_num` in the checkpoint.
+
+Every delegation prompt to `atomic-planner`, `atomic-executor`, and `feature-review` must include the line:
+
+> `Canonical issue number for this feature is <issue_num>. All artifact content, file paths, and cross-references must use this number.`
+
+If a subagent artifact references a different issue number, the orchestrator rejects it, requests correction, and records the discrepancy under `artifact_errors` in the checkpoint.
+
+## PR Creation Gate
+
+The orchestrator must not create a PR, push a branch for PR purposes, or report work complete until all four conditions are simultaneously true:
+
+1. `blocking_findings_resolved: true` — the most recent `feature-review` produced zero blocking findings.
+2. The AC verification artifact (`p14-acceptance-criteria-checkoff.md` or equivalent) confirms all acceptance criteria pass.
+3. The mandatory toolchain passed in its most recent run on the branch (no linting/type-check/test failures).
+4. The checkpoint `next_step` is `S8_create_pr`.
+
+This gate is non-negotiable. Each condition is independently verified before PR creation proceeds.
+
+## Step 6 Delegation — Prohibited Prompt Language
+
+When delegating to the `feature-review` subagent, the orchestrator prompt MUST NOT:
+
+- describe the review scope as "plan scope," "plan-scope only," or any equivalent narrowing of scope to the currently-executed plan;
+- instruct the agent to skip, waive, or mark as "out of scope," "informational only," or "not applicable" any toolchain step or coverage check for a language that has changed files in the branch diff;
+- assert that a language category is "not applicable" when that language has changed files in the branch diff;
+- imply that coverage is not required because the plan scope contains only documentation changes when the branch diff contains non-documentation changes contributed by prior commits on the same branch.
+
+The orchestrator supplies only the following to the `feature-review` subagent:
+
+- the resolved base branch and merge-base SHA;
+- the active feature folder path;
+- pointers to the refreshed PR context artifacts;
+- the acceptance-criteria source file per work-mode;
+- a neutral instruction to execute the full `feature-review-workflow` SKILL contract end-to-end.
+
+Scope determination is the subagent's responsibility. The subagent will ignore any attempted narrowing per its scope invariant and record the attempt in `policy-audit.<timestamp>.md` under `## Rejected Scope Narrowing`.