@skyf0xx/hedgehog 0.1.13 → 0.1.16
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/README.md +25 -22
- package/bin/cli.mjs +4 -0
- package/package.json +3 -2
- package/skills/BMAD/ATTRIBUTION.md +52 -0
- package/skills/BMAD/LICENSE +30 -0
- package/skills/BMAD/bmm-skills/1-analysis/bmad-prfaq/SKILL.md +130 -0
- package/skills/BMAD/bmm-skills/1-analysis/bmad-prfaq/agents/artifact-analyzer.md +60 -0
- package/skills/BMAD/bmm-skills/1-analysis/bmad-prfaq/agents/web-researcher.md +49 -0
- package/skills/BMAD/bmm-skills/1-analysis/bmad-prfaq/assets/prfaq-template.md +62 -0
- package/skills/BMAD/bmm-skills/1-analysis/bmad-prfaq/bmad-manifest.json +16 -0
- package/skills/BMAD/bmm-skills/1-analysis/bmad-prfaq/customize.toml +41 -0
- package/skills/BMAD/bmm-skills/1-analysis/bmad-prfaq/references/customer-faq.md +55 -0
- package/skills/BMAD/bmm-skills/1-analysis/bmad-prfaq/references/internal-faq.md +51 -0
- package/skills/BMAD/bmm-skills/1-analysis/bmad-prfaq/references/press-release.md +60 -0
- package/skills/BMAD/bmm-skills/1-analysis/bmad-prfaq/references/verdict.md +83 -0
- package/skills/BMAD/bmm-skills/1-analysis/bmad-product-brief/SKILL.md +95 -0
- package/skills/BMAD/bmm-skills/1-analysis/bmad-product-brief/assets/brief-template.md +41 -0
- package/skills/BMAD/bmm-skills/1-analysis/bmad-product-brief/customize.toml +101 -0
- package/skills/BMAD/bmm-skills/2-plan-workflows/bmad-prd/SKILL.md +94 -0
- package/skills/BMAD/bmm-skills/2-plan-workflows/bmad-prd/assets/headless-schemas.md +76 -0
- package/skills/BMAD/bmm-skills/2-plan-workflows/bmad-prd/assets/prd-template.md +165 -0
- package/skills/BMAD/bmm-skills/2-plan-workflows/bmad-prd/assets/prd-validation-checklist.md +135 -0
- package/skills/BMAD/bmm-skills/2-plan-workflows/bmad-prd/assets/validation-report-template.html +325 -0
- package/skills/BMAD/bmm-skills/2-plan-workflows/bmad-prd/customize.toml +149 -0
- package/skills/BMAD/bmm-skills/2-plan-workflows/bmad-prd/references/headless.md +39 -0
- package/skills/BMAD/bmm-skills/2-plan-workflows/bmad-prd/references/validate.md +97 -0
- package/skills/BMAD/bmm-skills/2-plan-workflows/bmad-ux/SKILL.md +94 -0
- package/skills/BMAD/bmm-skills/2-plan-workflows/bmad-ux/assets/color-themes.md +9 -0
- package/skills/BMAD/bmm-skills/2-plan-workflows/bmad-ux/assets/design-directions.md +9 -0
- package/skills/BMAD/bmm-skills/2-plan-workflows/bmad-ux/assets/design-example-editorial.md +158 -0
- package/skills/BMAD/bmm-skills/2-plan-workflows/bmad-ux/assets/design-example-mobile.md +93 -0
- package/skills/BMAD/bmm-skills/2-plan-workflows/bmad-ux/assets/design-example-shadcn.md +109 -0
- package/skills/BMAD/bmm-skills/2-plan-workflows/bmad-ux/assets/excalidraw-wireframe.md +19 -0
- package/skills/BMAD/bmm-skills/2-plan-workflows/bmad-ux/assets/experience-example-mobile.md +112 -0
- package/skills/BMAD/bmm-skills/2-plan-workflows/bmad-ux/assets/experience-example-shadcn.md +133 -0
- package/skills/BMAD/bmm-skills/2-plan-workflows/bmad-ux/assets/headless-schemas.md +84 -0
- package/skills/BMAD/bmm-skills/2-plan-workflows/bmad-ux/assets/key-screens.md +29 -0
- package/skills/BMAD/bmm-skills/2-plan-workflows/bmad-ux/assets/validation-report-template.html +319 -0
- package/skills/BMAD/bmm-skills/2-plan-workflows/bmad-ux/customize.toml +102 -0
- package/skills/BMAD/bmm-skills/2-plan-workflows/bmad-ux/references/creative-tools.md +19 -0
- package/skills/BMAD/bmm-skills/2-plan-workflows/bmad-ux/references/design-md-spec.md +50 -0
- package/skills/BMAD/bmm-skills/2-plan-workflows/bmad-ux/references/headless.md +37 -0
- package/skills/BMAD/bmm-skills/2-plan-workflows/bmad-ux/references/validate.md +115 -0
- package/skills/BMAD/core-skills/bmad-advanced-elicitation/SKILL.md +66 -0
- package/skills/BMAD/core-skills/bmad-advanced-elicitation/assets/methods.csv +72 -0
- package/skills/BMAD/core-skills/bmad-advanced-elicitation/customize.toml +54 -0
- package/skills/BMAD/core-skills/bmad-advanced-elicitation/scripts/pick_methods.py +233 -0
- package/skills/BMAD/core-skills/bmad-advanced-elicitation/scripts/tests/test_pick_methods.py +228 -0
- package/skills/BMAD/core-skills/bmad-brainstorming/SKILL.md +81 -0
- package/skills/BMAD/core-skills/bmad-brainstorming/assets/brain-icons.json +166 -0
- package/skills/BMAD/core-skills/bmad-brainstorming/assets/brain-methods.csv +109 -0
- package/skills/BMAD/core-skills/bmad-brainstorming/assets/brain-selector.html +328 -0
- package/skills/BMAD/core-skills/bmad-brainstorming/customize.toml +84 -0
- package/skills/BMAD/core-skills/bmad-brainstorming/references/converge.md +24 -0
- package/skills/BMAD/core-skills/bmad-brainstorming/references/finalize.md +26 -0
- package/skills/BMAD/core-skills/bmad-brainstorming/references/headless.md +54 -0
- package/skills/BMAD/core-skills/bmad-brainstorming/references/in-chat-techniques.md +18 -0
- package/skills/BMAD/core-skills/bmad-brainstorming/references/mode-autonomous.md +10 -0
- package/skills/BMAD/core-skills/bmad-brainstorming/references/mode-facilitator.md +11 -0
- package/skills/BMAD/core-skills/bmad-brainstorming/references/mode-partner.md +16 -0
- package/skills/BMAD/core-skills/bmad-brainstorming/references/resume.md +5 -0
- package/skills/BMAD/core-skills/bmad-brainstorming/scripts/brain.py +770 -0
- package/skills/BMAD/core-skills/bmad-brainstorming/scripts/tests/test_brain.py +239 -0
- package/skills/BMAD/core-skills/bmad-deep-recon/SKILL.md +82 -0
- package/skills/BMAD/core-skills/bmad-deep-recon/assets/research.template.md +18 -0
- package/skills/BMAD/core-skills/bmad-deep-recon/customize.toml +212 -0
- package/skills/BMAD/core-skills/bmad-deep-recon/references/draft.md +8 -0
- package/skills/BMAD/core-skills/bmad-deep-recon/references/finalize.md +11 -0
- package/skills/BMAD/core-skills/bmad-deep-recon/references/html-briefing.md +16 -0
- package/skills/BMAD/core-skills/bmad-deep-recon/references/lifecycle.md +11 -0
- package/skills/BMAD/core-skills/bmad-deep-recon/references/process.md +10 -0
- package/skills/BMAD/core-skills/bmad-deep-recon/references/run.md +73 -0
- package/skills/BMAD/core-skills/bmad-deep-recon/references/selection.md +13 -0
- package/skills/BMAD/core-skills/bmad-deep-recon/references/synthesis.md +16 -0
- package/skills/BMAD/core-skills/bmad-deep-recon/references/verification.md +29 -0
- package/skills/BMAD/core-skills/bmad-deep-recon/scripts/recon_kit.py +322 -0
- package/skills/BMAD/core-skills/bmad-deep-recon/scripts/tests/test_recon_kit.py +144 -0
- package/skills/BMAD/core-skills/bmad-deep-recon/types/academic-lit.md +19 -0
- package/skills/BMAD/core-skills/bmad-deep-recon/types/competitive.md +19 -0
- package/skills/BMAD/core-skills/bmad-deep-recon/types/domain.md +19 -0
- package/skills/BMAD/core-skills/bmad-deep-recon/types/market.md +19 -0
- package/skills/BMAD/core-skills/bmad-deep-recon/types/technical.md +19 -0
- package/skills/BMAD/core-skills/bmad-deep-recon/types/user-voice.md +19 -0
- package/skills/BMAD/scripts/memlog.py +224 -0
- package/skills/BMAD/scripts/resolve_customization.py +240 -0
- package/skills/BMAD/scripts/tests/test_memlog.py +306 -0
- package/src/agents/planner.md +10 -5
- package/src/skills/hedgehog-bootstrap/SKILL.md +1 -1
- package/src/skills/hedgehog-bootstrap-core/SKILL.md +1 -1
- package/src/skills/hedgehog-planning-intake/SKILL.md +7 -6
package/README.md
CHANGED
|
@@ -8,7 +8,13 @@ AI writes code faster than humans ever could, but **speed without discipline cre
|
|
|
8
8
|
|
|
9
9
|
**Build faster**, **save context**, stay aligned, and **ship** software you can still understand six months later.
|
|
10
10
|
|
|
11
|
-
|
|
11
|
+
Hedgehog pairs **BMAD's planning** with **disciplined execution**, in one workflow.
|
|
12
|
+
|
|
13
|
+
- Plan: BMAD workflow
|
|
14
|
+
- Build: Hedgehog execution discipline
|
|
15
|
+
- Ship: Quality gates and incremental loops
|
|
16
|
+
|
|
17
|
+

|
|
12
18
|
|
|
13
19
|
## Hedgehog gives AI
|
|
14
20
|
|
|
@@ -23,7 +29,7 @@ AI writes code faster than humans ever could, but **speed without discipline cre
|
|
|
23
29
|
- **Self-documenting architecture:** the codebase carries the context, not the AI
|
|
24
30
|
- **Traceable evolution:** decisions are preserved through conventional commits
|
|
25
31
|
|
|
26
|
-

|
|
27
33
|
|
|
28
34
|
## Why Hedgehog Exists
|
|
29
35
|
|
|
@@ -52,16 +58,16 @@ The build order is not something you negotiate with the AI. It is encoded into t
|
|
|
52
58
|
## The Hedgehog Loop
|
|
53
59
|
|
|
54
60
|
``` text
|
|
55
|
-
Planning intake
|
|
61
|
+
Planning intake - BMAD-METHOD's brief/PRD/UX spec, mined into scope
|
|
56
62
|
boundary + domain vocabulary (planner agent)
|
|
57
63
|
↓
|
|
58
64
|
Bootstrap (once per project)
|
|
59
65
|
↓
|
|
60
|
-
Phase A, per module
|
|
66
|
+
Phase A, per module - schema → contract → repository → service → controller
|
|
61
67
|
↓
|
|
62
68
|
Phase A closes for the module (gated: typecheck, lint, test)
|
|
63
69
|
↓
|
|
64
|
-
Phase B, per module
|
|
70
|
+
Phase B, per module - hook → UX rationale → screen
|
|
65
71
|
↓
|
|
66
72
|
Repeat for the next module or the next step
|
|
67
73
|
```
|
|
@@ -78,13 +84,13 @@ npx @skyf0xx/hedgehog init
|
|
|
78
84
|
```
|
|
79
85
|
|
|
80
86
|
Then open Claude Code and describe what you want to build. The
|
|
81
|
-
`planner` agent runs planning intake first
|
|
82
|
-
brief, PRD, and UX spec
|
|
87
|
+
`planner` agent runs planning intake first - BMAD-METHOD's brainstorming,
|
|
88
|
+
brief, PRD, and UX spec - then mines that into what's in scope and which
|
|
83
89
|
add-ons (Auth, Queue, Mobile) you need; once you confirm, it scaffolds
|
|
84
90
|
the project itself.
|
|
85
91
|
|
|
86
|
-
The core workspace
|
|
87
|
-
`apps/web`, and every enforcement file
|
|
92
|
+
The core workspace - Nx, `packages/config`, `packages/db`, `apps/api`,
|
|
93
|
+
`apps/web`, and every enforcement file - lands instantly from a
|
|
88
94
|
pre-verified template rather than being generated live; bootstrap then
|
|
89
95
|
only runs whichever add-ons planning intake determined your project needs.
|
|
90
96
|
|
|
@@ -106,7 +112,7 @@ Under the hood, it applies the practices experienced engineers rely on:
|
|
|
106
112
|
- continuous verification
|
|
107
113
|
- conventional commits
|
|
108
114
|
|
|
109
|
-
AI becomes the builder operating inside those constraints
|
|
115
|
+
AI becomes the builder operating inside those constraints - turning ideas into software without requiring you to manage every implementation detail.
|
|
110
116
|
|
|
111
117
|
## Architecture
|
|
112
118
|
|
|
@@ -136,28 +142,25 @@ Hedgehog is a package of agents and skills, built on an opinionated stack so the
|
|
|
136
142
|
|
|
137
143
|
## How Hedgehog Compares
|
|
138
144
|
|
|
139
|
-
Superpowers and BMAD both improve on raw prompting: one gives the AI good habits, the other
|
|
145
|
+
Superpowers and BMAD both improve on raw prompting: one gives the AI good habits, the other a planning process. Alone, either can still be broken by convention.
|
|
140
146
|
|
|
141
|
-
Hedgehog enforces
|
|
147
|
+
Hedgehog runs BMAD for planning, then enforces the build that follows with tooling, not convention: Nx boundaries, commit hooks, phase gates.
|
|
142
148
|
|
|
143
|
-
| | Superpowers | BMAD | Hedgehog |
|
|
149
|
+
| | Superpowers | BMAD | Hedgehog + BMAD |
|
|
144
150
|
| --- | --- | --- | --- |
|
|
145
|
-
| **What it is** | A skills library
|
|
146
|
-
| **Order comes from** | Skill instructions the agent is told to follow | Sequenced documents (brief → PRD → architecture → stories) | Tooling (Nx
|
|
147
|
-
| **Enforcement mechanism** | None. Prompted convention | None. One optional
|
|
151
|
+
| **What it is** | A skills library: brainstorm, plan, TDD, debug, review | A multi-agent planning framework: PM, Architect, Dev, QA personas | BMAD planning (brief → PRD → architecture) feeding a fixed-stack, enforced-order build |
|
|
152
|
+
| **Order comes from** | Skill instructions the agent is told to follow | Sequenced documents (brief → PRD → architecture → stories) | Tooling (Nx, lefthook, phase gate) |
|
|
153
|
+
| **Enforcement mechanism** | None. Prompted convention | None. One optional checklist between phases | Execution mechanically enforced |
|
|
148
154
|
| **Unit of work** | A task, planned in worktree-isolated steps | A story, derived from PRD and architecture docs | A module layer (schema → contract → repo → service → controller → UI) |
|
|
149
155
|
| **Stack** | Whatever the project already uses | No stack opinion | One locked stack (Nx, NestJS, Drizzle, ts-rest, Next.js) |
|
|
150
|
-
| **Context per step** | As much as the task pulls in | A full brief, PRD, and architecture doc per story | One module layer at a time
|
|
156
|
+
| **Context per step** | As much as the task pulls in | A full brief, PRD, and architecture doc per story | One module layer at a time - BMAD's docs are mined once, up front |
|
|
151
157
|
| **Finding a bug** | Search wherever the task touched | Search wherever the story touched | Search one layer, in one module, in a fixed order |
|
|
152
|
-
| **Real cost** | No safety net if the model shortcuts its own process | Documentation overhead most solo projects don't need |
|
|
158
|
+
| **Real cost** | No safety net if the model shortcuts its own process | Documentation overhead most solo projects don't need | Stack and order aren't negotiable |
|
|
153
159
|
|
|
154
160
|
## Credits
|
|
155
161
|
|
|
156
162
|
Planning intake runs on [BMAD-METHOD](https://github.com/bmad-code-org/BMAD-METHOD)
|
|
157
|
-
(`bmad-code-org/BMAD-METHOD`)
|
|
158
|
-
`skills/BMAD/` in every Hedgehog install. BMAD elicits the brief, PRD,
|
|
159
|
-
and UX spec; Hedgehog's own `planner` agent takes over from there with
|
|
160
|
-
the build discipline above.
|
|
163
|
+
(`bmad-code-org/BMAD-METHOD`) MIT-licensed.
|
|
161
164
|
|
|
162
165
|
## Support Hedgehog
|
|
163
166
|
|
package/bin/cli.mjs
CHANGED
|
@@ -36,6 +36,10 @@ const DOTFILE_RENAMES = { 'gitignore.template': '.gitignore' };
|
|
|
36
36
|
const PLAN = [
|
|
37
37
|
{ type: 'dir', from: 'src/agents', to: '.claude/agents' },
|
|
38
38
|
{ type: 'dir', from: 'src/skills', to: '.claude/skills' },
|
|
39
|
+
// The vendored BMAD-METHOD planning shelf that hedgehog-planning-intake
|
|
40
|
+
// runs — referenced by repo-root-relative path (skills/BMAD/...), so it
|
|
41
|
+
// lands there rather than under .claude/.
|
|
42
|
+
{ type: 'dir', from: 'skills/BMAD', to: 'skills/BMAD' },
|
|
39
43
|
{ type: 'file', from: 'src/templates/CLAUDE.md', to: 'CLAUDE.md' },
|
|
40
44
|
{ type: 'file', from: 'src/templates/TODO.md', to: 'TODO.md' },
|
|
41
45
|
// The pre-built, pre-verified core Nx workspace — packages/config,
|
package/package.json
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "@skyf0xx/hedgehog",
|
|
3
|
-
"version": "0.1.
|
|
3
|
+
"version": "0.1.16",
|
|
4
4
|
"description": "Install the Hedgehog build discipline (agents + skills) into a repo.",
|
|
5
5
|
"type": "module",
|
|
6
6
|
"repository": {
|
|
@@ -21,7 +21,8 @@
|
|
|
21
21
|
"src/agents",
|
|
22
22
|
"src/skills",
|
|
23
23
|
"src/templates",
|
|
24
|
-
"src/golden-core"
|
|
24
|
+
"src/golden-core",
|
|
25
|
+
"skills/BMAD"
|
|
25
26
|
],
|
|
26
27
|
"engines": {
|
|
27
28
|
"node": ">=18"
|
|
@@ -0,0 +1,52 @@
|
|
|
1
|
+
# Attribution
|
|
2
|
+
|
|
3
|
+
This directory vendors a subset of [BMAD-METHOD](https://github.com/bmad-code-org/BMAD-METHOD)
|
|
4
|
+
(`bmad-code-org/BMAD-METHOD`), MIT-licensed. See `LICENSE` in this directory
|
|
5
|
+
for the full license text.
|
|
6
|
+
|
|
7
|
+
- **Source repo:** https://github.com/bmad-code-org/BMAD-METHOD
|
|
8
|
+
- **Vendored from:** `main` branch, commit `bb45db4aa4496c69239f9c0629c290fd1b072fc9`
|
|
9
|
+
- **Vendored on:** 2026-07-23
|
|
10
|
+
- **Module:** `bmm` (BMAD Method Module)
|
|
11
|
+
|
|
12
|
+
## What's vendored
|
|
13
|
+
|
|
14
|
+
Seven skills from BMAD-METHOD's planning shelf, plus the two shared scripts
|
|
15
|
+
they depend on:
|
|
16
|
+
|
|
17
|
+
- `core-skills/bmad-brainstorming`
|
|
18
|
+
- `core-skills/bmad-advanced-elicitation`
|
|
19
|
+
- `core-skills/bmad-deep-recon`
|
|
20
|
+
- `bmm-skills/1-analysis/bmad-product-brief`
|
|
21
|
+
- `bmm-skills/1-analysis/bmad-prfaq`
|
|
22
|
+
- `bmm-skills/2-plan-workflows/bmad-prd`
|
|
23
|
+
- `bmm-skills/2-plan-workflows/bmad-ux`
|
|
24
|
+
- `scripts/memlog.py`, `scripts/resolve_customization.py` (shared utilities
|
|
25
|
+
every vendored skill calls, originally at `src/scripts/` in the source
|
|
26
|
+
repo)
|
|
27
|
+
|
|
28
|
+
Each skill directory carries its own templates, reference files, and
|
|
29
|
+
scripts as vendored, unmodified except where noted below.
|
|
30
|
+
|
|
31
|
+
## What's stripped
|
|
32
|
+
|
|
33
|
+
BMAD-METHOD's own orchestration layer is not vendored and is removed from
|
|
34
|
+
every skill file that referenced it:
|
|
35
|
+
|
|
36
|
+
- Central config resolution (`_bmad/scripts/resolve_config.py`,
|
|
37
|
+
`_bmad/config.toml`, `_bmad/bmm/config.yaml`) — replaced with trivial
|
|
38
|
+
defaults inline in each skill.
|
|
39
|
+
- `bmad-party-mode` (multi-agent roster) mentions and invocations.
|
|
40
|
+
- Chain-forward "common next skill" suggestions and `bmad-help` routing.
|
|
41
|
+
- Misroute-detection logic pointing at non-vendored BMAD skills.
|
|
42
|
+
|
|
43
|
+
`{bmad-root}` is introduced as a convention across the vendored files,
|
|
44
|
+
meaning this directory (`skills/BMAD/`) — used to address the shared
|
|
45
|
+
scripts (`{bmad-root}/scripts/memlog.py`, etc.) without reaching outside
|
|
46
|
+
this vendored tree.
|
|
47
|
+
|
|
48
|
+
## Re-vendoring
|
|
49
|
+
|
|
50
|
+
Pinned deliberately. Re-vendoring against a newer BMAD-METHOD commit is a
|
|
51
|
+
manual act: repeat the fetch against the new ref, re-apply the strip step
|
|
52
|
+
above, and update this file's pinned commit and date.
|
|
@@ -0,0 +1,30 @@
|
|
|
1
|
+
MIT License
|
|
2
|
+
|
|
3
|
+
Copyright (c) 2025 BMad Code, LLC
|
|
4
|
+
|
|
5
|
+
This project incorporates contributions from the open source community.
|
|
6
|
+
See [CONTRIBUTORS.md](CONTRIBUTORS.md) for contributor attribution.
|
|
7
|
+
|
|
8
|
+
Permission is hereby granted, free of charge, to any person obtaining a copy
|
|
9
|
+
of this software and associated documentation files (the "Software"), to deal
|
|
10
|
+
in the Software without restriction, including without limitation the rights
|
|
11
|
+
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
|
|
12
|
+
copies of the Software, and to permit persons to whom the Software is
|
|
13
|
+
furnished to do so, subject to the following conditions:
|
|
14
|
+
|
|
15
|
+
The above copyright notice and this permission notice shall be included in all
|
|
16
|
+
copies or substantial portions of the Software.
|
|
17
|
+
|
|
18
|
+
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
|
|
19
|
+
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
|
|
20
|
+
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
|
|
21
|
+
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
|
|
22
|
+
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
|
|
23
|
+
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
|
|
24
|
+
SOFTWARE.
|
|
25
|
+
|
|
26
|
+
TRADEMARK NOTICE:
|
|
27
|
+
BMad™, BMad Method™, and BMad Core™ are trademarks of BMad Code, LLC, covering all
|
|
28
|
+
casings and variations (including BMAD, bmad, BMadMethod, BMAD-METHOD, etc.). The use of
|
|
29
|
+
these trademarks in this software does not grant any rights to use the trademarks
|
|
30
|
+
for any other purpose. See [TRADEMARK.md](TRADEMARK.md) for detailed guidelines.
|
|
@@ -0,0 +1,130 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: bmad-prfaq
|
|
3
|
+
description: Working Backwards PRFAQ challenge that stress-tests a product concept customer-first. Use when the user requests to 'create a PRFAQ', 'work backwards', or 'run the PRFAQ challenge'.
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
# Working Backwards: The PRFAQ Challenge
|
|
7
|
+
|
|
8
|
+
## Overview
|
|
9
|
+
|
|
10
|
+
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.
|
|
11
|
+
|
|
12
|
+
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.
|
|
13
|
+
|
|
14
|
+
**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.
|
|
15
|
+
|
|
16
|
+
**Args:** Accepts `--headless` / `-H` for autonomous first-draft generation from provided context.
|
|
17
|
+
|
|
18
|
+
**Output:** A complete PRFAQ document + PRD distillate for downstream pipeline consumption.
|
|
19
|
+
|
|
20
|
+
**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.
|
|
21
|
+
|
|
22
|
+
## Conventions
|
|
23
|
+
|
|
24
|
+
- Bare paths (e.g. `references/press-release.md`) resolve from the skill root.
|
|
25
|
+
- `{skill-root}` resolves to this skill's installed directory (where `customize.toml` lives).
|
|
26
|
+
- `{project-root}`-prefixed paths resolve from the project working directory.
|
|
27
|
+
- `{skill-name}` resolves to the skill directory's basename.
|
|
28
|
+
- `{bmad-root}` is the vendored `skills/BMAD/` root.
|
|
29
|
+
|
|
30
|
+
## On Activation
|
|
31
|
+
|
|
32
|
+
### Step 1: Resolve the Workflow Block
|
|
33
|
+
|
|
34
|
+
Run: `uv run {bmad-root}/scripts/resolve_customization.py --skill {skill-root} --key workflow`
|
|
35
|
+
|
|
36
|
+
**If the script fails**, read `{skill-root}/customize.toml` directly and use its defaults.
|
|
37
|
+
|
|
38
|
+
### Step 2: Execute Prepend Steps
|
|
39
|
+
|
|
40
|
+
Execute each entry in `{workflow.activation_steps_prepend}` in order before proceeding.
|
|
41
|
+
|
|
42
|
+
### Step 3: Load Persistent Facts
|
|
43
|
+
|
|
44
|
+
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.
|
|
45
|
+
|
|
46
|
+
### Step 4: Resolve Context
|
|
47
|
+
|
|
48
|
+
Resolve, using sensible defaults:
|
|
49
|
+
- `{user_name}` for greeting — ask the user or omit
|
|
50
|
+
- `{communication_language}` for all communications — English
|
|
51
|
+
- `{document_output_language}` for output documents — English
|
|
52
|
+
- `{planning_artifacts}` for output location and artifact scanning
|
|
53
|
+
- `{project_knowledge}` for additional context scanning
|
|
54
|
+
|
|
55
|
+
### Step 5: Greet the User
|
|
56
|
+
|
|
57
|
+
Greet `{user_name}`, speaking in `{communication_language}`. Be warm but efficient — dream builder energy.
|
|
58
|
+
|
|
59
|
+
### Step 6: Execute Append Steps
|
|
60
|
+
|
|
61
|
+
Execute each entry in `{workflow.activation_steps_append}` in order.
|
|
62
|
+
|
|
63
|
+
Activation is complete. If `activation_steps_prepend` or `activation_steps_append` were non-empty, confirm every entry was executed in order before proceeding. Do not begin the main workflow until all activation steps have been completed.
|
|
64
|
+
|
|
65
|
+
## Pre-workflow Setup
|
|
66
|
+
|
|
67
|
+
1. **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.
|
|
68
|
+
|
|
69
|
+
2. **Mode detection:**
|
|
70
|
+
- `--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`.
|
|
71
|
+
- Default: Full interactive coaching — the gauntlet.
|
|
72
|
+
|
|
73
|
+
**Headless input schema:**
|
|
74
|
+
- **Required:** customer (specific persona), problem (concrete), stakes (why it matters), solution (concept)
|
|
75
|
+
- **Optional:** competitive context, technical constraints, team/org context, target market, existing research
|
|
76
|
+
|
|
77
|
+
**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.
|
|
78
|
+
|
|
79
|
+
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.
|
|
80
|
+
|
|
81
|
+
Then proceed to Stage 1 below.
|
|
82
|
+
|
|
83
|
+
## Stage 1: Ignition
|
|
84
|
+
|
|
85
|
+
**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.
|
|
86
|
+
|
|
87
|
+
**Customer-first enforcement:**
|
|
88
|
+
|
|
89
|
+
- If the user leads with a solution ("I want to build X"): redirect to the customer's problem. Don't let them skip the pain.
|
|
90
|
+
- If the user leads with a technology ("I want to use AI/blockchain/etc"): challenge harder. Technology is a "how", not a "why" — push them to articulate the human problem. Strip away the buzzword and ask whether anyone still cares.
|
|
91
|
+
- If the user leads with a customer problem: dig deeper into specifics — how they cope today, what they've tried, why it hasn't been solved.
|
|
92
|
+
|
|
93
|
+
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.
|
|
94
|
+
|
|
95
|
+
**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.
|
|
96
|
+
|
|
97
|
+
**Essentials to capture before progressing:**
|
|
98
|
+
- Who is the customer/user? (specific persona, not "everyone")
|
|
99
|
+
- What is their problem? (concrete and felt, not abstract)
|
|
100
|
+
- Why does this matter to them? (stakes and consequences)
|
|
101
|
+
- What's the initial concept for a solution? (even rough)
|
|
102
|
+
|
|
103
|
+
**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.
|
|
104
|
+
|
|
105
|
+
**Graceful redirect:** If after 2-3 exchanges the user can't articulate a customer or problem, don't force it. Point them upstream: `bmad-brainstorming` if they need to generate options, or `bmad-forge-idea` if they hold an idea that hasn't been pressure-tested into something sound yet.
|
|
106
|
+
|
|
107
|
+
**Contextual Gathering:** Once you understand the concept, gather external context before drafting begins.
|
|
108
|
+
|
|
109
|
+
1. **Ask about inputs:** Ask the user whether they have existing documents, research, brainstorming, or other materials to inform the PRFAQ. Collect paths for subagent scanning — do not read user-provided files yourself; that's the Artifact Analyzer's job.
|
|
110
|
+
2. **Fan out subagents in parallel:**
|
|
111
|
+
- **Artifact Analyzer** (`./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.
|
|
112
|
+
- **Web Researcher** (`./agents/web-researcher.md`) — Searches for competitive landscape, market context, and current industry data relevant to the concept. Receives the product intent summary.
|
|
113
|
+
3. **Graceful degradation:** If subagents are unavailable, scan the most relevant 1-2 documents inline and do targeted web searches directly. Never block the workflow.
|
|
114
|
+
4. **Merge findings** with what the user shared. Surface anything surprising that enriches or challenges their assumptions before proceeding.
|
|
115
|
+
|
|
116
|
+
**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.
|
|
117
|
+
|
|
118
|
+
**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.
|
|
119
|
+
|
|
120
|
+
**When you have enough to draft a press release headline**, route to `./references/press-release.md`.
|
|
121
|
+
|
|
122
|
+
## Stages
|
|
123
|
+
|
|
124
|
+
| # | Stage | Purpose | Location |
|
|
125
|
+
|---|-------|---------|----------|
|
|
126
|
+
| 1 | Ignition | Raw concept, enforce customer-first thinking | SKILL.md (above) |
|
|
127
|
+
| 2 | The Press Release | Iterative drafting with hard coaching | `./references/press-release.md` |
|
|
128
|
+
| 3 | Customer FAQ | Devil's advocate customer questions | `./references/customer-faq.md` |
|
|
129
|
+
| 4 | Internal FAQ | Skeptical stakeholder questions | `./references/internal-faq.md` |
|
|
130
|
+
| 5 | The Verdict | Synthesis, strength assessment, final output | `./references/verdict.md` |
|
|
@@ -0,0 +1,60 @@
|
|
|
1
|
+
# Artifact Analyzer
|
|
2
|
+
|
|
3
|
+
You are a research analyst. Your job is to scan project documents and extract information relevant to a product concept being stress-tested through the PRFAQ process.
|
|
4
|
+
|
|
5
|
+
## Input
|
|
6
|
+
|
|
7
|
+
You will receive:
|
|
8
|
+
- **Product intent:** A summary of the concept — customer, problem, solution direction
|
|
9
|
+
- **Scan paths:** Directories to search for relevant documents (e.g., planning artifacts, project knowledge folders)
|
|
10
|
+
- **User-provided paths:** Any specific files the user pointed to
|
|
11
|
+
|
|
12
|
+
## Process
|
|
13
|
+
|
|
14
|
+
1. **Scan the provided directories** for documents that could be relevant:
|
|
15
|
+
- Brainstorming reports (`*brainstorm*`, `*ideation*`)
|
|
16
|
+
- Research documents (`*research*`, `*analysis*`, `*findings*`)
|
|
17
|
+
- Project context (`*context*`, `*overview*`, `*background*`)
|
|
18
|
+
- Existing briefs or summaries (`*brief*`, `*summary*`)
|
|
19
|
+
- Any markdown, text, or structured documents that look relevant
|
|
20
|
+
|
|
21
|
+
2. **For sharded documents** (a folder with `index.md` and multiple files), read the index first to understand what's there, then read only the relevant parts.
|
|
22
|
+
|
|
23
|
+
3. **For very large documents** (estimated >50 pages), read the table of contents, executive summary, and section headings first. Read only sections directly relevant to the stated product intent. Note which sections were skimmed vs read fully.
|
|
24
|
+
|
|
25
|
+
4. **Read all relevant documents in parallel** — issue all Read calls in a single message rather than one at a time. Extract:
|
|
26
|
+
- Key insights that relate to the product intent
|
|
27
|
+
- Market or competitive information
|
|
28
|
+
- User research or persona information
|
|
29
|
+
- Technical context or constraints
|
|
30
|
+
- Ideas, both accepted and rejected (rejected ideas are valuable — they prevent re-proposing)
|
|
31
|
+
- Any metrics, data points, or evidence
|
|
32
|
+
|
|
33
|
+
5. **Ignore documents that aren't relevant** to the stated product intent. Don't waste tokens on unrelated content.
|
|
34
|
+
|
|
35
|
+
## Output
|
|
36
|
+
|
|
37
|
+
Return ONLY the following JSON object. No preamble, no commentary. Keep total response under 1,500 tokens. Maximum 5 bullets per section — prioritize the most impactful findings.
|
|
38
|
+
|
|
39
|
+
```json
|
|
40
|
+
{
|
|
41
|
+
"documents_found": [
|
|
42
|
+
{"path": "file path", "relevance": "one-line summary"}
|
|
43
|
+
],
|
|
44
|
+
"key_insights": [
|
|
45
|
+
"bullet — grouped by theme, each self-contained"
|
|
46
|
+
],
|
|
47
|
+
"user_market_context": [
|
|
48
|
+
"bullet — users, market, competition found in docs"
|
|
49
|
+
],
|
|
50
|
+
"technical_context": [
|
|
51
|
+
"bullet — platforms, constraints, integrations"
|
|
52
|
+
],
|
|
53
|
+
"ideas_and_decisions": [
|
|
54
|
+
{"idea": "description", "status": "accepted|rejected|open", "rationale": "brief why"}
|
|
55
|
+
],
|
|
56
|
+
"raw_detail_worth_preserving": [
|
|
57
|
+
"bullet — specific details, data points, quotes for the distillate"
|
|
58
|
+
]
|
|
59
|
+
}
|
|
60
|
+
```
|
|
@@ -0,0 +1,49 @@
|
|
|
1
|
+
# Web Researcher
|
|
2
|
+
|
|
3
|
+
You are a market research analyst. Your job is to find current, relevant competitive, market, and industry context for a product concept being stress-tested through the PRFAQ process.
|
|
4
|
+
|
|
5
|
+
## Input
|
|
6
|
+
|
|
7
|
+
You will receive:
|
|
8
|
+
- **Product intent:** A summary of the concept — customer, problem, solution direction, and the domain it operates in
|
|
9
|
+
|
|
10
|
+
## Process
|
|
11
|
+
|
|
12
|
+
1. **Identify search angles** based on the product intent:
|
|
13
|
+
- Direct competitors (products solving the same problem)
|
|
14
|
+
- Adjacent solutions (different approaches to the same pain point)
|
|
15
|
+
- Market size and trends for the domain
|
|
16
|
+
- Industry news or developments that create opportunity or risk
|
|
17
|
+
- User sentiment about existing solutions (what's frustrating people)
|
|
18
|
+
|
|
19
|
+
2. **Execute 3-5 targeted web searches** — quality over quantity. Search for:
|
|
20
|
+
- "[problem domain] solutions comparison"
|
|
21
|
+
- "[competitor names] alternatives" (if competitors are known)
|
|
22
|
+
- "[industry] market trends [current year]"
|
|
23
|
+
- "[target user type] pain points [domain]"
|
|
24
|
+
|
|
25
|
+
3. **Synthesize findings** — don't just list links. Extract the signal.
|
|
26
|
+
|
|
27
|
+
## Output
|
|
28
|
+
|
|
29
|
+
Return ONLY the following JSON object. No preamble, no commentary. Keep total response under 1,000 tokens. Maximum 5 bullets per section.
|
|
30
|
+
|
|
31
|
+
```json
|
|
32
|
+
{
|
|
33
|
+
"competitive_landscape": [
|
|
34
|
+
{"name": "competitor", "approach": "one-line description", "gaps": "where they fall short"}
|
|
35
|
+
],
|
|
36
|
+
"market_context": [
|
|
37
|
+
"bullet — market size, growth trends, relevant data points"
|
|
38
|
+
],
|
|
39
|
+
"user_sentiment": [
|
|
40
|
+
"bullet — what users say about existing solutions"
|
|
41
|
+
],
|
|
42
|
+
"timing_and_opportunity": [
|
|
43
|
+
"bullet — why now, enabling shifts"
|
|
44
|
+
],
|
|
45
|
+
"risks_and_considerations": [
|
|
46
|
+
"bullet — market risks, competitive threats, regulatory concerns"
|
|
47
|
+
]
|
|
48
|
+
}
|
|
49
|
+
```
|
|
@@ -0,0 +1,62 @@
|
|
|
1
|
+
---
|
|
2
|
+
title: "PRFAQ: {project_name}"
|
|
3
|
+
status: "{status}"
|
|
4
|
+
created: "{timestamp}"
|
|
5
|
+
updated: "{timestamp}"
|
|
6
|
+
stage: "{current_stage}"
|
|
7
|
+
inputs: []
|
|
8
|
+
---
|
|
9
|
+
|
|
10
|
+
# {Headline}
|
|
11
|
+
|
|
12
|
+
## {Subheadline — one sentence: who benefits and what changes for them}
|
|
13
|
+
|
|
14
|
+
**{City, Date}** — {Opening paragraph: announce the product/initiative, state the user's problem, and the key benefit.}
|
|
15
|
+
|
|
16
|
+
{Problem paragraph: the user's pain today. Specific, concrete, felt. No mention of the solution yet.}
|
|
17
|
+
|
|
18
|
+
{Solution paragraph: what changes for the user. Benefits, not features. Outcomes, not implementation.}
|
|
19
|
+
|
|
20
|
+
> "{Leader/founder quote — the vision beyond the feature list.}"
|
|
21
|
+
> — {Name, Title/Role}
|
|
22
|
+
|
|
23
|
+
### How It Works
|
|
24
|
+
|
|
25
|
+
{The user experience, step by step. Written from THEIR perspective. How they discover it, start using it, and get value from it.}
|
|
26
|
+
|
|
27
|
+
> "{User quote — what a real person would say after using this. Must sound human, not like marketing copy.}"
|
|
28
|
+
> — {Name, Role}
|
|
29
|
+
|
|
30
|
+
### Getting Started
|
|
31
|
+
|
|
32
|
+
{Clear, concrete path to first value. How to access, try, adopt, or contribute.}
|
|
33
|
+
|
|
34
|
+
---
|
|
35
|
+
|
|
36
|
+
## Customer FAQ
|
|
37
|
+
|
|
38
|
+
### Q: {Hardest customer question first}
|
|
39
|
+
|
|
40
|
+
A: {Honest, specific answer}
|
|
41
|
+
|
|
42
|
+
### Q: {Next question}
|
|
43
|
+
|
|
44
|
+
A: {Answer}
|
|
45
|
+
|
|
46
|
+
---
|
|
47
|
+
|
|
48
|
+
## Internal FAQ
|
|
49
|
+
|
|
50
|
+
### Q: {Hardest internal question first}
|
|
51
|
+
|
|
52
|
+
A: {Honest, specific answer}
|
|
53
|
+
|
|
54
|
+
### Q: {Next question}
|
|
55
|
+
|
|
56
|
+
A: {Answer}
|
|
57
|
+
|
|
58
|
+
---
|
|
59
|
+
|
|
60
|
+
## The Verdict
|
|
61
|
+
|
|
62
|
+
{Concept strength assessment — what's forged in steel, what needs more heat, what has cracks in the foundation.}
|
|
@@ -0,0 +1,16 @@
|
|
|
1
|
+
{
|
|
2
|
+
"module-code": "bmm",
|
|
3
|
+
"capabilities": [
|
|
4
|
+
{
|
|
5
|
+
"name": "working-backwards",
|
|
6
|
+
"menu-code": "WB",
|
|
7
|
+
"description": "Produces battle-tested PRFAQ document and optional LLM distillate for PRD input.",
|
|
8
|
+
"supports-headless": true,
|
|
9
|
+
"phase-name": "1-analysis",
|
|
10
|
+
"preceded-by": ["brainstorming", "perform-research"],
|
|
11
|
+
"followed-by": ["create-prd"],
|
|
12
|
+
"is-required": false,
|
|
13
|
+
"output-location": "{planning_artifacts}"
|
|
14
|
+
}
|
|
15
|
+
]
|
|
16
|
+
}
|
|
@@ -0,0 +1,41 @@
|
|
|
1
|
+
# DO NOT EDIT -- overwritten on every update.
|
|
2
|
+
#
|
|
3
|
+
# Workflow customization surface for bmad-prfaq. Mirrors the
|
|
4
|
+
# agent customization shape under the [workflow] namespace.
|
|
5
|
+
|
|
6
|
+
[workflow]
|
|
7
|
+
|
|
8
|
+
# --- Configurable below. Overrides merge per BMad structural rules: ---
|
|
9
|
+
# scalars: override wins • arrays (persistent_facts, activation_steps_*): append
|
|
10
|
+
# arrays-of-tables with `code`/`id`: replace matching items, append new ones.
|
|
11
|
+
|
|
12
|
+
# Steps to run before the standard activation (config load, greet).
|
|
13
|
+
# Overrides append. Use for pre-flight loads, compliance checks, etc.
|
|
14
|
+
|
|
15
|
+
activation_steps_prepend = []
|
|
16
|
+
|
|
17
|
+
# Steps to run after greet but before the workflow begins.
|
|
18
|
+
# Overrides append. Use for context-heavy setup that should happen
|
|
19
|
+
# once the user has been acknowledged.
|
|
20
|
+
|
|
21
|
+
activation_steps_append = []
|
|
22
|
+
|
|
23
|
+
# Persistent facts the workflow keeps in mind for the whole run
|
|
24
|
+
# (standards, compliance constraints, stylistic guardrails).
|
|
25
|
+
# Distinct from the runtime memory sidecar — these are static context
|
|
26
|
+
# loaded on activation. Overrides append.
|
|
27
|
+
#
|
|
28
|
+
# Each entry is either:
|
|
29
|
+
# - a literal sentence, e.g. "All briefs must include a regulatory-risk section."
|
|
30
|
+
# - a file reference prefixed with `file:`, e.g. "file:{project-root}/docs/standards.md"
|
|
31
|
+
# (glob patterns are supported; the file's contents are loaded and treated as facts).
|
|
32
|
+
|
|
33
|
+
persistent_facts = [
|
|
34
|
+
"file:{project-root}/**/project-context.md",
|
|
35
|
+
]
|
|
36
|
+
|
|
37
|
+
# Scalar: executed when the workflow reaches its terminal stage (Stage 5: The Verdict),
|
|
38
|
+
# after the PRFAQ and distillate have been delivered. Override wins. Leave empty for
|
|
39
|
+
# no custom post-completion behavior.
|
|
40
|
+
|
|
41
|
+
on_complete = ""
|
|
@@ -0,0 +1,55 @@
|
|
|
1
|
+
**Language:** Use `{communication_language}` for all output.
|
|
2
|
+
**Output Language:** Use `{document_output_language}` for documents.
|
|
3
|
+
**Output Location:** `{planning_artifacts}`
|
|
4
|
+
**Coaching stance:** Be direct, challenge vague thinking, but offer concrete alternatives when the user is stuck — tough love, not tough silence.
|
|
5
|
+
**Concept type:** Check `{concept_type}` — calibrate all question framing to match (commercial, internal tool, open-source, community/nonprofit).
|
|
6
|
+
|
|
7
|
+
# Stage 3: Customer FAQ
|
|
8
|
+
|
|
9
|
+
**Goal:** Validate the value proposition by asking the hardest questions a real user would ask — and crafting answers that hold up under scrutiny.
|
|
10
|
+
|
|
11
|
+
## The Devil's Advocate
|
|
12
|
+
|
|
13
|
+
You are now the customer. Not a friendly early-adopter — a busy, skeptical person who has been burned by promises before. You've read the press release. Now you have questions.
|
|
14
|
+
|
|
15
|
+
**Generate 6-10 customer FAQ questions** that cover these angles:
|
|
16
|
+
|
|
17
|
+
- **Skepticism:** "How is this different from [existing solution]?" / "Why should I switch from what I use today?"
|
|
18
|
+
- **Trust:** "What happens to my data?" / "What if this shuts down?" / "Who's behind this?"
|
|
19
|
+
- **Practical concerns:** "How much does it cost?" / "How long does it take to get started?" / "Does it work with [thing I already use]?"
|
|
20
|
+
- **Edge cases:** "What if I need to [uncommon but real scenario]?" / "Does it work for [adjacent use case]?"
|
|
21
|
+
- **The hard question they're afraid of:** Every product has one question the team hopes nobody asks. Find it and ask it.
|
|
22
|
+
|
|
23
|
+
**Don't generate softball questions.** "How do I sign up?" is not a FAQ — it's a CTA. Real customer FAQs are the objections standing between interest and adoption.
|
|
24
|
+
|
|
25
|
+
**Calibrate to concept type.** For non-commercial concepts (internal tools, open-source, community projects), adapt question framing: replace "cost" with "effort to adopt," replace "competitor switching" with "why change from current workflow," replace "trust/company viability" with "maintenance and sustainability."
|
|
26
|
+
|
|
27
|
+
## Coaching the Answers
|
|
28
|
+
|
|
29
|
+
Present the questions and work through answers with the user:
|
|
30
|
+
|
|
31
|
+
1. **Present all questions at once** — let the user see the full landscape of customer concern.
|
|
32
|
+
2. **Work through answers together.** The user drafts (or you draft and they react). For each answer:
|
|
33
|
+
- Is it honest? If the answer is "we don't do that yet," say so — and explain the roadmap or alternative.
|
|
34
|
+
- Is it specific? "We have enterprise-grade security" is not an answer. What certifications? What encryption? What SLA?
|
|
35
|
+
- Would a customer believe it? Marketing language in FAQ answers destroys credibility.
|
|
36
|
+
3. **If an answer reveals a real gap in the concept**, name it directly and force a decision: is this a launch blocker, a fast-follow, or an accepted trade-off?
|
|
37
|
+
4. **The user can add their own questions too.** Often they know the scary questions better than anyone.
|
|
38
|
+
|
|
39
|
+
## Headless Mode
|
|
40
|
+
|
|
41
|
+
Generate questions and best-effort answers from available context. Flag answers with low confidence so a human can review.
|
|
42
|
+
|
|
43
|
+
## Updating the Document
|
|
44
|
+
|
|
45
|
+
Append the Customer FAQ section to the output document. Update frontmatter: `status: "customer-faq"`, `stage: 3`, `updated` timestamp.
|
|
46
|
+
|
|
47
|
+
## Coaching Notes Capture
|
|
48
|
+
|
|
49
|
+
Before moving on, append a `<!-- coaching-notes-stage-3 -->` block to the output document: gaps revealed by customer questions, trade-off decisions made (launch blocker vs fast-follow vs accepted), competitive intelligence surfaced, and any scope or requirements signals.
|
|
50
|
+
|
|
51
|
+
## Stage Complete
|
|
52
|
+
|
|
53
|
+
This stage is complete when every question has an honest, specific answer — and the user has confronted the hardest customer objections their concept faces. No softballs survived.
|
|
54
|
+
|
|
55
|
+
Route to `./internal-faq.md`.
|