MCP.Market

setup-repo skill

by Significant-Gravitas·Significant-Gravitas/AutoGPT·188k stars

Initialize a worktree-based repo layout for parallel development. Creates a main worktree, a reviews worktree for PR reviews, and N numbered work branches. Handles .env creation, dependency installation, and branchlet config. TRIGGER when user asks to set up the repo from scratch, initialize worktrees, bootstrap their dev environment, "setup repo", "setup worktrees", "initialize dev environment", "set up branches", or when a freshly cloned repo has no sibling worktrees.

A100/100content scan

Is the setup-repo skill safe?

Clean: nothing in its files matched our rules. We read 1 file in the folder on 2026-10-25.

No findings.

Install the setup-repo skill

A skill is a folder. Copy it into your agent's skills folder and the agent loads it when the task matches its description.

git clone --depth 1 https://github.com/Significant-Gravitas/AutoGPT.git /tmp/AutoGPT
mkdir -p ~/.claude/skills
cp -r /tmp/AutoGPT/.claude/skills/setup-repo ~/.claude/skills/setup-repo
available in every project

In the Claude apps, zip the folder and upload it from the Skills settings. The folder on GitHub

The instructions your agent would load

SKILL.md as published, without the frontmatter. Read it on GitHub

Repository Setup

This skill sets up a worktree-based development layout from a freshly cloned repo. It creates:

  • A main worktree (the primary checkout)
  • A reviews worktree (for PR reviews)
  • N work branches (branch1..branchN) for parallel development

Step 1: Identify the repo

Determine the repo root and parent directory:

ROOT=$(git rev-parse --show-toplevel)
REPO_NAME=$(basename "$ROOT")
PARENT=$(dirname "$ROOT")

Detect if the repo is already inside a worktree layout by counting sibling worktrees (not just checking the directory name, which could be anything):

# Count worktrees that are siblings (live under $PARENT but aren't $ROOT itself)
SIBLING_COUNT=$(git worktree list --porcelain 2>/dev/null | grep "^worktree " | grep -c "$PARENT/" || true)
if [ "$SIBLING_COUNT" -gt 1 ]; then
  echo "INFO: Existing worktree layout detected at $PARENT ($SIBLING_COUNT worktrees)"
  # Use $ROOT as-is; skip renaming/restructuring
else
  echo "INFO: Fresh clone detected, proceeding with setup"
fi

Step 2: Ask the user questions

Use AskUserQuestion to gather setup preferences:

  1. How many parallel work branches do you need? (Options: 4, 8, 16, or custom)
  • These become branch1 through branchN
  1. Which branch should be the base? (Options: origin/master, origin/dev, or custom)
  • All work branches and reviews will start from this

Step 3: Fetch and set up branches

cd "$ROOT"
git fetch origin

# Create the reviews branch from base (skip if already exists)
if git show-ref --verify --quiet refs/heads/reviews; then
  echo "INFO: Branch 'reviews' already exists, skipping"
else
  git branch reviews <base-branch>
fi

# Create numbered work branches from base (skip if already exists)
for i in $(seq 1 "$COUNT"); do
  if git show-ref --verify --quiet "refs/heads/branch$i"; then
    echo "INFO: Branch 'branch$i' already exists, skipping"
  else
    git branch "branch$i" <base-branch>
  fi
done

Step 4: Create worktrees

Create worktrees as siblings to the main checkout:

if [ -d "$PARENT/reviews" ]; then
  echo "INFO: Worktree '$PARENT/reviews' already exists, skipping"
else
  git worktree add "$PARENT/reviews" reviews
fi

for i in $(seq 1 "$COUNT"); do
  if [ -d "$PARENT/branch$i" ]; then
    echo "INFO: Worktree '$PARENT/branch$i' already exists, skipping"
  else
    git worktree add "$PARENT/branch$i" "branch$i"
  fi
done

Step 5: Set up environment files

Do NOT assume .env files exist. For each worktree (including main if needed):

  1. Check if .env exists in the source worktree for each path
  2. If .env exists, copy it
  3. If only .env.default or .env.example exists, copy that as .env
  4. If neither exists, warn the user and list which env files are missing

Env file locations to check (same as the /worktree skill — keep these in sync):

  • autogpt_platform/.env
  • autogpt_platform/backend/.env
  • autogpt_platform/frontend/.env

Note: This env copying logic intentionally mirrors the /worktree skill's approach. If you update the path list or fallback logic here, update /worktree as well.

SOURCE="$ROOT"
WORKTREES="reviews"
for i in $(seq 1 "$COUNT"); do WORKTREES="$WORKTREES branch$i"; done

FOUND_ANY_ENV=0
for wt in $WORKTREES; do
  TARGET="$PARENT/$wt"
  for envpath in autogpt_platform autogpt_platform/backend autogpt_platform/frontend; do
    if [ -f "$SOURCE/$envpath/.env" ]; then
      FOUND_ANY_ENV=1
      cp "$SOURCE/$envpath/.env" "$TARGET/$envpath/.env"
    elif [ -f "$SOURCE/$envpath/.env.default" ]; then
      FOUND_ANY_ENV=1
      cp "$SOURCE/$envpath/.env.default" "$TARGET/$envpath/.env"
      echo "NOTE: $wt/$envpath/.env was created from .env.default — you may need to edit it"
    elif [ -f "$SOURCE/$envpath/.env.example" ]; then
      FOUND_ANY_ENV=1
      cp "$SOURCE/$envpath/.env.example" "$TARGET/$envpath/.env"
      echo "NOTE: $wt/$envpath/.env was created from .env.example — you may need to edit it"
    else
      echo "WARNING: No .env, .env.default, or .env.example found at $SOURCE/$envpath/"
    fi
  done
done

if [ "$FOUND_ANY_ENV" -eq 0 ]; then
  echo "WARNING: No environment files or templates were found in the source worktree."
  # Use AskUserQuestion to confirm: "Continue setup without env files?"
  # If the user declines, stop here and

Step 6: Copy branchlet config

Copy .branchlet.json from main to each worktree so branchlet can manage sub-worktrees:

if [ -f "$ROOT/.branchlet.json" ]; then
  for wt in $WORKTREES; do
    cp "$ROOT/.branchlet.json" "$PARENT/$wt/.branchlet.json"
  done
fi

Step 7: Install dependencies

Install deps in all worktrees. Run these sequentially per worktree:

for wt in $WORKTREES; do
  TARGET="$PARENT/$wt"
  echo "=== Installing deps for $wt ==="
  (cd "$TARGET/autogpt_platform/autogpt_libs" && poetry install) &&
  (cd "$TARGET/autogpt_platform/backend" && poetry install && poetry run prisma generate) &&
  (cd "$TARGET/autogpt_platform/frontend" && pnpm install) &&
  echo "=== Done: $wt ===" ||
  echo "=== FAILED: $wt ==="
done

This is slow. Run in background if possible and notify when complete.

Step 8: Verify and report

After setup, verify and report to the user:

git worktree list

Summarize:

  • Number of worktrees created
  • Which env files were copied vs created from defaults vs missing
  • Any warnings or errors encountered

Final directory layout

parent/
  main/              # Primary checkout (already exists)
  reviews/           # PR review worktree
  branch1/           # Work branch 1
  branch2/           # Work branch 2
  ...
  branchN/           # Work branch N

More skills from Significant-Gravitas/AutoGPT

  • Aopen-prOpen a pull request with proper PR template, test coverage, and review workflow. Guides agents through creating a PR that follows repo conventions, ensures existing behaviors aren't broken, covers new behaviors with tests, and handles review via bot when local testing isn't possible. TRIGGER when user asks to "open a PR", "create a PR", "make a PR", "submit a PR", "open pull request", "push and create PR", or any variation of opening/submitting a pull request.
  • DorchestrateMeta-agent supervisor that manages a fleet of Claude Code agents running in tmux windows. Auto-discovers spare worktrees, spawns agents, monitors state, kicks idle agents, approves safe confirmations, and recycles worktrees when done. TRIGGER when user asks to supervise agents, run parallel tasks, manage worktrees, check agent status, or orchestrate parallel work.
  • Aperf-compareShared measurement recipe for AutoGPT performance work. Compares a baseline and a candidate in Sentry (two releases, two environments such as preview pr-<n> deploys, or two time windows) per transaction: count, p50/p95/p99, failure rate, and a trace-clustered bootstrap verdict of faster / slower / no detectable change / not enough data, with exit codes agents can branch on. Works for span duration, web vitals (measurements.lcp) or any numeric span field. TRIGGER when an agent needs to show a change made the backend or frontend faster or slower, compare a preview against a control or dev, check a release after merge on dev or prod, or check for regressions.
  • Apr-addressAddress PR review comments and loop until CI green and all comments resolved. TRIGGER when user asks to address comments, fix PR feedback, respond to reviewers, or babysit/monitor a PR.
  • Apr-polishAlternate /pr-review and /pr-address on a PR until the PR is truly mergeable — no new review findings, zero unresolved inline threads, zero unaddressed top-level reviews or issue comments, all CI checks green, and two consecutive quiet polls after CI settles. Use when the user wants a PR polished to merge-ready without setting a fixed number of rounds.
  • Apr-reviewReview a PR for correctness, security, code quality, and testing issues. TRIGGER when user asks to review a PR, check PR quality, or give feedback on a PR.
  • Apr-testE2E manual testing of PRs/branches using docker compose, agent-browser, and API calls. TRIGGER when user asks to manually test a PR, test a feature end-to-end, or run integration tests against a running system.
  • Avercel-react-best-practicesReact and Next.js performance optimization guidelines from Vercel Engineering. This skill should be used when writing, reviewing, or refactoring React/Next.js code to ensure optimal performance patterns. Triggers on tasks involving React components, Next.js pages, data fetching, bundle optimization, or performance improvements.
  • Awebapp-testingToolkit for interacting with and testing local web applications using Playwright. Supports verifying frontend functionality, debugging UI behavior, capturing browser screenshots, and viewing browser logs.
  • AworktreeSet up a new git worktree for parallel development. Creates the worktree, copies .env files, installs dependencies, and generates Prisma client. TRIGGER when user asks to set up a worktree, work on a branch in isolation, or needs a separate environment for a branch or PR.
  • Awrite-frontend-testsAnalyze the current branch diff against dev, plan integration tests for changed frontend pages/components, and write them. TRIGGER when user asks to write frontend tests, add test coverage, or 'write tests for my changes'.

All agent skills → · MCP servers