slice
Bridge the spec's user-language description to the codebase's module structure. The napkin sketch says "something renders the editor" — your job is to say "the <WriteScreen> component at apps/web/src/features/write/WriteScreen.tsx renders it."
A vertical slice is the full stack a feature touches — UI, API, domain, data, external. TDD without a slice plan drifts to the easiest starting point (usually a backend unit) and quietly drops the UI.
Read the spec
Load the spec and any Technology Decisions from /spike. Summarise back: the headline interaction, the supporting jobs, and the tech choices.
Explore the codebase
Build a mental model of what already exists — real exploration, not guessing. For each supporting job, look for:
- Existing modules that match the responsibility
- Codebase conventions — monorepo layout, feature folders, layering patterns, how new features are typically added
- Frontend layer — framework, feature folder pattern, how screens handle state and API calls
- Data layer — where entities live, persistence approach
Use the Explore subagent or Grep/Glob directly. Be specific about files you looked at and patterns you found. The user knows things about the codebase you can't read from files — present findings and invite correction.
More from jonhilt/practical-engineer
tdd
Implement one theory through strict outside-in TDD, deriving tests from the spec brief. Use after /spec to drive implementation from a theory's headline interaction, supporting jobs, and napkin sketch.
11spec
Turn one theory into a clear brief — headline interaction, supporting jobs, and napkin sketch. The bridge between a theory and TDD. Use after /theories to specify one theory at a time.
11goals
Grill the user about a problem space until the business goal is crystal clear, then produce a structured Goals document. Use when the user wants to define what they're building and why, or kick off a new project.
10theories
Turn a Goals Document into a set of theories — each one a hypothesis about what might solve the problem, with a clear way to test it. Use after /goals to decide what to build and why.
10spike
Resolve technology unknowns from a spec's Requires field before TDD. Build throwaway proofs that validate choices, then record concrete decisions back into the spec. Use after /spec, before /tdd.
7refactoring-coach
Guided Socratic refactoring exercise — walks the user through refactoring a messy component one concern at a time, asking questions before revealing answers, naming principles, and showing only the relevant extraction. Use this skill whenever the user says "help me refactor", "walk me through refactoring", "let's refactor this together", "refactoring exercise", or shares a large/messy component and asks how to clean it up. Even if they just say "help me refactor" with a file attached, use this skill. Do NOT use this skill if they just want you to refactor without their involvement.
3