cboone
- 51 skills
- 0 followers
- 6 hours ago last updated
- ▌ Pr · cbooneCommit all changes (if needed), push to remote, and create a GitHub pull request in one automated step with no prompts. Handles plan files automatically (renaming, moving completed plans to done). Use when the user says "pr", "create a pr", "open a pr", "submit a pr", "push and create pr", "commit and create pr", or any variant involving creating a pull request from the current branch. Requires the gh CLI to be installed.
- ▌ Commit · cbooneCreate well-structured git commits with context-aware message generation, plan awareness, and support for common commit workflow variants. Use when the user says "commit", "commit the changes", "commit and push", "commit the plan", "commit staged", "commit just the staged changes", "give the plan a meaningful name and commit", or any variant involving committing code changes.
- ▌ Check Versions · cbooneVerify that plugin versions and marketplace.json are correct and consistent after changes on the current branch. Use when the user says "check versions", "verify versions", "are the versions correct", "review version bumps", or any similar variant. Also use after merging, rebasing, or before creating a PR.
- ▌ Release · cboone bundlePrepare a versioned release or Claude Code marketplace catalog state tag: detect project type, analyze conventional commits, update release files, create a release commit, tag it locally, and optionally push and create a GitHub Release. Use when the user says "release", "create a release", "cut a release", "prepare a release", "bump the version", "tag a release", "make a release", or any variant involving creating a new versioned release.
- ▌ Use Git · cboone bundleGit and GitHub CLI conventions for Claude Code. Use when: (1) running git commands (commit, push, merge, rebase), (2) running gh CLI commands (pr create, issue create, pr review), (3) passing long content to git or gh (PR bodies, issue bodies, release notes, review replies), (4) reviewing code that uses git or gh CLI patterns. Covers tmpfile patterns, HEREDOC commits, GPG signing, safe push practices, and permission-prompt avoidance.
- ▌ Set Up CI · cboone bundleSet up GitHub Actions CI with test, lint, format, and vulnerability check jobs, plus matching Makefile targets. Use when the user says "set up CI", "add GitHub Actions", "create a CI workflow", "add CI", "set up GitHub Actions CI", "configure CI", or wants test, lint, and format jobs wired up for a project. Detects the project language (Go, JavaScript/TypeScript, Python, Rust, Ruby, Shell, Zig, Zsh, or multi-language) and selects the matching template. Pairs with set-up-linters (linter configuration), set-up-secret-scanning (gitleaks/TruffleHog), and add-scrut-cli-tests (CLI snapshot tests).
- ▌ Merge Main · cbooneFetch and merge the base branch (usually main) into the current feature branch, handling conflicts and pushing. Use when the user says "merge main", "merge in main", "merge base branch", "update from main", "pull in main", "sync with main", "merge main into this branch", "update branch from main", or any variant involving merging the default branch into the current working branch.
- ▌ Write Math · cboone bundleMathematical writing and exposition guide based on Tao, Knuth, Halmos, and other leading references. Use whenever you produce or discuss mathematical content in any venue -- including chat responses and docstrings, not only file edits: (1) writing or editing mathematical prose in LaTeX, Pandoc Markdown, plain text, or Lean docstrings with mathematical content, (2) stating theorems, structuring proofs, or writing proof sketches (including informal sketches in a chat response), (3) explaining mathematical concepts, propositions, definitions, or results to the user, (4) summarizing or reporting on mathematical work or proof-formalization progress, (5) choosing, reviewing, or disambiguating notation, (6) organizing a mathematics paper, (7) reviewing mathematical exposition for clarity and correctness.
- ▌ Write Latex · cboone bundleLaTeX mathematical typesetting style guide based on AMS, IEEE, ISO 80000-2, and Knuth conventions. Use when: (1) writing or editing .tex files, (2) writing raw LaTeX blocks in Pandoc Markdown, (3) setting up LaTeX preambles or macros, (4) working with BibTeX files, or (5) reviewing LaTeX code for typesetting quality.
- ▌ Create Issue · cbooneCreate a GitHub issue using the gh CLI with tmpfile-based body content to avoid permission prompts from large multiline Bash arguments. Use when the user says "create issue", "create a GitHub issue", "file an issue", "open an issue", "new issue", "report a bug", "request a feature", or asks to create an issue on a GitHub repository. Requires the gh CLI to be installed and authenticated.
- ▌ Lint And Fix · cbooneDetect available linters and formatters in the project, run them with auto-fix flags, report results, manually resolve remaining issues, then commit and push the fixes. Use when the user says "lint and fix", "run the linter", "run linters", "fix lint errors", "format the code", "lint this project", "check and fix", "run eslint", "run prettier", or any variant involving running project linters or formatters.
- ▌ Address Issue · cbooneFetch a GitHub issue, analyze it, plan and execute the work in the current branch, and commit with issue references. Use when the user says "address issue", "address issue #42", "address #42", "fix issue #42", "work on issue #42", "handle issue #42", "resolve issue #42", "tackle issue #42", "implement issue #42", or references addressing a GitHub issue by number or description. Requires the gh CLI to be installed and authenticated.
- ▌ Create Plugin · cboone bundleGuide for creating new plugins in this repository with consistent structure and conventions. Use when the user says "create a plugin", "add a new skill", "add a new hook", "add a new command", "create a slash command", "new plugin", "scaffold plugin", "create a new plugin", or asks to add a skill, hook, or command to this repository.
- ▌ Review Branch · cbooneReview and evaluate all work done on the current branch: summarize changes, rigorously assess plan compliance, and independently evaluate code quality. Use when the user says "review branch", "review the work done on this branch", "summarize this branch", "where are we on this branch", "what's been done on this branch", "branch summary", "compare branch to plan", "evaluate this branch", or any variant involving reviewing, summarizing, or evaluating the work on the current branch.
- ▌ Write Go Code · cboone bundleGo code style guide based on Google Go Style Guide, Effective Go, and Code Review Comments. Use when: (1) writing new Go code, (2) reviewing Go code for style compliance, (3) refactoring existing Go code, (4) conducting code reviews. Covers naming, error handling, concurrency, testing, data types, functions, interfaces, code organization, and Cobra CLI command behavior.
- ▌ Address Review · cbooneParse a review document for actionable feedback items, work through them systematically, and track resolution progress. Use when the user says "address review", "address the review", "address @docs/reviews/...", "work through the review feedback", "resolve review items", "address the issues in @docs/...", or references addressing a review document by path.
- ▌ Handle Secrets · cboone bundleBest practices for handling user-provided secrets in CLI tools. Use when: (1) building CLI tools that accept API keys, tokens, or passwords from users, (2) reviewing secret-handling code for security issues, (3) choosing between input methods (env vars, stdin, keychains, config files), (4) implementing credential storage or retrieval. Covers the security hierarchy of input methods, credential storage patterns, secret masking, and language-specific libraries.
- ▌ Pin Everything · cboone bundlePin every version surface in a repository to commit hashes, integrity digests, or specific versions as a one-shot supply-chain hardening pass. Use when the user says "pin everything", "pin all versions", "harden version pinning", "SHA-pin actions", "SHA-pin all the actions", "pin to commit hashes", "audit version pins", "pin all uses to commit hashes", or wants to harden a repository against supply-chain attacks. SHA-pins GitHub Actions, integrity- pins Yarn via Corepack, exact-pins application package-manager dependencies, migrates scaffolded CI to language version files, pins install commands, and optionally generates a weekly drift-audit script. For ongoing template-drift detection use refresh-project-scaffolding; for credential-leak hardening use set-up-secret-scanning.
- ▌ Set Up Linters · cboone bundleDetect project languages, recommend linters and formatters, install them, and generate config files, including Pandoc-academic Markdown presets. Use when the user says "set up linters", "add linters", "configure linters", "set up formatters", "add a formatter", "add prettier", "add eslint", "add golangci-lint", "add ruff", "add clippy", "add markdownlint", "generate linter configs", "lint configuration", or wants linting and formatting wired up for a project. Detects Go, JavaScript/TypeScript, Python, Ruby, Rust, Shell, Swift, Zsh, Lean, and Markdown. Pairs with set-up-ci (CI workflows), set-up-secret-scanning (gitleaks and TruffleHog), and lint-and-fix (running the linters once they are configured).
- ▌ Write Markdown · cboone bundleApplies Markdown style conventions when creating or editing Markdown files. Use when: (1) creating new Markdown files, (2) editing existing .md files, or (3) reviewing Markdown for style and formatting issues.
- ▌ Create Worktree · cbooneCreate a new git worktree, branch, and tmux window using workmux, with a task prompt injected into the new session. Use when the user says "create worktree", "new worktree", "start working on", "spin up a worktree", or asks to create a worktree for a general task (not tied to a specific GitHub issue -- use create-worktree-from-issue for that). Requires workmux to be installed.
- ▌ Scaffold Go CLI · cboone bundleScaffold a complete Go CLI project with Cobra, GoReleaser, GitHub Actions CI/CD, Homebrew tap publishing, and Makefile. Use when the user says "scaffold a Go CLI", "new Go CLI project", "create a Go CLI", "start a Go CLI", "bootstrap a Go CLI", or starts a Go command-line tool from scratch. Optionally adds Viper for config file management and Charmbracelet bubbletea/lipgloss/bubbles for TUI work. For Go libraries (no main.go) use scaffold-go-library instead. For language-agnostic boilerplate alone, use scaffold-new-repo.
- ▌ Write Lean Code · cboone bundleLean 4 style guide and Mathlib conventions. Use whenever Lean code is the subject of the work, not only when editing: (1) writing, editing, or reviewing .lean files, (2) reading Lean source to answer a user question about it, (3) planning, proposing, or naming lemmas, definitions, theorems, or tactics before implementation, (4) discussing Lean design decisions, refactors, API choices, or proof strategies, (5) summarizing proof status or reporting on formalization progress, (6) writing or editing Lean docstrings and comments, (7) formalizing mathematical proofs, (8) writing custom tactics or metaprograms. Applies to any touch on .lean files or the proofs/ directory, including reading and discussion, not just edits. Covers naming, formatting, proof style, Mathlib conventions, general functional programming, and metaprogramming.
- ▌ Rebase Onto Main · cbooneFetch and rebase the current feature branch onto the base branch (usually main), handling conflicts per commit and force-with-lease pushing. Use when the user says "rebase onto main", "rebase on main", "rebase against main", "rebase from main", "rebase main", "rebase branch", "update branch via rebase", "rebase against base branch", "replay commits onto main", or any variant involving rebasing the current working branch onto the default branch.
- ▌ Write Lean Tests · cbooneConventions for compile-time, `example`-based Lean 4 API regression tests that mirror a library's public surface. Use whenever Lean test code is the subject of the work, not only when editing: (1) creating, editing, or reviewing files under a `<Name>Test/` directory (sibling to the main `<Name>/` library directory), (2) adding a library module and deciding what its sibling test module should assert, (3) planning a milestone and scoping which `example`s must land alongside new exported definitions and lemmas, (4) diagnosing a failing or overly coupled test module (imports reaching into internals, `sorry` in test proofs, restating implementation rather than signature), (5) wiring `lake test` via `testDriver` / `defaultTargets` in a Lake config, (6) reviewing a PR that touches library or test code to check the test-mirroring invariant still holds. Pairs with `write-lean-code`, which owns naming, proof style, and Mathlib conventions for the library code itself.
- ▌ Add Cobra Version · cboone bundleAdd a version subcommand with build metadata to an existing Cobra-based Go CLI. Use when the user says "add a version subcommand", "add the version command", "wire up version, commit, and date", "add build metadata to version", "add a /version command to this CLI", "make the version command print commit and build date", or wants `cmd/version.go` plus matching ldflags wired up in `main.go`, `cmd/root.go`, `.goreleaser.yml`, and the `Makefile`. Detects whether the project already has a basic `version` variable or no version wiring at all, then applies the changes idempotently. Pairs with scaffold-go-cli (which seeds the basic version variable) and add-goreleaser-homebrew (which sets up GoReleaser when it is missing).
- ▌ Bootstrap Project · cboone bundleAssess a repository, determine what scaffolding and setup tools are needed, present a plan, and execute them in the correct order. Use when the user says "bootstrap this project", "set up everything", "scaffold everything", "full project setup", or any variant involving bootstrapping or scaffolding an entire project.
- ▌ Check Zsh Scripts · cboone bundleCheck and evaluate zsh scripts using shellcheck, shfmt, shellharden, zsh -n, zcompile, setopt warn_create_global/warn_nested_var, and checkbashisms. Use when: (1) creating or editing zsh scripts (.zsh, zshrc, zshenv, zprofile, zlogin, zlogout), (2) reviewing zsh code for bugs or portability issues, (3) checking zsh variable scoping, (4) formatting zsh scripts, or (5) the user says "check zsh", "check zsh scripts", "lint zsh", "validate zsh", "zsh check", or "check my zsh script".
- ▌ Scaffold New Repo · cboone bundleScaffold the universal boilerplate for a new repository: LICENSE, README, CHANGELOG, .gitignore, agent config files (AGENTS.md, CLAUDE.md symlink, .claude/settings.json, .github/copilot-instructions.md), and a plans directory. Use when the user says "scaffold a new repo", "set up a new project", "bootstrap a new repository", "initialize a new repo", "create the boilerplate for", or starts a new repository and wants language-agnostic foundation files. Supports go-cli, go-library, javascript, pascal, python, ruby, rust, shell, swift, zig-cli, and generic project types. For language-specific scaffolding, pairs with scaffold-go-cli, scaffold-go-library, and scaffold-rust-cli; for full setup including CI and linters, see bootstrap-project.
- ▌ Scaffold Rust CLI · cboone bundleScaffold a complete Rust CLI project with Cargo, cargo-deny, cargo-nextest, git-cliff, GitHub Actions CI/CD, and Makefile. Use when the user says "scaffold a Rust CLI", "new Rust CLI", "create a Rust binary crate", "start a Rust CLI", "bootstrap a Rust CLI", or starts a Rust command-line tool from scratch. Optionally adds clap for argument parsing and supports a macOS-only variant. For language-agnostic boilerplate alone, use scaffold-new-repo.
- ▌ Set Up Installers · cbooneSet up installer and distribution methods for Go, Swift, Rust, and Zig projects: a Homebrew tap formula for `brew install`, plus README and compatibility wiring for `go install` (Go) and `cargo install` (Rust). Use when the user says "set up installers", "add a Homebrew formula", "set up homebrew", "publish to homebrew tap", "support brew install", "support go install", "support cargo install", "set up distribution", or wants users to install their CLI through a package manager. Pairs with add-goreleaser-homebrew when GoReleaser-driven Homebrew publishing is the goal.
- ▌ Write Scrut Tests · cboone bundleApplies scrut test style conventions when creating or editing scrut test files for CLI binaries and zsh plugins. Use when: (1) creating new scrut test files in tests/scrut/, (2) editing existing scrut test .md files, (3) reviewing scrut tests for style and maintainability, or (4) testing zsh plugins or sourced libraries with scrut.
- ▌ Write Zsh Scripts · cboone bundleApplies zsh style conventions when creating or editing zsh scripts, configurations, and completions. Use when: (1) creating new zsh scripts or .zsh files, (2) editing existing zsh configurations or plugins, (3) writing zsh completion functions, or (4) reviewing zsh code for bugs or style issues.
- ▌ Suggest Next Issue · cbooneReview all open GitHub issues in the current repository, analyze them in context (current branch state, recent work, project goals, dependencies), and recommend what to work on next with prioritized reasoning. Use when the user says "suggest next issue", "what should I work on next", "which issue should I tackle", "prioritize issues", "review open issues", "suggest an issue", "triage issues", or asks for help choosing between open issues. Requires the gh CLI to be installed and authenticated.
- ▌ Upgrade Everything · cboone bundleAssess every version reference in a repository, check current upstream versions, evaluate repo-specific risk and reward, and present selectable upgrade options. Use when the user says "upgrade everything", "upgrade all versions", "check dependency upgrades", "assess upgrades", "update dependencies", "what can be upgraded", or asks for a full upgrade audit. Always includes every discovered upgrade candidate in the plan and applies upgrades only after explicit user selection.
- ▌ Write Bash Scripts · cboone bundleApplies Bash style conventions when creating or editing Bash scripts. Use when: (1) creating new Bash scripts, (2) editing existing scripts in /bin/, or (3) reviewing Bash code for bugs or style issues.
- ▌ Add Community Files · cboone bundleAdd standard community files to a project: CONTRIBUTING.md, CODE_OF_CONDUCT.md, SECURITY.md, and a pull request template. Use when the user says "add community files", "add contributing guide", "prepare for open source", "add code of conduct", "add security policy", or any variant involving adding community or open-source readiness files to a project.
- ▌ Add Scrut CLI Tests · cbooneSet up scrut snapshot-based CLI integration testing for a CLI project. Use when the user says "add scrut tests", "set up scrut", "add CLI integration tests", "add snapshot tests for the CLI", "wire up scrut", or wants end-to-end snapshot tests for a CLI binary. Detects the project language (Go, Swift, Rust, Zig, Python, Ruby, Shell), creates starter test files under tests/scrut/, adds Makefile targets, and integrates with CI. Pairs with the write-scrut-tests skill for authoring conventions.
- ▌ Scaffold Go Library · cboone bundleScaffold a Go library project with GoReleaser changelog-only releases, golangci-lint, GitHub Actions CI/CD (multi-version Go matrix), and Makefile. Use when the user says "scaffold a Go library", "new Go library", "create a Go package", "start a Go library", "bootstrap a Go library", or starts a Go module that exposes a library API rather than a CLI binary. For Go CLIs (have main.go) use scaffold-go-cli instead. For language-agnostic boilerplate alone, use scaffold-new-repo.
- ▌ Clean Up Agent Config · cboone bundleReview and reorganize AI coding agent configuration and instruction files across Claude Code, Codex, Copilot, and OpenCode. Use when the user says "clean up agent config", "organize agent files", "standardize agent instructions", "set up agent config", "review agent config", "consolidate agent files", or mentions reorganizing CLAUDE.md, AGENTS.md, settings.json, or copilot-instructions.md. Also use when the user wants to deduplicate or rationalize agent instruction files across tools.
- ▌ Manage Repo Licensing · cboone bundleBootstrap, audit, and maintain REUSE-style mixed-license coverage in a repository: populate `LICENSES/`, write a root `NOTICE`, wire a root `REUSE.toml`, apply SPDX headers or sidecars to files, and keep `reuse lint` clean. Use when the user says "license this repo", "bootstrap licensing", "add SPDX headers", "normalize LICENSES", "audit license coverage", "REUSE lint", "fix REUSE", "add a NOTICE", "set up multi-license", "this new file needs a license header", or any variant involving SPDX, REUSE, `.license` sidecars, CC-BY, or dual licensing in a repo-maintenance context. Do not fire for legal interpretation of license text or for third-party dependency licensing questions.
- ▌ Optimize Runner Usage · cbooneAdd paths-ignore, concurrency groups, and timeout-minutes to existing GitHub Actions workflows. Use when the user says "optimize runner usage", "reduce CI costs", "reduce GitHub Actions minutes", "add concurrency to workflows", "add paths-ignore", "add timeout-minutes", "cancel in-progress CI runs", "skip CI on docs changes", or wants to cut runner-minute waste on already configured workflows. Private repos pay for Actions minutes and macOS runners cost 10x Linux runners, so these optimizations matter most there. For creating a CI workflow from scratch, use set-up-ci instead.
- ▌ Scaffold Lean Library · cboone bundleScaffold a Lean 4 library project with Mathlib or PFR dependencies, Lake test/lint wiring, GitHub Actions CI, text linting, and agent instructions. Use when the user says "scaffold a Lean library", "new Lean project", "new Mathlib project", "create a Lean formalization repo", "start a Mathlib-downstream library", or "create a PFR downstream formalization". For Lean proof, naming, or module edits inside an existing project, use write-lean-code instead. For compile-time test modules in an existing project, use write-lean-tests.
- ▌ Write Pandoc Markdown · cboone bundlePandoc-flavored Markdown conventions for academic papers with LaTeX output. Use when: (1) writing or editing .md files that use Pandoc extensions (math delimiters, citations, raw LaTeX blocks), (2) configuring YAML frontmatter for academic papers, (3) using Pandoc citation syntax, (4) embedding raw LaTeX in Markdown, or (5) working with the Pandoc-to-LaTeX build pipeline. This skill is distinct from write-markdown, which covers GFM and markdownlint rules.
- ▌ Set Up Secret Scanning · cboone bundleSet up secret scanning with gitleaks and TruffleHog GitHub Actions workflows and optional gitleaks configuration. Use when the user says "add secret scanning", "set up secret scanning", "set up gitleaks", "set up trufflehog", "scan for secrets in CI", or wants to detect leaked credentials in a repository. Both tools run on pushes to `main`, on pull requests, and on `workflow_dispatch`; gitleaks does fast pattern matching, TruffleHog adds verification-based scanning. Pairs with handle-secrets for application-level secret hygiene.
- ▌ Write Homebrew Formula · cboone bundleWrite or update Homebrew formulae using current Homebrew guidance and cboone/homebrew-tap conventions. Use when the user says "write a Homebrew formula", "update a formula", "add a brew formula", "review this formula", "convert this HEAD formula to stable", or asks for Homebrew tap packaging. Supports stable release formulae, HEAD-only formulae, Go source builds, GoReleaser-generated outputs, shell tools, caveats, services, completions, man pages, config files, and formula validation. Requires Homebrew for full local validation.
- ▌ Add Goreleaser Homebrew · cboone bundleAdd GoReleaser configuration and a GitHub Actions release workflow to an existing Go CLI project with Homebrew tap publishing. Use when the user says "add goreleaser", "set up goreleaser", "add Homebrew tap publishing", "publish to Homebrew", "set up release workflow", "add release automation for Go", or wants a Go CLI to ship signed release artifacts and a Homebrew cask. Detects shell completions, man-page generation, and macOS-only constraints, then conditionally tailors the GoReleaser config. Pairs with set-up-installers (alternative non-GoReleaser installer paths) and the release skill (cutting tagged releases).
- ▌ Create Worktree From Issue · cbooneFind a GitHub issue in the current repository and create a new git worktree, branch, and tmux window for working on it using workmux. Use when the user says "start issue", "create worktree from issue", "create worktree for issue", or references starting work on a GitHub issue by number (e.g., "#42") or by description (e.g., "the dark mode issue") in a new worktree. Requires the gh CLI and workmux to be installed.
- ▌ Refresh Project Scaffolding · cbooneRefresh existing project scaffolding against the latest agent-harness-plugins templates. Use when the user says "refresh project scaffolding", "update everything", "audit my repo", "audit the repo", "refresh templates", "bring this repo up to date", "check what's outdated", or wants the maintenance companion to bootstrap-project. Detects which scaffolds, CI workflows, linters, and installers are in use, diffs them against current templates, and applies confirmed updates. Does not set up tools that were never used; use bootstrap-project for initial setup.
- ▌ Resolve Copilot Pr Feedback · cbooneProcess and resolve GitHub Copilot automated PR review comments. Use when the user says "check copilot review", "handle copilot comments", "resolve copilot feedback", "address copilot suggestions", or mentions Copilot PR comments. Also use after PR creation when Copilot has left automated review comments.
- ▌ Write Formalization Roadmap · cboone bundlePlanning-document structure guide for multi-milestone formalization roadmaps (Lean, Rocq, Isabelle, HOL, and other proof assistants). A sibling to write-math that governs *document structure*, not mathematical prose. Use whenever a formalization roadmap is the subject of the work, including (1) writing or editing a new roadmap under docs/plans/todo/ that lays out a multi-milestone proof project, (2) reviewing an existing roadmap for structural drift or missing conventions, (3) updating a roadmap when scope, milestones, or verification gates change, (4) deciding whether a planning document should be a roadmap (multi-milestone, long-lived) or a single implementation plan (bounded, short-lived), (5) spinning out a per-milestone plan file from a roadmap entry, (6) auditing a milestone entry for the five required parts, (7) discussing roadmap structure with the user before drafting. Applies regardless of which proof assistant or host library the roadmap targets.