agentsclimarketplace
Sign in

Repo first vercel build

Skill VJDiPaola/skill-forge/repo-first-vercel-build

Build urgent repo-first Next.js or Vercel-ready MVPs with clean GitHub history, stable dependency choices, parallel review, and honest deployment readiness. Use when the user asks to create a GitHub repo first, one-shot a hackathon or MVP build, deploy to Vercel quickly, use subagents in parallel, or prove a Vercel app works beyond a demo flow.From its SKILL.md

Install
npx -y skills add VJDiPaola/skill-forge --skill repo-first-vercel-build

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

3 things to look at

  • 16 days oldThe repository was created 16 days ago. New is not bad, but a brand new repository carrying a familiar-sounding name is the shape a typosquat arrives in, and there has been no time for anyone else to find a problem with it.
  • no licenseNo license file was found in the repository. Code published without one is not open source by default, so using it at work is a question for whoever answers licensing questions where you are.
  • 0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

SKILL.md

3.0 KB, 543 tokens by cl100k_base, as published. Nobody here has run it

Repo-First Vercel Build

Use this skill when speed matters but the deliverable still needs source history, build verification, and truthful live-readiness reporting.

Workflow

  1. Establish the repo before major implementation.

    • If the user asks for a GitHub repo first, create the empty private repo before building.
    • On Windows, prefer gh repo create <name> --private, then git remote add origin <url> and git push.
    • Avoid relying on gh repo create --source . when path handling is flaky.

  2. Scaffold conservatively.

    • If the checkout is basically empty, scaffold directly instead of searching for nonexistent structure.
    • Pin stable framework versions when latest resolves to previews or broken Windows SWC behavior.
    • Avoid next/font/google for reproducible builds when network fetches may break build.

  3. Ship the vertical slice.

    • Build the first screen as the usable app, not a landing page, unless the user asked for marketing.
    • Keep optional capabilities optional and user-controlled.
    • Add demo-safe fallback behavior only when it is visibly labeled and does not mask live readiness.

  4. Add public readiness proof.

    • Include GET /api/health or equivalent when live integrations matter.
    • Return booleans, mode, and missing integration names only. Never return secret values.
    • Add smoke probes for expected bad inputs, guarded actions, and fallback mode.

  5. Use bounded parallel review.

    • Keep implementation moving in the mainline.
    • Use separate review lanes for approval gates, persistence fallback, security boundaries, and deployment readiness when useful.
    • Treat reviewer findings as real blockers if they affect safety or completion truth.

  6. Verify locally and after deploy.

    • Prefer npm.cmd on Windows.
    • Typical local sequence: lint, typecheck, build, audit if dependency risk matters, then one-shot production server smoke checks.
    • Restart the production server after route changes before treating route misses as app bugs.
    • After Vercel deploy, verify public URLs and health outputs.

Guardrails

  • Do not claim live provider success from demo fallback behavior.
  • Do not invent env vars or mark missing credentials as complete.
  • Do not hide integration gaps in a happy-path UI.
  • Do not push secrets, local logs, temporary clones, or generated caches.

Verification

Final response should separate:

  • Built and deployed behavior.
  • Local checks actually executed.
  • Public smoke checks actually executed.
  • Missing credentials or unproven live integrations.
  • Repo URL, branch, deployment URL, and any known blockers.

What ships with it: 2 files

319 B alongside SKILL.md

agents/

Gives 0 of the 12 instructions most containers cloud skills give in 543 tokens

Counted across 607 of the 657 authors here whose files we hold, read 2026-08-07

  • Run containers as a non-root userin 66 of 607, across 46 files
  • Use multi-stage buildsin 53 of 607, across 44 files
  • Use Promise.all for independent operationsin 47 of 607, across 13 files
  • Import directly instead of barrel filesin 46 of 607, across 12 files
  • Use ternary instead of AND for conditionalsin 45 of 607, across 12 files
  • Use Set or Map for O(1) lookupsin 42 of 607, across 10 files
  • Create a .dockerignore filein 41 of 607, across 31 files
  • Read individual rule files for detailsin 39 of 607, across 9 files
  • Copy dependency files before source codein 36 of 607, across 23 files
  • Authenticate server actions like API routesin 35 of 607, across 7 files
  • Use next/dynamic for heavy componentsin 34 of 607, across 9 files
  • Use React.cache for per-request deduplicationin 34 of 607, across 10 files

Said here and by no other author read

  • create the repository before implementation
  • build the usable app first
  • keep optional features user-controlled
  • use parallel review lanes
  • restart production servers after route changes

Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.

Keep looking

Skills are one crate of 326,782. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.