/cook

/cook

Let's cook.

---

Intent

You're building. Not hacking. Not vibing. Building with discipline. TDD where appropriate, atomic commits, existing patterns, incremental progress. 99.1% pure.

---

Load Skill

Load the walter skill first. Then read its execution, decomposition, and quality references. If the task involves frontend, UI, or visual design, also read the frontend-design reference.

---

Start

$ARGUMENTS

If no task was specified, STOP and use the AskUserQuestion tool to ask What are we building? If there's no clear spec or scope, use /formula first.

---

Pre-Flight

Before writing any code:

1. Verify Readiness

• Problem and scope are clear
• Success criteria are defined
• Dependencies are identified and satisfied
• Development environment is ready
• Pre-commit hooks running (lint, type check, format, tests) — if missing, set them up
• Governing docs located (check .walter/ for formulas, preps, or other in-flight work)

If any unclear, use /formula first. Don't cook without a formula.

2. Research with Sub-Agents

Spawn sub-agents to explore in parallel. Don't waste context on exploration.

Sub-agent tasks:

• Find existing code patterns relevant to this task (specify directories and file types to search)
• Identify similar implementations in the codebase (name the feature or behavior to match)
• Review test approaches used elsewhere (point to the test directories and frameworks)
• Check for dependencies or conflicts (list the modules and files being changed)

Brief each sub-agent with:

• Specific files or directories to focus on
• What to look for (patterns, naming, structure, not just "find patterns")
• The acceptance criteria for context on what's being built
• Expected output: file paths, code snippets, and a summary of how existing code handles this

After collection:

• Spot-check key claims against the actual code. Sub-agents can hallucinate file contents or misidentify patterns.
• Synthesize into implementation approach: what patterns to follow, what test approach to use, what dependencies exist.

3. Create Checklist

Convert acceptance criteria into explicit checklist:

• Setup (branch, dependencies, environment)
• Implementation (each criterion as checkbox)
• Testing (new tests, existing tests, coverage)
• Documentation

---

The Discipline

Work Incrementally

Build and test in small steps. Commit at logical boundaries:

1. Make changes incrementally, testing as you go
2. Commit when a work item or coherent part of a feature is complete
3. Review your work before committing — use sub-agents for verification when it warrants it
4. Move to next piece

No big bangs. No micro-commits after every small change. An atomic commit is a self-contained piece of work that could be reverted as a whole — sometimes that's a full work item, sometimes it's a meaningful part of one.

Follow TDD (When Appropriate)

For business logic, algorithms, APIs, service methods:

1. Write failing test
2. Write the best implementation — not just enough to pass
3. Refactor if needed
4. Repeat until the logical unit is complete
5. Run automated checks (lint, type check, build), review, and commit

Follow Existing Patterns

• Match the codebase naming
• Match the codebase patterns
• Don't introduce new patterns unless necessary

You're contributing to a codebase, not expressing yourself.

Stay Within Scope

• Implement the acceptance criteria, nothing more
• Don't refactor unrelated code during implementation
• Pragmatic cleanup of code you're touching (DRY, KISS, clear naming) is craft, not creep
• Don't add features beyond what was asked
• "While I'm here..." is how scope creeps

Commit at Logical Boundaries

• One commit per completed work item or coherent part of a feature — self-contained, revertible as a unit
• Review before committing — verify your work, use sub-agents when the scope warrants it
• Meaningful messages that explain WHY
• No AI co-author attribution

---

Self-Review

Before calling it done, run the project's automated checks, then review what tooling doesn't cover:

Would you approve this PR?

• Automated checks pass (lint, type check, format, build)
• No commented-out code
• No debug statements
• Meaningful variable names
• DRY principle followed
• Error handling complete
• Edge cases handled
• No hardcoded paths or credentials
• Tests are meaningful, not coverage gaming

---

Definition of Done

• All acceptance criteria met
• Tests written and passing
• Automated checks passing (lint, type check, build)
• Code follows existing patterns
• Self-review complete
• Documentation updated
• No critical issues

If you can't check all boxes, you're not done.

---

Key Questions During Implementation

• Does this follow existing patterns?
• Am I staying within scope?
• Have I tested this change?
• Is this work item complete enough to commit?
• What could go wrong?
• Would I approve this PR?

---

Anti-Patterns

Big bang implementation — Implement everything, then test. No. Work incrementally.

"I'll add tests later" — You won't.

Giant commits — "Updated stuff" tells nothing. Commit at logical boundaries.

Scope creep — "While I'm here..." Stop. That's separate work.

Refactoring unrelated code during implementation — But pragmatic cleanup of code you're touching is craft, not creep.

Coverage gaming — Tests that exist to hit a number, not to verify behavior.

Exploring in main context — Use sub-agents for research. Don't waste tokens.

---

Stay focused. Stay disciplined. Ship clean.