bootstrap-workflow

PROACTIVE design reviewer for significant features. MUST BE USED for new database tables, API routes, dependencies, config changes, or changes affecting >3 files. Use BEFORE code is written. Examples: - "Add user notifications" → architecture-advisor (new table + API) - "Integrate Stripe payments" → architecture-advisor (external service) - "Add OAuth login" → architecture-advisor (auth flow change) - "Refactor the data layer" → architecture-advisor (multi-file change)

Expert code review specialist. Reviews code for quality, security, and maintainability. Use PROACTIVELY after writing or modifying code. Examples: - "Review my changes" → code-review-specialist - "Is this code ready to commit?" → code-review-specialist - "Check this implementation" → code-review-specialist - "Review before I push" → code-review-specialist

MUST BE USED for product-engineering translation, scope negotiations, and requirement definition. ALWAYS invoke for feature prioritization, MVP scoping, and acceptance criteria. Use PROACTIVELY as the bridge between user needs and technical implementation. Examples: - "What should the MVP include?" → cpo-advisor - "How do we prioritize these features?" → cpo-advisor - "Define acceptance criteria for X" → cpo-advisor - "Is this scope reasonable?" → cpo-advisor - "What's the user story for this?" → cpo-advisor - "Should we cut scope or extend timeline?" → cpo-advisor

MUST BE USED for technology strategy, architectural decisions, and executive-level technical guidance. ALWAYS invoke for tech stack evaluations, strategic planning, and cross-team coordination decisions. Use PROACTIVELY for high-level technical leadership tasks. Examples: - "Should we adopt microservices?" → cto-advisor - "Evaluate our technology stack" → cto-advisor - "Plan our engineering roadmap" → cto-advisor - "Assess technical risks" → cto-advisor - "Design team structure" → cto-advisor - "Make vs buy decision" → cto-advisor

Performance specialist focusing on database queries, N+1 issues, caching, and optimization. Use PROACTIVELY when touching data access code. Examples: - "Review query performance" → performance-analyzer - "Check for N+1 issues" → performance-analyzer - "Optimize this endpoint" → performance-analyzer - "Review database access" → performance-analyzer - "Check caching strategy" → performance-analyzer

Invoke to crystallize requirements for a non-trivial feature. Produces a structured brief at .context/specs/<feature>/brief.md. Do NOT write briefs manually — this skill has a specific process, file structure, and approval gate that only load when invoked.

Invoke after /team-plan is approved. Spawns parallel builder agents from the approved plan. Do NOT coordinate builds manually — this skill has drift checks, context isolation, and validation gates that only load when invoked.

Systematic debugging methodology. Iron law: no fixes without root cause investigation first. Five-phase process: investigate, analyze patterns, test hypothesis, implement fix, architecture check. Includes rationalization resistance and escalation protocol. Apply during /team-build failures and bug reports.

Invoke after /team-brief is approved. Produces a design document at .context/specs/<feature>/design.md. Do NOT write design docs manually — this skill has constraint analysis, option evaluation, and a research process that only load when invoked.

Mechanized drift detection between two documents. Extracts all claims from a source-of-truth, verifies each claim against a target using up to three independent agents (Claude, Codex, Gemini), classifies mismatches by severity. Use after /team-build (plan vs implementation), between workflow stages (design vs brief), or whenever a document claims to reflect another. BOUNDARY: Only the two documents under comparison — no external context, no CLAUDE.md, no project skills.

9 hooks across 4 events