Menu
Force plan, HLD, ADRs, and constraints to exist BEFORE any code is generated. Trigger when starting a new feature, epic, or significant change.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
| name | spec-first-delivery |
| description | Force plan, HLD, ADRs, and constraints to exist BEFORE any code is generated. Trigger when starting a new feature, epic, or significant change. |
Review the spec harder than the code. The cheapest place to be wrong is the spec.
The harness runs in this order: spec → plan → tasks → code. Skipping the spec is not faster — it is a deferred rewrite.
docs/VISION.md or equivalent per project structure). If not, create or update it before proceeding.ADR-NNN).requirements/FEATURE_SPEC.md (or equivalent per project structure)architecture/decisions/ADR-NNN-<short-title>.md (one per decision)architecture/HLD-<feature>.md (if not already covered)docs/ROADMAP.md or equivalent per project structure) with new tasks or milestones| Excuse the agent makes | Counter |
|---|---|
| "I have enough context to start coding" | No spec = no acceptance criteria = no way to know if the output is correct. Write the spec. |
| "The spec will slow us down" | A missing spec causes rewrites. Rewrites cost more than specs. |
| "The requirements are obvious" | Obvious requirements are the ones most often wrong. Write them down and verify. |
| "We can spec it after the prototype" | Prototypes become production. Spec it now. |
Bootstrap or harden a project's operating model for mixed human and AI delivery teams. Use when starting a repository, adopting an agent harness, defining authority and risk tiers, coordinating parallel agents safely, binding evidence and review to an exact candidate, or correcting fragmented rules that prevent coherent, consistent, complete delivery.
Architecture decisions, trade-off analysis, and ADR authoring. Trigger when a significant technical decision needs to be made, documented, and owned — not when an implementation detail needs a choice.
Decompose an epic into atomic parallelizable tasks and route each task to the right skill. Use this as a meta-router when you have more than one skill available and need to decide which applies. Trigger at the start of any multi-track epic or when the skill count in your harness exceeds ~12.
Check proposed stack, data flows, cloud choices, and delivery controls against declared enterprise policies, compliance frameworks, and security controls. Trigger at R2/R3 risk classification, before locking architecture decisions, or when the operating profile names a governance pointer.
Govern the SemVer release process — versioning discipline, tag-based GitHub releases, changelog hygiene, and the ADR that confirms the release strategy is agreed. Trigger when setting up a release process, before a first public release, or when release practice has become inconsistent. Owned by delivery-orchestrator.
Session-start orientation for this team harness. Load first, before any work. Explains the operating contract, when each skill triggers, and how installed companion plugins supply agent-craft capabilities while this harness supplies the team contract. Trigger at the start of every session and whenever unsure which skill applies.