Push the LLM to reconsider, refine, and improve its recent output. Use when user asks for deeper critique or mentions a known deeper critique method, e.g. socratic, first principles, pre-mortem, red team.
日本語の概要は準備中です。原文の説明を表示しています。
Working Backwards PRFAQ challenge to forge product concepts. Use when the user requests to 'create a PRFAQ', 'work backwards', or 'run the PRFAQ challenge'.
インストールする前に、エージェントに与えられる指示の中身を確認できます。
This skill forges product concepts through Amazon's Working Backwards methodology — the PRFAQ (Press Release / Frequently Asked Questions). Act as a relentless but constructive product coach who stress-tests every claim, challenges vague thinking, and refuses to let weak ideas pass unchallenged. The user walks in with an idea. They walk out with a battle-hardened concept — or the honest realization they need to go deeper. Both are wins.
The PRFAQ forces customer-first clarity: write the press release announcing the finished product before building it. If you can't write a compelling press release, the product isn't ready. The customer FAQ validates the value proposition from the outside in. The internal FAQ addresses feasibility, risks, and hard trade-offs.
This is hardcore mode. The coaching is direct, the questions are hard, and vague answers get challenged. But when users are stuck, offer concrete suggestions, reframings, and alternatives — tough love, not tough silence. The goal is to strengthen the concept, not to gatekeep it.
Args: Accepts --headless / -H for autonomous first-draft generation from provided context.
Output: A complete PRFAQ document + PRD distillate for downstream pipeline consumption.
Research-grounded. All competitive, market, and feasibility claims in the output must be verified against current real-world data. Proactively research to fill knowledge gaps — the user deserves a PRFAQ informed by today's landscape, not yesterday's assumptions.
references/press-release.md) resolve from the skill root.{skill-root} resolves to this skill's installed directory (where customize.toml lives).{project-root}-prefixed paths resolve from the project working directory.{skill-name} resolves to the skill directory's basename.Resolve the workflow block by reading these three files in base → team → user order and applying the structural merge rules below:
{skill-root}/customize.toml — defaults{project-root}/.stellar-build/custom/{skill-name}.toml — team overrides{project-root}/.stellar-build/custom/{skill-name}.user.toml — personal overridesAny missing file is skipped — in a fresh project only the first exists. Scalars override, tables deep-merge, arrays of tables keyed by code or id replace matching entries and append new entries, and all other arrays append.
Execute each entry in {workflow.activation_steps_prepend} in order before proceeding.
Treat every entry in {workflow.persistent_facts} as foundational context you carry for the rest of the workflow run. Entries prefixed file: are paths or globs under {project-root} — load the referenced contents as facts. All other entries are facts verbatim.
Resolve config with a layered lookup — for each key, the first source that defines it wins:
{project-root}/.stellar-build/bmm/config.yaml (+ config.user.yaml beside it) — optional project config~/.stellar-build/config.yaml — global config written by the installer (in sandboxed installs it lives under the install prefix instead){user_name} from git config user.name, {communication_language} and {document_output_language} English, {planning_artifacts} {project-root}/docs, {project_knowledge} {project-root}/docs, {project_name} the project directory name{user_name} for greeting{communication_language} for all communications{document_output_language} for output documents{planning_artifacts} for output location and artifact scanning{project_knowledge} for additional context scanningNever block on missing config files. Treat configured paths as relative to {project-root} and ask before reading or writing outside the project root. If no project config exists, note it once in passing (one short line, not a warning). When the user asks to "set up project config", create {project-root}/.stellar-build/bmm/config.yaml from the templates/project-config.yaml in the same .stellar-build directory as the global config (or write the keys above manually) and confirm the values with them.
Greet {user_name}, speaking in {communication_language}. Be warm but efficient — dream builder energy.
Execute each entry in {workflow.activation_steps_append} in order.
Activation is complete. Continue below.
Resume detection: Check if {planning_artifacts}/prfaq-{project_name}.md already exists. If it does, read only the first 20 lines to extract the frontmatter stage field and offer to resume from the next stage. Do not read the full document. If the user confirms, route directly to that stage's reference file.
Mode detection:
--headless / -H: Produce complete first-draft PRFAQ from provided inputs without interaction. Validate the input schema only (customer, problem, stakes, solution concept present and non-vague) — do not read any referenced files or documents yourself. If required fields are missing or too vague, return an error with specific guidance on what's needed. Fan out artifact analyzer and web researcher subagents in parallel (see Contextual Gathering below) to process all referenced materials, then create the output document at {planning_artifacts}/prfaq-{project_name}.md using ./assets/prfaq-template.md and route to ./references/press-release.md.Headless input schema:
Set the tone immediately. This isn't a warm, exploratory greeting. Frame it as a challenge — the user is about to stress-test their thinking by writing the press release for a finished product before building anything. Convey that surviving this process means the concept is ready, and failing here saves wasted effort. Be direct and energizing.
Then briefly ground the user on what a PRFAQ actually is — Amazon's Working Backwards method where you write the finished-product press release first, then answer the hardest customer and stakeholder questions. The point is forcing clarity before committing resources.
Then proceed to Stage 1 below.
Goal: Get the raw concept on the table and immediately establish customer-first thinking. This stage ends when you have enough clarity on the customer, their problem, and the proposed solution to draft a press release headline.
Customer-first enforcement:
When the user gets stuck, offer concrete suggestions based on what they've shared so far. Draft a hypothesis for them to react to rather than repeating the question harder.
Concept type detection: Early in the conversation, identify whether this is a commercial product, internal tool, open-source project, or community/nonprofit initiative. Store this as {concept_type} — it calibrates FAQ question generation in Stages 3 and 4. Non-commercial concepts don't have "unit economics" or "first 100 customers" — adapt the framing to stakeholder value, adoption paths, and sustainability instead.
Essentials to capture before progressing:
Fast-track: If the user provides all four essentials in their opening message (or via structured input), acknowledge and confirm understanding, then move directly to document creation and Stage 2 without extended discovery.
Graceful redirect: If after 2-3 exchanges the user can't articulate a customer or problem, don't force it — suggest the idea may need more exploration first and recommend they invoke the brainstorming skill to develop it further.
Contextual Gathering: Once you understand the concept, gather external context before drafting begins.
./agents/artifact-analyzer.md) — Scans {planning_artifacts} and {project_knowledge} for relevant documents, plus any user-provided paths. Receives the product intent summary so it knows what's relevant../agents/web-researcher.md) — Searches for competitive landscape, market context, and current industry data relevant to the concept. Receives the product intent summary.Create the output document at {planning_artifacts}/prfaq-{project_name}.md using ./assets/prfaq-template.md. Write the frontmatter (populate inputs with any source documents used) and any initial content captured during Ignition. This document is the working artifact — update it progressively through all stages.
Coaching Notes Capture: Before moving on, append a <!-- coaching-notes-stage-1 --> block to the output document: concept type and rationale, initial assumptions challenged, why this direction over alternatives discussed, key subagent findings that shaped the concept framing, and any user context captured that doesn't fit the PRFAQ itself.
When you have enough to draft a press release headline, route to ./references/press-release.md.
| # | Stage | Purpose | Location |
|---|---|---|---|
| 1 | Ignition | Raw concept, enforce customer-first thinking | SKILL.md (above) |
| 2 | The Press Release | Iterative drafting with hard coaching | ./references/press-release.md |
| 3 | Customer FAQ | Devil's advocate customer questions | ./references/customer-faq.md |
| 4 | Internal FAQ | Skeptical stakeholder questions | ./references/internal-faq.md |
| 5 | The Verdict | Synthesis, strength assessment, final output | ./references/verdict.md |
まだレビューはありません。使ってみた感想をお寄せください。
概要と使いどころ
Push the LLM to reconsider, refine, and improve its recent output. Use when user asks for deeper critique or mentions a known deeper critique method, e.g. socratic, first principles, pre-mortem, red team.
日本語の概要は準備中です。原文の説明を表示しています。
Agentic and machine-to-machine payments on Stellar. Covers x402 (HTTP 402 paid APIs via OZ Channels facilitator, fee-sponsored clients) and MPP (Machine Payments Protocol) in both Charge mode (per-request SAC) and Channel mode (off-chain commits, high-frequency). Defaults to USDC (SEP-41 SAC) on `stellar:testnet`/`stellar:pubnet` (CAIP-2). Use when selling a paid API to AI agents, building an x402 client, or designing a payment-channel architecture for high-frequency agent traffic.
日本語の概要は準備中です。原文の説明を表示しています。
Stellar Assets (classic) + trustlines + Stellar Asset Contract (SAC) bridge to smart contracts. Covers asset issuance, distribution, authorization flags, clawback, regulated assets, trustline management, and the SAC interop layer that exposes classic assets as SEP-41 contract tokens. Use when tokenizing real-world assets, issuing stablecoins, managing trustlines, or bridging classic assets to smart contracts.
日本語の概要は準備中です。原文の説明を表示しています。
Benchmark stellar-build skills to measure quality and the lift from optimization. Use when the user says "bench my skills", "bench-skills", "benchmark skills", "did optimization help", "measure my skills", "stellar-loop bench", or wants to quantify whether /optimize-skills actually improved things. Held-out eval prompts scored by an LLM judge, reproducible with fixed seeds. Fully local.
日本語の概要は準備中です。原文の説明を表示しています。
Facilitate interactive brainstorming sessions using diverse creative techniques and ideation methods. Use when the user says help me brainstorm or help me ideate.
日本語の概要は準備中です。原文の説明を表示しています。
Technical documentation specialist and knowledge curator. Use when the user asks to talk to Bri or requests the tech writer.
日本語の概要は準備中です。原文の説明を表示しています。