clybor-claude-tooling

Review a tooling change made in a working repo (new skill, script, rule, hook, template, or workflow fix) and promote the universal parts into the clybor-claude-tooling master template. Use when the user says "promote to tooling", "add this to the master tooling", "update clybor-claude-tooling", "parlay this into the template", "should this go in the template repo", or right after building or adapting tooling in any project repo. Runs a universality test, diffs against the master counterpart, generalizes project-specific bits, applies the edit, wires references, and flags downstream repos that need a re-sync.

Template for writing a domain-governance skill — the pattern of encoding a domain's tool-selection rules, defaults, known bugs, and pre-write checks as an on-demand skill instead of always-on context. Use when the user says "create a governance skill for {{DOMAIN}}", "codify the rules for [tool/domain]", "we keep making the same mistake with [tool]", or after the same operational failure recurs twice in one domain. Copy this template, replace every token, delete sections that don't apply.

Guided install of reusable Claude tooling from the clybor-claude-tooling catalog into a new project. Reads catalog.json, asks up to 4 project-profile questions, proposes a matching install set with rationales, copies assets into .claude/, fills the catalog-declared adaptation tokens in one batch-confirm round, and writes a TOOLING.md manifest recording what was installed. Use when the user says "bootstrap this project", "set up claude tooling for this project", "install tooling from the catalog", "what tooling from my catalog fits this project", or "init this repo from clybor-claude-tooling". Works for both Claude Code and Cowork projects.

Root-cause analysis protocol for when something breaks or fails unexpectedly. Use when a tool call fails twice, an integration returns unexpected results, a workflow produces wrong output, or any situation where retrying blindly would waste time. Also use when the user says "why did that break", "what went wrong", "debug this", or "figure out why X isn't working." Use proactively — if you catch yourself about to retry the same failing call a third time, stop and invoke this skill instead. Do NOT use for routine errors with obvious fixes (typos, missing params, wrong file path). Use when the failure is surprising or the cause is unclear.

Transform meeting transcripts (pasted text, .vtt/.srt/.txt uploads, or your meeting tool's export) into structured records — a summary note with decisions and open questions, plus tracked tasks for every action item. Use whenever the user pastes or uploads a meeting transcript, says "log this meeting", "process this transcript", "here are my meeting notes", "what happened in this call", "meeting summary", or "turn this into notes". Handles extraction and structuring, then writes to the record system your project uses.

Audit and rewrite content to remove AI writing patterns ("AI-isms") from deliverables, emails, and any written output. Use whenever generating client-facing or publish-grade content, drafting external emails longer than 3 sentences, writing proposals or reports, or when the user says "clean up the writing", "remove AI-isms", "make this sound less like AI", "audit the writing", "check for AI patterns", or "writing quality check". Also invoke automatically before any deliverable formatting step. If you just wrote or curated content that will go to a client or the public, run this skill on it before finalizing. Adapted from conorbronsdon/avoid-ai-writing v3.3.0 (MIT license).

Decompose a PRD into a sequenced checkbox task list. Each task is small enough to complete in one focused pass and tied to one or more PRD success criteria. Use after the PRD is accepted and before implementation begins. Triggers — "plan from the PRD", "break this into tasks", "task list for [feature]", "decompose [PRD]", "give me a plan".

Audit and rewrite content to remove AI writing patterns ("AI-isms") from deliverables, emails, and any written output. Use this skill whenever generating deliverable content (Phase 1 curation in any client deliverable skill), drafting client emails longer than 3 sentences, writing proposals or SOWs, creating reports, or when the user says "clean up the writing", "remove AI-isms", "make this sound less like AI", "audit the writing", "check for AI patterns", or "writing quality check". Also invoke automatically before any deliverable formatting step — do not skip. If you just wrote or curated content that will go to a client, run this skill on it before finalizing. Adapted from conorbronsdon/avoid-ai-writing v3.3.0 (MIT license).

Run a Ralph Loop — Stop-hook-driven autonomous iteration on a single prompt. Same prompt re-fed each iteration via a Stop hook that blocks session exit. Claude emits an exact completion-promise string to signal done. Use for well-defined tasks with automatic verification that can run autonomously (overnight, walk-away). Triggers — "ralph this", "ralph loop on X", "autonomous loop on X", "let it iterate until done", "run until completion-promise". Monolithic — one task per loop.

Write a PRD (product requirements doc) for a new feature or non-trivial change. Output is a markdown file with problem statement, binary success criteria, in/out of scope, dependencies, and risks. Use at the start of any work that warrants a quality gate before implementation. Triggers — "write a PRD", "draft a PRD for X", "start with a PRD", "PRD for [feature]", "spec out [feature]". The success criteria written here become the verification gates downstream — they must be binary (yes/no answerable), not vibes.

Run the deterministic verification gate against a PRD's success criteria. Every criterion must map to a check that returns a green/red signal. Use after ralph-implement completes and before the quality-review evaluation stage. Triggers — "verify against the PRD", "run the verification", "check success criteria", "did we hit all the gates", "verify [feature]". Hand-waving green checks is the most common way to ship the wrong thing.

Capture valuable insights, analyses, and decisions from a chat session and file them as persistent markdown so they survive past the current context. Use when a conversation produces something worth keeping — a comparison, a decision with rationale, a research synthesis, a non-obvious debugging finding, a framework. Triggers — "file this", "save this insight", "this is worth keeping", "remember this analysis", "crystallize this", "don't lose this". Also trigger proactively after deep analytical work whose result would help future sessions. Prevents the "forgotten session" problem where valuable thinking evaporates when the chat ends.

Promote a crystallized insight or one-off realization into always-on governance — a CLAUDE.md hard rule, a .claude/rules/*.md section, or a skill SKILL.md addition. Use when the user says "promote this to governance", "add this as a rule", "make this always-on", "codify this", "add to the router", or "this needs to be a rule not a note". Also trigger proactively right after insight-crystallizer when the insight meets promotion criteria (pattern recurred twice or more, describes a governance gap, prevents a known failure mode). Crystallizer captures knowledge; promotion makes knowledge enforceable.

Ralph-loop skill validator. Iteratively runs a target skill against representative inputs in a target repo, scores output against pass criteria, applies fixes, and re-runs until pass or budget exhausted. Use when you need to validate that a skill works as advertised on a real codebase rather than just reviewing the SKILL.md by eye. Triggers — "validate this skill against [repo]", "ralph loop on [skill]", "does this skill work on [target repo]", "run the skill-validator". Read-only against the target repo by default.

Implement a task list with the ralph-loop pattern — run, score, fix, re-run. Generic code-implementation loop (separate from skill-validator which targets skills). Use when executing a plan from task-plan. Triggers — "implement the plan", "ralph the implementation", "work the task list", "iterate on [feature]", "run the implementation loop". Two-strike rule on retries; escalates to `debugger` and `five-whys` on repeated failure rather than masking with a third blind retry.

Root-cause analysis protocol for when something breaks unexpectedly. Use when a tool call fails twice, a service returns unexpected results, a workflow produces wrong output, or any situation where retrying blindly would waste time. Triggered by "why did that break", "what went wrong", "debug this", or the Two Strikes Rule. Use proactively — if you catch yourself about to retry the same failing call a third time, stop and invoke this instead. Do NOT use for routine errors with obvious fixes (typos, missing params, wrong file path).

Structured 3-agent quality review using parallel simplifier, adversarial-reviewer, and chaos-engineer agents. Use when evaluating plans, designs, PRDs, architecture decisions, or any proposal before implementation. Three non-overlapping lenses — KISS/YAGNI, evidence/reasoning, robustness/edge cases.