Cook

Purpose

Cook is the end-to-end feature builder orchestrator. It takes a feature request, user story, or task description and drives it through every stage of development -- from initial planning and research all the way through coding, testing, code review, and preparing to ship. Think of it as the "chef" that coordinates the entire kitchen: it delegates specialized work to hub and utility skills while maintaining the big picture.

Cook ensures that no step is skipped. Features built through Cook always have a plan, are informed by research, follow existing codebase patterns, include tests, pass review, and are commit-ready.

Workflow

Phase 1: Understand & Plan

1. Parse the request -- Extract the core feature, constraints, acceptance criteria, and scope from the user's input.
2. Invoke plan -- Generate a structured implementation plan with milestones, dependencies, and risk flags.
3. Invoke research (if needed) -- Look up library docs, API references, or patterns via Context7 or web search when the feature touches unfamiliar territory.
4. Invoke sequential-thinking (if complex) -- For multi-step logic or architectural decisions, use structured reasoning to resolve ambiguity before writing code.

Phase 2: Scout & Prepare

5. Invoke scout -- Scan the codebase for related files, existing patterns, naming conventions, and integration points. Identify where the new code should live and what it should conform to.
6. Summarize findings -- Present a brief to the user: "Here's the plan, here's what I found in the codebase, here's my approach." Wait for confirmation if the task is high-risk or ambiguous.

Phase 3: Implement

7. Write the code -- Implement the feature following the plan, adhering to patterns discovered by scout, and respecting all project guidelines (single responsibility, separation of concerns, DRY).
8. Invoke refactor (if needed) -- If existing code must be restructured to accommodate the feature cleanly, delegate refactoring to the refactor skill.
9. Invoke optimize (if needed) -- If the implementation has obvious performance concerns, run optimization passes.

Phase 4: Test

10. Invoke test -- Generate and run tests for the new feature. This includes unit tests, integration tests if applicable, and edge-case coverage.
11. Fix failures -- If tests fail, invoke fix or debug to resolve issues. Re-run tests until green.

Phase 5: Review

12. Invoke code-review -- Run a self-review pass on all changed files. Check for code quality, security issues, adherence to project patterns, and completeness against the original plan.
13. Address review findings -- Fix any issues surfaced by review. Re-review if changes were significant.

Phase 6: Prepare to Ship

14. Invoke commit-crafter -- Create well-structured commit(s) with meaningful messages.
15. Invoke docs-writer (if needed) -- Update or create documentation if the feature warrants it.
16. Report completion -- Present a summary of what was built, what was tested, and what's ready to ship. Suggest invoking ship or pr-writer as the next step.

Decision Points

Condition	Action
Feature touches unknown library	Invoke research before coding
Feature requires architectural change	Invoke sequential-thinking then confirm with user
Existing code needs restructuring	Invoke refactor before or during implementation
Tests fail after implementation	Invoke fix or debug, then re-test
Review surfaces critical issues	Fix and re-review before proceeding
Feature is trivial (< 20 lines)	Skip plan formal output, still scout and test

Usage

Use Cook when you have a well-defined feature or task and want it handled completely. Cook is the default choice for "build this thing" requests.

Best for:

• New features with clear requirements
• Bug fixes that need proper test coverage
• Enhancements to existing features
• Tasks where you want the full quality pipeline

Not ideal for:

• Pure exploration or research (use research or brainstorm directly)
• Release management (use ship)
• Codebase audits (use audit)
• Multi-team coordination (use team to orchestrate multiple cooks)

Examples

Example 1: Simple feature

User: /cook Add a dark mode toggle to the settings page

Cook workflow:
1. plan -> Identify settings page location, toggle component needs, theme system
2. scout -> Find existing theme files, settings page components, CSS variables
3. Implement -> Create toggle component, wire up theme context, add CSS variables
4. test -> Unit test toggle behavior, integration test with settings page
5. code-review -> Check accessibility, contrast ratios, state persistence
6. commit-crafter -> "Add dark mode toggle to settings page"

Example 2: Complex feature

User: /cook Implement real-time collaborative editing for document pages

Cook workflow:
1. plan -> Architecture decision (WebSocket vs SSE), conflict resolution strategy
2. research -> Look up CRDT libraries, WebSocket patterns via Context7
3. sequential-thinking -> Resolve operational transform vs CRDT trade-offs
4. scout -> Find document model, existing API routes, auth middleware
5. Implement -> WebSocket server, CRDT integration, cursor presence UI
6. refactor -> Restructure document save flow to support real-time
7. test -> Unit tests for CRDT ops, integration tests for sync
8. code-review -> Security review of WebSocket auth, performance review
9. commit-crafter -> Series of atomic commits for each component
10. docs-writer -> Update API docs with WebSocket endpoints

Example 3: Bug fix

User: /cook Fix the login form not validating email addresses properly

Cook workflow:
1. scout -> Find login form component, existing validation logic
2. plan -> Identify the validation gap, plan the fix
3. Implement -> Fix email regex or validation library usage
4. test -> Add test cases for valid/invalid emails, edge cases
5. code-review -> Verify fix doesn't break other validation
6. commit-crafter -> "Fix email validation in login form"

Guardrails

• Always scout before coding. Never write code without understanding the codebase context.
• Always test. No feature ships from Cook without at least unit-level test coverage.
• Always review. Even small changes get a code-review pass.
• Respect the plan. If the plan said 3 files, don't touch 12 without re-planning.
• Ask when uncertain. If a decision is ambiguous and high-impact, surface it to the user rather than guessing.