spec-driven-workflowlisted

# Spec-driven workflow This is the orchestration competence: given a request like *"add support for transfers between accounts"*, decide what process it needs, run that process, and know when to stop. `AGENTS.md` states the rules for Codex and `CLAUDE.md` states them for Claude Code. This shared skill is how you apply them. ## 1. Classify first Classification decides the process, so it happens before anything else. When a request sits between two tiers, take the higher one — the cost of over-process is some extra writing, the cost of under-process is unspecified behaviour in production. | Tier | Signals | Process | |---|---|---| | **TRIVIAL** | typo, comment, docstring wording; no behaviour change | fix it, run `make fast`, done | | **SMALL** | one validation rule, a narrow endpoint tweak, a local refactor | branch, implement, `make quality`, brief report | | **STANDARD** | new user-visible behaviour, contained in one or two layers | full workflow below | | **COMPLEX** | auth, schema, external integration, cross-cutting, migrations | full workflow + `security-reviewer` + architecture review | | **CRITICAL** | destructive migration, secrets, payments, central auth, infrastructure | full workflow + explicit human authorisation before any irreversible step | Say the classification out loud before proceeding, so it can be challenged early rather than after the work is done. ## 2. The lifecycle ``` classify → investigate → specify → branch → implement → gate → review → ver