Architecture Design Prompt

把架构回答逼成三个结构上真正不同的方案，各自写明成本与失效点，再给出一个明确推荐，并做一轮自我反驳。

分五部分：先用真实数字与硬约束复述问题；给出三个结构上不同的方案（必须包含最朴素的一个和比直觉更小的一个），每个都写明成本、失效方式、以及在什么量级上失效；然后必须选定一个；接着尽力反驳自己的推荐并做两年后的事前验尸；最后拆成可施工的部分，区分「可以延后」和「延后就得重写」。全文限 900 字。另附写 ADR 与评审既有架构的补充提示词。

# Architecture Design

**Use when:** you are choosing a structure you will live with for a long time.
**Pairs with:** [senior_engineer.md](senior_engineer.md), [../core/loop_engineering.md](../core/loop_engineering.md)

Architecture answers from models default to the textbook answer, which is usually more machinery than you need. This prompt forces real options, real costs, and a real recommendation.

---

## The prompt

```text
You are designing a system that a team will maintain for years. Your job
is a decision with reasons, not a survey of possibilities.

PART 1: GET THE PROBLEM RIGHT
Before proposing anything:
- Restate the problem in one paragraph, including the part I implied but
  did not say.
- What must be true for this to be a success? List the requirements that
  actually constrain the design. Drop the ones that do not.
- Numbers. Ask for them or state your assumption clearly: how many users,
  how much data, how many requests, how fast must it be, how much can it
  cost, how much downtime is acceptable. A design without numbers is a
  guess.
- What is fixed and cannot change: existing systems, team size, team
  skills, deadline, budget, compliance.
- What will change in two years? Design for that, not for infinity.

PART 2: THREE REAL OPTIONS
They must differ in structure and in trade off, not in wording. Include
the boring one. Include the one that is smaller than feels right.

For each:
- How it works, in five lines.
- What it makes easy.
- What it makes hard or impossible later.
- Cost: to build, to run, to operate, to understand.
- How it fails. Not if. Which part fails first and what happens then.
- The number at which it stops working.

PART 3: DECIDE
Pick one. State why in terms of this situation, this team, and these
numbers. Never "it depends" and never "industry best practice".
- What you are giving up by choosing it.
- What would have to be true for a different option to win. Be specific
  enough that I could check.
- What you would do differently if the numbers were ten times larger.

PART 4: ATTACK YOUR OWN CHOICE
- Argue against your recommendation as hard as you can, in 100 words.
- Then say whether the argument changes your mind.
- Pre mortem: it is two years from now and this design was a mistake.
  Write the three most likely reasons. For each, what early signal would
  have warned us?

PART 5: MAKE IT BUILDABLE
- The components and how they talk. Names and responsibilities.
- The data model and why it is shaped that way.
- The boundaries: what is behind an interface and why there.
- The first thing to build, and what proves it works.
- What can be deferred safely and what cannot be deferred without a
  rewrite. That second list is the important one.

RULES
- Do not add a component that does not earn its place. Every box is
  something someone has to run, monitor, debug at 3am, and upgrade.
- Do not design for a scale you cannot name.
- Prefer what the team already runs over what is better in theory.
- Say plainly when the answer is "one service and a database".
- No diagrams made of words unless they carry information a list cannot.

LENGTH
Under 900 words for the whole thing. If it takes more than that, the
design is too complicated.
```

---

## The number question

Most bad architecture comes from designing for imagined scale. Force the number early:

```text
Before proposing anything, ask me for the three numbers that decide this
design. If I do not have them, state the value you are assuming and how
the design changes if the real number is ten times higher or ten times
lower.
```

---

## For an architecture decision record

```text
Write this as an ADR:
  Title
  Status: proposed
  Context: the situation and the forces, including the numbers
  Decision: what we are doing, in the active voice
  Consequences: what gets better, what gets worse, what we can no longer
  do easily
  Alternatives considered: each with the one line reason it lost
Keep it under 400 words. An ADR nobody reads is not a record.
```

---

## For reviewing an existing architecture

```text
You have just joined this team. Review this architecture.
- What does it get right? Say this first and mean it, so I know you
  understood it before criticising.
- Where is the accidental complexity? Which part exists because of a
  decision that no longer applies?
- What is the single riskiest part and why?
- Where will it break first as we grow, and at what number?
- What would you change in the next quarter, and what would you leave
  alone even though it is ugly? Justify the "leave alone" list as
  carefully as the change list.
```

---

## Why it works

**Three options that must include the boring one and the small one** blocks the default, which is to propose the most sophisticated design the model knows.

**Naming the number where each option breaks** turns "does it scale" from a slogan into a fact you can check.

**Attacking your own choice** catches the design that sounded good while being written.

**The "cannot be deferred without a rewrite" list** is the most practical output. It tells you what to get right now and what to leave alone.