@danmoisan/drm-copilot-mcp 0.0.1

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

@@ -0,0 +1,67 @@
+# Converted skill
+
+Applied rewrites:
+- None
+
+---
+paths:
+  - "**/*.cs"
+  - "**/*.csproj"
+description: C#-specific toolchain and coding standards.
+---
+
+# C# Code Standards
+
+This rule file summarizes the C#-specific policies for this repository.
+
+## Toolchain
+
+1. **Formatting — CSharpier**: All C# source files must be formatted with CSharpier. Do not use `dotnet format`. Command: `dotnet tool run csharpier .` or `csharpier .`
+2. **Linting — .NET Analyzers**: C# code must pass Roslyn/.NET analyzer diagnostics. Command: `msbuild TaskMaster.sln /t:Build /p:Configuration=Debug /p:Platform="Any CPU" /p:EnableNETAnalyzers=true /p:EnforceCodeStyleInBuild=true`
+3. **Type Checking — Nullable Analysis**: Enable nullable reference types and fail on warnings. Command: `msbuild TaskMaster.sln /t:Build /p:Configuration=Debug /p:Platform="Any CPU" /p:Nullable=enable /p:TreatWarningsAsErrors=true`
+4. **Testing — MSTest + Moq + FluentAssertions**: Run tests with: `vstest.console.exe <test-assembly-paths> /EnableCodeCoverage`
+
+Run the toolchain in order: format → lint → type-check → test. Restart from step 1 if any step fails or changes files.
+
+## Coding Standards
+
+- **Naming**: `PascalCase` for types and public members. `camelCase` for locals and private fields/parameters.
+- **Null safety**: Keep nullable reference types enabled. Model optional values with nullable annotations and guard clauses.
+- **Composition over inheritance**: Keep classes cohesive and scoped to one responsibility. Favor composition unless polymorphism is a clear requirement.
+- **Async/await**: Use `async`/`await` for I/O-bound operations. Prefer `using`/`await using` for disposable resources.
+- **Exceptions**: Fail fast with explicit exceptions. Avoid broad `catch (Exception)` unless at a defined boundary with added context.
+- **Public surface**: Keep public API surface intentional and minimal. Prefer `internal` for non-public APIs.
+- **XML docs**: Public APIs should include XML documentation comments when behavior or contract is non-obvious.
+
+## Testing Standards
+
+- Use **MSTest** (`Microsoft.VisualStudio.TestTools.UnitTesting`) as the test framework.
+- Use **Moq** for mocking.
+- Prefer **FluentAssertions** for assertions; use MSTest `Assert` only when FluentAssertions is not practical.
+- Use `[TestClass]` and `[TestMethod]` attributes.
+- Follow Arrange–Act–Assert structure.
+- No external dependencies in unit tests.
+- Repository-wide line coverage must remain >= 80%.
+- Any new module, class, or method must reach >= 90% coverage.
+- Coverage regression on changed lines is a blocking finding.
+
+## Deterministic Test Rules
+
+Unit tests must not depend on network, mutable machine PATH or profile state, implicit working-directory assumptions, or external services. Use seam-based mocking for all external boundaries (processes, HTTP, filesystem, clocks). Tests must produce identical results in the IDE test runner and in CLI runs so local and CI behavior agree.
+
+## DI Seams
+
+Introduce the smallest seam that enables reliable unit testing. Apply in this order of preference:
+
+1. **Interface seam (preferred)** — extract boundary calls into narrow purpose-specific interfaces (for example, `IProcessRunner`, `IFileSystem`, `IClock`). Keep interfaces minimal.
+2. **Injectable delegate seam** — use a narrow `Func<>`/`Action<>` delegate for a single call path when a full interface is excessive. Default behavior must remain safe and deterministic.
+3. **Adapter seam for static or third-party APIs** — wrap the static or third-party call behind a small adapter so tests can mock the adapter with Moq.
+
+## Prohibited Behaviors
+
+- Broad refactors across unrelated projects or files.
+- Introducing heavy generic abstraction frameworks without need.
+- Creating analyzer debt and deferring cleanup.
+- Weakening assertions or relaxing test expectations to make tests pass.
+- Adding sleeps, retries, or timing hacks to mask flaky behavior.
+- Reporting success without running the required toolchain.

package/resources/codex-and-agents-customizations/.agents/skills/csharp-change-budget-router/SKILL.md

@@ -0,0 +1,94 @@
+# Converted skill
+
+Applied rewrites:
+- None
+
+---
+name: csharp-change-budget-router
+description: Budget-first routing contract for C# work: estimate production-file scope, choose small vs large path, enforce orchestration-first routing for larger changes, and use the VS Code extension command surface for promotion lifecycle steps when available.
+---
+
+# C# Change Budget Router
+
+Canonical guidance for deciding whether work should stay on the small path or escalate to the full C# orchestration workflow.
+
+## When to Use This Skill
+
+Use this skill when:
+- Intake starts from a natural-language C# 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.
+
+## Canonical Routing Rules
+
+1) Estimate rough change budget first based on likely **production C# files** touched.
+2) Route:
+- `1-3` production files (+ corresponding tests) → **small path** (`csharp-typed-engineer` direct mode).
+- `>3` production files or `>3` test files → **large path** (orchestration workflow with promotion/research/spec/planning/execution/review).
+
+## Orchestrated Small-Path Requirements
+
+When routed through `csharp-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 `csharp-typed-engineer` remains implementation-focused and does not replace orchestrator lifecycle steps.
+
+## Direct-Mode Rejection Rule
+
+If direct implementation is requested but estimated scope is `>3` production files:
+- Stop before implementation.
+- Return explicit routing instruction to invoke `csharp-orchestrator`.
+
+## Invocation Mode
+
+The `csharp-typed-engineer` worker supports two execution modes:
+
+- **Direct mode** (default): no handoff directive present. Strict overall change-budget limits apply per the routing rules above.
+- **Orchestrator handoff mode**: enabled only when the incoming request contains the exact line `DIRECTIVE: ORCHESTRATOR HANDOFF MODE`. Overall change-budget limits are lifted, but execution is allowed only when a complete context package is supplied.
+
+Required context package in orchestrator handoff mode:
+
+1. objective and expected outcome,
+2. `${promotion-type}` and `${issue-num}` when available,
+3. `${feature-folder}` path,
+4. issue doc path (`${feature-folder}/issue.md`),
+5. spec doc path (`${feature-folder}/spec.md`),
+6. user-story path (`${feature-folder}/user-story.md`) or explicit `NONE`,
+7. research artifact path(s),
+8. constraints, APIs, or invariants to preserve.
+
+If any required item is missing in orchestrator handoff mode, stop and request the missing context package fields before Phase A proceeds.
+
+## Per-Batch Cap
+
+In all modes, per-batch budget remains: at most **3 production files** and **3 test files** unless an explicit override is approved by the user. If no override is provided, the 3/3 per-batch limit applies. If a batch would exceed the cap, split it into smaller batches.
+
+## Orchestrator-Mode Delegation Chain
+
+When `csharp-typed-engineer` runs in orchestrator handoff mode, it must execute the following delegation chain and must not bypass it with direct implementation:
+
+1. Delegate to `atomic_planner` for an architecture plus testability plan only (no edits).
+2. Require planner output to include final `PREFLIGHT: ALL CLEAR` from the preflight validation loop.
+3. Delegate plan execution to `atomic_executor`.
+4. Delegate the final QA gate to `atomic_executor` per `csharp-qa-gate`.
+5. Delegate post-implementation review to `feature-review` per `feature-review-workflow`.
+
+Execution-start constraint: in orchestrator handoff mode, `csharp-typed-engineer` is routing-and-planning-only until the planner preflight loop returns `PREFLIGHT: ALL CLEAR`. Before that signal, it must not run any state-changing implementation command and must not edit production or test files directly. All implementation and QA execution must occur via delegated handoffs.
+
+Blocking rules in orchestrator mode:
+- If the incoming request does not include the exact directive line, stop and request a corrected orchestrator handoff.
+- If any delegation in the chain is skipped, treat the run as incomplete and do not report completion.
+- Do not claim completion unless the final report includes all artifact paths from the feature review step.
+
+## Documentation Expectations
+
+Record in response/logs:
+- estimated production file count,
+- chosen path (`small`/`large`),
+- rationale summary (1-3 bullets).

package/resources/codex-and-agents-customizations/.agents/skills/csharp-orchestration-state-machine/SKILL.md

@@ -0,0 +1,64 @@
+# Converted skill
+
+Applied rewrites:
+- None
+
+---
+name: csharp-orchestration-state-machine
+description: Checkpoint schema and resume protocol for long-running C# orchestration workflows.
+---
+
+# C# Orchestration State Machine
+
+Canonical checkpoint and resume behavior for orchestration agents running multi-step C# 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/csharp-orchestrator-state.json`
+
+Never create sidecar checkpoint files, suffixed variants, or backup files as active state. If checkpoint state is conflicted, stale, or belongs to another mission, stop and report the conflict instead of renaming or backing up the active checkpoint.
+
+## 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/codex-and-agents-customizations/.agents/skills/csharp-qa-gate/SKILL.md

@@ -0,0 +1,82 @@
+# Converted skill
+
+Applied rewrites:
+- Rewrite Claude skill paths to shared skill paths.
+
+---
+name: csharp-qa-gate
+description: Final QA gate for C# changes. Executes the full CSharpier -> .NET Analyzers -> Nullable Analysis -> MSTest toolchain, compares against a captured baseline, enforces zero-regression deltas, and produces the required reporting block before the agent declares the change complete.
+---
+
+# C# QA Gate
+
+Canonical procedure for the Phase D final quality gate that every C# change must pass before completion is reported.
+
+## When to Use This Skill
+
+Use this skill when:
+
+- `csharp-typed-engineer` is about to declare a change complete.
+- An executor has finished applying a planned batch and must verify zero regressions against the baseline captured in Phase A.
+- A reviewer needs to confirm the toolchain was actually run and produced a clean pass.
+
+## Required Inputs
+
+Before invoking this gate, the agent must have:
+
+- a baseline record produced in Phase A, containing analyzer findings, compiler/nullable diagnostics, MSTest pass/fail status, and per-file coverage status for the in-scope files,
+- 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. `dotnet tool run csharpier .`
+2. `msbuild TaskMaster.sln /t:Build /p:Configuration=Debug /p:Platform="Any CPU" /p:EnableNETAnalyzers=true /p:EnforceCodeStyleInBuild=true`
+3. `msbuild TaskMaster.sln /t:Build /p:Configuration=Debug /p:Platform="Any CPU" /p:Nullable=enable /p:TreatWarningsAsErrors=true`
+4. `vstest.console.exe <test-assembly-paths> /EnableCodeCoverage`
+
+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:
+
+- **Analyzer delta**: 0 new findings across the repository.
+- **Compiler / nullable delta**: 0 new diagnostics across the repository.
+- **MSTest delta**: 0 new failing tests.
+- **Per-file coverage delta**: coverage for every touched file is greater than or equal to the baseline for that file.
+- **Overall coverage delta** (when the repo enforces it): overall coverage is greater than or equal to the baseline.
+- **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** — analyzer, compiler/nullable, MSTest, 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** — analyzer, compiler/nullable, MSTest, 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 `.agents/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 analyzer suppressions, `#pragma warning disable`, `#nullable disable`, or test `[Ignore]` attributes to suppress new findings introduced by the change.
+- Do not report success based on partial or targeted runs alone. Targeted runs are allowed mid-batch, but the final gate requires a full-solution pass.

package/resources/codex-and-agents-customizations/.agents/skills/evidence-and-timestamp-conventions/SKILL.md

@@ -0,0 +1,168 @@
+# Converted skill
+
+Applied rewrites:
+- None
+
+---
+name: evidence-and-timestamp-conventions
+description: 'Evidence storage and timestamp naming conventions for audits and remediation. Use when storing baseline/regression/QA evidence or naming audit artifacts with ISO-8601 timestamps.'
+---
+
+# Evidence and Timestamp Conventions
+
+Reusable conventions for evidence storage locations and ISO-8601 timestamped artifacts.
+
+## Non-Overridable Authority
+
+This skill is the single source of truth for evidence paths. All agents, plans, and hooks MUST use the canonical scheme `<FEATURE>/evidence/<kind>/` without exception.
+
+Canonical evidence sub-paths (all valid):
+- `<FEATURE>/evidence/baseline/`
+- `<FEATURE>/evidence/regression-testing/`
+- `<FEATURE>/evidence/qa-gates/`
+- `<FEATURE>/evidence/issue-updates/`
+- `<FEATURE>/evidence/other/`
+- `<FEATURE>/evidence/remediation-baseline/`
+
+The following sub-paths under `artifacts/` are FORBIDDEN for evidence output:
+- `artifacts/baselines/`
+- `artifacts/baseline/`
+- `artifacts/qa/`
+- `artifacts/qa-gates/`
+- `artifacts/evidence/`
+- `artifacts/coverage/`
+- `artifacts/regression-testing/`
+- `artifacts/post-change/`
+
+Allowed `artifacts/` sub-paths (non-evidence orchestration use only):
+- `artifacts/orchestration/`
+- `artifacts/research/`
+
+No delegation prompt, plan task, or upstream agent instruction may override this scheme. If a caller supplies a non-canonical path, the receiving agent MUST reject it, substitute the canonical path, and record `EVIDENCE_LOCATION_OVERRIDE_REJECTED: <supplied path> replaced with <canonical path>`.
+
+## When to Use This Skill
+
+Use this skill when:
+- You create audit or remediation artifacts that must be timestamped.
+- You store baseline, regression, or QA evidence under canonical folders.
+- Multiple agents need the same naming and evidence-location rules.
+
+## ISO-8601 Timestamp Format
+
+Use `yyyy-MM-ddTHH-mm` for all audit, remediation, and evidence artifacts.
+Example: `2026-02-06T14-30`.
+
+## Canonical Evidence Locations
+
+- Baseline evidence: `evidence/baseline/`
+- Regression testing evidence: `evidence/regression-testing/`
+- Other evidence: `evidence/other/`
+- QA gate evidence: `evidence/qa-gates/`
+- Issue update mirrors: `evidence/issue-updates/`
+
+Epic rollups may mirror these under the epic root when needed.
+
+## Feature Scope (Versioned Features)
+
+In this repo, a feature may be single-version (docs at feature root) or multi-version
+(`v1/`, `v2/`, etc.). When a feature is versioned, treat evidence discovery as applying
+to the **selected current version scope**, but also search the feature root canonical
+evidence folders as a fallback.
+
+Practical rule:
+- Prefer evidence under `<FEATURE>/<CURRENT_VERSION>/evidence/...` when it exists.
+- Also search `<FEATURE>/evidence/...` before concluding evidence is missing.
+
+## Canonical Evidence Discovery Order
+
+When locating evidence artifacts for audits or plan reconciliation, use this order:
+
+1) `<FEATURE>/evidence/issue-updates/` (issue update mirrors)
+2) `<FEATURE>/evidence/regression-testing/`
+3) `<FEATURE>/evidence/other/`
+4) `<FEATURE>/evidence/qa-gates/`
+5) `<FEATURE>/evidence/baseline/`
+6) `<FEATURE>/evidence/remediation-baseline/`
+7) `<EPIC>/evidence/issue-updates/` (issue update mirrors)
+8) `<EPIC>/evidence/regression-testing/` (optional rollup)
+9) `<EPIC>/evidence/other/`
+10) `<EPIC>/evidence/qa-gates/` (optional rollup)
+11) `<EPIC>/evidence/baseline/` (optional rollup)
+12) `<EPIC>/evidence/remediation-baseline/` (optional rollup)
+
+Rule:
+- Use the list order by default for audit fidelity.
+- If the task is explicitly remediation reconciliation, you may prefer `remediation-baseline` over `baseline`, but still record the original baseline as the authoritative audit reference.
+
+If evidence or issue-update mirrors are found elsewhere, record it as non-canonical and include a remediation step to move/copy it into the first applicable canonical location.
+
+### Fail-before Requirements (Deterministic Check)
+
+When an acceptance criterion (AC) or plan item requires **fail-before / pass-after** evidence:
+
+- First, search for a failing run artifact in `<FEATURE>/evidence/regression-testing/`.
+- If no failing run exists (or it is structurally impossible), search for a **fail-before exception dossier**.
+
+Minimum required search pattern:
+- `fail-before-exception.*.md` (preferred name prefix)
+
+Only after checking both (failing run OR exception dossier) may you write a negative claim like
+"no fail-before evidence exists".
+
+## Evidence Artifact Schema (Machine-Checkable)
+
+When evidence artifacts are used for automated checking or plan reconciliation, include:
+- `Timestamp: <ISO-8601>`
+- `Command: <exact command>`
+- `EXIT_CODE: <int>`
+
+### Baseline Evidence Output Summary (Required)
+
+For baseline evidence artifacts stored under `evidence/baseline/`, include an output summary in addition to the schema fields above:
+- `Output Summary: <1–20 lines capturing the essential outcome>`
+
+The summary should be concise, human-readable, and include the most important result signal (e.g., “All checks passed”, “767 passed”, coverage total, or a brief error description).
+
+If a fail-before run is required but impossible, include a short exception dossier with:
+- `WhyFailingRunImpossible: <1–3 sentences>`
+- An alternative proof section (e.g., absence-of-test proof)
+
+Fail-before exception dossiers should be stored under `evidence/regression-testing/`.
+
+Preferred filename for fail-before exception dossiers:
+- `fail-before-exception.<timestamp>.md`
+
+If an exception dossier is present and schema-valid, it counts as satisfying the
+"fail-before" requirement for audit/plan reconciliation purposes.
+
+## Negative Evidence Claims (Absence Must Be Auditable)
+
+If you claim evidence is missing (e.g., "no exception dossier recorded"), you MUST also record:
+
+- `SearchScope:` the exact folder(s) searched (include both current-version scope and feature root when applicable)
+- `SearchPatterns:` the filename patterns used (e.g., `fail-before-exception.*.md`)
+- `SearchResult:` what was found (paths) or `none`
+
+This prevents false negatives caused by searching the wrong scope or using incomplete patterns.
+
+## Evidence-First Audit Writing
+
+When marking FAIL or PARTIAL in audit artifacts, include:
+- Concrete file + location (line/hunk/section when possible)
+- The violated rule or expected behavior
+- The verification command and its output (or why it could not be run)
+
+## Issue Update Mirroring (Canonical Location)
+
+When work involves updating a GitHub issue, create a local mirror artifact at:
+- `<FEATURE>/evidence/issue-updates/issue-<N>.<timestamp>.md`
+
+Required contents:
+- `Timestamp: <ISO-8601>`
+- The exact text intended/posted
+- `PostedAs: body` or `PostedAs: comment` (preferred), or `PostedAs: unknown`
+- If posted as a comment: the GitHub URL to the comment
+- If posted as an issue body update: the GitHub URL to the issue and `IssueUpdatedAt: <ISO-8601>`
+- If not posted: a `POSTING BLOCKED` header and the reason
+
+If `PostedAs: body`, mirror the same update into the local feature `issue.md` (current version folder if present; otherwise feature root).

package/resources/codex-and-agents-customizations/.agents/skills/execute-hard-lock/SKILL.md

@@ -0,0 +1,88 @@
+# Converted skill
+
+Applied rewrites:
+- Rewrite Claude agent manifest paths to Codex agent paths.
+- Rewrite remaining VS Code command IDs to semantic MCP tool usage.
+
+---
+name: execute-hard-lock
+description: Place the session in atomic execution mode bound to a specific plan-of-record. Resolves the hard-lock prompt via the drmCopilotExtension MCP tool, then delegates to the atomic-executor subagent with the resolved text. Use when a caller provides ${plan-path} and ${work-mode} and requires strict plan-following behavior.
+allowed-tools:
+  - mcp__drmCopilotExtension__resolve_execute_hard_lock_prompt
+  - Read
+---
+
+# Execute Hard Lock
+
+Thin wrapper that resolves the hard-lock prompt via the drmCopilotExtension MCP tool and hands the resolved text to the `atomic-executor` subagent as kickoff directives. The resolved prompt is the authoritative instruction set for the session; this skill does not duplicate its contents.
+
+## When to Use This Skill
+
+Use this skill when:
+
+- The caller provides an explicit plan file path (`${plan-path}`) and a selected work mode (`${work-mode}`).
+- Strict plan-following behavior is required (no replanning, no reordering, no bucket tasks).
+- The drmCopilotExtension MCP server is registered and reachable.
+
+## Inputs
+
+Required:
+
+- `plan-path` — absolute or repo-relative path to the plan-of-record markdown file.
+- `work-mode` — one of `minor-audit`, `full-feature`, `full-bug`. Legacy value `full` normalizes to `full-feature`. Missing or malformed values fail closed to `full-feature`.
+
+## Invocation Flow
+
+### 1. Resolve the Hard-Lock Prompt via MCP
+
+Call the extension's resolver as the first action:
+
+- Tool: `mcp__drmCopilotExtension__resolve_execute_hard_lock_prompt`
+- Parameters:
+  - `target` (required): the plan-of-record path (`${plan-path}`).
+  - `workspace_root` (optional): the workspace root. Omit to default to the current working directory.
+
+On success, the response contains an `artifacts` array whose first entry is the absolute path of a file containing the resolved hard-lock prompt (produced by the extension passing `--output` and `--quiet` to the bundled Python resolver).
+
+### 2. Read the Resolved Prompt
+
+Use the `Read` tool on the path returned in `artifacts[0]`. Treat the file contents as the authoritative hard-lock instruction set for this session.
+
+### 3. Delegate to atomic-executor
+
+Invoke the `atomic-executor` subagent via the Agent tool. Pass the resolved prompt text as the subagent's kickoff directive, followed by `${plan-path}` and `${work-mode}` as session context.
+
+The resolved prompt itself already instructs the subagent to perform the mandatory read-proof (`git rev-parse HEAD`, SHA-256 of the plan file, unchecked-task count), preflight validation, and `READY TO BEGIN FROM [P#-T#]` handshake before executing any task. This skill does not reissue those instructions locally — doing so would risk divergence from the canonical template.
+
+## Abort Conditions
+
+Stop immediately and report `BLOCKED: execute-hard-lock <cause>` in any of these cases. Do not reconstruct the hard-lock prompt from any other source and do not delegate to `atomic-executor` without a successful read in step 2.
+
+- MCP tool is not available or not permitted.
+- MCP response has `ok: false` or is otherwise malformed.
+- MCP response omits `artifacts` or `artifacts[0]`.
+- `Read` on the artifact path fails (file missing, unreadable, empty).
+
+## Equivalent Entry Points (Reference)
+
+The three entry points below all produce the same resolved hard-lock prompt for a given plan path. This skill always uses the MCP form:
+
+- MCP (used by this skill): `mcp__drmCopilotExtension__resolve_execute_hard_lock_prompt` with `target=<plan-path>`. The extension passes `--output artifacts/hard_lock_prompt.txt` and `--quiet` to the bundled Python resolver.
+- VS Code command: `@command:mcp__drmCopilotExtension__resolve_execute_hard_lock_prompt` (interactive; writes to stdout + clipboard, no file artifact).
+
+## Delegation Contract
+
+The `atomic-executor` subagent at [.codex/agents/atomic-executor.toml](.codex/agents/atomic-executor.toml) enforces the persistent execution-mode behaviors (anti-replanning, preflight-only blocking, persistence across turns, resume) and preloads the shared skills that support them:
+
+- `policy-compliance-order` — mandatory policy reading order.
+- `atomic-plan-contract` — plan format, Phase 0 requirements, preflight signals, validator gate, and mode-specific plan gates.
+- `acceptance-criteria-tracking` — AC check-off protocol and status summary format.
+- `evidence-and-timestamp-conventions` — baseline and final-QC artifact paths and required fields.
+
+## Prohibitions
+
+- Do not proceed without a successful MCP resolver response AND a successful `Read` of the artifact.
+- Do not reconstruct the hard-lock contract from any other source (not from this file nor from prior session memory).
+- Do not modify the resolved prompt text before passing it to `atomic-executor`.
+- Do not replan, reorder, or add tasks at this layer — the subagent owns that contract.
+- Do not create or read secrets unless explicitly authorized.