Proposal: Native PRFAQ generator /speckit.prfaq

[cruschke]

The Problem
When using Spec Kit it’s easy to get "artifact overwhelmed". When building a feature we have the user stories, plan, contracts and research, but we do not have a solid "North Star" for why we're building the feature.

The Idea
Add a native PRFAQ (Press Release / Frequently Asked Questions) generator. This synthesizes the technical specs into a one-page "vision" document based on the Amazon Working Backwards framework.

Why it helps:

• Clarity: Provides a plain-English summary for stakeholders before they dive into the technical weeds.
• Consistency: Standardizes the "Product Vision" format across all my projects and features.
• Focus: Acts as a guardrail to ensure technical artifacts align with the core problem.

Proposed Output (PRFAQ.md):

• Press Release: The "hook," the problem, and a fictional user quote.
• External FAQ: Real-world user questions (e.g., "Is this free?", "How do I migrate?").
• Internal FAQ: Tough technical/business questions (e.g., "Why this architecture?", "What are the risks?").

[cruschke]

Spec Kit Adds Native PRFAQ Generator: Stop Drowning in Specs, Start Shipping with Clarity

Berlin, GERMANY —Spec Kit today announced /speckit.prfaq, a native command that
synthesizes technical specifications into a one-page product narrative using the
Amazon "Working Backwards" framework.

The Problem: Spec Kit excels at generating deep technical artifacts—ERDs, OpenAPI
contracts, data models, research documents. But teams hit a wall: they have beautiful
technical specs and no clarity on why they're building it. Stakeholders get lost in
the weeds. Product intent drowns in implementation details. Technical decisions diverge
from the original problem statement.

The Solution: /speckit.prfaq reads your existing spec, plan, and research artifacts
and generates a Press Release + External FAQ + Internal FAQ in minutes. It forces a
critical moment of truth: "Do our technical decisions actually solve the problem we said
we'd solve?" Before code is written. Before architecture is locked in.

"We noticed something: teams with clarity on why ship 40% faster and have 60% fewer
scope-creep pivots," says a Spec Kit user. "PRFAQ is the North Star that keeps
everything aligned."

/speckit.prfaq is available now via the Spec Kit CLI for all projects.

EXTERNAL FAQ (Spec Kit Users)

Q: I already have 10 spec documents. Why do I need another one?
A: PRFAQ isn't another spec—it's a test. It proves your specs solve a real problem.
If your PRFAQ doesn't make sense, your technical approach probably doesn't either.

Q: Does this replace our design reviews?
A: No. It precedes them. PRFAQ answers "are we solving the right problem?" before
design review answers "are we solving it the right way?"

INTERNAL FAQ (Spec Kit Maintainers & Contributors)

Q: Why build this as a native command instead of just documenting "here's how to write
a PRFAQ manually"?
A: Because documented-but-optional features get skipped 80% of the time. A built-in
command makes it frictionless and encourages adoption. Also, we can reference the
user's actual spec/plan/research to ground the narrative in reality, not speculation.

Q: Isn't the "Working Backwards" framework from Amazon? Aren't we just copying their method?
A: Yes, intentionally. Amazon's framework is proven and well-documented. We're not
inventing narrative structure—we're lowering friction to using a proven method.
Adding it as a Spec Kit command introduces teams to the practice who wouldn't otherwise
encounter it.

EDIT: improved example PRFAQ

[mnriem]

Consider delivering this as an extension. See https://github.com/github/spec-kit/tree/main/extensions