
Claude Skills by coalesce-labs
github.com/coalesce-labsReference for Linearis CLI commands to interact with Linear project management. Use when working with Linear tickets, cycles, projects, milestones, or when the user mentions ticket IDs like TEAM-123, BRAVO-456, ENG-789.
Diagnose and fix Catalyst setup issues. Validates tools, database, config, OTel, direnv, the Catalyst Cloud replica mirror, 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.
Validates YAML frontmatter on plugins/*/skills/*/SKILL.md and plugins/*/agents/*.md against docs/frontmatter-standard.md and .claude/rules/plugin-editing.md: required fields, the disable-model-invocation/user-invocable polarity, allowed-tools vs tools, and skill-only fields that must not leak (model, category). Use when adding or editing a skill or agent, before opening a PR that touches plugins/**, or paired with audit-references to confirm a plugin cleanup's frontmatter didn't drift.
Fast browser automation CLI for AI agents. **ALWAYS use instead of Playwright MCP tools** for web testing, screenshots, form filling, and UI verification. Use when user says "open in browser", "check the site", "take a screenshot", "fill the form", "test the UI", or any browser interaction. Also use as a fallback when a task requires visual browser interaction that CLIs and APIs cannot handle (e.g., OAuth flows, complex dashboards, visual verification).
> Rules v3 (Ryan, 2026-08-15 → 08-17). Applies to every Catalyst-managed Linear project and every agent, > Claude or Codex. Full plugin verb: **CTL-1922**.
Invoke as `/catalyst-dev:briefing-followup` after `/catalyst-dev:morning-briefing` has produced today's briefing. Reads its `decisions:` block, presents each open decision, and records what the user chose.
You are tasked with creating git commits using conventional commit format for the changes made during this session.
Write a compound-log entry for a just-shipped ticket. This is the Phase 1 exit gate for AI-native estimation: without this closer, cost/wall-time signals never feed future estimates and the calibration loop stays open. All mechanical work delegates to `plugins/dev/scripts/compound-log.sh` — your job is collecting the three human-authored inputs and invoking it.
You are the human's **single desk**. Everything they need arrives through you, and nothing needs them except a decision only they can make. Spec **CTL-1995**; SOP `thoughts/shared/plans/2026-08-18-p13-coordination-sop.md`. ⛔ **You hold no authority over stewards.** You route, surface and scaffold; you never dispatch their tickets or overrule their calls. That is the whole reason this role is called *concierge* — the everyday meaning of the word is the only thing stopping it drifting into a se...
```bash if [[ -f "${CLAUDE_PLUGIN_ROOT}/scripts/check-project-setup.sh" ]]; then "${CLAUDE_PLUGIN_ROOT}/scripts/check-project-setup.sh" || exit 1 fi ```
You are tasked with creating detailed implementation plans through an interactive, iterative process. You should be skeptical, thorough, and work collaboratively with the user to produce high-quality technical specifications. Replace `PROJ` in ticket references with your Linear team's prefix from `.catalyst/config.json`.
Orchestrates the complete PR creation flow: commit → rebase → push → create → describe → link Linear ticket.
This command uses ticket references like `PROJ-123`. Replace `PROJ` with your Linear team's ticket prefix:
Generates or updates a PR description with incremental information, auto-updates the title, and links the Linear ticket — fully automated, no interactive prompts.
Fix TypeScript errors with strict anti-reward-hacking rules. **ALWAYS use when** the user says 'fix type errors', 'fix typescript', 'type-check is failing', or when TypeScript compilation errors need to be resolved. Ensures runtime type safety — fixes root causes instead of silencing errors with casts.
Every ticket must open with **a use case a stranger can understand**: who gets what outcome, under what condition, and why. Most tickets fail this — they dive straight into implementation ("Wire HRW ownership into dispatchTriage") and the reader has to reverse-engineer the point. This skill fixes that at authoring time. This skill owns **ticket format** (title voice + body structure). It does **not** own the Linear CLI mechanics — once a draft is ready, hand off to the `/catalyst-dev:linear` ...
You are tasked with implementing an approved technical plan from `thoughts/shared/plans/`. These plans contain phases with specific changes and success criteria.
Update existing implementation plans based on feedback or changed requirements. **ALWAYS use when** the user says 'update the plan', 'change the plan', 'the requirements changed', 'revise the approach', or wants to modify an existing plan in thoughts/shared/plans/ after review feedback or discovered issues.
Create tickets from thoughts documents, update existing tickets, and follow the Linearis-CLI workflow.
Safely merges a PR after comprehensive verification, with Linear integration and automated cleanup.
Invoke as `/catalyst-dev:morning-briefing` to produce today's briefing locally and fan it out to Slack DM, Slack channel, Notion page, and a Loom recording script.
This is the **project-scoped invocation of `catalyst-dev:steward`**, which is the canonical implementation of this role (its `SKILL.md` is CTL-1974's spec). The role is named `steward` in code and docs because this repo reserves the word *orchestrator* for the pipeline MACHINERY, never for an agent — so **run `catalyst-dev:steward` with scope = your project** and follow its loop. This file codifies the shape ORCH ran by hand on 2026-08-18 and points at the steward mechanics.
Read `plugins/dev/skills/validate-plan/SKILL.md` for the schema this skill reads — its `allowed-tools`, and the exact headings its "Validation Report" renders into the conversation. That report is this skill's entire input; do not re-derive or copy its contract here, since `validate-plan` is the owning skill and the only source that stays current when its report shape changes. See `references/single-session-fix.md` for a worked example of turning that report into fixes.
You are tasked with conducting comprehensive research across the codebase to answer user questions by spawning parallel sub-agents and synthesizing their findings. **You are a documentarian, not a critic.** Document what EXISTS without suggesting improvements, critiquing implementation, or proposing changes unless the user explicitly asks. **CRITICAL REQUIREMENTS — read these before doing anything else:** 1. You MUST save a research document to `thoughts/shared/research/YYYY-MM-DD-description...
You are resuming work from a handoff document through an interactive process. Handoffs carry context, learnings, and next steps from a prior session that need to be understood and continued — never assume the handoff's state still matches the codebase; verify first.
Systematically pull, categorize, and address all PR review comments — code change requests, questions, and suggestions. This skill fetches comments via gh api, groups them by file, implements fixes, handles disagreements diplomatically, and pushes a single commit. You should not try to handle PR review feedback manually — this skill ensures nothing gets missed. **ALWAYS consult this skill when** the user says 'address comments', 'fix review feedback', 'handle PR comments', 'respond to reviewe...
Scan TypeScript code for reward hacking patterns — shortcuts that make linters pass without actually fixing type safety. This skill has a comprehensive checklist of 8 forbidden patterns with severity tuning (libraries vs apps) that you cannot reliably check on your own. **ALWAYS consult this skill when** the user says 'scan for hacks', 'check for type cheats', 'reward hacking', 'verify no shortcuts', wants to check for `as any`, `as unknown as`, `@ts-ignore`, non-null assertions (`value!`), `...
You own one project or initiative until it closes: for each ready ticket you launch a `/relay-ticket <TICKET>` session, read its RELAY REPORT, and decide the next phase — no daemon, no Todo-triggered auto-pickup (both retired, CTL-2218). Spec **CTL-1974**.
Capture what a ticket taught us into the **shared** store (`thoughts/` + ADRs), so future agents on any machine make better decisions. This is `research-curate` evolved from *inventory* to *action*. Read `reference.md` (this dir) for the learnings-store schema before writing anything. **Two authority levels (hard rule):** - **Autonomous** — write/append/update/delete in `thoughts/shared/learnings/` and `thoughts/shared/CONCEPTS.md`, and prune stale notes in `thoughts/shared/{research,plans}/`...
Loop C of compound engineering: a human-readable reflection across a SET of tickets. It mostly **reads** what Loop B (friction logs, learnings) and Loop A (compound-log, estimation corpus) captured, then writes ONE artifact: the retro document. **Runs automatically per ticket, relay-native (CTL-2244):** `merge-pr` Step 14 ([post-merge.md](../merge-pr/references/post-merge.md)) invokes this skill last — after `compound-estimate` and `ticket-compound` — once Step 13b's deploy verification (`mer...
Drive an aging pull-request backlog to zero. Inventories every open PR, finds the STRUCTURAL blockers first (a required check that can never run, a reviewer that never fires, chronically red CI), triages every unresolved review thread in parallel and VERIFIES each finding against the code before fixing it, then merges serially. **ALWAYS use when** the user says 'burn down the PRs', 'stale PRs', 'aging PRs', 'PR backlog', 'get these PRs merged', 'clear the PR queue', or asks why PRs are not me...
Validate that implementation plans were correctly executed. **ALWAYS use when** the user says 'validate the plan', 'check if the plan was implemented correctly', 'verify the implementation', or after completing /implement-plan to confirm all phases were properly executed and success criteria met.
Run the full 5-step TypeScript validation gate: type check, reward hacking scan, test inclusion, tests, and lint. This skill provides a structured multi-step pipeline that you cannot replicate on your own — it detects the project's package manager and linter automatically, checks tsconfig strictness, and invokes /scan-reward-hacking internally. **ALWAYS consult this skill when** the user mentions 'validate types', 'check type safety', 'type validation', 'type safety gate', wants to verify Typ...
Converge a single-harness repo (Claude-only monolithic `CLAUDE.md`, or Codex-only `AGENTS.md` with no bridge) onto the target dual-harness layout, applying every mechanical fix automatically and only asking the model to do the one thing a script can't: split a monolithic `CLAUDE.md` into its portable core and its Claude-specific remainder. **User-invoked only.** This skill sets `disable-model-invocation: true`, so nothing can auto-trigger it as a handoff — not `catalyst-foundry:setup-catalyst...
Walk thoughts/shared/research/ and thoughts/shared/plans/, score each doc's staleness, regenerate INDEX.md, and append LLM-surfaced contradictions to CONTRADICTIONS.md (append-only). Source docs are never modified. Classification: current (age<90d AND refs valid), needs-review (age>=90d OR broken refs), likely-stale (age>=180d AND no recent activity). Inventory is deterministic; contradiction detection runs one LLM call per cluster (CTL-467 + CTL-468 / Initiative 4 Phase 1+2).
Diagnose the full Catalyst environment, fix everything fixable, and verify the fixes worked.
Configure Warp terminal to work as a Catalyst launcher. Scan the user's machine for projects, interview them, and generate `~/.warp/tab_configs/*.toml` files following the "catalyst quartet" pattern (main + PM + new-worktree + worktree), with colors, emoji, and session-name wiring so Claude's in-UI session name, terminal title, and remote-control name all match the Warp tab. > **Note.** This skill configures *manual development* tabs only. The legacy wave-orchestration tabs > ("New Worktree O...
Combines static state (where things are) with the live event log (how they got there and what's happening right now). Default invocation produces a full dashboard; args narrow the scope or switch interaction mode.
End-to-end autonomous workflow that chains research → plan → implement → validate → ship → merge in a single session. All phases run sequentially in the current Claude Code session, invoking skills directly. Context is managed naturally via Claude's automatic compaction, and the thoughts/ system provides persistent handoff documents between phases. > **Legacy mode for the orchestrator (post-2026-06-15).** `oneshot` remains the canonical > single-shot lifecycle for direct user invocation. The ...
Coordinate multiple Linear tickets in parallel across git worktrees. The orchestrator creates worktrees, dispatches `/oneshot` workers, tracks progress via a dashboard, and enforces quality gates through adversarial verification. **The orchestrator NEVER writes application code** — it only coordinates, monitors, and verifies. > **Two dispatch modes.** With the default `catalyst.orchestration.dispatchMode: "oneshot-legacy"`, > each ticket gets one long `claude -p` `/catalyst-dev:oneshot` worke...
Create an orchestrator worktree and output a single copy-paste command to launch the orchestration run. No questions — parse the input, create the worktree, print the command.
Audit plugin health and find broken references in manifests, commands, agents, and skills
Analyze and reorganize a directory structure with safe reference updates
Validates YAML frontmatter on plugins/*/skills/*/SKILL.md and plugins/*/agents/*.md against docs/frontmatter-standard.md and .claude/rules/plugin-editing.md: required fields, the disable-model-invocation/user-invocable polarity, allowed-tools vs tools, and skill-only fields that must not leak (model, category). Use when adding or editing a skill or agent, before opening a PR that touches plugins/**, or paired with audit-references to confirm a plugin cleanup's frontmatter didn't drift.
Comprehensive backlog health analysis that identifies: - Issues without projects (orphaned) - Issues in wrong projects (misclassified) - Issues without estimates - Stale issues (no activity >30 days) - Duplicate issues (similar titles)
A fixture skill that declares a neutral classification and can reach a non-Claude target.
A fixture skill with no neutral classification — legal, but cannot reach a non-Claude target.