Dev Architecture Playbook

Dev Architecture Playbook

Purpose

Use this as the lifecycle router before starting broad product or architecture work. It chooses the minimum useful skill chain, defines gates, and prevents starting implementation before the required contracts exist.

Route

Classify the request first:

| Request | Primary Skills | Output |

|---|---|---|

| Idea, product direction, or market/user problem | product-discovery, prd-master | Product brief, user stories, success metrics |

| Architecture or module boundaries | architecture-foundation, technical-spec, elegant-architecture | Architecture spec, boundaries, rejected alternatives |

| API, auth, data, or schema contract | api-design, auth-security, database-patterns, data-contract-migrations | Versioned contracts and migration plan |

| UI/product surface | frontend-design, ui-ux-pro-max, ui-design-system, playwright-automation | UX flow, component plan, visual checks |

| Implementation workflow | flowguard, threads, systematic-debugging, comprehensive-testing | Bounded execution, ownership, root-cause debugging, and verification |

| Quality and regression risk | comprehensive-testing, codebase-audit, vibeguard, project-health-auditor | Test matrix and risk list |

| Release and operations | release-engineering, config-secrets-environments, performance-capacity, incident-slo-runbook, observability-sre, devops-excellence | Rollout, config, capacity, SLO, runbook |

Required Gates

Do not treat the architecture as complete until these gates are explicit:

• Goal and non-goals.
• Domain model and ownership boundaries.
• External API, data, and config contracts.
• Security and permission model.
• Test strategy with command-level verification.
• Release, rollback, and migration gates.
• Observability, SLO, and incident response.

If a gate is irrelevant, state why. Do not silently skip data, security, or rollback gates for production systems.

Execution Pattern

Use this sequence for greenfield or major refactors:

• Product: write the product brief or PRD.
• Architecture: define modules, runtime boundaries, and tradeoffs.
• Contracts: define API, data, config, and security contracts.
• Plan: split work into independently verifiable steps.
• Implement: use one workflow skill per step, not every skill at once.
• Verify: run build, typecheck, tests, and focused behavioral checks.
• Release: define rollout, migration, rollback, monitoring, and support owner.

For existing repos, start with repo-agent-context-audit or codebase-audit before proposing new structure.

Output Shape

Return a compact plan:

goal:
context:
selected_skill_chain:
architecture_gates:
implementation_steps:
verification_commands:
release_and_ops_gates:
open_risks:

Prefer the smallest chain that covers the risk. Too many skills at once usually means the scope needs to be split.