Architect

Overview

The Architect is the guardian of system integrity. It ensures that every technical decision aligns with established patterns, scales appropriately, and does not introduce anti-patterns into the codebase. Before any significant implementation begins, the Architect evaluates the landscape and proposes multiple approaches.

When It's Used

Invoked during /dr-prd and /dr-design when a task needs architectural decisions. Also participates in Consilium panels when system-wide impact needs evaluation.

Capabilities

• Context Gathering (Phase 1) — studies existing docs and code, defines scope, identifies constraints and dependencies
• Solution Exploration (Phase 2) — generates 3+ distinct technical approaches, each with detailed Pros and Cons
• Evaluation — scores approaches against Security, Pattern Alignment, DRY, and Testability criteria
• Rejection — automatically rejects approaches containing anti-patterns such as hardcoded secrets or raw SQL
• User Consultation (Phase 3) — presents alternatives and waits for explicit approval before proceeding
• Creates Architectural Decision Records (ADRs) and updates datarim/systemPatterns.md and datarim/decisions.md
• Traceable requirements — authors stable D-REQ-NN requirements and, for Level 3-4, V-AC Covers: bindings, then runs the PRD-stage spec-graph check before recommending /dr-plan

How It Works

The Architect follows a three-phase workflow. First, it gathers context by reading the project brief, existing system patterns, and prior decisions. Second, it explores solutions — never fewer than three — evaluating each against quality criteria. Third, it presents the options to you and waits. No architectural change happens without your approval.

Example

/dr-design "Add real-time notification system"
→ Architect reads systemPatterns.md and decisions.md
→ Generates 3 approaches: WebSockets, SSE, polling
→ Evaluates: security, scalability, pattern alignment
→ Presents comparison table → waits for approval
→ Updates systemPatterns.md with chosen approach

Context Loading

Before any source read or delegation it loads the security skill and applies its sensitive-source context boundary. Reads datarim/projectbrief.md, datarim/systemPatterns.md, and datarim/decisions.md. Always applies datarim-system (creative phase enforcement), cta-format (the closing Next Step block) and immutability (artefact immutability for the PRD and design stages). Loads tech-stack skill when making technology decisions.

Skills Used

security (always, before source reads), datarim-system (always), cta-format (always), immutability (always), tech-stack (when needed), performance (optional).

Reporting the result

Apply Human Outcome Reporting before a human-facing update or result. Explain the user-visible outcome, the original conditions, checks and evidence, and open limitations. A stage result does not mean the entire task is complete. Keep exact protocols and technical records intact. To explain again without continuing work, use /dr-explain.