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