XFXA
XF Xecution Assurance

XFFI defined what done means. XFXA proves you delivered it.

The loop starts with XFFI — your intent decomposed into finite, binary terminals before a single line is written. XFXA is where that spec meets reality. Every terminal checked mechanically against the implementation. Unmet terminals become Claude's fix targets. The loop runs until every terminal is green. Only then: ship.

Connect with GitHub — it's free

What it does

1

The loop XFFI opened — XFXA closes.

XFFI decomposed your intent into a finite set of terminals: binary, verifiable outcomes the code must satisfy. XFXA reads that spec at ship time and enforces it. Not 'does it look right.' Not 'did the test pass.' Does the implementation satisfy every outcome XFFI defined as done. If not — Claude gets a fix target, the loop continues, and you don't ship until it does.

2

Terminals — binary outcomes, not feelings.

A terminal is not a unit test. It's a finite, binary outcome that describes what the feature is supposed to do: 'Google OAuth redirects to /dashboard.' 'Email validation fires on blur.' 'Session persists across page refresh.' Met or unmet. No ambiguity. XFFI defines them. XFXA verifies them.

3

Spec-first enforcement — XFFI writes it, XFXA reads it.

XFFI saves its output to docs/superpowers/specs/ in XFXA-compatible format. Run /xfxa after building — it reads the spec, checks each terminal, and closes the loop. The spec is the contract. The implementation either satisfies it or it doesn't. 'Looks right' is not a terminal. 'Renders without errors' is.

4

Already built something? Apply XFXA retroactively.

XFXA isn't only for new builds. Point it at code you've already written, define a spec based on your original intent — what you actually meant it to do — and run /xfxa synthesize to generate the spec from your conversation and verify immediately. Not whether it runs. Not whether it looks right. Whether it does what you meant. Code you haven't verified against intent is code you haven't finished.

5

Loop until all terminals are met — no manual re-runs.

XFXA doesn't just report. It gives Claude a fix target for every unmet terminal. Claude fixes. XFXA re-runs. Loop continues until every terminal is green. You don't call it done — XFXA does, when the spec is fully met.

6

Shows what's missing, not just what failed.

Unmet terminals come with a description of exactly what's missing in the implementation. Not 'test failed.' Not 'assertion error.' 'Google OAuth redirects to /dashboard — redirect handler missing.' Claude gets a concrete action, not a vague failure.

7

Gate your ship on XFXA green. No green, no ship.

Run /xfxa before pushing. It reads your spec, checks every terminal, and returns the full report in seconds. XFFI opened the contract. XFXA closes it. The full XF intent-to-delivery arc in two commands.

How it works

1

/xffi runs first — decomposes your intent into finite terminals, saves spec to docs/superpowers/specs/.

2

Build. When ready to ship, run /xfxa.

3

/xfxa reads the spec, checks each terminal against the implementation.

4

Met terminals listed with ✓. Unmet listed with ✗ and what's missing.

5

Claude receives fix targets for every unmet terminal.

6

Claude fixes. /xfxa re-runs automatically.

7

Loop continues until all terminals are green. Then and only then: ship.

● ● ●
◈ XFXA 5 terminals · 4 met · 1 unmet
✓ login screen renders without errors
✓ email validation fires on blur
✓ password minimum length enforced
✓ form submits on Enter key
✗ Google OAuth redirects to /dashboard — redirect handler missing
→ Claude: fix the 1 unmet terminal. /xfxa will re-run.
Other modules