setup

name	setup
description	Detect required services, check credential vaults, generate .env files, and guide account creation for missing services. Trigger: set up environment, configure project, set up credentials, prepare for build.
user-invocable	true

/setup — Environment & Credential Pipeline

You are an orchestrator preparing the environment before /build runs. You detect what services are needed, check what credentials exist, and create a clear path to get everything configured. You do not create accounts — you make it obvious what the human needs to do and automate everything else.

What This Skill Does

1. Reads the PRD (or codebase) to identify required services
2. Checks for existing credentials in vault/env
3. Generates .env template with all required variables
4. For services with CLIs, runs setup commands
5. For services requiring manual signup, produces a checklist with direct links
6. Blocks until all required credentials are present

Phase 1: SERVICE DETECTION

Scan the project to build a complete service manifest.

If PRD exists:

Read the PRD's service manifest section directly.

If no PRD (existing codebase):

Dispatch an Explore subagent:

Subagent: Task tool, subagent_type="Explore"
Prompt: Scan the entire codebase for external service dependencies.

        Look for:
        1. Environment variables referenced (process.env.*, os.environ, etc.)
        2. SDK imports (supabase, stripe, anthropic, twilio, aws-sdk, etc.)
        3. API endpoint URLs (hardcoded or configured)
        4. Database connection strings
        5. OAuth/auth provider configurations
        6. .env.example or .env.local.example files
        7. Docker compose service definitions
        8. CI/CD pipeline service references

        For each service found, return:
        - Service name
        - Required environment variables
        - Whether it's required or optional
        - Which files reference it

        Return as structured JSON.

Phase 2: CREDENTIAL CHECK

For each detected service, check if credentials already exist:

Check order:

1. Current .env / .env.local — read if exists
2. 1Password CLI (op) — op item list --tags [project-name] if available
3. AWS SSM — aws ssm get-parameters-by-path --path /[project-name]/ if AWS CLI configured
4. Environment variables — check current shell environment

Output:

Categorize each service as:

• READY — credentials found and valid
• PARTIAL — some credentials found, others missing
• MISSING — no credentials found
• OPTIONAL — service is optional, can proceed without it

Phase 3: ENVIRONMENT GENERATION

Generate the .env.local file (or equivalent):

# =============================================================================
# [PROJECT NAME] — Environment Configuration
# Generated by /setup on [DATE]
# =============================================================================

# --- Database (Supabase) --- [STATUS: READY]
NEXT_PUBLIC_SUPABASE_URL=https://xxx.supabase.co
NEXT_PUBLIC_SUPABASE_ANON_KEY=eyJ...
SUPABASE_SERVICE_ROLE_KEY=eyJ...

# --- AI (Anthropic) --- [STATUS: MISSING]
ANTHROPIC_API_KEY=  # ACTION: Sign up at https://console.anthropic.com

# --- Payments (Stripe) --- [STATUS: MISSING]
STRIPE_SECRET_KEY=  # ACTION: Get from https://dashboard.stripe.com/test/apikeys
STRIPE_WEBHOOK_SECRET=  # ACTION: Run `stripe listen --forward-to localhost:3000/api/webhooks/stripe`
NEXT_PUBLIC_STRIPE_PUBLISHABLE_KEY=  # ACTION: Get from Stripe dashboard

For each MISSING service, include:

• Direct signup/dashboard URL
• Which specific key to copy
• Any CLI setup commands (e.g., stripe login, supabase init)

Phase 4: CLI AUTOMATION

For services with CLIs that the user has already authenticated:

# Supabase (if supabase CLI is authenticated)
supabase link --project-ref [ref]
supabase db push

# Vercel (if vercel CLI is authenticated)
vercel link
vercel env pull .env.local

# Stripe (if stripe CLI is authenticated)
stripe listen --forward-to localhost:3000/api/webhooks/stripe

Only run CLI commands for services where the user is already authenticated. Never prompt for passwords or tokens interactively.

Phase 5: VALIDATION

After the human fills in missing credentials, validate each one:

Validation methods:

• API keys — make a lightweight API call (list models, get account info)
• Database — attempt connection, verify tables exist
• Webhook secrets — verify format (starts with whsec_ for Stripe, etc.)
• OAuth — verify redirect URIs are configured

Output per service:

[SERVICE] — [STATUS]
  ✓ Connection successful
  ✓ Permissions verified (read/write)
  ✗ Webhook endpoint not configured — run: stripe listen --forward-to ...

Phase 6: READINESS REPORT

Environment Status:
  ✓ Supabase: connected, 12 tables, RLS enabled
  ✓ Anthropic: connected, claude-sonnet-4-20250514 available
  ✗ Stripe: API key valid, webhook secret missing
  ○ Twilio: optional, not configured

Blocking: 1 service needs attention
  → Stripe webhook secret: run `stripe listen --forward-to localhost:3000/api/webhooks/stripe`

Ready for /build: NO (1 blocker remaining)

Credential Security Rules

1. Never log credentials — not in console output, not in commit messages, not in plan files
2. Never commit .env files — verify .gitignore includes .env* patterns
3. Prefer vault storage — if 1Password CLI or AWS SSM is available, store there instead of .env
4. Validate .gitignore — before writing any .env file, confirm it won't be tracked by git
5. Rotate warnings — if a key appears to be a production key in a dev environment, warn the human

Handoff

When all required services show READY status:

• Report: "Environment ready. N services configured. Ready for /build."
• The /build skill can now execute without credential-related failures.