How is this different from asking an AI to play devil's advocate?

Devil's-advocate prompts tend to hedge. This critic is instructed to give specific consequences, not "this might fail", and must rate every failure mode by severity and likelihood, tie it to a spec section, and answer four market-skeptic questions. It also asks for your own worry first, so you can see what you missed.

When should I use this instead of Spec Red-Team?

When you want a fast, focused list of what could go wrong, for example before a planning meeting. Spec Red-Team adds an isolated strengths review so you also know what not to break; Reckon adds a PRD-drafting interview for raw ideas.

What do proceed, descope and kill mean?

KILL when the critic judges the idea fundamentally flawed. DESCOPE when there is at least one critical failure mode or two or more weak market verdicts: fix those before building. PROCEED when there are no critical blockers, with the remaining risks listed.

Do I need an API key, an account or an internet connection?

No. It runs inside your own agent session. The bundled script makes no network calls and needs no npm install; it only reads and writes JSON files in a local .reckoning/ folder.

Which agents does it work with?

Any agent that supports the SKILL.md standard, including Claude Code, Cursor, Codex CLI, GitHub Copilot and Gemini CLI. Where the agent supports subagents, the critic runs in isolation so your stated worry can't bias it.

Spec Pre-mortem: Every Way Your Plan Could Fail

Spec Pre-mortem first asks: "Before I show you anything: what worries you most about this spec?" Then the critic runs on the spec alone and returns:

Reckoning Pre-mortem — forge-pulse-fast-feedback-team-heartbeat (v1)

⚖️ Verdict: DESCOPE

3 critical failure mode(s) and 3 weak market verdict(s) — fix before building.

🔴 Failure modes (by severity)

[critical/high] Anonymous Voting Manipulation Will Destroy Trust in First Real Incident (failure_modes · §technical_considerations)
Without cryptographic vote prevention (finding-014 shows one-time ring signatures required), first time someone stuffs votes with 20+ upvotes on their own note, entire team loses faith in anonymity system.
[critical/high] 1-2 Month Timeline With WebSocket, Real-Time Collaboration, and GDPR Compliance Is Fantasy (failure_modes · §scope)
Finding-020 shows simple products take 1-3 months, real-time features add 2-3 weeks.
[critical/medium] Permanent Anonymity Prevents You From Moderating Harassment or Malicious Content (failure_modes · §technical_considerations)
Technical section acknowledges 'permanent anonymity creates forensic challenge if malicious content posted.' First time someone posts 'Sarah is incompetent and should be fired' in anonymous note, you have zero recourse.
[high/high] You're Solving Symptom (Low Action Completion) Not Root Cause (No Accountability Culture) (failure_modes · §problem)
Finding-007 shows even with visibility features, completion only reached 65% from 40-50%.
[high/high] Mandatory Action Item Creates Resentment and Low-Quality Garbage Actions (failure_modes · §user_stories)
Story #9 says 'cannot close retro without creating at least one action.' When team has genuinely good sprint, they'll create fake action like 'Continue doing great work' to satisfy requirement.
[high/high] Can't Measure 'Team Health Improvement' Until Month 3, But Need Validation at Week 8 (failure_modes · §success_metrics)
Success criteria says 'team sentiment trends positive over 3+ month periods' and 'reduction in recurring themes across 3+ consecutive retros.' With 2-week sprints, that's 6 retros minimum = 12 weeks before ANY success signal.
[high/high] Free Competitor Dominance Means You're Building Features for GoRetro's Roadmap (failure_modes · §risks_and_open_questions)
Finding-002 shows GoRetro fully free, ranked #1 on G2, unlimited users.
[high/high] Historical Timeline Queries Become Unusably Slow at 6+ Months of Data (scale_pain · §scope)
Heartbeat Timeline shows 'all past retrospectives in chronological order.' Success criteria targets 6+ month retention.
[high/high] No Jira Integration Means Action Items Live in Silo, Creating Second-Class Status (scale_pain · §technical_considerations)
Finding-022 shows Jira/Linear integration is expected, but PRD says 'start fresh without integrations for MVP.' When team creates 3 retrospective actions in Forge Pulse but has 40 sprint tasks in Jira, the 3 retro actions are invisible to product planning.
[high/high] Actions Have Owners But Notes Are Anonymous—Users Won't Understand the Contradiction (user_confusion_risks · §user_stories)
Notes are 'permanently anonymous, even from facilitator' but actions require 'specific owner and delivery date.' User submits anonymous note 'Our CI pipeline is broken,' team discusses, facilitator says 'Sarah will fix CI by Friday.' Sarah thinks: 'Everyone knows that was my note now' and feels exposed.

🧭 Market skeptic

Why care? [moderate] The pain is real (40-50% action completion, recurring themes, psychological safety barriers) but the willingness to pay is questionable.

Why now? [weak] The PRD provides no 'why now' argument.
Why win? [weak] Differentiation is Heartbeat Timeline + permanent anonymity + auto-carry actions.
Feature or product? [weak] This is a feature bundle that any existing retro tool could add in 4-8 weeks.

📋 Overall

This PRD exhibits three fatal flaws: (1) Solving symptom (low action completion) not cause (no organizational accountability culture), (2) Technical complexity (anonymous voting cryptography, WebSocket scaling, GDPR compliance) vastly underestimated relative to 1-2 month timeline, (3) Zero defensible moat against 10+ free competitors who can copy all features in 6-12 weeks.

Critic confidence: 0.88

Then it adds a short diff against your stated worry: what the critique confirmed, what you missed, and what it didn't back up.

Condensed for this listing: critical and high/high failure modes only, with detail trimmed to the first sentence. Generated from the example critique bundled with the Reckon skills.

About this skill

Assume the project already failed. Spec Pre-mortem works out why, before you build it.

It's the critic half of Reckon on its own: no praise, no hedging, just every way the plan could fail, ranked so you know what to fix first. Fast and cheap, and good for a gut-check before a planning meeting.

How it works

Hand it a spec. A PRD, RFC, design doc, product plan or idea write-up, as a file path or pasted text.
Name your worry first. Before any AI output, you say what worries you most. This stops you anchoring on the machine.
Critique. The critic sees only the spec, in an isolated subagent where your agent supports one.
Validated output. The critique is checked against a strict schema, then rendered as a severity-ranked pre-mortem.
Diff. What the critique confirmed about your worry, what you missed, and what it didn't back up.

What the critic checks

Failure modes, scale pain, user confusion risks and engineering regrets, each rated by severity (critical / high / medium / low) and likelihood, and tied to a spec section
Market skeptic: Why care? Why now? Why win? Feature or product? Each rated strong, moderate or weak
Verdict: KILL if fundamentally flawed, DESCOPE if there are critical blockers, otherwise PROCEED

What's inside

SKILL.md: the pre-mortem flow
references/critic-assassin.md: the critic prompt and schema
scripts/reckoning.mjs: a short, readable validator and renderer with no dependencies (Node 18+)

Known limitations

Critic only: no strengths analysis. For the balanced bull vs. bear review, use Spec Red-Team or Reckon.
Rendering needs Node 18+. Without it, the agent formats the output by hand.

Free and open source (MIT): github.com/alchemyguy/reckoning

Spec Pre-mortem: Every Way Your Plan Could Fail