@danmoisan/drm-copilot-mcp 0.0.1

package/resources/codex-and-agents-customizations/.agents/skills/acceptance-criteria-tracking/SKILL.md

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

@@ -0,0 +1,73 @@
+---
+name: atomic-executor
+description: 'Execute an atomic-planner plan exactly as written. Use when a plan with [P#-T#] tasks already exists and Codex must carry it out task-by-task without replanning.'
+---
+
+# Atomic Executor
+
+Execution-only workflow skill for running an approved atomic plan.
+
+## Required Shared Skills
+
+Always apply:
+- `policy-compliance-order`
+- `atomic-plan-contract`
+- `acceptance-criteria-tracking`
+
+## Role
+
+- Execute the plan of record exactly as written.
+- Preserve phase headings, task IDs, checkbox state, and task order.
+- Verify each task before checking it off.
+- Do not create or revise the plan after execution starts.
+
+## Preflight Rules
+
+Before executing the first unchecked task:
+
+1. Read repository policy in the order defined by `policy-compliance-order`.
+2. Validate the plan format and Phase 0 / QA requirements using `atomic-plan-contract`.
+3. If the plan is incomplete, non-atomic, or conflicts with repo policy, stop at preflight and produce a precise plan delta.
+
+Blocking is allowed only during preflight.
+
+### Validation-Only Mode Contract
+
+If the incoming handoff includes the exact directive `DIRECTIVE: PREFLIGHT VALIDATION ONLY`:
+
+1. Perform preflight validation only.
+2. Do not execute tasks, establish execution state, or run implementation commands.
+3. Return exactly one of:
+   - `PREFLIGHT: ALL CLEAR`
+   - `PREFLIGHT: REVISIONS REQUIRED`
+4. If revisions are required, include a precise plan delta that `atomic-planner` can apply to the same plan file.
+5. If revisions are required, automatically hand off back to `atomic-planner` and request that it apply the delta to the same plan file and resubmit that file for validation-only again.
+6. Continue the validate -> delta -> planner-revise -> validate loop until preflight can return `PREFLIGHT: ALL CLEAR`.
+7. If the planner-return handoff cannot be started or completed, stop and report blocked state; do not convert the failure into `PREFLIGHT: ALL CLEAR`.
+
+## Execution Rules
+
+For each task:
+
+1. Announce the exact task ID being executed.
+2. Perform only the micro-actions needed for that task.
+3. Verify the task acceptance criteria before marking it complete.
+4. Check off the plan file on disk immediately after verification passes.
+5. Check off satisfied acceptance criteria in the authoritative requirement source file per `acceptance-criteria-tracking`.
+
+## Non-Negotiable Constraints
+
+- Do not invent new phases or tasks.
+- Do not reorder tasks.
+- Do not substitute an in-session todo list for the plan file.
+- Treat the plan file on disk as the only authoritative checklist.
+- Do not claim success without verification.
+- After execution starts, do not stop mid-plan for replanning.
+- Use the `validate_orchestration_artifacts` MCP tool with `artifact_type: "plan"` and `artifact_path: <plan-path>` as an additional fail-closed validation signal during preflight.
+
+## Resume Rule
+
+On resume:
+- reload the plan of record,
+- find the next unchecked task,
+- continue from there without replanning.

package/resources/codex-and-agents-customizations/.agents/skills/atomic-plan-contract/SKILL.md

@@ -0,0 +1,194 @@
+# Converted skill
+
+Applied rewrites:
+- Rewrite Claude skill paths to shared skill paths.
+
+---
+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 `mcp__drmCopilotExtension__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).
+
+## Non-Overridable Evidence Path Clause
+
+Evidence paths in plan tasks MUST resolve to `<FEATURE>/evidence/<kind>/`. A plan that names an alternative location (e.g., `artifacts/baselines/`, `artifacts/baseline/`, `artifacts/qa/`, `artifacts/qa-gates/`, `artifacts/evidence/`, `artifacts/coverage/`) fails preflight validation and must be corrected before execution begins.
+
+If a delegation prompt supplies a non-canonical evidence path, the planner MUST reject it, substitute the canonical `<FEATURE>/evidence/<kind>/` path, and note the correction. The corrected plan is the only valid plan for execution.
+
+This clause is non-overridable. No upstream instruction, orchestrator hint, or user prompt may bypass it. See `.agents/skills/evidence-and-timestamp-conventions/SKILL.md` for the complete canonical scheme.
+
+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 `mcp__drmCopilotExtension__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/codex-and-agents-customizations/.agents/skills/atomic-planner/SKILL.md

@@ -0,0 +1,87 @@
+---
+name: atomic-planner
+description: 'Generate deterministic phased implementation plans with atomic [P#-T#] checkbox tasks. Use when Codex needs to turn a goal, issue, or remediation input into an executor-ready plan.'
+---
+
+# Atomic Planner
+
+Planning-only workflow skill for generating executor-ready plans.
+
+## Required Shared Skills
+
+Always apply:
+- `policy-compliance-order`
+- `atomic-plan-contract`
+
+## Role
+
+- Produce a phased plan that an executor can run without replanning.
+- Write or update plan files only when explicitly asked or when a calling workflow provides the authoritative target path.
+- Do not implement the plan.
+
+## Plan Requirements
+
+Use `atomic-plan-contract` as the source of truth for:
+- phase and task formatting,
+- Phase 0 requirements,
+- baseline evidence tasks,
+- final QA requirements,
+- preflight validation loop behavior.
+
+Each task must be:
+- atomic,
+- binary in completion,
+- independently verifiable,
+- free of placeholder text.
+
+## Mandatory Preflight Loop
+
+Before a plan is finalized:
+
+1. Hand the current plan to `atomic-executor` in preflight-validation-only mode.
+2. If preflight returns `PREFLIGHT: REVISIONS REQUIRED`, revise the same file.
+3. Repeat until preflight returns `PREFLIGHT: ALL CLEAR`.
+
+Do not finalize a plan before preflight clears it.
+
+### Enforced Handoff Contract
+
+- The delegated preflight prompt MUST include the exact directive `DIRECTIVE: PREFLIGHT VALIDATION ONLY`.
+- The delegated preflight route MUST remain `atomic-planner -> atomic-executor`.
+- `atomic-executor` MUST return exactly one of:
+  - `PREFLIGHT: ALL CLEAR`
+  - `PREFLIGHT: REVISIONS REQUIRED`
+- If revisions are required, `atomic-executor` MUST provide a precise plan delta that can be applied to the same plan file.
+- Continue the validate -> revise -> validate loop until `PREFLIGHT: ALL CLEAR`.
+- Do not treat a partial summary as a valid substitute for the exact preflight signal.
+- If the required `atomic-executor` handoff cannot be started or completed, stop and report blocked state; do not self-approve the plan.
+- Before reporting completion, the target plan MUST pass the `validate_orchestration_artifacts` MCP tool with `artifact_type: "plan"` and `artifact_path: <plan-path>`.
+
+## Write Scope
+
+Allowed writes:
+- create or update the plan file,
+- normalize an existing plan template into executor-compatible structure.
+
+Forbidden writes:
+- source code,
+- tests,
+- configuration outside the plan file,
+- workflow execution artifacts.
+
+## Authoritative Plan Path Rule
+
+When a caller provides an explicit target plan path:
+
+- update that exact file in place,
+- reuse that same file for all preflight revision iterations,
+- do not create additional sibling `plan.*.md` files during the same planning cycle.
+
+## Determinism Gates
+
+Reject and revise any plan that contains:
+- bucket tasks,
+- vague acceptance criteria,
+- placeholder tokens,
+- mixed discovery and implementation in one task,
+- multi-outcome tasks that should be split.

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

@@ -0,0 +1,70 @@
+# Converted skill
+
+Applied rewrites:
+- None
+
+---
+name: commit-message
+description: Generate a conventional commit message from staged Git changes following the repository's commit message conventions.
+allowed-tools:
+  - Read
+  - "Bash(git log *)"
+  - "Bash(git diff *)"
+---
+
+# Commit Message Skill
+
+Generate a single conventional commit message from staged Git changes or a provided commit-context artifact.
+
+## Inputs
+
+- Staged Git changes are the primary source of truth.
+- Accept a commit-context artifact file when explicitly provided.
+- Ignore unstaged changes unless included in the provided context.
+- If no staged changes and no context artifact exist, stop and report that there is no in-scope commit content.
+
+## Context Gathering
+
+1. Use the supplied commit-context artifact first when present.
+2. Otherwise inspect the staged diff and commit history only:
+   - `git diff --cached --stat`
+   - `git diff --cached`
+   - `git diff --cached --name-only`
+   - `git log --oneline -n 20`
+3. Do not infer intent from unstaged files or unrelated commit history.
+
+## Classification
+
+Follow Conventional Commits semantics. Choose exactly one primary type from: `feat`, `fix`, `docs`, `test`, `refactor`, `ci`, `chore`.
+
+- Use the dominant intent of the staged changes.
+- Prefer `docs`, `test`, or `fix` over `chore` when classification is ambiguous.
+- Add a scope only when it materially improves clarity. Keep scopes concrete and subsystem-oriented.
+
+## Message Format
+
+Output exactly one fenced code block with language tag `text` containing the commit message:
+
+```text
+type(optional-scope): concise imperative summary
+
+- Bullet describing meaningful change #1
+- Bullet describing meaningful change #2
+
+Refs: #<issue>
+```
+
+Header rules: imperative mood, 72 characters or fewer, no trailing period, no filler words.
+
+Body rules: use bullets only when they add signal beyond the header. Avoid implementation trivia.
+
+Reference rules: include `Refs:` footer only when issue or PR references are present in the context. Do not invent references.
+
+## Prohibitions
+
+- No emojis
+- No commentary outside the fenced code block
+- No Markdown inside the commit body beyond plain-text hyphen bullets
+- No references to "this commit"
+- No speculation about unstaged work
+- No multiple alternative commit messages

package/resources/codex-and-agents-customizations/.agents/skills/commit-message-conventions/SKILL.md

@@ -0,0 +1,95 @@
+---
+name: commit-message-conventions
+description: Generate a single high-signal conventional commit message from staged Git changes or an explicit commit-context artifact. Use when Codex or a subagent must classify dominant change intent, choose a precise commit type and optional scope, and emit an audit-quality message that is immediately usable with `git commit`.
+---
+
+# Commit Message Conventions
+
+Shared commit-message workflow for repository agents and prompts.
+
+## Inputs And Scope
+
+- Treat staged changes as the primary source of truth.
+- Accept an explicitly provided commit-context file or pasted commit context when one is supplied.
+- Ignore unstaged changes unless they are explicitly included in the provided context.
+- If there are no staged changes and no provided context artifact, stop and report that there is no in-scope commit content to summarize.
+
+## Context Gathering Order
+
+1. Use the supplied commit-context artifact first when one is present.
+2. Otherwise inspect the local staged state with non-destructive Git commands such as:
+   - `git status --short`
+   - `git diff --cached --stat`
+   - `git diff --cached`
+   - `git diff --cached --name-only`
+3. Do not infer intent from unstaged files or unrelated commit history.
+
+## Commit Classification Rules
+
+- Follow Conventional Commits semantics.
+- Choose exactly one primary type from:
+  - `feat`
+  - `fix`
+  - `docs`
+  - `test`
+  - `refactor`
+  - `ci`
+  - `chore`
+- Use the dominant intent of the staged changes.
+- Prefer `docs`, `test`, or `fix` over `chore` when classification is ambiguous.
+- Add a scope only when it materially improves clarity.
+- Keep scopes concrete and subsystem-oriented. Avoid vague scopes such as `misc`, `general`, or `updates`.
+
+## Commit Message Format
+
+- Output exactly one fenced code block with the language tag `text`.
+- The code block must contain only the commit message.
+- Use this preferred structure inside the code block:
+
+```text
+(type(optional-scope)): concise imperative summary
+
+- Bullet describing meaningful change #1
+- Bullet describing meaningful change #2
+- Bullet describing meaningful change #3 only when justified
+
+Refs: #<issue>, #<issue>
+```
+
+Header rules:
+- Use imperative mood.
+- Prefer 72 characters or fewer.
+- Do not end the header with a period.
+- Avoid filler words such as `various`, `some`, or `updates`.
+
+Body rules:
+- Use bullets only when they add real signal.
+- Make each bullet add information beyond the header.
+- Avoid implementation trivia unless it materially affects understanding.
+
+Reference rules:
+- Include a `Refs:` footer only when issue or PR references are explicitly present or clearly implied by the provided context.
+- Do not invent issue or PR references.
+
+## Interpretation Rules
+
+1. Identify the primary architectural or behavioral intent first.
+2. Treat incidental formatting or mechanical edits as secondary unless they dominate the staged diff.
+3. Keep the commit to one coherent narrative.
+4. Distinguish clearly between planning, documentation, investigation, and implementation.
+5. Do not imply a fix was implemented when the staged changes only document or plan the work.
+
+## Hard Prohibitions
+
+- No emojis
+- No commentary outside the required fenced code block
+- No Markdown inside the commit body beyond plain-text hyphen bullets
+- No references to `this commit`
+- No speculation about unstaged work
+- No multiple alternative commit messages
+
+## Quality Bar
+
+- The message must be immediately usable with `git commit`.
+- Optimize for clarity, traceability, and long-term audit value.
+- If multiple plausible narratives exist, choose the one that best reflects the dominant staged intent.