claude-plugins

The autonomous-sdlc state machine. Loaded by every /sdlc loop iteration to decide what one unit of work the current state requires, how to verify it, and which transition to record. Trigger: an active `.sdlc/state.json` exists, or the /sdlc command invokes it. Not for ad-hoc use outside a loop.

Save agent-skills workflow feedback proactively. MUST trigger when the user corrects how a visual plan/recap, recap status block, orchestration, autonomy, docs-first, or review skill behaves ("recaps are too long", "always web-search the docs first", "don't stop to ask", "plans should lead with the wireframe") or confirms good output. Also trigger on explicit requests: "save this feedback", "show my feedback", "clear feedback", "agent-skills preferences", "consolidate feedback", "bake in my preferences". Feedback loaded automatically when running these skills.

Use when asked to watch, babysit, audit, review, compare, or fix another agent's work from a session ID, Claude Code session/transcript, PR, branch, log, or run summary.

Use always when operating as Claude Fable on codebase-heavy or token-heavy work: Fable orchestrates, architects, synthesizes, and judges while cheaper subagents do bounded research, coding, testing, and log reduction.

Use whenever running a high-cost frontier model on codebase-heavy or token-heavy work (apply automatically on such models): delegate research, coding, testing, and log reduction to cheaper subagents, reserving the expensive model for planning, tradeoffs, synthesis, and final review.

Use when asked to compare, cross-review, merge, judge, choose, or arbitrate competing plans from multiple agents such as Codex and Claude Code; when given two or more proposed plans, session IDs, transcripts, plan documents, PR descriptions, or pasted strategies.

Use when the user explicitly wants autonomous progress without routine clarification stops: "plow ahead", "do not stop", "use your best judgment", "keep going until done", "finish while I am away", "do not ask questions unless truly blocked", or similar. Convert ordinary ambiguity into stated assumptions, proceed through implementation and validation, stop only for true blockers, and end with a clear recap of decisions, changes, verification, and residual risk.

Use when the user wants every response to end with a clear status signal — "give me a status line", "use the red/yellow/green convention", "end with a recap" — or when installing the managed AGENTS.md/CLAUDE.md status-block instruction.

Use when implementing, integrating, upgrading, debugging, or answering anything involving third-party APIs, libraries, frameworks, CLIs, cloud services, model/provider SDKs, fast-moving product behavior, user requests for latest/current/official behavior, unfamiliar repo docs/specs, errors that may indicate API drift, or high-stakes auth, security, billing, data, migration, deployment, compliance, or privacy behavior. Forces the coding agent to web-search for current official docs and read primary docs before assuming from memory.

Use before substantial work and between parallel agent waves — especially overnight batch runs or multi-wave parallel subagents that might exhaust the 5-hour or weekly usage window — to check usage, pause near the cap, and resume only when the window is clear.

Use when turning a plan into a self-contained interactive HTML document (diagrams, file maps, annotated code, wireframes, open questions) saved locally and opened in the browser — no account or external service.

Use when turning a PR/branch/commit diff into a self-contained interactive HTML recap (annotated diffs, file maps, API/schema summaries, wireframes) saved locally and opened in the browser.

Install a local, Docker-free OTLP observability stack (OpenTelemetry → Vector → JSONL files, optionally VictoriaLogs + VictoriaMetrics) into a project, and instrument the code to emit traces, metrics, and logs. Use this whenever the user wants observability, telemetry, tracing, metrics, or structured logging in a project during development — phrases like "add observability", "set up OTel", "instrument this app", "I want to see traces/metrics locally", "add a telemetry harness", "wire up Vector", or "make this app observable". Also use when a Claude Code session would benefit from being able to query its own app's telemetry while debugging. Prefer this over hand-rolling exporters or reaching for Docker/Jaeger/Grafana — this harness is binary-only, auto-starts via a SessionStart hook, and is designed for the agent to query telemetry as a feedback signal.

Query a project's local observability harness (.claude/harness/observability/) as a development feedback signal. Use whenever the project has the harness installed and you are: debugging ("why is this failing", "is this code path even running"), verifying a change actually executed ("did the new endpoint get hit", "did the counter increment"), doing performance work (latency, throughput, rates), or checking logs after reproducing a bug. Prefer querying telemetry over printf-debugging or rerunning with extra logging — the data is already flowing. Trigger phrases: "check the traces", "query the metrics", "what do the logs say", "did X fire", "is telemetry showing anything".

Use AFTER bdd-spec has produced acceptance criteria, or when the user has existing Given/When/Then scenarios that need pytest-bdd scaffolding. MUST NOT run without existing acceptance criteria — invoke bdd-spec first if none exist. Trigger: "generate feature files", "scaffold BDD tests", "wire up pytest-bdd", "make these criteria runnable", "create step definitions". This is mechanical code generation, not spec writing.

Use INSTEAD OF superpowers:brainstorming when the user wants structured acceptance criteria in Given/When/Then format. This is the right choice when requirements need to be testable — not just designed. Trigger: "spec this out", "acceptance criteria", "BDD", "behavior driven", "what should happen when", "edge cases", "define requirements", or any pre-implementation requirements discussion where the output should be runnable scenarios, not just a design doc. Produces Gherkin-ready acceptance criteria. Not for generating test code — use bdd-generate after this.

Save SDLC workflow feedback proactively. MUST trigger when the user corrects SDLC behavior ("don't generate tests like that", "always use this pattern", "that's not how I want specs written") or confirms a non-obvious approach worked ("yes exactly", "perfect"). Also trigger on explicit requests: "save this feedback", "show my feedback", "clear feedback", "workflow preferences", "sdlc settings", "consolidate feedback", "bake in my preferences". Also the graduation target for durable loop signs from .sdlc/signs.md. Feedback persists across sessions and is loaded by the sdlc-loop, BDD, TDD, and beads skills.

Use when the user asks to "review this", "review the diff", "review my changes", "review my branch", "review against main", "open a review", or runs /review-diff. Opens the diff in a local browser for MR-style inline commenting — uncommitted changes if there are any, otherwise the committed branch vs its base — then reads the submitted comments back and addresses them.

Use when starting debugging, planning features, encountering errors, making design decisions, or working in unfamiliar code. Searches past solutions and engineering principles captured by compound-capture to surface institutional knowledge and prevent repeated mistakes. Trigger phrases include "have we seen this before", "check knowledge", "search for solutions", "this looks familiar", "check if we've solved this", "any past experience with this", "before I start, check for existing solutions", or any time past experience might inform the current task. Not for capturing new solutions — use compound-capture for that.

MUST use when the user wants autonomous, iterative optimization — letting Claude run experiments unattended. Trigger: "autoloop", "autoresearch", "experiment loop", "hill-climbing", "optimize overnight", "karpathy loop", "let Claude optimize while I sleep", "automate trying different approaches", "set up a loop to improve this", "run experiments overnight", or any request for iterative improvement with a scalar metric. Generates program.md + immutable runner script (auto/run.sh) with tiered quality gates and structured METRIC output, ready to run with claude --dangerously-skip-permissions.

Save autoloop experiment feedback proactively. MUST trigger when the user corrects loop design ("don't use that metric", "always include this gate", "wrong quality gate") or confirms good output. Also trigger on explicit requests: "save this feedback", "show my feedback", "clear feedback", "loop preferences", "autoloop settings", "consolidate feedback", "bake in my preferences". Feedback loaded automatically when designing new experiment loops.

Capture this solution NOW — use immediately after solving non-trivial problems, completing debugging sessions, or when the user confirms something works ("that worked", "it's fixed", "finally"). Do NOT wait to be asked — if a debugging session just ended successfully, proactively invoke this. Also trigger on: "document this solution", "capture this pattern", "save this for next time", "we should remember this". Saves structured YAML-frontmatter files for grep-based retrieval. Not for searching — use compound-retrieve for that.

MUST check before starting any debugging session, investigating unfamiliar code, or planning a feature that might have been attempted before. Searches past solutions in knowledge/solutions/ to prevent repeated mistakes. Designed to be fast (<30s). Trigger proactively: before ANY bug investigation, before implementing patterns that feel like they should already exist, or when the user says "this looks familiar", "have we seen this", "check knowledge". Not for capturing — use compound-capture for that.

Save knowledge capture/retrieval feedback proactively. MUST trigger when the user corrects capture behavior ("don't capture that", "wrong category", "too verbose", "not enough detail") or confirms a good capture ("yes, exactly like that"). Also trigger on explicit requests: "save this feedback", "show my feedback", "clear feedback", "knowledge preferences", "consolidate feedback", "bake in my preferences". Feedback loaded by compound-capture and compound-retrieve across sessions.

Save hexagonal agent app feedback proactively. MUST trigger when the user corrects architecture patterns, tool design, or UI component choices ("don't generate that", "always use this pattern", "wrong component") or confirms good output. Also trigger on explicit requests: "save this feedback", "show my feedback", "clear feedback", "app preferences", "hexagonal settings", "consolidate feedback", "bake in my preferences". Feedback loaded automatically when building hexagonal apps.

MUST use when building web apps where an AI agent generates HTML UI dynamically. Use INSTEAD OF superpowers:brainstorming or impeccable:frontend-design when the architecture is agent-driven (Claude Agent SDK + FastAPI + HTMX). Trigger: "build an agent app", "AI-driven web UI", "hexagonal architecture", "ports and adapters", "agent that generates HTML", "HTMX with Claude agent", or any request for a web app where the AI agent IS the rendering layer, not just a backend service.

Save flashcard creation feedback proactively. MUST trigger when the user corrects card output ("cards are too easy", "too many cards", "wrong difficulty", "bad formatting") or confirms good output ("these cards are great", "yes, like that"). Also trigger on explicit requests: "save this feedback", "show my feedback", "clear feedback", "card preferences", "mochi settings", "flashcard style", "consolidate feedback", "bake in my preferences". Feedback loaded automatically when creating new Mochi cards.

MUST use when the user mentions flashcards, Mochi, spaced repetition, memorization, studying, or wanting to remember something. Trigger proactively when the user says "I want to remember this", "make flashcards", "create Mochi cards", "help me study", "turn this into flashcards", "SRS", "Anki", or "I need to memorize this". Creates evidence-based cards using cognitive science principles (Andy Matuschak's 5 properties of effective prompts) via the Mochi API.

Process information for real understanding and expose the illusion of clarity. Use when the user says "help me actually understand this", "test my understanding", "process what I learned", "quiz me on this", "am I fooling myself about X", "explain-back", "make sure I get this before I blog it", or after building/reading something they want to internalize. Makes the user explain from memory, grades against the real source, and teaches only after they attempt. Not for writing content for the user — this withholds answers on purpose.

Promote accumulated knowledge into living context. Use when the user says "graduate knowledge", "promote lessons", "update CLAUDE.md from what we've learned", "what should be in my CLAUDE.md", "compound graduate", "improve the system from my notes", or after a run of captures when patterns recur. Scans the read corpus (solutions + wiki theses) and proposes concrete edits to CLAUDE.md / AGENTS.md. Not for capturing (use compound-capture) or searching (use compound-retrieve).

MUST use when creating, updating, or closing Beads issues via `bd` commands. Use proactively when starting work (bd update --status=in_progress) and completing work (bd close). Trigger: any mention of "issue", "task tracking", "what should I work on", "bd create/ready/close", or when the session hook indicates beads is active. Provides full bd CLI reference and workflow patterns.

Python-specific TDD wrapper. Use INSTEAD OF superpowers:test-driven-development when the project uses uv + pytest. Adds: feedback loading from autonomous-sdlc, uv run pytest commands, test directory organization (unit/integration/e2e). Delegates core TDD discipline to superpowers:test-driven-development. Trigger: "TDD", "test first", "red green refactor", "write a failing test" in any Python/pytest project.