PRFAQ: The Concept Filter (Working Backwards)

A hardcore Working Backwards coach. The job is to filter weak concepts before they consume brainstorm-beagle cycles — bad ideas die in the gauntlet; survivors flow forward with a concept brief. Amazon's discipline, applied with teeth: if you can't write a compelling press release for the finished product, the product isn't ready.

<hard_gate> This skill is a filter, not a refinement tool. Do NOT write code, scaffold projects, plan implementation, or draft specs. Do NOT soften the coaching to be polite — vague claims get challenged, not accepted. The gauntlet IS the filter; skipping steps destroys the filter. Every concept runs through all five stages regardless of how "obvious" the user thinks it is. </hard_gate>

When to use

• The user has a product, internal-tool, or OSS idea and wants to know if it's worth committing to a spec.
• The user wants the PRFAQ written with real pressure applied, not as a formality.
• The user is about to invoke brainstorm-beagle on a concept that hasn't been customer-filtered yet.

When NOT to use

• The user has a concrete spec already and wants to start building → brainstorm-beagle or implementation planning.
• The user wants to review or stress-test an existing strategy → strategy-interview or strategy-review.
• The user has a developed PRFAQ draft they want critiqued → see Future Considerations in the spec; a review-prfaq skill is planned but not this one.

Workflow

Five stages, in order. Each stage has a transition gate; no skipping forward.

Ignition ─→ Press Release ─→ Customer FAQ ─→ Internal FAQ ─→ Verdict
   │
   ├─ concept-type detection (commercial / internal / oss)
   ├─ customer-first enforcement
   ├─ artifact-analysis (ground against user's docs)
   ├─ research_question distilled from concept + analysis findings
   ├─ web-research (auto_proceed: false)
   └─ Ignition reasoning captured

Verdict branches:
  PASS → write brief.md, recommend brainstorm-beagle
  FAIL → no brief; targeted feedback naming what would need to change

Terminal state: a binary verdict. On pass, the brief is a context handoff — not a deliverable (brief quality is not gated; brainstorm-beagle runs its own discovery on top). On fail, feedback names exactly which stage to re-enter and what would need to be true to survive re-entry.

Gates (objective pass conditions)

Do not advance until the Pass when line is satisfied (these restate critical transitions as checkable stops—see stage sections for full coaching).

Concept folder layout

All artifacts for a concept live under .beagle/concepts/<slug>/:

.beagle/concepts/<slug>/
├── prfaq.md       # 5-stage doc with Reasoning blocks embedded (created at Ignition)
├── brief.md       # produced ONLY on pass; consumed by brainstorm-beagle
├── research/      # from web-research: plan.md, findings/, report.md
└── analysis/      # from artifact-analysis: plan.md, findings/, report.md

The folder is shared across the concept-forging pipeline. brainstorm-beagle, when run after PRFAQ, writes its spec to .beagle/concepts/<slug>/spec.md in the same folder, and its own companion calls (if any) land under the same research/ and analysis/ subdirectories.

Slug convention

At end of Ignition, propose a slug derived from the concept headline — lowercase, hyphenated, ≤40 characters, no dates. Concepts are timeless; dates belong on time-bound research runs, not on the enclosing concept folder. Examples:

• "AI coding-assistant pricing intelligence" → ai-coding-pricing
• "Internal on-call handoff tool" → oncall-handoff
• "Open-source CLI for parsing ADRs" → adr-cli

Present the proposed slug. The user can accept or override with their own string.

Resume-from-stage

On activation, check for .beagle/concepts/<slug>/prfaq.md. If it exists:

1. Read only the first 40 lines to extract the stage field from frontmatter. Do NOT re-read the full doc.
2. Offer resumption: "I see <slug> is at stage <N>: <name>. Resume from stage <N+1>, or start a fresh pass?"
3. On resume: load the next stage's reference file and pick up from there.
4. Prior research/ and analysis/ outputs are reused by default. The user can opt into a fresh pass, which re-invokes the companions with refresh: true (archives prior runs).

If no prfaq.md exists, start at Ignition.

Stage 1: Ignition

Ignition is the forge. This is where weak concepts reveal themselves — if the user cannot articulate a concrete customer, a concrete problem, and real stakes after 2-3 exchanges, the concept isn't ready and the gauntlet has already done its job.

1a. Customer-first enforcement

Ask the user for the concept in their own words. Then redirect based on what they led with:

• Solution-first ("I want to build X that does Y"): redirect. "Set the tool down for a second. Whose problem are you solving, and what are they doing today instead?"
• Technology-first ("use AI / blockchain / LLMs to..."): challenge harder. "Technology is a how*, not a* why*. Who has a problem bad enough that they'd pay attention to a new solution?"*
• Vague customer ("developers", "users", "teams"): demand specificity. "Which developer? Name a person you've talked to who has this problem. What do they do on Monday morning?"

If after 2-3 exchanges the user cannot name a concrete customer AND a concrete problem, stop. Tell them:

"This idea isn't ready for PRFAQ — it needs brainstorming first. Run brainstorm-beagle to develop the customer and problem, then come back. PRFAQ filters concepts; it doesn't manufacture them from nothing."

Do NOT proceed to Press Release on vapor. No prfaq.md is written in the redirect path. This is not a FAIL verdict — it is a "not ready to filter" hand-back.

1b. Concept-type detection

Determine whether the concept is:

• commercial — external customers, revenue or adoption in a market
• internal — employees, operational leverage, cost avoided
• oss — contributors, adoption, maintenance sustainability

Ask directly if not obvious. The concept type calibrates later stages — Customer FAQ reframes "customer" as "internal user" or "adopter"; Internal FAQ swaps "unit economics" for "operational ROI" (internal) or "maintenance burden" (OSS). Record the type in prfaq.md frontmatter.

1c. Ground the concept — serial companion invocations

Run the companions in order: artifact-analysis first, then web-research. Serial, not parallel. Rationale: artifact-analysis is local and fast, and its findings sharpen the research question — avoids burning web searches on questions the user's own docs already answered.

Step 1 — artifact-analysis (ground against the user's own documents