agentleFS
prateekjainprateekjain/ChiefOfStaff/skills/deploy/SKILL.md

deploy

Skill4 starsChanged 8 months agoMITView on GitHub

Deploy a venture's code to Vercel and/or set up Supabase — run by ChiefOfStaff

155 other projects use a version of this.

Adopted by

Most recently taken up by

Used with

Projects with it also use pm-discovery, qa-phase and 10 more.

Other files people use alongside this one.

Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
  • ww-w-aiSkill

    pm-discovery

    PM Agent Team - Automated product discovery, strategy, and PRD generation. Runs PM analysis workflow to produce comprehensive PRD before PDCA Plan phase.

    Also in 3 projects that use this

  • ww-w-aiSkill

    qa-phase

    Run QA tests at various levels (L1-L5) for features under PDCA management. Integrates with MCP tools to execute structured test plans.

    Also in 3 projects that use this

  • +10 more from ww-w-ai

The file

Show its rules and text

We split this skill into the rules it gives an agent

17 rules. 0 are common, 11 are distinctive, and 6 are very specific to this project.

  • 0

    Common

    Most of the 139 edited versions we read keep these.

  • 11

    Distinctive

    This author's own choices. Worth a look.

  • 6

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Very specific:

    Read portfolio/registry.md to find the venture and confirm stage allows deployment

    line 26
  2. Distinctive:

    Read the venture's CLAUDE.md for current deployment state (check for existing URLs)

    line 27
  3. Very specific:

    Read portfolio/guardrails.md to confirm free-tier deployment is allowed at this stage

    line 28
  4. Distinctive:

    Before deploying, verify the code meets quality standards.

    line 38
  5. Distinctive:

    If any checks fail, fix the issues before proceeding to deployment.

    line 59
  6. Very specific:

    If the venture has deployable code in src/ or has a package.json:

    line 63
  7. Distinctive:

    If this is the first deployment, also link the project:

    line 72
  8. Distinctive:

    Important: Only use Vercel's free (Hobby) tier.

    line 77
  9. Very specific:

    If the venture needs a database/auth (check docs/architecture.md):

    line 81
  10. Distinctive:

    If no account/project exists, submit a Spending approval to the Decisions DB for Supabase setup.

    line 94
  11. Distinctive:

    Update the venture's CLAUDE.md — add/update the Deployment section:

    line 98
  12. Very specific:

    Update portfolio/registry.md with the live URL

    line 107
  13. Distinctive:

    Update the Notion Ventures DB entry with the live URL (in the Repo URL or a note)

    line 109
  14. Distinctive:

    Check that the deployment is live and functional:

    line 119
  15. Distinctive:

    After deployment, run the QA agent to verify everything works end-to-end:

    line 130
  16. Very specific:

    Use the qa-check skill with the venture slug and deployment URL

    line 131
  17. Distinctive:

    If QA finds critical issues, fix and redeploy before reporting success

    line 133

“Common” is measured: kept by at least 6 in 10 of the 139 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Deploy Venture

Deploy a venture's code to Vercel and/or set up a Supabase project. This skill is executed by ChiefOfStaff — ventures do not self-deploy.

Input

Venture slug: $ARGUMENTS

Step 1: Read Context

  1. Read portfolio/registry.md to find the venture and confirm stage allows deployment
  2. Read the venture's CLAUDE.md for current deployment state (check for existing URLs)
  3. Read portfolio/guardrails.md to confirm free-tier deployment is allowed at this stage

Step 2: Pull Latest Code

cd $PROJECTS_DIR/{slug} && git pull --quiet

Step 3: Pre-Deployment Quality Gate (MANDATORY)

Before deploying, verify the code meets quality standards. If any check fails, DO NOT deploy — fix the issue first.

cd $PROJECTS_DIR/{slug}

# 1. Build must pass
npm run build 2>&1

# 2. Check for placeholder links (href="#")
grep -r 'href="#"' src/ --include="*.tsx" --include="*.ts" --include="*.jsx" --include="*.js" || echo "PASS: No placeholder links"

# 3. Check for console.log in API routes (should use real storage)
grep -r 'console.log' src/app/api/ --include="*.ts" --include="*.js" | grep -v 'console.error' || echo "PASS: No console.log in API routes"

# 4. Check for fake/placeholder content
grep -rEi '(lorem ipsum|\[Name\]|\[Company\]|TODO:|FIXME:)' src/ --include="*.tsx" --include="*.ts" || echo "PASS: No placeholder content"

# 5. Check for proper metadata
grep -r 'metadata' src/app/layout.tsx || echo "WARNING: No metadata found in layout"

If any checks fail, fix the issues before proceeding to deployment.

Step 4: Deploy to Vercel

If the venture has deployable code in src/ or has a package.json:

cd $PROJECTS_DIR/{slug}
vercel --yes --prod 2>&1

Capture the deployment URL from output.

If this is the first deployment, also link the project:

vercel link --yes 2>&1

Important: Only use Vercel's free (Hobby) tier. If the deployment would require a paid plan, stop and submit a Spending approval instead.

Step 5: Set Up Supabase (if needed)

If the venture needs a database/auth (check docs/architecture.md):

# Only if no Supabase project exists yet
supabase init 2>&1  # In the venture directory
supabase start 2>&1  # For local development

For remote Supabase (production), the founder needs to have a Supabase account. Check if one exists:

supabase projects list 2>&1

If no account/project exists, submit a Spending approval to the Decisions DB for Supabase setup.

Step 6: Record Deployment URLs

  1. Update the venture's CLAUDE.md — add/update the Deployment section:
    ## Deployment
    - **Live URL**: {vercel-url}
    - **Vercel Project**: {project-name}
    - **Supabase Project**: {project-ref} (if applicable)
    - **Last Deployed**: {date}
  2. Update portfolio/registry.md with the live URL
  3. Update the Notion Ventures DB entry with the live URL (in the Repo URL or a note)
  4. Log in the venture's docs/changelog.md:
    ## {date}: [Deployment] Deployed to Vercel
    Live at: {url}

Step 7: Post-Deployment Verification

Check that the deployment is live and functional:

# Basic health check
curl -s -o /dev/null -w "%{http_code}" {deployment-url}

# Check for server errors in the response
curl -s {deployment-url} | head -50

Step 8: Trigger QA Check

After deployment, run the QA agent to verify everything works end-to-end:

  • Use the qa-check skill with the venture slug and deployment URL
  • QA agent will test all forms, links, responsiveness, and console errors
  • If QA finds critical issues, fix and redeploy before reporting success

Report: "Deployed {venture} to {url}. Status: {http_code}. QA: {pass/fail}."

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.