Spec and Build

What it does

You give it a significant codebase change. It reads the system, argues the design, writes a phased spec, and stops. It writes code only after you approve. Use it for changes that touch more than two files or alter a gate, a permission, persisted state or a data model: new cross-file features, refactors, security hardening, migrations and external-service integrations.

/spec-and-build <problem statement>

The six stages

1. Deep read. Find every touch point, caller, test and affected path before forming an opinion.
2. The argument. Make the strongest case for the current design, the strongest case against it, then state a middle way and the one invariant that must hold before and after.
3. The dev spec. Write a phased Markdown spec. Each change carries the exact old text, the exact new text, a verification command and a test that fails before and passes after.
4. Approval gate. Stop. A request for a plan is not permission to change code.
5. Implementation. Build one phase at a time. A phase does not start until the previous validation gate passes.
6. Completion report. List the phases delivered, test results, files changed, what was removed and added, and the invariants confirmed.

Install

mkdir -p ~/.claude/skills/spec-and-build && curl -fsSL https://raw.githubusercontent.com/Kaikhalid/spec-and-build-skill/main/SKILL.md -o ~/.claude/skills/spec-and-build/SKILL.md

git clone https://github.com/Kaikhalid/spec-and-build-skill.git /tmp/spec-and-build-skill && mkdir -p ~/.codex/skills && cp -R /tmp/spec-and-build-skill/codex-plugin/skills/spec-and-build ~/.codex/skills/ && rm -rf /tmp/spec-and-build-skill