Decide an architecture that will not force a rewrite

A fixed chain of declared-position beats -- cut the portfolio, check longevity, name the integration seam, then stress-test the decision -- each one only valid once its predecessor has already run.

Also usesclaude-plugins-official

Each beat here is only valid once its predecessor has already run: cupertino-backwards must precede any named framework, cupertino-focus must precede longevity and integrate, and architecture-critic must close the chain rather than open it. Skipping ahead — naming an integration seam before the portfolio is cut, or reviewing adversarially before a decision exists to review — produces a verdict on the wrong artifact.

Start here

One prompt to start

Before we pick any architecture or framework here, work backwards from what this actually needs to do, cut the feature portfolio before naming an integration seam, and close with an adversarial review of the decision once it's actually made -- not before.

Needscupertino, code-modernization

Beats

Run these in order. Each prompt is copy-pasteable straight into Claude Code.

cupertino:cupertino-backwards
Its own frontmatter states it directly: use FIRST, before cupertino-focus or any other cupertino technique -- a pre-architecture gate, run once no framework or database has been named yet.
Run this beat on its own
prompt
```
before we pick any architecture or framework, work backwards from what this actually needs to do
```
cupertino:cupertino-focus
Use immediately after cupertino-backwards -- architecture must never be built to support an uncut portfolio of features.
cupertino:cupertino-longevity
Run at architecture-decision time, together with cupertino-integrate -- the Vista-Trap check, catching a design that looks modern today and stale in two years.
cupertino:cupertino-integrate
Own-vs-delegate, one named integration seam per invocation -- never issued as a blanket policy across the whole system.
code-modernization:architecture-criticalso in 1 other recipe
- Build a new feature in an existing codebase
Adversarial close: over-engineering and simpler alternatives, judged against the settled decision rather than against the enthusiasm that produced it.
Run this beat on its own
prompt
```
review this architecture decision adversarially -- where is it over-engineered, and what's the simpler alternative we didn't take seriously?
```

Worked example

Grounded in — why this beat order is trustworthy

This repo's own eight independent version groups in .rrt.toml, with deliberately no aggregate werkstoff version -- a real longevity/integrate decision (each plugin owns its own release seam) that no recipe currently shows anyone how to reach.

Do / Don't

Run cupertino-backwards before naming any framework or database -- it's a pre-architecture gate by its own declaration.
Cut the feature portfolio with cupertino-focus before naming any integration seam with cupertino-integrate.
Name exactly one integration seam per cupertino-integrate invocation, never issue it as a blanket policy across the whole system.
Close with architecture-critic only once a real decision exists to review adversarially.

Don't name an integration seam before the feature portfolio has been cut -- the ordering here is load-bearing, not incidental.
Don't run architecture-critic before a decision exists -- reviewing before an artifact exists produces a verdict on the wrong thing.
Don't treat cupertino-longevity as separable from cupertino-integrate -- they run together, at architecture-decision time.