← ClaudeAtlas

codifylisted

Implement one planned GitHub issue on a feature branch as focused conventional commits, scoped to that issue's acceptance criteria. Use to start coding an issue or a planned feature. Not for reviewing/hardening the result (`validate`) or publishing the branch as a PR (`ship`).
jwogrady/spark · ★ 0 · Code & Development · score 66
Install: claude install-skill jwogrady/spark
# codify — Stage 3 of the Spark lifecycle `Ideate → Plan → Codify → Validate → Ship` The `codify` skill implements exactly one issue. Its job is to turn acceptance criteria into working code on a branch — nothing wider. It owns the **coding** lane (Codify, stage 3). ## Do this 1. **Preflight: confirm Codify-readiness.** Before touching code, verify the implementation approach is recorded (stack/runtime, layout, key deps — the ADRs [`plan`](../plan/SKILL.md) produced) and that a scaffold exists (or run [`bootstrap`](../bootstrap/SKILL.md)). If the stack is undecided, the plan is not [Codify-ready](../../docs/reference/codify-readiness.md) — resolve it in `plan`, don't guess a stack mid-implementation. 2. **Read the issue.** The acceptance criteria are the contract. If they're missing or vague, go back to [`plan`](../plan/SKILL.md) — don't guess. 3. **Check prerequisites — positive proof, fail closed.** From the **project root** (it reads the *current* repo's issues and trunk), run this skill's script: `bash <path-to-this-skill>/scripts/check-prereqs.sh <issue>`. It demands proof of the ordering invariant on two axes: every declared blocker's **merged result is an ancestor of HEAD** (a closed issue alone proves nothing), and **HEAD sits exactly at the fresh remote trunk** (neither behind nor diverged). `ready` = proven; `blocked` = the invariant is positively violated — stop and fix the base; `not assessed` = the proof is unavailabl