Skip to content
cccskills
FreePublished on GitHub

stale-worktree-cleanup

Review old Git worktrees and their related Postgres databases, classify which appear safe to remove, and present recommendations before cleanup. The process checks branch and pull request status, local changes, and unpushed commits to protect work that may still be needed.

OriginalShow the original description

Use when cleaning up old git worktrees, removing worktrees whose branches have merged or been abandoned, or dropping orphaned compdev_* Postgres databases. Triggers on "clean up worktrees", "delete stale worktrees", "worktrees piling up", "orphaned databases", "remove unused worktree".

trycompai/comp2,058 stars(GitHub 2,058 + cccskills 0)

Run score Not tested

See how to install

Good for

  • Review old worktrees before cleanup
  • Find orphaned development databases
  • Check whether a worktree has uncommitted work

Files included (1)

  • SKILL.md7.0 KB

SKILL.md (original)

Review the instructions the agent will receive before you install.

Stale Worktree Cleanup

Overview

This repo's .githooks/post-checkout creates a per-worktree Postgres database (compdev_<slug>) on every git worktree add. Git has no pre-worktree-remove hook, so dead databases pile up over time. This skill defines a safe, reversible process to reap both the worktree directories and their dangling databases together.

Core principle: never delete work the user might still want. Classify first, ask second, remove last.

When to Use

  • User says "clean up worktrees", "delete stale worktrees", "remove old worktrees", "worktrees piling up"
  • User mentions orphaned compdev_* DBs or running out of disk space from dead node_modules
  • Starting a new feature and noticing many old worktree dirs

When NOT to Use

  • User wants to remove ONE specific worktree (just run git worktree remove <path> + drop its DB directly — don't load the whole process)
  • User is actively working in a worktree (never touch active work)

Process

Step 1 — Inventory

Run these four commands (parallel-safe) and capture the output:

git worktree list --porcelain
gh pr list --author @me --state all --limit 50 --json headRefName,state,url,number
git branch --no-color | cat

Then query the DB for compdev_* databases. The management URL is the main worktree's DATABASE_URL with the database path swapped to postgres:

bun -e '
  import { Client } from "pg";
  const raw = require("fs").readFileSync("packages/db/.env", "utf8");
  const url = raw.match(/^DATABASE_URL=(.*)$/m)[1].replace(/^["\x27]|["\x27]$/g, "");
  const mgmt = url.replace(/\/[^/?]+(\?|$)/, "/postgres$1");
  const c = new Client({ connectionString: mgmt });
  await c.connect();
  const r = await c.query("SELECT datname FROM pg_database WHERE datname LIKE \x27compdev\\\\_%\x27 ORDER BY 1");
  for (const row of r.rows) console.log(row.datname);
  await c.end();
'

Step 2 — Classify each worktree

For each worktree (skip the main one):

SignalClassification
Branch merged to main AND clean working tree AND no unpushed commitssafe
PR is CLOSED (not merged)needs-confirm
Uncommitted changes OR unpushed commitsneeds-confirm
No matching PR, no merge, has local commitskeep (user may still be working on it)
Is the main worktreeskip

Gather per worktree:

  • cd <path> && git status --porcelain | wc -l — uncommitted changes count
  • cd <path> && git log @{upstream}..HEAD --oneline 2>/dev/null | wc -l — unpushed commits (0 if no upstream)
  • Branch → PR lookup from step 1

Step 3 — Present to user

Show a table and explicit recommendations. Example:

Path                                    Branch                              PR state  Changes  Recommendation
.worktrees/sale-45-…                    mariano/sale-45-…                   MERGED    0 / 0    ✅ safe to remove
.worktrees/old-experiment               mariano/scratch                     —         3 / 0    ⚠ uncommitted — confirm first
.worktrees/worktree-env-auto-link       mariano/worktree-env-auto-link      OPEN      0 / 0    ⏳ keep (PR open)

Orphan databases (no worktree dir):
  compdev_abandoned_feature
  compdev_old_migration_test

Then ask: "Remove the items marked ✅? Confirm by listing anything you want me to also nuke from the ⚠ / ⏳ set."

Step 4 — Remove confirmed items

For each worktree the user approved:

# 1. Remove the worktree dir (use --force only if user confirmed dirty-removal)
git worktree remove "<path>"           # clean case
git worktree remove --force "<path>"   # only after explicit user OK

# 2. Derive the slug and drop the database
slug=$(basename "<path>" | tr '[:upper:]' '[:lower:]' | tr '-' '_' | tr -cd 'a-z0-9_')
bun -e '
  import { Client } from "pg";
  const raw = require("fs").readFileSync("packages/db/.env", "utf8");
  const url = raw.match(/^DATABASE_URL=(.*)$/m)[1].replace(/^["\x27]|["\x27]$/g, "");
  const mgmt = url.replace(/\/[^/?]+(\?|$)/, "/postgres$1");
  const c = new Client({ connectionString: mgmt });
  await c.connect();
  await c.query(`DROP DATABASE IF EXISTS "compdev_'"$slug"'"`);
  await c.end();
  console.log("dropped compdev_'"$slug"'");
'

For orphan databases (no matching worktree dir), just drop them — no worktree to remove.

Do NOT delete the local branch unless the user explicitly asked. Branches can be recreated from origin cheaply; worktrees cannot.

Step 5 — Verify and report

git worktree list
# then re-run the compdev_* query from step 1

Report back:

  • Worktrees removed (paths)
  • Databases dropped (names)
  • Anything skipped and why
  • What's left (still-active worktrees)

Safety Rules

  • Never remove the main worktree. Its path is always the first line of git worktree list --porcelain.
  • Never --force without confirmation. Dirty worktrees can contain un-stashed work.
  • Never DROP DATABASE on anything not matching ^compdev_[a-z0-9_]+$. Never drop comp, postgres, or any production-looking name.
  • Never delete a local branch as part of cleanup unless the user explicitly asks. Orphaned branches are cheap; lost work isn't.
  • Never run this inside a worktree you're about to delete. cd to the main worktree first.

Common Mistakes

MistakeFix
Dropping the DB but leaving the worktree dirRun git worktree prune then git worktree remove
Removing the worktree but leaving the DB (accumulates orphans)Always do both in the same pass
Using hyphens in the DB nameThe hook slug rule is tr '-' '_' — always underscores
Running from inside a doomed worktreecd to the main worktree before starting the process
Using gh pr list on a branch with no PRMissing data is not "abandoned" — needs needs-confirm classification

Red Flags

If any of these show up mid-process, stop and ask the user:

  • A worktree has unpushed commits AND no PR → might be unreleased work
  • The classification returned >10 "safe to remove" items → unusual volume, double-check
  • git worktree remove errors with "working tree is not clean" → never retry with --force without explicit consent
  • A compdev_* name has weird characters or unexpected format → don't drop

Quick Reference

# List everything
git worktree list --porcelain
gh pr list --author @me --state all --limit 50 --json headRefName,state

# Per-worktree inspection
git -C <path> status --porcelain
git -C <path> log @{upstream}..HEAD --oneline 2>/dev/null

# Clean removal
git worktree remove <path>

# Dirty removal (requires user confirmation first)
git worktree remove --force <path>

# Database drop (run from main worktree)
# See the bun -e snippets above for the exact invocation

Reviews

No reviews yet. Tell others what you thought.

Comments

No login needed. Share how it worked for you, ask a question, or note where it did not run.

No comments yet. Be the first to write one.

Comments are published right away. Do not include personal information such as email addresses or phone numbers. Up to 2 URLs.

0 / 1,000 characters

This form is protected by reCAPTCHA, and the Google Privacy Policy and Terms of Service apply.

More skills from this repository

Guide API endpoint changes so request DTOs, runtime validation, OpenAPI documentation, and MCP tool metadata stay aligned. It covers discoverability, authentication, uploads, long-running tasks, and response types that MCP tools cannot handle.

  • Adding an API endpoint with a request body
  • Updating DTO validation and OpenAPI metadata
  • Making an endpoint available as an MCP tool
trycompai/comp2.1KUpdated Oct 24, 2026

Review specified files for design system usage, replace legacy @trycompai/ui components and lucide-react icons with available @trycompai/design-system equivalents, and run the app type check to verify the migration.

  • Migrating legacy UI components
  • Replacing lucide-react icons with Carbon icons
  • Checking specified files for design system compliance
trycompai/comp2.1KUpdated Oct 24, 2026

audit-hooks

FreeSummary

Review specified files for outdated hook and API patterns, then replace them with the prescribed SWR hooks, API clients, or server API calls. The guidance covers data fetching, mutations, cache updates, and response handling, followed by a typecheck command.

  • Auditing files for disallowed API and hook patterns
  • Replacing raw fetch calls with the API client
  • Migrating server actions and database mutations to API hooks
trycompai/comp2.1KUpdated Oct 24, 2026

audit-rbac

FreeSummary

Review NestJS API endpoints and frontend components for role-based access control and audit log compliance. The skill lists permission, guard, route, and UI gating rules, then directs the agent to fix violations and run type checks.

  • Auditing API routes for permission decorators
  • Checking UI actions against user permissions
  • Fixing access control inconsistencies
trycompai/comp2.1KUpdated Oct 24, 2026

audit-tests

FreeSummary

Audit unit tests for components that use permissions. Add missing tests and fix failures, checking that administrators can use mutation controls, auditors cannot, and read-only content remains visible to both.

  • Adding permission tests for a component
  • Checking admin and auditor behavior
  • Fixing failing permission-related tests
trycompai/comp2.1KUpdated Oct 24, 2026

Set up Better Auth for TypeScript applications, including server and client configuration, database adapters, sessions, email and social sign-in, and plugins. The guide also highlights environment variables, schema generation, and security settings to review.

  • Configuring Better Auth in a TypeScript app
  • Connecting an ORM or database adapter
  • Setting up sessions and cookie storage
trycompai/comp2.1KUpdated Oct 24, 2026

See all skills by trycompai

Report a problem with this skill