implement

Do the plan in thin slices, one slice at a time. A slice is the smallest change to observable behavior. When a spec exists at docs/specs/<slug>.md, its acceptance criteria are the plan. Work through them one criterion at a time. The diff must not change anything that a non-goal of the spec excludes. A spec that still has an ## Open decisions section is a draft. Send it back to drill. A request with no spec and no settled plan goes to drill first. Its fast path gives the one-sentence plan.

1. Before the first test, create a task list. Add one item for each acceptance criterion when a spec exists. When no spec exists, add one item for each slice. Then add verify, and add rubric when the work is a UI, a public interface, a name, or a doc. Do not create a list of fewer than three items. Mark each item done when its work is committed. When you skip an item, mark it done and add skip: <reason> to its text. Never skip a criterion. Leave it open.
2. Pick the smallest unfinished slice, and do steps 3 to 7 on it in this session. When the user asked to give slices to workers, launch a subagent that runs the implement skill. It does steps 3 to 5 on one slice. Read its diff, then do steps 6 and 7 here.
3. Write the test that fails for the slice. Test through the interface, never against implementation details. If you cannot write a failing test, the interface under test is wrong. Fix the plan, not the test.
4. Write the minimum code that makes the test pass.
5. Refactor only while the tests pass. Use the style of the code around it.
6. Do the check in blast-radius.md before the gate when the diff deletes or renames a symbol that other code uses. Do it also when the diff changes a contract that another module, stored data, or an outside caller depends on.
7. Read the verify skill, and run its gate on the slice. Commit on its evidence record.
8. Go back to step 2 until no slice is left.

Rules:

• On the base branch, recommend a new branch before the first test, and ask the user. The base branch is where the remote HEAD points. Name the new branch with the spec slug, or with a short slug of the one-sentence plan. Work on the base branch only when the user says so. Never assume it. A session that is already on a feature branch stays there.
• Do one implementation at a time. Do not leave unfinished work for a new task on your own decision. Offer to finish and land it, to land it partly, or to keep it on its branch for later. Let the user pick. Only land ends the work.
• Write no production code before its failing test exists. The one exception is wiring whose only effect is inside a host that the tests cannot drive. Examples are a plugin entry point or a framework registration. Its proof is an end-to-end run through verify, never a regex or a string match over source code.
• Before the first slice that adds a module or an exported type, settle its shape with shape first. The sketch is one commit of not implemented stubs that have no behavior. So these stubs come before the failing tests that fill them.
• Before the first test of a slice, list the ways that the slice can fail. Test the likely ones and the costly ones: lost data, money, access, or a broken caller contract. Name the other ones in the commit message. Size the tests to the change. A one-line fix gets one regression test, not new test infrastructure.
• Inside a slice, run only the tests that exercise the slice, never the whole suite. The gate of the slice waits for step 7, and verify decides its size. Inside a phase that the spec declares, the gate follows outcome-oriented execution. A series of similar edits follows sequence verifiable units.
• Check each test with two imagined edits. When the behavior breaks, the test must fail. When only the internals change, the test must still pass. Read test behavior, not implementation when an assertion checks a mock, a call, or an error message. Read it also when an assertion does not plainly compare the subject's output with a literal value. A grep or a string check over source code proves nothing about behavior. A slice is not done until its tests failed on the behavior under test.
• Keep every diff to its slice. Each changed line belongs to the slice, or it removes dead code from a file that the slice changes.
• Before you add anything, ask four questions in this order. Does it need to exist? Does the standard library or the platform do it? Does a dependency that is already present do it? Can one line do it? Before you add a file, a layer, a dependency, or a parameter, read laziness protocol and subtract before you add. Add a wrapper, a layer, or a piece of state only when it passes the test in minimize reader load. Ask the four questions about test code too. Extend the existing fake, fixture, or helper before you write a new one, as part of the slice.
• Build a tool for mechanical work, and let the tool do the work. Mechanical work is a series of edits, a migration, generated files, or an analysis of data. Read build the lever before the first edit by hand.
• Define the data shape first when the logic of a slice holds state or branches on a shape. Do the same when the slice creates a type that later slices share. Read model the domain and foundational thinking before you write that logic.
• Keep the code type-safe: use no cast or other way around the type checker. Read type-system discipline when you design a type or a signature.
• Validate data at the I/O boundaries, and trust it inside. Configuration is input. Validate it where the code builds it, and refuse a bad value there, not at its first use. Read boundary discipline when you write validation, error handling, an adapter, or configuration code. Use no silent fallback that hides a failure.
• Give every call across the network a timeout. Give an idempotency key to each write that a caller can retry. Read make operations idempotent for a command, startup step, scheduler, or loop that writes state and can run twice.
• When two operations access the same data, run them one at a time. Or claim the data before the await: mark it in progress. Then, after the await, check again every condition that you read before it. A second check alone lets a charge or a send run twice. Read separate before serializing shared state when two actors can write the same file, key, or data.
• Change the state of a component only through its own operations. Never give a caller a reference that lets the caller change the state. Never give a reference to state that can change while the caller holds it. Read minimize reader load before you expose the state of a component.
• Delete what your change made unused. Read migrate callers, then delete legacy APIs before you write a new API to replace one that still has callers. In the files that the slice changes, also delete dead code before you add to them. Dead code is functions, imports, and parameters that no caller uses, and branches that no caller reaches. It is also stale flags, and validators that repeat a check that a boundary already did. It is also comments that repeat the code or excuse a workaround. Keep dead code that a non-goal puts out of scope. Flag dead code in other files, but do not remove it.
• Write no comment that repeats the code or explains a workaround. Fix the workaround at its cause, or hold the constraint in a type, a lint rule, or a test. Keep a comment only for what the code cannot say. An example is behavior outside the control of the project: a browser quirk, a vendor bug, or a protocol requirement.
• A slice that builds UI takes its typography, color, and spacing from the DESIGN.md of the project, when one exists.
• Write the commit message of each slice as one line in the convention of the repository. Read the recent git log to find the convention. When there is none, use the imperative in lowercase. Name the criterion by what it says, never by its spec id. Give the reason, not only the change. Stage the specific files, never git add ..
• Send a bug or an unexpected failure in a slice to the debug skill. Do not hide symptoms with a patch.
• Never guess a decision for the user that you find in a slice. Stop, name it, and let the user answer. A decision is for the user when it changes an acceptance criterion, a non-goal, or a public interface. It is also for the user when it needs the authority of the user or cannot be undone. Settle every other decision that a run can answer by running it, as never block on the human says.
• Stop the loop after three failed attempts on the same slice. Report to the user the criterion, what you tried, and the last error.
• When the last slice is committed, read the verify skill and follow it. Do this before you say that the work is done. For a UI, a public interface, a name, or a doc, also read the rubric skill and follow it. The maker never judges its own taste.