plugins/dev/skills/create-worktree/SKILL.md
Create a git worktree for parallel work and optionally launch implementation session. **ALWAYS use when** the user says 'create a worktree', 'work in parallel', 'start a worktree for', or needs to work on multiple features simultaneously without switching branches.
npx skillsauth add coalesce-labs/catalyst create-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.
This command uses ticket references like PROJ-123. Replace PROJ with your Linear team's ticket
prefix:
.catalyst/config.json if availableTICKET-XXXENG-123, FEAT-456, BUG-789You are tasked with creating a git worktree for parallel development work.
When this command is invoked:
Gather required information:
Confirm with user: Present the worktree details and get confirmation before creating.
Create the worktree: Use the create-worktree.sh script:
"${CLAUDE_PLUGIN_ROOT}/scripts/create-worktree.sh" <worktree_name> [base_branch]
The script automatically:
catalyst.worktree.setup from config for project-specific setup.claude/ and .catalyst/ directoriesProject setup (handled by script based on config):
If catalyst.worktree.setup is defined in config, those commands run in order. Otherwise, the
script auto-detects: dependency install (bun/npm) + thoughts init.
Example config for full control:
{
"catalyst": {
"worktree": {
"setup": [
"humanlayer thoughts init --directory ${DIRECTORY} --profile ${PROFILE}",
"humanlayer thoughts sync",
"bun install",
"~/.claude/scripts/trust-workspace.sh \"$(pwd)\""
]
}
}
}
Optional: Launch implementation session: If a plan file path was provided, ask if the user
wants to launch Claude in the worktree. Note: claude -w takes a name and creates a new
worktree — so cd into the already-created worktree instead, capture stderr to a real file for
post-mortem debugging, and use --dangerously-skip-permissions since there's no TTY.
(
cd "<worktree_path>" || exit 1
exec nohup claude \
--output-format stream-json --verbose \
--dangerously-skip-permissions \
-p "/catalyst-dev:implement-plan <plan_path> and when done: create commit, create PR, update Linear ticket"
) > "<worktree_path>/worker-stream.jsonl" 2> "<worktree_path>/worker-stderr.log" &
Worktree base directory is resolved in this order:
catalyst.orchestration.worktreeDir from config (explicit override)~/catalyst/wt/<projectKey>/ (default — reads catalyst.projectKey from config)~/catalyst/wt/<repo>/ (fallback if no config)Recommended: Add ~/catalyst to Claude Code's additionalDirectories in
~/.claude/settings.json so all worktrees across projects are automatically trusted.
Example layout (for project with projectKey: "acme"):
~/catalyst/wt/acme/
├── ACME-123-feature/
├── ACME-456-bugfix/
└── ENG-789-oauth/
With orchestration (multiple named orchestrators):
~/catalyst/wt/acme/
├── auth-orch/ # orchestrator
├── auth-orch-ACME-101/ # worker
├── auth-orch-ACME-102/ # worker
├── dash-orch/ # another orchestrator
└── dash-orch-ACME-201/ # worker
User: /create-worktree PROJ-123
development
Migrate a single-harness repo to the dual-harness layout so both Claude Code and Codex load the same instructions and skills — AGENTS.md as the portable canonical doc, a thin CLAUDE.md `@AGENTS.md` bridge, and a `.agents/skills` dir with a `.claude/skills` symlink onto it. Use when asked to migrate to dual-harness, make this repo work in both Claude and Codex, or for agent metadata cleanup.
tools
Goal-driven senior-engineer pipeline-unstick sweep (CTL-1176 rung 3). Given the stuck/failed/needs-human set (or ONE ticket handed by the recovery router), its GOAL is to get the pipeline MOVING again — not to fix one ticket's review findings (that is phase-remediate). It runs AFTER the eyes (diagnostician evidence) and the hands (deterministic unstuck-sweep seams) have already tried, and it CONSUMES their output from a recovery-pass.json brief rather than re-diagnosing or redoing their narrow work. It acts like a senior engineer with full tool access — it resolves merge conflicts, rebases, force-pushes, merges green PRs, and re-dispatches stalled phases AUTONOMOUSLY — and escalates to the operator ONLY for a genuine value judgment / something that degrades other functionality / a real cost-benefit trade-off / a serious architecture change / an ADR conflict. On escalation it AUTHORS the operator inbox row + the push notification (executive-voiced). Dispatched as a `claude --bg` job by phase-agent-dispatch via slash command, AND invocable bare by the operator as a sweep — hence `user-invocable: true`. Ships behind CATALYST_RECOVERY_PASS (off by default — no live behavior change until shadow/enforce).
tools
Diagnose and fix Catalyst setup issues. Validates tools, database, config, OTel, direnv, and thoughts. Automatically fixes what it can — creates directories, initializes the database, sets WAL mode, runs migrations. Use for new installs, upgrades, or when something isn't working.
tools
--- name: phase-triage description: Phase agent that triages a Linear ticket — expands acronyms, classifies (feature/bug/docs/refactor/chore), identifies genuine blockers (a semantic second-pass over the backlog — NOT a prose scrape; CTL-838), estimates scope, writes triage.json, and posts a triage analysis comment to Linear. Triage completion is signaled by that comment plus the local triage.json — there is no `triaged` label. Emits phase.triage.complete.<TICKET> on success and phase.triage.fai