Take one slice from SLICES.md and ship it. Often for dev work, but might be a different task that you should still complete to the standards of the company
Process
Read the slice and the brief. Find the target slice. Internalize what it delivers. Read PROJECT_BRIEF.md for architectural context
Orient in the codebase. Module boundaries, test patterns, naming, DI style, config approach, what prior slices built. Your code should feel native — same seams, same style. Greenfield: scaffolding + test runner + lint + CI belong inside slice 1, not as separate phases
Plan the TDD sequence. Map acceptance criteria to red-green-refactor cycles. Start with the criterion that proves the core approach. Decide what's a real collaborator and what's a system boundary to mock. Keep the plan light. Use judgement for when to use TDD or take a different approach
Build one test at a time. Red → green → refactor. One failing test, minimum code to pass, clean up while green, next. Public interfaces only; mock system boundaries only; tests survive internal refactors. Writing all tests first produces tests that describe imagined behavior, not actual. See tdd-reference.md for the full methodology
Bake SRE in as you go. Structured logs at decision points and error paths; metrics on the behaviors this slice introduces; health checks on new endpoints; errors that fail explicitly at boundaries with context; config externalized. Operational readiness isn't a final step — if it's not present when tests go green, it won't be added
Verify. All acceptance criteria met and covered by passing tests. Observable outcomes demonstrably work — run it, hit the endpoint, read the logs. Full suite green, not just new tests. No unrelated changes mixed in
Consider future agents by running updating-ai-knowledge, often for AGENTS.md
Close the slice. Check the boxes in SLICES.md. Follow-up work, discovered edge cases, or risks land in the relevant future slice, or in a ## Notes section at the bottom of SLICES.md
Report what you shipped and verified back to whoever ran you
Scope
Feature work, infrastructure-as-code, migrations, instrumentation, perf, bug fixes, deploy automation. Language, framework, and cloud agnostic
Not for: research spikes with no code deliverable, pure documentation, project planning (use plan-to-slices)
Skills you lean on: the verify subagent before declaring done, and a subagent for a second opinion or implementation partner
1---2name: complete-slice3description: Implement a vertical slice from SLICES.md end-to-end using TDD. Use when user wants to code a slice of a project or mentions "complete slice"4---56Take one slice from `SLICES.md` and ship it. Often for dev work, but might be a different task that you should still complete to the standards of the company78## Process9101. **Read the slice and the brief.** Find the target slice. Internalize what it delivers. Read `PROJECT_BRIEF.md` for architectural context11122. **Orient in the codebase.** Module boundaries, test patterns, naming, DI style, config approach, what prior slices built. Your code should feel native — same seams, same style. Greenfield: scaffolding + test runner + lint + CI belong inside slice 1, not as separate phases13143. **Plan the TDD sequence.** Map acceptance criteria to red-green-refactor cycles. Start with the criterion that proves the core approach. Decide what's a real collaborator and what's a system boundary to mock. Keep the plan light. Use judgement for when to use TDD or take a different approach15164. **Build one test at a time.** Red → green → refactor. One failing test, minimum code to pass, clean up while green, next. Public interfaces only; mock system boundaries only; tests survive internal refactors. Writing all tests first produces tests that describe imagined behavior, not actual. See [tdd-reference.md](tdd-reference.md) for the full methodology17185. **Bake SRE in as you go.** Structured logs at decision points and error paths; metrics on the behaviors this slice introduces; health checks on new endpoints; errors that fail explicitly at boundaries with context; config externalized. Operational readiness isn't a final step — if it's not present when tests go green, it won't be added19206. **Verify.** All acceptance criteria met and covered by passing tests. Observable outcomes demonstrably work — run it, hit the endpoint, read the logs. Full suite green, not just new tests. No unrelated changes mixed in21227. **Consider future agents** by running `updating-ai-knowledge`, often for `AGENTS.md`23248. **Close the slice.** Check the boxes in `SLICES.md`. Follow-up work, discovered edge cases, or risks land in the relevant future slice, or in a `## Notes` section at the bottom of `SLICES.md`25269. **Report** what you shipped and verified back to whoever ran you2728## Scope2930Feature work, infrastructure-as-code, migrations, instrumentation, perf, bug fixes, deploy automation. Language, framework, and cloud agnostic3132Not for: research spikes with no code deliverable, pure documentation, project planning (use `plan-to-slices`)3334Skills you lean on: the `verify` subagent before declaring done, and a subagent for a second opinion or implementation partner
ryan-scheinberg