By name: decision-accountability description: This skill should be used when making architectural decisions, writing specs, or reviewing decisions that contain "future work", "v2", "simpler for now", "out of scope", or complexity claims. Verifies assumptions are grounded and catches corner-cutting disguised as pragmatism. Applies to code, specs, data models, auth flows, and context structures.
Decision Accountability
Unified check for assumption verification AND ownership accountability. Both failures lead to the same outcome: decisions that cost 10x to fix later.
When to Use
- Writing or reviewing specs
- Any architectural decision (code, auth, data model, context structure)
- When these phrases appear: "future work", "v2", "later", "simpler for now", "out of scope"
- When deferring anything that might be foundational
- Before finalizing any decision that persists
The Dual Failure Mode
Epistemic failure: "I assumed X was complex without checking" Ownership failure: "I avoided checking because the answer might mean more work"
Both produce: deferred foundations, duplicate implementations, tech debt disguised as pragmatism.
The laziness cascade:
- See decision point
- One path looks like more work
- Don't verify (because verification might confirm it's the right path)
- Pick easy path
- Dress it up as "tradeoff" or "v1 scope"
- Abdicate: "future work"
Step 1: Extract Decisions and Claims
From the spec/decision, list all claims and deferrals:
| Decision | Rationale Claims | Deferrals |
|---|---|---|
| [What was decided] | [Claims used to justify] | [What was pushed to "later"] |
Example:
| Decision | Rationale Claims | Deferrals |
|---|---|---|
| MCP has own /login | "Cross-subdomain is complex" | "SSO is future work" |
Step 2: Verify Every Claim
For each claim, attempt to falsify it:
Complexity Claims
Write the implementation. If it's <20 lines, the claim is falsified.
Claim: "Cross-subdomain cookies add complexity"
Verification:
cookies.set('session', token, { domain: '.tastematter.dev' });
Verdict: FALSIFIED — one line, not complex
Simplicity Claims
Show both options concretely:
Claim: "Separate login per service is simpler"
Option A (spec chose): MCP /login + Browser /login = 2 implementations
Option B (alternative): Browser /login only = 1 implementation
Verdict: FALSIFIED — "simpler" option is actually more complex
Deferral Claims
Calculate cost now vs later:
Claim: "SSO is future work"
Cost now: Use parent domain cookie (1 line change)
Cost later: Migrate two auth flows, reconcile sessions, update both services, migration period
Verdict: FALSIFIED — deferral costs 10x more
Step 3: Ownership Test
For each decision, answer honestly:
The Avoidance Check
Did you avoid verifying because the answer might mean more work?
If yes → Go verify NOW. You're avoiding, not deciding.
The Timeline Test
| Timeframe | Question | If answer is concerning... |
|---|---|---|
| 6 months | Will this be debt or foundation? | It's the wrong decision |
| 12 months | Will someone undo this to build forward? | It's the wrong decision |
| 5 years | Thank yourself or curse yourself? | It's the wrong decision |
The Maintenance Test
If you had to maintain this for 5 years, would you make the same decision?
If no → You're optimizing for "not my problem" — that's abdication, not engineering.
Step 4: Classify Deferrals
| Item | Foundational? | Can Defer? |
|---|---|---|
| Auth flow unification | YES | NO |
| Cookie/token scoping | YES | NO |
| Data models crossing boundaries | YES | NO |
| State multiple services share | YES | NO |
| API contracts between services | YES | NO |
| Spec architecture for multi-phase work | YES | NO |
| Additional OAuth provider | NO | YES |
| UI polish | NO | YES |
| Analytics | NO | YES |
| Documentation | NO | YES |
Foundational items cannot be deferred. There is no "v2" for foundations — only rewrites.
Step 5: Block or Proceed
If any foundational claim is falsified or deferred:
BLOCKED. Do not proceed. Revise decision first.
Provide:
- Which claims were falsified with evidence
- The actual implementation that disproves the complexity claim
- Revised decision based on verified assumptions
If proceeding with legitimate deferrals:
Each deferral MUST have:
| Field | Required Content |
|---|---|
| Why not now | Actual blocker (not "too much work") |
| Cost comparison | Now vs later, with estimates |
| Owner | Who will do it (default: you) |
| Trigger/deadline | When it gets done |
No orphaned "future work." If you can't fill these out, you're abandoning, not deferring.
Output Format
## Decision Accountability Report
**Decision under review:** [What's being decided]
### Claims Verified
| Claim | Type | Verdict | Evidence |
|-------|------|---------|----------|
| "X is complex" | Complexity | VERIFIED/FALSIFIED | [Implementation or docs] |
| "Y is simpler" | Simplicity | VERIFIED/FALSIFIED | [Both options shown] |
| "Z can wait" | Deferral | VERIFIED/FALSIFIED | [Cost comparison] |
### Ownership Check
| Question | Answer | Concern? |
|----------|--------|----------|
| Avoided verification? | Yes/No | |
| 6mo: debt or foundation? | | |
| 12mo: undo to build forward? | | |
| 5yr: thank or curse? | | |
### Deferrals (if any)
| Item | Foundational? | Why not now | Cost now/later | Owner | Deadline |
|------|--------------|-------------|----------------|-------|----------|
| | | | | | |
### Verdict
[ ] **PROCEED** — all claims verified, no foundational deferrals
[ ] **BLOCKED** — falsified claims or foundational deferrals, revise first
### Revised Decision (if blocked)
[New decision based on verified assumptions and owned outcomes]
Quick Reference
Red Flag Phrases
| Phrase | Action |
|---|---|
| "adds complexity" | Verify — write the implementation |
| "simpler for now" | Show total cost comparison |
| "future work" / "v2" | Foundational or additive? |
| "we can unify later" | At what cost? Show the math |
| "accepted tradeoff" | Is the analysis actually correct? |
| "out of scope" | Is this actually out of scope or foundational? |
Cannot Defer (Foundational)
- Auth / sessions / identity
- Data models crossing service boundaries
- Cookie / token scoping
- API contracts between services
- State that multiple services touch
- Spec architecture for complex multi-phase work
The Core Test
Would I make this decision if I'm maintaining it for 5 years?
If no, it's corner-cutting disguised as pragmatism. Do it right.
Evidence Base
Origin: C1 MCP Auth Foundation spec review (2026-04-23)
The spec contained decision D5:
"Login UI served from MCP worker directly (not browser worker)... Cross-subdomain cookie sharing adds complexity... Two login pages accepted for v1. Single-sign-on is future work."
Analysis revealed:
- "Cross-subdomain cookies" = one line:
domain: '.tastematter.dev' - "Two login pages simpler" = false, it's 2x implementation and maintenance
- "SSO is future work" = will cost 10x to unify later
Root causes identified:
- Epistemic: Complexity claim unverified
- Ownership: Avoided verification because answer meant more work
Pattern extracted: Both failures stem from optimizing for "less work now" at the cost of "much more work later" — and dressing it up as pragmatism.