🎁 Get the FREE AI Skills Starter Guide β€” Subscribe β†’
BytesAgainBytesAgain
πŸ¦€ ClawHub

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...

Versionv1.0.0
Downloads714
TERMINAL
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:

  • Project type: web app, API, automation, audit, mobile, data pipeline, etc.
  • Client industry: SaaS, ecommerce, healthcare, finance, creator economy, etc.
  • Timeline hints: "need this in 2 weeks", "no rush", "ASAP", specific dates mentioned
  • Budget hints: hourly rate mentioned, fixed price, "small budget", enterprise
  • Tech constraints: "must use React", "we're on AWS", "no vendor lock-in"
  • Team context: "solo founder", "we have a dev team", "replacing a contractor"
  • Default assumptions when not specified:

  • Timeline: 4-6 weeks (reasonable for most web projects)
  • Budget: $75/hr or $2,000-5,000 fixed (Kevin's standard range)
  • Stack: Next.js + Supabase + Stripe + Python (Kevin's default)
  • Deployment: Vercel (frontend) + Railway or Supabase (backend)

  • 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 compliance

    Deployment

  • 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 Context

    What 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

  • 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
  • Multiple possible stacks: Choose Kevin's default stack, add "Alternatives Considered" section explaining why alternatives were skipped
  • Unclear budget: Leave payment schedule with placeholder percentages, note "confirm rate with client before sending"
  • CLIENT_ONBOARD/ already exists: Add timestamp suffix CLIENT_ONBOARD_[YYYY-MM-DD]/ to avoid overwriting
  • Missing tech details: Generate best-guess and mark assumptions clearly with [ASSUMED] inline
  • Kevin's Voice β€” Don't Forget

  • Direct, confident, no corporate fluff
  • "I'll build X using Y because Z" β€” not "I would suggest potentially leveraging..."
  • Milestones are concrete with clear handoff criteria, not vague "phase" labels
  • Kickoff message reads like a text from a capable contractor, not a formal business letter