Agent Building skills
Browse reusable Agent Skills, each with a clear purpose and practical guidance.
prompt-caching
Cache the parts of the prompt that don't change so a long-running loop stops paying full price on every turn. Use when the system prompt, tool defs, or reference docs are stable across many turns.
self-eval-bias
Detect and interrupt the pattern where an agent confidently praises work it just produced instead of reviewing it critically. Same-context grading is not review — it's rationalization.
spec-first
Write the goal spec on disk before the agent acts, so it can't drift. Use before any multi-step task.
structured-output
Get JSON out of the model reliably. Prefer tool_use with a schema over prompted-JSON, validate on receive, retry on parse fail. Use when downstream code will parse the response.
subagent-fanout
Parallelize independent sub-jobs across fresh-context subagents instead of one bloated context. Use when a goal branches into many independent pieces.
tool-restraint
Don't over-equip an agent with tools/MCP servers. More tools = more ways to fail and a higher cognitive load. Use when wiring tools or an agent underperforms.
llm-friendly-context
Clarifies inputs, outputs, success criteria, decisions, and unresolved conditions so downstream agents can execute without guessing. Use when writing or revising LLM-facing prompts, handoffs, planning artifacts, reviews, reports, or generated instructions.
subagents-orchestration-guide
Guides subagent coordination through implementation workflows. Use when orchestrating multiple agents, managing workflow phases, or determining autonomous execution mode.
capabilities-manager
Manage capa CLI configuration — `capabilities.yaml` / `capabilities.json`, skills, MCP servers, tools, hooks, sub-agents, rules, plugins, AGENTS.md / CLAUDE.md, security options, and tool exposure modes. Use whenever the user edits the capabilities file, runs any `capa` command (init, install, add, clean, sh, start/stop/restart/status, auth, upgrade, cache, registry), wires up an MCP server, adds a skill from GitHub / GitLab / a registry / a remote URL / a local path, configures secrets via `${VarName}` placeholders, installs lifecycle hooks, defines sub-agents, or troubleshoots a failed install. Use even when the user only names a fragment ("add a skill", "wire up brave search", "block this phrase in skills") without saying "capa" — if a `capabilities.yaml` or `capabilities.json` lives at the project root, this is almost certainly the right skill. If the project does NOT yet have a capabilities file, point at the `bootstrap` skill instead.