ai-plugins

This skill should be used when an orchestrator needs to choose or resolve a model for a delegated agent — i.e. by /bee:planner when authoring a plan (assigning a capability tier per agent per slice) and by /bee:plan-implementer when executing one (resolving a tier to a concrete subagent model value). Contains the single source of truth mapping capability tiers (best / excellent / fast) to Claude Code subagent model values, with per-tier guidance for picking the right one. Load this skill instead of hardcoding any model name.

Engine for the /ccaf:practice command. Asks which specific CCAF domains to focus on and how many questions (10/20/30), assembles a proportionally-weighted partial exam anchored to the reference bank and independently verified, administers it 4 questions per screen with resumable progress, and scores it with a per-domain performance chart. Attempt state lives in ~/.claude/ccaf-practice.local.md — separate from /ccaf:mock-exam. Use when running or resuming /ccaf:practice.

Engine for the /ccaf:mock-exam mock exam. Assembles a 60-question CCAF mock (all questions generated fresh per attempt, anchored to a self-authored reference bank and independently verified), administers it 4 questions per screen with resumable progress, and scores it on the real 100–1000 band with a 720 pass line. Use when running or resuming /ccaf:mock-exam.

Engine for the /ccaf:prepare conversational tutor. Teaches the Claude Certified Architect – Foundations (CCAF) syllabus turn by turn — one concept at a time, with a knowledge check every turn — adapting pace and difficulty to the learner. Opens with a multi-select topic menu over the blueprint's 5 domains and 30 task statements; the learner picks what to learn. Spawns the ccaf-check-author agent for scenario checks; hands off to /ccaf:mock-exam when a domain looks solid. Use when running /ccaf:prepare.

Generates a full incident postmortem markdown document from a cached timeline (built by incident-timeline-builder) and the source materials gathered during investigation. Uses a Google-SRE-style blameless template by default. Produces the postmortem as plain markdown text for the caller to render or save; the skill itself never writes to disk or posts anywhere. Use when the incident-postmortem agent reaches Phase 4, or when a user has a structured timeline and wants the full document.

Restructures a poorly written tracker issue into a clear, self-contained document a stranger can open cold and act on. Works on any archetype (Bug, Incident, Story, Feature, Task, Spike) and any supported tracker (Azure DevOps, Jira). Returns the refined title and markdown body; the caller owns the write (issuekit:tracker-adapter projects markdown to the vendor's format).

Investigates a non-bug issue (Story, Feature, Task, Spike) on any supported tracker (Azure DevOps, Jira) by reading the issue and linked design or product docs, searching chat (Slack/Teams) and docs (Confluence/Wiki) for prior decisions, and producing an evidence-tagged orientation report. Use when a developer is about to pick up a Story, Feature, Task, or Spike and wants context before starting work. For Bug/Incident, use issuekit:issue-investigator instead.

Investigates a Bug or Incident on any supported tracker (Azure DevOps, Jira) by searching chat (Slack/Teams), the issue and related issues, docs (Confluence/Wiki), Datadog, and the codebase, then writes an evidence-tagged report in the bug-archetype template. Use when a Bug or Incident needs an investigation report before triage decisions are made. For Feature, User Story, Task, or Spike, use `requirements-investigator` (lives in the issue-triage plugin).

Rewrites or audits prose to eliminate AI writing patterns and produce natural human writing. Use when the user says "AI slop", "sounds generated", "too formal", "write like a human", "fix the writing", "rewrite this", "clean up the prose", or asks for writing style guidance. Also apply proactively when generating documentation, chat messages (Slack/Teams), postmortems, Confluence pages, wiki pages, tracker work-item or ticket text, or any long-form prose output.

Auto-detects the active issue-tracker MCP and exposes an abstract verb surface that works across Azure DevOps and Jira. Routes reads (getIssue, searchIssues, ...) and writes (addComment, transition, updateFields, ...) through the vendor adapter resolved at session start. Loads policy from .claude/tracker-policy.json with lazy-prompt fallback. Owns the diff-and-confirm gate that every write batch must pass.

Reconstructs a chronological event timeline for an incident from gathered evidence: chat thread snippets, tracker state changes and related-issue history, Datadog log entries, and merged pull requests. Each timeline entry carries a UTC timestamp, a one-sentence description, a source citation, and an evidence tag. Use when the incident-postmortem agent reaches Phase 2, or when a developer wants to manually reconstruct what happened during an incident from a known set of source materials.

Runs end-to-end product discovery and produces a structured PRD. Use when the user asks to "start product discovery", "build a PRD", "PM this for me", "validate this idea", or "shape this product".

Interview the user about a plan or design with full codebase context. Use when the user wants to stress-test their thinking against the actual codebase, says 'grill me with context', 'challenge this against the code', 'does this plan fit our architecture', or presents a plan for a specific codebase and wants it pressure-tested against what actually exists. Differs from plain grill-me by grounding every question in the project's real architecture, patterns, and constraints.

This skill should be used when the user wants to brainstorm, explore ideas, think through options, says 'let's brainstorm', 'what are our options', 'how might we', 'what if we', 'help me think through', 'explore approaches', or presents an open-ended problem without a clear solution. Covers cross-domain thinking where changing one dimension (product, tech, UX) can simplify another.

Interview the user relentlessly about a plan, design, or idea until reaching shared understanding. Use when the user wants to stress-test their thinking, asks to be grilled, says 'poke holes in this', 'challenge my design', 'what am I missing', or presents a plan and wants it pressure-tested before committing to it.

This skill should be used when resolving git merge conflicts. Parses conflict markers, shows clean side-by-side diffs, explains why each conflict occurred using git history, and presents resolution options via AskUserQuestion with reasoning for the recommended choice. Use this skill whenever the user mentions merge conflicts, says 'resolve conflicts', 'fix conflicts', or when git status shows unmerged paths.

This skill should be used when running browser-based verification. Supports two providers: Claude-in-Chrome (primary) and chrome-devtools-mcp (fallback). Contains tool reference, dev server detection, screenshot conventions, and graceful degradation.

This skill should be used when making UI/UX decisions, designing layouts, choosing colors and typography, writing UI specs, or reviewing visual components. Contains the two-path design flow (existing system vs greenfield discovery), accessibility rules, typography pairing, color palette guidance using Sanzo Wada's Dictionary of Color Combinations, spatial composition, anti-generic rules, and visual quality checklist.

Rewrites software requirements to lead to better code design and architecture. Use this skill whenever a user shares requirements, user stories, feature specs, acceptance criteria, or PRDs and wants them improved before development begins. Also trigger when a user says 'review my requirements', 'improve this spec', 'make this requirement better', 'rewrite this for better design', 'architecture-aware requirements', or asks how to write requirements that produce cleaner code. Trigger even when users paste requirements without explicitly asking for review — if the requirements contain design-limiting patterns (conditional chains, implementation details, ambiguous boundaries), proactively suggest improvements.

This skill should be used when processing @bee annotations in documents or managing [ ] Reviewed gates. Contains the exact comment card format and review loop rules. Load before handling any @bee comment.

This skill should be used when updating workflow state in bee-state.local.md. Contains the full command reference for update-bee-state.sh including init, set, get, clear, all flags, and multi-line field syntax.

This skill should be used after discovery completes on a greenfield project when the discovery document contains a Module Structure section. Contains the full procedure for parsing module boundaries, generating BOUNDARIES.md, and optionally linking it from CLAUDE.md.

This skill should be used when writing specs, acceptance criteria, or slicing features into vertical slices. Contains adaptive depth by risk and out-of-scope capture.

This skill should be used after all slices are verified and before review. Contains templates for generating contextual 'Try it yourself' manual verification steps based on what was built (frontend, backend, CLI, greenfield, library).

This skill should be used when writing, reviewing, or refactoring code. Contains SRP, DRY, YAGNI, naming, error handling, dependency direction, and Kent Beck's four rules of simple design.

This skill should be used when guiding a learner through building a project, explaining code, creating curriculum steps, adapting to skill levels, or producing code examples for learners. It should be loaded when the user asks to "learn", "teach me", "walk me through", "explain this code", "build a project to learn", or when generating any instructional code content.

This skill should be used when evaluating how well code supports LLM-assisted development. Contains context window friendliness, explicitness, module boundaries, test-as-spec, and naming criteria.

This skill should be used when explaining why Bee follows spec-first TDD workflows, or when teaching mode is on. Contains the reasoning behind spec → plan → test → code ordering.

This skill should be used when evaluating architecture options, checking dependency direction, or deciding between onion, MVC, and simple patterns. Contains YAGNI-based decision criteria.

This skill should be used when performing code reviews, analyzing git hotspots, or detecting coupling. Contains Adam Tornhill's code-as-crime-scene methodology and effort sizing.

This skill should be used when diagnosing failures, fixing bugs, or investigating why tests don't pass. Contains systematic debugging: reproduce first, read before you change, assume nothing, find root cause.

This skill should be used when performing precise dependency analysis with LSP tools. Contains availability checking, graph reasoning, and graceful degradation.

This skill should be used when writing a TDD plan, reviewing test quality, choosing between unit and integration tests, or applying red-green-refactor. Contains outside-in double-loop, test isolation, and test naming.