\r \r

Client Onboard — Freelance Project Onboarding Generator\r

\r

Why This Exists\r

Kevin closes a client → now needs to look professional and get the project moving within 24 hours. Manual onboarding prep = 2 hours of doc writing. This skill turns a project description into a full onboarding package in one shot.\r \r

Trigger\r

Use when: "onboard a new client", "I just got a project", "set up client files for", "new client [description]", or any time a new freelance project is starting.\r \r Invoked as: /client-onboard [project description]\r \r ---\r \r

Process\r

\r

Step 1: Parse the Project\r

\r From $ARGUMENTS, extract:\r

• Project type: web app, API, automation, audit, mobile, data pipeline, etc.\r
• Client industry: SaaS, ecommerce, healthcare, finance, creator economy, etc.\r
• Timeline hints: "need this in 2 weeks", "no rush", "ASAP", specific dates mentioned\r
• Budget hints: hourly rate mentioned, fixed price, "small budget", enterprise\r
• Tech constraints: "must use React", "we're on AWS", "no vendor lock-in"\r
• Team context: "solo founder", "we have a dev team", "replacing a contractor"\r \r Default assumptions when not specified:\r
• Timeline: 4-6 weeks (reasonable for most web projects)\r
• Budget: $75/hr or $2,000-5,000 fixed (Kevin's standard range)\r
• Stack: Next.js + Supabase + Stripe + Python (Kevin's default)\r
• Deployment: Vercel (frontend) + Railway or Supabase (backend)\r \r ---\r \r

Step 2: Create the Output Directory\r

\r Create CLIENT_ONBOARD/ in the current directory.\r \r

mkdir -p CLIENT_ONBOARD\r
```\r
\r
If a client name is identifiable from `$ARGUMENTS`, use: `[ClientName]_ONBOARD/` instead.\r
\r
---\r
\r
### Step 3: Write PROJECT_BRIEF.md\r
\r
```markdown\r
# Project Brief — [Project Name]\r
Client: [client name or "TBD"]\r
Date: [today's date]\r
Status: DRAFT — pending client confirmation\r
\r
---\r
\r
## Project Overview\r
[2-3 sentences. What is being built, for whom, and why it matters to the client's business. Be specific — no "robust scalable solution" language.]\r
\r
## Business Goal\r
[What does the client actually need this to DO for their business? Revenue impact? Time savings? User growth?]\r
\r
## Success Criteria\r
- [ ] [Specific measurable outcome 1]\r
- [ ] [Specific measurable outcome 2]\r
- [ ] [Specific measurable outcome 3]\r
- [ ] All features from this brief are delivered and tested\r
- [ ] Client signs off on final deliverable\r
\r
## Key Users\r
- **Primary**: [who uses this most, what they need]\r
- **Secondary**: [any other users]\r
- **Admin**: [Kevin or client manages this]\r
\r
## Core Features (In Scope)\r
1. [Feature 1 — brief description]\r
2. [Feature 2 — brief description]\r
3. [Feature 3 — brief description]\r
[...continue for all core features...]\r
\r
## Out of Scope (v1)\r
- [Feature that sounds related but isn't included] — defer to v2\r
- [Feature] — available as add-on after launch\r
- [Feature] — client can self-manage post-launch\r
\r
## Known Risks\r
- [Risk 1]: [mitigation]\r
- [Risk 2]: [mitigation]\r
\r
## Open Questions\r
- [ ] [Question that needs client answer before starting]\r
- [ ] [Question]\r
\r
---\r
*This brief is a living document. Changes require written agreement from both parties.*\r
```\r
\r
---\r
\r
### Step 4: Write TECH_STACK.md\r
\r
```markdown\r
# Tech Stack — [Project Name]\r
Decided: [today's date]\r
\r
---\r
\r
## Recommended Stack\r
\r
### Frontend\r
- **Framework**: Next.js 14+ (App Router)\r
  - *Why*: [specific reason for this project — e.g., "SEO required", "fast iteration", "familiar to Kevin"]\r
- **UI**: Tailwind CSS + Shadcn/UI components\r
  - *Why*: Ships faster than custom CSS, consistent design system\r
- **State**: Zustand (client state) + React Query (server state)\r
- **TypeScript**: Yes — catches bugs before they reach the client\r
\r
### Backend\r
- **Database + Auth + Storage**: Supabase (Postgres)\r
  - *Why*: [specific reason — e.g., "handles auth out of the box", "real-time subscriptions needed", "generous free tier for MVP"]\r
- **Edge Functions**: Supabase Edge Functions (Deno)\r
  - *Why*: Co-located with DB, no cold starts on Vercel hobby plan\r
- **[If needed] Python API**: FastAPI\r
  - *Why*: [e.g., "AI/ML workloads", "batch processing", "heavier compute"]\r
\r
### Payments (if applicable)\r
- **Stripe**: Checkout, webhooks, Customer Portal\r
  - *Why*: Industry standard, great DX, handles PCI compliance\r
\r
### Deployment\r
- **Frontend**: Vercel (auto-deploy on git push)\r
- **Backend**: Supabase managed (no ops)\r
- **[If needed] Workers**: Railway (simple, cheap, no k8s)\r
\r
### AI/Automation (if applicable)\r
- **LLM**: Anthropic Claude API (claude-sonnet-4-6)\r
- **Orchestration**: Custom Python agent or Claude Code skill\r
\r
---\r
\r
## Alternatives Considered\r
| Option | Why Rejected |\r
|--------|-------------|\r
| [Alt 1] | [reason] |\r
| [Alt 2] | [reason] |\r
\r
## Stack Risks & Mitigations\r
- **Supabase vendor lock-in**: Postgres is standard — can self-host if needed\r
- **Vercel pricing at scale**: Set spending limits, switch to Railway if traffic spikes\r
```\r
\r
Customize the stack to the project — if the client specifies AWS, remove Vercel; if they need mobile, add React Native; etc.\r
\r
---\r
\r
### Step 5: Write MILESTONES.md\r
\r
```markdown\r
# Milestones — [Project Name]\r
Total estimated timeline: [X] weeks\r
Start date: [today or TBD]\r
Target completion: [date or TBD]\r
\r
---\r
\r
## Milestone 1: Foundation — Week 1-2\r
**Goal:** Project structure, auth, and core data models in place. Nothing works end-to-end yet, but the scaffolding is solid.\r
\r
**Deliverables:**\r
- [ ] Repo setup with CI/CD (Vercel auto-deploy)\r
- [ ] Supabase project + schema (tables, RLS policies)\r
- [ ] Auth flow (login, signup, session management)\r
- [ ] Basic navigation shell\r
- [ ] CLAUDE.md updated with project conventions\r
\r
**Handoff criteria:** Kevin demos a working login → dashboard skeleton. Client confirms schema looks right.\r
\r
---\r
\r
## Milestone 2: Core Features — Week 2-4\r
**Goal:** The main thing the client paid for is built and working.\r
\r
**Deliverables:**\r
- [ ] [Core feature 1] — built and tested\r
- [ ] [Core feature 2] — built and tested\r
- [ ] [Core feature 3] — built and tested\r
- [ ] Error states and loading states implemented\r
- [ ] Mobile responsive\r
\r
**Handoff criteria:** Client can use the app end-to-end for the primary use case.\r
\r
---\r
\r
## Milestone 3: Polish + Integrations — Week 4-5\r
**Goal:** Third-party integrations, edge cases handled, UI polished.\r
\r
**Deliverables:**\r
- [ ] [Payment / email / analytics integration]\r
- [ ] Edge cases from testing handled\r
- [ ] Performance check (Lighthouse score > 85)\r
- [ ] Security review (RLS policies, input validation, env vars)\r
\r
**Handoff criteria:** App is production-ready. No known bugs.\r
\r
---\r
\r
## Milestone 4: Launch + Handoff — Week 5-6\r
**Goal:** Live in production, client can operate it.\r
\r
**Deliverables:**\r
- [ ] Production deployment (custom domain, SSL)\r
- [ ] Monitoring set up (Sentry or basic error logging)\r
- [ ] Client walkthrough recording (Loom)\r
- [ ] Admin documentation (how to manage users, content, etc.)\r
- [ ] Code repo access transferred\r
\r
**Handoff criteria:** Client signs off. Final invoice sent.\r
\r
---\r
\r
## Payment Schedule (suggested)\r
- 25% upfront (project kickoff)\r
- 25% Milestone 2 complete\r
- 25% Milestone 3 complete\r
- 25% final delivery + sign-off\r
```\r
\r
Adjust milestone count and timeline to match project scope. Small projects (1-2 weeks): 2 milestones. Large projects (8+ weeks): 5-6 milestones.\r
\r
---\r
\r
### Step 6: Write FOLDER_STRUCTURE.md\r
\r
Generate a proposed directory layout tailored to the project. Standard Next.js + Supabase layout:\r
\r
```markdown\r
# Folder Structure — [Project Name]\r
\r
```\r
[project-name]/\r
├── src/\r
│   ├── app/                    # Next.js App Router pages\r
│   │   ├── (auth)/             # Auth-gated routes\r
│   │   │   ├── dashboard/\r
│   │   │   └── settings/\r
│   │   ├── (public)/           # Public routes\r
│   │   │   ├── page.tsx        # Landing page\r
│   │   │   └── pricing/\r
│   │   ├── api/                # API routes\r
│   │   │   └── webhooks/\r
│   │   ├── layout.tsx\r
│   │   └── globals.css\r
│   ├── components/\r
│   │   ├── ui/                 # Shadcn/UI base components\r
│   │   └── [feature]/          # Feature-specific components\r
│   ├── lib/\r
│   │   ├── supabase/           # DB client + type-safe helpers\r
│   │   ├── stripe/             # Stripe client + webhook handlers\r
│   │   └── utils.ts\r
│   ├── hooks/                  # Custom React hooks\r
│   └── types/                  # Shared TypeScript types\r
├── supabase/\r
│   ├── migrations/             # SQL migration files\r
│   └── functions/              # Edge functions\r
├── scripts/                    # One-off scripts + automation\r
├── docs/                       # Client-facing documentation\r
│   └── ADMIN_GUIDE.md\r
├── .env.local                  # Local env vars (not committed)\r
├── .env.example                # Template for env vars\r
├── CLAUDE.md                   # Claude Code context for this project\r
├── SPEC.md                     # Project specification\r
└── package.json\r
```\r
```\r
\r
Adjust to the actual stack. Python-only projects get a different layout.\r
\r
---\r
\r
### Step 7: Write CLAUDE.md (Project Starter)\r
\r
```markdown\r
# [Project Name] — Claude Code Context\r
\r
## What This Is\r
[1-2 sentences from PROJECT_BRIEF — what this project does]\r
\r
## Stack\r
- Frontend: Next.js 14 (App Router), TypeScript, Tailwind, Shadcn/UI\r
- Backend: Supabase (Postgres + Auth + Edge Functions)\r
- Payments: Stripe\r
- Deployment: Vercel\r
\r
## Key Paths\r
- App pages: `src/app/`\r
- Components: `src/components/`\r
- DB helpers: `src/lib/supabase/`\r
- DB schema: `supabase/migrations/`\r
- Edge functions: `supabase/functions/`\r
\r
## Dev Commands\r
```bash\r
npm run dev          # start local dev server (localhost:3000)\r
npm run build        # production build\r
npm run lint         # ESLint check\r
supabase start       # start local Supabase (Docker required)\r
supabase db push     # apply migrations to remote\r
```\r
\r
## Environment Variables\r
See `.env.example` for required vars. Local values in `.env.local` (not committed).\r
\r
## Conventions\r
- TypeScript strict mode — no `any`, no unchecked nulls\r
- Components: PascalCase, one component per file\r
- DB types: generate from Supabase dashboard → TypeScript types\r
- API routes: validate input with Zod before touching DB\r
- RLS: every table has Row Level Security enabled\r
\r
## Current Status\r
[Today's date] — Project just started. Milestone 1 in progress.\r
\r
## Known Gotchas\r
- [Any project-specific things Claude should know]\r
```\r
\r
---\r
\r
### Step 8: Write KICKOFF_MSG.md\r
\r
Write a message Kevin can send directly to the client — professional, warm, no fluff:\r
\r
```markdown\r
# Kickoff Message — Ready to Send\r
\r
---\r
\r
Hey [Client Name],\r
\r
Great to officially be on board — excited to build [project name] with you.\r
\r
I've put together the initial project brief and milestone breakdown based on our conversation. Before I write a single line of code, I want to make sure we're aligned on scope and timeline.\r
\r
Quick asks:\r
\r
1. **Review the scope**: Does the feature list match what you're expecting? Anything missing or that should be cut from v1?\r
\r
2. **One open question**: [Most important open question from PROJECT_BRIEF.md]\r
\r
3. **Kickoff call**: I'd like to do a 30-minute call this week to align on priorities and answer any questions you have. What does your schedule look like [Tuesday-Thursday]? I'm flexible between 10am-4pm ET.\r
\r
Once we're aligned, I'll kick off Milestone 1 and have a working foundation for you to see within [X] days.\r
\r
Let me know if you have any questions before then — happy to jump on a quick call or answer over message.\r
\r
— Kevin\r
\r
---\r
\r
*[Attach: PROJECT_BRIEF.md or paste the scope section inline]*\r
```\r
\r
---\r
\r
### Step 9: Print Summary\r
\r
```\r
Client onboarding package created.\r
\r
Directory: ./CLIENT_ONBOARD/ (or ./[ClientName]_ONBOARD/)\r
\r
Files generated:\r
  ✓ PROJECT_BRIEF.md     — scope, goals, out-of-scope\r
  ✓ TECH_STACK.md        — recommended stack with rationale\r
  ✓ MILESTONES.md        — [X] milestones, [Y]-week timeline\r
  ✓ FOLDER_STRUCTURE.md  — proposed directory layout\r
  ✓ CLAUDE.md            — project context for Claude Code\r
  ✓ KICKOFF_MSG.md       — client message, ready to send\r
\r
Next steps:\r
  1. Review PROJECT_BRIEF.md — confirm scope is accurate\r
  2. Adjust MILESTONES.md timeline if needed\r
  3. Send KICKOFF_MSG.md to client (customize [Client Name])\r
  4. Copy CLAUDE.md into the new project repo root\r
  5. Invoice 25% upfront before starting work\r
```\r
\r
---\r
\r
## Error Handling\r
\r
- **Very vague description** ("build me an app"): Generate with defaults + add 5 open questions to PROJECT_BRIEF.md under "Open Questions" — flag that client answers are required before kicking off\r
- **Multiple possible stacks**: Choose Kevin's default stack, add "Alternatives Considered" section explaining why alternatives were skipped\r
- **Unclear budget**: Leave payment schedule with placeholder percentages, note "confirm rate with client before sending"\r
- **CLIENT_ONBOARD/ already exists**: Add timestamp suffix `CLIENT_ONBOARD_[YYYY-MM-DD]/` to avoid overwriting\r
- **Missing tech details**: Generate best-guess and mark assumptions clearly with `[ASSUMED]` inline\r
\r
## Kevin's Voice — Don't Forget\r
- Direct, confident, no corporate fluff\r
- "I'll build X using Y because Z" — not "I would suggest potentially leveraging..."\r
- Milestones are concrete with clear handoff criteria, not vague "phase" labels\r
- Kickoff message reads like a text from a capable contractor, not a formal business letter\r