deliberate-cli 0.2.0-beta.1.1
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/AGENTS.md +40 -0
- package/LICENSE +174 -0
- package/README.md +89 -0
- package/package.json +51 -0
- package/roles/analyst/frame/instructions.md +88 -0
- package/roles/analyst/frame/output-template.md +52 -0
- package/roles/analyst/launch/instructions.md +63 -0
- package/roles/analyst/launch/output-template.md +50 -0
- package/roles/analyst/one-pager/instructions.md +75 -0
- package/roles/analyst/one-pager/output-template.md +38 -0
- package/roles/analyst/shape/instructions.md +63 -0
- package/roles/analyst/shape/output-template.md +52 -0
- package/roles/briefer/brief/instructions.md +77 -0
- package/roles/briefer/brief/output-template.md +37 -0
- package/roles/config.yaml +130 -0
- package/roles/evaluator/score/instructions.md +84 -0
- package/roles/evaluator/score/output-template.md +11 -0
- package/roles/initiator/init/instructions.md +111 -0
- package/roles/initiator/init/output-template-competitors.md +16 -0
- package/roles/initiator/init/output-template-ecosystem.md +19 -0
- package/roles/initiator/init/output-template-product.md +136 -0
- package/roles/prototyper/prototype/instructions.md +146 -0
- package/roles/prototyper/prototype/output-template.md +10 -0
- package/roles/reporter/readout/instructions.md +54 -0
- package/roles/reporter/readout/output-template.md +37 -0
- package/roles/scout/matchup/instructions.md +74 -0
- package/roles/scout/matchup/output-template.md +115 -0
- package/roles/skills/README.md +19 -0
- package/roles/skills/critique.md +64 -0
- package/roles/skills/head-to-head.md +88 -0
- package/roles/skills/jtbd.md +43 -0
- package/roles/skills/landscape-scan.md +77 -0
- package/roles/skills/metrics.md +58 -0
- package/roles/skills/positioning.md +44 -0
- package/roles/skills/prioritization.md +101 -0
- package/roles/skills/product-readout.md +98 -0
- package/roles/skills/tech-constraints.md +27 -0
- package/roles/skills/ux-principles.md +24 -0
- package/roles/skills/win-conditions.md +68 -0
- package/skill/SKILL.md +231 -0
- package/skill/scripts/deliberate.mjs +44 -0
- package/src/cli/deliberate.mjs +628 -0
- package/src/engine/app-boot.mjs +17 -0
- package/src/engine/briefs.mjs +101 -0
- package/src/engine/cases.mjs +17 -0
- package/src/engine/commands.mjs +75 -0
- package/src/engine/init.mjs +34 -0
- package/src/engine/layout.mjs +37 -0
- package/src/engine/log.mjs +22 -0
- package/src/engine/matchups.mjs +87 -0
- package/src/engine/onepager.mjs +51 -0
- package/src/engine/pipeline.mjs +134 -0
- package/src/engine/projects.mjs +17 -0
- package/src/engine/prompts.mjs +28 -0
- package/src/engine/prototype.mjs +86 -0
- package/src/engine/readout-charts.mjs +217 -0
- package/src/engine/readouts.mjs +132 -0
- package/src/engine/roles.mjs +137 -0
- package/src/engine/scaffold.mjs +54 -0
- package/src/engine/score.mjs +66 -0
- package/src/engine/service.mjs +18 -0
package/AGENTS.md
ADDED
|
@@ -0,0 +1,40 @@
|
|
|
1
|
+
# Repository guidance for AI agents
|
|
2
|
+
|
|
3
|
+
This repo implements **Deliberate** — a local, files-first product toolkit for product managers, founders, business development, marketing, and adjacent roles. It ships primarily as a **`/deliberate` skill** for coding-agent harnesses; the host produces Cases, briefs, product readouts, matchups, context, prototypes, and reviewable records in-session. Sonorance is the stable app/platform and agent-review workbench Deliberate runs on; Deliberate contributes capabilities additively and never replaces or rebrands it.
|
|
4
|
+
|
|
5
|
+
## Golden rules
|
|
6
|
+
- **Ground every claim.** Each conclusion must trace to the case, the attached sources, the project context (`deliberate/context/product.md`), or an explicit assumption labelled as such. Never invent demand, personas, competitors, or distribution channels.
|
|
7
|
+
- **Stay in scope.** Use the **skills** (reusable method/craft) and the **project context** (from `deliberate/context/product.md`) injected into your prompt before producing anything. Respect the project's non-goals and objective.
|
|
8
|
+
- **Append, don't overwrite.** Each stage appends its artifact to the case's accumulated context (the running record of everything prior). Do not contradict earlier stages without flagging it explicitly.
|
|
9
|
+
- **Be concise and structured.** Output the exact sections your stage's instruction file specifies — nothing more.
|
|
10
|
+
- **Fill the template; never echo its instructions.** Output templates describe each section with _italic guidance between underscores_ and parentheticals — these are instructions **to you**, not content. Replace every one with your real, grounded content: keep the section **headings** and fill in the tables, but **never reproduce the italic guidance, placeholder, or any `_…_` prompt text in your output**, and don't add a grounding / assumptions / notes section the template didn't ask for.
|
|
11
|
+
- **Outputs are end-user deliverables — never talk about the run.** The artifact is a finished document a customer reads. **Never** include commentary about your own execution, the task/instructions, the pipeline, tools, sessions, or previous responses (e.g. "the artifact was already produced in my previous response", "the task was to…", "as an AI…", "no further action needed"). Output only the deliverable content itself.
|
|
12
|
+
- **Do your stage's job objectively.** Each role analyzes thoroughly and without prejudging worth — the Analyst frames the problem and designs the concept + its go-to-market; the Evaluator scores. **Only Score (the Evaluator) scores go/no-go.** Don't kill, shelve, or hedge a case because it might be weak; that decision isn't yours.
|
|
13
|
+
- **Curate signal, not inventories.** Init discovers sources section by section and prefers a few authoritative inputs over noisy coverage. Ecosystem dependencies are strategic players whose changes could affect product or business decisions, never a dump of package manifests.
|
|
14
|
+
- **Hand off with a concrete CTA.** Every substantive workflow ends by explaining the most valuable next action and asking for it through the harness's native confirmation UI: init → brief, brief/readout → recommended Cases, Case → prototype, prototype/address → review, matchup → brief.
|
|
15
|
+
|
|
16
|
+
## Roles, stages & skills (how they're tied together)
|
|
17
|
+
Each part's method lives under `roles/<role>/<part>/instructions.md` + `output-template.md` (+ `skills`), organized by role — `roles/analyst/` (frame, shape, launch, one-pager), `roles/evaluator/` (score), `roles/prototyper/` (prototype) — with the reusable skills in `roles/skills/`. There are **three Case roles**: the **Analyst** — the host, in-session — writes the complete funnel `frame` (problem + competitive landscape) → `shape` (concept + step-level, surface-native journeys) → `launch` (go-to-market); the **Evaluator** judges that finished analysis, preferably as an isolated cross-vendor sub-agent; the **Prototyper** builds `prototype` on request. **The funnel is just `frame → shape → launch`**; Score is not an early-kill gate. The **score** and **prototype** are recomputable companions, not funnel stages. Host-run parts carry no model in `roles/config.yaml`; only `score` configures a target model.
|
|
18
|
+
|
|
19
|
+
**Beyond the per-case funnel, a fourth role — the Briefer (`brief`)** — produces a project-scoped **landscape brief** (`/deliberate brief`): the competitive + market changes **since the last brief**, capped at 3 months (a first-ever or stale brief → a full 3-month window). It is **not a case** and not a funnel stage (no score, no prototype): one host-run pass writes a single Markdown report to `deliberate/briefs/<YYYY-MM-DD>/brief.md`, applying the `landscape-scan` skill (timeframe discipline, mandatory source links, hard filtering to executive-worthy signal, then Action items for the project). Its method lives under `roles/briefer/brief/` and is bound like the host-run parts (no model). Never re-report a change a prior brief already covered; ground every highlight in a dated source inside the window.
|
|
20
|
+
|
|
21
|
+
**A fifth role — the Reporter (`readout`)** — produces a project-scoped **product readout** (`/deliberate readout [period]`): the key metrics, customer evidence, material insights, and warranted actions from the project's configured sources. One completed reporting period grounds the entire report; the default is the previous completed Monday–Sunday calendar week under the cadence/alignment/timezone stored in `product.md`, and a user may override one run with a completed period such as June or Q2. Every metric uses that report-level period and the immediately preceding equivalent completed period, so the table does not repeat dates per row. Data from the period currently in progress is excluded rather than projected or compared as complete. When a decision-relevant metric has enough comparable history, the Reporter may add one of up to three deterministic SVG trend charts under `charts/`; charts supplement the exact table values and never smooth, interpolate, forecast, or display targets. It is **not a case** and not a funnel stage: each host-run pass creates `deliberate/readouts/<YYYY-MM-DD[-N]>/readout.md`, keeping same-day runs as separate time-series artifacts. Its method lives under `roles/reporter/readout/`. Distinguish observations, context, hypotheses, and causal evidence; use exact representative feedback quotes only when source/date/prevalence and privacy-safe attribution are available; surface unavailable or contradictory evidence under Data gaps rather than filling it in.
|
|
22
|
+
|
|
23
|
+
**A sixth role — the Scout (`matchup`)** — produces a project-scoped, single-competitor **head-to-head** (`/deliberate matchup <competitor>`): a grounded teardown of us vs. one named rival across gaps, strengths/weaknesses, UX & user journey, supported scenarios, positioning, target JTBD, and partnership/reuse opportunities — deck-ready. Unlike the date-keyed brief, a matchup is **competitor-keyed and refresh-in-place**: one host-run pass writes a single Markdown report to `deliberate/matchups/<competitor-slug>/matchup.md`, and re-running it for the same competitor **overwrites in place** (keeping the id + created-at, updating the `as_of` timestamp). It carries an `as_of` in frontmatter **and** an "As of <date>." line in the body (so a point-in-time read survives even when metadata isn't rendered). It is **not a case** and not a funnel stage (no score, no prototype), applying the `head-to-head` skill (comparison framework, mandatory source links, executive-worthy signal). Its method lives under `roles/scout/matchup/` and is bound like the host-run parts (no model). Ground every claim in a dated source; keep it to one rival per report.
|
|
24
|
+
|
|
25
|
+
**Each stage's method is bound in `roles/config.yaml`, not loaded globally.** That file maps each stage to its `instructions` path, output `templates`, a `skills` list, and — for `score` only — a target `model` + tuning knobs. The engine reads and validates it on every invocation and injects only those skill files. Malformed YAML, unknown stages, incomplete bindings, and missing referenced files are hard failures; never add a silent fallback that can produce a plausible but methodologically wrong prompt. The `score` Evaluator carries the `critique` skill and flags ungrounded claims; isolation/provenance comes from how the harness actually runs and saves it, not from configuration alone.
|
|
26
|
+
|
|
27
|
+
**Auxiliary work is done by the HOST, not engine agents.** There are no `title`, `describe`, or `contextualize` model agents anymore. The **project context** lives as host-written **markdown** in `deliberate/context/product.md` (overview, value proposition & positioning, personas, jobs-to-be-done, interfaces, competitors, ecosystem, market, business model & pricing, distribution & channels, customer voice, metrics & traction, strategy, objective, non-goals — lists for enumerations; scaffold in `roles/initiator/init/output-template-product.md`) plus `deliberate/context/competitors.md` and `deliberate/context/ecosystem.md`. Init idempotently adds a root README section linking `deliberate/context/` and telling agent harnesses to read it before product, strategy, market, positioning, or implementation work. Metrics & traction owns the shared readout cadence/timezone and durable metric semantics rather than mutable values. The host never fabricates a section it can't ground. During `/deliberate init`, source discovery is section-led across product/strategy, code/delivery, metrics/data, customer voice, and go-to-market; it targets at least three high-signal sources per section when they genuinely exist, accepts fewer authoritative sources, and never pads with noise. Every discovered candidate is shown as `- <location> - <description>` before approval. Public product-owned GitHub repositories contribute their enabled Issues pages to Customer voice. Ecosystem dependency manifests are evidence only; ordinary libraries and transitive packages stay out of the strategic roster. The **case title** is likewise the host's job.
|
|
28
|
+
|
|
29
|
+
Case references may use a full id or a unique prefix. Never guess when a prefix matches multiple cases: the CLI rejects ambiguity so an agent cannot persist output into an arbitrary record. Project-required commands resolve only the initialized current working directory; they must fail rather than mutate another globally selected vault. Likewise, comment bridge transport/server errors are command failures, never success-shaped empty queues.
|
|
30
|
+
|
|
31
|
+
Score provenance must be literal, not aspirational. The model printed by `case score prompt` is the target; `case score save` receives the actual evaluator model. Pass `--independent` only when an isolated evaluator produced the artifact. If the harness must score inline, omit `--independent`; `score.md` will visibly label the same-session fallback and telemetry will record the content-free guardrail.
|
|
32
|
+
|
|
33
|
+
## Human gates
|
|
34
|
+
The pipeline stops after the analysis (`launch`); Prototype does not auto-start. Do not attempt to build the prototype without the human asking for it. In the coding-agent flow the harness asks *"Build the prototype now?"* (default yes) and only builds on approval — or the human runs `/deliberate case <id> prototype`.
|
|
35
|
+
|
|
36
|
+
## Execution model (host-driven; the engine runs no model)
|
|
37
|
+
Every stage is driven by the coding-agent **harness**, not the engine: create the case → `prompt <stage>` → the host produces the artifact → `save <stage>`. The engine is **LLM-free** — there is no headless run, background scheduler, or auto-resume. Keep Prototype's human ask and never add engine-side auto-advance. Sonorance is the existing local app for reviewing and addressing the resulting files; it does not run the workflow.
|
|
38
|
+
|
|
39
|
+
## State & memory
|
|
40
|
+
A run's records live in the initialized current repo as **plain Markdown/JSON — no database**. Its `deliberate/` folder holds `context/` (`product.md` + `competitors.md` + `ecosystem.md`) plus `cases/<YYYY-MM-DD-slug>/`. A Case is just a prompt, not its own file; the durable combined record is **`analysis.md`** with the title, summary, Key highlights, and one clean section per stage. Each prototype is a `prototype/[<surface>/]index.html` sidecar; **`score.md`** records `evaluator_model` and `evaluator_independent` and visibly labels a same-session fallback; **`one-pager.md`** contains the internal reverse PR-FAQ; `log.jsonl` holds the run log. Within a run, each stage sees the accumulated Case context plus the read-only project context.
|
package/LICENSE
ADDED
|
@@ -0,0 +1,174 @@
|
|
|
1
|
+
Apache License
|
|
2
|
+
Version 2.0, January 2004
|
|
3
|
+
http://www.apache.org/licenses/
|
|
4
|
+
|
|
5
|
+
TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION
|
|
6
|
+
|
|
7
|
+
1. Definitions.
|
|
8
|
+
|
|
9
|
+
"License" shall mean the terms and conditions for use, reproduction,
|
|
10
|
+
and distribution as defined by Sections 1 through 9 of this document.
|
|
11
|
+
|
|
12
|
+
"Licensor" shall mean the copyright owner or entity authorized by
|
|
13
|
+
the copyright owner that is granting the License.
|
|
14
|
+
|
|
15
|
+
"Legal Entity" shall mean the union of the acting entity and all
|
|
16
|
+
other entities that control, are controlled by, or are under common
|
|
17
|
+
control with that entity. For the purposes of this definition,
|
|
18
|
+
"control" means (i) the power, direct or indirect, to cause the
|
|
19
|
+
direction or management of such entity, whether by contract or
|
|
20
|
+
otherwise, or (ii) ownership of fifty percent (50%) or more of the
|
|
21
|
+
outstanding shares, or (iii) beneficial ownership of such entity.
|
|
22
|
+
|
|
23
|
+
"You" (or "Your") shall mean an individual or Legal Entity
|
|
24
|
+
exercising permissions granted by this License.
|
|
25
|
+
|
|
26
|
+
"Source" form shall mean the preferred form for making modifications,
|
|
27
|
+
including but not limited to software source code, documentation
|
|
28
|
+
source, and configuration files.
|
|
29
|
+
|
|
30
|
+
"Object" form shall mean any form resulting from mechanical
|
|
31
|
+
transformation or translation of a Source form, including but
|
|
32
|
+
not limited to compiled object code, generated documentation,
|
|
33
|
+
and conversions to other media types.
|
|
34
|
+
|
|
35
|
+
"Work" shall mean the work of authorship, whether in Source or
|
|
36
|
+
Object form, made available under the License, as indicated by a
|
|
37
|
+
copyright notice that is included in or attached to the work.
|
|
38
|
+
|
|
39
|
+
"Derivative Works" shall mean any work, whether in Source or Object
|
|
40
|
+
form, that is based on (or derived from) the Work and for which the
|
|
41
|
+
editorial revisions, annotations, elaborations, or other modifications
|
|
42
|
+
represent, as a whole, an original work of authorship. For the purposes
|
|
43
|
+
of this License, Derivative Works shall not include works that remain
|
|
44
|
+
separable from, or merely link (or bind by name) to the interfaces of,
|
|
45
|
+
the Work and Derivative Works thereof.
|
|
46
|
+
|
|
47
|
+
"Contribution" shall mean any work of authorship, including
|
|
48
|
+
the original version of the Work and any modifications or additions
|
|
49
|
+
to that Work or Derivative Works thereof, that is intentionally
|
|
50
|
+
submitted to Licensor for inclusion in the Work by the copyright owner
|
|
51
|
+
or by an individual or Legal Entity authorized to submit on behalf of
|
|
52
|
+
the copyright owner. For the purposes of this definition, "submitted"
|
|
53
|
+
means any form of electronic, verbal, or written communication sent
|
|
54
|
+
to the Licensor or its representatives, including but not limited to
|
|
55
|
+
communication on electronic mailing lists, source code control systems,
|
|
56
|
+
and issue tracking systems that are managed by, or on behalf of, the
|
|
57
|
+
Licensor for the purpose of discussing and improving the Work, but
|
|
58
|
+
excluding communication that is conspicuously marked or otherwise
|
|
59
|
+
designated in writing by the copyright owner as "Not a Contribution."
|
|
60
|
+
|
|
61
|
+
"Contributor" shall mean Licensor and any individual or Legal Entity
|
|
62
|
+
on behalf of whom a Contribution has been received by Licensor and
|
|
63
|
+
subsequently incorporated within the Work.
|
|
64
|
+
|
|
65
|
+
2. Grant of Copyright License. Subject to the terms and conditions of
|
|
66
|
+
this License, each Contributor hereby grants to You a perpetual,
|
|
67
|
+
worldwide, non-exclusive, no-charge, royalty-free, irrevocable
|
|
68
|
+
copyright license to reproduce, prepare Derivative Works of,
|
|
69
|
+
publicly display, publicly perform, sublicense, and distribute the
|
|
70
|
+
Work and such Derivative Works in Source or Object form.
|
|
71
|
+
|
|
72
|
+
3. Grant of Patent License. Subject to the terms and conditions of
|
|
73
|
+
this License, each Contributor hereby grants to You a perpetual,
|
|
74
|
+
worldwide, non-exclusive, no-charge, royalty-free, irrevocable
|
|
75
|
+
(except as stated in this section) patent license to make, have made,
|
|
76
|
+
use, offer to sell, sell, import, and otherwise transfer the Work,
|
|
77
|
+
where such license applies only to those patent claims licensable
|
|
78
|
+
by such Contributor that are necessarily infringed by their
|
|
79
|
+
Contribution(s) alone or by combination of their Contribution(s)
|
|
80
|
+
with the Work to which such Contribution(s) was submitted. If You
|
|
81
|
+
institute patent litigation against any entity (including a
|
|
82
|
+
cross-claim or counterclaim in a lawsuit) alleging that the Work
|
|
83
|
+
or a Contribution incorporated within the Work constitutes direct
|
|
84
|
+
or contributory patent infringement, then any patent licenses
|
|
85
|
+
granted to You under this License for that Work shall terminate
|
|
86
|
+
as of the date such litigation is filed.
|
|
87
|
+
|
|
88
|
+
4. Redistribution. You may reproduce and distribute copies of the
|
|
89
|
+
Work or Derivative Works thereof in any medium, with or without
|
|
90
|
+
modifications, and in Source or Object form, provided that You
|
|
91
|
+
meet the following conditions:
|
|
92
|
+
|
|
93
|
+
(a) You must give any other recipients of the Work or
|
|
94
|
+
Derivative Works a copy of this License; and
|
|
95
|
+
|
|
96
|
+
(b) You must cause any modified files to carry prominent notices
|
|
97
|
+
stating that You changed the files; and
|
|
98
|
+
|
|
99
|
+
(c) You must retain, in the Source form of any Derivative Works
|
|
100
|
+
that You distribute, all copyright, patent, trademark, and
|
|
101
|
+
attribution notices from the Source form of the Work,
|
|
102
|
+
excluding those notices that do not pertain to any part of
|
|
103
|
+
the Derivative Works; and
|
|
104
|
+
|
|
105
|
+
(d) If the Work includes a "NOTICE" text file as part of its
|
|
106
|
+
distribution, then any Derivative Works that You distribute must
|
|
107
|
+
include a readable copy of the attribution notices contained
|
|
108
|
+
within such NOTICE file, excluding those notices that do not
|
|
109
|
+
pertain to any part of the Derivative Works, in at least one
|
|
110
|
+
of the following places: within a NOTICE text file distributed
|
|
111
|
+
as part of the Derivative Works; within the Source form or
|
|
112
|
+
documentation, if provided along with the Derivative Works; or,
|
|
113
|
+
within a display generated by the Derivative Works, if and
|
|
114
|
+
wherever such third-party notices normally appear. The contents
|
|
115
|
+
of the NOTICE file are for informational purposes only and do not
|
|
116
|
+
modify the License. You may add Your own attribution notices
|
|
117
|
+
within Derivative Works, alongside or as an addendum to the NOTICE
|
|
118
|
+
text from the Work, provided that such additional attribution
|
|
119
|
+
notices cannot be construed as modifying the License.
|
|
120
|
+
|
|
121
|
+
You may add Your own copyright statement to Your modifications and
|
|
122
|
+
may provide additional or different license terms and conditions
|
|
123
|
+
for use, reproduction, or distribution of Your modifications, or for
|
|
124
|
+
any such Derivative Works as a whole, provided Your use, reproduction,
|
|
125
|
+
and distribution of the Work otherwise complies with the conditions
|
|
126
|
+
stated in this License.
|
|
127
|
+
|
|
128
|
+
5. Submission of Contributions. Unless You explicitly state otherwise,
|
|
129
|
+
any Contribution intentionally submitted for inclusion in the Work
|
|
130
|
+
by You to the Licensor shall be under the terms and conditions of
|
|
131
|
+
this License, without any additional terms or conditions.
|
|
132
|
+
Notwithstanding the above, nothing herein shall supersede or modify
|
|
133
|
+
the terms of any separate license agreement you may have executed
|
|
134
|
+
with Licensor regarding such Contributions.
|
|
135
|
+
|
|
136
|
+
6. Trademarks. This License does not grant permission to use the trade
|
|
137
|
+
names, trademarks, service marks, or product names of the Licensor,
|
|
138
|
+
except as required for reasonable and customary use in describing the
|
|
139
|
+
origin of the Work and reproducing the content of the NOTICE file.
|
|
140
|
+
|
|
141
|
+
7. Disclaimer of Warranty. Unless required by applicable law or
|
|
142
|
+
agreed to in writing, Licensor provides the Work (and each
|
|
143
|
+
Contributor provides its Contributions) on an "AS IS" BASIS,
|
|
144
|
+
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
|
|
145
|
+
implied, including, without limitation, any warranties or conditions
|
|
146
|
+
of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A
|
|
147
|
+
PARTICULAR PURPOSE. You are solely responsible for determining the
|
|
148
|
+
appropriateness of using or redistributing the Work and assume any
|
|
149
|
+
risks associated with Your exercise of permissions under this License.
|
|
150
|
+
|
|
151
|
+
8. Limitation of Liability. In no event and under no legal theory,
|
|
152
|
+
whether in tort (including negligence), contract, or otherwise,
|
|
153
|
+
unless required by applicable law (such as deliberate and grossly
|
|
154
|
+
negligent acts) or agreed to in writing, shall any Contributor be
|
|
155
|
+
liable to You for damages, including any direct, indirect, special,
|
|
156
|
+
incidental, or consequential damages of any character arising as a
|
|
157
|
+
result of this License or out of the use or inability to use the
|
|
158
|
+
Work (including but not limited to damages for loss of goodwill,
|
|
159
|
+
work stoppage, computer failure or malfunction, or any and all other
|
|
160
|
+
commercial damages or losses), even if such Contributor has been
|
|
161
|
+
advised of the possibility of such damages.
|
|
162
|
+
|
|
163
|
+
9. Accepting Warranty or Additional Liability. While redistributing
|
|
164
|
+
the Work or Derivative Works thereof, You may choose to offer, and
|
|
165
|
+
charge a fee for, acceptance of support, warranty, indemnity, or
|
|
166
|
+
other liability obligations and/or rights consistent with this
|
|
167
|
+
License. However, in accepting such obligations, You may act only
|
|
168
|
+
on Your own behalf and on Your sole responsibility, not on behalf
|
|
169
|
+
of any other Contributor, and only if You agree to indemnify,
|
|
170
|
+
defend, and hold each Contributor harmless for any liability
|
|
171
|
+
incurred by, or claims asserted against, such Contributor by reason
|
|
172
|
+
of your accepting any such warranty or additional liability.
|
|
173
|
+
|
|
174
|
+
END OF TERMS AND CONDITIONS
|
package/README.md
ADDED
|
@@ -0,0 +1,89 @@
|
|
|
1
|
+
# Deliberate
|
|
2
|
+
|
|
3
|
+
Deliberate is a files-first toolkit for creating reviewable Markdown records in the current repository. The CLI builds prompts, validates role configuration, and persists artifacts; the host coding agent performs the reasoning.
|
|
4
|
+
|
|
5
|
+
## Install and run
|
|
6
|
+
|
|
7
|
+
Node.js 22.5 or newer is required.
|
|
8
|
+
|
|
9
|
+
```bash
|
|
10
|
+
npx deliberate-cli install
|
|
11
|
+
```
|
|
12
|
+
|
|
13
|
+
Use `/deliberate` in a compatible coding-agent harness. A typical first journey establishes the product and market baseline before creating a Case:
|
|
14
|
+
|
|
15
|
+
```text
|
|
16
|
+
/deliberate init
|
|
17
|
+
/deliberate brief
|
|
18
|
+
|
|
19
|
+
# Turn a grounded opportunity from the Brief into a Case.
|
|
20
|
+
/deliberate case "Opportunity surfaced by the landscape brief"
|
|
21
|
+
|
|
22
|
+
# Review the decision, then make it tangible and monitor product health.
|
|
23
|
+
/deliberate case prototype
|
|
24
|
+
/deliberate readout
|
|
25
|
+
```
|
|
26
|
+
|
|
27
|
+
Run `deliberate serve --open` to review the generated Markdown, inspect diffs, and leave anchored comments in Sonorance. Project-required commands operate only in an initialized current working directory.
|
|
28
|
+
|
|
29
|
+
## Commands
|
|
30
|
+
|
|
31
|
+
```text
|
|
32
|
+
deliberate help [--skill]
|
|
33
|
+
deliberate init
|
|
34
|
+
deliberate serve [--open] [--port <n>]
|
|
35
|
+
deliberate install [--here|--project <dir>]
|
|
36
|
+
deliberate case "<idea>"
|
|
37
|
+
deliberate case list
|
|
38
|
+
deliberate case analysis prompt|save [id] [--file <path> | --note <text>]
|
|
39
|
+
deliberate case score prompt [id]
|
|
40
|
+
deliberate case score save [id] --model <id> [--independent] [--file <path>]
|
|
41
|
+
deliberate case one-pager prompt|save [id] [--file <path>]
|
|
42
|
+
deliberate case prototype prompt|save|list [id] [--surface <slug>] [--file <path>]
|
|
43
|
+
deliberate brief prompt|save|list
|
|
44
|
+
deliberate readout prompt|save|list
|
|
45
|
+
deliberate readout chart --spec <json> --output <svg>
|
|
46
|
+
deliberate matchup prompt|save|list [competitor]
|
|
47
|
+
deliberate source [list | add <location> ["<description>"] [--section <section>] | remove <location>]
|
|
48
|
+
deliberate feedback ["<message>"] [--category <category>] [--rating <rating>] [--file <json>]
|
|
49
|
+
deliberate comment list
|
|
50
|
+
deliberate comment <commentId> resolve [--note "<text>"] [--revised]
|
|
51
|
+
```
|
|
52
|
+
|
|
53
|
+
Run `deliberate help --skill` for generated, current command guidance.
|
|
54
|
+
|
|
55
|
+
## Files
|
|
56
|
+
|
|
57
|
+
```text
|
|
58
|
+
.sonorance/
|
|
59
|
+
config.json
|
|
60
|
+
plugins.json
|
|
61
|
+
sources.md
|
|
62
|
+
local/
|
|
63
|
+
deliberate/
|
|
64
|
+
context/
|
|
65
|
+
product.md
|
|
66
|
+
competitors.md
|
|
67
|
+
ecosystem.md
|
|
68
|
+
cases/<YYYY-MM-DD-slug>/
|
|
69
|
+
analysis.md
|
|
70
|
+
score.md
|
|
71
|
+
one-pager.md
|
|
72
|
+
prototype/[<surface>/]index.html
|
|
73
|
+
log.jsonl
|
|
74
|
+
briefs/<YYYY-MM-DD>/brief.md
|
|
75
|
+
readouts/<YYYY-MM-DD[-N]>/
|
|
76
|
+
readout.md
|
|
77
|
+
charts/<metric>.svg
|
|
78
|
+
matchups/<competitor-slug>/matchup.md
|
|
79
|
+
```
|
|
80
|
+
|
|
81
|
+
## Repository map
|
|
82
|
+
|
|
83
|
+
```text
|
|
84
|
+
src/engine/ prompt builders, persistence, role configuration, and commands
|
|
85
|
+
src/cli/ the deliberate binary
|
|
86
|
+
roles/ generic instructions, templates, and methods
|
|
87
|
+
skill/ the shipped /deliberate skill and launcher
|
|
88
|
+
test/ offline engine, CLI, contract, and skill tests
|
|
89
|
+
```
|
package/package.json
ADDED
|
@@ -0,0 +1,51 @@
|
|
|
1
|
+
{
|
|
2
|
+
"name": "deliberate-cli",
|
|
3
|
+
"version": "0.2.0-beta.1.1",
|
|
4
|
+
"type": "module",
|
|
5
|
+
"description": "Deliberate — a files-first product toolkit for coding agents that creates grounded, reviewable Markdown cases, briefs, readouts, matchups, and prototypes.",
|
|
6
|
+
"author": {
|
|
7
|
+
"name": "Deliberate"
|
|
8
|
+
},
|
|
9
|
+
"license": "Apache-2.0",
|
|
10
|
+
"repository": {
|
|
11
|
+
"type": "git",
|
|
12
|
+
"url": "git+https://github.com/Sonorance/deliberate.git"
|
|
13
|
+
},
|
|
14
|
+
"homepage": "https://deliberate.md",
|
|
15
|
+
"bugs": {
|
|
16
|
+
"url": "https://github.com/Sonorance/deliberate/issues"
|
|
17
|
+
},
|
|
18
|
+
"bin": {
|
|
19
|
+
"deliberate-cli": "src/cli/deliberate.mjs",
|
|
20
|
+
"deliberate": "src/cli/deliberate.mjs",
|
|
21
|
+
"dlb": "src/cli/deliberate.mjs"
|
|
22
|
+
},
|
|
23
|
+
"scripts": {
|
|
24
|
+
"deliberate": "node src/cli/deliberate.mjs",
|
|
25
|
+
"app": "node src/cli/deliberate.mjs serve --open",
|
|
26
|
+
"test": "node --test --test-force-exit --import ./test-setup.mjs"
|
|
27
|
+
},
|
|
28
|
+
"engines": {
|
|
29
|
+
"node": ">=22.5.0"
|
|
30
|
+
},
|
|
31
|
+
"dependencies": {
|
|
32
|
+
"sonorance": "^0.1.0",
|
|
33
|
+
"vega": "^6.2.0",
|
|
34
|
+
"vega-lite": "^6.4.3"
|
|
35
|
+
},
|
|
36
|
+
"files": [
|
|
37
|
+
"src/engine",
|
|
38
|
+
"src/cli",
|
|
39
|
+
"roles",
|
|
40
|
+
"skill",
|
|
41
|
+
"AGENTS.md",
|
|
42
|
+
"README.md",
|
|
43
|
+
"LICENSE"
|
|
44
|
+
],
|
|
45
|
+
"publishConfig": {
|
|
46
|
+
"access": "public"
|
|
47
|
+
},
|
|
48
|
+
"devDependencies": {
|
|
49
|
+
"js-yaml": "^4.1.0"
|
|
50
|
+
}
|
|
51
|
+
}
|
|
@@ -0,0 +1,88 @@
|
|
|
1
|
+
---
|
|
2
|
+
agent: frame
|
|
3
|
+
role: Analyst pass 1 — frames the case into a solution-free problem (personas + jobs-to-be-done) and the competitive landscape for the specific change it proposes.
|
|
4
|
+
---
|
|
5
|
+
# Agent — Frame
|
|
6
|
+
|
|
7
|
+
You are the **Analyst**, on your **first pass**. In one coherent artifact you (a) turn the case into a
|
|
8
|
+
crisp, **solution-free problem definition** grounded in who the product actually serves, and (b) judge
|
|
9
|
+
whether today's alternatives already offer **exactly the change this case proposes**. This is the
|
|
10
|
+
problem-space groundwork the Evaluator will score next — so be honest and evidence-led, and **do not
|
|
11
|
+
design a solution yet** (that's the `shape` stage).
|
|
12
|
+
|
|
13
|
+
## Inputs
|
|
14
|
+
- The **case** — the incoming problem, especially the `## Case` section. It is the subject of your
|
|
15
|
+
analysis; keep it central to every persona, job, and competitor row.
|
|
16
|
+
- The **attached project sources** (the read-only repo, code, docs) and the auto-derived **project
|
|
17
|
+
context** (personas, jobs-to-be-done, interfaces, strategy, competitors) — your evidence base for who
|
|
18
|
+
the product serves and what the alternatives are.
|
|
19
|
+
- **`jtbd`** (the method you must apply).
|
|
20
|
+
|
|
21
|
+
## Task
|
|
22
|
+
|
|
23
|
+
### Part A — the problem
|
|
24
|
+
**Infer the key personas and their jobs-to-be-done from the evidence** (the sources + the content of the
|
|
25
|
+
case) — ground each; never invent a persona or job the material doesn't support. Turn the case into a
|
|
26
|
+
crisp, **solution-free problem definition**: who is struggling, the jobs they're trying to get done, and
|
|
27
|
+
the outcomes they want. Use `jtbd` — group jobs under their persona and phrase each as a job ("I want to
|
|
28
|
+
_[job]_, so I can _[outcome]_"), with the persona line carrying the *who* and situation. Keep it tight:
|
|
29
|
+
concise personas with their key jobs, not an exhaustive JTBD workup.
|
|
30
|
+
|
|
31
|
+
Then include any **additional key personas / jobs materially affected** — secondary or adjacent users who
|
|
32
|
+
feel the ripple effects (an admin, an approver, a downstream consumer, a teammate) — grounded the same
|
|
33
|
+
way, with a note of *how* the problem touches them. Only those whose jobs are genuinely impacted.
|
|
34
|
+
|
|
35
|
+
### Part A.5 — validate the problem
|
|
36
|
+
**Show the problems above are real, not assumed.** In **~3 concise bullets (5 max)**, back the pain with
|
|
37
|
+
evidence — **quantitative** (telemetry, usage data, survey results) or **qualitative** (verbatim field /
|
|
38
|
+
sales / customer / partner quotes, each **attributed to the real person or company by name**). Every figure
|
|
39
|
+
and quote must be real and traceable to the attached sources or the project context — **never invent a
|
|
40
|
+
number, a quote, a company, or a source.** Where a problem has no real supporting evidence, say so plainly
|
|
41
|
+
(mark it an assumption) rather than fabricating one.
|
|
42
|
+
|
|
43
|
+
### Part B — the competitive landscape
|
|
44
|
+
For each competing solution a customer could reach for **to get this specific change done — as Part A
|
|
45
|
+
frames it** — answer precisely: **does it offer what the case proposes, and how?**, then its honest
|
|
46
|
+
strengths and weaknesses, **scoped to this change only**.
|
|
47
|
+
|
|
48
|
+
1. **Choose the competing solutions that matter for THIS change** — the real, named products a user could
|
|
49
|
+
actually use *instead*; **at most five, ideally fewer**. Assume the reader already knows them — don't
|
|
50
|
+
describe or pre-list them. **No "status quo / do nothing" row.** Never map broad product categories.
|
|
51
|
+
2. **Analyze them in one single table** (not per persona, not per job). Each row: does it offer what the
|
|
52
|
+
case proposes **as Part A frames it** (yes / partly / no), **how**, then strengths and weaknesses —
|
|
53
|
+
**assessing only the scope of this case's change**, never unrelated capabilities or the product's
|
|
54
|
+
overall positioning.
|
|
55
|
+
3. **Differentiation — crisp.** The defensible gap **on this specific change** in **one strong bullet
|
|
56
|
+
(two at most)**. If there is no real differentiation — it's **table-stakes** everyone already offers —
|
|
57
|
+
**say so explicitly**; that is a fine, honest answer.
|
|
58
|
+
|
|
59
|
+
## Output
|
|
60
|
+
Fill in your stage's **output template** (`roles/analyst/frame/output-template.md`), provided at runtime: the
|
|
61
|
+
**Problem** section (personas + jobs), the **Validation** section (real quant / qual evidence), and the
|
|
62
|
+
**Competitive landscape** (one Analysis table + Differentiation). Keep it tight and scoped strictly to the
|
|
63
|
+
case's change.
|
|
64
|
+
|
|
65
|
+
- **Keep persona descriptions short** — a phrase or a single crisp sentence; no biography or demographics
|
|
66
|
+
padding. The jobs carry the substance.
|
|
67
|
+
- **Grounding is internal, not a deliverable.** Do the grounding discipline in your reasoning, but **do
|
|
68
|
+
not emit a "Grounding", "Sources", "Assumptions", or "Notes" section** — the **Validation** section is
|
|
69
|
+
the one place real evidence belongs; everywhere else, surface an
|
|
70
|
+
assumption only inline, in the one place it matters, if a claim genuinely rests on one.
|
|
71
|
+
|
|
72
|
+
Produce the full version now, following every heading of the template.
|
|
73
|
+
|
|
74
|
+
## Grounding rules
|
|
75
|
+
- Every claim traces to the case or the attached sources — or is labelled an assumption **inline** (never
|
|
76
|
+
a separate notes/grounding section). **Never invent personas, jobs, competitors, features, or pricing.**
|
|
77
|
+
- **Validation must be real.** Quantitative figures cite their source; qualitative quotes are verbatim and
|
|
78
|
+
attributed to the real person / company by name. **Never fabricate a quote, a number, a company, or a
|
|
79
|
+
source** — an honest "no direct evidence yet" beats an invented one.
|
|
80
|
+
- Each job must be **solution-free** and phrased as a job (not a feature request), tied to a concrete
|
|
81
|
+
persona. **Do not propose a solution — that's `shape`. Stay on the problem.**
|
|
82
|
+
- Stay anchored to what **this case** actually proposes; assess each alternative only on *that* change —
|
|
83
|
+
not the whole product, not unrelated capabilities.
|
|
84
|
+
- Use **real, named products** as rows (at most five, ideally fewer, only those genuinely relevant); the
|
|
85
|
+
reader already knows them, so don't describe them. **No status-quo / do-nothing row. One single
|
|
86
|
+
Analysis table** — never per persona or per job.
|
|
87
|
+
- Don't score go/no-go — that's the Evaluator (`score`). Don't drift into solutioning or channels —
|
|
88
|
+
that's `shape`.
|
|
@@ -0,0 +1,52 @@
|
|
|
1
|
+
# Frame
|
|
2
|
+
|
|
3
|
+
## Problem
|
|
4
|
+
|
|
5
|
+
_Who is struggling and the jobs they're trying to get done — solution-free. One block per distinct
|
|
6
|
+
persona; keep persona lines short._
|
|
7
|
+
|
|
8
|
+
### _Persona 1_
|
|
9
|
+
|
|
10
|
+
_Who they are and their situation, in a short phrase or one crisp sentence — no biography._
|
|
11
|
+
|
|
12
|
+
* I want to _[job to be done]_, so I can _[outcome]_.
|
|
13
|
+
* I want to _[job to be done]_, so I can _[outcome]_.
|
|
14
|
+
|
|
15
|
+
_(Repeat the persona block for each distinct persona, including any adjacent persona materially affected —
|
|
16
|
+
noting how the problem touches them. No grounding, evidence, sources, or assumptions block.)_
|
|
17
|
+
|
|
18
|
+
## Validation
|
|
19
|
+
|
|
20
|
+
_Evidence that the problems above are **real**, not assumed — **quantitative** (telemetry, usage data,
|
|
21
|
+
survey results) or **qualitative** (verbatim field / sales / customer / partner quotes, each attributed to
|
|
22
|
+
the real person or company by name). **~3 concise bullets, 5 max.** Every figure and quote must be real and
|
|
23
|
+
traceable to the sources — **never invent a number, quote, company, or source**. If a problem can't be
|
|
24
|
+
grounded in real evidence, say so plainly (e.g. "no direct evidence yet — assumption") rather than
|
|
25
|
+
fabricating one._
|
|
26
|
+
|
|
27
|
+
* _a quantitative signal with its source (e.g. "38% of onboarding sessions drop at step 3 — product telemetry, Q2"), **or** a real attributed quote (e.g. "'We rebuild this by hand every release.' — Platform lead, Acme Corp") — grounded, never invented._
|
|
28
|
+
|
|
29
|
+
## Competitive landscape
|
|
30
|
+
|
|
31
|
+
_Whether today's alternatives already offer **what this case proposes — exactly as the Problem above
|
|
32
|
+
frames it** — and where the product can credibly differentiate on that specific change._
|
|
33
|
+
|
|
34
|
+
### Analysis
|
|
35
|
+
|
|
36
|
+
_A single table with **at most five rows (ideally fewer)** — the real, named products genuinely relevant
|
|
37
|
+
to **this specific change**. For each: does it offer what the case proposes, the way the Problem frames
|
|
38
|
+
it? How? Then its strengths and weaknesses — scoped to this change only, not the whole product. Assume
|
|
39
|
+
the reader already knows these products; don't describe them. No status-quo / do-nothing row._
|
|
40
|
+
|
|
41
|
+
| Competitor | Offers what the case proposes, as framed? | How | Strengths | Weaknesses / limitations |
|
|
42
|
+
|---|---|---|---|---|
|
|
43
|
+
| _…_ | _yes / partly / no_ | _…_ | _…_ | _…_ |
|
|
44
|
+
|
|
45
|
+
### Differentiation
|
|
46
|
+
|
|
47
|
+
_The defensible gap on **this specific change** in **one strong bullet — two at most**. If there is no
|
|
48
|
+
real differentiation because it's **table-stakes** everyone already offers, **say so explicitly** — that
|
|
49
|
+
is a fine, honest answer._
|
|
50
|
+
|
|
51
|
+
* _the single defensible gap on this change — or "No differentiation: this is table-stakes; the
|
|
52
|
+
alternatives already offer it."_
|
|
@@ -0,0 +1,63 @@
|
|
|
1
|
+
---
|
|
2
|
+
agent: launch
|
|
3
|
+
role: Analyst pass 3 — plans how the shaped concept reaches its first users, ships in phases, and compounds (positioning, first users, phased launch, growth, telemetry-grounded metrics).
|
|
4
|
+
---
|
|
5
|
+
# Agent — Launch
|
|
6
|
+
|
|
7
|
+
You are the **Analyst**, on your **third pass** — after you've shaped the concept and its journeys. Design
|
|
8
|
+
**how this concept reaches its first users, launches in phases, earns their trust, and compounds** —
|
|
9
|
+
grounded only in the concept you designed in `## shape` and the problem + competitive landscape in
|
|
10
|
+
`## frame`. **You do not re-judge whether the case should advance** — the Evaluator already scored it.
|
|
11
|
+
|
|
12
|
+
## Inputs
|
|
13
|
+
- The accumulated context — **anchor on the `## shape` concept + user journeys** and the `## frame`
|
|
14
|
+
personas, jobs-to-be-done, and competitive landscape. Respect the `## score` read.
|
|
15
|
+
- `jtbd`, **`win-conditions`**. The product's strategy, surface, and **non-goals** come from the project
|
|
16
|
+
context.
|
|
17
|
+
|
|
18
|
+
## Task
|
|
19
|
+
Keep it as plain and tight as the Frame and Shape — five short parts:
|
|
20
|
+
|
|
21
|
+
1. **Pitch.** The sharp value proposition — who it's for, the problem, the payoff. (Timing / "why now" is
|
|
22
|
+
**not** here — the Evaluator owns it in `## score`; don't restate it.)
|
|
23
|
+
2. **First users.** Two lines plus a follow-on: **Who** — the single, specific first customer to win (name
|
|
24
|
+
the persona) in one sentence; **Why** — their acute pain and why they're reachable / reference-able, in
|
|
25
|
+
one sentence; **Who comes next** — one sentence on whether this broadens the product's current audience
|
|
26
|
+
(and how), or, if not meaningfully, say so plainly.
|
|
27
|
+
3. **Launch plan.** Sequence the shaped concept into phases — **each grounded in a persona + job and the
|
|
28
|
+
hero journey from `## shape`** (invent no new capabilities; only phase what the concept already implies):
|
|
29
|
+
- **Phase 1 — Hero MVP:** the core shape plus the minimum capabilities that carry the **hero user
|
|
30
|
+
journey** end-to-end for the first user — enough to **validate the customer need and ship fast**. Say
|
|
31
|
+
what's in and the exact need it validates.
|
|
32
|
+
- **Phase 2 — Fast follow:** the next **necessary** capabilities that complete the experience and cover
|
|
33
|
+
the adjacent scenarios these users hit — what makes the product whole, not merely viable.
|
|
34
|
+
- **Phase 3+ — Later:** the **non-necessities** — breadth, nice-to-haves, and polish deferred until the
|
|
35
|
+
core need is validated.
|
|
36
|
+
4. **Growth.** Considering **only the functionality this case and the concept deliver** (invent no
|
|
37
|
+
new capabilities): can it strengthen a **product-led** loop — network effects, virality, referrals,
|
|
38
|
+
content, agent-of-mouth? If no/unlikely, say so in one sentence and stop. If yes, name the single most
|
|
39
|
+
likely loop: **What** — the loop and how *this feature* drives it; **How** — how to leverage it.
|
|
40
|
+
5. **Key metrics.** Every metric must be **derivable from the telemetry of the capabilities the concept
|
|
41
|
+
designed** — never an abstract win-condition.
|
|
42
|
+
- **North Star:** one metric, from the shipped feature's telemetry, that measures this case's success.
|
|
43
|
+
- **Guardrail:** one telemetry guardrail against over-optimizing the North Star.
|
|
44
|
+
- **Early signals:** at most **two** leading / proxy telemetry metrics that project where the North Star
|
|
45
|
+
is heading, each with a scale-vs-pull-back read.
|
|
46
|
+
|
|
47
|
+
## Output
|
|
48
|
+
Fill in your stage's **output template** (`roles/analyst/launch/output-template.md`), provided at runtime —
|
|
49
|
+
every section, grounded, concise. Prefer **compounding loops** and trust over one-shot reach.
|
|
50
|
+
|
|
51
|
+
Produce the full version now, following every heading of the template.
|
|
52
|
+
|
|
53
|
+
## Grounding rules
|
|
54
|
+
- **Build only on the shaped concept — invent no new capabilities.** Scope the launch phases and the
|
|
55
|
+
growth-loop section to only what the case and concept deliver; phasing is about **sequencing** that scope,
|
|
56
|
+
not adding to it.
|
|
57
|
+
- **Every phase traces to a persona + job and the hero journey** — Phase 1 is whatever carries that hero
|
|
58
|
+
journey and validates the need; later phases are ordered by necessity, not wishlist.
|
|
59
|
+
- **Do not mention win-conditions or any internal framework in the output.**
|
|
60
|
+
- Name **real, reachable** segments and channels — cite why that segment is present. Unsupported channel =
|
|
61
|
+
drop it. **Every metric must be readable from the telemetry of the capabilities the concept designs** —
|
|
62
|
+
not an abstract win-condition.
|
|
63
|
+
- Every claim traces to the context or is labelled an assumption inline (no separate notes section).
|
|
@@ -0,0 +1,50 @@
|
|
|
1
|
+
# Launch
|
|
2
|
+
|
|
3
|
+
## Pitch
|
|
4
|
+
|
|
5
|
+
* **Value proposition:** _one sharp line — who it's for, the problem, the payoff._
|
|
6
|
+
|
|
7
|
+
## First users
|
|
8
|
+
|
|
9
|
+
* **Who:** _the single, specific first customer to win (name the persona) — one concise sentence._
|
|
10
|
+
* **Why:** _their acute pain and why they're reachable / reference-able — one concise sentence._
|
|
11
|
+
* **Who comes next:** _one concise sentence — does this broaden the product's current audience (and how),
|
|
12
|
+
or, if not meaningfully, say so plainly._
|
|
13
|
+
|
|
14
|
+
## Launch plan
|
|
15
|
+
|
|
16
|
+
_Sequence the shaped concept into phases — each grounded in a persona + job and the hero journey from
|
|
17
|
+
`## shape` (invent no new capabilities; phase only what the concept already implies)._
|
|
18
|
+
|
|
19
|
+
* **Phase 1 — Hero MVP:** _the core shape + the minimum capabilities that carry the hero user journey
|
|
20
|
+
end-to-end for the first user — enough to validate the customer need and ship fast. What's in, and the
|
|
21
|
+
exact need it validates._
|
|
22
|
+
* **Phase 2 — Fast follow:** _the next necessary capabilities that complete the experience and cover the
|
|
23
|
+
adjacent scenarios these users hit — what makes it whole, not merely viable._
|
|
24
|
+
* **Phase 3+ — Later:** _the non-necessities — breadth, nice-to-haves, and polish deferred until the core
|
|
25
|
+
need is validated._
|
|
26
|
+
|
|
27
|
+
## Growth
|
|
28
|
+
|
|
29
|
+
_Using **only the functionality this case and the concept deliver** (invent no new capabilities): can it
|
|
30
|
+
strengthen a **product-led** growth loop? If no/unlikely, say so in one sentence. If yes, name the single
|
|
31
|
+
most likely one:_
|
|
32
|
+
|
|
33
|
+
* **What:** _the loop and how *this feature* drives it._
|
|
34
|
+
* **How:** _how to leverage it for growth._
|
|
35
|
+
|
|
36
|
+
## Key metrics
|
|
37
|
+
|
|
38
|
+
_All derived from the **telemetry of the capabilities the concept designs** — not abstract
|
|
39
|
+
win-conditions. If a growth loop was specified, tie these to it._
|
|
40
|
+
|
|
41
|
+
* **North Star:** _one key metric that best measures the success of this case after release, readable
|
|
42
|
+
from the shipped feature's telemetry._
|
|
43
|
+
* **Guardrail:** _one telemetry guardrail against over-optimizing the North Star._
|
|
44
|
+
|
|
45
|
+
**Early signals** — at most **two** leading / proxy telemetry metrics that project where the North Star
|
|
46
|
+
is heading:
|
|
47
|
+
|
|
48
|
+
| Signal (leading indicator of the North Star) | Scale if… | Pull back if… |
|
|
49
|
+
| --- | --- | --- |
|
|
50
|
+
| _…_ | _…_ | _…_ |
|