@danmoisan/drm-copilot-mcp 0.0.1

package/resources/codex-and-agents-customizations/.agents/skills/make-skill-template/SKILL.md

@@ -0,0 +1,152 @@
+# Converted skill
+
+Applied rewrites:
+- None
+
+---
+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/codex-and-agents-customizations/.agents/skills/orchestrate/SKILL.md

@@ -0,0 +1,143 @@
+# Converted skill
+
+Applied rewrites:
+- Rewrite merged standing-guidance source paths to the native AGENTS.md target.
+- Rewrite Claude skill paths to shared skill paths.
+- Rewrite Claude rules-directory references to the native skill root.
+
+---
+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 `AGENTS.md` for repository tone policy and architectural context.
+2. Read applicable `.agents/skills/` files for the languages in scope.
+3. Read the policy files listed in the compliance reading order section of `AGENTS.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
+- `commit-steward` — writes commit messages from commit-context 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 `.agents/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. Run MCP tool `collect_commit_context` and capture the returned on-disk artifact path.
+3. Delegate to `commit_steward` using that commit-context artifact as the authoritative staged-change input.
+4. Commit using the generated message: `git commit -m "<generated message>"`.
+5. 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. Read the exact terminal status lines from the review result.
+2. If the result does not include `REVIEW_STATUS: PASS` or `REVIEW_STATUS: REMEDIATION_REQUIRED`, stop and record blocked state.
+3. If the result is `REVIEW_STATUS: PASS`, advance to the PR creation gate.
+4. If the result is `REVIEW_STATUS: REMEDIATION_REQUIRED`, require both `REMEDIATION_INPUTS: <path>` and `REMEDIATION_PLAN: <path>` and then enter the remediation loop.
+
+## 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 plan of record:** Use the exact `REMEDIATION_PLAN: <path>` returned by the review as the starting plan of record for the loop.
+- **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 by re-delegating to `atomic-planner` against the same remediation-plan path 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`), run MCP tool `collect_commit_context`, delegate to `commit_steward` using the resulting artifact, and commit with the generated message. Advance to R4 only after a successful commit.
+- **R4 — Re-audit:** Refresh PR context via MCP tool `collect_pr_context`, then 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 returns `REVIEW_STATUS: PASS`, 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.
+   Equivalent deterministic gate: the latest review returned `REVIEW_STATUS: PASS`.
+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`.

package/resources/codex-and-agents-customizations/.agents/skills/orchestrator-workflow/SKILL.md

@@ -0,0 +1,317 @@
+---
+name: orchestrator-workflow
+description: 'Coordinate a feature or bug request from intake through promotion, planning, execution, validation, and review by selecting the correct small or large path and delegating to migrated Codex specialists when available.'
+---
+
+# Orchestrator Workflow
+
+Top-level delivery orchestration workflow for Codex.
+
+## Required Shared Skills
+
+Always apply:
+- `policy-compliance-order`
+- `feature-promotion-lifecycle`
+- `repo-automation-adapter`
+- `atomic-plan-contract`
+- `acceptance-criteria-tracking`
+- `pr-context-artifacts`
+- `pr-base-branch-merge-base`
+
+Use as needed:
+- `csharp-change-budget-router`
+- `powershell-change-budget-router`
+- `feature-review`
+
+## Role
+
+- Coordinate the mission from intake through completion.
+- Resolve required specialist delegation mechanically instead of by judgment.
+- Required delegated specialists:
+  - `atomic-planner`
+  - `atomic-executor`
+  - `feature-reviewer`
+  - `commit-steward`
+- Deterministic availability rule:
+  - if the host exposes `spawn_agent`, treat all four required delegated specialists as available,
+  - do not infer unavailability from missing nicknames, missing prior agent instances, or lack of a dedicated launcher alias.
+- Required delegated steps MUST delegate or stop execution.
+- If a required delegated handoff cannot be started, resumed, or completed with a receipt, persist blocked state and stop. Do not perform that step directly.
+- Direct local execution is allowed only for workflow steps that are not designated below as required delegated handoffs.
+
+## Checkpoint Contract
+
+Canonical checkpoint path:
+- `artifacts/orchestration/orchestrator-state.json`
+
+Persist and reuse these fields exactly:
+- `objective`
+- `change_budget_estimate`
+- `path_selected`
+- `promotion-type`
+- `short-name`
+- `relativeFile`
+- `long-name`
+- `issue-num`
+- `feature-folder`
+- `work-mode`
+- `plan-path`
+- `review-status`
+- `remediation-inputs-path`
+- `remediation-plan-path`
+- `remediation-pass`
+- `commit-context-path`
+- `pr-context-base-branch`
+- `completed_steps`
+- `next_step`
+- `last_updated`
+- `step5_status`
+- `step6_status`
+- `step7_status`
+- `step8_status`
+- `step9_status`
+- `step10_status`
+- `delegation_receipts`
+- `blocked_reason`
+
+For small-path runs, also persist:
+- `bootstrap_mode`
+- `phase0_execution_summary`
+- `small_path_qc_summary`
+- `small_path_audit_artifacts`
+- `resume_after_manual_bootstrap`
+
+Status enums:
+- `step5_status` / `step6_status` / `step7_status` / `step8_status` / `step9_status` / `step10_status` MUST use one of:
+  - `not-applicable`
+  - `pending`
+  - `delegated`
+  - `verified`
+  - `blocked`
+
+Blocked-reason enum:
+- `blocked_reason` MUST be one of:
+  - `none`
+  - `checkpoint_conflict`
+  - `lifecycle_preconditions_missing`
+  - `spawn_agent_unavailable`
+  - `delegation_launch_failed`
+  - `delegate_no_receipt`
+  - `delegate_contract_incomplete`
+  - `validator_failed`
+  - `user_requested_stop`
+  - `review_status_missing`
+  - `commit_context_missing`
+  - `no_staged_changes`
+
+Delegation receipt schema:
+- `delegation_receipts` MUST be a list of objects with:
+  - `step`
+  - `agent_name`
+  - `agent_id`
+  - `skill_source`
+  - `started_at`
+  - `completed_at`
+  - `result_signal`
+  - `artifact_paths`
+
+Required-delegation step map:
+- small path:
+  - Step 5 -> `atomic-planner`
+  - Step 6 -> `atomic-executor`
+  - Step 9 -> `atomic-executor`
+  - Step 10 -> `feature-reviewer`
+- large path:
+  - Step 7 -> `atomic-planner`
+  - Step 8 -> `atomic-executor`
+  - Step 9 -> `feature-reviewer`
+- remediation planning:
+  - review-triggered remediation planning -> `atomic-planner`
+  - remediation preflight clearance -> `atomic-executor`
+  - remediation execution -> `atomic-executor`
+  - remediation commit message -> `commit-steward`
+  - remediation re-review -> `feature-reviewer`
+
+## Deterministic Handoff Result Contract
+
+Do not advance on summaries alone when an exact result signal is required.
+
+- feature review result:
+  - `REVIEW_STATUS: PASS`
+  - `REVIEW_STATUS: REMEDIATION_REQUIRED`
+  - `FEATURE_FOLDER: <path>`
+  - `POLICY_AUDIT: <path>`
+  - `CODE_REVIEW: <path>`
+  - `FEATURE_AUDIT: <path>`
+  - `REMEDIATION_INPUTS: <path-or-NONE>`
+  - `REMEDIATION_PLAN: <path-or-NONE>`
+- remediation preflight result:
+  - `PREFLIGHT: ALL CLEAR`
+  - `PREFLIGHT: REVISIONS REQUIRED`
+- commit-steward result:
+  - one fenced `text` code block only
+
+If an exact signal or required path field is missing, set the relevant step to `blocked`, set `blocked_reason` to `delegate_contract_incomplete`, and stop.
+
+## Resume Rules
+
+1. Read the checkpoint first when it exists.
+2. If the recorded mission is incomplete, resume from `next_step`.
+3. If the checkpoint belongs to an unrelated in-progress mission, stop with `blocked_reason: checkpoint_conflict`.
+4. Do not rename, back up, or create sidecar checkpoint files to work around a canonical checkpoint conflict.
+5. Restart only when the user explicitly requests restart.
+6. Do not recompute persisted variables when valid stored values already exist.
+
+## Routing Rules
+
+1. Estimate the likely touched production files and test files first.
+2. Determine the dominant implementation language.
+3. If the scope is primarily C#, use `csharp-change-budget-router`.
+4. If the scope is primarily PowerShell, use `powershell-change-budget-router`.
+5. If the scope is mixed-language, ambiguous, or unsupported by an existing change-budget router, fail closed to the large path.
+6. Treat any request outside the applicable small-path budget as large path.
+
+## Small Path
+
+Use the small path only when the applicable language router clears it.
+
+Required behavior:
+
+1. Set `${work-mode}` to `minor-audit`.
+2. Use `feature-promotion-lifecycle` as the source of truth for lifecycle variables, branch naming, and `${plan-path}` resolution.
+3. Route all promotion, issue, and feature-folder automation through `repo-automation-adapter`.
+4. Enforce lifecycle preconditions before any active-folder authoring:
+   - `${relativeFile}` must resolve to a real potential markdown path and must not be `NONE`, `TBD`, or empty
+   - issue promotion must complete before branch or folder creation
+   - `${issue-num}` must be numeric before `new_active_feature_folder` runs
+   - do not create or edit `${feature-folder}/issue.md`, `${feature-folder}/spec.md`, `${feature-folder}/user-story.md`, or `plan*.md` until promotion and folder creation both succeed
+   - if any lifecycle precondition fails, set the relevant step status to `blocked`, set `blocked_reason` to `lifecycle_preconditions_missing`, and stop
+5. Enforce minor-audit folder integrity:
+   - `${feature-folder}/issue.md` must exist
+   - `${feature-folder}/spec.md` must be absent
+   - `${feature-folder}/user-story.md` must be absent
+6. Spawn `atomic-planner` to create or revise the minimal plan at `${plan-path}`.
+   - Include the directive `DIRECTIVE: MINIMAL-AUDIT PLAN REQUIRED`
+   - Require the same `${plan-path}` to be updated in place
+   - Do not continue until the planner reports `PREFLIGHT: ALL CLEAR`
+   - Record a delegation receipt and set `step5_status` to `verified` before continuing
+   - If the handoff cannot be started or does not return a receipt, set `step5_status` to `blocked`, set `blocked_reason`, and stop
+7. Spawn `atomic-executor` to execute Phase 0 only.
+   - Record a delegation receipt and set `step6_status` to `verified` before branching
+   - If the handoff cannot be started or does not return a receipt, set `step6_status` to `blocked`, set `blocked_reason`, and stop
+8. If the request is manual bootstrap, persist the resume checkpoint and stop after Phase 0.
+9. Otherwise continue with constrained implementation:
+   - steps that are not modeled as required delegated handoffs may execute directly while staying within the approved plan and applicable repo policy
+10. Validate the delivered work against `${feature-folder}/issue.md` and persist plan or acceptance-criteria checkoffs before review.
+   - MUST delegate to `atomic-executor` for validation and checklist updates
+   - Record a delegation receipt and set `step9_status` to `verified` before continuing
+   - If the handoff cannot be started or does not return a receipt, set `step9_status` to `blocked`, set `blocked_reason`, and stop
+11. Run reduced audit:
+   - MUST delegate to `feature-reviewer`
+   - require the exact `REVIEW_STATUS` and artifact-path fields from the review result
+   - Record a delegation receipt and set `step10_status` to `verified` before continuing
+   - If the handoff cannot be started or does not return a receipt, set `step10_status` to `blocked`, set `blocked_reason`, and stop
+12. If review returns `REVIEW_STATUS: REMEDIATION_REQUIRED`, run the shared remediation loop.
+   - Treat the returned `REMEDIATION_INPUTS` and `REMEDIATION_PLAN` paths as mandatory inputs
+   - If any required remediation handoff cannot be started or does not return a receipt, set `blocked_reason` and stop
+
+## Large Path
+
+Use the large path for any request that exceeds or bypasses the small-path router.
+
+Required behavior:
+
+1. Set `${work-mode}` to:
+   - `full-feature` for feature work
+   - `full-bug` for bug work
+2. Use `feature-promotion-lifecycle` as the source of truth for lifecycle variables, branch naming, and `${plan-path}` resolution.
+3. Route all promotion, issue, and feature-folder automation through `repo-automation-adapter`.
+4. Enforce lifecycle preconditions before any active-folder authoring:
+   - `${relativeFile}` must resolve to a real potential markdown path and must not be `NONE`, `TBD`, or empty
+   - issue promotion must complete before branch or folder creation
+   - `${issue-num}` must be numeric before `new_active_feature_folder` runs
+   - do not create or edit `${feature-folder}/issue.md`, `${feature-folder}/spec.md`, `${feature-folder}/user-story.md`, or `plan*.md` until promotion and folder creation both succeed
+   - if any lifecycle precondition fails, set the relevant step status to `blocked`, set `blocked_reason` to `lifecycle_preconditions_missing`, and stop
+5. Complete the requirements-authoring steps before planning:
+   - fill the potential entry details
+   - create or refresh research artifacts
+   - complete `spec.md` and `user-story.md` when the selected work mode requires them
+6. Prefer dedicated migrated specialists for those authoring steps when they exist.
+7. When those specialists are not yet migrated, perform the authoring steps directly without changing template headings.
+8. Spawn `atomic-planner` to finalize `${plan-path}` and require `PREFLIGHT: ALL CLEAR`.
+    Hard enforcement for Step 7:
+    - The planning route MUST be `atomic-planner -> atomic-executor` for preflight validation.
+    - The planner MUST update `${plan-path}` in place and MUST NOT create additional `plan.*.md` files for revisions.
+    - The approved plan MUST include explicit Phase 0 baseline evidence tasks and explicit final-QA evidence or coverage tasks for each language in scope where policy requires them.
+    - Do not mark Step 7 complete until delegate output includes both a concrete `plan-path` and final `PREFLIGHT: ALL CLEAR`.
+    - Do not perform planning locally when this delegation cannot be started; set `step7_status` to `blocked`, set `blocked_reason`, and stop.
+    - Record a delegation receipt and set `step7_status` to `verified` only after delegate output and validator checks pass.
+9. Spawn `atomic-executor` to execute the approved plan.
+    Hard enforcement for Step 8:
+    - Do not mark Step 8 complete until execution output includes execution summary, QA summary, lint/type/test/coverage deltas, and numeric baseline/post/new-code coverage metrics where policy requires them.
+    - Do not accept PASS execution outcomes when required baseline or final-QA artifacts are missing, when checklist state is not backed by artifacts, or when coverage-bearing plan tasks remain unverified.
+    - Do not perform execution locally when this delegation cannot be started; set `step8_status` to `blocked`, set `blocked_reason`, and stop.
+    - Record a delegation receipt and set `step8_status` to `verified` only after delegate output and validator checks pass.
+10. Spawn `feature-reviewer` for post-implementation review.
+    Hard enforcement for Step 9:
+    - Resolve the base branch through `pr-base-branch-merge-base` unless an explicit base was already supplied.
+    - Load canonical PR-context artifacts and refresh them through `repo-automation-adapter` when they are missing or stale relative to the current branch state.
+    - Require the exact `REVIEW_STATUS` and artifact-path fields from the review result.
+    - Do not mark Step 9 complete until expected review artifacts are present on disk in `${feature-folder}`.
+    - Do not accept PASS review outcomes when required coverage fields are left unverified, when PR-context artifacts are missing or stale relative to the current branch state, or when required remediation artifacts are missing.
+    - Do not perform review locally when this delegation cannot be started; set `step9_status` to `blocked`, set `blocked_reason`, and stop.
+    - Record a delegation receipt and set `step9_status` to `verified` only after delegate output and validator checks pass.
+11. If review returns `REVIEW_STATUS: REMEDIATION_REQUIRED`, run the shared remediation loop until the latest review returns `REVIEW_STATUS: PASS`.
+    - remediation planning, preflight clearance, remediation execution, remediation commit-message generation, and re-review delegations are all mandatory; if any cannot be started, set `blocked_reason` and stop
+
+## Shared Remediation Loop
+
+Apply this loop after any required review returns `REVIEW_STATUS: REMEDIATION_REQUIRED`.
+
+1. Persist `review-status`, `remediation-inputs-path`, `remediation-plan-path`, and `remediation-pass` in the checkpoint.
+2. Delegate `atomic-executor` in validation-only mode against the exact `remediation-plan-path`.
+3. If the executor returns `PREFLIGHT: REVISIONS REQUIRED`, delegate `atomic-planner` to update the same `remediation-plan-path` in place and then repeat preflight clearance.
+4. Only after `PREFLIGHT: ALL CLEAR`, delegate `atomic-executor` to execute the remediation plan exactly as written.
+5. Stage all files with `git add -A`.
+6. If staging is empty after execution, set `blocked_reason` to `no_staged_changes` and stop.
+7. Use `repo-automation-adapter` to run MCP tool `collect_commit_context`, capture the returned on-disk artifact path as `commit-context-path`, and stop with `blocked_reason: commit_context_missing` if that path is unavailable.
+8. Delegate `commit-steward` using `commit-context-path` as the authoritative staged-change input.
+9. Commit the staged work with the exact message returned by `commit-steward`.
+10. Use `repo-automation-adapter` to refresh PR-context artifacts through MCP tool `collect_pr_context` with the resolved base branch.
+11. Delegate `feature-reviewer` again with the refreshed PR context.
+12. If the new review still returns `REVIEW_STATUS: REMEDIATION_REQUIRED`, increment `remediation-pass` and repeat the loop. Exit only when the latest review returns `REVIEW_STATUS: PASS`.
+
+## Completion Gates
+
+Do not claim mission completion until all of the following are true:
+
+- the selected path completed end to end
+- all required delegations completed with receipts
+- the checkpoint is updated with the final state
+- the canonical checkpoint path was used without sidecar replacement or backup substitution
+- `${relativeFile}` is a real promoted-input path and `${issue-num}` is numeric when lifecycle setup was required
+- `${feature-folder}` and `${plan-path}` are known when lifecycle setup was required
+- the approved plan is executor-compliant and references the required baseline and final-QA evidence tasks
+- required review artifacts exist on disk
+- small path has Phase 0 evidence plus reduced audit artifacts
+- large path has policy, code, and feature audit artifacts
+- required baseline and final-QA evidence artifacts referenced by the approved plan exist on disk
+- any required remediation artifacts exist on disk and the latest re-review is clean
+- any required remediation loop run also includes a remediation execution receipt, a remediation commit receipt, and a final `REVIEW_STATUS: PASS`
+- validator-backed checks for the approved plan, policy audit, code review, feature audit, and checkpoint state pass
+
+## Hard Constraints
+
+- Do not stop after one delegation when required downstream steps remain.
+- Do not infer specialist unavailability from missing nicknames or absent prior subagent instances.
+- Do not call `drmCopilotExtension.*` directly from this workflow.
+- Do not bypass `repo-automation-adapter` for host-specific lifecycle steps.
+- Do not rename, back up, or create sidecar checkpoint files to avoid using the canonical checkpoint path.
+- Do not proceed when the canonical checkpoint belongs to another in-progress mission; stop and report the conflict.
+- Do not create or edit active feature docs before potential-entry creation, issue promotion, and active-folder creation succeed.
+- Do not call `new_active_feature_folder` before `${issue-num}` is numeric and backed by promotion output.
+- Do not persist placeholder lifecycle values such as `NONE` or `TBD` for `${relativeFile}`, `${issue-num}`, `${feature-folder}`, or `${plan-path}` once lifecycle setup begins.
+- Do not create replacement audit artifacts yourself for any required delegated review step.
+- Do not execute required delegated steps locally as a fallback.
+- Do not accept stale PR-context artifacts, unsupported checklist checkoffs, or missing required evidence as PASS outcomes.
+- Do not claim completion without reporting the checkpoint path and the created or updated artifact paths.

package/resources/codex-and-agents-customizations/.agents/skills/policy-audit-template-usage/SKILL.md

@@ -0,0 +1,53 @@
+# Converted skill
+
+Applied rewrites:
+- None
+
+---
+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.