Cook anything

Cook Anything

Treat the user's prompt, specifications, skills, and context as the map. Treat the actual codebase, users, constraints, and real-world behavior as the territory. Find and reduce the gap between them before it becomes expensive implementation rework.

Use the exact 5 + 1 + 2 workflow below. Do not silently skip, merge, reorder, or abbreviate steps. A step may be marked Not applicable only after documenting concrete evidence and obtaining the user's agreement.

Operating contract

1. State the current phase and step in each substantive progress update.
2. Keep an artifact ledger in status.md and update it when each gate changes state.
3. Do not begin production implementation until Steps 1-5 pass their gates.
4. Do not declare the workflow complete until Steps 7-8 pass their gates.
5. Surface uncertainty. Never convert an assumption into a fact without labeling it.
6. Search the project before asking the user a question the codebase or supplied materials can answer.
7. Prefer cheap, reversible discovery over early production changes.
8. Match the project's existing documentation convention. If none exists, create docs/cook-anything/ and place all required artifacts there.

At entry, announce the artifact directory and initialize status.md with this checklist:

# Cook Anything Status

- [ ] 1. Blind spot pass
- [ ] 2. Brainstorms and prototypes
- [ ] 3. Interview
- [ ] 4. References
- [ ] 5. Implementation plan
- [ ] 6. Implementation notes
- [ ] 7. Pitch and explainer
- [ ] 8. Learning report and quiz

Do not create placeholder documents for later steps. Create each artifact when doing that step.

Phase A: Before implementation

Step 1: Blind spot pass

Establish the user's starting point before proposing a solution.

Required behavior:

• Restate the intended outcome, audience, current evidence, constraints, and success criteria.
• Record what the user knows, what they know they do not know, what they may recognize only when shown, and what they have not considered.
• Inspect relevant project files, history, documentation, and authoritative external sources when needed.
• Identify unknown unknowns, historical constraints, dependencies, failure modes, security or privacy concerns, operational risks, and missing acceptance criteria.
• Distinguish facts, assumptions, open questions, and recommendations.
• Rewrite the working project brief using the discoveries. Do not implement.

Required artifact: 01-blind-spot-pass.md

It must contain:

• Problem and desired outcome
• User starting point and experience
• Known knowns
• Known unknowns
• Unknown knowns to elicit
• Unknown unknowns and blind spots
• Assumption register with evidence status
• Constraints and failure modes
• Draft success criteria
• Rewritten project brief

Gate 1 passes only when the unknown categories, assumptions, and revised brief are explicit enough to guide option generation.

Step 2: Brainstorms and prototypes

Use alternatives and cheap experiments to expose preferences the user cannot yet verbalize.

Required behavior:

• Generate 3-5 meaningfully different approaches. Do not produce cosmetic variations of one idea.
• Label the belief or user need each approach bets on.
• Compare scope, value, cost, risk, reversibility, and implications for the final implementation.
• Build the cheapest useful prototype or experiment for the highest-impact uncertainty.
• Use fake data, isolated files, disposable branches, mock interfaces, wireframes, or small technical spikes as appropriate.
• Do not connect production services, migrate real data, or add production architecture during this step.
• Ask the user to react to concrete alternatives and record what resonates or fails.

Required artifact: 02-brainstorms-and-prototypes.md, plus any prototype files it references.

It must contain:

• Approaches and their underlying bets
• Comparison table
• Prototype question and scope
• Prototype location or evidence
• User reactions
• Selected direction and rejected directions with reasons
• Newly discovered unknowns

Gate 2 passes only when a direction is selected and the user's implicit preferences have been converted into explicit criteria.

Step 3: Interview

Resolve remaining ambiguities through a focused interview.

Required behavior:

• Ask exactly one question at a time.
• Prioritize questions whose answers could change architecture, data models, user flows, permissions, security boundaries, migration strategy, or scope.
• Do not ask questions that project inspection can answer.
• Explain briefly why a question matters when its impact is not obvious.
• Record every answer as a decision, constraint, preference, deferred decision, or unresolved risk.
• Continue until no unresolved high-impact ambiguity remains.

Required artifact: 03-interview-decisions.md

It must contain:

• Questions and user answers
• Decision log
• Confirmed constraints and preferences
• Deferred decisions with owners or triggers
• Remaining low-impact unknowns
• Updated acceptance criteria

Gate 3 passes only when all architecture-changing questions are answered or explicitly deferred with a safe handling rule.

Step 4: References

Use real examples to specify behavior that words alone do not capture.

Required behavior:

• Search supplied materials and the codebase for relevant existing implementations before searching externally.
• Prefer working source code over screenshots; prefer authoritative documentation over summaries.
• Identify exactly what should be borrowed: semantics, interaction, structure, visual language, data model, algorithm, or operational behavior.
• Read references closely enough to extract inputs, outputs, state transitions, edge cases, error handling, and user-observable behavior.
• Separate reusable behavior from reference-specific technology or style.
• Check licensing or redistribution constraints before copying implementation details.
• If no suitable reference exists, document the search performed and use the closest validated evidence rather than pretending one exists.

Required artifact: 04-reference-semantics.md

It must contain:

• Reference inventory and source locations
• Why each reference is relevant
• Semantic behavior to preserve
• Elements not to copy
• Edge cases and failure behavior
• Licensing or attribution constraints
• Implications for the current project

Gate 4 passes only when the selected reference behavior is described independently of its original implementation.

Step 5: Implementation plan

Turn the discoveries into a reviewable implementation contract.

Required behavior:

• Lead with decisions the user is most likely to change.
• Present data model changes, type or API contracts, user-facing flows, permissions, security, migrations, and irreversible operations before mechanical work.
• For every high-impact decision, provide the recommendation, alternatives, rationale, and consequences.
• Map each acceptance criterion to implementation work and verification.
• Define milestones, dependencies, rollback strategy, test strategy, and unresolved risks.
• Put routine refactors, file lists, and mechanical edits at the end.
• Present the plan to the user and obtain explicit approval before production implementation.

Required artifact: 05-implementation-plan.md

It must contain:

• Approved direction and scope boundaries
• High-impact decisions and alternatives
• Architecture and data flow
• User-visible behavior
• Data, type, API, permission, and migration changes
• Milestones and ordered tasks
• Acceptance-criterion-to-verification matrix
• Test and rollback strategy
• Risks, assumptions, and deferred work
• Mechanical work appendix
• Approval record

Gate 5 passes only after the user explicitly approves the plan and all blocking risks have a handling decision.

Phase B: During implementation

Step 6: Implementation notes

Implement the approved plan while preserving a trustworthy record of discoveries and deviations.

Required behavior:

• Create implementation-notes.md before the first production change and keep it current throughout implementation.
• Record meaningful discoveries, decisions, verification results, and plan deviations as they happen.
• When an edge case requires deviation, choose the conservative and reversible option, record it under Deviations, and continue.
• Pause for the user only when a deviation changes product direction, creates irreversible data impact, weakens security or privacy, or invalidates an approved acceptance criterion.
• Keep changes scoped to the approved plan. Do not fold unrelated cleanup into the task.
• Verify incrementally at milestone boundaries, not only at the end.
• Update the implementation plan when an approved deviation changes the contract; preserve the original decision in the notes.

Required artifact: implementation-notes.md

It must contain these live sections:

• Progress by milestone
• Discoveries
• Decisions made during implementation
• Deviations: trigger, chosen response, rationale, impact, and reversibility
• Verification evidence
• Known limitations and remaining risks

Gate 6 passes only when the approved scope is implemented, acceptance checks pass or failures are documented, and every material deviation is traceable.

Phase C: After implementation

Step 7: Pitch and explainer

Package the result so a reviewer can understand and approve it without reconstructing the entire project history.

Required behavior:

• Lead with the working result: demo, screenshot, recording, executable example, or concise before-and-after evidence.
• Explain the problem, outcome, user impact, architecture, and key decisions.
• Show how the implementation handled the blind spots and likely failure points.
• Summarize deviations from the approved plan and why they were acceptable.
• Include verification evidence, known limitations, rollout or usage instructions, and rollback guidance.
• Tailor the explanation to reviewers who begin with the same unknowns the user originally had.

Required artifact: 07-pitch-and-explainer.md

It must contain:

• Demo first
• Executive summary
• Problem and resulting behavior
• Architecture or workflow explanation
• Key decisions and tradeoffs
• Unknowns addressed
• Plan deviations
• Verification evidence
• Known limitations, rollout, and rollback
• Review questions that still require expert judgment

Gate 7 passes only when the result and its evidence are reviewable without relying on chat history.

Step 8: Learning report and quiz

Confirm that the user understands what was built before closing the workflow.

Required behavior:

• Produce a learning report explaining the change with context, intuition, data flow, state transitions, key decisions, failure modes, debugging approach, and rollback.
• Create questions covering architecture, user behavior, edge cases, deviations, operations, and recovery.
• Ask exactly one quiz question at a time.
• Evaluate the substance of each answer. Do not accept vague or partially correct answers.
• Explain gaps, point the user back to the relevant report section, and retest the missed concept with a different question.
• Do not declare the workflow closed, ready to merge, or fully handed off until the user answers every required concept correctly.

Required artifact: 08-learning-report-and-quiz.md

It must contain:

• Context and mental model
• What changed and why
• Data and control flow
• Important decisions and tradeoffs
• Edge cases and failure modes
• How to verify, debug, and roll back
• Quiz question bank
• Quiz results and concepts requiring review

Gate 8 passes only when all required concepts are answered correctly and the result is recorded in the artifact.

Final handoff

After Gate 8 passes:

1. Mark all eight items complete in status.md.
2. Summarize the delivered outcome, verification, remaining limitations, and artifact directory.
3. Clearly separate completed scope from deferred work.
4. Never claim success for failed or unrun checks.

Quality checks

Before advancing any gate, verify:

• The artifact exists and contains every required section.
• Claims are supported by project evidence, user decisions, or cited authoritative sources.
• New unknowns are routed back to the relevant artifact instead of being hidden in chat.
• The current scope still matches the approved project outcome.
• The next step is allowed by the preceding gate.

If the user interrupts or changes direction, record the change in status.md, update affected artifacts, and resume from the earliest invalidated gate.