Rapid Prototyping from Client Requirements

A prototype that ships on time wins the next contract. A prototype that misses the demo date loses it. With Sun Agent Kit, you drop the client’s requirement docs, feature lists, and screen mockups into a folder, point /sk:brainstorm at it — the agent reads everything, extracts requirements, identifies gaps, and recommends a stack. From there, /sk:bootstrap scaffolds the project and per-feature /sk:plan + /sk:cook cycles drive it to completion before the client meeting.

Overview

Goal: Go from a client brief to a working, demo-ready prototype in under a day
Time: 2–4 hours (vs 2–3 days manual)
Agents used: planner, implementer, reviewer
Commands: /sk:brainstorm, /sk:research, /sk:ui-ux-pro-max, /sk:bootstrap, /sk:plan, /sk:cook, /sk:code-review, /sk:git

Prerequisites

• Sun Agent Kit installed (installation guide)
• Node.js 18+ or Bun runtime available
• Client documents in your project directory — requirement specs, feature lists, screen lists, meeting notes (PDF, Markdown, Word, or plain text all work)
• Git initialized in your target directory (git init)
• A clear demo deadline so the brainstorm agent can calibrate scope vs. speed trade-offs

Step-by-Step Workflow

Step 1: Brainstorm from Client Documents

/sk:brainstorm "read ./docs/client-brief/ — this contains the client's requirement spec, feature list, and screen mockups for a personal task manager. Brainstorm what's missing, suggest the fastest stack for a 3-day prototype, and flag any scope risks"

What happens: The agent:

1. Reads all files in the specified path — PDFs, Markdown, images, spreadsheets — and extracts requirements, features, and screen descriptions
2. Identifies gaps in the client docs: missing edge cases, undefined user flows, ambiguous requirements
3. Brainstorms additional features or improvements the client may not have considered
4. Recommends a stack optimized for prototype speed given the timeline
5. Outputs a confirmed feature list, stack decision, and a list of questions to clarify with the client

Step 2: Validate the Stack Choice

/sk:research "best lightweight stack for a task manager prototype — compare Node.js/Express vs Next.js for speed of prototyping, Bull queue vs cron for email reminders"

What happens: The agent:

1. Compares the candidate stacks against prototyping speed, ecosystem maturity, and integration complexity
2. Reviews Bull queue vs. cron for email reminders — surfacing queue persistence and retry behavior trade-offs
3. Returns a ranked recommendation with integration gotchas for the chosen stack
4. Confirms or challenges the brainstorm’s stack recommendation based on the requirements extracted from client docs

Step 3: Select Design Style

/sk:ui-ux-pro-max "personal task manager SaaS — recommend style, color palette, and typography for a professional prototype"

What happens: The agent:

1. Queries its design database — 50+ styles, 161 color palettes, 57 font pairings — filtered by your product type
2. Recommends a cohesive style direction (e.g., minimalism with a SaaS color palette and clean font pairing)
3. Outputs specific design tokens: primary/secondary colors, font stack, spacing scale, and component style guidelines
4. This context carries forward into /sk:cook — the implementer agent applies these choices instead of defaulting to generic styles

Step 4: Scaffold the Project

/sk:bootstrap "personal task manager: Next.js, PostgreSQL, Prisma, NextAuth for user auth, task CRUD with deadlines and priorities, Bull queue for email reminders, dashboard page"

What happens: The agent:

1. Generates folder structure, route stubs, and database schema matching your feature list
2. Installs and configures Next.js, Prisma, NextAuth, Bull, and all required dependencies
3. Creates .env.example, docker-compose.yml for local Postgres, and Prisma migrations
4. Runs an initial typecheck to confirm the scaffold compiles clean before you write a line of logic

Step 5: Plan Each Feature

/sk:plan "Feature 1: user auth + task CRUD. Feature 2: email reminders with Bull queue. Feature 3: dashboard with task statistics"

What happens: The agent:

1. Reads the scaffolded codebase and maps features to the generated file structure
2. Writes a focused phase file per feature under plans/ — each with tasks, acceptance criteria, and file ownership
3. Resolves dependencies between features (auth must land before tasks, tasks before dashboard)
4. Keeps each phase file tight so /sk:cook has a narrow, unambiguous scope per round

Step 6: Implement Feature by Feature

/sk:cook plans/{timestamp}-personal-task-manager/phase-01-auth-tasks.md

Repeat for phase-02-email-reminders.md and phase-03-dashboard.md.

What happens: The agent:

1. Reads the phase file and implements each task in dependency order
2. Writes service logic, API routes, database queries, and UI components for the feature
3. Runs typecheck and linting after each file to catch errors before they compound
4. Reports completion with a list of files changed and any deviations from the plan

Step 7: Prototype-Scoped Code Review

/sk:code-review --pending

What happens: The agent:

1. Reads all files changed since the last commit
2. Applies a prototype lens — crashes, broken routes, and demo-blocking bugs take priority
3. Skips production concerns (rate limiting, pagination defaults, full test coverage) unless they break the demo
4. Outputs a prioritized list of issues with fix recommendations, sorted by demo impact

Step 8: Commit the Prototype Baseline

/sk:git cm

What happens: The agent:

1. Stages all changed files, respecting .gitignore (.env excluded automatically)
2. Writes a conventional commit message summarizing the prototype state
3. Creates a baseline commit you can branch from for client feedback iterations

Complete Example: Task Manager Prototype for a Monday Demo

Scenario: A client sends a requirement spec (PDF), a feature list (spreadsheet), and screen mockups (Figma export) on Monday morning for a personal task management app. They want to see a working demo on Wednesday. You drop the files into ./docs/client-brief/ and start.

Monday morning you run:

# 1. Feed the client docs to brainstorm — it reads everything and fills the gaps
/sk:brainstorm "read ./docs/client-brief/ — this contains the client's requirement spec, feature list, and screen mockups for a personal task manager. Brainstorm what's missing, suggest the fastest stack for a 3-day prototype, and flag any scope risks"

# 2. Validate the stack recommendation
/sk:research "best lightweight stack for a task manager prototype — compare Node.js/Express vs Next.js for speed of prototyping, Bull queue vs cron for email reminders"

# 3. Pick a design style before scaffolding
/sk:ui-ux-pro-max "personal task manager SaaS — recommend style, color palette, and typography for a professional prototype"

# 4. Scaffold with the confirmed stack
/sk:bootstrap "personal task manager: Next.js, PostgreSQL, Prisma, NextAuth for user auth, task CRUD with deadlines and priorities, Bull queue for email reminders, dashboard page"

# 5. Plan each feature as its own phase
/sk:plan "Feature 1: user auth + task CRUD. Feature 2: email reminders with Bull queue. Feature 3: dashboard with task statistics"

# 6. Implement feature by feature
/sk:cook plans/{timestamp}-personal-task-manager/phase-01-auth-tasks.md
/sk:cook plans/{timestamp}-personal-task-manager/phase-02-email-reminders.md
/sk:cook plans/{timestamp}-personal-task-manager/phase-03-dashboard.md

# 7. Prototype-scoped review — crashes and demo blockers only
/sk:code-review --pending

# 8. Commit the baseline
/sk:git cm

Result: By Monday afternoon, you have a working prototype running locally — login, task creation with deadlines and priorities, a Bull queue wiring up reminder emails, and a dashboard that shows task statistics. Every feature traces back to the client’s own docs. You demo on Wednesday with two full days to spare for client feedback.

Time Comparison

Best Practices

1. Scope the prototype explicitly during brainstorm ✅

Tell the agent “demo-ready” not “production-ready”. The brainstorm step exists to draw that line — use it to kill features that don’t fit the deadline before the scaffold is built.

2. Select a design style before scaffolding ✅

Run /sk:ui-ux-pro-max after brainstorm confirms the product type. The style, color palette, and typography choices feed into every /sk:cook cycle — picking them upfront prevents the “generic Tailwind default” prototype look.

3. Use per-feature plan + cook cycles ✅

One giant cook run over an unscoped codebase produces unfocused output. Keep each phase file to a single feature so the implementer agent has a narrow, reviewable scope per pass.

4. Tell code-review the prototype context ✅

Pass context with the review: “this is a prototype for a client demo, not production code”. The reviewer agent adjusts its lens — crash-level bugs first, production hardening deferred.

5. Put all client docs in one folder before brainstorm ✅

Drop requirement specs, feature lists, screen mockups, and meeting notes into a single directory (e.g., ./docs/client-brief/). The brainstorm agent reads everything in the path — scattered files across your machine mean missed requirements.

6. Skipping brainstorm and bootstrapping without reading client docs ❌

/sk:bootstrap "build a task app" generates a generic skeleton that won’t match the client’s actual requirements. Feed the client’s own documents to /sk:brainstorm first — it extracts what the client wrote, identifies what’s missing, and produces a feature list grounded in evidence.

7. Polishing the prototype to production-grade ❌

Rate limiting, full test coverage, pagination defaults, and i18n have no place in a prototype sprint. That work belongs in Start a New Project after the client signs off.

Troubleshooting

Problem: Bootstrap selects the wrong stack

Solution: The brainstorm agent may not have extracted enough detail from the client docs. Re-run /sk:brainstorm with tighter constraints — point it to specific files: "read ./docs/client-brief/tech-requirements.pdf and pick a stack that matches the client's existing infrastructure". Then re-run /sk:bootstrap with the confirmed stack.

Problem: Plan generates too many tasks per feature phase

Solution: The feature scope in your plan prompt is too broad. Narrow it to a single vertical slice: /sk:plan "Feature 1: NextAuth email/password login and Prisma user table only". Run /sk:plan for each feature separately rather than listing all three in one prompt.

Problem: Cook drifts from the plan

Solution: Always pass the explicit phase file path to cook — not a text description of what you want. /sk:cook plans/{timestamp}-personal-task-manager/phase-01-auth-tasks.md grounds the agent in the written spec. Text prompts produce interpretation drift.

Problem: Code review flags too many issues for a prototype

Solution: Remind it of the context in the command: /sk:code-review --pending "this is a prototype for a client demo — flag crashes and broken routes only, defer production hardening". The reviewer agent scales its standards to the stated purpose.

Problem: Prototype UI looks generic despite using cook

Solution: You skipped the design style step. Run /sk:ui-ux-pro-max with your product type before the next /sk:cook cycle — it queries 50+ styles and 161 color palettes to recommend a cohesive design direction. The implementer agent picks up these choices automatically.

Next Steps

• Client Upsale Proposal — turn the prototype engagement into a longer contract
• Project Migration — when the prototype needs to move to a production stack
• Start a New Project — the full production path when you’re past the prototype stage
• Add a New Feature — extend the prototype with additional features

Key takeaway: Start from the client’s own documents, not a text summary in your head — /sk:brainstorm reads the files, extracts requirements, and fills the gaps. /sk:ui-ux-pro-max sets the visual direction. /sk:bootstrap scaffolds it, and per-feature /sk:plan + /sk:cook cycles deliver it before the client meeting.