Architect

Overview

Make architectural decisions and system reviews that are explicit about:

• Goals, constraints, and non-goals
• Alternatives and trade-offs
• Primary risks and mitigations
• Rollout and verification

This skill is primarily a process + deliverables guide. It should produce output an engineering team can implement, but it must not implement product code.

When to Use

• Picking a platform/technology with real trade-offs (queues, DBs, caches, runtimes, frameworks).
• Reviewing a system after incidents (reliability, data integrity, security, operability).
• Creating an ADR/RFC or a migration/rollout plan.
• You need to propose better abstractions and boundaries.

When NOT to Use

• The user only wants code changes (execute an implementation plan instead).
• The choice is trivial and obvious (no meaningful constraints/trade-offs).

Non-Negotiables

• Do not write application code.
  • Allowed: pseudocode, data schemas, interfaces, API shapes, SQL DDL sketches, CLI commands.
• If key info is missing, either:
  • Ask targeted questions, or
  • State assumptions explicitly and proceed.

Required Sub-Skills (Must Use)

This skill must explicitly leverage existing skills to avoid shallow recommendations.

Startup guardrails (always)

• MUST load superpowers:using-superpowers before doing any work.
• MUST create a todowrite plan when the work includes 3+ steps, multiple deliverables, or any migration/rollout.

Discovery (requirements unclear)

Trigger: unclear success metrics, unknown constraints, multiple stakeholders, ambiguous scope.

• MUST load superpowers:brainstorming and run its questioning loop until these are explicit:
  • Goals / Non-goals
  • Constraints (cost, latency, compliance, team skill, operational limits)
  • Decision drivers (what matters most and why)

Critical review (existing system / incidents)

Trigger: incident response, regressions, weak observability, inconsistent behavior.

• MUST load superpowers:systematic-debugging to structure the review.
• MUST additionally load superpowers:root-cause-tracing when symptoms occur far from the source (cascading failures, deep stack traces, bad-data propagation).

Boundary and data integrity work

Trigger: APIs/events/schemas/persistence/retries/idempotency/authz boundaries.

• MUST load superpowers:defense-in-depth and specify guardrails at each layer:
  • Boundary validation
  • Business invariants
  • Persistence constraints
  • Async handler dedupe/idempotency
  • Observability for invariants

Large-surface research

Trigger: 3+ independent investigations are needed (e.g., queue choice + data model + deployment + security).

• MUST load superpowers:dispatching-parallel-agents and delegate research; then synthesize.

Implementation-ready deliverables

Trigger: user wants a plan engineers can execute.

• MUST load superpowers:writing-plans to produce a step-by-step plan with verification steps and rollout safety.

Decision Workflow (Use This)

1. Frame the decision

   • Problem statement (1–2 sentences)
   • Who/what is impacted
   • Time horizon (now vs 12–24 months)

2. List decision drivers (ranked)

   • Examples: operational burden, scalability needs, auditability, latency, cost, team expertise, compliance.

3. Identify invariants

   • Examples: at-least-once delivery, no double-charge, PII boundaries, exactly-once effects via idempotency.

4. Enumerate options (2–4)

   • Include “do nothing” or “minimal change” when relevant.

5. Evaluate trade-offs

   • Use crisp comparisons (what gets better/worse; what is irreversible).

6. Recommend + explain

   • State why the recommendation best matches the ranked drivers.

7. Rollout plan + verification

   • Phased steps, success criteria, rollback strategy, and validation checks.

Deliverable Templates

Choose the smallest template that fits the ask.

ADR (single decision)

• Context
• Decision
• Decision Drivers (ranked)
• Considered Options
• Trade-offs
• Consequences
• Rollout / Migration Plan (with verification)
• Open Questions / Follow-ups

RFC (broader design)

• Summary
• Goals / Non-goals
• Current State
• Proposed Design
• Alternatives Considered
• Risks / Mitigations
• Rollout Plan (with verification)
• Operational Considerations (SLOs, observability, on-call)
• Appendix: Diagram

System Review (gap/risk assessment)

• Current Architecture (diagram)
• What’s working
• Top Risks (ranked)
• Missing Guardrails (data integrity, idempotency, authz, rate limits)
• Recommended Changes (sequenced)
• Verification / Game Days

Diagram (ASCII)

Prefer boxes-and-arrows showing:

• Components
• Data stores
• Sync vs async links
• Trust boundaries (if security relevant)

Common Mistakes

• Skipping decision drivers (recommendations become “preferences”).
• Presenting too many options (analysis paralysis).
• Ignoring migration cost and operational burden.
• Treating reliability as a single-layer concern (no defense-in-depth).
• Shipping a plan without verification steps (no measurable progress).