mcp-cli

Sprint lifecycle: plan, run, review, retro. The top-level orchestrator for autonomous issue resolution. Use for "run a sprint", "plan the sprint", "sprint review", "sprint retro", "/sprint", "/sprint plan", "/sprint review", "/sprint retro", or any variant.

Step back and interrogate the frame instead of executing it. `/why <subject>` GENERATES the sharp questions that should have been asked about a request, plan, artifact, or your own intended action — it does NOT answer them. Use when handed an assignment that smells mis-scoped, when about to loosen a constraint to silence a signal (bump a timeout, widen a threshold, disable a check, narrow scope to the measurable half), when triaging borderline/unfiltered backlog issues, or when a user is frustrated that the obvious framing is wrong. Triggers: /why, /why nsfw.

Build an autonomous sprint skill for a target project. Explores the project's workflows, constraints, and tooling, then produces a tailored sprint skill that lets Claude orchestrate parallel implementation sessions end-to-end. Use when setting up auto-sprint in a new repo, or when adapting sprint orchestration to a project with different workflows. Trigger on "bootstrap sprint", "set up auto-sprint", "build sprint skill for <project>", or "make <project> sprintable".

Audit and garbage-collect a committed Claude-memory store (MEMORY.md + per-fact files). Evidence-based, parallel, then a gated apply. Use when MEMORY.md has grown large, after several sprints, when memory has drifted from CLAUDE.md, or when the user says "/memory-gc", "clean up memory", "audit memory", "the memory is huge", or notices memory diffs/orphans.

Extract actionable lessons from sprint history. Buckets every Claude Code session into the sprint it ran in, builds a deterministic per-session digest (tokens, duration, errors, orchestration signals, evidence), then runs a multi-agent Workflow that classifies each session (orchestrator vs worker), scans for tool errors / autoclassifier rejections / user interventions, summarizes it, aggregates per-sprint, per-10-sprint window, and over time — ending in ranked, concrete actions. Use for "extract sprint lessons", "what can we learn from sprint history", "/sprint-lessons", or a retro deep-dive.

Author, refine, or migrate a doing-it-wrong architectural rule, and harvest recurring mistakes from merged PRs. Routes on its argument — `harvest` (mine PR review comments for recurring author mistakes), `init` (bootstrap the rule engine into a repo), `add` (author a rule), or no arg (overview + "is this a good rule?" triage). Use when the user wants to "write a rule", "add a lint rule", "should we lint for this", "make a rule for X", "migrate a check-*.ts into the rule engine", "harvest rules", "what should we lint for", "reduce review churn", "mine PR comments for rules", or judging whether a proposed invariant is worth a rule.

Post-implementation triage: measure actual diff metrics to determine review depth. Run after implement, before review. Usage: /estimate (in a worktree with changes)

Create a versioned release from the current state of main. Reads the latest diary entry or sprint summary, generates release notes, determines the semver bump, tags, and pushes. Use when the user says "cut a release", "ship it", "/release", "tag a version", or at natural sprint boundaries.

Backfill diary entries from Claude Code session transcripts. Extracts insights, learnings, and patterns from past sessions and writes structured diary entries to .claude/diary/. Use when the user says "write diary", "backfill diary", "/diary", "what did we do today", or wants to capture session learnings. Also use proactively at the end of long productive sessions when significant work was completed.

Mine flaky test failures from Claude Code session transcripts. Scans JSONL session files for test failure patterns in tool results, aggregates by test file and name, and reports which tests fail across multiple sessions. Use when investigating test reliability, after a sprint to check for new flaky tests, or when the user says "flaky tests", "which tests are flaky", "test stability report", or "/flaky-tests".

Review recent PRs in a feature area for architectural consistency, missed integration points, duplicated patterns, and wrong directions. File issues for problems found. Use after 3-4 related issues merge or when a session's cost exceeds $15.

Analyze open GitHub issues, group them into thematic arcs, and write a sprint file for orchestrator context. Use when deciding what to work on next, assessing board health, or updating strategic context.