XFFI
XF Finite Intent · XFFI

Turns your intent into a finite, verifiable spec — before Claude writes a single line.

Every session starts with a prompt. That prompt is infinite — it can mean anything, go anywhere, expand without bound. XFFI intercepts before any work starts and produces a finite MECE spec sheet: bounded limbs (WHAT/WHO/HOW), recursive discovery to terminals, every node atomic and non-overlapping. The rest of XF executes against that spec. Without XFFI, you're enforcing execution on undefined intent. With it, done is defined before work begins.

Connect with GitHub — it's free

What it does

1

Fires before everything else — intent defined before code begins.

XFFI is the first module in the stack. Before XFTD routes a tool, before XFBA checks a contract, before XSIA maps impact — XFFI produces the spec every other module executes against. You can't enforce what you haven't defined. XFFI defines it.

2

MECE decomposition — every boundary complete, every node non-overlapping.

XFFI decomposes your intent into three bounded limbs: WHAT (the deliverable), WHO (the user or system it serves), HOW (the method of delivery). Each limb is recursively explored until every node is atomic. Nothing leaks between boundaries. Nothing is double-counted. The result is a finite set of terminals — not a roadmap, not a backlog, a closed list.

3

Terminals you can verify — not goals you hope to reach.

The output isn't a plan. It's a spec sheet: a finite list of binary outcomes the implementation must satisfy. Each terminal is a verifiable condition — met or not met. XFDB reads this spec at ship time and enforces it mechanically. XFFI defines done. XFDB proves it.

4

Uses the Xpansion engine — falls back to Claude-native decomposition.

XFFI invokes the Xpansion recursive decomposition engine first. If the engine returns invalid or incomplete boundaries, XFFI falls back to Claude-native MECE analysis — same structure, same rigor, same output format. The spec is always produced, regardless of engine state.

5

Saves to your project — XFDB picks it up automatically.

The spec writes to docs/superpowers/specs/ in XFDB-compatible format. Run /xfdb after building — it reads the spec, checks every terminal, and closes the loop. Intent defined here. Delivery verified there. The full XF contract in two commands.

How it works

1

You state your intent — /xffi fires.

2

Xpansion engine attempts full MECE decomposition: WHAT/WHO/HOW boundaries.

3

If engine returns invalid output: Claude-native MECE fallback runs.

4

Completeness check: every limb populated, every terminal atomic and non-overlapping.

5

Spec saved to docs/superpowers/specs/YYYY-MM-DD-xffi.md — XFDB-compatible format.

6

Session context set: all subsequent XF modules execute against this spec.

● ● ●
◈ XFFI intent received — decomposing to MECE terminals
WHAT
- [ ] Auth handles Google OAuth + email/password
- [ ] Session persists across page refresh
WHO
- [ ] New user signing up for the first time
HOW
- [ ] Supabase Auth + redirect to /dashboard on success
◈ XFFI ✓ 7 terminals written → docs/superpowers/specs/2026-04-09-xffi.md
Other modules