skills/worktree/SKILL.md
--- name: worktree description: Coordinate multiple agents on one repo via a worktree-lock pool, so two agents never clobber each other's working tree. Acquire the first free slot (main, then beta/gamma… worktrees, created on demand), work there on your own branch, release when you've pushed. Use before modifying any repo that might be in use by another agent (factory, dataforce, etc.), or whenever you're told a repo is being worked on. Backed by `ro worktree`. category: development argument-hin
npx skillsauth add RonanCodes/ronan-skills skills/worktreeInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
Multiple agents work the local factory at once. Two agents in the same working tree corrupt each other's edits. The fix: a per-repo lock pool of worktrees. You take a free slot, work there, hand it back when you've pushed.
# 1. Before touching a repo that might be busy, take a slot:
path="$(ro worktree acquire)" # prints the path; stderr says which slot
cd "$path"
# 2. Do your work on your own branch (never main):
git checkout -b feat/whatever
# … edit, commit, run the local gate, push, open PR, squash-merge …
# 3. ALWAYS release when you've pushed and you're done:
ro worktree release
acquire locks the first free slot: main (the primary checkout) if free,
else an existing Greek worktree (<repo>-beta, -gamma, …), else it creates the
next Greek one off origin/main. release (run from inside the slot, or pass the
slot name) frees it and marks pushed: true.
Releasing is load-bearing. If you don't release, the slot stays busy and the
pool fills up. The only safety net is TTL reaping (RO_WT_TTL, default 6h) via
ro worktree reap — don't rely on it.
<main-checkout>/.ro/worktree-locks.json (gitignored; ro adds
.ro/ to .gitignore automatically).RO_AGENT=<name> so ro worktree status shows who holds what.ro worktree status prints the whole pool; ro worktree reap frees stale slots./ro:planner-worker, /ro:night-shift, /ro:swarm)
touching a shared repo.testing
--- name: ship description: Ship a feature branch the local-CI-first way — run the full local gate, push, open a PR, squash-merge, then deploy, without waiting on GitHub Actions. Use when a branch is ready for main and you want it merged and deployed now. Reads CI policy from `ro ci` (default skips remote CI because GitHub Actions billing keeps hitting limits). Sibling to /ro:gh-ship (waits on GitHub checks) and /ro:cf-ship (the deploy half). Triggers on "ship it", "ship this", "merge and deploy
testing
--- name: setup-logging description: Set up (or audit) the observability stack in a TanStack Start + Cloudflare Workers app so it is "diagnosable by default" — structured logging (logtape) with a request context carrying trace_id + userId + tenant/orgId, a trace_id propagated FE→BE→logs→Sentry→PostHog, Cloudflare Workers observability enabled, and Sentry + PostHog wired. Two modes: `setup` (wire it into an app) and `audit` (check an existing app + report gaps). Use when scaffolding a new app, wh
development
Manage credentials INSIDE the active ~/.claude/.env file — read which token/account to use for a given app (Simplicity vs Dataforce vs Ronan-personal), add or update a secret WITHOUT it passing through the chat (an interactive Terminal window prompts for it), and track secrets that were exposed in a transcript so they get rotated. Sibling to /ro:context (which switches WHICH env file is active). Use when the user wants to add an API key/token/secret, asks "which credential do I use for X", needs the env organized/labelled, or a secret was pasted into the chat and should be rotated.
development
Diagnose a runtime bug by sweeping the observability logs (Cloudflare Workers logs, Sentry, PostHog) using the shared trace_id, and if the logs don't capture what's needed, ADD structured logging at the failure point + in the request context, deploy (remote) or run locally, and have the user reproduce. Use whenever the user mentions logs, a bug, an issue, "why did X fail / not work", "check the logs", "it works on desktop but not mobile", a stack trace, an error code, or a flaky/intermittent failure. Auto-pick this before guessing at a fix.