Lightweight bug-fixing loop — reproduce → root-cause → fix test-first → verify — deliberately separate from the heavyweight feature workflow so small fixes don't drag a spec-and-plan process behind them. Demands a deterministic reproduction before any code changes, a stated root-cause hypothesis confirmed with evidence (never a shotgun fix), a failing test that captures the bug, and the original repro re-run as proof. Keeps a one-line-per-bug log in out/dev/bugfix-log.md and checks it first, so recurring bugs get recognized instead of re-diagnosed. Use when the user reports something broken, failing, throwing, or flaky, or asks to fix a bug — e.g. "/bugfix login 500s on empty password", "fix this error", "this test is flaky", "why is X crashing". If the fix turns out to need real design work, hand off to feature; the shipping gate is done.
Morning work briefing — "what does my day look like, in one scan?" Gathers today's calendar and emails needing attention (via connected Google MCP tools when available), recent git activity and unfinished work across your local repos, your open tasks (TODO file / assigned GitHub issues), and a quick radar check on topics you track — all in parallel — and renders one compact, prioritized brief in chat, carrying over unfinished focus items from yesterday's saved brief. Every source is optional and degrades gracefully; strictly read-only (never sends email, never touches the calendar, never pushes). Use at the start of a workday or when the user asks "what's on today", "morning brief", "daybrief", "catch me up", "what should I focus on today". For deep research on one topic use pulse instead.
Community-pulse research on any topic — "what are people saying about X right now." Fans out parallel sub-agents across web search, Hacker News, Reddit, and GitHub; ranks findings by real engagement (points/upvotes/stars/comments); flags rumors; and writes a cited brief to chat plus saved .md and .html files. Use when the user wants the current community conversation / recent buzz / sentiment / "last 30 days" view on a person, product, project, or concept — e.g. "/pulse <topic>", "what's the buzz on X", "what are people saying about X lately", "research recent discussion on X". For exhaustive, adversarially fact-checked web reports, prefer the deep-research skill instead.
Competitive reconnaissance for your project — what do the repos solving this same problem do better, and what's worth adopting? Finds peer repos (ranked by activity, downloads, dependents — never raw stars), mines what their users beg for — issue reactions, releases, docs claims, every finding with a locator — and verdicts each candidate feature ADOPT/ADAPT/SKIP/WATCH, where SKIP is the default and "a competitor has it" is never a reason. ADOPT items become ready seeds for feature or autopilot; verdicts persist in out/scout/tracker.md so repeat runs open with what changed. Keyless. Use for "what are similar projects doing", "compare us to X", "what are we missing" — e.g. "/scout", "/scout <owner/repo>", "/scout deep <repo>". For X-vs-Y tech choices use verdict; for community buzz use pulse.
Architect-grade technology decision briefs — "which option should we pick, and why?" Takes a decision question (X vs Y vs Z for a stated context: library, database, framework, platform, buy-vs-build) plus your constraints, fans out parallel sub-agents to research each option's project health, community sentiment, technical claims, and operational story, then scores options across weighted criteria and emits an ADR-style recommendation with a full scorecard and cited evidence. Keyless; the recommendation is advisory — you decide. Use when the user must choose between technologies or approaches — e.g. "/verdict postgres vs mongodb for <use case>", "should we use Kafka or NATS", "compare X and Y", "buy vs build", "which framework for this". Also supports "/verdict revisit <brief>" to cheaply re-check a past verdict's revisit-when triggers. For community buzz on a single topic use pulse; for exhaustive fact-checked research use deep-research.
Human-facing documentation, architecture docs, and mermaid diagrams for a codebase, a module, or a feature — "draw me the architecture, with receipts." Fans out read-only sub-agents to build a grounded component graph first: every node is a real path, every edge backed by a grep-verified import or call — unverifiable edges are dropped, not drawn. Diagrams render from that verified table per a fixed checklist (never freehand mermaid), capped at 5–8 top-level components with drill-down pages; every doc section cites its sources as file:line. Drafts in chat, writes docs/blueprint/ only on your yes, and stamps a manifest with date + commit so /blueprint refresh regenerates only what the diff touched. Use for "generate an architecture diagram", "document this codebase or module for people", "create a mermaid diagram of this feature" — e.g. "/blueprint", "/blueprint the payment flow", "/blueprint refresh". For agent-facing orientation (AGENTS.md) use map; blueprint is the human-facing sibling.
Codebase orientation for an unfamiliar or large repo — "map this before I work in it." Fans out read-only Explore sub-agents that navigate the code (keyless — grep/glob/read, no embeddings to go stale) along the order that matters: entry points, build/test/lint commands, architecture and key abstractions, conventions and gotchas, test layout. Distills the findings into a lean AGENTS.md at the repo root — the cross-tool standard file many agents auto-load — where every claim points to a real file and nothing survives that isn't load-bearing. Human-in-the-loop: it drafts, you approve, and it never writes or commits into your repo without an explicit yes. Stamps the map with date + commit so /map refresh regenerates only what went stale. Use before working in a repo you or the agent don't know — e.g. "/map", "/map the auth subsystem", "generate an AGENTS.md", "/map refresh". Run it upstream of feature or bugfix; for the end-of-session shipping gate use done.
The whole coding loop on one deliberate yes: map, spec, critic-hardened plan, GitHub issues, parallel worktree implementers, fresh-context review loops, one PR with the evidence. Acts only on its itemized charter; parks what it can't settle honestly. Commands: /autopilot <task> [--merge], resume, status. It signs a charter and pushes branches, so it never auto-triggers — explicit invocation only.