Write prfaq

Skill: write-prfaq

Produces a PRFAQ — a press release written as if the product already exists, followed by a customer FAQ and an internal FAQ — using the Amazon PRFAQ format as the direction-setting convention. The press release forces specificity about who the customer is, what problem they have, and how the product solves it in their terms. See references/agentbundle-layout.md for artifact path.

Output rendering

Rationale / narrative — Use short ## headings and 2–3 sentence paragraphs. Don't force narrative into a table. Key–value / one record — For a single record's fields, use an aligned key: value list, not a two-row table.

When to invoke

1. A product concept exists but has not yet been committed to engineering — PRFAQ is a pre-spec forcing function, not a post-spec documentation exercise.
2. The strategist needs to align stakeholders on a direction before engineering begins.
3. No current PRFAQ exists for this product concept — amend rather than duplicate.

Procedure

1. Elicit the product concept. Ask: "Who is the customer? What is the painful problem they have today? What does the product do differently?" Confirm all three before drafting. A PRFAQ without a clear customer and problem produces a marketing document, not a forcing function.
2. Author the press release. Structure: (a) Headline — product name and the customer benefit in one sentence; (b) Sub-headline — the key detail the headline compressed; (c) Problem — the customer's current pain in their words, not industry jargon; (d) Solution — what the product does and why it is better than existing alternatives; (e) Call to action — what the customer does next; (f) Leadership quote — one sentence that names the strategic rationale, attributed to a role (not a placeholder name).
3. Author the customer FAQ. Three to five questions a real customer would ask before adopting: pricing, switching cost, reliability, comparison to the alternative they already use. Answer each honestly, including trade-offs.
4. Author the internal FAQ. Three to five questions the engineering, design, or business team must resolve before this product can ship: the riskiest assumption, the hardest technical challenge, the customer acquisition path, the success metric.
5. Apply the quality bar. Read the press release aloud: Is it jargon-free? Is the customer benefit specific and measurable? Would a non-technical reader understand the problem and solution? If not, revise before committing.
6. Resolve the artifact path following references/agentbundle-layout.md. Surface the path, then commit prfaq.md with frontmatter type: prfaq.

Anti-patterns

• PRFAQ as a spec. The PRFAQ is not an implementation contract — it does not define API boundaries, architecture, or feature-level acceptance criteria. Those belong in frame-intent and downstream specs.
• Jargon-filled problem statements. The problem section must be written in the customer's words. "Lack of operational visibility into cross-functional dependencies" is not a customer problem; "I can't tell if my team's work is blocked by another team" is.
• Leadership quote as a placeholder. A "TBD" or "[CEO name]" quote defeats the purpose — the quote should force the author to articulate the strategic rationale clearly enough to attribute to a role.