Example agent template demonstrating frontmatter. Replace or delete. Use when the user explicitly invokes the example agent.
Execute a single fully-specced task file end-to-end — read the spec, do the work, ship the code and tests, and return a structured status. Dispatched by the `run-tasks` orchestrator skill; not typically invoked directly by humans. Each invocation handles exactly one task file; the agent does not pick its own task, does not understand the broader DAG, and does not run the acceptance criteria as a self-grade (the validator does that).
Independently verify that a completed task meets its acceptance criteria by running the checks listed in the task spec. Dispatched by the `run-tasks` orchestrator after a coder reports `done`; not typically invoked directly by humans. Read-only with respect to source code — the validator runs commands but does not edit files, does not understand the work, and does not attempt to fix anything.
Interview the user relentlessly about a plan or design until reaching shared understanding, resolving each branch of the decision tree. Use when user wants to stress-test a plan, get grilled on their design, or mentions "grill me".
Generate a Product Requirements Document (PRD) as a markdown file. Use this skill whenever the user asks for a PRD, product spec, product requirements doc, feature brief, or wants to "write up" / "draft" / "spec out" a feature or product. Trigger even when the user doesn't say the literal word "PRD" — phrases like "draft a spec for X", "write requirements for the new onboarding flow", or "I need a doc that explains what we're building and why" all qualify.
Drive a task DAG to completion by dispatching a coder subagent then a validator subagent for each eligible task, in serial. Use this skill whenever the user asks to "run the tasks", "execute the DAG", "drain the task queue", "start the autonomous coding session", "work through the plan", or similar phrasings that mean "actually do the work the task files describe." Trigger on phrases like "run the tasks in plans/<slug>/", "execute the DAG at …", "kick off the autopilot for …", "start coding the tasks", "drain plans/<slug>/tasks/". This is the step *after* `task-specs` — it assumes the task files are already fleshed out with full bodies (acceptance criteria, files to touch, etc.) and walks the DAG until completion or until something needs human attention.
Decompose a technical design document into a DAG (directed acyclic graph) of work tasks. Use this skill whenever the user asks to "break down" / "decompose" / "split up" a design into tasks, create a task DAG, sequence the work, or build a task list with dependencies. Trigger on phrases like "decompose the design at … into tasks", "break this design into a task DAG", "create the task list with dependencies", "what's the work breakdown for this design", "sequence the tasks for …", "decompose into a DAG", "build the work plan for the design". This is the step *after* a technical design — it produces a human-reviewable DAG (index.md with Mermaid + table) plus skeleton task files (one per task, with frontmatter), which the `task-specs` skill later fleshes out into full per-task specs.
Flesh out the skeleton task files from a task DAG into full self-contained task specifications that stateless coding agents can execute. Use this skill whenever the user asks to "spec out the tasks", "flesh out the task specs", "write the task specs for the DAG", "make the tasks executable", "expand the task skeletons", or "finalize the tasks for the coding agents". Trigger on phrases like "spec out the tasks in plans/<slug>/", "write specs for the DAG at …", "fill in the tasks", "make the tasks ready for execution", "task-spec the DAG". This is the step *after* `task-dag` — it reads each skeleton task file and replaces the 1-line body with a complete spec (files to touch, interface contracts, acceptance criteria, test plan, patterns to reuse), so a coding agent picking up a single task file has everything it needs without reading siblings.
Uses power tools
Uses Bash, Write, or Edit tools
Own this plugin?
Verify ownership to unlock analytics, metadata editing, and a verified badge. GitHub access is read-only (username + org membership).
Sign in to claimOwn this plugin?
Verify ownership to unlock analytics, metadata editing, and a verified badge. GitHub access is read-only (username + org membership).
Sign in to claimBased on adoption, maintenance, documentation, and repository signals. Not a security audit or endorsement.
Personal Claude Code plugin and marketplace. Holds the skills, agents, and slash commands I use across all my projects.
This repo is a single-plugin marketplace:
claude-bholzer/
├── .claude-plugin/
│ └── marketplace.json # marketplace catalog
└── plugins/
└── bholzer/ # the plugin
├── .claude-plugin/
│ └── plugin.json # plugin manifest
├── skills/ # directory-based skills (<name>/SKILL.md)
├── agents/ # subagent .md files
└── commands/ # flat-file slash commands
The marketplace is named bholzer and the plugin is also named bholzer, so skills/commands are invoked as /bholzer:<name> and the install target is bholzer@bholzer.
From this checkout:
# Add the marketplace (one-time)
claude
> /plugin marketplace add /Users/brennanholzer/projects/personal/claude-bholzer
# Install the plugin (user scope is the default — available across all projects)
> /plugin install bholzer@bholzer
After installation the marketplace is tracked in ~/.claude/plugins/known_marketplaces.json and the plugin is added to enabledPlugins in ~/.claude/settings.json. Pull new commits and run /plugin update bholzer@bholzer to refresh.
For fast iteration without installing, use --plugin-dir:
claude --plugin-dir ./plugins/bholzer
Run /reload-plugins after edits to pick up changes without restarting.
Validate the plugin and marketplace manifests before committing:
claude plugin validate ./plugins/bholzer
| Type | Where | Invocation |
|---|---|---|
| Skill | plugins/bholzer/skills/<name>/SKILL.md | /bholzer:<name> |
| Slash cmd | plugins/bholzer/commands/<name>.md | /bholzer:<name> |
| Agent | plugins/bholzer/agents/<name>.md | auto / /agents |
skills/ and commands/ both produce /bholzer:<name> invocations — use skills/ when you need supporting files (scripts, references) alongside the prompt, commands/ for one-off flat files.
Each .md needs YAML frontmatter. Minimum required: description (skills/commands) or name + description (agents). See the example files in each directory for templates.
No version field is set in plugin.json or marketplace.json, so the git commit SHA is the version — every commit counts as a new release. Set an explicit version in plugin.json if you want to gate updates on a manual bump.
npx claudepluginhub bholzer/claude-bholzer --plugin bholzerA plugin for autonomously building over long sessions.
Claude harness - A harness for solo developers (Vibecoders) to handle full-cycle contract development.
Harness-native ECC operator layer - 67 agents, 271 skills, 92 legacy command shims, reusable hooks, rules, selective install profiles, and production-ready workflows for Claude Code, Codex, OpenCode, Cursor, and related agent harnesses
v9.44.1 — Patch release for Gemini environment/version detection and qwen auth gating. Run /octo:setup.
AI-powered development tools for code review, research, design, and workflow automation.
Superpowers Plus core skills library for Claude Code: planning, execution routing, TDD, debugging, and collaboration workflows
Unity Development Toolkit - Expert agents for scripting/refactoring/optimization, script templates, and Agent Skills for Unity C# development