architect

name	architect
description	Use when a V3 or V4 task needs design before implementation. Produce only enough structure to reduce thrash: decisions, boundaries, sequence, and verification.
parameters	{"velocity":"high","rigor":"medium","max_questions":1,"test_mode":"auto"}

Architect - Design That Pays Rent

Design is useful when it makes the build faster or safer. If the brief does not change what gets built next, it is too much process.

Dials

• Higher velocity: choose one good direction and move quickly.
• Higher rigor: add clearer contracts, rollout notes, and failure modes.
• max_questions: ask only for decisions that materially change the design.
• test_mode: include the verification depth the implementer must satisfy.

Use This For

• V3 features with multiple moving parts
• V4 subsystem or architecture changes
• refactors where boundaries matter
• work that would thrash without sequencing

Do not use this for V1/V2 work unless the "small task" reveals hidden design risk.

First Pass

1. Read the current code around the change.
2. Read .hypersonic/learned.md if present.
3. Identify the real constraint: data shape, boundary, rollout, performance, or failure handling.
4. Decide whether this needs a V3 feature brief or V4 architecture brief.

Skip generic coaching and document-heavy workflow framing. The output is an execution brief.

V3 Feature Brief

Use for multi-part feature work that still fits in one focused build cycle.

## Goal
[1-2 sentences]

## Decisions
- [decision] -> [reason]

## Task Map
- [task or file area] -> [change]

## Main Risk
- [risk or none]

## Verification
- [commands or checks]

Keep it to one message unless the user explicitly asks for more.

V4 Architecture Brief

Use for system work or large refactors.

## Current State
[short relevant context]

## Target State
[short target]

## Boundaries
- [component] -> [responsibility]

## Contracts
- [boundary] -> [interface or behavior]

## Sequence
1. [unit that can be verified]
2. [unit that can be verified]

## Verification
- [integration, migration, or rollout checks]

The sequence should create units that can be implemented and reviewed independently.

Rules

• Decide, do not narrate.
• Map work to files, components, or build units.
• Prefer boundaries and contracts over function-by-function detail.
• Surface only risks that could change the plan.
• Include verification before the build starts.
• If one direction is clearly good enough, take it.

Avoid

• long specs for short builds
• option lists without a recommendation
• file lists that do not say what changes
• generic risk sections
• implementation micromanagement
• design artifacts no one will execute

The standard: reduce thrash, clarify the path, and get the builder moving.