sdlc-workflow

Comprehensive code review covering all 30 review dimensions — correctness, security, architecture, infrastructure, quality, and UX — in a single thorough pass

Architecture review covering design quality, performance, scalability, and API contracts in a single pass

Infrastructure review covering deployment config, CI/CD, release management, migrations, logging, and observability in a single pass

Pre-merge code review covering correctness, testing, security, refactor safety, and maintainability

Quick code review covering correctness, style consistency, developer experience, UX copy, and overengineering in a single pass

Use when a documentation request is ambiguous, involves planning a docs structure, or a page seems to mix multiple purposes. Classifies content into Diátaxis quadrants (tutorial, how-to, reference, explanation), proposes a documentation map, and produces a writing plan with ordering. Triggers on phrases like "plan my docs", "what docs do I need", "help me organise my documentation", "docs architecture", "I need to write docs for my project", or when a user asks for a README and a full docs set together.

Use when the user asks to review, audit, improve, classify, or reorganise existing documentation — for a single page or a whole docs set. Evaluates docs against Diátaxis principles: type fit, boundary discipline, user fit, structure, and quality. Returns concrete prioritised fixes and, where needed, recommends splitting overloaded pages. Triggers on phrases like "review my docs", "audit the documentation", "what's wrong with this guide", "improve this README", "tell me what's wrong".

This skill should be used when analyzing errors, stack traces, and logs to identify root causes and implement fixes.

Use when the user asks for conceptual guides, architecture overviews, design rationale, trade-off discussions, background on how a subsystem works, historical context, or "why is it built this way?" documentation. Creates understanding-oriented content that builds mental models — the why, not the how. Do not use for direct task execution (use how-to) or factual lookup (use reference).

Use when the user asks for a how-to guide, step-by-step instructions for a specific goal, troubleshooting guide, configuration guide, deployment steps, migration guide, or operational runbook. Creates goal-oriented guides for competent users who know what they want to achieve. The reader already understands the basics — this is about getting work done. Do not use for beginner onboarding (use tutorial) or conceptual background (use explanation).

3 hooks across 3 events