Expand UtilitiesCS coverage with QuickFiler stability fixes and Codex workflow support

.agents/README.md

@@ -0,0 +1,86 @@
+# Codex Skill Architecture
+
+## Purpose
+
+This directory is the canonical Codex runtime surface for repository-local skills.
+
+Codex-supported repository locations in this repo are:
+
+- `.agents/skills/<skill-name>/SKILL.md` for reusable workflow skills
+- `.codex/agents/*.toml` for subagent definitions
+- `.codex/prompts/*.md` for prompt entrypoints and lightweight workflow launchers
+
+The legacy GitHub Copilot ecosystem under `.github/skills` and `.github/agents` remains as historical source material during migration. New Codex-native runtime behavior should be authored in `.agents/skills` and consumed from `.codex/agents`.
+
+## Layering
+
+Design skills in layers so behavior is authored once and reused everywhere:
+
+1. Foundation skills
+   - Policy order
+   - Atomic plan contract
+   - Acceptance criteria tracking
+   - Evidence conventions
+   - Canonical-location audits
+
+2. Integration skills
+   - PR base resolution
+   - PR context artifact rules
+   - Feature-promotion lifecycle
+   - Remediation handoff
+   - Host-surface adapters
+
+3. Language routing and orchestration-state skills
+   - Change-budget routers
+   - Checkpoint and resume contracts
+
+4. Workflow skills
+   - `atomic-executor`
+   - `atomic-planner`
+   - `feature-review`
+   - `orchestrator-workflow`
+
+5. Specialist support skills
+   - `commit-message-conventions`
+   - `pr-authoring`
+
+6. Subagents
+   - Keep `.codex/agents/*.toml` concise.
+   - Reference workflow and shared skills by name instead of embedding long duplicated instructions.
+
+## Anti-Duplication Rules
+
+1. If multiple workflows need the same rule, extract it into one shared skill.
+2. Workflow skills should name the shared skills they depend on rather than restating those blocks.
+3. Environment-specific repo automation and its MCP dependency binding should live in `repo-automation-adapter`, not in each workflow skill.
+4. Canonical paths should be defined in exactly one skill; other skills should reference that skill instead of repeating the path.
+5. If Codex already ships a suitable system skill, prefer a thin repo-local compatibility wrapper instead of re-implementing the same scaffolding.
+6. If an agent persona grows reusable decision rules or formatting rules, move those rules into a shared skill and keep the agent as a thin wrapper.
+7. If a top-level workflow routes between multiple existing skills or subagents, capture that routing once in a shared workflow skill and keep the prompt or agent as a launcher.
+
+## Migration Rules
+
+When migrating a Copilot artifact:
+
+1. If it defines reusable repository guidance, migrate it to `.agents/skills/<name>/SKILL.md`.
+2. If it defines a reusable agent persona or bounded delegation role, migrate it to `.codex/agents/<name>.toml`.
+3. If it is mainly a launch prompt or an orchestration shortcut, migrate it to `.codex/prompts/<name>.md`.
+4. Preserve stable names where possible so downstream handoffs remain readable and consistent.
+5. If a Copilot workflow relied on `drmCopilotExtension.*` commands or another host-specific surface, move that translation logic into `repo-automation-adapter`, target semantic MCP tools on server `drmCopilotExtension` when available, and keep the business workflow skill host-agnostic.
+
+## External Tool Bindings
+
+When a repository skill owns an external MCP dependency:
+
+- declare that dependency once in `agents/openai.yaml` beside the owning skill
+- keep downstream workflow skills dependent on the adapter skill, not on duplicated MCP binding metadata
+
+## Future Migrations
+
+Use the system `$skill-creator` skill when scaffolding a new Codex skill, then apply the repository rules in this file:
+
+- place the runtime skill under `.agents/skills`
+- keep frontmatter minimal
+- make the description explicit about triggers
+- reference existing shared skills before creating a new one
+- add a new shared skill only when the behavior cannot be expressed as a composition of existing skills

.agents/skills/README.md

@@ -0,0 +1,49 @@
+# Codex Repository Skills
+
+Repository-local Codex skills live under `.agents/skills/<skill-name>/SKILL.md`.
+
+## Skill Groups
+
+- Foundation
+  - `policy-compliance-order`
+  - `atomic-plan-contract`
+  - `acceptance-criteria-tracking`
+  - `evidence-and-timestamp-conventions`
+  - `skill-canonical-location-audit`
+
+- Integration
+  - `repo-automation-adapter`
+  - `pr-base-branch-merge-base`
+  - `pr-context-artifacts`
+  - `feature-promotion-lifecycle`
+  - `policy-audit-template-usage`
+  - `remediation-handoff-atomic-planner`
+
+- Language routing and state
+  - `csharp-change-budget-router`
+  - `csharp-orchestration-state-machine`
+  - `powershell-change-budget-router`
+  - `powershell-orchestration-state-machine`
+
+- Workflow
+  - `atomic-planner`
+  - `atomic-executor`
+  - `feature-review`
+  - `orchestrator-workflow`
+
+- Specialist support
+  - `commit-message-conventions`
+  - `pr-authoring`
+
+- Meta
+  - `make-skill-template`
+
+## Authoring Rules
+
+1. Put shared rules in one skill only.
+2. Have workflow skills reference shared skills instead of copying their text.
+3. Put host-specific repo automation rules and their MCP dependency binding in `repo-automation-adapter`.
+4. Keep names stable when migrating from the legacy Copilot ecosystem.
+5. When an agent needs reusable rules, extract them into a shared skill and keep the agent as a thin wrapper.
+6. Put top-level route selection and checkpoint rules in a shared workflow skill rather than duplicating them across prompts or agent personas.
+7. When a skill depends on an external MCP server, declare it in that skill's `agents/openai.yaml` instead of repeating the binding in each caller.

.agents/skills/acceptance-criteria-tracking/SKILL.md

@@ -0,0 +1,50 @@
+---
+name: acceptance-criteria-tracking
+description: 'Track and check off acceptance criteria in requirement source files such as issue.md, spec.md, and user-story.md as work is delivered. Use when executing plans, reviewing features, or validating delivery.'
+---
+
+# Acceptance Criteria Tracking
+
+Shared protocol for identifying, tracking, and checking off acceptance criteria in their authoritative source files.
+
+## When to Use This Skill
+
+Use this skill when:
+- executing an atomic plan that satisfies acceptance criteria,
+- reviewing a feature branch and validating delivered behavior,
+- reconciling task completion with requirement documents.
+
+## AC Source Resolution
+
+Resolve authoritative acceptance-criteria sources from the persisted work-mode marker in `issue.md`:
+
+| 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` |
+| missing / malformed | fail closed to `full-feature` |
+
+When multiple source files apply, track checkboxes in each applicable file independently.
+
+## Check-Off Rules
+
+1. Only mark an AC item complete after implementation and verification.
+2. Check off each item individually.
+3. Preserve the criterion text exactly; change only `- [ ]` to `- [x]`.
+4. Leave unmet items unchecked and document the gap elsewhere.
+5. Do not invent or add new acceptance criteria.
+
+## Completion Summary
+
+At the end of plan execution or feature review, report:
+
+```text
+### 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>
+```

.agents/skills/atomic-executor/SKILL.md

@@ -0,0 +1,57 @@
+---
+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.
+
+## 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.
+- Do not claim success without verification.
+- After execution starts, do not stop mid-plan for replanning.
+
+## Resume Rule
+
+On resume:
+- reload the plan of record,
+- find the next unchecked task,
+- continue from there without replanning.

.agents/skills/atomic-plan-contract/SKILL.md

@@ -0,0 +1,60 @@
+---
+name: atomic-plan-contract
+description: 'Atomic plan format and QA contract shared by planning and execution skills. Use when generating, validating, or executing plans with Phase 0, baseline evidence, and final QA loops.'
+---
+
+# Atomic Plan Contract
+
+Shared rules for atomic plan formatting, Phase 0 requirements, baseline evidence, and final QA loops.
+
+## Canonical Plan Format
+
+- Phase headings must be `### Phase N — <Title>`.
+- Tasks must start with `- [ ] [P#-T#]` or `- [x] [P#-T#]`.
+- Task IDs must match the phase number and be sequential within the phase.
+
+## Phase 0 Requirements
+
+Phase 0 must:
+- read repository policy in the order defined by `policy-compliance-order`,
+- capture baseline toolchain state for each language touched,
+- write baseline artifacts using the conventions in `evidence-and-timestamp-conventions`.
+
+Baseline command-step artifacts must include:
+- `Timestamp:`
+- `Command:`
+- `EXIT_CODE:`
+- `Output Summary:`
+
+## Final QA Loop
+
+For plans that change code or tests, the final QA phase must run the applicable toolchain loop in order:
+
+1. Formatting
+2. Linting
+3. Type checking when applicable
+4. Testing
+
+If any step fails or changes files, restart from step 1 until the final pass is clean.
+
+## Minor-Audit Gate
+
+`minor-audit` plans must include:
+- baseline evidence tasks,
+- targeted verification evidence tasks,
+- end-state evidence tasks.
+
+They must not depend on `spec.md` or `user-story.md` when those documents are intentionally absent.
+
+## Expect-Fail Tasks
+
+Any regression-test task expected to fail before a later fix must:
+- include the exact `[expect-fail]` tag in the task title,
+- identify the exact command to run,
+- record auditable evidence in the canonical regression-testing location.
+
+## Preflight Signals
+
+Use these exact signals for executor preflight validation:
+- `PREFLIGHT: ALL CLEAR`
+- `PREFLIGHT: REVISIONS REQUIRED`

.agents/skills/atomic-planner/SKILL.md

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