Feature Build
Write code that fits the decisions already made — not framework-default scaffolding. This skill is thin on purpose: it keeps the build faithful to STACK.md and hands the real language work to specialists.
Before writing code
- Read
STACK.md,CLAUDE.md, andTASTE.md. IfSTACK.mdis missing, run thetech-charterskill first — nothing is built on an undecided stack. (Check for and open these with your Read/Glob tools, not shell commands — OS portability.) - Stay inside the declared stack. A dependency not in
STACK.mdis not yours to add — if the feature genuinely needs one, go back and amendSTACK.mdas a decision, don't slip it in. - Name the smallest change that delivers the feature. YAGNI: no speculative abstraction, no layer a requirement hasn't forced.
Build
- Tests first. If
tdd-guideis available, hand off to it. Otherwise write the failing test, make it pass, refactor — same loop, done inline. - Match the surrounding code — its naming, its idioms, its error-handling. New code should be unattributable as "the AI part."
- Errors handled explicitly, at every boundary. No silent swallow.
- The one decision. Even in code, the fit to this project should be visible — a chosen boundary, a deliberate data shape — not a generated template.
Delegate the language review (portable)
Hand off to the most specific reviewer that exists in the install; skip silently if none do:
- Python →
python-reviewer· TypeScript/JS →typescript-reviewer· Go →go-reviewer· Rust →rust-reviewer· React →react-reviewer(and the same pattern for other languages). - No language-specific reviewer? Use
code-reviewerif present, else review inline againstCLAUDE.md. - Build broken?
build-error-resolverif present, else fix inline.
These are optional accelerators, not requirements — the skill works without any of them.
Before calling it done
Hand to the dev-critic agent (always shipped with this plugin) against STACK.md + TASTE.md. If it finds an undeclared dependency or code no human clearly decided, redo it.