@danmoisan/drm-copilot-mcp 0.0.1

package/resources/customizations/.github/skills/feature-promotion-lifecycle/SKILL.md

@@ -0,0 +1,121 @@
+---
+name: feature-promotion-lifecycle
+description: Deterministic promotion workflow from potential feature/bug entry to issue, branch, active feature folder, and downstream spec/research handoffs. Prefer MCP server (drmCopilotExtension) tool invocations when the MCP server is reachable; use underlying scripts only as fallback.
+---
+
+# Feature Promotion Lifecycle
+
+Canonical variable model and command sequence for promoting potential feature/bug entries and initializing active feature delivery.
+
+## When to Use This Skill
+
+Use this skill when:
+- A large-scope change requires feature/bug promotion workflow.
+- A short-path workflow still requires promotion/folder initialization before delegated implementation.
+- An orchestrator must create potential docs, promote to issue, branch, and active feature folder.
+- Downstream research/spec agents depend on deterministic paths and identifiers.
+
+## MCP-First Execution Rule
+
+When the MCP server (`drmCopilotExtension`) is reachable, execute the lifecycle through the MCP tool surface first.
+
+Canonical MCP tool invocations:
+- feature potential entry: `mcp__drmCopilotExtension__new_potential_entry` with `{"short_name": "${short-name}"}`
+- bug potential entry: `mcp__drmCopilotExtension__new_potential_bug_entry` with `{"short_name": "${short-name}"}`
+- potential-to-issue promotion: `mcp__drmCopilotExtension__potential_to_issue` with `{"potential_path": "${relativeFile}", "promotion_type": "${promotion-type}", "work_mode": "${work-mode}"}`
+- active feature folder creation: `mcp__drmCopilotExtension__new_active_feature_folder` with `{"feature_name": "${long-name}", "type": "${promotion-type}", "issue_number": "${issue-num}", "work_mode": "${work-mode}"}`
+
+Documented alternatives:
+- VS Code extension commands (via `vscode/runCommand`): use when MCP server is unreachable but the VS Code extension command surface is available.
+- Direct script/CLI commands: use only when neither MCP nor VS Code extension commands are available.
+- When falling back, preserve the same variable model, flags, and work-mode semantics.
+
+## Canonical Variables
+
+- `${promotion-type}`: `feature` or `bug`
+- `${short-name}`: lowercase slug, hyphen-separated
+- `${relativeFile}`: workspace-relative path to created potential entry markdown
+- `${long-name}`: `${relativeFile}` filename without `.md`
+- `${issue-num}`: promoted GitHub issue number
+- `${feature-folder}`: active feature folder path
+- `${plan-path}`: single canonical plan file path reused across planning and preflight revisions
+- `${work-mode}`: `minor-audit`, `full-feature`, or `full-bug` (legacy `full` is accepted only as an alias for `full-feature`)
+- `${short-path-flag}`: `--work-mode minor-audit` (mandatory for short-path promotion/folder creation)
+
+## Canonical Fallback Command Sequence
+
+1) Create potential entry by type:
+- feature: `VS Code command: `drm-copilot: New Potential Entry` (command ID: `drmCopilotExtension.newPotentialEntry`) -ShortName ${short-name}`
+- bug: `VS Code command: `drm-copilot: New Potential Bug Entry` (command ID: `drmCopilotExtension.newPotentialBugEntry`) --short-name ${short-name}`
+
+2) Promote potential doc:
+- `VS Code command: `drm-copilot: Potential To Issue` (command ID: `drmCopilotExtension.potentialToIssue`) --potential-path ${relativeFile} --promotion-type ${promotion-type} --work-mode ${work-mode}`
+
+3) Create branch:
+- `${promotion-type}/${short-name}-${issue-num}`
+
+4) Create active feature folder:
+- `VS Code command: `drm-copilot: New Active Feature Folder` (command ID: `drmCopilotExtension.newActiveFeatureFolder`) --feature-name ${long-name} --type ${promotion-type} --issue-number ${issue-num} --work-mode ${work-mode}`
+
+## Canonical Fallback Short-Path Sequence (Minor Audit Mode)
+
+When orchestrator routing selects short path, promotion/folder initialization still occurs and MUST use `minor-audit` mode.
+
+1) Promote potential doc with short-path flag:
+- `VS Code command: `drm-copilot: Potential To Issue` (command ID: `drmCopilotExtension.potentialToIssue`) --potential-path ${relativeFile} --promotion-type ${promotion-type} --work-mode minor-audit`
+
+2) Create branch:
+- `${promotion-type}/${short-name}-${issue-num}`
+
+3) Create active feature folder with short-path flag:
+- `VS Code command: `drm-copilot: New Active Feature Folder` (command ID: `drmCopilotExtension.newActiveFeatureFolder`) --feature-name ${long-name} --type ${promotion-type} --issue-number ${issue-num} --work-mode minor-audit`
+
+3a) Verify minor-audit folder integrity before proceeding:
+- `${feature-folder}/issue.md` exists and contains `- Work Mode: minor-audit`
+- `${feature-folder}/issue.md` contains an explicit `## Acceptance Criteria` section
+- `${feature-folder}/spec.md` does not exist
+- `${feature-folder}/user-story.md` does not exist
+- if any check fails, stop and remediate before planning
+
+4) Delegate minimal-audit plan creation to `atomic_planner` with directive:
+- `DIRECTIVE: MINIMAL-AUDIT PLAN REQUIRED`
+
+4a) Resolve and persist `${plan-path}` before delegation:
+- reuse the earliest existing `plan*.md` in `${feature-folder}` when present
+- otherwise create exactly one canonical plan file path and reuse it for all revisions
+
+5) Require preflight validation via `atomic_executor` until:
+- `PREFLIGHT: ALL CLEAR`
+
+6) Execute plan Phase 0 only via executor and checkpoint evidence.
+
+7) Branch:
+- manual bootstrap: save state and stop,
+- non-bootstrap: continue with constrained small-path development.
+
+8) Validate delivery via executor against `issue.md`, then run reduced audit/remediation loop until ready-to-merge.
+
+## Required Outputs for Downstream Handoffs
+
+Before delegating research/spec/planning, provide:
+- `${feature-folder}/issue.md`
+- `${feature-folder}/spec.md` (or expected target path)
+- `${feature-folder}/user-story.md` (or explicit `NONE`)
+- latest research artifact path(s)
+- constraints/APIs/invariants to preserve
+
+Mode-aware expectations:
+- For `minor-audit`, the explicit `## Acceptance Criteria` section in `issue.md` is the primary acceptance-criteria source and `spec.md`/`user-story.md` may be intentionally absent by design.
+- For `minor-audit`, do not infer acceptance criteria from other `issue.md` sections such as verification notes, next steps, or severity checklists.
+- For `minor-audit`, `spec.md`/`user-story.md` must be treated as integrity failures when they appear unexpectedly in the active folder.
+- For `full-feature`, `spec.md` and `user-story.md` are expected alongside `issue.md`.
+- For `full-bug`, `spec.md` is expected alongside `issue.md`; `user-story.md` should be absent unless the requirements explicitly justify it.
+
+Selected-mode persistence requirements:
+- Producer outputs MUST persist exactly one marker in `issue.md` metadata above the first `##` heading:
+	- `- Work Mode: minor-audit`
+	- `- Work Mode: full-feature`
+	- `- Work Mode: full-bug`
+- Persisted marker MUST represent selected mode after eligibility checks, not requested mode.
+- If a legacy requested `full` path is accepted, tooling MUST normalize it to `full-feature` before persistence.
+- If a requested `minor-audit` path is rejected by eligibility checks, tooling MUST fail closed to `full-feature`, emit fallback reason, and persist `- Work Mode: full-feature`.

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

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

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

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

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

@@ -0,0 +1,48 @@
+---
+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 `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 `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 `validate_orchestration_artifacts` MCP tool with `artifact_type: "policy-audit"` and `artifact_path: <path>` and fail closed on any non-zero result.
+
+## Invalid Outputs
+
+- A freeform summary note is invalid.
+- A policy audit that retains the template instruction block is invalid.
+- A policy audit that omits the canonical major headings is invalid.

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

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

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

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

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

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

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