| name | cook-fullstack |
| description | Workflow orchestration for fullstack projects (Next.js, Nuxt, SvelteKit — API + UI). Structured phases — Plan, Design, Code API, Code UI, Review, Test — with memory-bank integration for session continuity. |
Cook — Fullstack Workflow
Structured workflow for fullstack projects. Every non-trivial task flows through ordered phases.
Plan → Design → Code (API first) → Code (UI) → Review → Test
Memory Bank — Required for Every Session
At the start of EVERY session, read all files in memory-bank/:
projectbrief.md — Core requirements and goals
productContext.md — Problem and solution context
techContext.md — Technical setup and dependencies
systemPatterns.md — Architecture and design patterns
activeContext.md — Current work focus and recent changes
progress.md — Completed work and known issues
If memory-bank/ does not exist, create it with the files above based on what you learn from the codebase.
After completing work (end of Test phase or any stopping point), update:
activeContext.md — What was done, current state, next steps
progress.md — Mark completed items, add new known issues
This ensures continuity across sessions. Never skip this step.
[PLAN] Plan
- Read requirements. Identify both API and UI changes needed.
- Break into backend subtasks and frontend subtasks separately.
- Define the API contract (endpoints, request/response shapes) as the boundary.
- Define acceptance criteria for the full user flow.
Output: Numbered plan with API contract and component changes.
Rule: No code in this phase.
[DESIGN] Design
- Design API contract first — it's the bridge between layers.
- Define component hierarchy and data fetching strategy.
- Plan optimistic UI, loading states, and error handling.
Output: API contract, component signatures, and data flow.
Rule: Match existing patterns in both layers.
[CODE] Code — API First
- Implement backend: models → services → routes.
- Validate the API works (test endpoint manually or with integration test).
- Then implement frontend against the real API.
- Wire up data fetching, mutations, and error handling.
Rule: Backend must be working before building the frontend against it.
[REVIEW] Review
Backend checks:
- API contract — Do endpoints match the spec? Correct HTTP methods and status codes?
- Validation — Is all user input validated before reaching business logic?
- Security — No SQL injection, no exposed secrets, proper auth checks?
- Error handling — Do all error paths return meaningful responses?
Frontend checks:
5. Visual — Does it match the requirements? Responsive on mobile/tablet/desktop?
6. Accessibility — Keyboard navigable? Screen reader friendly?
7. State — No unnecessary re-renders? Proper cleanup of effects/subscriptions?
Integration checks:
8. Contract — Does the frontend match the API contract exactly?
9. Error propagation — Do API errors surface as user-friendly messages?
10. Loading — Are there loading states for every async operation?
Fix issues immediately. If a design flaw is found, loop back to Design.
[TEST] Test
- Backend: Unit tests for services + integration tests for API endpoints.
- Frontend: Component tests for UI + test data fetching with mocked API.
- End-to-end: Test the full user flow if E2E tests exist in the project.
- Run type checker and linter for both layers.
Rules:
- Test behavior, not implementation. Test error paths, not just happy paths.
- Never mark done with failing tests.
Iteration
If any phase reveals problems:
- Test failures from a bug → Fix in Code, re-run Review + Test.
- Review reveals missing requirements → Loop back to Plan.
- Design flaw found during Code → Loop back to Design.
- User feedback changes scope → Restart from Plan.
Always note which phase you're returning to and why.
Phase Markers
Prefix progress with the current phase:
[PLAN] Analyzing requirements...
[DESIGN] Defining API contract and components...
[CODE] Implementing API layer...
[CODE] Implementing UI layer...
[REVIEW] Self-reviewing changes...
[TEST] Running integration tests...