bcbeidel
57 verified skills57 total stars
check-shell
Audits a general-purpose shell script against 14 curated lints grouped into Portability / Safety / Documentation, detects and merges findings from shellcheck / shfmt / checkbashisms when present, and surfaces a Missing Tools preamble with install hints when any are absent. Use when the user wants to "audit a shell script", "check this bash script", "review my shell script", "lint a script", or "is this script safe". Not for hook scripts — route to `/build:check-hook`.
tools1
build-shell
Scaffolds a general-purpose shell script with a strict-mode preamble, structured file header, dependency preflight, and conditional features scoped to a declared target shell (bash 3.2 / 4+ / 5+ / POSIX sh). Use when the user wants to "create a shell script", "scaffold a bash script", "write a CLI script", "new utility script", or "build a shell script". Not for Claude Code hooks — route to `/build:build-hook`.
tools1
refine-prompt
Assesses and refines prompts using evidence-backed techniques. Use when the user wants to "improve a prompt", "refine this prompt", or "assess prompt quality", or to review any prompt text or SKILL.md instruction block for clarity, structure, and completeness.
testing1
build-readme
Scaffolds a project's top-level README.md — the `README.md` at a repository root that orients a first-time reader in the top 30 seconds. Produces a conditionalized template with a single H1, one-sentence description, problem statement, badges block, H2 section sequence (Prerequisites → Installation → Usage → Configuration → Troubleshooting → Contributing → License), fenced code blocks with language tags, and placeholder discipline. Use when the user wants to "scaffold a README", "create a README", or "bootstrap README.md". Not for sub-package READMEs inside a monorepo, docs-site landing pages, or GitHub org-profile READMEs — those have different audiences and out of scope.
development1
build-resolver
Scaffold a root-level RESOLVER.md — a dual routing table (filing for writes, context for reads) plus an AGENTS.md pointer and a trigger-eval sidecar at `.resolver/evals.yml`. Use when the user wants to "scaffold RESOLVER.md", "create a resolver", or "add a routing table for filing and context".
development1
check-help-skill
Use when the user wants to "audit a help skill", "review my plugin index", or "verify my help-skill is up to date". Audits a plugins/<plugin>/skills/help/SKILL.md against the help-skill rubric — coverage, freshness, frontmatter fidelity, plus five judgment dimensions and a trigger-collision check.
tools1
check-pre-commit-config
Audits a `.pre-commit-config.yaml` (and referenced local hook scripts) against 20 deterministic checks (YAML shape, `rev:` pinning, scope declarations, network-call / destructive-command / error-suppression patterns, shell-script strict mode, hook explicit-name and require-serial hygiene) plus seven judgment dimensions and a Tier-3 cross-config collision check. Use when the user wants to "audit pre-commit", "lint pre-commit", or "review my pre-commit hooks". Not for hand-rolled `.git/hooks/` — out of scope. Not for CI pipelines — route elsewhere.
development1
check-rule
Check a Claude Code rule library under `.claude/rules/` for path-glob validity, vague phrasing, contradictions, and oversize files. Use when the user wants to "audit rules", "review my rules", or "find conflicting rules".
development1
check-readme
Audits a project's top-level README.md against 28 deterministic checks across seven scripts (secret scanning, H1 uniqueness & position, heading-hierarchy skips, section presence & order, TOC threshold, line count & length, code-block language tags, shell-prompt prefixes, smart quotes in code, relative-link resolution, fragment-anchor resolution, image alt text, badge/image byte size, destructive-command flagging, pipe-to-shell patterns, TLS-disable instructions, non-reserved hostnames/IPs, emoji in headings, LICENSE file presence & link, CONTRIBUTING link, TODO/FIXME/XXX markers, README gitignore status) plus seven judgment dimensions and a Tier-3 cross-README collision check. Use when the user wants to "audit a README", "lint a README", or "run linters on README.md". Not for sub-package READMEs (different rubric) or docs-site pages (different toolchain).
tools1
check-bash-script
Audits a Bash 4.0+ script against 34 deterministic rules emitted as JSON envelopes (shebang, `set -euo pipefail`, header comment, main + sourceable guard, readonly constants, mktemp+trap pairing, shellcheck rule set SC2086 / SC2046 / SC2068 / SC2154 / SC2155 / SC2006 / SC2010 / SC2012 / SC2045 / SC2013 / SC2162 / SC2038 / SC2164 / SC2002 / SC2294, shfmt format compliance, eval / GNU-flag / `/tmp/` literal flagging, secret patterns, line count, naming conventions, command preflight) plus six judgment dimensions (output discipline, input validation, performance intent, function design, commenting intent, cross-entity collision). Use when the user wants to "audit a bash script", "lint a bash script", or "run shellcheck on this". Not for POSIX `sh` portability — refused at scope. Not for Python scripts — route to `/build:check-python-script`.
development1
occams-razor
Find the simplest explanation or solution that accounts for all known facts — use when there are multiple competing explanations and the simplest hasn't been tried first
tools1
reversibility
Assess decision risk by classifying as one-way or two-way door — use when calibrating how much analysis a decision deserves before committing
testing1
build-github-workflow
Scaffolds a GitHub Actions workflow — a YAML file under `.github/workflows/` — with top-level least-priv `permissions:`, SHA-pinned `uses:`, per-job `timeout-minutes`, workflow-level `defaults.run.shell: bash`, scoped triggers, `harden-runner` as first step, `set -euo pipefail` in every multi-line `run:`, and deliberate concurrency posture (cancel-in-progress for PR/push, no-cancel for deploy). Use when the user wants to "scaffold a ci workflow", "create a github workflow", or "build a github actions workflow for X". Not for composite actions (`action.yml` — separate primitive), org rulesets, Dependabot configs, or GitHub Apps.
development1
swot
Map strengths, weaknesses, opportunities, and threats systematically — use when evaluating a strategic position or deciding how to proceed with both internal and external factors at play
testing1
verify-work
Verifies completed work against validation criteria. Works in two modes: with a plan (runs the plan's Validation section) or ad-hoc (builds checks from git diff, project config, and project docs). Use when the user wants to "verify the work", "validate the work", or "run checks", or after completing all tasks in a plan.
development1
start-work
Use when you have an approved implementation plan to execute. Handles sequential execution, progress tracking, and recovery. Enforces the approval gate. Use when the user wants to "execute the plan", "implement this plan", or "start work".
tools1
build-bash-script
Scaffolds a standalone Bash 4.0+ script — a single-file CLI tool, glue automation, or ops utility — with explicit shebang, `set -euo pipefail`, header comment, `readonly` constants, `die` helper, `local` variables, `main` function, and a sourceable guard. Use when the user wants to "scaffold a bash script", "create a bash script", or "scaffold a shell script". Not for POSIX `sh` portability targets, Claude Code hooks, or scripts that would be cleaner in Python — route to the appropriate primitive.
tools1
build-help-skill
Use when the user wants to "scaffold a help skill", "add a /<plugin>:help command", or "build a plugin index skill", or wants to give a plugin an orientation surface that lists its skills and common workflows. Produces a SKILL.md at plugins/<plugin>/skills/help/SKILL.md.
tools1
check-makefile
Audits a top-level Makefile against 29 deterministic checks (strict-shell pin, `.SHELLFLAGS`, `MAKEFLAGS` warnings, `.PHONY` coverage, tab-indent, header comment, help-target patterns, variable-assignment discipline, top-level shell, destructive-op guards including `rm -rf`/`sudo`/global-install/curl-pipe, recipe hygiene, secrets, file/line size, optional `checkmake` wrap) plus seven judgment dimensions and a Tier-3 cross-Makefile collision check. Use when the user wants to "audit a makefile", "lint a makefile", or "review this makefile". Not for POSIX-`make`, compilation trees, or recursive multi-module builds — different rubric.
development1
build-rule
Create a Claude Code rule under `.claude/rules/` — a markdown instruction file with optional `paths:` frontmatter for path-scoping. Use when the user wants to "create a rule", "capture this convention", or "enforce this pattern".
development1
check-hook
Audits Claude Code hooks configuration for event coverage, script safety, async and blocking contradictions, Stop hook loop risks, rule overlap, and idempotency. Use when the user wants to "audit hooks", "review hooks", or "are my hooks safe".
development1
build-subagent
Scaffolds a Claude Code custom subagent definition — a `.md` file under `.claude/agents/` with a routing-oriented description, an explicit `tools` allowlist sized to the workflow, a bounded system prompt in the markdown body, and explicit failure behavior. Use when the user wants to "create a subagent", "scaffold an agent", or "make a custom agent". Not for skills (route to `/build:build-skill`), hooks (route to `/build:build-hook`), or rules (route to `/build:build-rule`).
tools1
check-python-script
Audits a standalone Python 3 script against 25 deterministic checks (shebang, `__main__` guard, argparse shape, declared dependencies, ruff-backed AST lints, line count, secret patterns) plus nine judgment dimensions (output discipline, input validation, dependency posture, performance intent, naming, function design, module-scope discipline, literal intent, commenting intent) and a Tier-3 cross-script collision check. Use when the user wants to "audit a python script", "lint a python script", or "review this script". Not for general-purpose shell scripts — route to `/build:check-bash-script`.
development1
build-skill-pair
Scaffolds a primitive-pair — a matched `build-<primitive>` and `check-<primitive>` skill sharing a single distilled principles doc under `_shared/references/`, plus one `references/check-<dim>.md` per judgment dimension on the check half. Distills best-practice material (files, URLs, pasted text, or the model's own domain knowledge) into one rubric that both halves reference. Use when the user wants to "create a skill pair", "scaffold build and check skills for X", or "codify best practices for a new primitive". Not for creating a single skill — route to `/build:build-skill`. Not for auditing an existing pair — route to `/build:check-skill` on each half.
development1
build-skill
Use when the user wants to "create a skill", "scaffold a skill", or "new skill for [X]", or wants to capture a recurring workflow as a reusable Claude Code skill. Also use to improve an existing SKILL.md.
development1
check-resolver
Audit a root-level resolver — verify AGENTS.md pointer, managed-region integrity, filing-table coverage against disk, context-table actionability, and trigger-eval pass rate. Use when the user wants to "audit a resolver", "validate routing table", or "find dark capabilities".
testing1
build-hook
Builds a Claude Code hook (event-driven quality gate) with a script and the corresponding settings.json hooks entry. Use when the user wants to "create a hook", "add a PostToolUse hook", or "enforce quality on tool use".
tools1
check-skill-pair
Audits pair-level integrity of a primitive-pair (the artifact `/build:build-skill-pair` produces) by walking the four required artifact slots — principles doc, `build-<primitive>/SKILL.md`, `check-<primitive>/SKILL.md`, and the `primitive-routing.md` registration — and reports cross-artifact issues a per-SKILL.md checker cannot see: missing principles doc, divergent principles paths between halves, absent routing registration, missing build→check handoff. Per-half structural compliance with the unified pattern (`check-skill-pattern.md`) is delegated to `plugins/build/_shared/scripts/check_skill_pattern.py`. Use when the user wants to "audit a skill pair", "review a primitive pair", or "validate the skill pair for X". Not for auditing a single SKILL.md — route to `/build:check-skill`. Not for re-distilling a stale principles doc — route to `/build:build-skill-pair`.
tools1
check-github-workflow
Audits a GitHub Actions workflow YAML file (or a directory under `.github/workflows/`) against 30 deterministic checks (top-level `name:`, permissions, timeouts, concurrency, SHA-pinning for every `uses:`, no `@main`/`@master`/floating refs, `pull_request_target` + PR checkout combo, template injection in `run:`, deprecated commands, secrets-in-top-env, fork-PR secret exposure, harden-runner first, persist-credentials, strict bash, actionlint, zizmor, yamllint, shellcheck on extracted `run:` content) plus seven judgment dimensions. Use when the user wants to "audit a github workflow", "lint my workflow", or "run zizmor on this". Not for composite actions — different rubric.
development1
check-subagent
Audits Claude Code custom subagent definitions against deterministic Tier-1 checks (location, frontmatter shape, naming, `tools` hygiene, prompt size, body structure, secret patterns) and seven judgment dimensions (scope discipline, routing-description quality, tool proportionality, output contract, voice & framing, failure behavior, injection surface). Use when the user wants to "audit a subagent", "review agent permissions", or "validate a subagent definition". Not for skills (route to `/build:check-skill`), hooks (route to `/build:check-hook`), or rules (route to `/build:check-rule`).
tools1
10-10-10
Evaluate decisions by considering impact across three time horizons — use when short-term emotions and long-term consequences may point in different directions
testing1
circle-of-competence
Scope decisions by distinguishing what you know well from what you don't — use when expertise boundaries are uncertain or a decision requires knowledge outside your direct experience
testing1
consider
Apply structured mental models to think through problems. Use when the user wants to "analyze", "evaluate", "think through", "decide between", "weigh tradeoffs", or needs a framework for a decision.
development1
check-skill
Use when the user wants to "audit a skill", "review a skill", or "improve a skill". Audits a Claude Code SKILL.md for format compliance, content quality, and cross-skill description collisions across three tiers (deterministic scripts → LLM rubric → cross-skill conflict).
development1
hanlons-razor
Interpret behavior charitably — attribute to mistakes before malice; use when behavior seems hostile or frustrating and an adversarial interpretation is forming
development1
first-principles
Break down assumptions and rebuild reasoning from fundamental truths — use when a standard approach feels wrong or produces diminishing returns but no one has questioned its underlying assumptions
development1
check-skill-chain
Design a skill-chain from a goal, or check an existing skill-chain manifest for structural and contract issues. Use when the user wants to "design a skill-chain", "audit a chain", or "repair a chain".
development1
eisenhower-matrix
Prioritize tasks and decisions by mapping urgency against importance — use when facing competing demands and unclear where to focus first
testing1
opportunity-cost
Evaluate what you give up by choosing one option over alternatives — use when a decision is being made without explicitly naming the best alternative foregone
development1
pick-model
Select the right AI model for a task based on external benchmarks, pricing, and effort tradeoffs. Use when the user asks "which model should I use?", "what's the best model for X?", "help me pick a model", "model comparison", "should I use Opus or Sonnet?", or needs to decide between AI models for a specific workload. Also use when someone mentions cost optimization for LLM usage or wants to know if a cheaper model would work.
testing1
one-thing
Identify the single highest-leverage action that makes everything else easier — use when there are too many competing priorities and focus needs to be established before work begins
data-ai1
via-negativa
Improve by removing problems rather than adding solutions — use when a system or process has accumulated complexity and improvement by addition has hit diminishing returns
tools1
map-vs-territory
Recognize where your mental model diverges from reality — use when a plan or model is driving decisions and its assumptions haven't been stress-tested
testing1
second-order
Think through the consequences of consequences before acting — use when an action has obvious immediate effects but the downstream consequences haven't been traced
content-media1
ingest
Ingest any source into wiki pages. Use when the user says "ingest this", "add to wiki", or "update wiki with", or provides a URL, file path, or pasted text for knowledge capture.
documentation1
research
Conducts structured investigations using the SIFT framework and produces verified research documents. Use when the user wants to "research", "investigate", or "deep dive into" a topic — any request to conduct a structured investigation.
development1
5-whys
Drill to root cause by asking why repeatedly until fundamentals emerge — use when a problem recurs or the quick fix keeps failing to hold
data-ai1
setup
Initialize or update project context. Use when starting a new project, setting up context structure, configuring project documentation, or re-run to verify and repair an existing setup. Idempotent — safe to run multiple times.
testing1
finish-work
Use when implementation is complete and validated, to decide how to integrate the work. Presents structured options for merge, PR, keep, or discard with safety verification. Use when the user wants to "finish", "create PR", or "ship it", or after completing all tasks and validation in a plan.
testing1
scope-work
Use before creating implementation plans. Explores user intent, requirements, and design through structured divergent-then-convergent thinking. Produces a design document, not code. Use when the user wants to "brainstorm", "design", or "figure out what to build", or needs to think through a problem before planning.
development1
plan-work
Use when the user has a spec or requirements for a multi-step task, before touching code. Creates structured implementation plans with explicit lifecycle management and verification criteria. Use when the user wants to "plan", "make an implementation plan", "break this down into tasks", or needs to turn a design into actionable work items.
development1
lint
Runs lint checks on project content quality and reports frontmatter, URL, index, and skill issues. Use when the user asks to "lint", "audit content quality", or "check health".
development1
build-makefile
Scaffolds a top-level Makefile for repository workflow orchestration — strict-shell header, safety `MAKEFLAGS`, `.PHONY` coverage, self-documenting `help` from `## description` comments, overridable `?=` config, and a flat target graph with scoped `clean`. Use when the user wants to "create a makefile", "scaffold a makefile", or "new makefile for [X]". Not for POSIX-`make`, compilation-driving Makefiles, or multi-module recursive builds.
development1
build-pre-commit-config
Scaffolds a reproducible pre-commit configuration — a `.pre-commit-config.yaml` at the repo root (optionally with local shell scripts under `scripts/hooks/`) that runs formatters, linters, and validators against staged changes via the `pre-commit` framework. Pins every `rev:`, declares scope per hook, serializes file-mutators, and documents the bootstrap. Use when the user wants to "set up pre-commit", "scaffold pre-commit hooks", or "configure .pre-commit-config.yaml". Not for hand-rolled `.git/hooks/` scripts, not for `pre-push` / `commit-msg` / server-side hooks, not for CI pipelines — route to the appropriate primitive.
development1
build-python-script
Scaffolds a standalone Python 3 script — a single-file CLI tool, automation helper, or data-wrangling utility — with shebang, module docstring, `main(argv) -> int`, `__main__` guard via `sys.exit(main())`, argparse parser, KeyboardInterrupt handling, and declared dependencies. Use when the user wants to "scaffold a python script", "create a python script", or "build an automation script in python". Not for long-running services, packages with multiple modules, or Claude Code hooks — route to the appropriate primitive instead.
tools1
pareto
Apply the 80/20 rule to find the highest-leverage inputs — use when effort and results feel misaligned or there are too many things competing for attention
data-ai1
inversion
Solve problems backwards by identifying what would guarantee failure — use when direct optimization feels stuck or failure modes are unclear
data-ai1