← ClaudeAtlas

cooklisted

Use when the user asks to implement an approved `plan.md` or a clear bounded requirement. Execute the scoped change, verify it, inspect the resulting diff, and record meaningful decisions and verification in one `implement-notes.md`. Use scout, subagents, or independent review only when uncertainty, risk, or scope warrants them. Do not make commits, pushes, or releases implicit.
danielleit241/forge · ★ 1 · Code & Development · score 70
Install: claude install-skill danielleit241/forge
# cook Implement the approved scope with the smallest loop that can establish trust. ## Workflow 1. Read `plan.md` when present. Confirm the next unchecked item and its acceptance criteria. Use `scout --repo` only when touchpoints or current behavior are uncertain. 2. Edit the scoped code. Dispatch an implementer or tester only when isolation, size, risk, or tests-first work makes it useful; send a compact inline contract and changed-file context, not a generated brief file. 3. Run focused verification, then inspect the diff. Request independent review for public contracts, security/data/migration/concurrency risk, unfamiliar surfaces, or an explicit review request. Handle `APPROVE`, `REQUEST CHANGES`, or `BLOCK` before claiming completion. 4. Update the plan's checkbox/status when a plan exists. Write or append `plans/YYMMDD-{slug}/implement-notes.md` with completed scope, changed files, commands/results, material decisions or deviations, review verdict when present, and residual risk. This is the only cook artifact. 5. Stop for a blocker, failed verification, or a decision that changes the Design Contract. Keep commits, push, and release as explicit user choices. For a clear standalone request, create `plans/YYMMDD-{slug}/implement-notes.md` only after the change is verified. Do not generate phase briefs, phase evidence, implementer reports, implementation-note copies, or review files.