symbiopowers

Use for reviewing code changes before merge — diffs, PRs, or staged commits. Covers plan alignment, code quality, architecture, and test coverage. Examples: <example>Context: Developer opens a PR implementing a new API endpoint. user: "Review this PR" assistant: Structured review with findings by severity, checking implementation against the stated plan and project conventions. <commentary>Catches issues before they reach main.</commentary></example> <example>Context: Feature branch with 12 changed files. user: "Is this ready to merge?" assistant: Evaluates test coverage gaps, identifies a missing error handler, and confirms architecture alignment. <commentary>Comprehensive pre-merge quality gate.</commentary></example>

Dispatched after every code change to check whether docs/ needs updating. The check always runs; updates happen only when warranted. Examples: <example>Context: Developer adds a new REST endpoint for user invitations. user: "Done with the endpoint" assistant: Context-keeper detects new route, updates docs/conventions/api-design.md and docs/domain/glossary.md with "invitation" term. <commentary>Keeps docs in sync without manual effort.</commentary></example> <example>Context: New Postgres migration adds a tenants table. user: "Migration applied" assistant: Context-keeper updates docs/architecture/data-model.md with tenant entity and proposes ADR for multi-tenancy. <commentary>Catches structural changes that affect multiple doc areas.</commentary></example>

Dispatched before responding to a non-trivial user prompt or at the start of a reasoning-heavy skill. Walks docs/ MOC relevance-filtered against the prompt and returns a concise context pack so the main agent reasons with real project context instead of only the root index. Examples: <example>Context: User invokes /brainstorming mid-session to discuss caching. user: "/brainstorming add Redis caching" assistant: Dispatches context-loader with the prompt. Receives a pack referencing docs/architecture/components.md and docs/conventions/performance.md. Uses both in the clarifying questions. <commentary>Skill-layer invocation gets deep context, not just root index.</commentary></example> <example>Context: First prompt of a session, user asks to fix an auth bug. user: "login is broken on staging" assistant: Hook checklist dispatches context-loader. Pack returns runbooks/incident-response.md and architecture/auth.md excerpts. <commentary>Hook-layer baseline fires on first prompt of a session.</commentary></example>

Use when a PRD/spec/design doc is written and must be challenged before planning or coding — find contradictions, hidden assumptions, and planning-breaking gaps. Examples: <example>Context: Spec for new API is saved. user: "Review the spec before we plan" assistant: I'll use adversarial-document-reviewer to stress-test assumptions and edge cases; blockers return the flow to brainstorming. <commentary>Gate before implementation planning.</commentary></example> <example>Context: Two sections of the spec disagree on auth model. user: "Is this ready?" assistant: Verdict fail — blocker on conflicting auth assumptions with section references. <commentary>Internal consistency is a blocking issue.</commentary></example>

Use when an implementation plan exists and must be checked against real repo constraints — dependencies, CI, migrations, test harness, and "can a human/agent execute this without getting stuck?". Examples: <example>Context: Plan assumes pnpm but repo uses npm. user: "Review the plan" assistant: Feasibility reviewer flags plan step using wrong package manager with blocker. <commentary>Reality mismatch blocks until plan updated.</commentary></example> <example>Context: Plan touches 20 files but no test command documented. user: "Is this buildable?" assistant: Important risk — verification steps missing; required_plan_changes lists concrete additions. <commentary>Buildability is core to feasibility.</commentary></example>

Use when a user brings a new feature, design question, or architectural decision that needs exploration before code. Guides Socratic discovery of requirements, proposes multiple approaches, and produces an approved spec under docs/ before any implementation begins.

Use after shipping a meaningful chunk of work, before merge, or when closing a major session to capture lessons in docs/solutions and propose manifest or rules updates as human-reviewed diffs only.

Use when diagnosing bugs, unexpected behavior, or production issues. Enforces a two-phase approach: first understand the problem completely, then and only then propose a fix that addresses the root cause.

Use when work decomposes into three or more independent problem domains that can execute simultaneously. Each agent receives isolated context, while a coordinator preserves overall orchestration context and integrates results.

Use to execute an implementation plan task by task in a single session. Follow the plan produced by writing-plans, mark progress as you go, and transition to finishing-a-development-branch when all tasks are complete.