@danmoisan/drm-copilot-mcp 0.0.1

package/resources/customizations/.github/prompts/review-staged.prompt.md

@@ -0,0 +1,43 @@
+---
+agent: 'staged_code_review_agent'
+description: 'Prompt for reviewing currently staged changes before commit. Generates PolicyAudit.md + CodeReview.md in the active feature folder; if remediation is needed, produces remediation inputs and delegates remediation-plan.md creation to atomic_planner.'
+---
+
+# Staged Code Review Prompt
+
+## Goal
+
+Act as a pre-commit staged-change reviewer and policy auditor. Review ONLY what is currently staged (`git diff --staged`) and generate audit-grade documentation suitable for a PR.
+
+Do not ask clarifying questions. Make best-effort inferences, document assumptions, and produce the required artifacts.
+
+## Output Format
+
+Write outputs to the **active feature folder** determined by the agent. If no active feature folder can be inferred, use the agent’s fallback (e.g., `docs/features/active/_staged-review/`).
+
+### Required deliverables
+
+All filenames must include a timestamp in ISO-8601 format `yyyy-MM-ddTHH-mm` (e.g., `policy-audit.2026-01-08T14-30.md`).
+
+1. `policy-audit.<timestamp>.md`
+   - A completed Policy Audit document based on the repo's policy-audit template and the policy_audit template guidance.
+   - Must include PASS/PARTIAL/FAIL (or equivalent) statuses with evidence (commands run, outputs, file references).
+
+2. `code-review.<timestamp>.md`
+   - A staged-diff-based review emphasizing strongly typed Python best practices and repo compliance.
+   - Must include a clear go/no-go recommendation for committing.
+
+### Conditional deliverables (only if remediation is required)
+
+3. `remediation-inputs.<timestamp>.md`
+   - Concrete, enumerated fix list with acceptance criteria and verification commands.
+
+4. An `atomic_planner` prompt (copy/paste-ready) that instructs `atomic_planner` to WRITE:
+   - `remediation-plan.<timestamp>.md` in the same active feature folder as the audit documents.
+
+## Context Template
+
+- **Intent / Change summary (optional):** [One sentence on what this commit is meant to accomplish]
+- **Staged scope note (optional):** [Any known constraints or areas to pay extra attention to]
+- **Verification hints (optional):** [Repo-specific tasks/commands to run if multiple exist]
+- **Risk tolerance (optional):** [e.g., “fail if any PARTIAL”, or “allow PARTIAL with remediation plan”]

package/resources/customizations/.github/prompts/update_status.prompt.md

@@ -0,0 +1,68 @@
+---
+agent: 'status_updater_agent'
+description: 'Synchronize epic/feature status: check off delivered plan tasks, reconcile docs vs issues, and document acceptance-criteria evidence. Derives all paths from EpicRootFolder using the same epic directory rules as epic review.'
+---
+
+# Update Status Prompt
+
+## Goal
+
+Synchronize epic and feature status across:
+- atomic plans (`plan.<timestamp>.md`) where items are unchecked despite delivery
+- documentation (`issue.md`, `spec.md`, `user-story.md`)
+- GitHub Issues (read-only by default; optional mutation via gh CLI)
+
+If ALL acceptance criteria in `spec.md` and `user-story.md` are delivered, document evidence inside those files.
+
+Do not ask clarifying questions. Make best-effort inferences, record assumptions, and only mark items complete when objective evidence exists.
+
+## Inputs (required)
+
+- **Epic root folder (required):** `${input:EpicRootFolder}`
+  - Example: `docs/features/active/2026-02-02-some-epic-47`
+
+## Optional inputs
+
+- **Allow GitHub mutations (optional):** `${input:AllowGitHubMutations:true|false}`
+  - Default behavior is **false** (no remote changes).
+  - If true, the agent may use `gh` CLI to update remote issue state/content only if authenticated and safe.
+
+## What must be derived from the epic root
+
+From the epic root folder contents:
+- Read `initiative.md`, `issue.md`, `orchestration.md` (if present)
+- Enumerate each feature subfolder
+- For each feature:
+  - If version folders exist (`v1`, `v2`, ...), select highest `vN` as current
+  - Otherwise treat the feature root as current
+  - Select latest `plan.<timestamp>.md` in the current scope (max ISO timestamp `yyyy-MM-ddTHH-mm`)
+  - Read `issue.md`, `spec.md`, `user-story.md`, and the selected plan (best-effort)
+
+## Outputs
+
+Write outputs to the epic root folder `${input:EpicRootFolder}`.
+
+All filenames must include a timestamp in ISO-8601 format `yyyy-MM-ddTHH-mm`.
+
+### Required deliverable
+
+1) `status-sync.<timestamp>.md`
+- Run metadata and summary
+- Plans updated (which files, which tasks checked, evidence notes)
+- Docs updated (issue/spec/user-story changes)
+- Issue/doc synchronization outcomes
+- Remote issue actions (if enabled) OR recommended gh commands
+- Blockers/gaps where evidence was insufficient
+
+### In-place updates (evidence-driven)
+
+- Update relevant `plan.<timestamp>.md` files:
+  - check off `[ ]` -> `[x]` only when evidence supports it
+  - add compact evidence notes under checked items
+
+- Update `issue.md` files:
+  - add/refresh “Sync Summary (as of <timestamp>)” + preserve prior notes
+
+- Update `spec.md` and `user-story.md`:
+  - if ALL acceptance criteria are evidenced, append “Acceptance Criteria Evidence (as of <timestamp>)”
+  - otherwise (optional) append partial evidence + open criteria list without claiming delivery

package/resources/customizations/.github/skills/README.md

@@ -0,0 +1,26 @@
+# Skills Taxonomy
+
+## Taxonomy
+
+Skills live under `.github/skills/<skill-name>/SKILL.md` and define reusable guidance that can be shared across agents and prompts. Each skill directory contains a single canonical `SKILL.md` file and optional supporting assets (kept minimal).
+
+## Frontmatter Requirements
+
+Every `SKILL.md` must include YAML frontmatter with:
+- `name`: the canonical skill name (kebab-case recommended).
+- `description`: a concise summary of the skill’s purpose.
+
+## Canonical Location
+
+Reusable guidance must be authored once in its canonical skill file. Agents and prompts should reference the canonical skill instead of duplicating its content. Canonical references should point to the full path of the skill, for example:
+
+- `.github/skills/feature-review-workflow/SKILL.md`
+
+## Examples
+
+```yaml
+---
+name: feature-review-workflow
+description: Feature-branch review workflow: artifact generation, evidence storage, remediation handoff.
+---
+```

package/resources/customizations/.github/skills/acceptance-criteria-tracking/SKILL.md

@@ -0,0 +1,102 @@
+---
+name: acceptance-criteria-tracking
+description: 'Track and check off acceptance criteria in requirement source files (issue.md, spec.md, user-story.md) as they are delivered. Use when executing plans, reviewing features, or validating delivery to keep AC checkboxes current.'
+---
+
+# Acceptance Criteria Tracking
+
+Shared protocol for identifying, tracking, and checking off acceptance criteria (AC) in their source requirement files as work is delivered and verified.
+
+## When to Use This Skill
+
+Use this skill when:
+- Executing an atomic plan that delivers work satisfying acceptance criteria.
+- Reviewing a feature branch and verifying acceptance criteria.
+- Validating small-path or large-path delivery against requirement files.
+- Any agent completes work that satisfies one or more acceptance criteria from `issue.md`, `spec.md`, or `user-story.md`.
+
+## AC Source Resolution (by Work Mode)
+
+Resolve the authoritative acceptance-criteria source file(s) using the work-mode marker from `issue.md`, per the mode rules in `feature-promotion-lifecycle` and `atomic-plan-contract`:
+
+| Work Mode | AC Source File(s) |
+|---|---|
+| `minor-audit` | `issue.md` only |
+| `full-feature` | `spec.md` and `user-story.md` |
+| `full-bug` | `spec.md` only |
+| legacy `full` | normalize to `full-feature` for compatibility |
+| missing / malformed | fail closed to `full-feature` (`spec.md` + `user-story.md`) |
+
+Deterministic mode rule: use the persisted `- Work Mode: ...` marker from `issue.md` as the single source of truth. `full-feature` always means `spec.md` **and** `user-story.md`; `full-bug` always means `spec.md` **only**; legacy `full` always normalizes to `full-feature`.
+
+For `minor-audit`, require an explicit `## Acceptance Criteria` section in `issue.md`. Do not treat other `issue.md` checkbox sections as acceptance criteria for `minor-audit`.
+
+When multiple AC source files exist, track checkboxes in **each** applicable file independently.
+
+## AC Identification
+
+Acceptance criteria are markdown checkbox items within AC source files.
+
+Deterministic heading rule:
+- For `minor-audit`, acceptance criteria MUST live under the exact heading `## Acceptance Criteria` in `issue.md`.
+- For other work modes, headings such as `## Acceptance Criteria`, `### Acceptance Criteria`, or `## Done When` may still be used when they are the authoritative AC source file.
+
+AC items use the standard markdown checkbox format:
+- `- [ ] <criterion text>` (not yet delivered)
+- `- [x] <criterion text>` (delivered and verified)
+
+If the explicit `minor-audit` section is missing, fail closed instead of guessing from other issue sections. If AC items are not in checkbox format (e.g., numbered lists or prose), do NOT reformat them. Instead, note their status in the agent's own tracking artifacts (plan checklist, feature-audit, etc.) and document that the source file uses a non-checkbox format.
+
+## Check-Off Protocol
+
+### Rules (non-negotiable)
+
+1. **Evidence before check-off**: Only mark an AC item `[x]` after the work satisfying it has been **implemented and verified** (e.g., tests pass, toolchain clean, code reviewed).
+2. **One-at-a-time**: Check off each AC item individually as the corresponding work is verified. Do not batch-check items without individual verification.
+3. **Preserve text**: When checking off, change only `- [ ]` to `- [x]`. Do not modify the criterion text.
+4. **Leave unmet items unchecked**: If an AC item cannot be fully delivered or verified, leave it as `- [ ]` and document the gap in the appropriate artifact (plan checklist, remediation inputs, or feature-audit).
+5. **No phantom criteria**: Do not add new AC items to source files. AC items are authored by planning/scoping agents, not by executors or reviewers.
+
+### When Executors Check Off AC
+
+During plan execution, after completing a task whose work satisfies an acceptance criterion:
+
+1. Identify which AC item(s) in the resolved source file(s) are satisfied by the completed task.
+2. Verify the work meets the criterion (task acceptance criteria passed, tests pass, etc.).
+3. Update the AC source file(s): change `- [ ]` to `- [x]` for the satisfied criterion.
+4. Report the check-off in the task's progress output (e.g., "Checked off AC: `<criterion text>` in `issue.md`").
+
+Timing: Check off AC items as soon as the corresponding plan task passes verification — do not defer all AC updates to the end of plan execution.
+
+### When Reviewers Check Off AC
+
+During feature review (feature-audit phase):
+
+1. For each AC item evaluated as **PASS** in the feature-audit evaluation table, check it off in the source file(s) if not already checked.
+2. For items evaluated as **PARTIAL**, **FAIL**, or **UNVERIFIED**, leave them unchecked and document the gap.
+3. Report any newly checked-off items in the feature-audit artifact.
+
+### When Orchestrators Enforce AC Tracking
+
+Orchestrators do not directly check off AC items. Instead:
+
+1. Ensure delegated executors and reviewers reference this skill.
+2. After executor or reviewer completion, verify that AC source files reflect delivered work (spot-check; do not re-execute verification).
+3. If AC items remain unchecked after all delegated work completes, flag them in the orchestration summary as outstanding acceptance criteria.
+
+## AC Status Summary (Required at Completion)
+
+At the end of plan execution or feature review, report an AC summary:
+
+```
+### Acceptance Criteria Status
+- Source: <file path(s)>
+- Total AC items: <N>
+- Checked off (delivered): <M>
+- Remaining (unchecked): <N - M>
+- Items remaining: <list of unchecked criterion texts, if any>
+```
+
+This summary must appear in:
+- The executor's final completion report (after last plan task).
+- The reviewer's feature-audit artifact (Phase F or equivalent).

package/resources/customizations/.github/skills/atomic-plan-contract/SKILL.md

@@ -0,0 +1,174 @@
+---
+name: atomic-plan-contract
+description: 'Atomic plan format and toolchain contract shared by planning and execution agents. Use when generating, validating, or executing atomic plans with Phase 0, baseline capture, and final QA loops.'
+---
+
+# Atomic Plan Contract
+
+Shared rules for atomic plan formatting, Phase 0 requirements, baseline capture, and final QA loops.
+
+## When to Use This Skill
+
+Use this skill when:
+- Creating or validating atomic plans.
+- Executing plans with strict format requirements.
+- Enforcing Phase 0 policy reading + baseline capture and final QA loops.
+
+## Canonical Plan Format
+
+- Phase headings must be: `### Phase N — <Title>`
+- Tasks must start with: `- [ ] [P#-T#]` (or `[x]` for completed)
+- Task IDs must match their phase and be sequential per phase.
+- Plans must pass the `validate_orchestration_artifacts` MCP tool with `artifact_type: "plan"` and `artifact_path: <plan-path>` before they can be reported as approved.
+
+## Short-Path Minimal Plan Contract
+
+When orchestration selects short path, a minimal plan is still mandatory and must include these blocks:
+
+1) Baseline capture block
+- policy reads in required order,
+- baseline toolchain/test state capture for each language that has explicit baseline command tasks in the plan.
+- required artifacts:
+	- a Phase 0 policy-read evidence artifact in the canonical evidence location defined by `evidence-and-timestamp-conventions`
+	- one baseline artifact per baseline command step (no aggregate-only baseline artifact)
+	- each baseline step artifact MUST include: `Timestamp:`, `Command:`, `EXIT_CODE:`, `Output Summary:`
+	- baseline test-step artifacts for languages with mandatory coverage policy MUST include numeric coverage headline values in `Output Summary:` (baseline percent and, when applicable, targeted module/new-code percent).
+
+2) Delegated implementation block
+- explicit handoff task to the small-path implementation engineer,
+- acceptance criteria for implementation completion.
+
+3) Final QC block
+- full language-appropriate QA loop (format → lint → type-check when applicable → test),
+- rerun behavior when any step changes files or fails.
+- one final-QC artifact per QC command step (no aggregate-only final-QC artifact)
+- each final-QC step artifact MUST include: `Timestamp:`, `Command:`, `EXIT_CODE:`, `Output Summary:`
+- final-QC test commands for languages with mandatory coverage policy MUST run in coverage mode and record numeric post-change coverage values in `Output Summary:`.
+- final-QC command tasks that are present in the approved plan MUST execute their stated commands; `SKIPPED` is invalid unless the task text itself explicitly authorizes a skip condition.
+
+4) Reduced audit block
+- explicit post-implementation small-audit handoff,
+- reduced artifact checks required by short-path policy.
+
+## Minimal-Audit Directive Contract (Small Path)
+
+For short-path planning handoffs, orchestrators MUST include:
+- `DIRECTIVE: MINIMAL-AUDIT PLAN REQUIRED`
+
+Required planner outputs for this directive:
+- plan MUST use `${feature-folder}/issue.md` as sole requirements source,
+- plan MUST require `${feature-folder}/issue.md` to contain an explicit `## Acceptance Criteria` section and MUST treat only that section as the minor-audit AC source,
+- plan MUST NOT require `spec.md`/`user-story.md`/`research.md`,
+- plan MUST include exactly 3 phases:
+	- Phase 0 baseline capture,
+	- Phase 1 placeholder for constrained small-path implementation,
+	- Phase 2 final QC loop,
+- final-QC command tasks in the generated plan MUST be unconditional when present; no IN_SCOPE/OUT_OF_SCOPE branches and no SKIPPED completion path unless the task text explicitly authorizes a skip branch,
+- planner MUST return `plan-path` and final preflight signal.
+
+## Phase-0-Only Execution Contract (Small Path)
+
+After preflight all-clear on the minimal-audit plan:
+- orchestrator MUST delegate to executor to run Phase 0 only,
+- orchestrator MUST checkpoint Phase 0 evidence before branching.
+
+Branching after Phase 0:
+- `manual bootstrap` → save state and stop for manual resume,
+- otherwise continue with constrained small-path development, then executor validation, then reduced audit/remediation loop.
+
+## Phase 0 Requirements
+
+Phase 0 must include tasks to read policy files in the order defined in `policy-compliance-order`.
+
+Phase 0 must also capture baseline toolchain results for the languages touched. Baseline artifact conventions (location + required fields) are defined in `evidence-and-timestamp-conventions`.
+
+For short-path/minimal-audit plans, Phase 0 evidence is incomplete unless both artifacts exist:
+- `phase0-instructions-read.md` with at least: `Timestamp:`, `Policy Order:`, and explicit list of files read.
+- baseline command-step artifacts with at least: `Timestamp:`, `Command:`, `EXIT_CODE:`, `Output Summary:` for each baseline check executed.
+- approved-plan checklist state MUST remain unchecked for any Phase 0 task whose artifact is absent or whose artifact fields are incomplete.
+
+`Output Summary:` is mandatory for each command-step artifact and must concisely summarize the essential result signal (for example: pass/fail status, key counts, coverage headline, or primary diagnostic).
+
+## Coverage Evidence Contract (Mandatory when policy requires coverage)
+
+For any language in scope where repository policy requires coverage validation:
+
+- The approved plan MUST include explicit baseline and final-QC coverage capture tasks.
+- Baseline and final-QC artifacts MUST record numeric coverage values (not placeholders such as `UNVERIFIED`).
+- Where policy requires no-regression and new-code thresholds, the plan MUST include a delta/threshold verification task that reports:
+	- baseline coverage,
+	- post-change coverage,
+	- new/changed-code coverage.
+- If required coverage values are unavailable, the plan outcome MUST be remediation-required and MUST NOT be reported as PASS.
+
+## Final QA Loop (Required for Code/Test Changes)
+
+Run the full toolchain loop for each applicable language in order:
+1) Formatting
+2) Linting
+3) Type checking (if applicable)
+4) Testing
+
+For languages with mandatory coverage policy, step 4 must use coverage-enabled test commands and persist numeric coverage evidence.
+
+If any step fails or changes files, restart the loop from step 1 until a clean pass completes.
+
+## No-SKIPPED Rule for Planned Command Tasks
+
+For command-bearing tasks in approved plans (especially Phase 2 final-QC tasks):
+- if the task exists in the plan, the command must be executed and recorded,
+- `EXIT_CODE: SKIPPED` MUST NOT be used as a passing outcome,
+- exceptions are allowed only when the task text itself explicitly contains a skip branch and that branch is intentionally approved in requirements.
+
+## Expect-Fail Test Tasks
+
+Any regression test task expected to fail must be tagged with `[expect-fail]` and include an auditable evidence artifact per `evidence-and-timestamp-conventions`.
+
+## Preflight Validation (Planner ↔ Executor)
+
+When validating or handing off plans for execution:
+- Use the directive line: `DIRECTIVE: PREFLIGHT VALIDATION ONLY`.
+- Require one of the exact signals:
+	- `PREFLIGHT: ALL CLEAR`
+	- `PREFLIGHT: REVISIONS REQUIRED`
+- If revisions are required, provide a precise plan delta and repeat validation until all clear.
+- If the required planner ↔ executor handoff cannot be started or completed, stop and report blocked state; do not self-approve the plan.
+
+## Validator Gate (Mandatory)
+
+Before a plan can be treated as approved:
+
+- run the `validate_orchestration_artifacts` MCP tool with `artifact_type: "plan"` and `artifact_path: <plan-path>`,
+- reject the plan if that validator exits non-zero,
+- do not treat human-readable summaries as a substitute for validator success.
+
+## Plan-Path Continuity Contract (Mandatory)
+
+When a caller provides an explicit target plan file path (for example `${plan-path}` or `${file}`):
+
+- Planner MUST update that exact file in place.
+- Planner MUST reuse the same file for all preflight revision iterations.
+- Planner MUST NOT create additional timestamped sibling files (for example `plan.<timestamp>.md`) during the same planning cycle.
+
+If the provided path does not exist, it may be created once, then reused for all subsequent revisions in that cycle.
+
+## Mode source precedence (Mandatory)
+
+When a plan is generated or validated from a feature folder, resolve selected mode in this order:
+
+1) Persisted marker in `issue.md` metadata block:
+	- `- Work Mode: minor-audit`
+	- `- Work Mode: full-feature`
+	- `- Work Mode: full-bug`
+2) Legacy compatibility marker `- Work Mode: full` resolves to `full-feature`
+3) Explicit workflow override only when repo policy allows and only when reconciled against `issue.md`
+4) Fail closed to `full-feature` when marker is missing or malformed
+
+## Mode-Specific Mandatory Plan Gates
+
+- `minor-audit` plans MUST include baseline evidence tasks, targeted verification evidence tasks, and end-state evidence tasks.
+- `minor-audit` plans MUST require `${feature-folder}/issue.md` to contain an explicit `## Acceptance Criteria` section; do not infer acceptance criteria from other `issue.md` sections.
+- `minor-audit` plans MUST NOT treat missing `spec.md` or `user-story.md` as automatic blockers.
+- `minor-audit` execution/validation/audit MUST fail closed when `spec.md` or `user-story.md` exists unexpectedly in the active folder, when the explicit `## Acceptance Criteria` section is missing from `issue.md`, when required Phase 0 artifacts are missing, or when checklist state contradicts evidence on disk.
+- `full-feature` plans MUST enforce full-document expectations (`spec.md` + `user-story.md`) and full QA loop obligations.
+- `full-bug` plans MUST enforce spec-driven expectations (`spec.md` required, `user-story.md` optional/absent by default) and full QA loop obligations.

package/resources/customizations/.github/skills/csharp-change-budget-router/SKILL.md

@@ -0,0 +1,48 @@
+---
+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` (or `.github/prompts/orchestrate-csharp-work.prompt.md`).
+
+## Documentation Expectations
+
+Record in response/logs:
+- estimated production file count,
+- chosen path (`small`/`large`),
+- rationale summary (1-3 bullets).

package/resources/customizations/.github/skills/csharp-orchestration-state-machine/SKILL.md

@@ -0,0 +1,57 @@
+---
+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`
+
+## 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/customizations/.github/skills/evidence-and-timestamp-conventions/SKILL.md

@@ -0,0 +1,135 @@
+---
+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.
+
+## 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).