Menu
Discipline for running a code-changing task, covering scope, spec alignment, verification, and clean handoff.
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
Draft an academic paper or thesis in phases that survive peer review, from fitting the venue through shaping the contribution, storyboarding the skeleton, and writing the prose.
Pressure-test a paper at any phase, whether shape, skeleton, draft, or final, by reviewing it three ways at once, four when citations need checking against sources, then synthesize a mock notification with a phased revision list.
Build a single-file HTML slide deck in three light passes, content and mechanics first, then a unique visual identity, then the assembled deck, so revising the sequence never means regenerating the whole file.
Use after implementation is committed on a branch to open or update a PR, write the PR body, link work items, monitor checks, and handle CI feedback. Works for a feature or a standalone fix/perf/refactor.
Record an architecture decision by creating, updating, or superseding an ADR after a significant, costly-to-reverse technical choice is approved.
Define how approved requirements will be implemented (service boundaries, APIs, data model, integrations, failure modes, technical contracts) before coding.
| name | code-craft |
| description | Discipline for running a code-changing task, covering scope, spec alignment, verification, and clean handoff. |
| user-invocable | false |
Do one unit of work. Adjacent refactors, cleanup, and other items stay untouched. Behavior outside the unit is frozen: its outputs, contracts, and side effects stay as they are.
docs/srs.md, docs/architecture.md, and the ADRs define intended behavior. A change that must diverge from them updates the spec in the same commit. A result that contradicts the spec is unfinished, even when green.
Two things stop the work and go back to the caller with your hypothesis:
Run the unit's verification command and the static checks (lint, typecheck, compiler), and they pass. With no verification named, run the narrowest check that proves the change and name it. Then read your own diff against the request and for bugs it introduced.
With memory: project, a persistent MEMORY.md loads at start: durable craft, not task logs. Read it first, and check each entry against current code before trusting it. Record one curated lesson per recurring trap or dead end, refining the entry that already covers it, dropping what proved wrong, and keeping the file well under its load cap.
Compact, no build logs: the verification and static-check outcome, any spec files touched, and the stop reason if you halted. Adjacent problems you were not sent to fix, like a sibling bug or a hotspot, go back as findings for the caller to file, never fixed inline.
