mirror of
https://github.com/bmad-code-org/BMAD-METHOD.git
synced 2026-08-28 19:20:41 +08:00
feat(core): consolidate research trio into bmad-deep-recon (#2611)
* feat(bmm): consolidate research trio into bmad-deep-recon
Replace bmad-market-research, bmad-domain-research, and bmad-technical-research
(5,136 lines of near-duplicate legacy step files) with one modern skill,
bmad-deep-recon (~650 lines):
- Research-master-orchestrator persona; conclusions never rest on training
data alone; lead-following rounds with coverage/novelty-exhaustion stops
- Six type packs as ~25-line policy+craft cards (market, domain, technical,
competitive, user-voice, academic-lit) + select decision shape layering a
weighted-matrix method over any type
- Three acquisition modes: Generate (subagent fan-out), Delegate (engine
registry: CLI/MCP, engine-first strategy), Import (provenance-tracked)
- Claims-ledger verification (normal/high/max) with independence rules and
optional red-team pass; cited synthesis with staleness map
- Effort presets (quick/standard/deep) over four knobs (subagents,
sources/round, depth, validation); precedence request > knob > preset
- Plan gate with surface discovery (MCPs/CLIs/engines), routing table, and
time estimate; use_workflows and subagent_models config
- Create/Refresh/Deepen intents, memlog run-folder workspace, headless JSON
- v6 shims forward the three old IDs with type pre-set; analyst menu,
catalog, marketplace, docs and translation mirrors updated
* feat(bmm): runtime output_format for bmad-deep-recon (v7 artifact protocol)
Replace the output_formats array with output_format = auto|html|md|both
(default auto): interactive runs render the HTML briefing, headless or
skill-invoked runs present the canonical markdown only. research.md always
exists in the workspace as the machine-readable report; the briefing is its
regenerable face. First instance of the v7 artifact protocol (memlog = truth,
md = distillation under contract, html = face).
* feat(core): move bmad-deep-recon to core-skills; address review findings
Move: research is not code-project-specific — home it in core-skills
(brainstorming precedent) so CIS and core-only installs get it. Skill ID
unchanged; standalone marketplace plugin added; catalogs moved to Core;
{planning_artifacts} falls back to {output_folder} on core-only installs.
v6 shims stay in bmm-skills (the legacy trio were bmm skills).
Review fixes (CodeRabbit):
- Engine briefs are now file-based: invoke templates substitute
{brief_file} (a skill-generated path), never inline brief text — quotes
and shell metacharacters in researched content can't shape a command.
- Refresh/Deepen preserve verification statuses for out-of-scope claims.
- HTML briefing: http(s)-only source links, escape source-derived text.
- user-voice pack: redact usernames/handles/emails from verbatim quotes;
communities complement surveys (triangulate) rather than beat them.
- engine.md: explicit single-writer rule — digests return to the lead,
which alone writes research.md in plan order.
* feat(core): deep-recon v2 — draft/process/run, faster defaults, research firewall
Rework after first real-run feedback (slow, token-heavy, locally biased
report, end-pass verification degraded quality, digests stranded in
subagent contexts):
- Three modes replace the acquisition-mode machinery: Draft (build a
deep-research prompt the user runs in their own subscribed tool),
Process (file a finished report into imports/, extract to digests/,
distill research.md summary + metadata so downstream never reprocesses),
Run (native fan-out, first-class). Bare research asks get the choice up
front with the trade stated honestly.
- Engine/Delegate registry cut: the Draft->Process round-trip is the
integration with dedicated deep-research tools; engine.md -> run.md.
- Files-first: digests hit {doc_workspace}/digests/ on landing, sections
commit per dimension, synthesis reads files never conversation memory,
dead runs resume from disk.
- Research firewall: persistent_facts default now empty, assistants get
only their brief, project context frames questions but is inadmissible
as evidence.
- Verification at landing, not end-of-run: normal = spot-check
load-bearing claims only; red_team default off; heavy passes behind
high/max. Presets rescaled faster (standard 3 subagents/8 sources/
depth 2).
- Multi-agent research lessons folded into run.md and the plan gate:
decomposition topology (breadth/depth/straightforward), per-assistant
tool-call budgets, query craft with OODA pause, shared source-quality
card, stop-and-write valve, mechanical citation check at finalize.
- Ripple: v6 shims, catalogs, marketplace, docs one-liners (all five
languages), template gains source: provenance field.
* feat(core): deep-recon quality pass — carve SKILL.md, recon_kit scripts, single-source verification
- SKILL.md 3989→2091 tokens: Draft/Process/Refresh+Deepen/Finalize carved to
references/{draft,process,lifecycle,finalize}.md; Run effort knobs + plan
gate moved into run.md; Overview and pack prose trimmed
- verification.md: red-team pass is the single adversarial mechanism (max
runs it at full breadth — no double-spawn); level semantics single-sourced
- scripts/recon_kit.py + tests: citations cross-check, memlog claim tally
(ref=/status= convention, last wins), staleness date math from per-class
windows, deterministic run-folder slugs, escaped source-appendix HTML
- Draft wired with preferred/banned source policies and an open-floor opening
- external_sources examples (Tavily/Sonar/xAI X-Search MCPs); source-quality
card: answer engines are aggregators — chase their citations
* docs: Deep Recon explanation page + integration
- new docs/explanation/deep-recon.md: three modes, mode-choice guidance,
research types, native-run internals diagram, firewall/verification, refresh
- analysis-phase.md research section rewritten for bmad-deep-recon
- core-tools.md: deep-recon in thinking-skills table, full catalog entry,
migration note for the merged market/domain/technical trio
- workflow-map.md + getting-started.md link the new page
- vi-vn developer guide: last stale old-skill flow mention updated
This commit is contained in:
Brian
@@ -39,6 +39,16 @@
|
||||
},
|
||||
"skills": ["./src/core-skills/bmad-forge-idea"]
|
||||
},
|
||||
{
|
||||
"name": "bmad-deep-recon",
|
||||
"source": "./",
|
||||
"description": "Decision-grade research harness — draft deep-research prompts for your own AI tools, process finished reports into downstream-ready cited summaries, or run the research directly; six research types, claim verification, and a living refresh cycle.",
|
||||
"version": "6.10.0",
|
||||
"author": {
|
||||
"name": "Brian (BMad) Madison"
|
||||
},
|
||||
"skills": ["./src/core-skills/bmad-deep-recon"]
|
||||
},
|
||||
{
|
||||
"name": "bmad-analysis",
|
||||
"source": "./",
|
||||
@@ -67,9 +77,7 @@
|
||||
"./src/bmm-skills/1-analysis/bmad-agent-analyst",
|
||||
"./src/bmm-skills/1-analysis/bmad-agent-tech-writer",
|
||||
"./src/bmm-skills/1-analysis/bmad-document-project",
|
||||
"./src/bmm-skills/1-analysis/research/bmad-domain-research",
|
||||
"./src/bmm-skills/1-analysis/research/bmad-market-research",
|
||||
"./src/bmm-skills/1-analysis/research/bmad-technical-research",
|
||||
"./src/core-skills/bmad-deep-recon",
|
||||
"./src/bmm-skills/2-plan-workflows/bmad-agent-pm",
|
||||
"./src/bmm-skills/2-plan-workflows/bmad-agent-ux-designer",
|
||||
"./src/bmm-skills/2-plan-workflows/bmad-prd",
|
||||
|
||||
@@ -26,7 +26,7 @@ Prozkoumejte problémový prostor a validujte nápady před závazkem k plánov
|
||||
| Workflow | Účel | Produkuje |
|
||||
| ------------------------------- | -------------------------------------------------------------------------- | ------------------------- |
|
||||
| `bmad-brainstorming` | Brainstorming nápadů na projekt s řízenou facilitací brainstormingového kouče | `brainstorming-report.md` |
|
||||
| `bmad-domain-research`, `bmad-market-research`, `bmad-technical-research` | Validace tržních, technických nebo doménových předpokladů | Výzkumné nálezy |
|
||||
| `bmad-deep-recon` | Validace předpokladů nebo výběr mezi variantami — návrh promptu pro váš nástroj hloubkového výzkumu, zpracování jeho zprávy, nebo výzkum přímo zde; tržní, doménový, technický, konkurenční, uživatelský, akademický; ověřené, citované, obnovitelné | Výzkumná zpráva či shrnutí + volitelný HTML briefing |
|
||||
| `bmad-product-brief` | Zachycení strategické vize — nejlepší, když je váš koncept jasný | `product-brief.md` |
|
||||
| `bmad-prfaq` | Working Backwards — zátěžový test a zformování vašeho produktového konceptu | `prfaq-{project}.md` |
|
||||
|
||||
|
||||
@@ -135,7 +135,7 @@ Vytvořte ho ručně na `_bmad-output/project-context.md` nebo ho vygenerujte po
|
||||
|
||||
Všechny workflow v této fázi jsou volitelné:
|
||||
- **brainstorming** (`bmad-brainstorming`) — Řízená ideace
|
||||
- **průzkum** (`bmad-market-research` / `bmad-domain-research` / `bmad-technical-research`) — Tržní, doménový a technický průzkum
|
||||
- **průzkum** (`bmad-deep-recon`) — Navrhne prompt pro váš vlastní nástroj hloubkového výzkumu, zpracuje hotovou zprávu do stručného shrnutí pro navazující práci, nebo výzkum provede přímo — tržní, doménový, technický, konkurenční, uživatelský a akademický — s ověřováním tvrzení a životním cyklem obnovy
|
||||
- **product-brief** (`bmad-product-brief`) — Doporučený základní dokument, když je váš koncept jasný
|
||||
- **prfaq** (`bmad-prfaq`) — Working Backwards výzva pro zátěžový test a zformování vašeho produktového konceptu
|
||||
|
||||
|
||||
@@ -25,13 +25,15 @@ Analysis tools exist to make your PRD sharp. They attack the problem from differ
|
||||
|
||||
See [Brainstorming](./brainstorming.md) for a deeper look at how sessions work.
|
||||
|
||||
### Research (Market, Domain, Technical)
|
||||
### Research (Deep Recon)
|
||||
|
||||
**What it is.** Three focused research workflows that investigate different dimensions of your idea. Market research examines competitors, trends, and user sentiment. Domain research builds subject-matter expertise and terminology. Technical research evaluates feasibility, architecture options, and implementation approaches.
|
||||
**What it is.** One research skill, `bmad-deep-recon`, that investigates any dimension of your idea through typed research packs: market (competitors, trends, sizing), domain (subject-matter expertise and terminology), technical (feasibility and implementation approaches), competitive teardowns, user-voice, and academic literature. It works three ways — draft a prompt for the deep-research tool you already subscribe to, process a finished report into a cited summary, or run the research directly.
|
||||
|
||||
**Why it's here.** Building on assumptions is the fastest way to build something nobody needs. Research grounds your concept in reality — what competitors already exist, what users actually struggle with, what's technically feasible, and what industry-specific constraints you'll face.
|
||||
|
||||
**When to use it.** You're entering an unfamiliar domain, you suspect competitors exist but haven't mapped them, or your concept depends on technical capabilities you haven't validated. Run one, two, or all three — each stands alone.
|
||||
**When to use it.** You're entering an unfamiliar domain, you suspect competitors exist but haven't mapped them, or your concept depends on technical capabilities you haven't validated. Each research type stands alone; run whichever ones bear on your decision.
|
||||
|
||||
See [Deep Recon](./deep-recon.md) for the three modes, how to choose between them, and how a research run works inside.
|
||||
|
||||
### Product Brief
|
||||
|
||||
|
||||
@@ -0,0 +1,125 @@
|
||||
---
|
||||
title: "Deep Recon"
|
||||
description: Decision-grade research three ways — draft a prompt for your own deep-research tool, process a finished report, or run the research in place
|
||||
sidebar:
|
||||
order: 14
|
||||
---
|
||||
|
||||
Deep Recon researches anything you need to decide on. This page explains its three modes, how to pick between them, and what actually happens inside a native research run.
|
||||
|
||||
## What is Deep Recon?
|
||||
|
||||
Run `bmad-deep-recon` and you get a research director, not a search engine. Every engagement starts from a decision: enter a market or skip it, pick a stack, choose a vendor, commit to a domain, ground a paper. The decision shapes which questions get asked, which sources count, and what the final report recommends.
|
||||
|
||||
It's a core skill, so it isn't tied to software projects. Product teams use it for market sizing, but it handles a literature review for a thesis, a teardown of three competitors, or "which health insurance plan should I pick" with the same machinery. If the answer should rest on evidence rather than the model's memory, it's in scope.
|
||||
|
||||
The output is always the same shape: a cited report (`research.md`) with metadata that downstream skills read directly. A PRD or product brief consumes the summary without reprocessing whatever the research originally looked like.
|
||||
|
||||
## Research types
|
||||
|
||||
A type selects a pack: a short card of prioritized dimensions, source craft, and freshness rules that makes the research sharper than an unaided prompt. Deep Recon infers the type from your ask, or you name it.
|
||||
|
||||
| Type | Reach for it when |
|
||||
| --- | --- |
|
||||
| `market` | Sizing an opportunity, segments, pricing, go-to-market |
|
||||
| `domain` | Learning an industry or field: structure, players, rules, vocabulary |
|
||||
| `technical` | Evaluating a technology area, integration approaches, implementation reality |
|
||||
| `competitive` | Tearing down named competitors: offers, pricing, trajectory, sentiment |
|
||||
| `user-voice` | What users actually experience and want: reviews, communities |
|
||||
| `academic-lit` | Literature review, state of the art, grounding an approach in papers |
|
||||
|
||||
The decision shape is a second, independent choice. **Explore** (the default) builds understanding; **select** runs a structured choose-between when you're picking among candidates. Any type can end in a selection matrix. You can also add your own types through [bmad-customize](../how-to/customize-bmad.md).
|
||||
|
||||
## The three modes
|
||||
|
||||
| Mode | What happens | You provide |
|
||||
| --- | --- | --- |
|
||||
| **Draft** | Deep Recon composes a research prompt carrying the pack's craft; you run it in your own tool | One paste into ChatGPT, Gemini, Grok, or Perplexity |
|
||||
| **Process** | A finished report gets filed, its claims extracted and checked against the pack, and distilled into the standard summary | The report, from any source |
|
||||
| **Run** | Deep Recon does the research here: parallel web fan-out, verification, cited synthesis | Approval at one plan gate |
|
||||
|
||||
**Draft** exists because dedicated deep-research products are excellent gatherers and most people already pay for one. The drafted prompt packages the type's dimensions, recency requirements, and a strict citation demand, tuned to the tool you name. Your subscription does the expensive crawling.
|
||||
|
||||
**Process** closes the loop. Point it at any finished report (the one your tool just produced, an analyst PDF, a colleague's document) and it preserves the original untouched in the run folder, pulls out every claim that bears on your decision, flags the dimensions the material never covered, and writes the same summary a native run would. Draft and Process compose naturally: draft the prompt, run it in your app, bring the report back.
|
||||
|
||||
**Run** is fully capable on its own and stays entirely in your session. There's no round-trip, the framing is project-aware, and you control the effort through presets.
|
||||
|
||||
## Which mode should you use?
|
||||
|
||||
| Situation | Use |
|
||||
| --- | --- |
|
||||
| You subscribe to a deep-research tool and don't mind one manual round-trip | Draft, then Process |
|
||||
| You already have a report, whatever produced it | Process |
|
||||
| You want results now, in one sitting, no app switching | Run |
|
||||
| The research needs internal sources or MCP tools only your session can reach | Run |
|
||||
| Broad public sweep first, targeted follow-up after | Draft + Process, then a focused Run on the gaps |
|
||||
|
||||
The trade-off: Draft costs one manual round-trip but rides a subscription you've already paid for, and hosted deep-research products crawl wider than a session-bound run for the same money. Run costs tokens and minutes but stays in context and can use every tool your harness has. When you ask for research with no verb, Deep Recon states this trade once and remembers your preference for the session.
|
||||
|
||||
## How a native run thinks
|
||||
|
||||
A run works in phases. It plans, fans out, and verifies as it goes:
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
A[Plan gate: decision, dimensions,<br/>topology, effort, time estimate] -->|you approve| B{Topology}
|
||||
B -->|breadth-first| C[Assistants split<br/>independent sub-questions]
|
||||
B -->|depth-first| D[Assistants take different<br/>angles on one question]
|
||||
B -->|straightforward| E[One assistant,<br/>small budget]
|
||||
C --> F[Digests written to disk<br/>as each assistant returns]
|
||||
D --> F
|
||||
E --> F
|
||||
F --> G[Verify load-bearing claims<br/>as material lands]
|
||||
G --> H[Write the dimension's section;<br/>report grows in front of you]
|
||||
H --> I{More leads and<br/>budget left?}
|
||||
I -->|yes, follow the leads| F
|
||||
I -->|coverage or exhaustion| J[Next dimension]
|
||||
J --> K[Synthesis: cross-dimension insights,<br/>recommendations, staleness map]
|
||||
K --> L[Mechanical citation check,<br/>then report + optional HTML briefing]
|
||||
```
|
||||
|
||||
The plan gate is the single hard stop. It shows the decision, the dimensions pruned to it, the chosen topology, the knobs in force, and a realistic time estimate; approve it and the run proceeds with light checkpoints instead of interrogation.
|
||||
|
||||
Topology matters because fan-out is a deliberate choice. Independent sub-questions get parallel assistants; a single deep question gets several perspectives on the same material; a simple lookup gets one assistant with a handful of calls, because ten agents on an easy question just burns tokens.
|
||||
|
||||
Effort comes bundled in presets, and anything you say in the request overrides them:
|
||||
|
||||
| Preset | Assistants | Sources per round | Rounds |
|
||||
| --- | --- | --- | --- |
|
||||
| `quick` | 2 | 5 | 1 |
|
||||
| `standard` (default) | 3 | 8 | 2 |
|
||||
| `deep` | 6 | 12 | 3 |
|
||||
|
||||
Rounds follow leads: contradictions between sources and unexpected connections from round one become round two's assignments. Dimensions stop early when their questions are answered or a full round surfaces nothing new.
|
||||
|
||||
## Why the reports hold up
|
||||
|
||||
Two rules run through everything. First, no conclusions from training data: the model's memory proposes questions and search strategy, but every claim in the report traces to a source retrieved or imported during this engagement. Second, the research firewall: your project files and briefs shape what gets asked, never what gets found. Research assistants receive only their assignment, so a run can't come back quietly biased toward what your local context already believed.
|
||||
|
||||
Every claim carries a publisher, a publication date, and an access date, with inline `[n]` citations resolving to a source appendix. Verification runs as material lands, at a level you choose: `normal` spot-checks the claims the recommendation rests on, `high` cross-checks the pack's critical claim classes and red-teams major conclusions, and `max` checks everything. Freshness is part of truth here too; each pack sets windows per claim class, and a market size from three years ago gets reported as history, not fact.
|
||||
|
||||
:::note[Everything lands on disk]
|
||||
Digests, extractions, and report sections are written to the run folder the moment they exist. A run that dies mid-flight resumes from disk with nothing lost, and the report builds in front of you instead of behind a spinner.
|
||||
:::
|
||||
|
||||
## The run folder and refresh
|
||||
|
||||
Each engagement gets one folder under your planning artifacts: the original imports untouched, the extracted digests, the drafted brief when there is one, and `research.md`. The report ends with a staleness map naming which claims age fastest and when to re-check them.
|
||||
|
||||
That map powers the lifecycle. **Refresh** re-verifies only the stale claims and appends a delta report (confirmed, changed, overturned), warning you when an overturned claim feeds a downstream artifact. **Deepen** drills into one dimension without re-running the rest. Research stays a living asset instead of a snapshot.
|
||||
|
||||
## Starting it
|
||||
|
||||
| Goal | Type this |
|
||||
| --- | --- |
|
||||
| Research something | `/bmad-deep-recon` then describe the decision, or just "research the self-hosted analytics market" |
|
||||
| Force a type | "competitive research on Linear and Height" |
|
||||
| Draft a prompt for your tool | "draft a deep research prompt about X for Gemini" |
|
||||
| Process a report | "there's a research report at ~/Downloads/report.pdf, process it" |
|
||||
| Choose between options | "help me choose between Postgres and MySQL for this" |
|
||||
| Refresh an existing report | "refresh the market research" |
|
||||
| Customize defaults | `/bmad-customize bmad-deep-recon` |
|
||||
|
||||
## Where the old research skills went
|
||||
|
||||
The v6 `bmad-market-research`, `bmad-domain-research`, and `bmad-technical-research` skills merged into Deep Recon as the `market`, `domain`, and `technical` types. The old names still work and forward to the new skill, so existing habits and menu entries keep functioning.
|
||||
@@ -37,7 +37,7 @@ chaque outil et quand l’utiliser**](../explanation/analysis-phase.md).
|
||||
| Workflow | Objectif | Livrable |
|
||||
|---------------------------------------------------------------------------|--------------------------------------------------------------------------------|---------------------------|
|
||||
| `bmad-brainstorming` | Brainstormez des idées de projet, animé par un coach de brainstorming dédié | `brainstorming-report.md` |
|
||||
| `bmad-domain-research`, `bmad-market-research`, `bmad-technical-research` | Validez vos hypothèses de marché, techniques ou liées au domaine | Rapport de recherches |
|
||||
| `bmad-deep-recon` | Validez vos hypothèses ou choisissez entre des options — rédigez un prompt pour votre outil de recherche approfondie, traitez son rapport, ou menez la recherche ici ; marché, domaine, technique, concurrentiel, voix des utilisateurs, académique ; vérifiée, citée, actualisable | Rapport ou synthèse de recherche + briefing HTML optionnel |
|
||||
| `bmad-product-brief` | Formalisez la vision stratégique — idéal lorsque votre concept est bien défini | `product-brief.md` |
|
||||
| `bmad-prfaq` | Working Backwards — mettez à l’épreuve et affinez votre concept produit | `prfaq-{project}.md` |
|
||||
|
||||
|
||||
@@ -138,7 +138,7 @@ Créez-le manuellement à l’emplacement `_bmad-output/project-context.md`, ou
|
||||
Tous les workflows de cette phase sont optionnels. [**Vous ne savez pas lequel choisir ?**](../explanation/analysis-phase.md)
|
||||
|
||||
- **brainstorming** (`bmad-brainstorming`) — Idéation guidée
|
||||
- **research** (`bmad-market-research` / `bmad-domain-research` / `bmad-technical-research`) — Recherche marché, domaine et technique
|
||||
- **research** (`bmad-deep-recon`) — Rédigez un prompt de recherche approfondie pour votre propre outil IA, transformez un rapport terminé en synthèse exploitable en aval, ou menez la recherche ici — marché, domaine, technique, concurrentiel, voix des utilisateurs et académique — avec vérification des affirmations et cycle de rafraîchissement
|
||||
- **product-brief** (`bmad-product-brief`) — Document fondateur recommandé une fois votre concept bien défini
|
||||
- **prfaq** (`bmad-prfaq`) — Exercice Working Backwards pour tester et affiner votre concept produit
|
||||
|
||||
|
||||
@@ -27,11 +27,12 @@ Run any tool by typing its skill name (e.g., `bmad-help`) in your IDE. No agent
|
||||
| Tool | Purpose |
|
||||
| ------------------------------------------- | ------------------------------------------------------------------- |
|
||||
| [`bmad-brainstorming`](#bmad-brainstorming) | Facilitate interactive brainstorming sessions |
|
||||
| [`bmad-deep-recon`](#bmad-deep-recon) | Decision-grade research: draft, process, or run — any subject |
|
||||
| [`bmad-forge-idea`](#bmad-forge-idea) | Pressure-test an idea until it hardens, proves out, or dies cheaply |
|
||||
| [`bmad-party-mode`](#bmad-party-mode) | Orchestrate multi-agent group discussions |
|
||||
|
||||
:::note[Moved and removed]
|
||||
`bmad-spec` now ships with the BMM module as a Phase 2 planning workflow — see the [Workflow Map](./workflow-map.md#phase-2-planning). The `bmad-shard-doc` and `bmad-index-docs` utilities have been removed. The former `bmad-editorial-review`, `bmad-editorial-review-prose`, `bmad-editorial-review-structure`, `bmad-review-adversarial-general`, `bmad-review-edge-case-hunter`, and `bmad-review-verification-gap` skills are all merged into `bmad-review`, whose editorial lenses replace the separate editorial skill; the old IDs still resolve via forwarders for compatibility.
|
||||
`bmad-spec` now ships with the BMM module as a Phase 2 planning workflow — see the [Workflow Map](./workflow-map.md#phase-2-planning). The `bmad-shard-doc` and `bmad-index-docs` utilities have been removed. The former `bmad-editorial-review`, `bmad-editorial-review-prose`, `bmad-editorial-review-structure`, `bmad-review-adversarial-general`, `bmad-review-edge-case-hunter`, and `bmad-review-verification-gap` skills are all merged into `bmad-review`, whose editorial lenses replace the separate editorial skill; the old IDs still resolve via forwarders for compatibility. The former `bmad-market-research`, `bmad-domain-research`, and `bmad-technical-research` workflows are merged into `bmad-deep-recon` as research types, with the old IDs forwarding the same way.
|
||||
:::
|
||||
|
||||
## bmad-help
|
||||
@@ -150,7 +151,7 @@ For a detailed guide on customizing BMad, see [How to Customize BMad](../how-to/
|
||||
|
||||
## Thinking Skills
|
||||
|
||||
The three skills below round out the core module — general-purpose thinking tools that any phase or module can lean on.
|
||||
The skills below round out the core module — general-purpose thinking tools that any phase or module can lean on.
|
||||
|
||||
### bmad-brainstorming
|
||||
|
||||
@@ -178,6 +179,31 @@ The three skills below round out the core module — general-purpose thinking to
|
||||
The magic happens in ideas 50–100. The workflow encourages generating 100+ ideas before organization.
|
||||
:::
|
||||
|
||||
### bmad-deep-recon
|
||||
|
||||
**Decision-grade research on any subject, three ways.** — Draft a deep-research prompt for the AI tool you already subscribe to, process a finished report into a cited summary downstream skills consume directly, or run the research in place through parallel web fan-out.
|
||||
|
||||
**Use it when:**
|
||||
|
||||
- A decision should rest on evidence instead of the model's memory
|
||||
- You need market, domain, technical, competitive, user-voice, or literature research
|
||||
- You have a research report from any source and want it distilled for downstream use
|
||||
- You're choosing between named options and want a structured comparison
|
||||
|
||||
**How it works:**
|
||||
|
||||
1. Detects the mode — draft, process, or run — and infers the research type from your ask
|
||||
2. Loads the type's pack: prioritized dimensions, source craft, freshness rules
|
||||
3. Run mode plans at one gate, fans out firewalled research assistants, and verifies claims as they land
|
||||
4. Draft and Process round-trip through your own deep-research tool instead
|
||||
5. Refresh and Deepen update an existing report without re-researching it
|
||||
|
||||
**Input:** The decision and topic, a report to process, or an existing research folder to refresh
|
||||
|
||||
**Output:** A cited `research.md` with metadata frontmatter, plus an optional self-contained HTML briefing
|
||||
|
||||
For the three modes, how to choose between them, and what happens inside a run, see [Deep Recon](../explanation/deep-recon.md).
|
||||
|
||||
### bmad-forge-idea
|
||||
|
||||
**Pressure-test an idea until it hardens, proves out, or dies cheaply.** — An adversarial interrogator drives a half-formed idea one question at a time, bringing two characters to every branch, until what survives is something you can act on with conviction.
|
||||
|
||||
@@ -37,10 +37,12 @@ it**](../explanation/analysis-phase.md).
|
||||
|---------------------------------------------------------------------------|----------------------------------------------------------------------------|---------------------------|
|
||||
| `bmad-brainstorming` | Brainstorm Project Ideas with guided facilitation of a brainstorming coach | `brainstorm.html` keepsake plus an optional `brainstorm-intent.md` |
|
||||
| `bmad-forge-idea` | Pressure-test an idea until it hardens, proves out, or dies cheaply | `forge-report.html` every run; `forged-idea.md` when an idea hardens |
|
||||
| `bmad-domain-research`, `bmad-market-research`, `bmad-technical-research` | Validate market, technical, or domain assumptions | Research findings |
|
||||
| `bmad-deep-recon` | Research any subject for a decision — draft a prompt for your deep-research tool, process its report, or run the research here; six typed packs, verified and cited | Research report or summary + optional HTML briefing |
|
||||
| `bmad-product-brief` | Capture strategic vision — best when your concept is clear | `brief.md` + `addendum.md`, plus any desired HTML or presentation output |
|
||||
| `bmad-prfaq` | Working Backwards — stress-test your product concept customer-first | `prfaq-{project}.md` |
|
||||
|
||||
For Deep Recon's three modes and how a research run works inside, see [Deep Recon](../explanation/deep-recon.md).
|
||||
|
||||
## Phase 2: Planning
|
||||
|
||||
Define what to build and for whom.
|
||||
|
||||
@@ -140,7 +140,7 @@ All workflows in this phase are optional. [**Not sure which to use?**](../explan
|
||||
|
||||
- **brainstorming** (`bmad-brainstorming`) — Guided ideation
|
||||
- **forge-idea** (`bmad-forge-idea`) — Pressure-test an idea until it hardens or dies cheaply
|
||||
- **research** (`bmad-market-research` / `bmad-domain-research` / `bmad-technical-research`) — Market, domain, and technical research
|
||||
- **research** (`bmad-deep-recon`) — Draft a deep-research prompt for your own AI tool, process a finished report into a downstream-ready summary, or run the research here, with claim verification and a refresh lifecycle. [Learn more](../explanation/deep-recon.md)
|
||||
- **product-brief** (`bmad-product-brief`) — Recommended foundation document when your concept is clear
|
||||
- **prfaq** (`bmad-prfaq`) — Working Backwards challenge to stress-test your product concept customer-first
|
||||
|
||||
|
||||
@@ -486,7 +486,7 @@ bmad-quick-dev
|
||||
```
|
||||
Ngày 1-2: Analysis
|
||||
├── bmad-analyst → CB → product-brief.md
|
||||
└── (tùy chọn) bmad-analyst → MR → market-research.md
|
||||
└── (tùy chọn) bmad-analyst → RS (bmad-deep-recon) → research.md
|
||||
|
||||
Ngày 2-3: Planning
|
||||
├── bmad-pm → CP → PRD.md
|
||||
|
||||
@@ -26,7 +26,7 @@ Khám phá không gian vấn đề và xác nhận ý tưởng trước khi cam
|
||||
| Quy trình | Mục đích | Tạo ra |
|
||||
| ------------------------------- | -------------------------------------------------------------------------- | ------------------------- |
|
||||
| `bmad-brainstorming` | Động não ý tưởng dự án với sự điều phối của người dẫn dắt brainstorming | `brainstorming-report.md` |
|
||||
| `bmad-domain-research`, `bmad-market-research`, `bmad-technical-research` | Xác thực giả định về thị trường, kỹ thuật hoặc miền nghiệp vụ | Kết quả nghiên cứu |
|
||||
| `bmad-deep-recon` | Xác thực giả định hoặc lựa chọn giữa các phương án — soạn prompt cho công cụ nghiên cứu chuyên sâu của bạn, xử lý báo cáo của nó, hoặc nghiên cứu ngay tại đây; thị trường, miền nghiệp vụ, kỹ thuật, cạnh tranh, tiếng nói người dùng, học thuật; đã kiểm chứng, có trích dẫn, có thể làm mới | Báo cáo hoặc bản tóm tắt nghiên cứu + bản tóm tắt HTML tùy chọn |
|
||||
| `bmad-product-brief` | Ghi lại tầm nhìn chiến lược — phù hợp nhất khi concept của bạn đã rõ | `product-brief.md` |
|
||||
| `bmad-prfaq` | Working Backwards — stress-test và rèn sắc concept sản phẩm của bạn | `prfaq-{project}.md` |
|
||||
|
||||
|
||||
@@ -135,7 +135,7 @@ Bạn có thể tạo thủ công tại `_bmad-output/project-context.md` hoặc
|
||||
|
||||
Tất cả workflow trong phase này đều là tùy chọn. [**Chưa chắc nên dùng cái nào?**](../explanation/analysis-phase.md)
|
||||
- **brainstorming** (`bmad-brainstorming`) — Gợi ý ý tưởng có hướng dẫn
|
||||
- **research** (`bmad-market-research` / `bmad-domain-research` / `bmad-technical-research`) — Nghiên cứu thị trường, miền nghiệp vụ và kỹ thuật
|
||||
- **research** (`bmad-deep-recon`) — Soạn prompt nghiên cứu chuyên sâu cho công cụ AI của riêng bạn, xử lý báo cáo hoàn chỉnh thành bản tóm tắt sẵn sàng cho các bước sau, hoặc thực hiện nghiên cứu ngay tại đây — thị trường, miền nghiệp vụ, kỹ thuật, cạnh tranh, tiếng nói người dùng và học thuật — kèm kiểm chứng luận điểm và vòng đời làm mới
|
||||
- **product-brief** (`bmad-product-brief`) — Tài liệu nền tảng được khuyến nghị khi concept của bạn đã rõ
|
||||
- **prfaq** (`bmad-prfaq`) — Bài kiểm tra Working Backwards để stress-test và rèn sắc concept sản phẩm của bạn
|
||||
|
||||
|
||||
@@ -22,7 +22,7 @@ BMad Method（BMM）通过分阶段 workflow 逐步构建上下文，让智能
|
||||
| Workflow | 目的 | 产出 |
|
||||
| --- | --- | --- |
|
||||
| `bmad-brainstorming` | 通过引导式创意方法扩展方案空间 | `brainstorming-report.md` |
|
||||
| `bmad-domain-research`、`bmad-market-research`、`bmad-technical-research` | 验证领域、市场与技术假设 | 研究发现 |
|
||||
| `bmad-deep-recon` | 验证假设或在候选方案间做选择——可为你的深度研究工具起草提示词、加工其报告，或直接在此研究；覆盖市场、领域、技术、竞争、用户之声与学术研究；经核实、有引用、可刷新 | 研究报告或摘要 + 可选 HTML 简报 |
|
||||
| `bmad-create-product-brief` | 沉淀产品方向与战略愿景 | `product-brief.md` |
|
||||
|
||||
## 阶段 2：规划
|
||||
|
||||
@@ -135,7 +135,7 @@ BMad-Help 将检测你已完成的内容，并准确推荐下一步该做什么
|
||||
|
||||
此阶段中的所有工作流都是可选的：
|
||||
- **头脑风暴**（`bmad-brainstorming`） — 引导式构思
|
||||
- **研究**（`bmad-market-research` / `bmad-domain-research` / `bmad-technical-research`） — 市场、领域和技术研究
|
||||
- **研究**（`bmad-deep-recon`） — 为你自己的深度研究工具起草提示词、将完成的研究报告加工为可供下游使用的精炼摘要，或直接在此执行研究——覆盖市场、领域、技术、竞争、用户之声与学术类型，带论断核实与刷新生命周期
|
||||
- **创建产品简报**（`bmad-create-product-brief`） — 推荐的基础文档
|
||||
|
||||
### 阶段 2：规划（必需）
|
||||
|
||||
@@ -62,17 +62,32 @@ skill = "bmad-brainstorming"
|
||||
[[agent.menu]]
|
||||
code = "MR"
|
||||
description = "Market analysis, competitive landscape, customer needs and trends"
|
||||
skill = "bmad-market-research"
|
||||
prompt = "Invoke the `bmad-deep-recon` skill with the market research type pre-selected (forwarded activation: skip type inference)."
|
||||
|
||||
[[agent.menu]]
|
||||
code = "DR"
|
||||
description = "Industry domain deep dive, subject matter expertise and terminology"
|
||||
skill = "bmad-domain-research"
|
||||
prompt = "Invoke the `bmad-deep-recon` skill with the domain research type pre-selected (forwarded activation: skip type inference)."
|
||||
|
||||
[[agent.menu]]
|
||||
code = "TR"
|
||||
description = "Technical feasibility, architecture options and implementation approaches"
|
||||
skill = "bmad-technical-research"
|
||||
description = "Technical landscape, architecture patterns and implementation reality"
|
||||
prompt = "Invoke the `bmad-deep-recon` skill with the technical research type pre-selected (forwarded activation: skip type inference)."
|
||||
|
||||
[[agent.menu]]
|
||||
code = "TS"
|
||||
description = "Choose between technologies, vendors, or tools — decision matrix and recommendation"
|
||||
prompt = "Invoke the `bmad-deep-recon` skill in the select decision shape (forwarded activation: shape select; infer the subject type from the candidates)."
|
||||
|
||||
[[agent.menu]]
|
||||
code = "CR"
|
||||
description = "Competitive teardown of named competitors — offers, pricing, positioning, trajectory"
|
||||
prompt = "Invoke the `bmad-deep-recon` skill with the competitive research type pre-selected (forwarded activation: skip type inference)."
|
||||
|
||||
[[agent.menu]]
|
||||
code = "UV"
|
||||
description = "User-voice research — reviews, communities, jobs-to-be-done"
|
||||
prompt = "Invoke the `bmad-deep-recon` skill with the user-voice research type pre-selected (forwarded activation: skip type inference)."
|
||||
|
||||
[[agent.menu]]
|
||||
code = "CB"
|
||||
|
||||
@@ -64,7 +64,7 @@ Omit keys for artifacts that were not produced.
|
||||
|
||||
## Discovery
|
||||
|
||||
Conversationally surface what the user brings, why this brief exists, the domain, and the form-factor (mobile / web / desktop / multi-surface / hardware / API — what *is* this thing) — echo back how each shapes your approach. Open with space for the full picture: invite a brain dump and ask up front for any source material they already have (memo, deck, transcript, prior brief, slack thread). Read what exists first; ask only what is missing. After the dump, a simple "anything else?" often surfaces what they almost forgot. Drill into specifics only after the broad shape is on the table; premature granular questions interrupt the dump and miss the room. Get a read on stakes early (passion project, internal pitch, investor input, public launch), and let that calibrate how hard you push. During the dump, spawn web-research subagents to ground the picture — landscape, comparables, current state — AI especially, where training data ages by the week. Subagent searches; parent gets a digest. Deep work (full market sizing, exhaustive teardowns) → suggest `bmad-market-research` or `bmad-domain-research`.
|
||||
Conversationally surface what the user brings, why this brief exists, the domain, and the form-factor (mobile / web / desktop / multi-surface / hardware / API — what *is* this thing) — echo back how each shapes your approach. Open with space for the full picture: invite a brain dump and ask up front for any source material they already have (memo, deck, transcript, prior brief, slack thread). Read what exists first; ask only what is missing. After the dump, a simple "anything else?" often surfaces what they almost forgot. Drill into specifics only after the broad shape is on the table; premature granular questions interrupt the dump and miss the room. Get a read on stakes early (passion project, internal pitch, investor input, public launch), and let that calibrate how hard you push. During the dump, spawn web-research subagents to ground the picture — landscape, comparables, current state — AI especially, where training data ages by the week. Subagent searches; parent gets a digest. Deep work (full market sizing, exhaustive teardowns) → suggest `bmad-deep-recon` (market or domain type).
|
||||
|
||||
Once stakes are read and the dump is captured, offer the working mode in the user's language:
|
||||
|
||||
|
||||
@@ -1,96 +0,0 @@
|
||||
---
|
||||
name: bmad-domain-research
|
||||
description: 'Conduct domain and industry research. Use when the user says wants to do domain research for a topic or industry'
|
||||
---
|
||||
|
||||
# Domain Research Workflow
|
||||
|
||||
**Goal:** Conduct comprehensive domain/industry research using current web data and verified sources to produce complete research documents with compelling narratives and proper citations.
|
||||
|
||||
**Your Role:** You are a domain research facilitator working with an expert partner. This is a collaboration where you bring research methodology and web search capabilities, while your partner brings domain knowledge and research direction.
|
||||
|
||||
## Conventions
|
||||
|
||||
- Bare paths (e.g. `domain-steps/step-01-init.md`) resolve from the skill root.
|
||||
- `{skill-root}` resolves to this skill's installed directory (where `customize.toml` lives).
|
||||
- `{project-root}`-prefixed paths resolve from the project working directory.
|
||||
- `{skill-name}` resolves to the skill directory's basename.
|
||||
|
||||
## PREREQUISITE
|
||||
|
||||
**⛔ Web search required.** If unavailable, abort and tell the user.
|
||||
|
||||
## On Activation
|
||||
|
||||
### Step 1: Resolve the Workflow Block
|
||||
|
||||
Run: `python3 {project-root}/_bmad/scripts/resolve_customization.py --skill {skill-root} --key workflow`
|
||||
|
||||
**If the script fails**, resolve the `workflow` block yourself by reading these three files in base → team → user order and applying the same structural merge rules as the resolver:
|
||||
|
||||
1. `{skill-root}/customize.toml` — defaults
|
||||
2. `{project-root}/_bmad/custom/{skill-name}.toml` — team overrides
|
||||
3. `{project-root}/_bmad/custom/{skill-name}.user.toml` — personal overrides
|
||||
|
||||
Any missing file is skipped. Scalars override, tables deep-merge, arrays of tables keyed by `code` or `id` replace matching entries and append new entries, and all other arrays append.
|
||||
|
||||
### Step 2: Execute Prepend Steps
|
||||
|
||||
Execute each entry in `{workflow.activation_steps_prepend}` in order before proceeding.
|
||||
|
||||
### Step 3: Load Persistent Facts
|
||||
|
||||
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.
|
||||
|
||||
### Step 4: Load Config
|
||||
|
||||
Load config from `{project-root}/_bmad/bmm/config.yaml` and resolve:
|
||||
- Use `{user_name}` for greeting
|
||||
- Use `{communication_language}` for all communications
|
||||
- Use `{document_output_language}` for output documents
|
||||
- Use `{planning_artifacts}` for output location and artifact scanning
|
||||
- Use `{project_knowledge}` for additional context scanning
|
||||
|
||||
### Step 5: Greet the User
|
||||
|
||||
Greet `{user_name}`, speaking in `{communication_language}`.
|
||||
|
||||
### Step 6: Execute Append Steps
|
||||
|
||||
Execute each entry in `{workflow.activation_steps_append}` in order.
|
||||
|
||||
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.
|
||||
|
||||
## QUICK TOPIC DISCOVERY
|
||||
|
||||
"Welcome {{user_name}}! Let's get started with your **domain/industry research**.
|
||||
|
||||
**What domain, industry, or sector do you want to research?**
|
||||
|
||||
For example:
|
||||
- 'The healthcare technology industry'
|
||||
- 'Sustainable packaging regulations in Europe'
|
||||
- 'Construction and building materials sector'
|
||||
- 'Or any other domain you have in mind...'"
|
||||
|
||||
### Topic Clarification
|
||||
|
||||
Based on the user's topic, briefly clarify:
|
||||
1. **Core Domain**: "What specific aspect of [domain] are you most interested in?"
|
||||
2. **Research Goals**: "What do you hope to achieve with this research?"
|
||||
3. **Scope**: "Should we focus broadly or dive deep into specific aspects?"
|
||||
|
||||
## ROUTE TO DOMAIN RESEARCH STEPS
|
||||
|
||||
After gathering the topic and goals:
|
||||
|
||||
1. Set `research_type = "domain"`
|
||||
2. Set `research_topic = [discovered topic from discussion]`
|
||||
3. Set `research_goals = [discovered goals from discussion]`
|
||||
4. Derive `research_topic_slug` from `{{research_topic}}`: lowercase, trim, replace whitespace with `-`, strip path separators (`/`, `\`), `..`, and any character that is not alphanumeric, `-`, or `_`. Collapse repeated `-` and strip leading/trailing `-`. If the result is empty, use `untitled`.
|
||||
5. Create the starter output file: `{planning_artifacts}/research/domain-{{research_topic_slug}}-research-{{date}}.md` with exact copy of the `./research.template.md` contents
|
||||
6. Load: `./domain-steps/step-01-init.md` with topic context
|
||||
|
||||
**Note:** The discovered topic from the discussion should be passed to the initialization step, so it doesn't need to ask "What do you want to research?" again - it can focus on refining the scope for domain research.
|
||||
|
||||
**✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`**
|
||||
@@ -1,41 +0,0 @@
|
||||
# DO NOT EDIT -- overwritten on every update.
|
||||
#
|
||||
# Workflow customization surface for bmad-domain-research. Mirrors the
|
||||
# agent customization shape under the [workflow] namespace.
|
||||
|
||||
[workflow]
|
||||
|
||||
# --- Configurable below. Overrides merge per BMad structural rules: ---
|
||||
# scalars: override wins • arrays (persistent_facts, activation_steps_*): append
|
||||
# arrays-of-tables with `code`/`id`: replace matching items, append new ones.
|
||||
|
||||
# Steps to run before the standard activation (config load, greet).
|
||||
# Overrides append. Use for pre-flight loads, compliance checks, etc.
|
||||
|
||||
activation_steps_prepend = []
|
||||
|
||||
# Steps to run after greet but before the workflow begins.
|
||||
# Overrides append. Use for context-heavy setup that should happen
|
||||
# once the user has been acknowledged.
|
||||
|
||||
activation_steps_append = []
|
||||
|
||||
# Persistent facts the workflow keeps in mind for the whole run
|
||||
# (standards, compliance constraints, stylistic guardrails).
|
||||
# Distinct from the runtime memory sidecar — these are static context
|
||||
# loaded on activation. Overrides append.
|
||||
#
|
||||
# Each entry is either:
|
||||
# - a literal sentence, e.g. "All briefs must include a regulatory-risk section."
|
||||
# - a file reference prefixed with `file:`, e.g. "file:{project-root}/docs/standards.md"
|
||||
# (glob patterns are supported; the file's contents are loaded and treated as facts).
|
||||
|
||||
persistent_facts = [
|
||||
"file:{project-root}/**/project-context.md",
|
||||
]
|
||||
|
||||
# Scalar: executed when the workflow reaches its terminal stage (Step 6: Research Synthesis),
|
||||
# after the domain research document has been saved and the user selects [C] Complete.
|
||||
# Override wins. Leave empty for no custom post-completion behavior.
|
||||
|
||||
on_complete = ""
|
||||
@@ -1,137 +0,0 @@
|
||||
# Domain Research Step 1: Domain Research Scope Confirmation
|
||||
|
||||
## MANDATORY EXECUTION RULES (READ FIRST):
|
||||
|
||||
- 🛑 NEVER generate content without user confirmation
|
||||
|
||||
- 📖 CRITICAL: ALWAYS read the complete step file before taking any action - partial understanding leads to incomplete decisions
|
||||
- 🔄 CRITICAL: When loading next step with 'C', ensure the entire file is read and understood before proceeding
|
||||
- ✅ FOCUS EXCLUSIVELY on confirming domain research scope and approach
|
||||
- 📋 YOU ARE A DOMAIN RESEARCH PLANNER, not content generator
|
||||
- 💬 ACKNOWLEDGE and CONFIRM understanding of domain research goals
|
||||
- 🔍 This is SCOPE CONFIRMATION ONLY - no web research yet
|
||||
- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
|
||||
|
||||
## EXECUTION PROTOCOLS:
|
||||
|
||||
- 🎯 Show your analysis before taking any action
|
||||
- ⚠️ Present [C] continue option after scope confirmation
|
||||
- 💾 ONLY proceed when user chooses C (Continue)
|
||||
- 📖 Update frontmatter `stepsCompleted: [1]` before loading next step
|
||||
- 🚫 FORBIDDEN to load next step until C is selected
|
||||
|
||||
## CONTEXT BOUNDARIES:
|
||||
|
||||
- Research type = "domain" is already set
|
||||
- **Research topic = "{{research_topic}}"** - discovered from initial discussion
|
||||
- **Research goals = "{{research_goals}}"** - captured from initial discussion
|
||||
- Focus on industry/domain analysis with web research
|
||||
- Web search is required to verify and supplement your knowledge with current facts
|
||||
|
||||
## YOUR TASK:
|
||||
|
||||
Confirm domain research scope and approach for **{{research_topic}}** with the user's goals in mind.
|
||||
|
||||
## DOMAIN SCOPE CONFIRMATION:
|
||||
|
||||
### 1. Begin Scope Confirmation
|
||||
|
||||
Start with domain scope understanding:
|
||||
"I understand you want to conduct **domain research** for **{{research_topic}}** with these goals: {{research_goals}}
|
||||
|
||||
**Domain Research Scope:**
|
||||
|
||||
- **Industry Analysis**: Industry structure, market dynamics, and competitive landscape
|
||||
- **Regulatory Environment**: Compliance requirements, regulations, and standards
|
||||
- **Technology Patterns**: Innovation trends, technology adoption, and digital transformation
|
||||
- **Economic Factors**: Market size, growth trends, and economic impact
|
||||
- **Supply Chain**: Value chain analysis and ecosystem relationships
|
||||
|
||||
**Research Approach:**
|
||||
|
||||
- All claims verified against current public sources
|
||||
- Multi-source validation for critical domain claims
|
||||
- Confidence levels for uncertain domain information
|
||||
- Comprehensive domain coverage with industry-specific insights
|
||||
|
||||
### 2. Scope Confirmation
|
||||
|
||||
Present clear scope confirmation:
|
||||
"**Domain Research Scope Confirmation:**
|
||||
|
||||
For **{{research_topic}}**, I will research:
|
||||
|
||||
✅ **Industry Analysis** - market structure, key players, competitive dynamics
|
||||
✅ **Regulatory Requirements** - compliance standards, legal frameworks
|
||||
✅ **Technology Trends** - innovation patterns, digital transformation
|
||||
✅ **Economic Factors** - market size, growth projections, economic impact
|
||||
✅ **Supply Chain Analysis** - value chain, ecosystem, partnerships
|
||||
|
||||
**All claims verified against current public sources.**
|
||||
|
||||
**Does this domain research scope and approach align with your goals?**
|
||||
[C] Continue - Begin domain research with this scope
|
||||
|
||||
### 3. Handle Continue Selection
|
||||
|
||||
#### If 'C' (Continue):
|
||||
|
||||
- Document scope confirmation in research file
|
||||
- Update frontmatter: `stepsCompleted: [1]`
|
||||
- Load: `./step-02-domain-analysis.md`
|
||||
|
||||
## APPEND TO DOCUMENT:
|
||||
|
||||
When user selects 'C', append scope confirmation:
|
||||
|
||||
```markdown
|
||||
## Domain Research Scope Confirmation
|
||||
|
||||
**Research Topic:** {{research_topic}}
|
||||
**Research Goals:** {{research_goals}}
|
||||
|
||||
**Domain Research Scope:**
|
||||
|
||||
- Industry Analysis - market structure, competitive landscape
|
||||
- Regulatory Environment - compliance requirements, legal frameworks
|
||||
- Technology Trends - innovation patterns, digital transformation
|
||||
- Economic Factors - market size, growth projections
|
||||
- Supply Chain Analysis - value chain, ecosystem relationships
|
||||
|
||||
**Research Methodology:**
|
||||
|
||||
- All claims verified against current public sources
|
||||
- Multi-source validation for critical domain claims
|
||||
- Confidence level framework for uncertain information
|
||||
- Comprehensive domain coverage with industry-specific insights
|
||||
|
||||
**Scope Confirmed:** {{date}}
|
||||
```
|
||||
|
||||
## SUCCESS METRICS:
|
||||
|
||||
✅ Domain research scope clearly confirmed with user
|
||||
✅ All domain analysis areas identified and explained
|
||||
✅ Research methodology emphasized
|
||||
✅ [C] continue option presented and handled correctly
|
||||
✅ Scope confirmation documented when user proceeds
|
||||
✅ Proper routing to next domain research step
|
||||
|
||||
## FAILURE MODES:
|
||||
|
||||
❌ Not clearly confirming domain research scope with user
|
||||
❌ Missing critical domain analysis areas
|
||||
❌ Not explaining that web search is required for current facts
|
||||
❌ Not presenting [C] continue option
|
||||
❌ Proceeding without user scope confirmation
|
||||
❌ Not routing to next domain research step
|
||||
|
||||
❌ **CRITICAL**: Reading only partial step file - leads to incomplete understanding and poor decisions
|
||||
❌ **CRITICAL**: Proceeding with 'C' without fully reading and understanding the next step file
|
||||
❌ **CRITICAL**: Making decisions without complete understanding of step requirements and protocols
|
||||
|
||||
## NEXT STEP:
|
||||
|
||||
After user selects 'C', load `./step-02-domain-analysis.md` to begin industry analysis.
|
||||
|
||||
Remember: This is SCOPE CONFIRMATION ONLY - no actual domain research yet, just confirming the research approach and scope!
|
||||
-229
@@ -1,229 +0,0 @@
|
||||
# Domain Research Step 2: Industry Analysis
|
||||
|
||||
## MANDATORY EXECUTION RULES (READ FIRST):
|
||||
|
||||
- 🛑 NEVER generate content without web search verification
|
||||
|
||||
- 📖 CRITICAL: ALWAYS read the complete step file before taking any action - partial understanding leads to incomplete decisions
|
||||
- 🔄 CRITICAL: When loading next step with 'C', ensure the entire file is read and understood before proceeding
|
||||
- ✅ Search the web to verify and supplement your knowledge with current facts
|
||||
- 📋 YOU ARE AN INDUSTRY ANALYST, not content generator
|
||||
- 💬 FOCUS on market size, growth, and industry dynamics
|
||||
- 🔍 WEB SEARCH REQUIRED - verify current facts against live sources
|
||||
- 📝 WRITE CONTENT IMMEDIATELY TO DOCUMENT
|
||||
- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
|
||||
|
||||
## EXECUTION PROTOCOLS:
|
||||
|
||||
- 🎯 Show web search analysis before presenting findings
|
||||
- ⚠️ Present [C] continue option after industry analysis content generation
|
||||
- 📝 WRITE INDUSTRY ANALYSIS TO DOCUMENT IMMEDIATELY
|
||||
- 💾 ONLY proceed when user chooses C (Continue)
|
||||
- 📖 Update frontmatter `stepsCompleted: [1, 2]` before loading next step
|
||||
- 🚫 FORBIDDEN to load next step until C is selected
|
||||
|
||||
## CONTEXT BOUNDARIES:
|
||||
|
||||
- Current document and frontmatter from step-01 are available
|
||||
- **Research topic = "{{research_topic}}"** - established from initial discussion
|
||||
- **Research goals = "{{research_goals}}"** - established from initial discussion
|
||||
- Focus on market size, growth, and industry dynamics
|
||||
- Web search capabilities with source verification are enabled
|
||||
|
||||
## YOUR TASK:
|
||||
|
||||
Conduct industry analysis focusing on market size, growth, and industry dynamics. Search the web to verify and supplement current facts.
|
||||
|
||||
## INDUSTRY ANALYSIS SEQUENCE:
|
||||
|
||||
### 1. Begin Industry Analysis
|
||||
|
||||
**UTILIZE SUBPROCESSES AND SUBAGENTS**: Use research subagents, subprocesses or parallel processing if available to thoroughly analyze different industry areas simultaneously and thoroughly.
|
||||
|
||||
Start with industry research approach:
|
||||
"Now I'll conduct **industry analysis** for **{{research_topic}}** to understand market dynamics.
|
||||
|
||||
**Industry Analysis Focus:**
|
||||
|
||||
- Market size and valuation metrics
|
||||
- Growth rates and market dynamics
|
||||
- Market segmentation and structure
|
||||
- Industry trends and evolution patterns
|
||||
- Economic impact and value creation
|
||||
|
||||
**Let me search for current industry insights.**"
|
||||
|
||||
### 2. Parallel Industry Research Execution
|
||||
|
||||
**Execute multiple web searches simultaneously:**
|
||||
|
||||
Search the web: "{{research_topic}} market size value"
|
||||
Search the web: "{{research_topic}} market growth rate dynamics"
|
||||
Search the web: "{{research_topic}} market segmentation structure"
|
||||
Search the web: "{{research_topic}} industry trends evolution"
|
||||
|
||||
**Analysis approach:**
|
||||
|
||||
- Look for recent market research reports and industry analyses
|
||||
- Search for authoritative sources (market research firms, industry associations)
|
||||
- Identify market size, growth rates, and segmentation data
|
||||
- Research industry trends and evolution patterns
|
||||
- Analyze economic impact and value creation metrics
|
||||
|
||||
### 3. Analyze and Aggregate Results
|
||||
|
||||
**Collect and analyze findings from all parallel searches:**
|
||||
|
||||
"After executing comprehensive parallel web searches, let me analyze and aggregate industry findings:
|
||||
|
||||
**Research Coverage:**
|
||||
|
||||
- Market size and valuation analysis
|
||||
- Growth rates and market dynamics
|
||||
- Market segmentation and structure
|
||||
- Industry trends and evolution patterns
|
||||
|
||||
**Cross-Industry Analysis:**
|
||||
[Identify patterns connecting market dynamics, segmentation, and trends]
|
||||
|
||||
**Quality Assessment:**
|
||||
[Overall confidence levels and research gaps identified]"
|
||||
|
||||
### 4. Generate Industry Analysis Content
|
||||
|
||||
**WRITE IMMEDIATELY TO DOCUMENT**
|
||||
|
||||
Prepare industry analysis with web search citations:
|
||||
|
||||
#### Content Structure:
|
||||
|
||||
When saving to document, append these Level 2 and Level 3 sections:
|
||||
|
||||
```markdown
|
||||
## Industry Analysis
|
||||
|
||||
### Market Size and Valuation
|
||||
|
||||
[Market size analysis with source citations]
|
||||
_Total Market Size: [Current market valuation]_
|
||||
_Growth Rate: [CAGR and market growth projections]_
|
||||
_Market Segments: [Size and value of key market segments]_
|
||||
_Economic Impact: [Economic contribution and value creation]_
|
||||
_Source: [URL]_
|
||||
|
||||
### Market Dynamics and Growth
|
||||
|
||||
[Market dynamics analysis with source citations]
|
||||
_Growth Drivers: [Key factors driving market growth]_
|
||||
_Growth Barriers: [Factors limiting market expansion]_
|
||||
_Cyclical Patterns: [Industry seasonality and cycles]_
|
||||
_Market Maturity: [Life cycle stage and development phase]_
|
||||
_Source: [URL]_
|
||||
|
||||
### Market Structure and Segmentation
|
||||
|
||||
[Market structure analysis with source citations]
|
||||
_Primary Segments: [Key market segments and their characteristics]_
|
||||
_Sub-segment Analysis: [Detailed breakdown of market sub-segments]_
|
||||
_Geographic Distribution: [Regional market variations and concentrations]_
|
||||
_Vertical Integration: [Supply chain and value chain structure]_
|
||||
_Source: [URL]_
|
||||
|
||||
### Industry Trends and Evolution
|
||||
|
||||
[Industry trends analysis with source citations]
|
||||
_Emerging Trends: [Current industry developments and transformations]_
|
||||
_Historical Evolution: [Industry development over recent years]_
|
||||
_Technology Integration: [How technology is changing the industry]_
|
||||
_Future Outlook: [Projected industry developments and changes]_
|
||||
_Source: [URL]_
|
||||
|
||||
### Competitive Dynamics
|
||||
|
||||
[Competitive dynamics analysis with source citations]
|
||||
_Market Concentration: [Level of market consolidation and competition]_
|
||||
_Competitive Intensity: [Degree of competition and rivalry]_
|
||||
_Barriers to Entry: [Obstacles for new market entrants]_
|
||||
_Innovation Pressure: [Rate of innovation and change]_
|
||||
_Source: [URL]_
|
||||
```
|
||||
|
||||
### 5. Present Analysis and Continue Option
|
||||
|
||||
**Show analysis and present continue option:**
|
||||
|
||||
"I've completed **industry analysis** for {{research_topic}}.
|
||||
|
||||
**Key Industry Findings:**
|
||||
|
||||
- Market size and valuation thoroughly analyzed
|
||||
- Growth dynamics and market structure documented
|
||||
- Industry trends and evolution patterns identified
|
||||
- Competitive dynamics clearly mapped
|
||||
- Multiple sources verified for critical insights
|
||||
|
||||
**Ready to proceed to competitive landscape analysis?**
|
||||
[C] Continue - Save this to document and proceed to competitive landscape
|
||||
|
||||
### 6. Handle Continue Selection
|
||||
|
||||
#### If 'C' (Continue):
|
||||
|
||||
- **CONTENT ALREADY WRITTEN TO DOCUMENT**
|
||||
- Update frontmatter: `stepsCompleted: [1, 2]`
|
||||
- Load: `./step-03-competitive-landscape.md`
|
||||
|
||||
## APPEND TO DOCUMENT:
|
||||
|
||||
Content is already written to document when generated in step 4. No additional append needed.
|
||||
|
||||
## SUCCESS METRICS:
|
||||
|
||||
✅ Market size and valuation thoroughly analyzed
|
||||
✅ Growth dynamics and market structure documented
|
||||
✅ Industry trends and evolution patterns identified
|
||||
✅ Competitive dynamics clearly mapped
|
||||
✅ Multiple sources verified for critical insights
|
||||
✅ Content written immediately to document
|
||||
✅ [C] continue option presented and handled correctly
|
||||
✅ Proper routing to next step (competitive landscape)
|
||||
✅ Research goals alignment maintained
|
||||
|
||||
## FAILURE MODES:
|
||||
|
||||
❌ Relying on training data instead of web search for current facts
|
||||
❌ Missing critical market size or growth data
|
||||
❌ Incomplete market structure analysis
|
||||
❌ Not identifying key industry trends
|
||||
❌ Not writing content immediately to document
|
||||
❌ Not presenting [C] continue option after content generation
|
||||
❌ Not routing to competitive landscape step
|
||||
|
||||
❌ **CRITICAL**: Reading only partial step file - leads to incomplete understanding and poor decisions
|
||||
❌ **CRITICAL**: Proceeding with 'C' without fully reading and understanding the next step file
|
||||
❌ **CRITICAL**: Making decisions without complete understanding of step requirements and protocols
|
||||
|
||||
## INDUSTRY RESEARCH PROTOCOLS:
|
||||
|
||||
- Research market research reports and industry analyses
|
||||
- Use authoritative sources (market research firms, industry associations)
|
||||
- Analyze market size, growth rates, and segmentation data
|
||||
- Study industry trends and evolution patterns
|
||||
- Search the web to verify facts
|
||||
- Present conflicting information when sources disagree
|
||||
- Apply confidence levels appropriately
|
||||
|
||||
## INDUSTRY ANALYSIS STANDARDS:
|
||||
|
||||
- Always cite URLs for web search results
|
||||
- Use authoritative industry research sources
|
||||
- Note data currency and potential limitations
|
||||
- Present multiple perspectives when sources conflict
|
||||
- Apply confidence levels to uncertain data
|
||||
- Focus on actionable industry insights
|
||||
|
||||
## NEXT STEP:
|
||||
|
||||
After user selects 'C', load `./step-03-competitive-landscape.md` to analyze competitive landscape, key players, and ecosystem analysis for {{research_topic}}.
|
||||
|
||||
Remember: Always write research content to document immediately and search the web to verify facts!
|
||||
-238
@@ -1,238 +0,0 @@
|
||||
# Domain Research Step 3: Competitive Landscape
|
||||
|
||||
## MANDATORY EXECUTION RULES (READ FIRST):
|
||||
|
||||
- 🛑 NEVER generate content without web search verification
|
||||
|
||||
- 📖 CRITICAL: ALWAYS read the complete step file before taking any action - partial understanding leads to incomplete decisions
|
||||
- 🔄 CRITICAL: When loading next step with 'C', ensure the entire file is read and understood before proceeding
|
||||
- ✅ Search the web to verify and supplement your knowledge with current facts
|
||||
- 📋 YOU ARE A COMPETITIVE ANALYST, not content generator
|
||||
- 💬 FOCUS on key players, market share, and competitive dynamics
|
||||
- 🔍 WEB SEARCH REQUIRED - verify current facts against live sources
|
||||
- 📝 WRITE CONTENT IMMEDIATELY TO DOCUMENT
|
||||
- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
|
||||
|
||||
## EXECUTION PROTOCOLS:
|
||||
|
||||
- 🎯 Show web search analysis before presenting findings
|
||||
- ⚠️ Present [C] continue option after competitive analysis content generation
|
||||
- 📝 WRITE COMPETITIVE ANALYSIS TO DOCUMENT IMMEDIATELY
|
||||
- 💾 ONLY proceed when user chooses C (Continue)
|
||||
- 📖 Update frontmatter `stepsCompleted: [1, 2, 3]` before loading next step
|
||||
- 🚫 FORBIDDEN to load next step until C is selected
|
||||
|
||||
## CONTEXT BOUNDARIES:
|
||||
|
||||
- Current document and frontmatter from previous steps are available
|
||||
- **Research topic = "{{research_topic}}"** - established from initial discussion
|
||||
- **Research goals = "{{research_goals}}"** - established from initial discussion
|
||||
- Focus on key players, market share, and competitive dynamics
|
||||
- Web search capabilities with source verification are enabled
|
||||
|
||||
## YOUR TASK:
|
||||
|
||||
Conduct competitive landscape analysis focusing on key players, market share, and competitive dynamics. Search the web to verify and supplement current facts.
|
||||
|
||||
## COMPETITIVE LANDSCAPE ANALYSIS SEQUENCE:
|
||||
|
||||
### 1. Begin Competitive Landscape Analysis
|
||||
|
||||
**UTILIZE SUBPROCESSES AND SUBAGENTS**: Use research subagents, subprocesses or parallel processing if available to thoroughly analyze different competitive areas simultaneously and thoroughly.
|
||||
|
||||
Start with competitive research approach:
|
||||
"Now I'll conduct **competitive landscape analysis** for **{{research_topic}}** to understand the competitive ecosystem.
|
||||
|
||||
**Competitive Landscape Focus:**
|
||||
|
||||
- Key players and market leaders
|
||||
- Market share and competitive positioning
|
||||
- Competitive strategies and differentiation
|
||||
- Business models and value propositions
|
||||
- Entry barriers and competitive dynamics
|
||||
|
||||
**Let me search for current competitive insights.**"
|
||||
|
||||
### 2. Parallel Competitive Research Execution
|
||||
|
||||
**Execute multiple web searches simultaneously:**
|
||||
|
||||
Search the web: "{{research_topic}} key players market leaders"
|
||||
Search the web: "{{research_topic}} market share competitive landscape"
|
||||
Search the web: "{{research_topic}} competitive strategies differentiation"
|
||||
Search the web: "{{research_topic}} entry barriers competitive dynamics"
|
||||
|
||||
**Analysis approach:**
|
||||
|
||||
- Look for recent competitive intelligence reports and market analyses
|
||||
- Search for company websites, annual reports, and investor presentations
|
||||
- Research market share data and competitive positioning
|
||||
- Analyze competitive strategies and differentiation approaches
|
||||
- Study entry barriers and competitive dynamics
|
||||
|
||||
### 3. Analyze and Aggregate Results
|
||||
|
||||
**Collect and analyze findings from all parallel searches:**
|
||||
|
||||
"After executing comprehensive parallel web searches, let me analyze and aggregate competitive findings:
|
||||
|
||||
**Research Coverage:**
|
||||
|
||||
- Key players and market leaders analysis
|
||||
- Market share and competitive positioning assessment
|
||||
- Competitive strategies and differentiation mapping
|
||||
- Entry barriers and competitive dynamics evaluation
|
||||
|
||||
**Cross-Competitive Analysis:**
|
||||
[Identify patterns connecting players, strategies, and market dynamics]
|
||||
|
||||
**Quality Assessment:**
|
||||
[Overall confidence levels and research gaps identified]"
|
||||
|
||||
### 4. Generate Competitive Landscape Content
|
||||
|
||||
**WRITE IMMEDIATELY TO DOCUMENT**
|
||||
|
||||
Prepare competitive landscape analysis with web search citations:
|
||||
|
||||
#### Content Structure:
|
||||
|
||||
When saving to document, append these Level 2 and Level 3 sections:
|
||||
|
||||
```markdown
|
||||
## Competitive Landscape
|
||||
|
||||
### Key Players and Market Leaders
|
||||
|
||||
[Key players analysis with source citations]
|
||||
_Market Leaders: [Dominant players and their market positions]_
|
||||
_Major Competitors: [Significant competitors and their specialties]_
|
||||
_Emerging Players: [New entrants and innovative companies]_
|
||||
_Global vs Regional: [Geographic distribution of key players]_
|
||||
_Source: [URL]_
|
||||
|
||||
### Market Share and Competitive Positioning
|
||||
|
||||
[Market share analysis with source citations]
|
||||
_Market Share Distribution: [Current market share breakdown]_
|
||||
_Competitive Positioning: [How players position themselves in the market]_
|
||||
_Value Proposition Mapping: [Different value propositions across players]_
|
||||
_Customer Segments Served: [Different customer bases by competitor]_
|
||||
_Source: [URL]_
|
||||
|
||||
### Competitive Strategies and Differentiation
|
||||
|
||||
[Competitive strategies analysis with source citations]
|
||||
_Cost Leadership Strategies: [Players competing on price and efficiency]_
|
||||
_Differentiation Strategies: [Players competing on unique value]_
|
||||
_Focus/Niche Strategies: [Players targeting specific segments]_
|
||||
_Innovation Approaches: [How different players innovate]_
|
||||
_Source: [URL]_
|
||||
|
||||
### Business Models and Value Propositions
|
||||
|
||||
[Business models analysis with source citations]
|
||||
_Primary Business Models: [How competitors make money]_
|
||||
_Revenue Streams: [Different approaches to monetization]_
|
||||
_Value Chain Integration: [Vertical integration vs partnership models]_
|
||||
_Customer Relationship Models: [How competitors build customer loyalty]_
|
||||
_Source: [URL]_
|
||||
|
||||
### Competitive Dynamics and Entry Barriers
|
||||
|
||||
[Competitive dynamics analysis with source citations]
|
||||
_Barriers to Entry: [Obstacles facing new market entrants]_
|
||||
_Competitive Intensity: [Level of rivalry and competitive pressure]_
|
||||
_Market Consolidation Trends: [M&A activity and market concentration]_
|
||||
_Switching Costs: [Costs for customers to switch between providers]_
|
||||
_Source: [URL]_
|
||||
|
||||
### Ecosystem and Partnership Analysis
|
||||
|
||||
[Ecosystem analysis with source citations]
|
||||
_Supplier Relationships: [Key supplier partnerships and dependencies]_
|
||||
_Distribution Channels: [How competitors reach customers]_
|
||||
_Technology Partnerships: [Strategic technology alliances]_
|
||||
_Ecosystem Control: [Who controls key parts of the value chain]_
|
||||
_Source: [URL]_
|
||||
```
|
||||
|
||||
### 5. Present Analysis and Continue Option
|
||||
|
||||
**Show analysis and present continue option:**
|
||||
|
||||
"I've completed **competitive landscape analysis** for {{research_topic}}.
|
||||
|
||||
**Key Competitive Findings:**
|
||||
|
||||
- Key players and market leaders thoroughly identified
|
||||
- Market share and competitive positioning clearly mapped
|
||||
- Competitive strategies and differentiation analyzed
|
||||
- Business models and value propositions documented
|
||||
- Competitive dynamics and entry barriers evaluated
|
||||
|
||||
**Ready to proceed to regulatory focus analysis?**
|
||||
[C] Continue - Save this to document and proceed to regulatory focus
|
||||
|
||||
### 6. Handle Continue Selection
|
||||
|
||||
#### If 'C' (Continue):
|
||||
|
||||
- **CONTENT ALREADY WRITTEN TO DOCUMENT**
|
||||
- Update frontmatter: `stepsCompleted: [1, 2, 3]`
|
||||
- Load: `./step-04-regulatory-focus.md`
|
||||
|
||||
## APPEND TO DOCUMENT:
|
||||
|
||||
Content is already written to document when generated in step 4. No additional append needed.
|
||||
|
||||
## SUCCESS METRICS:
|
||||
|
||||
✅ Key players and market leaders thoroughly identified
|
||||
✅ Market share and competitive positioning clearly mapped
|
||||
✅ Competitive strategies and differentiation analyzed
|
||||
✅ Business models and value propositions documented
|
||||
✅ Competitive dynamics and entry barriers evaluated
|
||||
✅ Content written immediately to document
|
||||
✅ [C] continue option presented and handled correctly
|
||||
✅ Proper routing to next step (regulatory focus)
|
||||
✅ Research goals alignment maintained
|
||||
|
||||
## FAILURE MODES:
|
||||
|
||||
❌ Relying on training data instead of web search for current facts
|
||||
❌ Missing critical key players or market leaders
|
||||
❌ Incomplete market share or positioning analysis
|
||||
❌ Not identifying competitive strategies
|
||||
❌ Not writing content immediately to document
|
||||
❌ Not presenting [C] continue option after content generation
|
||||
❌ Not routing to regulatory focus step
|
||||
|
||||
❌ **CRITICAL**: Reading only partial step file - leads to incomplete understanding and poor decisions
|
||||
❌ **CRITICAL**: Proceeding with 'C' without fully reading and understanding the next step file
|
||||
❌ **CRITICAL**: Making decisions without complete understanding of step requirements and protocols
|
||||
|
||||
## COMPETITIVE RESEARCH PROTOCOLS:
|
||||
|
||||
- Research competitive intelligence reports and market analyses
|
||||
- Use company websites, annual reports, and investor presentations
|
||||
- Analyze market share data and competitive positioning
|
||||
- Study competitive strategies and differentiation approaches
|
||||
- Search the web to verify facts
|
||||
- Present conflicting information when sources disagree
|
||||
- Apply confidence levels appropriately
|
||||
|
||||
## COMPETITIVE ANALYSIS STANDARDS:
|
||||
|
||||
- Always cite URLs for web search results
|
||||
- Use authoritative competitive intelligence sources
|
||||
- Note data currency and potential limitations
|
||||
- Present multiple perspectives when sources conflict
|
||||
- Apply confidence levels to uncertain data
|
||||
- Focus on actionable competitive insights
|
||||
|
||||
## NEXT STEP:
|
||||
|
||||
After user selects 'C', load `./step-04-regulatory-focus.md` to analyze regulatory requirements, compliance frameworks, and legal considerations for {{research_topic}}.
|
||||
|
||||
Remember: Always write research content to document immediately and search the web to verify facts!
|
||||
-206
@@ -1,206 +0,0 @@
|
||||
# Domain Research Step 4: Regulatory Focus
|
||||
|
||||
## MANDATORY EXECUTION RULES (READ FIRST):
|
||||
|
||||
- 🛑 NEVER generate content without web search verification
|
||||
|
||||
- 📖 CRITICAL: ALWAYS read the complete step file before taking any action - partial understanding leads to incomplete decisions
|
||||
- 🔄 CRITICAL: When loading next step with 'C', ensure the entire file is read and understood before proceeding
|
||||
- ✅ Search the web to verify and supplement your knowledge with current facts
|
||||
- 📋 YOU ARE A REGULATORY ANALYST, not content generator
|
||||
- 💬 FOCUS on compliance requirements and regulatory landscape
|
||||
- 🔍 WEB SEARCH REQUIRED - verify current facts against live sources
|
||||
- 📝 WRITE CONTENT IMMEDIATELY TO DOCUMENT
|
||||
- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
|
||||
|
||||
## EXECUTION PROTOCOLS:
|
||||
|
||||
- 🎯 Show web search analysis before presenting findings
|
||||
- ⚠️ Present [C] continue option after regulatory content generation
|
||||
- 📝 WRITE REGULATORY ANALYSIS TO DOCUMENT IMMEDIATELY
|
||||
- 💾 ONLY save when user chooses C (Continue)
|
||||
- 📖 Update frontmatter `stepsCompleted: [1, 2, 3, 4]` before loading next step
|
||||
- 🚫 FORBIDDEN to load next step until C is selected
|
||||
|
||||
## CONTEXT BOUNDARIES:
|
||||
|
||||
- Current document and frontmatter from previous steps are available
|
||||
- **Research topic = "{{research_topic}}"** - established from initial discussion
|
||||
- **Research goals = "{{research_goals}}"** - established from initial discussion
|
||||
- Focus on regulatory and compliance requirements for the domain
|
||||
- Web search capabilities with source verification are enabled
|
||||
|
||||
## YOUR TASK:
|
||||
|
||||
Conduct focused regulatory and compliance analysis with emphasis on requirements that impact {{research_topic}}. Search the web to verify and supplement current facts.
|
||||
|
||||
## REGULATORY FOCUS SEQUENCE:
|
||||
|
||||
### 1. Begin Regulatory Analysis
|
||||
|
||||
Start with regulatory research approach:
|
||||
"Now I'll focus on **regulatory and compliance requirements** that impact **{{research_topic}}**.
|
||||
|
||||
**Regulatory Focus Areas:**
|
||||
|
||||
- Specific regulations and compliance frameworks
|
||||
- Industry standards and best practices
|
||||
- Licensing and certification requirements
|
||||
- Data protection and privacy regulations
|
||||
- Environmental and safety requirements
|
||||
|
||||
**Let me search for current regulatory requirements.**"
|
||||
|
||||
### 2. Web Search for Specific Regulations
|
||||
|
||||
Search for current regulatory information:
|
||||
Search the web: "{{research_topic}} regulations compliance requirements"
|
||||
|
||||
**Regulatory focus:**
|
||||
|
||||
- Specific regulations applicable to the domain
|
||||
- Compliance frameworks and standards
|
||||
- Recent regulatory changes or updates
|
||||
- Enforcement agencies and oversight bodies
|
||||
|
||||
### 3. Web Search for Industry Standards
|
||||
|
||||
Search for current industry standards:
|
||||
Search the web: "{{research_topic}} standards best practices"
|
||||
|
||||
**Standards focus:**
|
||||
|
||||
- Industry-specific technical standards
|
||||
- Best practices and guidelines
|
||||
- Certification requirements
|
||||
- Quality assurance frameworks
|
||||
|
||||
### 4. Web Search for Data Privacy Requirements
|
||||
|
||||
Search for current privacy regulations:
|
||||
Search the web: "data privacy regulations {{research_topic}}"
|
||||
|
||||
**Privacy focus:**
|
||||
|
||||
- GDPR, CCPA, and other data protection laws
|
||||
- Industry-specific privacy requirements
|
||||
- Data governance and security standards
|
||||
- User consent and data handling requirements
|
||||
|
||||
### 5. Generate Regulatory Analysis Content
|
||||
|
||||
Prepare regulatory content with source citations:
|
||||
|
||||
#### Content Structure:
|
||||
|
||||
When saving to document, append these Level 2 and Level 3 sections:
|
||||
|
||||
```markdown
|
||||
## Regulatory Requirements
|
||||
|
||||
### Applicable Regulations
|
||||
|
||||
[Specific regulations analysis with source citations]
|
||||
_Source: [URL]_
|
||||
|
||||
### Industry Standards and Best Practices
|
||||
|
||||
[Industry standards analysis with source citations]
|
||||
_Source: [URL]_
|
||||
|
||||
### Compliance Frameworks
|
||||
|
||||
[Compliance frameworks analysis with source citations]
|
||||
_Source: [URL]_
|
||||
|
||||
### Data Protection and Privacy
|
||||
|
||||
[Privacy requirements analysis with source citations]
|
||||
_Source: [URL]_
|
||||
|
||||
### Licensing and Certification
|
||||
|
||||
[Licensing requirements analysis with source citations]
|
||||
_Source: [URL]_
|
||||
|
||||
### Implementation Considerations
|
||||
|
||||
[Practical implementation considerations with source citations]
|
||||
_Source: [URL]_
|
||||
|
||||
### Risk Assessment
|
||||
|
||||
[Regulatory and compliance risk assessment]
|
||||
```
|
||||
|
||||
### 6. Present Analysis and Continue Option
|
||||
|
||||
Show the generated regulatory analysis and present continue option:
|
||||
"I've completed **regulatory requirements analysis** for {{research_topic}}.
|
||||
|
||||
**Key Regulatory Findings:**
|
||||
|
||||
- Specific regulations and frameworks identified
|
||||
- Industry standards and best practices mapped
|
||||
- Compliance requirements clearly documented
|
||||
- Implementation considerations provided
|
||||
- Risk assessment completed
|
||||
|
||||
**Ready to proceed to technical trends?**
|
||||
[C] Continue - Save this to the document and move to technical trends
|
||||
|
||||
### 7. Handle Continue Selection
|
||||
|
||||
#### If 'C' (Continue):
|
||||
|
||||
- **CONTENT ALREADY WRITTEN TO DOCUMENT**
|
||||
- Update frontmatter: `stepsCompleted: [1, 2, 3, 4]`
|
||||
- Load: `./step-05-technical-trends.md`
|
||||
|
||||
## APPEND TO DOCUMENT:
|
||||
|
||||
Content is already written to document when generated in step 5. No additional append needed.
|
||||
|
||||
## SUCCESS METRICS:
|
||||
|
||||
✅ Applicable regulations identified with current citations
|
||||
✅ Industry standards and best practices documented
|
||||
✅ Compliance frameworks clearly mapped
|
||||
✅ Data protection requirements analyzed
|
||||
✅ Implementation considerations provided
|
||||
✅ [C] continue option presented and handled correctly
|
||||
✅ Content properly appended to document when C selected
|
||||
|
||||
## FAILURE MODES:
|
||||
|
||||
❌ Relying on training data instead of web search for current facts
|
||||
❌ Missing critical regulatory requirements for the domain
|
||||
❌ Not providing implementation considerations for compliance
|
||||
❌ Not completing risk assessment for regulatory compliance
|
||||
❌ Not presenting [C] continue option after content generation
|
||||
❌ Appending content without user selecting 'C'
|
||||
|
||||
❌ **CRITICAL**: Reading only partial step file - leads to incomplete understanding and poor decisions
|
||||
❌ **CRITICAL**: Proceeding with 'C' without fully reading and understanding the next step file
|
||||
❌ **CRITICAL**: Making decisions without complete understanding of step requirements and protocols
|
||||
|
||||
## REGULATORY RESEARCH PROTOCOLS:
|
||||
|
||||
- Search for specific regulations by name and number
|
||||
- Identify regulatory bodies and enforcement agencies
|
||||
- Research recent regulatory changes and updates
|
||||
- Map industry standards to regulatory requirements
|
||||
- Consider regional and jurisdictional differences
|
||||
|
||||
## SOURCE VERIFICATION:
|
||||
|
||||
- Always cite regulatory agency websites
|
||||
- Use official government and industry association sources
|
||||
- Note effective dates and implementation timelines
|
||||
- Present compliance requirement levels and obligations
|
||||
|
||||
## NEXT STEP:
|
||||
|
||||
After user selects 'C' and content is saved to document, load `./step-05-technical-trends.md` to analyze technical trends and innovations in the domain.
|
||||
|
||||
Remember: Search the web to verify regulatory facts and provide practical implementation considerations!
|
||||
-234
@@ -1,234 +0,0 @@
|
||||
# Domain Research Step 5: Technical Trends
|
||||
|
||||
## MANDATORY EXECUTION RULES (READ FIRST):
|
||||
|
||||
- 🛑 NEVER generate content without web search verification
|
||||
|
||||
- 📖 CRITICAL: ALWAYS read the complete step file before taking any action - partial understanding leads to incomplete decisions
|
||||
- 🔄 CRITICAL: When loading next step with 'C', ensure the entire file is read and understood before proceeding
|
||||
- ✅ Search the web to verify and supplement your knowledge with current facts
|
||||
- 📋 YOU ARE A TECHNOLOGY ANALYST, not content generator
|
||||
- 💬 FOCUS on emerging technologies and innovation patterns
|
||||
- 🔍 WEB SEARCH REQUIRED - verify current facts against live sources
|
||||
- 📝 WRITE CONTENT IMMEDIATELY TO DOCUMENT
|
||||
- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
|
||||
|
||||
## EXECUTION PROTOCOLS:
|
||||
|
||||
- 🎯 Show web search analysis before presenting findings
|
||||
- ⚠️ Present [C] continue option after technical trends content generation
|
||||
- 📝 WRITE TECHNICAL TRENDS ANALYSIS TO DOCUMENT IMMEDIATELY
|
||||
- 💾 ONLY proceed when user chooses C (Continue)
|
||||
- 📖 Update frontmatter `stepsCompleted: [1, 2, 3, 4, 5]` before loading next step
|
||||
- 🚫 FORBIDDEN to load next step until C is selected
|
||||
|
||||
## CONTEXT BOUNDARIES:
|
||||
|
||||
- Current document and frontmatter from previous steps are available
|
||||
- **Research topic = "{{research_topic}}"** - established from initial discussion
|
||||
- **Research goals = "{{research_goals}}"** - established from initial discussion
|
||||
- Focus on emerging technologies and innovation patterns in the domain
|
||||
- Web search capabilities with source verification are enabled
|
||||
|
||||
## YOUR TASK:
|
||||
|
||||
Conduct comprehensive technical trends analysis using current web data with emphasis on innovations and emerging technologies impacting {{research_topic}}.
|
||||
|
||||
## TECHNICAL TRENDS SEQUENCE:
|
||||
|
||||
### 1. Begin Technical Trends Analysis
|
||||
|
||||
Start with technology research approach:
|
||||
"Now I'll conduct **technical trends and emerging technologies** analysis for **{{research_topic}}** using current data.
|
||||
|
||||
**Technical Trends Focus:**
|
||||
|
||||
- Emerging technologies and innovations
|
||||
- Digital transformation impacts
|
||||
- Automation and efficiency improvements
|
||||
- New business models enabled by technology
|
||||
- Future technology projections and roadmaps
|
||||
|
||||
**Let me search for current technology developments.**"
|
||||
|
||||
### 2. Web Search for Emerging Technologies
|
||||
|
||||
Search for current technology information:
|
||||
Search the web: "{{research_topic}} emerging technologies innovations"
|
||||
|
||||
**Technology focus:**
|
||||
|
||||
- AI, machine learning, and automation impacts
|
||||
- Digital transformation trends
|
||||
- New technologies disrupting the industry
|
||||
- Innovation patterns and breakthrough developments
|
||||
|
||||
### 3. Web Search for Digital Transformation
|
||||
|
||||
Search for current transformation trends:
|
||||
Search the web: "{{research_topic}} digital transformation trends"
|
||||
|
||||
**Transformation focus:**
|
||||
|
||||
- Digital adoption trends and rates
|
||||
- Business model evolution
|
||||
- Customer experience innovations
|
||||
- Operational efficiency improvements
|
||||
|
||||
### 4. Web Search for Future Outlook
|
||||
|
||||
Search for future projections:
|
||||
Search the web: "{{research_topic}} future outlook trends"
|
||||
|
||||
**Future focus:**
|
||||
|
||||
- Technology roadmaps and projections
|
||||
- Market evolution predictions
|
||||
- Innovation pipelines and R&D trends
|
||||
- Long-term industry transformation
|
||||
|
||||
### 5. Generate Technical Trends Content
|
||||
|
||||
**WRITE IMMEDIATELY TO DOCUMENT**
|
||||
|
||||
Prepare technical analysis with source citations:
|
||||
|
||||
#### Content Structure:
|
||||
|
||||
When saving to document, append these Level 2 and Level 3 sections:
|
||||
|
||||
```markdown
|
||||
## Technical Trends and Innovation
|
||||
|
||||
### Emerging Technologies
|
||||
|
||||
[Emerging technologies analysis with source citations]
|
||||
_Source: [URL]_
|
||||
|
||||
### Digital Transformation
|
||||
|
||||
[Digital transformation analysis with source citations]
|
||||
_Source: [URL]_
|
||||
|
||||
### Innovation Patterns
|
||||
|
||||
[Innovation patterns analysis with source citations]
|
||||
_Source: [URL]_
|
||||
|
||||
### Future Outlook
|
||||
|
||||
[Future outlook and projections with source citations]
|
||||
_Source: [URL]_
|
||||
|
||||
### Implementation Opportunities
|
||||
|
||||
[Implementation opportunity analysis with source citations]
|
||||
_Source: [URL]_
|
||||
|
||||
### Challenges and Risks
|
||||
|
||||
[Challenges and risks assessment with source citations]
|
||||
_Source: [URL]_
|
||||
|
||||
## Recommendations
|
||||
|
||||
### Technology Adoption Strategy
|
||||
|
||||
[Technology adoption recommendations]
|
||||
|
||||
### Innovation Roadmap
|
||||
|
||||
[Innovation roadmap suggestions]
|
||||
|
||||
### Risk Mitigation
|
||||
|
||||
[Risk mitigation strategies]
|
||||
```
|
||||
|
||||
### 6. Present Analysis and Complete Option
|
||||
|
||||
Show the generated technical analysis and present complete option:
|
||||
"I've completed **technical trends and innovation analysis** for {{research_topic}}.
|
||||
|
||||
**Technical Highlights:**
|
||||
|
||||
- Emerging technologies and innovations identified
|
||||
- Digital transformation trends mapped
|
||||
- Future outlook and projections analyzed
|
||||
- Implementation opportunities and challenges documented
|
||||
- Practical recommendations provided
|
||||
|
||||
**Technical Trends Research Completed:**
|
||||
|
||||
- Emerging technologies and innovations identified
|
||||
- Digital transformation trends mapped
|
||||
- Future outlook and projections analyzed
|
||||
- Implementation opportunities and challenges documented
|
||||
|
||||
**Ready to proceed to research synthesis and recommendations?**
|
||||
[C] Continue - Save this to document and proceed to synthesis
|
||||
|
||||
### 7. Handle Continue Selection
|
||||
|
||||
#### If 'C' (Continue):
|
||||
|
||||
- **CONTENT ALREADY WRITTEN TO DOCUMENT**
|
||||
- Update frontmatter: `stepsCompleted: [1, 2, 3, 4, 5]`
|
||||
- Load: `./step-06-research-synthesis.md`
|
||||
|
||||
## APPEND TO DOCUMENT:
|
||||
|
||||
Content is already written to document when generated in step 5. No additional append needed.
|
||||
|
||||
## SUCCESS METRICS:
|
||||
|
||||
✅ Emerging technologies identified with current data
|
||||
✅ Digital transformation trends clearly documented
|
||||
✅ Future outlook and projections analyzed
|
||||
✅ Implementation opportunities and challenges mapped
|
||||
✅ Strategic recommendations provided
|
||||
✅ Content written immediately to document
|
||||
✅ [C] continue option presented and handled correctly
|
||||
✅ Proper routing to next step (research synthesis)
|
||||
✅ Research goals alignment maintained
|
||||
|
||||
## FAILURE MODES:
|
||||
|
||||
❌ Relying solely on training data without web verification for current facts
|
||||
❌ Missing critical emerging technologies in the domain
|
||||
❌ Not providing practical implementation recommendations
|
||||
❌ Not completing strategic recommendations
|
||||
❌ Not presenting completion option for research workflow
|
||||
❌ Appending content without user selecting 'C'
|
||||
|
||||
❌ **CRITICAL**: Reading only partial step file - leads to incomplete understanding and poor decisions
|
||||
❌ **CRITICAL**: Proceeding with 'C' without fully reading and understanding the next step file
|
||||
❌ **CRITICAL**: Making decisions without complete understanding of step requirements and protocols
|
||||
|
||||
## TECHNICAL RESEARCH PROTOCOLS:
|
||||
|
||||
- Search for cutting-edge technologies and innovations
|
||||
- Identify disruption patterns and game-changers
|
||||
- Research technology adoption timelines and barriers
|
||||
- Consider regional technology variations
|
||||
- Analyze competitive technological advantages
|
||||
|
||||
## RESEARCH WORKFLOW COMPLETION:
|
||||
|
||||
When 'C' is selected:
|
||||
|
||||
- All domain research steps completed
|
||||
- Comprehensive research document generated
|
||||
- All sections appended with source citations
|
||||
- Research workflow status updated
|
||||
- Final recommendations provided to user
|
||||
|
||||
## NEXT STEPS:
|
||||
|
||||
Research workflow complete. User may:
|
||||
|
||||
- Use the domain research to inform other workflows (PRD, architecture, etc.)
|
||||
- Conduct additional research on specific topics if needed
|
||||
- Move forward with product development based on research insights
|
||||
|
||||
Congratulations on completing comprehensive domain research! 🎉
|
||||
-450
@@ -1,450 +0,0 @@
|
||||
# Domain Research Step 6: Research Synthesis and Completion
|
||||
|
||||
## MANDATORY EXECUTION RULES (READ FIRST):
|
||||
|
||||
- 🛑 NEVER generate content without web search verification
|
||||
|
||||
- 📖 CRITICAL: ALWAYS read the complete step file before taking any action - partial understanding leads to incomplete decisions
|
||||
- 🔄 CRITICAL: When loading next step with 'C', ensure the entire file is read and understood before proceeding
|
||||
- ✅ Search the web to verify and supplement your knowledge with current facts
|
||||
- 📋 YOU ARE A DOMAIN RESEARCH STRATEGIST, not content generator
|
||||
- 💬 FOCUS on comprehensive synthesis and authoritative conclusions
|
||||
- 🔍 WEB SEARCH REQUIRED - verify current facts against live sources
|
||||
- 📄 PRODUCE COMPREHENSIVE DOCUMENT with narrative intro, TOC, and summary
|
||||
- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
|
||||
|
||||
## EXECUTION PROTOCOLS:
|
||||
|
||||
- 🎯 Show web search analysis before presenting findings
|
||||
- ⚠️ Present [C] complete option after synthesis content generation
|
||||
- 💾 ONLY save when user chooses C (Complete)
|
||||
- 📖 Update frontmatter `stepsCompleted: [1, 2, 3, 4, 5, 6]` before completing workflow
|
||||
- 🚫 FORBIDDEN to complete workflow until C is selected
|
||||
- 📚 GENERATE COMPLETE DOCUMENT STRUCTURE with intro, TOC, and summary
|
||||
|
||||
## CONTEXT BOUNDARIES:
|
||||
|
||||
- Current document and frontmatter from previous steps are available
|
||||
- **Research topic = "{{research_topic}}"** - comprehensive domain analysis
|
||||
- **Research goals = "{{research_goals}}"** - achieved through exhaustive research
|
||||
- All domain research sections have been completed (analysis, regulatory, technical)
|
||||
- Web search capabilities with source verification are enabled
|
||||
- This is the final synthesis step producing the complete research document
|
||||
|
||||
## YOUR TASK:
|
||||
|
||||
Produce a comprehensive, authoritative research document on **{{research_topic}}** with compelling narrative introduction, detailed TOC, and executive summary based on exhaustive domain research.
|
||||
|
||||
## COMPREHENSIVE DOCUMENT SYNTHESIS:
|
||||
|
||||
### 1. Document Structure Planning
|
||||
|
||||
**Complete Research Document Structure:**
|
||||
|
||||
```markdown
|
||||
# [Compelling Title]: Comprehensive {{research_topic}} Research
|
||||
|
||||
## Executive Summary
|
||||
|
||||
[Brief compelling overview of key findings and implications]
|
||||
|
||||
## Table of Contents
|
||||
|
||||
- Research Introduction and Methodology
|
||||
- Industry Overview and Market Dynamics
|
||||
- Technology Trends and Innovation Landscape
|
||||
- Regulatory Framework and Compliance Requirements
|
||||
- Competitive Landscape and Key Players
|
||||
- Strategic Insights and Recommendations
|
||||
- Implementation Considerations and Risk Assessment
|
||||
- Future Outlook and Strategic Opportunities
|
||||
- Research Methodology and Source Documentation
|
||||
- Appendices and Additional Resources
|
||||
```
|
||||
|
||||
### 2. Generate Compelling Narrative Introduction
|
||||
|
||||
**Introduction Requirements:**
|
||||
|
||||
- Hook reader with compelling opening about {{research_topic}}
|
||||
- Establish research significance and timeliness
|
||||
- Outline comprehensive research methodology
|
||||
- Preview key findings and strategic implications
|
||||
- Set professional, authoritative tone
|
||||
|
||||
**Web Search for Introduction Context:**
|
||||
Search the web: "{{research_topic}} significance importance"
|
||||
|
||||
### 3. Synthesize All Research Sections
|
||||
|
||||
**Section-by-Section Integration:**
|
||||
|
||||
- Combine industry analysis from step-02
|
||||
- Integrate regulatory focus from step-03
|
||||
- Incorporate technical trends from step-04
|
||||
- Add cross-sectional insights and connections
|
||||
- Ensure comprehensive coverage with no gaps
|
||||
|
||||
### 4. Generate Complete Document Content
|
||||
|
||||
#### Final Document Structure:
|
||||
|
||||
```markdown
|
||||
# [Compelling Title]: Comprehensive {{research_topic}} Domain Research
|
||||
|
||||
## Executive Summary
|
||||
|
||||
[2-3 paragraph compelling summary of the most critical findings and strategic implications for {{research_topic}} based on comprehensive current research]
|
||||
|
||||
**Key Findings:**
|
||||
|
||||
- [Most significant market dynamics]
|
||||
- [Critical regulatory considerations]
|
||||
- [Important technology trends]
|
||||
- [Strategic implications]
|
||||
|
||||
**Strategic Recommendations:**
|
||||
|
||||
- [Top 3-5 actionable recommendations based on research]
|
||||
|
||||
## Table of Contents
|
||||
|
||||
1. Research Introduction and Methodology
|
||||
2. {{research_topic}} Industry Overview and Market Dynamics
|
||||
3. Technology Landscape and Innovation Trends
|
||||
4. Regulatory Framework and Compliance Requirements
|
||||
5. Competitive Landscape and Ecosystem Analysis
|
||||
6. Strategic Insights and Domain Opportunities
|
||||
7. Implementation Considerations and Risk Assessment
|
||||
8. Future Outlook and Strategic Planning
|
||||
9. Research Methodology and Source Verification
|
||||
10. Appendices and Additional Resources
|
||||
|
||||
## 1. Research Introduction and Methodology
|
||||
|
||||
### Research Significance
|
||||
|
||||
[Compelling narrative about why {{research_topic}} research is critical right now]
|
||||
_Why this research matters now: [Strategic importance with current context]_
|
||||
_Source: [URL]_
|
||||
|
||||
### Research Methodology
|
||||
|
||||
[Comprehensive description of research approach including:]
|
||||
|
||||
- **Research Scope**: [Comprehensive coverage areas]
|
||||
- **Data Sources**: [Authoritative sources and verification approach]
|
||||
- **Analysis Framework**: [Structured analysis methodology]
|
||||
- **Time Period**: [current focus and historical context]
|
||||
- **Geographic Coverage**: [Regional/global scope]
|
||||
|
||||
### Research Goals and Objectives
|
||||
|
||||
**Original Goals:** {{research_goals}}
|
||||
|
||||
**Achieved Objectives:**
|
||||
|
||||
- [Goal 1 achievement with supporting evidence]
|
||||
- [Goal 2 achievement with supporting evidence]
|
||||
- [Additional insights discovered during research]
|
||||
|
||||
## 2. {{research_topic}} Industry Overview and Market Dynamics
|
||||
|
||||
### Market Size and Growth Projections
|
||||
|
||||
[Comprehensive market analysis synthesized from step-02 with current data]
|
||||
_Market Size: [Current market valuation]_
|
||||
_Growth Rate: [CAGR and projections]_
|
||||
_Market Drivers: [Key growth factors]_
|
||||
_Source: [URL]_
|
||||
|
||||
### Industry Structure and Value Chain
|
||||
|
||||
[Complete industry structure analysis]
|
||||
_Value Chain Components: [Detailed breakdown]_
|
||||
_Industry Segments: [Market segmentation analysis]_
|
||||
_Economic Impact: [Industry economic significance]_
|
||||
_Source: [URL]_
|
||||
|
||||
## 3. Technology Landscape and Innovation Trends
|
||||
|
||||
### Current Technology Adoption
|
||||
|
||||
[Technology trends analysis from step-04 with current context]
|
||||
_Emerging Technologies: [Key technologies affecting {{research_topic}}]_
|
||||
_Adoption Patterns: [Technology adoption rates and patterns]_
|
||||
_Innovation Drivers: [Factors driving technology change]_
|
||||
_Source: [URL]_
|
||||
|
||||
### Digital Transformation Impact
|
||||
|
||||
[Comprehensive analysis of technology's impact on {{research_topic}}]
|
||||
_Transformation Trends: [Major digital transformation patterns]_
|
||||
_Disruption Opportunities: [Technology-driven opportunities]_
|
||||
_Future Technology Outlook: [Emerging technologies and timelines]_
|
||||
_Source: [URL]_
|
||||
|
||||
## 4. Regulatory Framework and Compliance Requirements
|
||||
|
||||
### Current Regulatory Landscape
|
||||
|
||||
[Regulatory analysis from step-03 with current updates]
|
||||
_Key Regulations: [Critical regulatory requirements]_
|
||||
_Compliance Standards: [Industry standards and best practices]_
|
||||
_Recent Changes: [current regulatory updates and implications]_
|
||||
_Source: [URL]_
|
||||
|
||||
### Risk and Compliance Considerations
|
||||
|
||||
[Comprehensive risk assessment]
|
||||
_Compliance Risks: [Major regulatory and compliance risks]_
|
||||
_Risk Mitigation Strategies: [Approaches to manage regulatory risks]_
|
||||
_Future Regulatory Trends: [Anticipated regulatory developments]_
|
||||
_Source: [URL]_
|
||||
|
||||
## 5. Competitive Landscape and Ecosystem Analysis
|
||||
|
||||
### Market Positioning and Key Players
|
||||
|
||||
[Competitive analysis with current market positioning]
|
||||
_Market Leaders: [Dominant players and strategies]_
|
||||
_Emerging Competitors: [New entrants and innovative approaches]_
|
||||
_Competitive Dynamics: [Market competition patterns and trends]_
|
||||
_Source: [URL]_
|
||||
|
||||
### Ecosystem and Partnership Landscape
|
||||
|
||||
[Complete ecosystem analysis]
|
||||
_Ecosystem Players: [Key stakeholders and relationships]_
|
||||
_Partnership Opportunities: [Strategic collaboration potential]_
|
||||
_Supply Chain Dynamics: [Supply chain structure and risks]_
|
||||
_Source: [URL]_
|
||||
|
||||
## 6. Strategic Insights and Domain Opportunities
|
||||
|
||||
### Cross-Domain Synthesis
|
||||
|
||||
[Strategic insights from integrating all research sections]
|
||||
_Market-Technology Convergence: [How technology and market forces interact]_
|
||||
_Regulatory-Strategic Alignment: [How regulatory environment shapes strategy]_
|
||||
_Competitive Positioning Opportunities: [Strategic advantages based on research]_
|
||||
_Source: [URL]_
|
||||
|
||||
### Strategic Opportunities
|
||||
|
||||
[High-value opportunities identified through comprehensive research]
|
||||
_Market Opportunities: [Specific market entry or expansion opportunities]_
|
||||
_Technology Opportunities: [Technology adoption or innovation opportunities]_
|
||||
_Partnership Opportunities: [Strategic collaboration and partnership potential]_
|
||||
_Source: [URL]_
|
||||
|
||||
## 7. Implementation Considerations and Risk Assessment
|
||||
|
||||
### Implementation Framework
|
||||
|
||||
[Practical implementation guidance based on research findings]
|
||||
_Implementation Timeline: [Recommended phased approach]_
|
||||
_Resource Requirements: [Key resources and capabilities needed]_
|
||||
_Success Factors: [Critical success factors for implementation]_
|
||||
_Source: [URL]_
|
||||
|
||||
### Risk Management and Mitigation
|
||||
|
||||
[Comprehensive risk assessment and mitigation strategies]
|
||||
_Implementation Risks: [Major risks and mitigation approaches]_
|
||||
_Market Risks: [Market-related risks and contingency plans]_
|
||||
_Technology Risks: [Technology adoption and implementation risks]_
|
||||
_Source: [URL]_
|
||||
|
||||
## 8. Future Outlook and Strategic Planning
|
||||
|
||||
### Future Trends and Projections
|
||||
|
||||
[Forward-looking analysis based on comprehensive research]
|
||||
_Near-term Outlook: [1-2 year projections and implications]_
|
||||
_Medium-term Trends: [3-5 year expected developments]_
|
||||
_Long-term Vision: [5+ year strategic outlook for {{research_topic}}]_
|
||||
_Source: [URL]_
|
||||
|
||||
### Strategic Recommendations
|
||||
|
||||
[Comprehensive strategic recommendations]
|
||||
_Immediate Actions: [Priority actions for next 6 months]_
|
||||
_Strategic Initiatives: [Key strategic initiatives for 1-2 years]_
|
||||
_Long-term Strategy: [Strategic positioning for 3+ years]_
|
||||
_Source: [URL]_
|
||||
|
||||
## 9. Research Methodology and Source Verification
|
||||
|
||||
### Comprehensive Source Documentation
|
||||
|
||||
[Complete documentation of all research sources]
|
||||
_Primary Sources: [Key authoritative sources used]_
|
||||
_Secondary Sources: [Supporting research and analysis]_
|
||||
_Web Search Queries: [Complete list of search queries used]_
|
||||
|
||||
### Research Quality Assurance
|
||||
|
||||
[Quality assurance and validation approach]
|
||||
_Source Verification: [All factual claims verified with multiple sources]_
|
||||
_Confidence Levels: [Confidence assessments for uncertain data]_
|
||||
_Limitations: [Research limitations and areas for further investigation]_
|
||||
_Methodology Transparency: [Complete transparency about research approach]_
|
||||
|
||||
## 10. Appendices and Additional Resources
|
||||
|
||||
### Detailed Data Tables
|
||||
|
||||
[Comprehensive data tables supporting research findings]
|
||||
_Market Data Tables: [Detailed market size, growth, and segmentation data]_
|
||||
_Technology Adoption Data: [Detailed technology adoption and trend data]_
|
||||
_Regulatory Reference Tables: [Complete regulatory requirements and compliance data]_
|
||||
|
||||
### Additional Resources
|
||||
|
||||
[Valuable resources for continued research and implementation]
|
||||
_Industry Associations: [Key industry organizations and resources]_
|
||||
_Research Organizations: [Authoritative research institutions and reports]_
|
||||
_Government Resources: [Regulatory agencies and official resources]_
|
||||
_Professional Networks: [Industry communities and knowledge sources]_
|
||||
|
||||
---
|
||||
|
||||
## Research Conclusion
|
||||
|
||||
### Summary of Key Findings
|
||||
|
||||
[Comprehensive summary of the most important research findings]
|
||||
|
||||
### Strategic Impact Assessment
|
||||
|
||||
[Assessment of strategic implications for {{research_topic}}]
|
||||
|
||||
### Next Steps Recommendations
|
||||
|
||||
[Specific next steps for leveraging this research]
|
||||
|
||||
---
|
||||
|
||||
**Research Completion Date:** {{date}}
|
||||
**Research Period:** Comprehensive analysis
|
||||
**Document Length:** As needed for comprehensive coverage
|
||||
**Source Verification:** All facts cited with sources
|
||||
**Confidence Level:** High - based on multiple authoritative sources
|
||||
|
||||
_This comprehensive research document serves as an authoritative reference on {{research_topic}} and provides strategic insights for informed decision-making._
|
||||
```
|
||||
|
||||
### 5. Present Complete Document and Final Option
|
||||
|
||||
**Document Completion Presentation:**
|
||||
|
||||
"I've completed the **comprehensive research document synthesis** for **{{research_topic}}**, producing an authoritative research document with:
|
||||
|
||||
**Document Features:**
|
||||
|
||||
- **Compelling Narrative Introduction**: Engaging opening that establishes research significance
|
||||
- **Comprehensive Table of Contents**: Complete navigation structure for easy reference
|
||||
- **Exhaustive Research Coverage**: All aspects of {{research_topic}} thoroughly analyzed
|
||||
- **Executive Summary**: Key findings and strategic implications highlighted
|
||||
- **Strategic Recommendations**: Actionable insights based on comprehensive research
|
||||
- **Complete Source Citations**: Every factual claim verified with sources
|
||||
|
||||
**Research Completeness:**
|
||||
|
||||
- Industry analysis and market dynamics fully documented
|
||||
- Technology trends and innovation landscape comprehensively covered
|
||||
- Regulatory framework and compliance requirements detailed
|
||||
- Competitive landscape and ecosystem analysis complete
|
||||
- Strategic insights and implementation guidance provided
|
||||
|
||||
**Document Standards Met:**
|
||||
|
||||
- Exhaustive research with no critical gaps
|
||||
- Professional structure and compelling narrative
|
||||
- As long as needed for comprehensive coverage
|
||||
- Multiple independent sources for all claims
|
||||
- Proper citations throughout
|
||||
|
||||
**Ready to complete this comprehensive research document?**
|
||||
[C] Complete Research - Save final comprehensive document
|
||||
|
||||
### 6. Handle Final Completion
|
||||
|
||||
#### If 'C' (Complete Research):
|
||||
|
||||
- **Replace** the template placeholder `[Research overview and methodology will be appended here]` in the `## Research Overview` section near the top of the document with a concise 2-3 paragraph overview summarizing the research scope, key findings, and a pointer to the full executive summary in the Research Synthesis section
|
||||
- Append the complete document to the research file
|
||||
- Update frontmatter: `stepsCompleted: [1, 2, 3, 4, 5]`
|
||||
- Complete the domain research workflow
|
||||
- Provide final document delivery confirmation
|
||||
|
||||
## APPEND TO DOCUMENT:
|
||||
|
||||
When user selects 'C', append the complete comprehensive research document using the full structure above. Also replace the `[Research overview and methodology will be appended here]` placeholder in the Research Overview section at the top of the document.
|
||||
|
||||
## SUCCESS METRICS:
|
||||
|
||||
✅ Compelling narrative introduction with research significance
|
||||
✅ Comprehensive table of contents with complete document structure
|
||||
✅ Exhaustive research coverage across all domain aspects
|
||||
✅ Executive summary with key findings and strategic implications
|
||||
✅ Strategic recommendations grounded in comprehensive research
|
||||
✅ Complete source verification with citations
|
||||
✅ Professional document structure and compelling narrative
|
||||
✅ [C] complete option presented and handled correctly
|
||||
✅ Domain research workflow completed with comprehensive document
|
||||
|
||||
## FAILURE MODES:
|
||||
|
||||
❌ Not producing compelling narrative introduction
|
||||
❌ Missing comprehensive table of contents
|
||||
❌ Incomplete research coverage across domain aspects
|
||||
❌ Not providing executive summary with key findings
|
||||
❌ Missing strategic recommendations based on research
|
||||
❌ Relying solely on training data without web verification for current facts
|
||||
❌ Producing document without professional structure
|
||||
❌ Not presenting completion option for final document
|
||||
|
||||
❌ **CRITICAL**: Reading only partial step file - leads to incomplete understanding and poor decisions
|
||||
❌ **CRITICAL**: Proceeding with 'C' without fully reading and understanding the next step file
|
||||
❌ **CRITICAL**: Making decisions without complete understanding of step requirements and protocols
|
||||
|
||||
## COMPREHENSIVE DOCUMENT STANDARDS:
|
||||
|
||||
This step ensures the final research document:
|
||||
|
||||
- Serves as an authoritative reference on {{research_topic}}
|
||||
- Provides compelling narrative and professional structure
|
||||
- Includes comprehensive coverage with no gaps
|
||||
- Maintains rigorous source verification standards
|
||||
- Delivers strategic insights and actionable recommendations
|
||||
- Meets professional research document quality standards
|
||||
|
||||
## DOMAIN RESEARCH WORKFLOW COMPLETION:
|
||||
|
||||
When 'C' is selected:
|
||||
|
||||
- All domain research steps completed (1-5)
|
||||
- Comprehensive domain research document generated
|
||||
- Professional document structure with intro, TOC, and summary
|
||||
- All sections appended with source citations
|
||||
- Domain research workflow status updated to complete
|
||||
- Final comprehensive research document delivered to user
|
||||
|
||||
## FINAL DELIVERABLE:
|
||||
|
||||
Complete authoritative research document on {{research_topic}} that:
|
||||
|
||||
- Establishes professional credibility through comprehensive research
|
||||
- Provides strategic insights for informed decision-making
|
||||
- Serves as reference document for continued use
|
||||
- Maintains highest research quality standards
|
||||
|
||||
## On Complete
|
||||
|
||||
Run: `python3 {project-root}/_bmad/scripts/resolve_customization.py --skill {skill-root} --key workflow.on_complete`
|
||||
|
||||
If the resolved `workflow.on_complete` is non-empty, follow it as the final terminal instruction before exiting.
|
||||
|
||||
Congratulations on completing comprehensive domain research! 🎉
|
||||
@@ -1,29 +0,0 @@
|
||||
---
|
||||
stepsCompleted: []
|
||||
inputDocuments: []
|
||||
workflowType: 'research'
|
||||
lastStep: 1
|
||||
research_type: '{{research_type}}'
|
||||
research_topic: '{{research_topic}}'
|
||||
research_goals: '{{research_goals}}'
|
||||
user_name: '{{user_name}}'
|
||||
date: '{{date}}'
|
||||
web_research_enabled: true
|
||||
source_verification: true
|
||||
---
|
||||
|
||||
# Research Report: {{research_type}}
|
||||
|
||||
**Date:** {{date}}
|
||||
**Author:** {{user_name}}
|
||||
**Research Type:** {{research_type}}
|
||||
|
||||
---
|
||||
|
||||
## Research Overview
|
||||
|
||||
[Research overview and methodology will be appended here]
|
||||
|
||||
---
|
||||
|
||||
<!-- Content will be appended sequentially through research workflow steps -->
|
||||
@@ -1,96 +0,0 @@
|
||||
---
|
||||
name: bmad-market-research
|
||||
description: 'Conduct market research on competition and customers. Use when the user says they need market research'
|
||||
---
|
||||
|
||||
# Market Research Workflow
|
||||
|
||||
**Goal:** Conduct comprehensive market research using current web data and verified sources to produce complete research documents with compelling narratives and proper citations.
|
||||
|
||||
**Your Role:** You are a market research facilitator working with an expert partner. This is a collaboration where you bring research methodology and web search capabilities, while your partner brings domain knowledge and research direction.
|
||||
|
||||
## Conventions
|
||||
|
||||
- Bare paths (e.g. `steps/step-01-init.md`) resolve from the skill root.
|
||||
- `{skill-root}` resolves to this skill's installed directory (where `customize.toml` lives).
|
||||
- `{project-root}`-prefixed paths resolve from the project working directory.
|
||||
- `{skill-name}` resolves to the skill directory's basename.
|
||||
|
||||
## PREREQUISITE
|
||||
|
||||
**⛔ Web search required.** If unavailable, abort and tell the user.
|
||||
|
||||
## On Activation
|
||||
|
||||
### Step 1: Resolve the Workflow Block
|
||||
|
||||
Run: `python3 {project-root}/_bmad/scripts/resolve_customization.py --skill {skill-root} --key workflow`
|
||||
|
||||
**If the script fails**, resolve the `workflow` block yourself by reading these three files in base → team → user order and applying the same structural merge rules as the resolver:
|
||||
|
||||
1. `{skill-root}/customize.toml` — defaults
|
||||
2. `{project-root}/_bmad/custom/{skill-name}.toml` — team overrides
|
||||
3. `{project-root}/_bmad/custom/{skill-name}.user.toml` — personal overrides
|
||||
|
||||
Any missing file is skipped. Scalars override, tables deep-merge, arrays of tables keyed by `code` or `id` replace matching entries and append new entries, and all other arrays append.
|
||||
|
||||
### Step 2: Execute Prepend Steps
|
||||
|
||||
Execute each entry in `{workflow.activation_steps_prepend}` in order before proceeding.
|
||||
|
||||
### Step 3: Load Persistent Facts
|
||||
|
||||
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.
|
||||
|
||||
### Step 4: Load Config
|
||||
|
||||
Load config from `{project-root}/_bmad/bmm/config.yaml` and resolve:
|
||||
- Use `{user_name}` for greeting
|
||||
- Use `{communication_language}` for all communications
|
||||
- Use `{document_output_language}` for output documents
|
||||
- Use `{planning_artifacts}` for output location and artifact scanning
|
||||
- Use `{project_knowledge}` for additional context scanning
|
||||
|
||||
### Step 5: Greet the User
|
||||
|
||||
Greet `{user_name}`, speaking in `{communication_language}`.
|
||||
|
||||
### Step 6: Execute Append Steps
|
||||
|
||||
Execute each entry in `{workflow.activation_steps_append}` in order.
|
||||
|
||||
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.
|
||||
|
||||
## QUICK TOPIC DISCOVERY
|
||||
|
||||
"Welcome {{user_name}}! Let's get started with your **market research**.
|
||||
|
||||
**What topic, problem, or area do you want to research?**
|
||||
|
||||
For example:
|
||||
- 'The electric vehicle market in Europe'
|
||||
- 'Plant-based food alternatives market'
|
||||
- 'Mobile payment solutions in Southeast Asia'
|
||||
- 'Or anything else you have in mind...'"
|
||||
|
||||
### Topic Clarification
|
||||
|
||||
Based on the user's topic, briefly clarify:
|
||||
1. **Core Topic**: "What exactly about [topic] are you most interested in?"
|
||||
2. **Research Goals**: "What do you hope to achieve with this research?"
|
||||
3. **Scope**: "Should we focus broadly or dive deep into specific aspects?"
|
||||
|
||||
## ROUTE TO MARKET RESEARCH STEPS
|
||||
|
||||
After gathering the topic and goals:
|
||||
|
||||
1. Set `research_type = "market"`
|
||||
2. Set `research_topic = [discovered topic from discussion]`
|
||||
3. Set `research_goals = [discovered goals from discussion]`
|
||||
4. Derive `research_topic_slug` from `{{research_topic}}`: lowercase, trim, replace whitespace with `-`, strip path separators (`/`, `\`), `..`, and any character that is not alphanumeric, `-`, or `_`. Collapse repeated `-` and strip leading/trailing `-`. If the result is empty, use `untitled`.
|
||||
5. Create the starter output file: `{planning_artifacts}/research/market-{{research_topic_slug}}-research-{{date}}.md` with exact copy of the `./research.template.md` contents
|
||||
6. Load: `./steps/step-01-init.md` with topic context
|
||||
|
||||
**Note:** The discovered topic from the discussion should be passed to the initialization step, so it doesn't need to ask "What do you want to research?" again - it can focus on refining the scope for market research.
|
||||
|
||||
**✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`**
|
||||
@@ -1,41 +0,0 @@
|
||||
# DO NOT EDIT -- overwritten on every update.
|
||||
#
|
||||
# Workflow customization surface for bmad-market-research. Mirrors the
|
||||
# agent customization shape under the [workflow] namespace.
|
||||
|
||||
[workflow]
|
||||
|
||||
# --- Configurable below. Overrides merge per BMad structural rules: ---
|
||||
# scalars: override wins • arrays (persistent_facts, activation_steps_*): append
|
||||
# arrays-of-tables with `code`/`id`: replace matching items, append new ones.
|
||||
|
||||
# Steps to run before the standard activation (config load, greet).
|
||||
# Overrides append. Use for pre-flight loads, compliance checks, etc.
|
||||
|
||||
activation_steps_prepend = []
|
||||
|
||||
# Steps to run after greet but before the workflow begins.
|
||||
# Overrides append. Use for context-heavy setup that should happen
|
||||
# once the user has been acknowledged.
|
||||
|
||||
activation_steps_append = []
|
||||
|
||||
# Persistent facts the workflow keeps in mind for the whole run
|
||||
# (standards, compliance constraints, stylistic guardrails).
|
||||
# Distinct from the runtime memory sidecar — these are static context
|
||||
# loaded on activation. Overrides append.
|
||||
#
|
||||
# Each entry is either:
|
||||
# - a literal sentence, e.g. "All briefs must include a regulatory-risk section."
|
||||
# - a file reference prefixed with `file:`, e.g. "file:{project-root}/docs/standards.md"
|
||||
# (glob patterns are supported; the file's contents are loaded and treated as facts).
|
||||
|
||||
persistent_facts = [
|
||||
"file:{project-root}/**/project-context.md",
|
||||
]
|
||||
|
||||
# Scalar: executed when the workflow reaches its terminal stage (Step 6: Research Completion),
|
||||
# after the market research document has been saved and the user selects [C] Complete.
|
||||
# Override wins. Leave empty for no custom post-completion behavior.
|
||||
|
||||
on_complete = ""
|
||||
@@ -1,29 +0,0 @@
|
||||
---
|
||||
stepsCompleted: []
|
||||
inputDocuments: []
|
||||
workflowType: 'research'
|
||||
lastStep: 1
|
||||
research_type: '{{research_type}}'
|
||||
research_topic: '{{research_topic}}'
|
||||
research_goals: '{{research_goals}}'
|
||||
user_name: '{{user_name}}'
|
||||
date: '{{date}}'
|
||||
web_research_enabled: true
|
||||
source_verification: true
|
||||
---
|
||||
|
||||
# Research Report: {{research_type}}
|
||||
|
||||
**Date:** {{date}}
|
||||
**Author:** {{user_name}}
|
||||
**Research Type:** {{research_type}}
|
||||
|
||||
---
|
||||
|
||||
## Research Overview
|
||||
|
||||
[Research overview and methodology will be appended here]
|
||||
|
||||
---
|
||||
|
||||
<!-- Content will be appended sequentially through research workflow steps -->
|
||||
@@ -1,184 +0,0 @@
|
||||
# Market Research Step 1: Market Research Initialization
|
||||
|
||||
## MANDATORY EXECUTION RULES (READ FIRST):
|
||||
|
||||
- 🛑 NEVER generate research content in init step
|
||||
- ✅ ALWAYS confirm understanding of user's research goals
|
||||
- 📋 YOU ARE A MARKET RESEARCH FACILITATOR, not content generator
|
||||
- 💬 FOCUS on clarifying scope and approach
|
||||
- 🔍 NO WEB RESEARCH in init - that's for later steps
|
||||
- 📖 CRITICAL: ALWAYS read the complete step file before taking any action - partial understanding leads to incomplete research
|
||||
- 🔄 CRITICAL: When loading next step with 'C', ensure the entire file is read and understood before proceeding
|
||||
- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
|
||||
|
||||
## EXECUTION PROTOCOLS:
|
||||
|
||||
- 🎯 Confirm research understanding before proceeding
|
||||
- ⚠️ Present [C] continue option after scope clarification
|
||||
- 💾 Write initial scope document immediately
|
||||
- 📖 Update frontmatter `stepsCompleted: [1]` before loading next step
|
||||
- 🚫 FORBIDDEN to load next step until C is selected
|
||||
|
||||
## CONTEXT BOUNDARIES:
|
||||
|
||||
- Current document and frontmatter from main workflow discovery are available
|
||||
- Research type = "market" is already set
|
||||
- **Research topic = "{{research_topic}}"** - discovered from initial discussion
|
||||
- **Research goals = "{{research_goals}}"** - captured from initial discussion
|
||||
- Focus on market research scope clarification
|
||||
- Web search capabilities are enabled for later steps
|
||||
|
||||
## YOUR TASK:
|
||||
|
||||
Initialize market research by confirming understanding of {{research_topic}} and establishing clear research scope.
|
||||
|
||||
## MARKET RESEARCH INITIALIZATION:
|
||||
|
||||
### 1. Confirm Research Understanding
|
||||
|
||||
**INITIALIZE - DO NOT RESEARCH YET**
|
||||
|
||||
Start with research confirmation:
|
||||
"I understand you want to conduct **market research** for **{{research_topic}}** with these goals: {{research_goals}}
|
||||
|
||||
**My Understanding of Your Research Needs:**
|
||||
|
||||
- **Research Topic**: {{research_topic}}
|
||||
- **Research Goals**: {{research_goals}}
|
||||
- **Research Type**: Market Research
|
||||
- **Approach**: Comprehensive market analysis with source verification
|
||||
|
||||
**Market Research Areas We'll Cover:**
|
||||
|
||||
- Market size, growth dynamics, and trends
|
||||
- Customer insights and behavior analysis
|
||||
- Competitive landscape and positioning
|
||||
- Strategic recommendations and implementation guidance
|
||||
|
||||
**Does this accurately capture what you're looking for?**"
|
||||
|
||||
### 2. Refine Research Scope
|
||||
|
||||
Gather any clarifications needed:
|
||||
|
||||
#### Scope Clarification Questions:
|
||||
|
||||
- "Are there specific customer segments or aspects of {{research_topic}} we should prioritize?"
|
||||
- "Should we focus on specific geographic regions or global market?"
|
||||
- "Is this for market entry, expansion, product development, or other business purpose?"
|
||||
- "Any competitors or market segments you specifically want us to analyze?"
|
||||
|
||||
### 3. Document Initial Scope
|
||||
|
||||
**WRITE IMMEDIATELY TO DOCUMENT**
|
||||
|
||||
Write initial research scope to document:
|
||||
|
||||
```markdown
|
||||
# Market Research: {{research_topic}}
|
||||
|
||||
## Research Initialization
|
||||
|
||||
### Research Understanding Confirmed
|
||||
|
||||
**Topic**: {{research_topic}}
|
||||
**Goals**: {{research_goals}}
|
||||
**Research Type**: Market Research
|
||||
**Date**: {{date}}
|
||||
|
||||
### Research Scope
|
||||
|
||||
**Market Analysis Focus Areas:**
|
||||
|
||||
- Market size, growth projections, and dynamics
|
||||
- Customer segments, behavior patterns, and insights
|
||||
- Competitive landscape and positioning analysis
|
||||
- Strategic recommendations and implementation guidance
|
||||
|
||||
**Research Methodology:**
|
||||
|
||||
- Current web data with source verification
|
||||
- Multiple independent sources for critical claims
|
||||
- Confidence level assessment for uncertain data
|
||||
- Comprehensive coverage with no critical gaps
|
||||
|
||||
### Next Steps
|
||||
|
||||
**Research Workflow:**
|
||||
|
||||
1. ✅ Initialization and scope setting (current step)
|
||||
2. Customer Insights and Behavior Analysis
|
||||
3. Competitive Landscape Analysis
|
||||
4. Strategic Synthesis and Recommendations
|
||||
|
||||
**Research Status**: Scope confirmed, ready to proceed with detailed market analysis
|
||||
```
|
||||
|
||||
### 4. Present Confirmation and Continue Option
|
||||
|
||||
Show initial scope document and present continue option:
|
||||
"I've documented our understanding and initial scope for **{{research_topic}}** market research.
|
||||
|
||||
**What I've established:**
|
||||
|
||||
- Research topic and goals confirmed
|
||||
- Market analysis focus areas defined
|
||||
- Research methodology verification
|
||||
- Clear workflow progression
|
||||
|
||||
**Document Status:** Initial scope written to research file for your review
|
||||
|
||||
**Ready to begin detailed market research?**
|
||||
[C] Continue - Confirm scope and proceed to customer insights analysis
|
||||
[Modify] Suggest changes to research scope before proceeding
|
||||
|
||||
**HALT — wait for user response before proceeding.**
|
||||
|
||||
### 5. Handle User Response
|
||||
|
||||
#### If 'C' (Continue):
|
||||
|
||||
- Update frontmatter: `stepsCompleted: [1]`
|
||||
- Add confirmation note to document: "Scope confirmed by user on {{date}}"
|
||||
- Load: `./step-02-customer-behavior.md`
|
||||
|
||||
#### If 'Modify':
|
||||
|
||||
- Gather user changes to scope
|
||||
- Update document with modifications
|
||||
- Re-present updated scope for confirmation
|
||||
|
||||
## SUCCESS METRICS:
|
||||
|
||||
✅ Research topic and goals accurately understood
|
||||
✅ Market research scope clearly defined
|
||||
✅ Initial scope document written immediately
|
||||
✅ User opportunity to review and modify scope
|
||||
✅ [C] continue option presented and handled correctly
|
||||
✅ Document properly updated with scope confirmation
|
||||
|
||||
## FAILURE MODES:
|
||||
|
||||
❌ Not confirming understanding of research topic and goals
|
||||
❌ Generating research content instead of just scope clarification
|
||||
❌ Not writing initial scope document to file
|
||||
❌ Not providing opportunity for user to modify scope
|
||||
❌ Proceeding to next step without user confirmation
|
||||
❌ **CRITICAL**: Reading only partial step file - leads to incomplete understanding and poor research decisions
|
||||
❌ **CRITICAL**: Proceeding with 'C' without fully reading and understanding the next step file
|
||||
❌ **CRITICAL**: Making decisions without complete understanding of step requirements and protocols
|
||||
|
||||
## INITIALIZATION PRINCIPLES:
|
||||
|
||||
This step ensures:
|
||||
|
||||
- Clear mutual understanding of research objectives
|
||||
- Well-defined research scope and approach
|
||||
- Immediate documentation for user review
|
||||
- User control over research direction before detailed work begins
|
||||
|
||||
## NEXT STEP:
|
||||
|
||||
After user confirmation and scope finalization, load `./step-02-customer-behavior.md` to begin detailed market research with customer insights analysis.
|
||||
|
||||
Remember: Init steps confirm understanding and scope, not generate research content!
|
||||
-239
@@ -1,239 +0,0 @@
|
||||
# Market Research Step 2: Customer Behavior and Segments
|
||||
|
||||
## MANDATORY EXECUTION RULES (READ FIRST):
|
||||
|
||||
- 🛑 NEVER generate content without web search verification
|
||||
- ✅ Search the web to verify and supplement your knowledge with current facts
|
||||
- 📋 YOU ARE A CUSTOMER BEHAVIOR ANALYST, not content generator
|
||||
- 💬 FOCUS on customer behavior patterns and demographic analysis
|
||||
- 🔍 WEB SEARCH REQUIRED - verify current facts against live sources
|
||||
- 📝 WRITE CONTENT IMMEDIATELY TO DOCUMENT
|
||||
- 📖 CRITICAL: ALWAYS read the complete step file before taking any action - partial understanding leads to incomplete research
|
||||
- 🔄 CRITICAL: When loading next step with 'C', ensure the entire file is read and understood before proceeding
|
||||
- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
|
||||
|
||||
## EXECUTION PROTOCOLS:
|
||||
|
||||
- 🎯 Show web search analysis before presenting findings
|
||||
- ⚠️ Present [C] continue option after customer behavior content generation
|
||||
- 📝 WRITE CUSTOMER BEHAVIOR ANALYSIS TO DOCUMENT IMMEDIATELY
|
||||
- 💾 ONLY proceed when user chooses C (Continue)
|
||||
- 📖 Update frontmatter `stepsCompleted: [1, 2]` before loading next step
|
||||
- 🚫 FORBIDDEN to load next step until C is selected
|
||||
|
||||
## CONTEXT BOUNDARIES:
|
||||
|
||||
- Current document and frontmatter from step-01 are available
|
||||
- Focus on customer behavior patterns and demographic analysis
|
||||
- Web search capabilities with source verification are enabled
|
||||
- Previous step confirmed research scope and goals
|
||||
- **Research topic = "{{research_topic}}"** - established from initial discussion
|
||||
- **Research goals = "{{research_goals}}"** - established from initial discussion
|
||||
|
||||
## YOUR TASK:
|
||||
|
||||
Conduct customer behavior and segment analysis with emphasis on patterns and demographics.
|
||||
|
||||
## CUSTOMER BEHAVIOR ANALYSIS SEQUENCE:
|
||||
|
||||
### 1. Begin Customer Behavior Analysis
|
||||
|
||||
**UTILIZE SUBPROCESSES AND SUBAGENTS**: Use research subagents, subprocesses or parallel processing if available to thoroughly analyze different customer behavior areas simultaneously and thoroughly.
|
||||
|
||||
Start with customer behavior research approach:
|
||||
"Now I'll conduct **customer behavior analysis** for **{{research_topic}}** to understand customer patterns.
|
||||
|
||||
**Customer Behavior Focus:**
|
||||
|
||||
- Customer behavior patterns and preferences
|
||||
- Demographic profiles and segmentation
|
||||
- Psychographic characteristics and values
|
||||
- Behavior drivers and influences
|
||||
- Customer interaction patterns and engagement
|
||||
|
||||
**Let me search for current customer behavior insights.**"
|
||||
|
||||
### 2. Parallel Customer Behavior Research Execution
|
||||
|
||||
**Execute multiple web searches simultaneously:**
|
||||
|
||||
Search the web: "{{research_topic}} customer behavior patterns"
|
||||
Search the web: "{{research_topic}} customer demographics"
|
||||
Search the web: "{{research_topic}} psychographic profiles"
|
||||
Search the web: "{{research_topic}} customer behavior drivers"
|
||||
|
||||
**Analysis approach:**
|
||||
|
||||
- Look for customer behavior studies and research reports
|
||||
- Search for demographic segmentation and analysis
|
||||
- Research psychographic profiling and value systems
|
||||
- Analyze behavior drivers and influencing factors
|
||||
- Study customer interaction and engagement patterns
|
||||
|
||||
### 3. Analyze and Aggregate Results
|
||||
|
||||
**Collect and analyze findings from all parallel searches:**
|
||||
|
||||
"After executing comprehensive parallel web searches, let me analyze and aggregate customer behavior findings:
|
||||
|
||||
**Research Coverage:**
|
||||
|
||||
- Customer behavior patterns and preferences
|
||||
- Demographic profiles and segmentation
|
||||
- Psychographic characteristics and values
|
||||
- Behavior drivers and influences
|
||||
- Customer interaction patterns and engagement
|
||||
|
||||
**Cross-Behavior Analysis:**
|
||||
[Identify patterns connecting demographics, psychographics, and behaviors]
|
||||
|
||||
**Quality Assessment:**
|
||||
[Overall confidence levels and research gaps identified]"
|
||||
|
||||
### 4. Generate Customer Behavior Content
|
||||
|
||||
**WRITE IMMEDIATELY TO DOCUMENT**
|
||||
|
||||
Prepare customer behavior analysis with web search citations:
|
||||
|
||||
#### Content Structure:
|
||||
|
||||
When saving to document, append these Level 2 and Level 3 sections:
|
||||
|
||||
```markdown
|
||||
## Customer Behavior and Segments
|
||||
|
||||
### Customer Behavior Patterns
|
||||
|
||||
[Customer behavior patterns analysis with source citations]
|
||||
_Behavior Drivers: [Key motivations and patterns from web search]_
|
||||
_Interaction Preferences: [Customer engagement and interaction patterns]_
|
||||
_Decision Habits: [How customers typically make decisions]_
|
||||
_Source: [URL]_
|
||||
|
||||
### Demographic Segmentation
|
||||
|
||||
[Demographic analysis with source citations]
|
||||
_Age Demographics: [Age groups and preferences]_
|
||||
_Income Levels: [Income segments and purchasing behavior]_
|
||||
_Geographic Distribution: [Regional/city differences]_
|
||||
_Education Levels: [Education impact on behavior]_
|
||||
_Source: [URL]_
|
||||
|
||||
### Psychographic Profiles
|
||||
|
||||
[Psychographic analysis with source citations]
|
||||
_Values and Beliefs: [Core values driving customer behavior]_
|
||||
_Lifestyle Preferences: [Lifestyle choices and behaviors]_
|
||||
_Attitudes and Opinions: [Customer attitudes toward products/services]_
|
||||
_Personality Traits: [Personality influences on behavior]_
|
||||
_Source: [URL]_
|
||||
|
||||
### Customer Segment Profiles
|
||||
|
||||
[Detailed customer segment profiles with source citations]
|
||||
_Segment 1: [Detailed profile including demographics, psychographics, behavior]_
|
||||
_Segment 2: [Detailed profile including demographics, psychographics, behavior]_
|
||||
_Segment 3: [Detailed profile including demographics, psychographics, behavior]_
|
||||
_Source: [URL]_
|
||||
|
||||
### Behavior Drivers and Influences
|
||||
|
||||
[Behavior drivers analysis with source citations]
|
||||
_Emotional Drivers: [Emotional factors influencing behavior]_
|
||||
_Rational Drivers: [Logical decision factors]_
|
||||
_Social Influences: [Social and peer influences]_
|
||||
_Economic Influences: [Economic factors affecting behavior]_
|
||||
_Source: [URL]_
|
||||
|
||||
### Customer Interaction Patterns
|
||||
|
||||
[Customer interaction analysis with source citations]
|
||||
_Research and Discovery: [How customers find and research options]_
|
||||
_Purchase Decision Process: [Steps in purchase decision making]_
|
||||
_Post-Purchase Behavior: [After-purchase engagement patterns]_
|
||||
_Loyalty and Retention: [Factors driving customer loyalty]_
|
||||
_Source: [URL]_
|
||||
```
|
||||
|
||||
### 5. Present Analysis and Continue Option
|
||||
|
||||
**Show analysis and present continue option:**
|
||||
|
||||
"I've completed **customer behavior analysis** for {{research_topic}}, focusing on customer patterns.
|
||||
|
||||
**Key Customer Behavior Findings:**
|
||||
|
||||
- Customer behavior patterns clearly identified with drivers
|
||||
- Demographic segmentation thoroughly analyzed
|
||||
- Psychographic profiles mapped and documented
|
||||
- Customer interaction patterns captured
|
||||
- Multiple sources verified for critical insights
|
||||
|
||||
**Ready to proceed to customer pain points?**
|
||||
[C] Continue - Save this to document and proceed to pain points analysis
|
||||
|
||||
**HALT — wait for user response before proceeding.**
|
||||
|
||||
### 6. Handle Continue Selection
|
||||
|
||||
#### If 'C' (Continue):
|
||||
|
||||
- **CONTENT ALREADY WRITTEN TO DOCUMENT**
|
||||
- Update frontmatter: `stepsCompleted: [1, 2]`
|
||||
- Load: `./step-03-customer-pain-points.md`
|
||||
|
||||
## APPEND TO DOCUMENT:
|
||||
|
||||
Content is already written to document when generated in step 4. No additional append needed.
|
||||
|
||||
## SUCCESS METRICS:
|
||||
|
||||
✅ Customer behavior patterns identified with current citations
|
||||
✅ Demographic segmentation thoroughly analyzed
|
||||
✅ Psychographic profiles clearly documented
|
||||
✅ Customer interaction patterns captured
|
||||
✅ Multiple sources verified for critical insights
|
||||
✅ Content written immediately to document
|
||||
✅ [C] continue option presented and handled correctly
|
||||
✅ Proper routing to next step (customer pain points)
|
||||
✅ Research goals alignment maintained
|
||||
|
||||
## FAILURE MODES:
|
||||
|
||||
❌ Relying solely on training data without web verification for current facts
|
||||
|
||||
❌ Missing critical customer behavior patterns
|
||||
❌ Incomplete demographic segmentation analysis
|
||||
❌ Missing psychographic profile documentation
|
||||
❌ Not writing content immediately to document
|
||||
❌ Not presenting [C] continue option after content generation
|
||||
❌ Not routing to customer pain points analysis step
|
||||
❌ **CRITICAL**: Reading only partial step file - leads to incomplete understanding and poor research decisions
|
||||
❌ **CRITICAL**: Proceeding with 'C' without fully reading and understanding the next step file
|
||||
❌ **CRITICAL**: Making decisions without complete understanding of step requirements and protocols
|
||||
|
||||
## CUSTOMER BEHAVIOR RESEARCH PROTOCOLS:
|
||||
|
||||
- Research customer behavior studies and market research
|
||||
- Use demographic data from authoritative sources
|
||||
- Research psychographic profiling and value systems
|
||||
- Analyze customer interaction and engagement patterns
|
||||
- Focus on current behavior data and trends
|
||||
- Present conflicting information when sources disagree
|
||||
- Apply confidence levels appropriately
|
||||
|
||||
## BEHAVIOR ANALYSIS STANDARDS:
|
||||
|
||||
- Always cite URLs for web search results
|
||||
- Use authoritative customer research sources
|
||||
- Note data currency and potential limitations
|
||||
- Present multiple perspectives when sources conflict
|
||||
- Apply confidence levels to uncertain data
|
||||
- Focus on actionable customer insights
|
||||
|
||||
## NEXT STEP:
|
||||
|
||||
After user selects 'C', load `./step-03-customer-pain-points.md` to analyze customer pain points, challenges, and unmet needs for {{research_topic}}.
|
||||
|
||||
Remember: Always write research content to document immediately and emphasize current customer data with rigorous source verification!
|
||||
-251
@@ -1,251 +0,0 @@
|
||||
# Market Research Step 3: Customer Pain Points and Needs
|
||||
|
||||
## MANDATORY EXECUTION RULES (READ FIRST):
|
||||
|
||||
- 🛑 NEVER generate content without web search verification
|
||||
|
||||
- 📖 CRITICAL: ALWAYS read the complete step file before taking any action - partial understanding leads to incomplete decisions
|
||||
- 🔄 CRITICAL: When loading next step with 'C', ensure the entire file is read and understood before proceeding
|
||||
- ✅ Search the web to verify and supplement your knowledge with current facts
|
||||
- 📋 YOU ARE A CUSTOMER NEEDS ANALYST, not content generator
|
||||
- 💬 FOCUS on customer pain points, challenges, and unmet needs
|
||||
- 🔍 WEB SEARCH REQUIRED - verify current facts against live sources
|
||||
- 📝 WRITE CONTENT IMMEDIATELY TO DOCUMENT
|
||||
- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
|
||||
|
||||
## EXECUTION PROTOCOLS:
|
||||
|
||||
- 🎯 Show web search analysis before presenting findings
|
||||
- ⚠️ Present [C] continue option after pain points content generation
|
||||
- 📝 WRITE CUSTOMER PAIN POINTS ANALYSIS TO DOCUMENT IMMEDIATELY
|
||||
- 💾 ONLY proceed when user chooses C (Continue)
|
||||
- 📖 Update frontmatter `stepsCompleted: [1, 2, 3]` before loading next step
|
||||
- 🚫 FORBIDDEN to load next step until C is selected
|
||||
|
||||
## CONTEXT BOUNDARIES:
|
||||
|
||||
- Current document and frontmatter from previous steps are available
|
||||
- Customer behavior analysis completed in previous step
|
||||
- Focus on customer pain points, challenges, and unmet needs
|
||||
- Web search capabilities with source verification are enabled
|
||||
- **Research topic = "{{research_topic}}"** - established from initial discussion
|
||||
- **Research goals = "{{research_goals}}"** - established from initial discussion
|
||||
|
||||
## YOUR TASK:
|
||||
|
||||
Conduct customer pain points and needs analysis with emphasis on challenges and frustrations.
|
||||
|
||||
## CUSTOMER PAIN POINTS ANALYSIS SEQUENCE:
|
||||
|
||||
### 1. Begin Customer Pain Points Analysis
|
||||
|
||||
**UTILIZE SUBPROCESSES AND SUBAGENTS**: Use research subagents, subprocesses or parallel processing if available to thoroughly analyze different customer pain point areas simultaneously and thoroughly.
|
||||
|
||||
Start with customer pain points research approach:
|
||||
"Now I'll conduct **customer pain points analysis** for **{{research_topic}}** to understand customer challenges.
|
||||
|
||||
**Customer Pain Points Focus:**
|
||||
|
||||
- Customer challenges and frustrations
|
||||
- Unmet needs and unaddressed problems
|
||||
- Barriers to adoption or usage
|
||||
- Service and support pain points
|
||||
- Customer satisfaction gaps
|
||||
|
||||
**Let me search for current customer pain points insights.**"
|
||||
|
||||
### 2. Parallel Pain Points Research Execution
|
||||
|
||||
**Execute multiple web searches simultaneously:**
|
||||
|
||||
Search the web: "{{research_topic}} customer pain points challenges"
|
||||
Search the web: "{{research_topic}} customer frustrations"
|
||||
Search the web: "{{research_topic}} unmet customer needs"
|
||||
Search the web: "{{research_topic}} customer barriers to adoption"
|
||||
|
||||
**Analysis approach:**
|
||||
|
||||
- Look for customer satisfaction surveys and reports
|
||||
- Search for customer complaints and reviews
|
||||
- Research customer support and service issues
|
||||
- Analyze barriers to customer adoption
|
||||
- Study unmet needs and market gaps
|
||||
|
||||
### 3. Analyze and Aggregate Results
|
||||
|
||||
**Collect and analyze findings from all parallel searches:**
|
||||
|
||||
"After executing comprehensive parallel web searches, let me analyze and aggregate customer pain points findings:
|
||||
|
||||
**Research Coverage:**
|
||||
|
||||
- Customer challenges and frustrations
|
||||
- Unmet needs and unaddressed problems
|
||||
- Barriers to adoption or usage
|
||||
- Service and support pain points
|
||||
|
||||
**Cross-Pain Points Analysis:**
|
||||
[Identify patterns connecting different types of pain points]
|
||||
|
||||
**Quality Assessment:**
|
||||
[Overall confidence levels and research gaps identified]"
|
||||
|
||||
### 4. Generate Customer Pain Points Content
|
||||
|
||||
**WRITE IMMEDIATELY TO DOCUMENT**
|
||||
|
||||
Prepare customer pain points analysis with web search citations:
|
||||
|
||||
#### Content Structure:
|
||||
|
||||
When saving to document, append these Level 2 and Level 3 sections:
|
||||
|
||||
```markdown
|
||||
## Customer Pain Points and Needs
|
||||
|
||||
### Customer Challenges and Frustrations
|
||||
|
||||
[Customer challenges analysis with source citations]
|
||||
_Primary Frustrations: [Major customer frustrations identified]_
|
||||
_Usage Barriers: [Barriers preventing effective usage]_
|
||||
_Service Pain Points: [Customer service and support issues]_
|
||||
_Frequency Analysis: [How often these challenges occur]_
|
||||
_Source: [URL]_
|
||||
|
||||
### Unmet Customer Needs
|
||||
|
||||
[Unmet needs analysis with source citations]
|
||||
_Critical Unmet Needs: [Most important unaddressed needs]_
|
||||
_Solution Gaps: [Opportunities to address unmet needs]_
|
||||
_Market Gaps: [Market opportunities from unmet needs]_
|
||||
_Priority Analysis: [Which needs are most critical]_
|
||||
_Source: [URL]_
|
||||
|
||||
### Barriers to Adoption
|
||||
|
||||
[Adoption barriers analysis with source citations]
|
||||
_Price Barriers: [Cost-related barriers to adoption]_
|
||||
_Technical Barriers: [Complexity or technical barriers]_
|
||||
_Trust Barriers: [Trust and credibility issues]_
|
||||
_Convenience Barriers: [Ease of use or accessibility issues]_
|
||||
_Source: [URL]_
|
||||
|
||||
### Service and Support Pain Points
|
||||
|
||||
[Service pain points analysis with source citations]
|
||||
_Customer Service Issues: [Common customer service problems]_
|
||||
_Support Gaps: [Areas where customer support is lacking]_
|
||||
_Communication Issues: [Communication breakdowns and frustrations]_
|
||||
_Response Time Issues: [Slow response and resolution problems]_
|
||||
_Source: [URL]_
|
||||
|
||||
### Customer Satisfaction Gaps
|
||||
|
||||
[Satisfaction gap analysis with source citations]
|
||||
_Expectation Gaps: [Differences between expectations and reality]_
|
||||
_Quality Gaps: [Areas where quality expectations aren't met]_
|
||||
_Value Perception Gaps: [Perceived value vs actual value]_
|
||||
_Trust and Credibility Gaps: [Trust issues affecting satisfaction]_
|
||||
_Source: [URL]_
|
||||
|
||||
### Emotional Impact Assessment
|
||||
|
||||
[Emotional impact analysis with source citations]
|
||||
_Frustration Levels: [Customer frustration severity assessment]_
|
||||
_Loyalty Risks: [How pain points affect customer loyalty]_
|
||||
_Reputation Impact: [Impact on brand or product reputation]_
|
||||
_Customer Retention Risks: [Risk of customer loss from pain points]_
|
||||
_Source: [URL]_
|
||||
|
||||
### Pain Point Prioritization
|
||||
|
||||
[Pain point prioritization with source citations]
|
||||
_High Priority Pain Points: [Most critical pain points to address]_
|
||||
_Medium Priority Pain Points: [Important but less critical pain points]_
|
||||
_Low Priority Pain Points: [Minor pain points with lower impact]_
|
||||
_Opportunity Mapping: [Pain points with highest solution opportunity]_
|
||||
_Source: [URL]_
|
||||
```
|
||||
|
||||
### 5. Present Analysis and Continue Option
|
||||
|
||||
**Show analysis and present continue option:**
|
||||
|
||||
"I've completed **customer pain points analysis** for {{research_topic}}, focusing on customer challenges.
|
||||
|
||||
**Key Pain Points Findings:**
|
||||
|
||||
- Customer challenges and frustrations thoroughly documented
|
||||
- Unmet needs and solution gaps clearly identified
|
||||
- Adoption barriers and service pain points analyzed
|
||||
- Customer satisfaction gaps assessed
|
||||
- Pain points prioritized by impact and opportunity
|
||||
|
||||
**Ready to proceed to customer decision processes?**
|
||||
[C] Continue - Save this to document and proceed to decision processes analysis
|
||||
|
||||
**HALT — wait for user response before proceeding.**
|
||||
|
||||
### 6. Handle Continue Selection
|
||||
|
||||
#### If 'C' (Continue):
|
||||
|
||||
- **CONTENT ALREADY WRITTEN TO DOCUMENT**
|
||||
- Update frontmatter: `stepsCompleted: [1, 2, 3]`
|
||||
- Load: `./step-04-customer-decisions.md`
|
||||
|
||||
## APPEND TO DOCUMENT:
|
||||
|
||||
Content is already written to document when generated in step 4. No additional append needed.
|
||||
|
||||
## SUCCESS METRICS:
|
||||
|
||||
✅ Customer challenges and frustrations clearly documented
|
||||
✅ Unmet needs and solution gaps identified
|
||||
✅ Adoption barriers and service pain points analyzed
|
||||
✅ Customer satisfaction gaps assessed
|
||||
✅ Pain points prioritized by impact and opportunity
|
||||
✅ Content written immediately to document
|
||||
✅ [C] continue option presented and handled correctly
|
||||
✅ Proper routing to next step (customer decisions)
|
||||
✅ Research goals alignment maintained
|
||||
|
||||
## FAILURE MODES:
|
||||
|
||||
❌ Relying solely on training data without web verification for current facts
|
||||
|
||||
❌ Missing critical customer challenges or frustrations
|
||||
❌ Not identifying unmet needs or solution gaps
|
||||
❌ Incomplete adoption barriers analysis
|
||||
❌ Not writing content immediately to document
|
||||
❌ Not presenting [C] continue option after content generation
|
||||
❌ Not routing to customer decisions analysis step
|
||||
|
||||
❌ **CRITICAL**: Reading only partial step file - leads to incomplete understanding and poor decisions
|
||||
❌ **CRITICAL**: Proceeding with 'C' without fully reading and understanding the next step file
|
||||
❌ **CRITICAL**: Making decisions without complete understanding of step requirements and protocols
|
||||
|
||||
## CUSTOMER PAIN POINTS RESEARCH PROTOCOLS:
|
||||
|
||||
- Research customer satisfaction surveys and reviews
|
||||
- Use customer feedback and complaint data
|
||||
- Analyze customer support and service issues
|
||||
- Study barriers to customer adoption
|
||||
- Focus on current pain point data
|
||||
- Present conflicting information when sources disagree
|
||||
- Apply confidence levels appropriately
|
||||
|
||||
## PAIN POINTS ANALYSIS STANDARDS:
|
||||
|
||||
- Always cite URLs for web search results
|
||||
- Use authoritative customer research sources
|
||||
- Note data currency and potential limitations
|
||||
- Present multiple perspectives when sources conflict
|
||||
- Apply confidence levels to uncertain data
|
||||
- Focus on actionable pain point insights
|
||||
|
||||
## NEXT STEP:
|
||||
|
||||
After user selects 'C', load `./step-04-customer-decisions.md` to analyze customer decision processes, journey mapping, and decision factors for {{research_topic}}.
|
||||
|
||||
Remember: Always write research content to document immediately and emphasize current customer pain points data with rigorous source verification!
|
||||
-261
@@ -1,261 +0,0 @@
|
||||
# Market Research Step 4: Customer Decisions and Journey
|
||||
|
||||
## MANDATORY EXECUTION RULES (READ FIRST):
|
||||
|
||||
- 🛑 NEVER generate content without web search verification
|
||||
|
||||
- 📖 CRITICAL: ALWAYS read the complete step file before taking any action - partial understanding leads to incomplete decisions
|
||||
- 🔄 CRITICAL: When loading next step with 'C', ensure the entire file is read and understood before proceeding
|
||||
- ✅ Search the web to verify and supplement your knowledge with current facts
|
||||
- 📋 YOU ARE A CUSTOMER DECISION ANALYST, not content generator
|
||||
- 💬 FOCUS on customer decision processes and journey mapping
|
||||
- 🔍 WEB SEARCH REQUIRED - verify current facts against live sources
|
||||
- 📝 WRITE CONTENT IMMEDIATELY TO DOCUMENT
|
||||
- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
|
||||
|
||||
## EXECUTION PROTOCOLS:
|
||||
|
||||
- 🎯 Show web search analysis before presenting findings
|
||||
- ⚠️ Present [C] continue option after decision processes content generation
|
||||
- 📝 WRITE CUSTOMER DECISIONS ANALYSIS TO DOCUMENT IMMEDIATELY
|
||||
- 💾 ONLY proceed when user chooses C (Continue)
|
||||
- 📖 Update frontmatter `stepsCompleted: [1, 2, 3, 4]` before loading next step
|
||||
- 🚫 FORBIDDEN to load next step until C is selected
|
||||
|
||||
## CONTEXT BOUNDARIES:
|
||||
|
||||
- Current document and frontmatter from previous steps are available
|
||||
- Customer behavior and pain points analysis completed in previous steps
|
||||
- Focus on customer decision processes and journey mapping
|
||||
- Web search capabilities with source verification are enabled
|
||||
- **Research topic = "{{research_topic}}"** - established from initial discussion
|
||||
- **Research goals = "{{research_goals}}"** - established from initial discussion
|
||||
|
||||
## YOUR TASK:
|
||||
|
||||
Conduct customer decision processes and journey analysis with emphasis on decision factors and journey mapping.
|
||||
|
||||
## CUSTOMER DECISIONS ANALYSIS SEQUENCE:
|
||||
|
||||
### 1. Begin Customer Decisions Analysis
|
||||
|
||||
**UTILIZE SUBPROCESSES AND SUBAGENTS**: Use research subagents, subprocesses or parallel processing if available to thoroughly analyze different customer decision areas simultaneously and thoroughly.
|
||||
|
||||
Start with customer decisions research approach:
|
||||
"Now I'll conduct **customer decision processes analysis** for **{{research_topic}}** to understand customer decision-making.
|
||||
|
||||
**Customer Decisions Focus:**
|
||||
|
||||
- Customer decision-making processes
|
||||
- Decision factors and criteria
|
||||
- Customer journey mapping
|
||||
- Purchase decision influencers
|
||||
- Information gathering patterns
|
||||
|
||||
**Let me search for current customer decision insights.**"
|
||||
|
||||
### 2. Parallel Decisions Research Execution
|
||||
|
||||
**Execute multiple web searches simultaneously:**
|
||||
|
||||
Search the web: "{{research_topic}} customer decision process"
|
||||
Search the web: "{{research_topic}} buying criteria factors"
|
||||
Search the web: "{{research_topic}} customer journey mapping"
|
||||
Search the web: "{{research_topic}} decision influencing factors"
|
||||
|
||||
**Analysis approach:**
|
||||
|
||||
- Look for customer decision research studies
|
||||
- Search for buying criteria and factor analysis
|
||||
- Research customer journey mapping methodologies
|
||||
- Analyze decision influence factors and channels
|
||||
- Study information gathering and evaluation patterns
|
||||
|
||||
### 3. Analyze and Aggregate Results
|
||||
|
||||
**Collect and analyze findings from all parallel searches:**
|
||||
|
||||
"After executing comprehensive parallel web searches, let me analyze and aggregate customer decision findings:
|
||||
|
||||
**Research Coverage:**
|
||||
|
||||
- Customer decision-making processes
|
||||
- Decision factors and criteria
|
||||
- Customer journey mapping
|
||||
- Decision influence factors
|
||||
|
||||
**Cross-Decisions Analysis:**
|
||||
[Identify patterns connecting decision factors and journey stages]
|
||||
|
||||
**Quality Assessment:**
|
||||
[Overall confidence levels and research gaps identified]"
|
||||
|
||||
### 4. Generate Customer Decisions Content
|
||||
|
||||
**WRITE IMMEDIATELY TO DOCUMENT**
|
||||
|
||||
Prepare customer decisions analysis with web search citations:
|
||||
|
||||
#### Content Structure:
|
||||
|
||||
When saving to document, append these Level 2 and Level 3 sections:
|
||||
|
||||
```markdown
|
||||
## Customer Decision Processes and Journey
|
||||
|
||||
### Customer Decision-Making Processes
|
||||
|
||||
[Decision processes analysis with source citations]
|
||||
_Decision Stages: [Key stages in customer decision making]_
|
||||
_Decision Timelines: [Timeframes for different decisions]_
|
||||
_Complexity Levels: [Decision complexity assessment]_
|
||||
_Evaluation Methods: [How customers evaluate options]_
|
||||
_Source: [URL]_
|
||||
|
||||
### Decision Factors and Criteria
|
||||
|
||||
[Decision factors analysis with source citations]
|
||||
_Primary Decision Factors: [Most important factors in decisions]_
|
||||
_Secondary Decision Factors: [Supporting factors influencing decisions]_
|
||||
_Weighing Analysis: [How different factors are weighed]_
|
||||
_Evoluton Patterns: [How factors change over time]_
|
||||
_Source: [URL]_
|
||||
|
||||
### Customer Journey Mapping
|
||||
|
||||
[Journey mapping analysis with source citations]
|
||||
_Awareness Stage: [How customers become aware of {{research_topic}}]_
|
||||
_Consideration Stage: [Evaluation and comparison process]_
|
||||
_Decision Stage: [Final decision-making process]_
|
||||
_Purchase Stage: [Purchase execution and completion]_
|
||||
_Post-Purchase Stage: [Post-decision evaluation and behavior]_
|
||||
_Source: [URL]_
|
||||
|
||||
### Touchpoint Analysis
|
||||
|
||||
[Touchpoint analysis with source citations]
|
||||
_Digital Touchpoints: [Online and digital interaction points]_
|
||||
_Offline Touchpoints: [Physical and in-person interaction points]_
|
||||
_Information Sources: [Where customers get information]_
|
||||
_Influence Channels: [What influences customer decisions]_
|
||||
_Source: [URL]_
|
||||
|
||||
### Information Gathering Patterns
|
||||
|
||||
[Information patterns analysis with source citations]
|
||||
_Research Methods: [How customers research options]_
|
||||
_Information Sources Trusted: [Most trusted information sources]_
|
||||
_Research Duration: [Time spent gathering information]_
|
||||
_Evaluation Criteria: [How customers evaluate information]_
|
||||
_Source: [URL]_
|
||||
|
||||
### Decision Influencers
|
||||
|
||||
[Decision influencer analysis with source citations]
|
||||
_Peer Influence: [How friends and family influence decisions]_
|
||||
_Expert Influence: [How expert opinions affect decisions]_
|
||||
_Media Influence: [How media and marketing affect decisions]_
|
||||
_Social Proof Influence: [How reviews and testimonials affect decisions]_
|
||||
_Source: [URL]_
|
||||
|
||||
### Purchase Decision Factors
|
||||
|
||||
[Purchase decision factors analysis with source citations]
|
||||
_Immediate Purchase Drivers: [Factors triggering immediate purchase]_
|
||||
_Delayed Purchase Drivers: [Factors causing purchase delays]_
|
||||
_Brand Loyalty Factors: [Factors driving repeat purchases]_
|
||||
_Price Sensitivity: [How price affects purchase decisions]_
|
||||
_Source: [URL]_
|
||||
|
||||
### Customer Decision Optimizations
|
||||
|
||||
[Decision optimization analysis with source citations]
|
||||
_Friction Reduction: [Ways to make decisions easier]_
|
||||
_Trust Building: [Building customer trust in decisions]_
|
||||
_Conversion Optimization: [Optimizing decision-to-purchase rates]_
|
||||
_Loyalty Building: [Building long-term customer relationships]_
|
||||
_Source: [URL]_
|
||||
```
|
||||
|
||||
### 5. Present Analysis and Continue Option
|
||||
|
||||
**Show analysis and present continue option:**
|
||||
|
||||
"I've completed **customer decision processes analysis** for {{research_topic}}, focusing on customer decision-making.
|
||||
|
||||
**Key Decision Findings:**
|
||||
|
||||
- Customer decision-making processes clearly mapped
|
||||
- Decision factors and criteria thoroughly analyzed
|
||||
- Customer journey mapping completed across all stages
|
||||
- Decision influencers and touchpoints identified
|
||||
- Information gathering patterns documented
|
||||
|
||||
**Ready to proceed to competitive analysis?**
|
||||
[C] Continue - Save this to document and proceed to competitive analysis
|
||||
|
||||
**HALT — wait for user response before proceeding.**
|
||||
|
||||
### 6. Handle Continue Selection
|
||||
|
||||
#### If 'C' (Continue):
|
||||
|
||||
- **CONTENT ALREADY WRITTEN TO DOCUMENT**
|
||||
- Update frontmatter: `stepsCompleted: [1, 2, 3, 4]`
|
||||
- Load: `./step-05-competitive-analysis.md`
|
||||
|
||||
## APPEND TO DOCUMENT:
|
||||
|
||||
Content is already written to document when generated in step 4. No additional append needed.
|
||||
|
||||
## SUCCESS METRICS:
|
||||
|
||||
✅ Customer decision-making processes clearly mapped
|
||||
✅ Decision factors and criteria thoroughly analyzed
|
||||
✅ Customer journey mapping completed across all stages
|
||||
✅ Decision influencers and touchpoints identified
|
||||
✅ Information gathering patterns documented
|
||||
✅ Content written immediately to document
|
||||
✅ [C] continue option presented and handled correctly
|
||||
✅ Proper routing to next step (competitive analysis)
|
||||
✅ Research goals alignment maintained
|
||||
|
||||
## FAILURE MODES:
|
||||
|
||||
❌ Relying solely on training data without web verification for current facts
|
||||
|
||||
❌ Missing critical decision-making process stages
|
||||
❌ Not identifying key decision factors
|
||||
❌ Incomplete customer journey mapping
|
||||
❌ Not writing content immediately to document
|
||||
❌ Not presenting [C] continue option after content generation
|
||||
❌ Not routing to competitive analysis step
|
||||
|
||||
❌ **CRITICAL**: Reading only partial step file - leads to incomplete understanding and poor decisions
|
||||
❌ **CRITICAL**: Proceeding with 'C' without fully reading and understanding the next step file
|
||||
❌ **CRITICAL**: Making decisions without complete understanding of step requirements and protocols
|
||||
|
||||
## CUSTOMER DECISIONS RESEARCH PROTOCOLS:
|
||||
|
||||
- Research customer decision studies and psychology
|
||||
- Use customer journey mapping methodologies
|
||||
- Analyze buying criteria and decision factors
|
||||
- Study decision influence and touchpoint analysis
|
||||
- Focus on current decision data
|
||||
- Present conflicting information when sources disagree
|
||||
- Apply confidence levels appropriately
|
||||
|
||||
## DECISION ANALYSIS STANDARDS:
|
||||
|
||||
- Always cite URLs for web search results
|
||||
- Use authoritative customer decision research sources
|
||||
- Note data currency and potential limitations
|
||||
- Present multiple perspectives when sources conflict
|
||||
- Apply confidence levels to uncertain data
|
||||
- Focus on actionable decision insights
|
||||
|
||||
## NEXT STEP:
|
||||
|
||||
After user selects 'C', load `./step-05-competitive-analysis.md` to analyze competitive landscape, market positioning, and competitive strategies for {{research_topic}}.
|
||||
|
||||
Remember: Always write research content to document immediately and emphasize current customer decision data with rigorous source verification!
|
||||
-173
@@ -1,173 +0,0 @@
|
||||
# Market Research Step 5: Competitive Analysis
|
||||
|
||||
## MANDATORY EXECUTION RULES (READ FIRST):
|
||||
|
||||
- 🛑 NEVER generate content without web search verification
|
||||
|
||||
- 📖 CRITICAL: ALWAYS read the complete step file before taking any action - partial understanding leads to incomplete decisions
|
||||
- 🔄 CRITICAL: When loading next step with 'C', ensure the entire file is read and understood before proceeding
|
||||
- ✅ Search the web to verify and supplement your knowledge with current facts
|
||||
- 📋 YOU ARE A COMPETITIVE ANALYST, not content generator
|
||||
- 💬 FOCUS on competitive landscape and market positioning
|
||||
- 🔍 WEB SEARCH REQUIRED - verify current facts against live sources
|
||||
- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
|
||||
|
||||
## EXECUTION PROTOCOLS:
|
||||
|
||||
- 🎯 Show web search analysis before presenting findings
|
||||
- ⚠️ Present [C] complete option after competitive analysis content generation
|
||||
- 💾 ONLY save when user chooses C (Complete)
|
||||
- 📖 Update frontmatter `stepsCompleted: [1, 2, 3, 4, 5]` before completing workflow
|
||||
- 🚫 FORBIDDEN to complete workflow until C is selected
|
||||
|
||||
## CONTEXT BOUNDARIES:
|
||||
|
||||
- Current document and frontmatter from previous steps are available
|
||||
- Focus on competitive landscape and market positioning analysis
|
||||
- Web search capabilities with source verification are enabled
|
||||
- May need to search for specific competitor information
|
||||
|
||||
## YOUR TASK:
|
||||
|
||||
Conduct comprehensive competitive analysis with emphasis on market positioning.
|
||||
|
||||
## COMPETITIVE ANALYSIS SEQUENCE:
|
||||
|
||||
### 1. Begin Competitive Analysis
|
||||
|
||||
Start with competitive research approach:
|
||||
"Now I'll conduct **competitive analysis** to understand the competitive landscape.
|
||||
|
||||
**Competitive Analysis Focus:**
|
||||
|
||||
- Key players and market share
|
||||
- Competitive positioning strategies
|
||||
- Strengths and weaknesses analysis
|
||||
- Market differentiation opportunities
|
||||
- Competitive threats and challenges
|
||||
|
||||
**Let me search for current competitive information.**"
|
||||
|
||||
### 2. Generate Competitive Analysis Content
|
||||
|
||||
Prepare competitive analysis with web search citations:
|
||||
|
||||
#### Content Structure:
|
||||
|
||||
When saving to document, append these Level 2 and Level 3 sections:
|
||||
|
||||
```markdown
|
||||
## Competitive Landscape
|
||||
|
||||
### Key Market Players
|
||||
|
||||
[Key players analysis with market share data]
|
||||
_Source: [URL]_
|
||||
|
||||
### Market Share Analysis
|
||||
|
||||
[Market share analysis with source citations]
|
||||
_Source: [URL]_
|
||||
|
||||
### Competitive Positioning
|
||||
|
||||
[Positioning analysis with source citations]
|
||||
_Source: [URL]_
|
||||
|
||||
### Strengths and Weaknesses
|
||||
|
||||
[SWOT analysis with source citations]
|
||||
_Source: [URL]_
|
||||
|
||||
### Market Differentiation
|
||||
|
||||
[Differentiation analysis with source citations]
|
||||
_Source: [URL]_
|
||||
|
||||
### Competitive Threats
|
||||
|
||||
[Threats analysis with source citations]
|
||||
_Source: [URL]_
|
||||
|
||||
### Opportunities
|
||||
|
||||
[Competitive opportunities analysis with source citations]
|
||||
_Source: [URL]_
|
||||
```
|
||||
|
||||
### 3. Present Analysis and Complete Option
|
||||
|
||||
Show the generated competitive analysis and present complete option:
|
||||
"I've completed the **competitive analysis** for the competitive landscape.
|
||||
|
||||
**Key Competitive Findings:**
|
||||
|
||||
- Key market players and market share identified
|
||||
- Competitive positioning strategies mapped
|
||||
- Strengths and weaknesses thoroughly analyzed
|
||||
- Market differentiation opportunities identified
|
||||
- Competitive threats and challenges documented
|
||||
|
||||
**Ready to complete the market research?**
|
||||
[C] Complete Research - Save competitive analysis and proceed to research completion
|
||||
|
||||
**HALT — wait for user response before proceeding.**
|
||||
|
||||
### 4. Handle Complete Selection
|
||||
|
||||
#### If 'C' (Complete Research):
|
||||
|
||||
- Append the final content to the research document
|
||||
- Update frontmatter: `stepsCompleted: [1, 2, 3, 4, 5]`
|
||||
- Load: `./step-06-research-completion.md`
|
||||
|
||||
## APPEND TO DOCUMENT:
|
||||
|
||||
When user selects 'C', append the content directly to the research document using the structure from step 2.
|
||||
|
||||
## SUCCESS METRICS:
|
||||
|
||||
✅ Key market players identified
|
||||
✅ Market share analysis completed with source verification
|
||||
✅ Competitive positioning strategies clearly mapped
|
||||
✅ Strengths and weaknesses thoroughly analyzed
|
||||
✅ Market differentiation opportunities identified
|
||||
✅ [C] complete option presented and handled correctly
|
||||
✅ Content properly appended to document when C selected
|
||||
✅ Market research workflow completed successfully
|
||||
|
||||
## FAILURE MODES:
|
||||
|
||||
❌ Relying solely on training data without web verification for current facts
|
||||
|
||||
❌ Missing key market players or market share data
|
||||
❌ Incomplete competitive positioning analysis
|
||||
❌ Not identifying market differentiation opportunities
|
||||
❌ Not presenting completion option for research workflow
|
||||
❌ Appending content without user selecting 'C'
|
||||
|
||||
❌ **CRITICAL**: Reading only partial step file - leads to incomplete understanding and poor decisions
|
||||
❌ **CRITICAL**: Proceeding with 'C' without fully reading and understanding the next step file
|
||||
❌ **CRITICAL**: Making decisions without complete understanding of step requirements and protocols
|
||||
|
||||
## COMPETITIVE RESEARCH PROTOCOLS:
|
||||
|
||||
- Search for industry reports and competitive intelligence
|
||||
- Use competitor company websites and annual reports
|
||||
- Research market research firm competitive analyses
|
||||
- Note competitive advantages and disadvantages
|
||||
- Search for recent market developments and disruptions
|
||||
|
||||
## MARKET RESEARCH COMPLETION:
|
||||
|
||||
When 'C' is selected:
|
||||
|
||||
- All market research steps completed
|
||||
- Comprehensive market research document generated
|
||||
- All sections appended with source citations
|
||||
- Market research workflow status updated
|
||||
- Final recommendations provided to user
|
||||
|
||||
## NEXT STEP:
|
||||
|
||||
After user selects 'C', load `./step-06-research-completion.md` to produce the final comprehensive market research document with strategic synthesis, executive summary, and complete document structure.
|
||||
-484
@@ -1,484 +0,0 @@
|
||||
# Market Research Step 6: Research Completion
|
||||
|
||||
## MANDATORY EXECUTION RULES (READ FIRST):
|
||||
|
||||
- 🛑 NEVER generate content without web search verification
|
||||
|
||||
- 📖 CRITICAL: ALWAYS read the complete step file before taking any action - partial understanding leads to incomplete decisions
|
||||
- 🔄 CRITICAL: When loading next step with 'C', ensure the entire file is read and understood before proceeding
|
||||
- ✅ Search the web to verify and supplement your knowledge with current facts
|
||||
- 📋 YOU ARE A MARKET RESEARCH STRATEGIST, not content generator
|
||||
- 💬 FOCUS on strategic recommendations and actionable insights
|
||||
- 🔍 WEB SEARCH REQUIRED - verify current facts against live sources
|
||||
- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
|
||||
|
||||
## EXECUTION PROTOCOLS:
|
||||
|
||||
- 🎯 Show web search analysis before presenting findings
|
||||
- ⚠️ Present [C] complete option after completion content generation
|
||||
- 💾 ONLY save when user chooses C (Complete)
|
||||
- 📖 Update frontmatter `stepsCompleted: [1, 2, 3, 4, 5, 6]` before completing workflow
|
||||
- 🚫 FORBIDDEN to complete workflow until C is selected
|
||||
- 📚 GENERATE COMPLETE DOCUMENT STRUCTURE with intro, TOC, and summary
|
||||
|
||||
## CONTEXT BOUNDARIES:
|
||||
|
||||
- Current document and frontmatter from previous steps are available
|
||||
- **Research topic = "{{research_topic}}"** - comprehensive market analysis
|
||||
- **Research goals = "{{research_goals}}"** - achieved through exhaustive market research
|
||||
- All market research sections have been completed (customer behavior, pain points, decisions, competitive analysis)
|
||||
- Web search capabilities with source verification are enabled
|
||||
- This is the final synthesis step producing the complete market research document
|
||||
|
||||
## YOUR TASK:
|
||||
|
||||
Produce a comprehensive, authoritative market research document on **{{research_topic}}** with compelling narrative introduction, detailed TOC, and executive summary based on exhaustive market research.
|
||||
|
||||
## MARKET RESEARCH COMPLETION SEQUENCE:
|
||||
|
||||
### 1. Begin Strategic Synthesis
|
||||
|
||||
Start with strategic synthesis approach:
|
||||
"Now I'll complete our market research with **strategic synthesis and recommendations** .
|
||||
|
||||
**Strategic Synthesis Focus:**
|
||||
|
||||
- Integrated insights from market, customer, and competitive analysis
|
||||
- Strategic recommendations based on research findings
|
||||
- Market entry or expansion strategies
|
||||
- Risk assessment and mitigation approaches
|
||||
- Actionable next steps and implementation guidance
|
||||
|
||||
**Let me search for current strategic insights and best practices.**"
|
||||
|
||||
### 2. Web Search for Market Entry Strategies
|
||||
|
||||
Search for current market strategies:
|
||||
Search the web: "market entry strategies best practices"
|
||||
|
||||
**Strategy focus:**
|
||||
|
||||
- Market entry timing and approaches
|
||||
- Go-to-market strategies and frameworks
|
||||
- Market positioning and differentiation tactics
|
||||
- Customer acquisition and growth strategies
|
||||
|
||||
### 3. Web Search for Risk Assessment
|
||||
|
||||
Search for current risk approaches:
|
||||
Search the web: "market research risk assessment frameworks"
|
||||
|
||||
**Risk focus:**
|
||||
|
||||
- Market risks and uncertainty management
|
||||
- Competitive threats and mitigation strategies
|
||||
- Regulatory and compliance risks
|
||||
- Economic and market volatility considerations
|
||||
|
||||
### 4. Generate Complete Market Research Document
|
||||
|
||||
Prepare comprehensive market research document with full structure:
|
||||
|
||||
#### Complete Document Structure:
|
||||
|
||||
```markdown
|
||||
# [Compelling Title]: Comprehensive {{research_topic}} Market Research
|
||||
|
||||
## Executive Summary
|
||||
|
||||
[Brief compelling overview of key market findings and strategic implications]
|
||||
|
||||
## Table of Contents
|
||||
|
||||
- Market Research Introduction and Methodology
|
||||
- {{research_topic}} Market Analysis and Dynamics
|
||||
- Customer Insights and Behavior Analysis
|
||||
- Competitive Landscape and Positioning
|
||||
- Strategic Market Recommendations
|
||||
- Market Entry and Growth Strategies
|
||||
- Risk Assessment and Mitigation
|
||||
- Implementation Roadmap and Success Metrics
|
||||
- Future Market Outlook and Opportunities
|
||||
- Market Research Methodology and Source Documentation
|
||||
- Market Research Appendices and Additional Resources
|
||||
|
||||
## 1. Market Research Introduction and Methodology
|
||||
|
||||
### Market Research Significance
|
||||
|
||||
**Compelling market narrative about why {{research_topic}} research is critical now**
|
||||
_Market Importance: [Strategic market significance with up-to-date context]_
|
||||
_Business Impact: [Business implications of market research]_
|
||||
_Source: [URL]_
|
||||
|
||||
### Market Research Methodology
|
||||
|
||||
[Comprehensive description of market research approach including:]
|
||||
|
||||
- **Market Scope**: [Comprehensive market coverage areas]
|
||||
- **Data Sources**: [Authoritative market sources and verification approach]
|
||||
- **Analysis Framework**: [Structured market analysis methodology]
|
||||
- **Time Period**: [current focus and market evolution context]
|
||||
- **Geographic Coverage**: [Regional/global market scope]
|
||||
|
||||
### Market Research Goals and Objectives
|
||||
|
||||
**Original Market Goals:** {{research_goals}}
|
||||
|
||||
**Achieved Market Objectives:**
|
||||
|
||||
- [Market Goal 1 achievement with supporting evidence]
|
||||
- [Market Goal 2 achievement with supporting evidence]
|
||||
- [Additional market insights discovered during research]
|
||||
|
||||
## 2. {{research_topic}} Market Analysis and Dynamics
|
||||
|
||||
### Market Size and Growth Projections
|
||||
|
||||
_[Comprehensive market analysis]_
|
||||
_Market Size: [Current market valuation and size]_
|
||||
_Growth Rate: [CAGR and market growth projections]_
|
||||
_Market Drivers: [Key factors driving market growth]_
|
||||
_Market Segments: [Detailed market segmentation analysis]_
|
||||
_Source: [URL]_
|
||||
|
||||
### Market Trends and Dynamics
|
||||
|
||||
[Current market trends analysis]
|
||||
_Emerging Trends: [Key market trends and their implications]_
|
||||
_Market Dynamics: [Forces shaping market evolution]_
|
||||
_Consumer Behavior Shifts: [Changes in customer behavior and preferences]_
|
||||
_Source: [URL]_
|
||||
|
||||
### Pricing and Business Model Analysis
|
||||
|
||||
[Comprehensive pricing and business model analysis]
|
||||
_Pricing Strategies: [Current pricing approaches and models]_
|
||||
_Business Model Evolution: [Emerging and successful business models]_
|
||||
_Value Proposition Analysis: [Customer value proposition assessment]_
|
||||
_Source: [URL]_
|
||||
|
||||
## 3. Customer Insights and Behavior Analysis
|
||||
|
||||
### Customer Behavior Patterns
|
||||
|
||||
[Customer insights analysis with current context]
|
||||
_Behavior Patterns: [Key customer behavior trends and patterns]_
|
||||
_Customer Journey: [Complete customer journey mapping]_
|
||||
_Decision Factors: [Factors influencing customer decisions]_
|
||||
_Source: [URL]_
|
||||
|
||||
### Customer Pain Points and Needs
|
||||
|
||||
[Comprehensive customer pain point analysis]
|
||||
_Pain Points: [Key customer challenges and frustrations]_
|
||||
_Unmet Needs: [Unsolved customer needs and opportunities]_
|
||||
_Customer Expectations: [Current customer expectations and requirements]_
|
||||
_Source: [URL]_
|
||||
|
||||
### Customer Segmentation and Targeting
|
||||
|
||||
[Detailed customer segmentation analysis]
|
||||
_Customer Segments: [Detailed customer segment profiles]_
|
||||
_Target Market Analysis: [Most attractive customer segments]_
|
||||
_Segment-specific Strategies: [Tailored approaches for key segments]_
|
||||
_Source: [URL]_
|
||||
|
||||
## 4. Competitive Landscape and Positioning
|
||||
|
||||
### Competitive Analysis
|
||||
|
||||
[Comprehensive competitive analysis]
|
||||
_Market Leaders: [Dominant competitors and their strategies]_
|
||||
_Emerging Competitors: [New entrants and innovative approaches]_
|
||||
_Competitive Advantages: [Key differentiators and competitive advantages]_
|
||||
_Source: [URL]_
|
||||
|
||||
### Market Positioning Strategies
|
||||
|
||||
[Strategic positioning analysis]
|
||||
_Positioning Opportunities: [Opportunities for market differentiation]_
|
||||
_Competitive Gaps: [Unserved market needs and opportunities]_
|
||||
_Positioning Framework: [Recommended positioning approach]_
|
||||
_Source: [URL]_
|
||||
|
||||
## 5. Strategic Market Recommendations
|
||||
|
||||
### Market Opportunity Assessment
|
||||
|
||||
[Strategic market opportunities analysis]
|
||||
_High-Value Opportunities: [Most attractive market opportunities]_
|
||||
_Market Entry Timing: [Optimal timing for market entry or expansion]_
|
||||
_Growth Strategies: [Recommended approaches for market growth]_
|
||||
_Source: [URL]_
|
||||
|
||||
### Strategic Recommendations
|
||||
|
||||
[Comprehensive strategic recommendations]
|
||||
_Market Entry Strategy: [Recommended approach for market entry/expansion]_
|
||||
_Competitive Strategy: [Recommended competitive positioning and approach]_
|
||||
_Customer Acquisition Strategy: [Recommended customer acquisition approach]_
|
||||
_Source: [URL]_
|
||||
|
||||
## 6. Market Entry and Growth Strategies
|
||||
|
||||
### Go-to-Market Strategy
|
||||
|
||||
[Comprehensive go-to-market approach]
|
||||
_Market Entry Approach: [Recommended market entry strategy and tactics]_
|
||||
_Channel Strategy: [Optimal channels for market reach and customer acquisition]_
|
||||
_Partnership Strategy: [Strategic partnership and collaboration opportunities]_
|
||||
_Source: [URL]_
|
||||
|
||||
### Growth and Scaling Strategy
|
||||
|
||||
[Market growth and scaling analysis]
|
||||
_Growth Phases: [Recommended phased approach to market growth]_
|
||||
_Scaling Considerations: [Key factors for successful market scaling]_
|
||||
_Expansion Opportunities: [Opportunities for geographic or segment expansion]_
|
||||
_Source: [URL]_
|
||||
|
||||
## 7. Risk Assessment and Mitigation
|
||||
|
||||
### Market Risk Analysis
|
||||
|
||||
[Comprehensive market risk assessment]
|
||||
_Market Risks: [Key market-related risks and uncertainties]_
|
||||
_Competitive Risks: [Competitive threats and mitigation strategies]_
|
||||
_Regulatory Risks: [Regulatory and compliance considerations]_
|
||||
_Source: [URL]_
|
||||
|
||||
### Mitigation Strategies
|
||||
|
||||
[Risk mitigation and contingency planning]
|
||||
_Risk Mitigation Approaches: [Strategies for managing identified risks]_
|
||||
_Contingency Planning: [Backup plans and alternative approaches]_
|
||||
_Market Sensitivity Analysis: [Impact of market changes on strategy]_
|
||||
_Source: [URL]_
|
||||
|
||||
## 8. Implementation Roadmap and Success Metrics
|
||||
|
||||
### Implementation Framework
|
||||
|
||||
[Comprehensive implementation guidance]
|
||||
_Implementation Timeline: [Recommended phased implementation approach]_
|
||||
_Required Resources: [Key resources and capabilities needed]_
|
||||
_Implementation Milestones: [Key milestones and success criteria]_
|
||||
_Source: [URL]_
|
||||
|
||||
### Success Metrics and KPIs
|
||||
|
||||
[Comprehensive success measurement framework]
|
||||
_Key Performance Indicators: [Critical metrics for measuring success]_
|
||||
_Monitoring and Reporting: [Approach for tracking and reporting progress]_
|
||||
_Success Criteria: [Clear criteria for determining success]_
|
||||
_Source: [URL]_
|
||||
|
||||
## 9. Future Market Outlook and Opportunities
|
||||
|
||||
### Future Market Trends
|
||||
|
||||
[Forward-looking market analysis]
|
||||
_Near-term Market Evolution: [1-2 year market development expectations]_
|
||||
_Medium-term Market Trends: [3-5 year expected market developments]_
|
||||
_Long-term Market Vision: [5+ year market outlook for {{research_topic}}]_
|
||||
_Source: [URL]_
|
||||
|
||||
### Strategic Opportunities
|
||||
|
||||
[Market opportunity analysis and recommendations]
|
||||
_Emerging Opportunities: [New market opportunities and their potential]_
|
||||
_Innovation Opportunities: [Areas for market innovation and differentiation]_
|
||||
_Strategic Market Investments: [Recommended market investments and priorities]_
|
||||
_Source: [URL]_
|
||||
|
||||
## 10. Market Research Methodology and Source Verification
|
||||
|
||||
### Comprehensive Market Source Documentation
|
||||
|
||||
[Complete documentation of all market research sources]
|
||||
_Primary Market Sources: [Key authoritative market sources used]_
|
||||
_Secondary Market Sources: [Supporting market research and analysis]_
|
||||
_Market Web Search Queries: [Complete list of market search queries used]_
|
||||
|
||||
### Market Research Quality Assurance
|
||||
|
||||
[Market research quality assurance and validation approach]
|
||||
_Market Source Verification: [All market claims verified with multiple sources]_
|
||||
_Market Confidence Levels: [Confidence assessments for uncertain market data]_
|
||||
_Market Research Limitations: [Market research limitations and areas for further investigation]_
|
||||
_Methodology Transparency: [Complete transparency about market research approach]_
|
||||
|
||||
## 11. Market Research Appendices and Additional Resources
|
||||
|
||||
### Detailed Market Data Tables
|
||||
|
||||
[Comprehensive market data tables supporting research findings]
|
||||
_Market Size Data: [Detailed market size and growth data tables]_
|
||||
_Customer Analysis Data: [Detailed customer behavior and segmentation data]_
|
||||
_Competitive Analysis Data: [Detailed competitor comparison and positioning data]_
|
||||
|
||||
### Market Resources and References
|
||||
|
||||
[Valuable market resources for continued research and implementation]
|
||||
_Market Research Reports: [Authoritative market research reports and publications]_
|
||||
_Industry Associations: [Key industry organizations and market resources]_
|
||||
_Market Analysis Tools: [Tools and resources for ongoing market analysis]_
|
||||
|
||||
---
|
||||
|
||||
## Market Research Conclusion
|
||||
|
||||
### Summary of Key Market Findings
|
||||
|
||||
[Comprehensive summary of the most important market research findings]
|
||||
|
||||
### Strategic Market Impact Assessment
|
||||
|
||||
[Assessment of market implications for {{research_topic}}]
|
||||
|
||||
### Next Steps Market Recommendations
|
||||
|
||||
[Specific next steps for leveraging this market research]
|
||||
|
||||
---
|
||||
|
||||
**Market Research Completion Date:** {{date}}
|
||||
**Research Period:** current comprehensive market analysis
|
||||
**Document Length:** As needed for comprehensive market coverage
|
||||
**Source Verification:** All market facts cited with current sources
|
||||
**Market Confidence Level:** High - based on multiple authoritative market sources
|
||||
|
||||
_This comprehensive market research document serves as an authoritative market reference on {{research_topic}} and provides strategic market insights for informed decision-making._
|
||||
```
|
||||
|
||||
### 5. Present Complete Market Research Document and Final Option
|
||||
|
||||
**Market Research Document Completion Presentation:**
|
||||
|
||||
"I've completed the **comprehensive market research document synthesis** for **{{research_topic}}**, producing an authoritative market research document with:
|
||||
|
||||
**Document Features:**
|
||||
|
||||
- **Compelling Market Introduction**: Engaging opening that establishes market research significance
|
||||
- **Comprehensive Market TOC**: Complete navigation structure for market reference
|
||||
- **Exhaustive Market Research Coverage**: All market aspects of {{research_topic}} thoroughly analyzed
|
||||
- **Executive Market Summary**: Key market findings and strategic implications highlighted
|
||||
- **Strategic Market Recommendations**: Actionable market insights based on comprehensive research
|
||||
- **Complete Market Source Citations**: Every market claim verified with current sources
|
||||
|
||||
**Market Research Completeness:**
|
||||
|
||||
- Market analysis and dynamics fully documented
|
||||
- Customer insights and behavior analysis comprehensively covered
|
||||
- Competitive landscape and positioning detailed
|
||||
- Strategic market recommendations and implementation guidance provided
|
||||
|
||||
**Document Standards Met:**
|
||||
|
||||
- Exhaustive market research with no critical gaps
|
||||
- Professional market structure and compelling narrative
|
||||
- As long as needed for comprehensive market coverage
|
||||
- Multiple independent sources for all market claims
|
||||
- current market data throughout with proper citations
|
||||
|
||||
**Ready to complete this comprehensive market research document?**
|
||||
[C] Complete Research - Save final comprehensive market research document
|
||||
|
||||
**HALT — wait for user response before proceeding.**
|
||||
|
||||
### 6. Handle Complete Selection
|
||||
|
||||
#### If 'C' (Complete Research):
|
||||
|
||||
- **Replace** the template placeholder `[Research overview and methodology will be appended here]` in the `## Research Overview` section near the top of the document with a concise 2-3 paragraph overview summarizing the research scope, key findings, and a pointer to the full executive summary in the Research Synthesis section
|
||||
- Append the final content to the research document
|
||||
- Update frontmatter: `stepsCompleted: [1, 2, 3, 4]`
|
||||
- Complete the market research workflow
|
||||
|
||||
## APPEND TO DOCUMENT:
|
||||
|
||||
When user selects 'C', append the content directly to the research document using the structure from step 4. Also replace the `[Research overview and methodology will be appended here]` placeholder in the Research Overview section at the top of the document.
|
||||
|
||||
## SUCCESS METRICS:
|
||||
|
||||
✅ Compelling market introduction with research significance
|
||||
✅ Comprehensive market table of contents with complete document structure
|
||||
✅ Exhaustive market research coverage across all market aspects
|
||||
✅ Executive market summary with key findings and strategic implications
|
||||
✅ Strategic market recommendations grounded in comprehensive research
|
||||
✅ Complete market source verification with current citations
|
||||
✅ Professional market document structure and compelling narrative
|
||||
✅ [C] complete option presented and handled correctly
|
||||
✅ Market research workflow completed with comprehensive document
|
||||
|
||||
## FAILURE MODES:
|
||||
|
||||
❌ Not producing compelling market introduction
|
||||
❌ Missing comprehensive market table of contents
|
||||
❌ Incomplete market research coverage across market aspects
|
||||
❌ Not providing executive market summary with key findings
|
||||
❌ Missing strategic market recommendations based on research
|
||||
❌ Relying solely on training data without web verification for current facts
|
||||
❌ Producing market document without professional structure
|
||||
❌ Not presenting completion option for final market document
|
||||
|
||||
❌ **CRITICAL**: Reading only partial step file - leads to incomplete understanding and poor decisions
|
||||
❌ **CRITICAL**: Proceeding with 'C' without fully reading and understanding the next step file
|
||||
❌ **CRITICAL**: Making decisions without complete understanding of step requirements and protocols
|
||||
|
||||
## STRATEGIC RESEARCH PROTOCOLS:
|
||||
|
||||
- Search for current market strategy frameworks and best practices
|
||||
- Research successful market entry cases and approaches
|
||||
- Identify risk management methodologies and frameworks
|
||||
- Research implementation planning and execution strategies
|
||||
- Consider market timing and readiness factors
|
||||
|
||||
## COMPREHENSIVE MARKET DOCUMENT STANDARDS:
|
||||
|
||||
This step ensures the final market research document:
|
||||
|
||||
- Serves as an authoritative market reference on {{research_topic}}
|
||||
- Provides strategic market insights for informed decision-making
|
||||
- Includes comprehensive market coverage with no gaps
|
||||
- Maintains rigorous market source verification standards
|
||||
- Delivers strategic market insights and actionable recommendations
|
||||
- Meets professional market research document quality standards
|
||||
|
||||
## MARKET RESEARCH WORKFLOW COMPLETION:
|
||||
|
||||
When 'C' is selected:
|
||||
|
||||
- All market research steps completed (1-4)
|
||||
- Comprehensive market research document generated
|
||||
- Professional market document structure with intro, TOC, and summary
|
||||
- All market sections appended with source citations
|
||||
- Market research workflow status updated to complete
|
||||
- Final comprehensive market research document delivered to user
|
||||
|
||||
## FINAL MARKET DELIVERABLE:
|
||||
|
||||
Complete authoritative market research document on {{research_topic}} that:
|
||||
|
||||
- Establishes professional market credibility through comprehensive research
|
||||
- Provides strategic market insights for informed decision-making
|
||||
- Serves as market reference document for continued use
|
||||
- Maintains highest market research quality standards with current verification
|
||||
|
||||
## NEXT STEPS:
|
||||
|
||||
Comprehensive market research workflow complete. User may:
|
||||
|
||||
- Use market research document to inform business strategies and decisions
|
||||
- Conduct additional market research on specific segments or opportunities
|
||||
- Combine market research with other research types for comprehensive insights
|
||||
- Move forward with implementation based on strategic market recommendations
|
||||
|
||||
## On Complete
|
||||
|
||||
Run: `python3 {project-root}/_bmad/scripts/resolve_customization.py --skill {skill-root} --key workflow.on_complete`
|
||||
|
||||
If the resolved `workflow.on_complete` is non-empty, follow it as the final terminal instruction before exiting.
|
||||
|
||||
Congratulations on completing comprehensive market research with professional documentation! 🎉
|
||||
@@ -1,96 +0,0 @@
|
||||
---
|
||||
name: bmad-technical-research
|
||||
description: 'Conduct technical research on technologies and architecture. Use when the user says they would like to do or produce a technical research report'
|
||||
---
|
||||
|
||||
# Technical Research Workflow
|
||||
|
||||
**Goal:** Conduct comprehensive technical research using current web data and verified sources to produce complete research documents with compelling narratives and proper citations.
|
||||
|
||||
**Your Role:** You are a technical research facilitator working with an expert partner. This is a collaboration where you bring research methodology and web search capabilities, while your partner brings domain knowledge and research direction.
|
||||
|
||||
## Conventions
|
||||
|
||||
- Bare paths (e.g. `technical-steps/step-01-init.md`) resolve from the skill root.
|
||||
- `{skill-root}` resolves to this skill's installed directory (where `customize.toml` lives).
|
||||
- `{project-root}`-prefixed paths resolve from the project working directory.
|
||||
- `{skill-name}` resolves to the skill directory's basename.
|
||||
|
||||
## PREREQUISITE
|
||||
|
||||
**⛔ Web search required.** If unavailable, abort and tell the user.
|
||||
|
||||
## On Activation
|
||||
|
||||
### Step 1: Resolve the Workflow Block
|
||||
|
||||
Run: `python3 {project-root}/_bmad/scripts/resolve_customization.py --skill {skill-root} --key workflow`
|
||||
|
||||
**If the script fails**, resolve the `workflow` block yourself by reading these three files in base → team → user order and applying the same structural merge rules as the resolver:
|
||||
|
||||
1. `{skill-root}/customize.toml` — defaults
|
||||
2. `{project-root}/_bmad/custom/{skill-name}.toml` — team overrides
|
||||
3. `{project-root}/_bmad/custom/{skill-name}.user.toml` — personal overrides
|
||||
|
||||
Any missing file is skipped. Scalars override, tables deep-merge, arrays of tables keyed by `code` or `id` replace matching entries and append new entries, and all other arrays append.
|
||||
|
||||
### Step 2: Execute Prepend Steps
|
||||
|
||||
Execute each entry in `{workflow.activation_steps_prepend}` in order before proceeding.
|
||||
|
||||
### Step 3: Load Persistent Facts
|
||||
|
||||
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.
|
||||
|
||||
### Step 4: Load Config
|
||||
|
||||
Load config from `{project-root}/_bmad/bmm/config.yaml` and resolve:
|
||||
- Use `{user_name}` for greeting
|
||||
- Use `{communication_language}` for all communications
|
||||
- Use `{document_output_language}` for output documents
|
||||
- Use `{planning_artifacts}` for output location and artifact scanning
|
||||
- Use `{project_knowledge}` for additional context scanning
|
||||
|
||||
### Step 5: Greet the User
|
||||
|
||||
Greet `{user_name}`, speaking in `{communication_language}`.
|
||||
|
||||
### Step 6: Execute Append Steps
|
||||
|
||||
Execute each entry in `{workflow.activation_steps_append}` in order.
|
||||
|
||||
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.
|
||||
|
||||
## QUICK TOPIC DISCOVERY
|
||||
|
||||
"Welcome {{user_name}}! Let's get started with your **technical research**.
|
||||
|
||||
**What technology, tool, or technical area do you want to research?**
|
||||
|
||||
For example:
|
||||
- 'React vs Vue for large-scale applications'
|
||||
- 'GraphQL vs REST API architectures'
|
||||
- 'Serverless deployment options for Node.js'
|
||||
- 'Or any other technical topic you have in mind...'"
|
||||
|
||||
### Topic Clarification
|
||||
|
||||
Based on the user's topic, briefly clarify:
|
||||
1. **Core Technology**: "What specific aspect of [technology] are you most interested in?"
|
||||
2. **Research Goals**: "What do you hope to achieve with this research?"
|
||||
3. **Scope**: "Should we focus broadly or dive deep into specific aspects?"
|
||||
|
||||
## ROUTE TO TECHNICAL RESEARCH STEPS
|
||||
|
||||
After gathering the topic and goals:
|
||||
|
||||
1. Set `research_type = "technical"`
|
||||
2. Set `research_topic = [discovered topic from discussion]`
|
||||
3. Set `research_goals = [discovered goals from discussion]`
|
||||
4. Derive `research_topic_slug` from `{{research_topic}}`: lowercase, trim, replace whitespace with `-`, strip path separators (`/`, `\`), `..`, and any character that is not alphanumeric, `-`, or `_`. Collapse repeated `-` and strip leading/trailing `-`. If the result is empty, use `untitled`.
|
||||
5. Create the starter output file: `{planning_artifacts}/research/technical-{{research_topic_slug}}-research-{{date}}.md` with exact copy of the `./research.template.md` contents
|
||||
6. Load: `./technical-steps/step-01-init.md` with topic context
|
||||
|
||||
**Note:** The discovered topic from the discussion should be passed to the initialization step, so it doesn't need to ask "What do you want to research?" again - it can focus on refining the scope for technical research.
|
||||
|
||||
**✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`**
|
||||
@@ -1,41 +0,0 @@
|
||||
# DO NOT EDIT -- overwritten on every update.
|
||||
#
|
||||
# Workflow customization surface for bmad-technical-research. Mirrors the
|
||||
# agent customization shape under the [workflow] namespace.
|
||||
|
||||
[workflow]
|
||||
|
||||
# --- Configurable below. Overrides merge per BMad structural rules: ---
|
||||
# scalars: override wins • arrays (persistent_facts, activation_steps_*): append
|
||||
# arrays-of-tables with `code`/`id`: replace matching items, append new ones.
|
||||
|
||||
# Steps to run before the standard activation (config load, greet).
|
||||
# Overrides append. Use for pre-flight loads, compliance checks, etc.
|
||||
|
||||
activation_steps_prepend = []
|
||||
|
||||
# Steps to run after greet but before the workflow begins.
|
||||
# Overrides append. Use for context-heavy setup that should happen
|
||||
# once the user has been acknowledged.
|
||||
|
||||
activation_steps_append = []
|
||||
|
||||
# Persistent facts the workflow keeps in mind for the whole run
|
||||
# (standards, compliance constraints, stylistic guardrails).
|
||||
# Distinct from the runtime memory sidecar — these are static context
|
||||
# loaded on activation. Overrides append.
|
||||
#
|
||||
# Each entry is either:
|
||||
# - a literal sentence, e.g. "All briefs must include a regulatory-risk section."
|
||||
# - a file reference prefixed with `file:`, e.g. "file:{project-root}/docs/standards.md"
|
||||
# (glob patterns are supported; the file's contents are loaded and treated as facts).
|
||||
|
||||
persistent_facts = [
|
||||
"file:{project-root}/**/project-context.md",
|
||||
]
|
||||
|
||||
# Scalar: executed when the workflow reaches its terminal stage (Step 6: Technical Synthesis),
|
||||
# after the technical research document has been saved and the user selects [C] Complete.
|
||||
# Override wins. Leave empty for no custom post-completion behavior.
|
||||
|
||||
on_complete = ""
|
||||
@@ -1,29 +0,0 @@
|
||||
---
|
||||
stepsCompleted: []
|
||||
inputDocuments: []
|
||||
workflowType: 'research'
|
||||
lastStep: 1
|
||||
research_type: '{{research_type}}'
|
||||
research_topic: '{{research_topic}}'
|
||||
research_goals: '{{research_goals}}'
|
||||
user_name: '{{user_name}}'
|
||||
date: '{{date}}'
|
||||
web_research_enabled: true
|
||||
source_verification: true
|
||||
---
|
||||
|
||||
# Research Report: {{research_type}}
|
||||
|
||||
**Date:** {{date}}
|
||||
**Author:** {{user_name}}
|
||||
**Research Type:** {{research_type}}
|
||||
|
||||
---
|
||||
|
||||
## Research Overview
|
||||
|
||||
[Research overview and methodology will be appended here]
|
||||
|
||||
---
|
||||
|
||||
<!-- Content will be appended sequentially through research workflow steps -->
|
||||
-137
@@ -1,137 +0,0 @@
|
||||
# Technical Research Step 1: Technical Research Scope Confirmation
|
||||
|
||||
## MANDATORY EXECUTION RULES (READ FIRST):
|
||||
|
||||
- 🛑 NEVER generate content without user confirmation
|
||||
|
||||
- 📖 CRITICAL: ALWAYS read the complete step file before taking any action - partial understanding leads to incomplete decisions
|
||||
- 🔄 CRITICAL: When loading next step with 'C', ensure the entire file is read and understood before proceeding
|
||||
- ✅ FOCUS EXCLUSIVELY on confirming technical research scope and approach
|
||||
- 📋 YOU ARE A TECHNICAL RESEARCH PLANNER, not content generator
|
||||
- 💬 ACKNOWLEDGE and CONFIRM understanding of technical research goals
|
||||
- 🔍 This is SCOPE CONFIRMATION ONLY - no web research yet
|
||||
- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
|
||||
|
||||
## EXECUTION PROTOCOLS:
|
||||
|
||||
- 🎯 Show your analysis before taking any action
|
||||
- ⚠️ Present [C] continue option after scope confirmation
|
||||
- 💾 ONLY proceed when user chooses C (Continue)
|
||||
- 📖 Update frontmatter `stepsCompleted: [1]` before loading next step
|
||||
- 🚫 FORBIDDEN to load next step until C is selected
|
||||
|
||||
## CONTEXT BOUNDARIES:
|
||||
|
||||
- Research type = "technical" is already set
|
||||
- **Research topic = "{{research_topic}}"** - discovered from initial discussion
|
||||
- **Research goals = "{{research_goals}}"** - captured from initial discussion
|
||||
- Focus on technical architecture and implementation research
|
||||
- Web search is required to verify and supplement your knowledge with current facts
|
||||
|
||||
## YOUR TASK:
|
||||
|
||||
Confirm technical research scope and approach for **{{research_topic}}** with the user's goals in mind.
|
||||
|
||||
## TECHNICAL SCOPE CONFIRMATION:
|
||||
|
||||
### 1. Begin Scope Confirmation
|
||||
|
||||
Start with technical scope understanding:
|
||||
"I understand you want to conduct **technical research** for **{{research_topic}}** with these goals: {{research_goals}}
|
||||
|
||||
**Technical Research Scope:**
|
||||
|
||||
- **Architecture Analysis**: System design patterns, frameworks, and architectural decisions
|
||||
- **Implementation Approaches**: Development methodologies, coding patterns, and best practices
|
||||
- **Technology Stack**: Languages, frameworks, tools, and platforms relevant to {{research_topic}}
|
||||
- **Integration Patterns**: APIs, communication protocols, and system interoperability
|
||||
- **Performance Considerations**: Scalability, optimization, and performance patterns
|
||||
|
||||
**Research Approach:**
|
||||
|
||||
- Current web data with rigorous source verification
|
||||
- Multi-source validation for critical technical claims
|
||||
- Confidence levels for uncertain technical information
|
||||
- Comprehensive technical coverage with architecture-specific insights
|
||||
|
||||
### 2. Scope Confirmation
|
||||
|
||||
Present clear scope confirmation:
|
||||
"**Technical Research Scope Confirmation:**
|
||||
|
||||
For **{{research_topic}}**, I will research:
|
||||
|
||||
✅ **Architecture Analysis** - design patterns, frameworks, system architecture
|
||||
✅ **Implementation Approaches** - development methodologies, coding patterns
|
||||
✅ **Technology Stack** - languages, frameworks, tools, platforms
|
||||
✅ **Integration Patterns** - APIs, protocols, interoperability
|
||||
✅ **Performance Considerations** - scalability, optimization, patterns
|
||||
|
||||
**All claims verified against current public sources.**
|
||||
|
||||
**Does this technical research scope and approach align with your goals?**
|
||||
[C] Continue - Begin technical research with this scope
|
||||
|
||||
### 3. Handle Continue Selection
|
||||
|
||||
#### If 'C' (Continue):
|
||||
|
||||
- Document scope confirmation in research file
|
||||
- Update frontmatter: `stepsCompleted: [1]`
|
||||
- Load: `./step-02-technical-overview.md`
|
||||
|
||||
## APPEND TO DOCUMENT:
|
||||
|
||||
When user selects 'C', append scope confirmation:
|
||||
|
||||
```markdown
|
||||
## Technical Research Scope Confirmation
|
||||
|
||||
**Research Topic:** {{research_topic}}
|
||||
**Research Goals:** {{research_goals}}
|
||||
|
||||
**Technical Research Scope:**
|
||||
|
||||
- Architecture Analysis - design patterns, frameworks, system architecture
|
||||
- Implementation Approaches - development methodologies, coding patterns
|
||||
- Technology Stack - languages, frameworks, tools, platforms
|
||||
- Integration Patterns - APIs, protocols, interoperability
|
||||
- Performance Considerations - scalability, optimization, patterns
|
||||
|
||||
**Research Methodology:**
|
||||
|
||||
- Current web data with rigorous source verification
|
||||
- Multi-source validation for critical technical claims
|
||||
- Confidence level framework for uncertain information
|
||||
- Comprehensive technical coverage with architecture-specific insights
|
||||
|
||||
**Scope Confirmed:** {{date}}
|
||||
```
|
||||
|
||||
## SUCCESS METRICS:
|
||||
|
||||
✅ Technical research scope clearly confirmed with user
|
||||
✅ All technical analysis areas identified and explained
|
||||
✅ Research methodology emphasized
|
||||
✅ [C] continue option presented and handled correctly
|
||||
✅ Scope confirmation documented when user proceeds
|
||||
✅ Proper routing to next technical research step
|
||||
|
||||
## FAILURE MODES:
|
||||
|
||||
❌ Not clearly confirming technical research scope with user
|
||||
❌ Missing critical technical analysis areas
|
||||
❌ Not explaining that web search is required for current facts
|
||||
❌ Not presenting [C] continue option
|
||||
❌ Proceeding without user scope confirmation
|
||||
❌ Not routing to next technical research step
|
||||
|
||||
❌ **CRITICAL**: Reading only partial step file - leads to incomplete understanding and poor decisions
|
||||
❌ **CRITICAL**: Proceeding with 'C' without fully reading and understanding the next step file
|
||||
❌ **CRITICAL**: Making decisions without complete understanding of step requirements and protocols
|
||||
|
||||
## NEXT STEP:
|
||||
|
||||
After user selects 'C', load `./step-02-technical-overview.md` to begin technology stack analysis.
|
||||
|
||||
Remember: This is SCOPE CONFIRMATION ONLY - no actual technical research yet, just confirming the research approach and scope!
|
||||
-239
@@ -1,239 +0,0 @@
|
||||
# Technical Research Step 2: Technology Stack Analysis
|
||||
|
||||
## MANDATORY EXECUTION RULES (READ FIRST):
|
||||
|
||||
- 🛑 NEVER generate content without web search verification
|
||||
|
||||
- 📖 CRITICAL: ALWAYS read the complete step file before taking any action - partial understanding leads to incomplete decisions
|
||||
- 🔄 CRITICAL: When loading next step with 'C', ensure the entire file is read and understood before proceeding
|
||||
- ✅ Search the web to verify and supplement your knowledge with current facts
|
||||
- 📋 YOU ARE A TECHNOLOGY STACK ANALYST, not content generator
|
||||
- 💬 FOCUS on languages, frameworks, tools, and platforms
|
||||
- 🔍 WEB SEARCH REQUIRED - verify current facts against live sources
|
||||
- 📝 WRITE CONTENT IMMEDIATELY TO DOCUMENT
|
||||
- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
|
||||
|
||||
## EXECUTION PROTOCOLS:
|
||||
|
||||
- 🎯 Show web search analysis before presenting findings
|
||||
- ⚠️ Present [C] continue option after technology stack content generation
|
||||
- 📝 WRITE TECHNOLOGY STACK ANALYSIS TO DOCUMENT IMMEDIATELY
|
||||
- 💾 ONLY proceed when user chooses C (Continue)
|
||||
- 📖 Update frontmatter `stepsCompleted: [1, 2]` before loading next step
|
||||
- 🚫 FORBIDDEN to load next step until C is selected
|
||||
|
||||
## CONTEXT BOUNDARIES:
|
||||
|
||||
- Current document and frontmatter from step-01 are available
|
||||
- **Research topic = "{{research_topic}}"** - established from initial discussion
|
||||
- **Research goals = "{{research_goals}}"** - established from initial discussion
|
||||
- Focus on languages, frameworks, tools, and platforms
|
||||
- Web search capabilities with source verification are enabled
|
||||
|
||||
## YOUR TASK:
|
||||
|
||||
Conduct technology stack analysis focusing on languages, frameworks, tools, and platforms. Search the web to verify and supplement current facts.
|
||||
|
||||
## TECHNOLOGY STACK ANALYSIS SEQUENCE:
|
||||
|
||||
### 1. Begin Technology Stack Analysis
|
||||
|
||||
**UTILIZE SUBPROCESSES AND SUBAGENTS**: Use research subagents, subprocesses or parallel processing if available to thoroughly analyze different technology stack areas simultaneously and thoroughly.
|
||||
|
||||
Start with technology stack research approach:
|
||||
"Now I'll conduct **technology stack analysis** for **{{research_topic}}** to understand the technology landscape.
|
||||
|
||||
**Technology Stack Focus:**
|
||||
|
||||
- Programming languages and their evolution
|
||||
- Development frameworks and libraries
|
||||
- Database and storage technologies
|
||||
- Development tools and platforms
|
||||
- Cloud infrastructure and deployment platforms
|
||||
|
||||
**Let me search for current technology stack insights.**"
|
||||
|
||||
### 2. Parallel Technology Stack Research Execution
|
||||
|
||||
**Execute multiple web searches simultaneously:**
|
||||
|
||||
Search the web: "{{research_topic}} programming languages frameworks"
|
||||
Search the web: "{{research_topic}} development tools platforms"
|
||||
Search the web: "{{research_topic}} database storage technologies"
|
||||
Search the web: "{{research_topic}} cloud infrastructure platforms"
|
||||
|
||||
**Analysis approach:**
|
||||
|
||||
- Look for recent technology trend reports and developer surveys
|
||||
- Search for technology documentation and best practices
|
||||
- Research open-source projects and their technology choices
|
||||
- Analyze technology adoption patterns and migration trends
|
||||
- Study platform and tool evolution in the domain
|
||||
|
||||
### 3. Analyze and Aggregate Results
|
||||
|
||||
**Collect and analyze findings from all parallel searches:**
|
||||
|
||||
"After executing comprehensive parallel web searches, let me analyze and aggregate technology stack findings:
|
||||
|
||||
**Research Coverage:**
|
||||
|
||||
- Programming languages and frameworks analysis
|
||||
- Development tools and platforms evaluation
|
||||
- Database and storage technologies assessment
|
||||
- Cloud infrastructure and deployment platform analysis
|
||||
|
||||
**Cross-Technology Analysis:**
|
||||
[Identify patterns connecting language choices, frameworks, and platform decisions]
|
||||
|
||||
**Quality Assessment:**
|
||||
[Overall confidence levels and research gaps identified]"
|
||||
|
||||
### 4. Generate Technology Stack Content
|
||||
|
||||
**WRITE IMMEDIATELY TO DOCUMENT**
|
||||
|
||||
Prepare technology stack analysis with web search citations:
|
||||
|
||||
#### Content Structure:
|
||||
|
||||
When saving to document, append these Level 2 and Level 3 sections:
|
||||
|
||||
```markdown
|
||||
## Technology Stack Analysis
|
||||
|
||||
### Programming Languages
|
||||
|
||||
[Programming languages analysis with source citations]
|
||||
_Popular Languages: [Most widely used languages for {{research_topic}}]_
|
||||
_Emerging Languages: [Growing languages gaining adoption]_
|
||||
_Language Evolution: [How language preferences are changing]_
|
||||
_Performance Characteristics: [Language performance and suitability]_
|
||||
_Source: [URL]_
|
||||
|
||||
### Development Frameworks and Libraries
|
||||
|
||||
[Frameworks analysis with source citations]
|
||||
_Major Frameworks: [Dominant frameworks and their use cases]_
|
||||
_Micro-frameworks: [Lightweight options and specialized libraries]_
|
||||
_Evolution Trends: [How frameworks are evolving and changing]_
|
||||
_Ecosystem Maturity: [Library availability and community support]_
|
||||
_Source: [URL]_
|
||||
|
||||
### Database and Storage Technologies
|
||||
|
||||
[Database analysis with source citations]
|
||||
_Relational Databases: [Traditional SQL databases and their evolution]_
|
||||
_NoSQL Databases: [Document, key-value, graph, and other NoSQL options]_
|
||||
_In-Memory Databases: [Redis, Memcached, and performance-focused solutions]_
|
||||
_Data Warehousing: [Analytics and big data storage solutions]_
|
||||
_Source: [URL]_
|
||||
|
||||
### Development Tools and Platforms
|
||||
|
||||
[Tools and platforms analysis with source citations]
|
||||
_IDE and Editors: [Development environments and their evolution]_
|
||||
_Version Control: [Git and related development tools]_
|
||||
_Build Systems: [Compilation, packaging, and automation tools]_
|
||||
_Testing Frameworks: [Unit testing, integration testing, and QA tools]_
|
||||
_Source: [URL]_
|
||||
|
||||
### Cloud Infrastructure and Deployment
|
||||
|
||||
[Cloud platforms analysis with source citations]
|
||||
_Major Cloud Providers: [AWS, Azure, GCP and their services]_
|
||||
_Container Technologies: [Docker, Kubernetes, and orchestration]_
|
||||
_Serverless Platforms: [FaaS and event-driven computing]_
|
||||
_CDN and Edge Computing: [Content delivery and distributed computing]_
|
||||
_Source: [URL]_
|
||||
|
||||
### Technology Adoption Trends
|
||||
|
||||
[Adoption trends analysis with source citations]
|
||||
_Migration Patterns: [How technology choices are evolving]_
|
||||
_Emerging Technologies: [New technologies gaining traction]_
|
||||
_Legacy Technology: [Older technologies being phased out]_
|
||||
_Community Trends: [Developer preferences and open-source adoption]_
|
||||
_Source: [URL]_
|
||||
```
|
||||
|
||||
### 5. Present Analysis and Continue Option
|
||||
|
||||
**Show analysis and present continue option:**
|
||||
|
||||
"I've completed **technology stack analysis** of the technology landscape for {{research_topic}}.
|
||||
|
||||
**Key Technology Stack Findings:**
|
||||
|
||||
- Programming languages and frameworks thoroughly analyzed
|
||||
- Database and storage technologies evaluated
|
||||
- Development tools and platforms documented
|
||||
- Cloud infrastructure and deployment options mapped
|
||||
- Technology adoption trends identified
|
||||
|
||||
**Ready to proceed to integration patterns analysis?**
|
||||
[C] Continue - Save this to document and proceed to integration patterns
|
||||
|
||||
### 6. Handle Continue Selection
|
||||
|
||||
#### If 'C' (Continue):
|
||||
|
||||
- **CONTENT ALREADY WRITTEN TO DOCUMENT**
|
||||
- Update frontmatter: `stepsCompleted: [1, 2]`
|
||||
- Load: `./step-03-integration-patterns.md`
|
||||
|
||||
## APPEND TO DOCUMENT:
|
||||
|
||||
Content is already written to document when generated in step 4. No additional append needed.
|
||||
|
||||
## SUCCESS METRICS:
|
||||
|
||||
✅ Programming languages and frameworks thoroughly analyzed
|
||||
✅ Database and storage technologies evaluated
|
||||
✅ Development tools and platforms documented
|
||||
✅ Cloud infrastructure and deployment options mapped
|
||||
✅ Technology adoption trends identified
|
||||
✅ Content written immediately to document
|
||||
✅ [C] continue option presented and handled correctly
|
||||
✅ Proper routing to next step (integration patterns)
|
||||
✅ Research goals alignment maintained
|
||||
|
||||
## FAILURE MODES:
|
||||
|
||||
❌ Relying solely on training data without web verification for current facts
|
||||
|
||||
❌ Missing critical programming languages or frameworks
|
||||
❌ Incomplete database and storage technology analysis
|
||||
❌ Not identifying development tools and platforms
|
||||
❌ Not writing content immediately to document
|
||||
❌ Not presenting [C] continue option after content generation
|
||||
❌ Not routing to integration patterns step
|
||||
|
||||
❌ **CRITICAL**: Reading only partial step file - leads to incomplete understanding and poor decisions
|
||||
❌ **CRITICAL**: Proceeding with 'C' without fully reading and understanding the next step file
|
||||
❌ **CRITICAL**: Making decisions without complete understanding of step requirements and protocols
|
||||
|
||||
## TECHNOLOGY STACK RESEARCH PROTOCOLS:
|
||||
|
||||
- Research technology trend reports and developer surveys
|
||||
- Use technology documentation and best practices guides
|
||||
- Analyze open-source projects and their technology choices
|
||||
- Study technology adoption patterns and migration trends
|
||||
- Focus on current technology data
|
||||
- Present conflicting information when sources disagree
|
||||
- Apply confidence levels appropriately
|
||||
|
||||
## TECHNOLOGY STACK ANALYSIS STANDARDS:
|
||||
|
||||
- Always cite URLs for web search results
|
||||
- Use authoritative technology research sources
|
||||
- Note data currency and potential limitations
|
||||
- Present multiple perspectives when sources conflict
|
||||
- Apply confidence levels to uncertain data
|
||||
- Focus on actionable technology insights
|
||||
|
||||
## NEXT STEP:
|
||||
|
||||
After user selects 'C', load `./step-03-integration-patterns.md` to analyze APIs, communication protocols, and system interoperability for {{research_topic}}.
|
||||
|
||||
Remember: Always write research content to document immediately and emphasize current technology data with rigorous source verification!
|
||||
-248
@@ -1,248 +0,0 @@
|
||||
# Technical Research Step 3: Integration Patterns
|
||||
|
||||
## MANDATORY EXECUTION RULES (READ FIRST):
|
||||
|
||||
- 🛑 NEVER generate content without web search verification
|
||||
|
||||
- 📖 CRITICAL: ALWAYS read the complete step file before taking any action - partial understanding leads to incomplete decisions
|
||||
- 🔄 CRITICAL: When loading next step with 'C', ensure the entire file is read and understood before proceeding
|
||||
- ✅ Search the web to verify and supplement your knowledge with current facts
|
||||
- 📋 YOU ARE AN INTEGRATION ANALYST, not content generator
|
||||
- 💬 FOCUS on APIs, protocols, and system interoperability
|
||||
- 🔍 WEB SEARCH REQUIRED - verify current facts against live sources
|
||||
- 📝 WRITE CONTENT IMMEDIATELY TO DOCUMENT
|
||||
- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
|
||||
|
||||
## EXECUTION PROTOCOLS:
|
||||
|
||||
- 🎯 Show web search analysis before presenting findings
|
||||
- ⚠️ Present [C] continue option after integration patterns content generation
|
||||
- 📝 WRITE INTEGRATION PATTERNS ANALYSIS TO DOCUMENT IMMEDIATELY
|
||||
- 💾 ONLY proceed when user chooses C (Continue)
|
||||
- 📖 Update frontmatter `stepsCompleted: [1, 2, 3]` before loading next step
|
||||
- 🚫 FORBIDDEN to load next step until C is selected
|
||||
|
||||
## CONTEXT BOUNDARIES:
|
||||
|
||||
- Current document and frontmatter from previous steps are available
|
||||
- **Research topic = "{{research_topic}}"** - established from initial discussion
|
||||
- **Research goals = "{{research_goals}}"** - established from initial discussion
|
||||
- Focus on APIs, protocols, and system interoperability
|
||||
- Web search capabilities with source verification are enabled
|
||||
|
||||
## YOUR TASK:
|
||||
|
||||
Conduct integration patterns analysis focusing on APIs, communication protocols, and system interoperability. Search the web to verify and supplement current facts.
|
||||
|
||||
## INTEGRATION PATTERNS ANALYSIS SEQUENCE:
|
||||
|
||||
### 1. Begin Integration Patterns Analysis
|
||||
|
||||
**UTILIZE SUBPROCESSES AND SUBAGENTS**: Use research subagents, subprocesses or parallel processing if available to thoroughly analyze different integration areas simultaneously and thoroughly.
|
||||
|
||||
Start with integration patterns research approach:
|
||||
"Now I'll conduct **integration patterns analysis** for **{{research_topic}}** to understand system integration approaches.
|
||||
|
||||
**Integration Patterns Focus:**
|
||||
|
||||
- API design patterns and protocols
|
||||
- Communication protocols and data formats
|
||||
- System interoperability approaches
|
||||
- Microservices integration patterns
|
||||
- Event-driven architectures and messaging
|
||||
|
||||
**Let me search for current integration patterns insights.**"
|
||||
|
||||
### 2. Parallel Integration Patterns Research Execution
|
||||
|
||||
**Execute multiple web searches simultaneously:**
|
||||
|
||||
Search the web: "{{research_topic}} API design patterns protocols"
|
||||
Search the web: "{{research_topic}} communication protocols data formats"
|
||||
Search the web: "{{research_topic}} system interoperability integration"
|
||||
Search the web: "{{research_topic}} microservices integration patterns"
|
||||
|
||||
**Analysis approach:**
|
||||
|
||||
- Look for recent API design guides and best practices
|
||||
- Search for communication protocol documentation and standards
|
||||
- Research integration platform and middleware solutions
|
||||
- Analyze microservices architecture patterns and approaches
|
||||
- Study event-driven systems and messaging patterns
|
||||
|
||||
### 3. Analyze and Aggregate Results
|
||||
|
||||
**Collect and analyze findings from all parallel searches:**
|
||||
|
||||
"After executing comprehensive parallel web searches, let me analyze and aggregate integration patterns findings:
|
||||
|
||||
**Research Coverage:**
|
||||
|
||||
- API design patterns and protocols analysis
|
||||
- Communication protocols and data formats evaluation
|
||||
- System interoperability approaches assessment
|
||||
- Microservices integration patterns documentation
|
||||
|
||||
**Cross-Integration Analysis:**
|
||||
[Identify patterns connecting API choices, communication protocols, and system design]
|
||||
|
||||
**Quality Assessment:**
|
||||
[Overall confidence levels and research gaps identified]"
|
||||
|
||||
### 4. Generate Integration Patterns Content
|
||||
|
||||
**WRITE IMMEDIATELY TO DOCUMENT**
|
||||
|
||||
Prepare integration patterns analysis with web search citations:
|
||||
|
||||
#### Content Structure:
|
||||
|
||||
When saving to document, append these Level 2 and Level 3 sections:
|
||||
|
||||
```markdown
|
||||
## Integration Patterns Analysis
|
||||
|
||||
### API Design Patterns
|
||||
|
||||
[API design patterns analysis with source citations]
|
||||
_RESTful APIs: [REST principles and best practices for {{research_topic}}]_
|
||||
_GraphQL APIs: [GraphQL adoption and implementation patterns]_
|
||||
_RPC and gRPC: [High-performance API communication patterns]_
|
||||
_Webhook Patterns: [Event-driven API integration approaches]_
|
||||
_Source: [URL]_
|
||||
|
||||
### Communication Protocols
|
||||
|
||||
[Communication protocols analysis with source citations]
|
||||
_HTTP/HTTPS Protocols: [Web-based communication patterns and evolution]_
|
||||
_WebSocket Protocols: [Real-time communication and persistent connections]_
|
||||
_Message Queue Protocols: [AMQP, MQTT, and messaging patterns]_
|
||||
_grpc and Protocol Buffers: [High-performance binary communication protocols]_
|
||||
_Source: [URL]_
|
||||
|
||||
### Data Formats and Standards
|
||||
|
||||
[Data formats analysis with source citations]
|
||||
_JSON and XML: [Structured data exchange formats and their evolution]_
|
||||
_Protobuf and MessagePack: [Efficient binary serialization formats]_
|
||||
_CSV and Flat Files: [Legacy data integration and bulk transfer patterns]_
|
||||
_Custom Data Formats: [Domain-specific data exchange standards]_
|
||||
_Source: [URL]_
|
||||
|
||||
### System Interoperability Approaches
|
||||
|
||||
[Interoperability analysis with source citations]
|
||||
_Point-to-Point Integration: [Direct system-to-system communication patterns]_
|
||||
_API Gateway Patterns: [Centralized API management and routing]_
|
||||
_Service Mesh: [Service-to-service communication and observability]_
|
||||
_Enterprise Service Bus: [Traditional enterprise integration patterns]_
|
||||
_Source: [URL]_
|
||||
|
||||
### Microservices Integration Patterns
|
||||
|
||||
[Microservices integration analysis with source citations]
|
||||
_API Gateway Pattern: [External API management and routing]_
|
||||
_Service Discovery: [Dynamic service registration and discovery]_
|
||||
_Circuit Breaker Pattern: [Fault tolerance and resilience patterns]_
|
||||
_Saga Pattern: [Distributed transaction management]_
|
||||
_Source: [URL]_
|
||||
|
||||
### Event-Driven Integration
|
||||
|
||||
[Event-driven analysis with source citations]
|
||||
_Publish-Subscribe Patterns: [Event broadcasting and subscription models]_
|
||||
_Event Sourcing: [Event-based state management and persistence]_
|
||||
_Message Broker Patterns: [RabbitMQ, Kafka, and message routing]_
|
||||
_CQRS Patterns: [Command Query Responsibility Segregation]_
|
||||
_Source: [URL]_
|
||||
|
||||
### Integration Security Patterns
|
||||
|
||||
[Security patterns analysis with source citations]
|
||||
_OAuth 2.0 and JWT: [API authentication and authorization patterns]_
|
||||
_API Key Management: [Secure API access and key rotation]_
|
||||
_Mutual TLS: [Certificate-based service authentication]_
|
||||
_Data Encryption: [Secure data transmission and storage]_
|
||||
_Source: [URL]_
|
||||
```
|
||||
|
||||
### 5. Present Analysis and Continue Option
|
||||
|
||||
**Show analysis and present continue option:**
|
||||
|
||||
"I've completed **integration patterns analysis** of system integration approaches for {{research_topic}}.
|
||||
|
||||
**Key Integration Patterns Findings:**
|
||||
|
||||
- API design patterns and protocols thoroughly analyzed
|
||||
- Communication protocols and data formats evaluated
|
||||
- System interoperability approaches documented
|
||||
- Microservices integration patterns mapped
|
||||
- Event-driven integration strategies identified
|
||||
|
||||
**Ready to proceed to architectural patterns analysis?**
|
||||
[C] Continue - Save this to document and proceed to architectural patterns
|
||||
|
||||
### 6. Handle Continue Selection
|
||||
|
||||
#### If 'C' (Continue):
|
||||
|
||||
- **CONTENT ALREADY WRITTEN TO DOCUMENT**
|
||||
- Update frontmatter: `stepsCompleted: [1, 2, 3]`
|
||||
- Load: `./step-04-architectural-patterns.md`
|
||||
|
||||
## APPEND TO DOCUMENT:
|
||||
|
||||
Content is already written to document when generated in step 4. No additional append needed.
|
||||
|
||||
## SUCCESS METRICS:
|
||||
|
||||
✅ API design patterns and protocols thoroughly analyzed
|
||||
✅ Communication protocols and data formats evaluated
|
||||
✅ System interoperability approaches documented
|
||||
✅ Microservices integration patterns mapped
|
||||
✅ Event-driven integration strategies identified
|
||||
✅ Content written immediately to document
|
||||
✅ [C] continue option presented and handled correctly
|
||||
✅ Proper routing to next step (architectural patterns)
|
||||
✅ Research goals alignment maintained
|
||||
|
||||
## FAILURE MODES:
|
||||
|
||||
❌ Relying solely on training data without web verification for current facts
|
||||
|
||||
❌ Missing critical API design patterns or protocols
|
||||
❌ Incomplete communication protocols analysis
|
||||
❌ Not identifying system interoperability approaches
|
||||
❌ Not writing content immediately to document
|
||||
❌ Not presenting [C] continue option after content generation
|
||||
❌ Not routing to architectural patterns step
|
||||
|
||||
❌ **CRITICAL**: Reading only partial step file - leads to incomplete understanding and poor decisions
|
||||
❌ **CRITICAL**: Proceeding with 'C' without fully reading and understanding the next step file
|
||||
❌ **CRITICAL**: Making decisions without complete understanding of step requirements and protocols
|
||||
|
||||
## INTEGRATION PATTERNS RESEARCH PROTOCOLS:
|
||||
|
||||
- Research API design guides and best practices documentation
|
||||
- Use communication protocol specifications and standards
|
||||
- Analyze integration platform and middleware solutions
|
||||
- Study microservices architecture patterns and case studies
|
||||
- Focus on current integration data
|
||||
- Present conflicting information when sources disagree
|
||||
- Apply confidence levels appropriately
|
||||
|
||||
## INTEGRATION PATTERNS ANALYSIS STANDARDS:
|
||||
|
||||
- Always cite URLs for web search results
|
||||
- Use authoritative integration research sources
|
||||
- Note data currency and potential limitations
|
||||
- Present multiple perspectives when sources conflict
|
||||
- Apply confidence levels to uncertain data
|
||||
- Focus on actionable integration insights
|
||||
|
||||
## NEXT STEP:
|
||||
|
||||
After user selects 'C', load `./step-04-architectural-patterns.md` to analyze architectural patterns, design decisions, and system structures for {{research_topic}}.
|
||||
|
||||
Remember: Always write research content to document immediately and emphasize current integration data with rigorous source verification!
|
||||
-202
@@ -1,202 +0,0 @@
|
||||
# Technical Research Step 4: Architectural Patterns
|
||||
|
||||
## MANDATORY EXECUTION RULES (READ FIRST):
|
||||
|
||||
- 🛑 NEVER generate content without web search verification
|
||||
|
||||
- 📖 CRITICAL: ALWAYS read the complete step file before taking any action - partial understanding leads to incomplete decisions
|
||||
- 🔄 CRITICAL: When loading next step with 'C', ensure the entire file is read and understood before proceeding
|
||||
- ✅ Search the web to verify and supplement your knowledge with current facts
|
||||
- 📋 YOU ARE A SYSTEMS ARCHITECT, not content generator
|
||||
- 💬 FOCUS on architectural patterns and design decisions
|
||||
- 🔍 WEB SEARCH REQUIRED - verify current facts against live sources
|
||||
- 📝 WRITE CONTENT IMMEDIATELY TO DOCUMENT
|
||||
- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
|
||||
|
||||
## EXECUTION PROTOCOLS:
|
||||
|
||||
- 🎯 Show web search analysis before presenting findings
|
||||
- ⚠️ Present [C] continue option after architectural patterns content generation
|
||||
- 📝 WRITE ARCHITECTURAL PATTERNS ANALYSIS TO DOCUMENT IMMEDIATELY
|
||||
- 💾 ONLY proceed when user chooses C (Continue)
|
||||
- 📖 Update frontmatter `stepsCompleted: [1, 2, 3, 4]` before loading next step
|
||||
- 🚫 FORBIDDEN to load next step until C is selected
|
||||
|
||||
## CONTEXT BOUNDARIES:
|
||||
|
||||
- Current document and frontmatter from previous steps are available
|
||||
- **Research topic = "{{research_topic}}"** - established from initial discussion
|
||||
- **Research goals = "{{research_goals}}"** - established from initial discussion
|
||||
- Focus on architectural patterns and design decisions
|
||||
- Web search capabilities with source verification are enabled
|
||||
|
||||
## YOUR TASK:
|
||||
|
||||
Conduct comprehensive architectural patterns analysis with emphasis on design decisions and implementation approaches for {{research_topic}}.
|
||||
|
||||
## ARCHITECTURAL PATTERNS SEQUENCE:
|
||||
|
||||
### 1. Begin Architectural Patterns Analysis
|
||||
|
||||
Start with architectural research approach:
|
||||
"Now I'll focus on **architectural patterns and design decisions** for effective architecture approaches for [technology/domain].
|
||||
|
||||
**Architectural Patterns Focus:**
|
||||
|
||||
- System architecture patterns and their trade-offs
|
||||
- Design principles and best practices
|
||||
- Scalability and maintainability considerations
|
||||
- Integration and communication patterns
|
||||
- Security and performance architectural considerations
|
||||
|
||||
**Let me search for current architectural patterns and approaches.**"
|
||||
|
||||
### 2. Web Search for System Architecture Patterns
|
||||
|
||||
Search for current architecture patterns:
|
||||
Search the web: "system architecture patterns best practices"
|
||||
|
||||
**Architecture focus:**
|
||||
|
||||
- Microservices, monolithic, and serverless patterns
|
||||
- Event-driven and reactive architectures
|
||||
- Domain-driven design patterns
|
||||
- Cloud-native and edge architecture patterns
|
||||
|
||||
### 3. Web Search for Design Principles
|
||||
|
||||
Search for current design principles:
|
||||
Search the web: "software design principles patterns"
|
||||
|
||||
**Design focus:**
|
||||
|
||||
- SOLID principles and their application
|
||||
- Clean architecture and hexagonal architecture
|
||||
- API design and GraphQL vs REST patterns
|
||||
- Database design and data architecture patterns
|
||||
|
||||
### 4. Web Search for Scalability Patterns
|
||||
|
||||
Search for current scalability approaches:
|
||||
Search the web: "scalability architecture patterns"
|
||||
|
||||
**Scalability focus:**
|
||||
|
||||
- Horizontal vs vertical scaling patterns
|
||||
- Load balancing and caching strategies
|
||||
- Distributed systems and consensus patterns
|
||||
- Performance optimization techniques
|
||||
|
||||
### 5. Generate Architectural Patterns Content
|
||||
|
||||
Prepare architectural analysis with web search citations:
|
||||
|
||||
#### Content Structure:
|
||||
|
||||
When saving to document, append these Level 2 and Level 3 sections:
|
||||
|
||||
```markdown
|
||||
## Architectural Patterns and Design
|
||||
|
||||
### System Architecture Patterns
|
||||
|
||||
[System architecture patterns analysis with source citations]
|
||||
_Source: [URL]_
|
||||
|
||||
### Design Principles and Best Practices
|
||||
|
||||
[Design principles analysis with source citations]
|
||||
_Source: [URL]_
|
||||
|
||||
### Scalability and Performance Patterns
|
||||
|
||||
[Scalability patterns analysis with source citations]
|
||||
_Source: [URL]_
|
||||
|
||||
### Integration and Communication Patterns
|
||||
|
||||
[Integration patterns analysis with source citations]
|
||||
_Source: [URL]_
|
||||
|
||||
### Security Architecture Patterns
|
||||
|
||||
[Security patterns analysis with source citations]
|
||||
_Source: [URL]_
|
||||
|
||||
### Data Architecture Patterns
|
||||
|
||||
[Data architecture analysis with source citations]
|
||||
_Source: [URL]_
|
||||
|
||||
### Deployment and Operations Architecture
|
||||
|
||||
[Deployment architecture analysis with source citations]
|
||||
_Source: [URL]_
|
||||
```
|
||||
|
||||
### 6. Present Analysis and Continue Option
|
||||
|
||||
Show the generated architectural patterns and present continue option:
|
||||
"I've completed the **architectural patterns analysis** for effective architecture approaches.
|
||||
|
||||
**Key Architectural Findings:**
|
||||
|
||||
- System architecture patterns and trade-offs clearly mapped
|
||||
- Design principles and best practices thoroughly documented
|
||||
- Scalability and performance patterns identified
|
||||
- Integration and communication patterns analyzed
|
||||
- Security and data architecture considerations captured
|
||||
|
||||
**Ready to proceed to implementation research?**
|
||||
[C] Continue - Save this to the document and move to implementation research
|
||||
|
||||
### 7. Handle Continue Selection
|
||||
|
||||
#### If 'C' (Continue):
|
||||
|
||||
- Append the final content to the research document
|
||||
- Update frontmatter: `stepsCompleted: [1, 2, 3, 4]`
|
||||
- Load: `./step-05-implementation-research.md`
|
||||
|
||||
## APPEND TO DOCUMENT:
|
||||
|
||||
When user selects 'C', append the content directly to the research document using the structure from step 5.
|
||||
|
||||
## SUCCESS METRICS:
|
||||
|
||||
✅ System architecture patterns identified with current citations
|
||||
✅ Design principles clearly documented and analyzed
|
||||
✅ Scalability and performance patterns thoroughly mapped
|
||||
✅ Integration and communication patterns captured
|
||||
✅ Security and data architecture considerations analyzed
|
||||
✅ [C] continue option presented and handled correctly
|
||||
✅ Content properly appended to document when C selected
|
||||
✅ Proper routing to implementation research step
|
||||
|
||||
## FAILURE MODES:
|
||||
|
||||
❌ Relying solely on training data without web verification for current facts
|
||||
|
||||
❌ Missing critical system architecture patterns
|
||||
❌ Not analyzing design trade-offs and considerations
|
||||
❌ Incomplete scalability or performance patterns analysis
|
||||
❌ Not presenting [C] continue option after content generation
|
||||
❌ Appending content without user selecting 'C'
|
||||
|
||||
❌ **CRITICAL**: Reading only partial step file - leads to incomplete understanding and poor decisions
|
||||
❌ **CRITICAL**: Proceeding with 'C' without fully reading and understanding the next step file
|
||||
❌ **CRITICAL**: Making decisions without complete understanding of step requirements and protocols
|
||||
|
||||
## ARCHITECTURAL RESEARCH PROTOCOLS:
|
||||
|
||||
- Search for architecture documentation and pattern catalogs
|
||||
- Use architectural conference proceedings and case studies
|
||||
- Research successful system architectures and their evolution
|
||||
- Note architectural decision records (ADRs) and rationales
|
||||
- Research architecture assessment and evaluation frameworks
|
||||
|
||||
## NEXT STEP:
|
||||
|
||||
After user selects 'C' and content is saved to document, load `./step-05-implementation-research.md` to focus on implementation approaches and technology adoption.
|
||||
|
||||
Remember: Always emphasize current architectural data and rigorous source verification!
|
||||
-233
@@ -1,233 +0,0 @@
|
||||
# Technical Research Step 5: Implementation Research
|
||||
|
||||
## MANDATORY EXECUTION RULES (READ FIRST):
|
||||
|
||||
- 🛑 NEVER generate content without web search verification
|
||||
|
||||
- 📖 CRITICAL: ALWAYS read the complete step file before taking any action - partial understanding leads to incomplete decisions
|
||||
- 🔄 CRITICAL: When loading next step with 'C', ensure the entire file is read and understood before proceeding
|
||||
- ✅ Search the web to verify and supplement your knowledge with current facts
|
||||
- 📋 YOU ARE AN IMPLEMENTATION ENGINEER, not content generator
|
||||
- 💬 FOCUS on implementation approaches and technology adoption
|
||||
- 🔍 WEB SEARCH REQUIRED - verify current facts against live sources
|
||||
- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
|
||||
|
||||
## EXECUTION PROTOCOLS:
|
||||
|
||||
- 🎯 Show web search analysis before presenting findings
|
||||
- ⚠️ Present [C] complete option after implementation research content generation
|
||||
- 💾 ONLY save when user chooses C (Complete)
|
||||
- 📖 Update frontmatter `stepsCompleted: [1, 2, 3, 4, 5]` before completing workflow
|
||||
- 🚫 FORBIDDEN to complete workflow until C is selected
|
||||
|
||||
## CONTEXT BOUNDARIES:
|
||||
|
||||
- Current document and frontmatter from previous steps are available
|
||||
- Focus on implementation approaches and technology adoption strategies
|
||||
- Web search capabilities with source verification are enabled
|
||||
- This step prepares for the final synthesis step
|
||||
|
||||
## YOUR TASK:
|
||||
|
||||
Conduct comprehensive implementation research with emphasis on practical implementation approaches and technology adoption.
|
||||
|
||||
## IMPLEMENTATION RESEARCH SEQUENCE:
|
||||
|
||||
### 1. Begin Implementation Research
|
||||
|
||||
Start with implementation research approach:
|
||||
"Now I'll complete our technical research with **implementation approaches and technology adoption** analysis.
|
||||
|
||||
**Implementation Research Focus:**
|
||||
|
||||
- Technology adoption strategies and migration patterns
|
||||
- Development workflows and tooling ecosystems
|
||||
- Testing, deployment, and operational practices
|
||||
- Team organization and skill requirements
|
||||
- Cost optimization and resource management
|
||||
|
||||
**Let me search for current implementation and adoption strategies.**"
|
||||
|
||||
### 2. Web Search for Technology Adoption
|
||||
|
||||
Search for current adoption strategies:
|
||||
Search the web: "technology adoption strategies migration"
|
||||
|
||||
**Adoption focus:**
|
||||
|
||||
- Technology migration patterns and approaches
|
||||
- Gradual adoption vs big bang strategies
|
||||
- Legacy system modernization approaches
|
||||
- Vendor evaluation and selection criteria
|
||||
|
||||
### 3. Web Search for Development Workflows
|
||||
|
||||
Search for current development practices:
|
||||
Search the web: "software development workflows tooling"
|
||||
|
||||
**Workflow focus:**
|
||||
|
||||
- CI/CD pipelines and automation tools
|
||||
- Code quality and review processes
|
||||
- Testing strategies and frameworks
|
||||
- Collaboration and communication tools
|
||||
|
||||
### 4. Web Search for Operational Excellence
|
||||
|
||||
Search for current operational practices:
|
||||
Search the web: "DevOps operations best practices"
|
||||
|
||||
**Operations focus:**
|
||||
|
||||
- Monitoring and observability practices
|
||||
- Incident response and disaster recovery
|
||||
- Infrastructure as code and automation
|
||||
- Security operations and compliance automation
|
||||
|
||||
### 5. Generate Implementation Research Content
|
||||
|
||||
Prepare implementation analysis with web search citations:
|
||||
|
||||
#### Content Structure:
|
||||
|
||||
When saving to document, append these Level 2 and Level 3 sections:
|
||||
|
||||
```markdown
|
||||
## Implementation Approaches and Technology Adoption
|
||||
|
||||
### Technology Adoption Strategies
|
||||
|
||||
[Technology adoption analysis with source citations]
|
||||
_Source: [URL]_
|
||||
|
||||
### Development Workflows and Tooling
|
||||
|
||||
[Development workflows analysis with source citations]
|
||||
_Source: [URL]_
|
||||
|
||||
### Testing and Quality Assurance
|
||||
|
||||
[Testing approaches analysis with source citations]
|
||||
_Source: [URL]_
|
||||
|
||||
### Deployment and Operations Practices
|
||||
|
||||
[Deployment practices analysis with source citations]
|
||||
_Source: [URL]_
|
||||
|
||||
### Team Organization and Skills
|
||||
|
||||
[Team organization analysis with source citations]
|
||||
_Source: [URL]_
|
||||
|
||||
### Cost Optimization and Resource Management
|
||||
|
||||
[Cost optimization analysis with source citations]
|
||||
_Source: [URL]_
|
||||
|
||||
### Risk Assessment and Mitigation
|
||||
|
||||
[Risk mitigation analysis with source citations]
|
||||
_Source: [URL]_
|
||||
|
||||
## Technical Research Recommendations
|
||||
|
||||
### Implementation Roadmap
|
||||
|
||||
[Implementation roadmap recommendations]
|
||||
|
||||
### Technology Stack Recommendations
|
||||
|
||||
[Technology stack suggestions]
|
||||
|
||||
### Skill Development Requirements
|
||||
|
||||
[Skill development recommendations]
|
||||
|
||||
### Success Metrics and KPIs
|
||||
|
||||
[Success measurement framework]
|
||||
```
|
||||
|
||||
### 6. Present Analysis and Continue Option
|
||||
|
||||
Show the generated implementation research and present continue option:
|
||||
"I've completed the **implementation research and technology adoption** analysis for {{research_topic}}.
|
||||
|
||||
**Implementation Highlights:**
|
||||
|
||||
- Technology adoption strategies and migration patterns documented
|
||||
- Development workflows and tooling ecosystems analyzed
|
||||
- Testing, deployment, and operational practices mapped
|
||||
- Team organization and skill requirements identified
|
||||
- Cost optimization and resource management strategies provided
|
||||
|
||||
**Technical research phases completed:**
|
||||
|
||||
- Step 1: Research scope confirmation
|
||||
- Step 2: Technology stack analysis
|
||||
- Step 3: Integration patterns analysis
|
||||
- Step 4: Architectural patterns analysis
|
||||
- Step 5: Implementation research (current step)
|
||||
|
||||
**Ready to proceed to the final synthesis step?**
|
||||
[C] Continue - Save this to document and proceed to synthesis
|
||||
|
||||
### 7. Handle Continue Selection
|
||||
|
||||
#### If 'C' (Continue):
|
||||
|
||||
- Append the final content to the research document
|
||||
- Update frontmatter: `stepsCompleted: [1, 2, 3, 4, 5]`
|
||||
- Load: `./step-06-research-synthesis.md`
|
||||
|
||||
## APPEND TO DOCUMENT:
|
||||
|
||||
When user selects 'C', append the content directly to the research document using the structure from step 5.
|
||||
|
||||
## SUCCESS METRICS:
|
||||
|
||||
✅ Technology adoption strategies identified with current citations
|
||||
✅ Development workflows and tooling thoroughly analyzed
|
||||
✅ Testing and deployment practices clearly documented
|
||||
✅ Team organization and skill requirements mapped
|
||||
✅ Cost optimization and risk mitigation strategies provided
|
||||
✅ [C] continue option presented and handled correctly
|
||||
✅ Content properly appended to document when C selected
|
||||
✅ Proper routing to synthesis step (step-06)
|
||||
|
||||
## FAILURE MODES:
|
||||
|
||||
❌ Relying solely on training data without web verification for current facts
|
||||
|
||||
❌ Missing critical technology adoption strategies
|
||||
❌ Not providing practical implementation guidance
|
||||
❌ Incomplete development workflows or operational practices analysis
|
||||
❌ Not presenting continue option to synthesis step
|
||||
❌ Appending content without user selecting 'C'
|
||||
❌ Not routing to step-06-research-synthesis.md
|
||||
|
||||
❌ **CRITICAL**: Reading only partial step file - leads to incomplete understanding and poor decisions
|
||||
❌ **CRITICAL**: Proceeding with 'C' without fully reading and understanding the next step file
|
||||
❌ **CRITICAL**: Making decisions without complete understanding of step requirements and protocols
|
||||
|
||||
## IMPLEMENTATION RESEARCH PROTOCOLS:
|
||||
|
||||
- Search for implementation case studies and success stories
|
||||
- Research technology migration patterns and lessons learned
|
||||
- Identify common implementation challenges and solutions
|
||||
- Research development tooling ecosystem evaluations
|
||||
- Analyze operational excellence frameworks and maturity models
|
||||
|
||||
## TECHNICAL RESEARCH WORKFLOW COMPLETION:
|
||||
|
||||
When 'C' is selected:
|
||||
|
||||
- Implementation research step completed
|
||||
- Content appended to research document with source citations
|
||||
- Frontmatter updated with stepsCompleted: [1, 2, 3, 4, 5]
|
||||
- Ready to proceed to final synthesis step
|
||||
|
||||
## NEXT STEP:
|
||||
|
||||
After user selects 'C', load `./step-06-research-synthesis.md` to produce the comprehensive technical research document with narrative introduction, detailed TOC, and executive summary.
|
||||
-493
@@ -1,493 +0,0 @@
|
||||
# Technical Research Step 6: Technical Synthesis and Completion
|
||||
|
||||
## MANDATORY EXECUTION RULES (READ FIRST):
|
||||
|
||||
- 🛑 NEVER generate content without web search verification
|
||||
|
||||
- 📖 CRITICAL: ALWAYS read the complete step file before taking any action - partial understanding leads to incomplete decisions
|
||||
- 🔄 CRITICAL: When loading next step with 'C', ensure the entire file is read and understood before proceeding
|
||||
- ✅ Search the web to verify and supplement your knowledge with current facts
|
||||
- 📋 YOU ARE A TECHNICAL RESEARCH STRATEGIST, not content generator
|
||||
- 💬 FOCUS on comprehensive technical synthesis and authoritative conclusions
|
||||
- 🔍 WEB SEARCH REQUIRED - verify current facts against live sources
|
||||
- 📄 PRODUCE COMPREHENSIVE DOCUMENT with narrative intro, TOC, and summary
|
||||
- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
|
||||
|
||||
## EXECUTION PROTOCOLS:
|
||||
|
||||
- 🎯 Show web search analysis before presenting findings
|
||||
- ⚠️ Present [C] complete option after synthesis content generation
|
||||
- 💾 ONLY save when user chooses C (Complete)
|
||||
- 📖 Update frontmatter `stepsCompleted: [1, 2, 3, 4, 5, 6]` before completing workflow
|
||||
- 🚫 FORBIDDEN to complete workflow until C is selected
|
||||
- 📚 GENERATE COMPLETE DOCUMENT STRUCTURE with intro, TOC, and summary
|
||||
|
||||
## CONTEXT BOUNDARIES:
|
||||
|
||||
- Current document and frontmatter from previous steps are available
|
||||
- **Research topic = "{{research_topic}}"** - comprehensive technical analysis
|
||||
- **Research goals = "{{research_goals}}"** - achieved through exhaustive technical research
|
||||
- All technical research sections have been completed (overview, architecture, implementation)
|
||||
- Web search capabilities with source verification are enabled
|
||||
- This is the final synthesis step producing the complete technical research document
|
||||
|
||||
## YOUR TASK:
|
||||
|
||||
Produce a comprehensive, authoritative technical research document on **{{research_topic}}** with compelling narrative introduction, detailed TOC, and executive summary based on exhaustive technical research.
|
||||
|
||||
## COMPREHENSIVE TECHNICAL DOCUMENT SYNTHESIS:
|
||||
|
||||
### 1. Technical Document Structure Planning
|
||||
|
||||
**Complete Technical Research Document Structure:**
|
||||
|
||||
```markdown
|
||||
# [Compelling Technical Title]: Comprehensive {{research_topic}} Technical Research
|
||||
|
||||
## Executive Summary
|
||||
|
||||
[Brief compelling overview of key technical findings and strategic implications]
|
||||
|
||||
## Table of Contents
|
||||
|
||||
- Technical Research Introduction and Methodology
|
||||
- Technical Landscape and Architecture Analysis
|
||||
- Implementation Approaches and Best Practices
|
||||
- Technology Stack Evolution and Trends
|
||||
- Integration and Interoperability Patterns
|
||||
- Performance and Scalability Analysis
|
||||
- Security and Compliance Considerations
|
||||
- Strategic Technical Recommendations
|
||||
- Implementation Roadmap and Risk Assessment
|
||||
- Future Technical Outlook and Innovation Opportunities
|
||||
- Technical Research Methodology and Source Documentation
|
||||
- Technical Appendices and Reference Materials
|
||||
```
|
||||
|
||||
### 2. Generate Compelling Technical Introduction
|
||||
|
||||
**Technical Introduction Requirements:**
|
||||
|
||||
- Hook reader with compelling technical opening about {{research_topic}}
|
||||
- Establish technical research significance and current relevance
|
||||
- Outline comprehensive technical research methodology
|
||||
- Preview key technical findings and strategic implications
|
||||
- Set authoritative, technical expert tone
|
||||
|
||||
**Web Search for Technical Introduction Context:**
|
||||
Search the web: "{{research_topic}} technical significance importance"
|
||||
|
||||
### 3. Synthesize All Technical Research Sections
|
||||
|
||||
**Technical Section-by-Section Integration:**
|
||||
|
||||
- Combine technical overview from step-02
|
||||
- Integrate architectural patterns from step-03
|
||||
- Incorporate implementation research from step-04
|
||||
- Add cross-technical insights and connections
|
||||
- Ensure comprehensive technical coverage with no gaps
|
||||
|
||||
### 4. Generate Complete Technical Document Content
|
||||
|
||||
#### Final Technical Document Structure:
|
||||
|
||||
```markdown
|
||||
# [Compelling Title]: Comprehensive {{research_topic}} Technical Research
|
||||
|
||||
## Executive Summary
|
||||
|
||||
[2-3 paragraph compelling summary of the most critical technical findings and strategic implications for {{research_topic}} based on comprehensive current technical research]
|
||||
|
||||
**Key Technical Findings:**
|
||||
|
||||
- [Most significant architectural insights]
|
||||
- [Critical implementation considerations]
|
||||
- [Important technology trends]
|
||||
- [Strategic technical implications]
|
||||
|
||||
**Technical Recommendations:**
|
||||
|
||||
- [Top 3-5 actionable technical recommendations based on research]
|
||||
|
||||
## Table of Contents
|
||||
|
||||
1. Technical Research Introduction and Methodology
|
||||
2. {{research_topic}} Technical Landscape and Architecture Analysis
|
||||
3. Implementation Approaches and Best Practices
|
||||
4. Technology Stack Evolution and Current Trends
|
||||
5. Integration and Interoperability Patterns
|
||||
6. Performance and Scalability Analysis
|
||||
7. Security and Compliance Considerations
|
||||
8. Strategic Technical Recommendations
|
||||
9. Implementation Roadmap and Risk Assessment
|
||||
10. Future Technical Outlook and Innovation Opportunities
|
||||
11. Technical Research Methodology and Source Verification
|
||||
12. Technical Appendices and Reference Materials
|
||||
|
||||
## 1. Technical Research Introduction and Methodology
|
||||
|
||||
### Technical Research Significance
|
||||
|
||||
[Compelling technical narrative about why {{research_topic}} research is critical right now]
|
||||
_Technical Importance: [Strategic technical significance with current context]_
|
||||
_Business Impact: [Business implications of technical research]_
|
||||
_Source: [URL]_
|
||||
|
||||
### Technical Research Methodology
|
||||
|
||||
[Comprehensive description of technical research approach including:]
|
||||
|
||||
- **Technical Scope**: [Comprehensive technical coverage areas]
|
||||
- **Data Sources**: [Authoritative technical sources and verification approach]
|
||||
- **Analysis Framework**: [Structured technical analysis methodology]
|
||||
- **Time Period**: [current focus and technical evolution context]
|
||||
- **Technical Depth**: [Level of technical detail and analysis]
|
||||
|
||||
### Technical Research Goals and Objectives
|
||||
|
||||
**Original Technical Goals:** {{research_goals}}
|
||||
|
||||
**Achieved Technical Objectives:**
|
||||
|
||||
- [Technical Goal 1 achievement with supporting evidence]
|
||||
- [Technical Goal 2 achievement with supporting evidence]
|
||||
- [Additional technical insights discovered during research]
|
||||
|
||||
## 2. {{research_topic}} Technical Landscape and Architecture Analysis
|
||||
|
||||
### Current Technical Architecture Patterns
|
||||
|
||||
[Comprehensive architectural analysis synthesized from step-03 with current context]
|
||||
_Dominant Patterns: [Current architectural approaches]_
|
||||
_Architectural Evolution: [Historical and current evolution patterns]_
|
||||
_Architectural Trade-offs: [Key architectural decisions and implications]_
|
||||
_Source: [URL]_
|
||||
|
||||
### System Design Principles and Best Practices
|
||||
|
||||
[Complete system design analysis]
|
||||
_Design Principles: [Core principles guiding {{research_topic}} implementations]_
|
||||
_Best Practice Patterns: [Industry-standard approaches and methodologies]_
|
||||
_Architectural Quality Attributes: [Performance, scalability, maintainability considerations]_
|
||||
_Source: [URL]_
|
||||
|
||||
## 3. Implementation Approaches and Best Practices
|
||||
|
||||
### Current Implementation Methodologies
|
||||
|
||||
[Implementation analysis from step-04 with current context]
|
||||
_Development Approaches: [Current development methodologies and approaches]_
|
||||
_Code Organization Patterns: [Structural patterns and organization strategies]_
|
||||
_Quality Assurance Practices: [Testing, validation, and quality approaches]_
|
||||
_Deployment Strategies: [Current deployment and operations practices]_
|
||||
_Source: [URL]_
|
||||
|
||||
### Implementation Framework and Tooling
|
||||
|
||||
[Comprehensive implementation framework analysis]
|
||||
_Development Frameworks: [Popular frameworks and their characteristics]_
|
||||
_Tool Ecosystem: [Development tools and platform considerations]_
|
||||
_Build and Deployment Systems: [CI/CD and automation approaches]_
|
||||
_Source: [URL]_
|
||||
|
||||
## 4. Technology Stack Evolution and Current Trends
|
||||
|
||||
### Current Technology Stack Landscape
|
||||
|
||||
[Technology stack analysis from step-02 with current updates]
|
||||
_Programming Languages: [Current language trends and adoption patterns]_
|
||||
_Frameworks and Libraries: [Popular frameworks and their use cases]_
|
||||
_Database and Storage Technologies: [Current data storage and management trends]_
|
||||
_API and Communication Technologies: [Integration and communication patterns]_
|
||||
_Source: [URL]_
|
||||
|
||||
### Technology Adoption Patterns
|
||||
|
||||
[Comprehensive technology adoption analysis]
|
||||
_Adoption Trends: [Technology adoption rates and patterns]_
|
||||
_Migration Patterns: [Technology migration and evolution trends]_
|
||||
_Emerging Technologies: [New technologies and their potential impact]_
|
||||
_Source: [URL]_
|
||||
|
||||
## 5. Integration and Interoperability Patterns
|
||||
|
||||
### Current Integration Approaches
|
||||
|
||||
[Integration patterns analysis with current context]
|
||||
_API Design Patterns: [Current API design and implementation patterns]_
|
||||
_Service Integration: [Microservices and service integration approaches]_
|
||||
_Data Integration: [Data exchange and integration patterns]_
|
||||
_Source: [URL]_
|
||||
|
||||
### Interoperability Standards and Protocols
|
||||
|
||||
[Comprehensive interoperability analysis]
|
||||
_Standards Compliance: [Industry standards and compliance requirements]_
|
||||
_Protocol Selection: [Communication protocols and selection criteria]_
|
||||
_Integration Challenges: [Common integration challenges and solutions]_
|
||||
_Source: [URL]_
|
||||
|
||||
## 6. Performance and Scalability Analysis
|
||||
|
||||
### Performance Characteristics and Optimization
|
||||
|
||||
[Performance analysis based on research findings]
|
||||
_Performance Benchmarks: [Current performance characteristics and benchmarks]_
|
||||
_Optimization Strategies: [Performance optimization approaches and techniques]_
|
||||
_Monitoring and Measurement: [Performance monitoring and measurement practices]_
|
||||
_Source: [URL]_
|
||||
|
||||
### Scalability Patterns and Approaches
|
||||
|
||||
[Comprehensive scalability analysis]
|
||||
_Scalability Patterns: [Architectural and design patterns for scalability]_
|
||||
_Capacity Planning: [Capacity planning and resource management approaches]_
|
||||
_Elasticity and Auto-scaling: [Dynamic scaling approaches and implementations]_
|
||||
_Source: [URL]_
|
||||
|
||||
## 7. Security and Compliance Considerations
|
||||
|
||||
### Security Best Practices and Frameworks
|
||||
|
||||
[Security analysis with current context]
|
||||
_Security Frameworks: [Current security frameworks and best practices]_
|
||||
_Threat Landscape: [Current security threats and mitigation approaches]_
|
||||
_Secure Development Practices: [Secure coding and development lifecycle]_
|
||||
_Source: [URL]_
|
||||
|
||||
### Compliance and Regulatory Considerations
|
||||
|
||||
[Comprehensive compliance analysis]
|
||||
_Industry Standards: [Relevant industry standards and compliance requirements]_
|
||||
_Regulatory Compliance: [Legal and regulatory considerations for {{research_topic}}]_
|
||||
_Audit and Governance: [Technical audit and governance practices]_
|
||||
_Source: [URL]_
|
||||
|
||||
## 8. Strategic Technical Recommendations
|
||||
|
||||
### Technical Strategy and Decision Framework
|
||||
|
||||
[Strategic technical recommendations based on comprehensive research]
|
||||
_Architecture Recommendations: [Recommended architectural approaches and patterns]_
|
||||
_Technology Selection: [Recommended technology stack and selection criteria]_
|
||||
_Implementation Strategy: [Recommended implementation approaches and methodologies]_
|
||||
_Source: [URL]_
|
||||
|
||||
### Competitive Technical Advantage
|
||||
|
||||
[Analysis of technical competitive positioning]
|
||||
_Technology Differentiation: [Technical approaches that provide competitive advantage]_
|
||||
_Innovation Opportunities: [Areas for technical innovation and differentiation]_
|
||||
_Strategic Technology Investments: [Recommended technology investments and priorities]_
|
||||
_Source: [URL]_
|
||||
|
||||
## 9. Implementation Roadmap and Risk Assessment
|
||||
|
||||
### Technical Implementation Framework
|
||||
|
||||
[Comprehensive implementation guidance based on research findings]
|
||||
_Implementation Phases: [Recommended phased implementation approach]_
|
||||
_Technology Migration Strategy: [Approach for technology adoption and migration]_
|
||||
_Resource Planning: [Technical resources and capabilities planning]_
|
||||
_Source: [URL]_
|
||||
|
||||
### Technical Risk Management
|
||||
|
||||
[Comprehensive technical risk assessment]
|
||||
_Technical Risks: [Major technical risks and mitigation strategies]_
|
||||
_Implementation Risks: [Risks associated with implementation and deployment]_
|
||||
_Business Impact Risks: [Technical risks and their business implications]_
|
||||
_Source: [URL]_
|
||||
|
||||
## 10. Future Technical Outlook and Innovation Opportunities
|
||||
|
||||
### Emerging Technology Trends
|
||||
|
||||
[Forward-looking technical analysis based on comprehensive research]
|
||||
_Near-term Technical Evolution: [1-2 year technical development expectations]_
|
||||
_Medium-term Technology Trends: [3-5 year expected technical developments]_
|
||||
_Long-term Technical Vision: [5+ year technical outlook for {{research_topic}}]_
|
||||
_Source: [URL]_
|
||||
|
||||
### Innovation and Research Opportunities
|
||||
|
||||
[Technical innovation analysis and recommendations]
|
||||
_Research Opportunities: [Areas for technical research and innovation]_
|
||||
_Emerging Technology Adoption: [Potential new technologies and adoption timelines]_
|
||||
_Innovation Framework: [Approach for fostering technical innovation]_
|
||||
_Source: [URL]_
|
||||
|
||||
## 11. Technical Research Methodology and Source Verification
|
||||
|
||||
### Comprehensive Technical Source Documentation
|
||||
|
||||
[Complete documentation of all technical research sources]
|
||||
_Primary Technical Sources: [Key authoritative technical sources used]_
|
||||
_Secondary Technical Sources: [Supporting technical research and analysis]_
|
||||
_Technical Web Search Queries: [Complete list of technical search queries used]_
|
||||
|
||||
### Technical Research Quality Assurance
|
||||
|
||||
[Technical quality assurance and validation approach]
|
||||
_Technical Source Verification: [All technical claims verified with multiple sources]_
|
||||
_Technical Confidence Levels: [Confidence assessments for uncertain technical data]_
|
||||
_Technical Limitations: [Technical research limitations and areas for further investigation]_
|
||||
_Methodology Transparency: [Complete transparency about technical research approach]_
|
||||
|
||||
## 12. Technical Appendices and Reference Materials
|
||||
|
||||
### Detailed Technical Data Tables
|
||||
|
||||
[Comprehensive technical data tables supporting research findings]
|
||||
_Architectural Pattern Tables: [Detailed architectural pattern comparisons]_
|
||||
_Technology Stack Analysis: [Detailed technology evaluation and comparison data]_
|
||||
_Performance Benchmark Data: [Comprehensive performance measurement data]_
|
||||
|
||||
### Technical Resources and References
|
||||
|
||||
[Valuable technical resources for continued research and implementation]
|
||||
_Technical Standards: [Relevant technical standards and specifications]_
|
||||
_Open Source Projects: [Key open source projects and communities]_
|
||||
_Research Papers and Publications: [Academic and industry research sources]_
|
||||
_Technical Communities: [Professional networks and technical communities]_
|
||||
|
||||
---
|
||||
|
||||
## Technical Research Conclusion
|
||||
|
||||
### Summary of Key Technical Findings
|
||||
|
||||
[Comprehensive summary of the most important technical research findings]
|
||||
|
||||
### Strategic Technical Impact Assessment
|
||||
|
||||
[Assessment of technical implications for {{research_topic}}]
|
||||
|
||||
### Next Steps Technical Recommendations
|
||||
|
||||
[Specific next steps for leveraging this technical research]
|
||||
|
||||
---
|
||||
|
||||
**Technical Research Completion Date:** {{date}}
|
||||
**Research Period:** current comprehensive technical analysis
|
||||
**Document Length:** As needed for comprehensive technical coverage
|
||||
**Source Verification:** All technical facts cited with current sources
|
||||
**Technical Confidence Level:** High - based on multiple authoritative technical sources
|
||||
|
||||
_This comprehensive technical research document serves as an authoritative technical reference on {{research_topic}} and provides strategic technical insights for informed decision-making and implementation._
|
||||
```
|
||||
|
||||
### 5. Present Complete Technical Document and Final Option
|
||||
|
||||
**Technical Document Completion Presentation:**
|
||||
|
||||
"I've completed the **comprehensive technical research document synthesis** for **{{research_topic}}**, producing an authoritative technical research document with:
|
||||
|
||||
**Technical Document Features:**
|
||||
|
||||
- **Compelling Technical Introduction**: Engaging technical opening that establishes research significance
|
||||
- **Comprehensive Technical TOC**: Complete navigation structure for technical reference
|
||||
- **Exhaustive Technical Research Coverage**: All technical aspects of {{research_topic}} thoroughly analyzed
|
||||
- **Executive Technical Summary**: Key technical findings and strategic implications highlighted
|
||||
- **Strategic Technical Recommendations**: Actionable technical insights based on comprehensive research
|
||||
- **Complete Technical Source Citations**: Every technical claim verified with current sources
|
||||
|
||||
**Technical Research Completeness:**
|
||||
|
||||
- Technical landscape and architecture analysis fully documented
|
||||
- Implementation approaches and best practices comprehensively covered
|
||||
- Technology stack evolution and trends detailed
|
||||
- Integration, performance, and security analysis complete
|
||||
- Strategic technical insights and implementation guidance provided
|
||||
|
||||
**Technical Document Standards Met:**
|
||||
|
||||
- Exhaustive technical research with no critical gaps
|
||||
- Professional technical structure and compelling narrative
|
||||
- As long as needed for comprehensive technical coverage
|
||||
- Multiple independent technical sources for all claims
|
||||
- current technical data throughout with proper citations
|
||||
|
||||
**Ready to complete this comprehensive technical research document?**
|
||||
[C] Complete Research - Save final comprehensive technical document
|
||||
|
||||
### 6. Handle Final Technical Completion
|
||||
|
||||
#### If 'C' (Complete Research):
|
||||
|
||||
- **Replace** the template placeholder `[Research overview and methodology will be appended here]` in the `## Research Overview` section near the top of the document with a concise 2-3 paragraph overview summarizing the research scope, key findings, and a pointer to the full executive summary in the Research Synthesis section
|
||||
- Append the complete technical document to the research file
|
||||
- Update frontmatter: `stepsCompleted: [1, 2, 3, 4, 5, 6]`
|
||||
- Complete the technical research workflow
|
||||
- Provide final technical document delivery confirmation
|
||||
|
||||
## APPEND TO DOCUMENT:
|
||||
|
||||
When user selects 'C', append the complete comprehensive technical research document using the full structure above. Also replace the `[Research overview and methodology will be appended here]` placeholder in the Research Overview section at the top of the document.
|
||||
|
||||
## SUCCESS METRICS:
|
||||
|
||||
✅ Compelling technical introduction with research significance
|
||||
✅ Comprehensive technical table of contents with complete document structure
|
||||
✅ Exhaustive technical research coverage across all technical aspects
|
||||
✅ Executive technical summary with key findings and strategic implications
|
||||
✅ Strategic technical recommendations grounded in comprehensive research
|
||||
✅ Complete technical source verification with current citations
|
||||
✅ Professional technical document structure and compelling narrative
|
||||
✅ [C] complete option presented and handled correctly
|
||||
✅ Technical research workflow completed with comprehensive document
|
||||
|
||||
## FAILURE MODES:
|
||||
|
||||
❌ Not producing compelling technical introduction
|
||||
❌ Missing comprehensive technical table of contents
|
||||
❌ Incomplete technical research coverage across technical aspects
|
||||
❌ Not providing executive technical summary with key findings
|
||||
❌ Missing strategic technical recommendations based on research
|
||||
❌ Relying solely on training data without web verification for current facts
|
||||
❌ Producing technical document without professional structure
|
||||
❌ Not presenting completion option for final technical document
|
||||
|
||||
❌ **CRITICAL**: Reading only partial step file - leads to incomplete understanding and poor decisions
|
||||
❌ **CRITICAL**: Proceeding with 'C' without fully reading and understanding the next step file
|
||||
❌ **CRITICAL**: Making decisions without complete understanding of step requirements and protocols
|
||||
|
||||
## COMPREHENSIVE TECHNICAL DOCUMENT STANDARDS:
|
||||
|
||||
This step ensures the final technical research document:
|
||||
|
||||
- Serves as an authoritative technical reference on {{research_topic}}
|
||||
- Provides strategic technical insights for informed decision-making
|
||||
- Includes comprehensive technical coverage with no gaps
|
||||
- Maintains rigorous technical source verification standards
|
||||
- Delivers strategic technical insights and actionable recommendations
|
||||
- Meets professional technical research document quality standards
|
||||
|
||||
## TECHNICAL RESEARCH WORKFLOW COMPLETION:
|
||||
|
||||
When 'C' is selected:
|
||||
|
||||
- All technical research steps completed (1-5)
|
||||
- Comprehensive technical research document generated
|
||||
- Professional technical document structure with intro, TOC, and summary
|
||||
- All technical sections appended with source citations
|
||||
- Technical research workflow status updated to complete
|
||||
- Final comprehensive technical research document delivered to user
|
||||
|
||||
## FINAL TECHNICAL DELIVERABLE:
|
||||
|
||||
Complete authoritative technical research document on {{research_topic}} that:
|
||||
|
||||
- Establishes technical credibility through comprehensive research
|
||||
- Provides strategic technical insights for informed decision-making
|
||||
- Serves as technical reference document for continued use
|
||||
- Maintains highest technical research quality standards with current verification
|
||||
|
||||
## On Complete
|
||||
|
||||
Run: `python3 {project-root}/_bmad/scripts/resolve_customization.py --skill {skill-root} --key workflow.on_complete`
|
||||
|
||||
If the resolved `workflow.on_complete` is non-empty, follow it as the final terminal instruction before exiting.
|
||||
|
||||
Congratulations on completing comprehensive technical research with professional documentation! 🎉
|
||||
@@ -11,9 +11,6 @@ BMad Method,bmad-agent-tech-writer,Mermaid Generate,MG,Create a Mermaid diagram
|
||||
BMad Method,bmad-agent-tech-writer,Validate Document,VD,Review the specified document against documentation standards and best practices. Returns specific actionable improvement suggestions organized by priority.,validate,[path],anytime,,,false,planning_artifacts,validation report
|
||||
BMad Method,bmad-agent-tech-writer,Explain Concept,EC,Create clear technical explanations with examples and diagrams for complex concepts.,explain,[topic],anytime,,,false,project_knowledge,explanation
|
||||
BMad Method,bmad-brainstorming,Brainstorm Project,BP,Expert guided facilitation through a single or multiple techniques.,,,1-analysis,,,false,{output_folder}/brainstorming,brainstorming session
|
||||
BMad Method,bmad-market-research,Market Research,MR,Market analysis competitive landscape customer needs and trends.,,,1-analysis,,,false,planning_artifacts|project-knowledge,research documents
|
||||
BMad Method,bmad-domain-research,Domain Research,DR,Industry domain deep dive subject matter expertise and terminology.,,,1-analysis,,,false,planning_artifacts|project_knowledge,research documents
|
||||
BMad Method,bmad-technical-research,Technical Research,TR,Technical feasibility architecture options and implementation approaches.,,,1-analysis,,,false,planning_artifacts|project_knowledge,research documents
|
||||
BMad Method,bmad-product-brief,Create Brief,CB,An expert guided experience to nail down your product idea in a brief. a gentler approach than PRFAQ when you are already sure of your concept and nothing will sway you.,,-A,1-analysis,,,false,planning_artifacts,product brief
|
||||
BMad Method,bmad-prfaq,PRFAQ Challenge,WB,Working Backwards guided experience to forge and stress-test your product concept to ensure you have a great product that users will love and need through the PRFAQ gauntlet to determine feasibility and alignment with user needs. alternative to product brief.,,-H,1-analysis,,,false,planning_artifacts,prfaq document
|
||||
BMad Method,bmad-prd,Create Edit and Review PRD,PRD,"Facilitated PRD workflow — create a new PRD via coached discovery, update an existing one against a change signal, or validate a finished PRD against a checklist with an HTML findings report.",,,2-planning,bmad-product-brief,,true,planning_artifacts,prd
|
||||
|
||||
|
@@ -5,12 +5,15 @@ Each one holds no logic of its own — it forwards to the skill that replaced it
|
||||
stated intent and pre-resolved customization fields so the target skips its own intent
|
||||
inference.
|
||||
|
||||
| Shim | Forwards to |
|
||||
| -------------------------- | ----------------------------------- |
|
||||
| `bmad-create-prd` | `bmad-prd` (create intent) |
|
||||
| `bmad-edit-prd` | `bmad-prd` (update intent) |
|
||||
| `bmad-validate-prd` | `bmad-prd` (validate intent) |
|
||||
| `bmad-create-architecture` | `bmad-architecture` (create intent) |
|
||||
| Shim | Forwards to |
|
||||
| -------------------------- | ------------------------------------ |
|
||||
| `bmad-create-prd` | `bmad-prd` (create intent) |
|
||||
| `bmad-edit-prd` | `bmad-prd` (update intent) |
|
||||
| `bmad-validate-prd` | `bmad-prd` (validate intent) |
|
||||
| `bmad-create-architecture` | `bmad-architecture` (create intent) |
|
||||
| `bmad-market-research` | `bmad-deep-recon` (market type) |
|
||||
| `bmad-domain-research` | `bmad-deep-recon` (domain type) |
|
||||
| `bmad-technical-research` | `bmad-deep-recon` (technical type) |
|
||||
|
||||
Enterprise users may still depend on these IDs, so they ship by default. Removal rides the
|
||||
v7 cut — never a 6.x minor.
|
||||
|
||||
@@ -0,0 +1,14 @@
|
||||
---
|
||||
name: bmad-domain-research
|
||||
description: 'Deprecated — forwards to bmad-deep-recon (domain type).'
|
||||
---
|
||||
|
||||
# DEPRECATED — forwards to bmad-deep-recon (domain type)
|
||||
|
||||
This skill was consolidated into `bmad-deep-recon`. It is retained as a thin compatibility shim so existing invocations by name and `_bmad/custom/bmad-domain-research.toml` override files keep working. New work should invoke `bmad-deep-recon` directly — it drafts deep-research prompts for outside tools, processes finished reports into downstream-ready summaries, and runs research directly, across market, domain, technical, competitive, user-voice, and academic-lit types (plus a select shape for choose-between decisions and custom types).
|
||||
|
||||
## On Activation
|
||||
|
||||
1. Resolve customization: `uv run {project-root}/_bmad/scripts/resolve_customization.py --skill {skill-root} --key workflow`. This picks up any `{project-root}/_bmad/custom/bmad-domain-research.toml` and `bmad-domain-research.user.toml` overrides for the legacy fields (`activation_steps_prepend`, `activation_steps_append`, `persistent_facts`, `on_complete`).
|
||||
2. Emit a deprecation notice to the user (in their configured communication language): `bmad-domain-research` is deprecated and forwards to `bmad-deep-recon` with the domain type. To silence this notice and access the full new surface (draft/process/run modes, research types, verification levels, HTML briefing, handoffs), migrate `_bmad/custom/bmad-domain-research.toml` to `_bmad/custom/bmad-deep-recon.toml` and invoke `bmad-deep-recon` directly.
|
||||
3. Invoke `bmad-deep-recon` with: **research type** `domain` (skip its type inference), the four legacy fields above as pre-resolved values, and the user's original input verbatim. `bmad-deep-recon` takes the workflow from here — do not execute any further steps in this shim.
|
||||
@@ -0,0 +1,14 @@
|
||||
---
|
||||
name: bmad-market-research
|
||||
description: 'Deprecated — forwards to bmad-deep-recon (market type).'
|
||||
---
|
||||
|
||||
# DEPRECATED — forwards to bmad-deep-recon (market type)
|
||||
|
||||
This skill was consolidated into `bmad-deep-recon`. It is retained as a thin compatibility shim so existing invocations by name and `_bmad/custom/bmad-market-research.toml` override files keep working. New work should invoke `bmad-deep-recon` directly — it drafts deep-research prompts for outside tools, processes finished reports into downstream-ready summaries, and runs research directly, across market, domain, technical, competitive, user-voice, and academic-lit types (plus a select shape for choose-between decisions and custom types).
|
||||
|
||||
## On Activation
|
||||
|
||||
1. Resolve customization: `uv run {project-root}/_bmad/scripts/resolve_customization.py --skill {skill-root} --key workflow`. This picks up any `{project-root}/_bmad/custom/bmad-market-research.toml` and `bmad-market-research.user.toml` overrides for the legacy fields (`activation_steps_prepend`, `activation_steps_append`, `persistent_facts`, `on_complete`).
|
||||
2. Emit a deprecation notice to the user (in their configured communication language): `bmad-market-research` is deprecated and forwards to `bmad-deep-recon` with the market type. To silence this notice and access the full new surface (draft/process/run modes, research types, verification levels, HTML briefing, handoffs), migrate `_bmad/custom/bmad-market-research.toml` to `_bmad/custom/bmad-deep-recon.toml` and invoke `bmad-deep-recon` directly.
|
||||
3. Invoke `bmad-deep-recon` with: **research type** `market` (skip its type inference), the four legacy fields above as pre-resolved values, and the user's original input verbatim. `bmad-deep-recon` takes the workflow from here — do not execute any further steps in this shim.
|
||||
@@ -0,0 +1,14 @@
|
||||
---
|
||||
name: bmad-technical-research
|
||||
description: 'Deprecated — forwards to bmad-deep-recon (technical type).'
|
||||
---
|
||||
|
||||
# DEPRECATED — forwards to bmad-deep-recon (technical type)
|
||||
|
||||
This skill was consolidated into `bmad-deep-recon`. It is retained as a thin compatibility shim so existing invocations by name and `_bmad/custom/bmad-technical-research.toml` override files keep working. New work should invoke `bmad-deep-recon` directly — it drafts deep-research prompts for outside tools, processes finished reports into downstream-ready summaries, and runs research directly, across market, domain, technical, competitive, user-voice, and academic-lit types (plus a select shape for choose-between decisions and custom types).
|
||||
|
||||
## On Activation
|
||||
|
||||
1. Resolve customization: `uv run {project-root}/_bmad/scripts/resolve_customization.py --skill {skill-root} --key workflow`. This picks up any `{project-root}/_bmad/custom/bmad-technical-research.toml` and `bmad-technical-research.user.toml` overrides for the legacy fields (`activation_steps_prepend`, `activation_steps_append`, `persistent_facts`, `on_complete`).
|
||||
2. Emit a deprecation notice to the user (in their configured communication language): `bmad-technical-research` is deprecated and forwards to `bmad-deep-recon` with the technical type. To silence this notice and access the full new surface (draft/process/run modes, research types, verification levels, HTML briefing, handoffs), migrate `_bmad/custom/bmad-technical-research.toml` to `_bmad/custom/bmad-deep-recon.toml` and invoke `bmad-deep-recon` directly.
|
||||
3. Invoke `bmad-deep-recon` with: **research type** `technical` (skip its type inference), the four legacy fields above as pre-resolved values, and the user's original input verbatim. `bmad-deep-recon` takes the workflow from here — do not execute any further steps in this shim.
|
||||
@@ -0,0 +1,82 @@
|
||||
---
|
||||
name: bmad-deep-recon
|
||||
description: 'Decision-grade research, three ways: draft a deep-research prompt for the user to run in their own tool (ChatGPT, Gemini, Grok, Perplexity, …), process a finished research report — file it, distill a succinct cited summary with metadata that downstream skills consume without reprocessing — or run the research here through web fan-out. Shipped type packs: market, domain, technical, competitive, user-voice, academic-lit — plus a select shape for choose-between decisions and custom types via overrides. Use when the user says "deep recon", "research this", "draft a research prompt", "process this research report", "market research", "domain research", "technical research", "competitor research", "literature review", or "help me choose between".'
|
||||
---
|
||||
|
||||
# BMad Deep Recon
|
||||
|
||||
## Overview
|
||||
|
||||
You are **Deep Recon** — a research director, not a search engine. Your value is framing research worth running and turning whatever comes back into a decision-grade artifact this project consumes without reprocessing. Every engagement serves a **decision** — enter a market, pick a stack, scope a product, commit to a domain — and is shaped by it from the first question to the final artifact.
|
||||
|
||||
Three services, freely combined — each detailed in its reference: **Draft** a deep-research prompt the user runs in their own tool, **Process** a finished report into the succinct cited summary downstream skills read, or **Run** the research here through parallel web fan-out. Draft → run externally → Process is the natural loop; Run is fully capable on its own.
|
||||
|
||||
**Epistemics — two standing rules, inherited verbatim by every subagent you spawn:**
|
||||
|
||||
1. **Never conclude from training data alone.** What you already know proposes hypotheses, queries, and structure; conclusions require evidence retrieved or imported *this run*. A claim you cannot evidence is stated as an unverified belief or not at all.
|
||||
2. **The research firewall.** Project context — briefs, PRDs, code, memory, `{workflow.persistent_facts}` — shapes *what to ask*, never *what is true*. It is inadmissible as evidence: every claim in a research artifact traces to a digest or import file with a source. Research subagents receive only their brief — no project files, no ambient context — unless the plan explicitly grants a named document.
|
||||
|
||||
## How you work
|
||||
|
||||
- **Nothing exists until it is a file.** Every digest, import extraction, and report section is written to the run folder the moment it lands — the conversation is a control channel, never the store. A run that dies mid-flight resumes from disk with nothing lost.
|
||||
- **Extract, don't ingest.** Raw reports and search results never enter the parent context whole; subagents return relevance-filtered digests, and the parent reads digest files JIT.
|
||||
- **A claim is a sentence with a source.** Publisher, publication date, access date. No naked numbers.
|
||||
- **Report what is real.** Thin public data is reported as thin, absence of evidence is a finding, and freshness is part of truth — each pack sets windows per claim class; a market size from three years ago is history, not fact.
|
||||
- **Fast by default.** Rigor is bought consciously through the knobs, never accreted through extra passes. One gate, light checkpoints, no ceremony.
|
||||
- **The memlog is the process memory.** Every decision, source batch, load-bearing claim, plan change, and assumption is one append-only line, always through the script: `uv run {project-root}/_bmad/scripts/memlog.py` with `--type <decision|source|claim|assumption|question|event>`.
|
||||
- Web access is required for Run. If unavailable, say so and offer Draft/Process — never fabricate research.
|
||||
|
||||
## Resolution rules
|
||||
|
||||
- Bare paths and `{skill-root}` (e.g. `references/run.md`) resolve from this skill's installed directory.
|
||||
- `{project-root}` → the project working directory; `{skill-name}` → the skill directory's basename.
|
||||
- `{workflow.<name>}` → a merged `customize.toml` field; `{doc_workspace}` → the bound run folder.
|
||||
- Forward slashes only. Config variables already contain `{project-root}` in their resolved values — never double-prefix.
|
||||
|
||||
## On Activation
|
||||
|
||||
**Forwarded activation:** if a caller invoked you with a stated intent, research type, or pre-resolved customization fields (the legacy research shims and Mary's menu do), honor them verbatim — skip your own inference for those values and resolve only the rest.
|
||||
|
||||
1. Resolve customization: `uv run {project-root}/_bmad/scripts/resolve_customization.py --skill {skill-root} --key workflow` (on failure read `{skill-root}/customize.toml`, use defaults). Run `{workflow.activation_steps_prepend}`, then `{workflow.activation_steps_append}`.
|
||||
2. Resolve config: `uv run {project-root}/_bmad/scripts/resolve_config.py --project-root {project-root}`. From the merged JSON resolve `{user_name}`, `{communication_language}`, `{document_output_language}`, `{project_name}`, `{output_folder}` (under `core`), `{planning_artifacts}` (under `modules.bmm`; absent on core-only installs → `{output_folder}`), and `{date}`; missing keys take neutral defaults, never block.
|
||||
3. Headless (no interactive user) → see `## Headless Mode`. Otherwise greet `{user_name}` in `{communication_language}` — and stay in it every turn.
|
||||
4. Detect the intent: **draft**, **process** (the user has or names a report), **run**, or lifecycle **refresh** / **deepen** on an existing run folder. When the ask is bare research with no verb ("research X for me"), open the floor first — invite the decision they're facing and anything they already have (briefs, links, a prior report) in one turn, then ask only what's missing — and put the choice up front, once: **Run** it here now, or **Draft** a prompt for a deep-research tool they subscribe to — often cheaper and a strong gatherer, with Process turning its output into the same artifact. State the trade honestly (tokens and minutes here vs. one manual round-trip there); their call, remembered for the session.
|
||||
5. If a run folder for this topic already exists under `{workflow.research_output_path}`, offer to resume or extend it (a drafted brief awaiting its report, a report awaiting refresh) rather than start a duplicate.
|
||||
|
||||
## Research types and decision shapes
|
||||
|
||||
The type set is whatever `{workflow.research_types}` resolves to — shipped: `market`, `domain`, `technical`, `competitive`, `user-voice`, `academic-lit` — each pointing at a pack file. You already know how to research; the pack is where this harness is opinionated — prioritized dimensions, non-obvious source craft, freshness bars and two-source classes per claim class, downstream bindings. Apply it in every mode; don't re-derive it. Overrides replace matching codes and append new ones; never claim a fixed type list — read the resolved set.
|
||||
|
||||
Infer the type from the user's ask and each entry's `when` clause; confirm only when genuinely ambiguous. An explicit type (argument, shim, menu) wins without discussion.
|
||||
|
||||
Orthogonal to type is the **decision shape**: **explore** (the default — understand, assess, validate) or **select** (choose between candidates). When the shape is select, load `references/selection.md` and layer its method over the type's pack — it shapes drafted prompts and processed summaries as much as native runs.
|
||||
|
||||
## Intents
|
||||
|
||||
Route on the detected intent and load only what it names. Every intent shares the run-folder workspace shape — `brief.md`, `imports/`, `digests/`, `research.md`, `.memlog.md` — and ends per `references/finalize.md`.
|
||||
|
||||
| Intent | What it does | Load |
|
||||
| --- | --- | --- |
|
||||
| Draft | Compose a deep-research prompt for the user's own tool, carrying the pack's craft | `references/draft.md` |
|
||||
| Process | File a finished report, extract its claims, distill the downstream summary | `references/process.md` |
|
||||
| Run | Native research: resolve effort, hold the plan gate — the one hard stop — then run the loop | `references/run.md`, then `references/verification.md` + `references/synthesis.md` |
|
||||
| Refresh / Deepen | Update or extend an existing run folder | `references/lifecycle.md` |
|
||||
|
||||
## Headless Mode
|
||||
|
||||
When invoked headless, do not ask. Bare research defaults to **run**; a named report means **process**; a requested prompt means **draft** (the brief file is the deliverable). Plan-and-proceed: infer type, build from the pack, keep configured knobs plus anything in the invocation (red team and workflow orchestration only when set `"on"`), skip checkpoints, log every judgment call as an `assumption`. Halt `blocked` only when topic or target folder cannot be inferred. End with JSON:
|
||||
|
||||
```json
|
||||
{
|
||||
"status": "complete",
|
||||
"intent": "run",
|
||||
"type": "market",
|
||||
"report": "{doc_workspace}/research.md",
|
||||
"memlog": "{doc_workspace}/.memlog.md",
|
||||
"claims": {"verified": 12, "unverified": 3, "overturned": 0},
|
||||
"open_questions": [],
|
||||
"external_handoffs": []
|
||||
}
|
||||
```
|
||||
|
||||
Omit keys for artifacts not produced; the `claims` counts come from `uv run scripts/recon_kit.py tally {doc_workspace}/.memlog.md`, never hand-counted. Draft adds `"brief"`; process adds `"imports"`; refresh replaces `claims` scope with the refresh set plus a `deltas` array. With `output_format = "auto"`, headless runs produce no briefing; add `"briefing"` when rendered.
|
||||
@@ -0,0 +1,18 @@
|
||||
---
|
||||
title: '{research_type} research: {research_topic}'
|
||||
type: '{research_type}'
|
||||
topic: '{research_topic}'
|
||||
decision: '{decision}'
|
||||
source: '{source}'
|
||||
status: draft
|
||||
preset: '{preset}'
|
||||
validation: '{validation}'
|
||||
created: '{date}'
|
||||
updated: '{date}'
|
||||
---
|
||||
|
||||
# {research_type} research: {research_topic}
|
||||
|
||||
**Decision this research serves:** {decision}
|
||||
|
||||
_Sections are appended per the approved research plan; the executive summary is written last and placed here, first._
|
||||
@@ -0,0 +1,212 @@
|
||||
# DO NOT EDIT -- overwritten on every update.
|
||||
#
|
||||
# Workflow customization surface for bmad-deep-recon.
|
||||
#
|
||||
# Override files (not edited here):
|
||||
# {project-root}/_bmad/custom/bmad-deep-recon.toml (team)
|
||||
# {project-root}/_bmad/custom/bmad-deep-recon.user.toml (personal)
|
||||
|
||||
[workflow]
|
||||
|
||||
# --- Configurable below. Overrides merge per BMad structural rules: ---
|
||||
# scalars: override wins
|
||||
# arrays (persistent_facts, activation_steps_*, *_sources, doc_standards,
|
||||
# external_*): append
|
||||
# arrays of tables keyed by `code`: matching key replaces, new keys append
|
||||
|
||||
# Steps executed on activation: prepend runs before the skill's own
|
||||
# activation flow, append runs after it. Each entry is a literal instruction.
|
||||
activation_steps_prepend = []
|
||||
activation_steps_append = []
|
||||
|
||||
# Standing context for framing the research — decision context only, never
|
||||
# evidence: the research firewall keeps project material out of findings.
|
||||
# Entries prefixed `file:` are paths or globs whose contents load as facts;
|
||||
# all others are literal facts. Empty by default so nothing local leaks into
|
||||
# research framing unasked.
|
||||
persistent_facts = []
|
||||
|
||||
# Where research runs live and how each run folder is named. Draft, Process,
|
||||
# and Run all use the same folder shape: brief.md (drafted prompts),
|
||||
# imports/ (originals, full fidelity), digests/ (extracted claims),
|
||||
# research.md (the canonical summary/report), .memlog.md.
|
||||
research_output_path = "{planning_artifacts}/research"
|
||||
run_folder_pattern = "{research_type}-{topic_slug}-{date}"
|
||||
|
||||
# Seed document for a new run.
|
||||
research_template = "assets/research.template.md"
|
||||
|
||||
# --- Effort (Run mode) ------------------------------------------------------
|
||||
# A preset bundles the three effort knobs; any knob set here individually
|
||||
# pins that knob over the preset. What the user says in the request beats
|
||||
# both.
|
||||
#
|
||||
# preset subagents sources/round depth
|
||||
# quick low (2) 5 1
|
||||
# standard normal (3) 8 2
|
||||
# deep high (6) 12 3
|
||||
#
|
||||
# Grounding: orchestrator-worker research systems document 3-5 parallel
|
||||
# workers as the sweet spot (more only for genuinely wide work). Depth and
|
||||
# sources are caps, not quotas — dimensions stop early on coverage or
|
||||
# novelty exhaustion. Defaults are tuned for a fast run; buy more rigor
|
||||
# consciously, per run, in the request.
|
||||
|
||||
preset = "standard"
|
||||
|
||||
# "" = from preset. Values: none | low | normal | high
|
||||
# (0 / 2 / 3 / 6 parallel research assistants, ceiling 10; none also =
|
||||
# no-subagent environments, run inline sequentially).
|
||||
subagents = ""
|
||||
|
||||
# 0 = from preset. Distinct sources actually read per dimension per round.
|
||||
# Ceiling 25 — beyond that a single round exceeds what hosted deep-research
|
||||
# products spend on an entire run.
|
||||
max_sources_per_round = 0
|
||||
|
||||
# 0 = from preset. Rounds per dimension: initial pass + lead-following
|
||||
# follow-ups. Ceiling 5.
|
||||
max_depth = 0
|
||||
|
||||
# Verification level, applied as material lands (never an end-of-run pass).
|
||||
# normal spot-check load-bearing claims only — fast, the default
|
||||
# high cross-check the pack's two-source classes; red-team major
|
||||
# conclusions
|
||||
# max cross-check every ledger claim + the red-team pass at full
|
||||
# breadth + primary-source-priority ranking
|
||||
validation = "normal"
|
||||
|
||||
# Red-team stance pass — fresh-context skeptics hunting disconfirming
|
||||
# evidence for major conclusions: "off" (default), "offer" (proposed at the
|
||||
# plan gate), or "on" (always; headless honors only "on"). high/max
|
||||
# validation includes it for major conclusions regardless.
|
||||
red_team = "off"
|
||||
|
||||
# Run the acquisition fan-out through the harness's deterministic
|
||||
# orchestration when it offers one (e.g. workflows): "off", "offer"
|
||||
# (proposed at the plan gate when available), or "on". Orchestrated runs are
|
||||
# faster wall-clock but spend more tokens.
|
||||
use_workflows = "offer"
|
||||
|
||||
# Ordered model preference for spawned research assistants — first model the
|
||||
# harness can provide wins; [] lets the harness/skill choose (lead stays on
|
||||
# the strongest model; researchers at most one capable tier down; judgment
|
||||
# work never on the smallest tier; mechanical extraction may use a fast
|
||||
# tier).
|
||||
#
|
||||
# Example: subagent_models = ["<your-mid-tier-model-id>", "<your-fast-model-id>"]
|
||||
subagent_models = []
|
||||
|
||||
# Source policy. Preferred sources are consulted first and weighted as more
|
||||
# credible; banned sources are never cited (their claims may still be leads
|
||||
# to verify elsewhere). Entries are domains or plain-text descriptions.
|
||||
# Draft mode writes both policies into drafted prompts.
|
||||
preferred_sources = []
|
||||
banned_sources = []
|
||||
|
||||
# What is presented and handed off — never what exists: research.md (the
|
||||
# canonical machine-readable summary/report) always lives in the workspace.
|
||||
# "auto" html briefing on interactive runs; md only on headless or
|
||||
# skill-invoked runs (the caller reads the md; render later at will)
|
||||
# "html" always render the briefing page (references/html-briefing.md)
|
||||
# "md" never render html
|
||||
# "both" render and present both
|
||||
output_format = "auto"
|
||||
|
||||
# Theme for the HTML briefing: empty = the shipped neutral professional
|
||||
# theme, a `file:` path to a theme/brand spec, or inline directives
|
||||
# (e.g. "Canvas #122543, accent #B66D46, sans-serif, dark-mode aware").
|
||||
html_theme = ""
|
||||
|
||||
# Default audience shaping for the synthesis — freeform, empty = balanced
|
||||
# technical/business register. Examples: "executive one-pager first, detail
|
||||
# after", "engineering team, keep vendor marketing out".
|
||||
audience = ""
|
||||
|
||||
# Registry of extra research surfaces — internal knowledge bases or search
|
||||
# tools you subscribe to — consulted alongside web research in Run mode; each
|
||||
# entry names the tool and when to use it. Installed search-shaped MCP tools
|
||||
# are discovered automatically at the plan gate; an entry here adds routing
|
||||
# guidance the discovery can't infer.
|
||||
#
|
||||
# Examples:
|
||||
# external_sources = [
|
||||
# "Tavily MCP (tavily_search/tavily_extract): preferred web search + clean page extraction",
|
||||
# "Perplexity Sonar MCP (perplexity_ask): cited synthesized answers — chase its citations as the sources",
|
||||
# "xAI X Search MCP: live X/Twitter posts and threads, for user-voice and sentiment dimensions",
|
||||
# "Gartner MCP (corp:gartner_query): analyst data on enterprise software markets",
|
||||
# ]
|
||||
external_sources = []
|
||||
|
||||
# Polish passes applied to research.md at finalize. Entries are `skill:NAME`
|
||||
# directives, `file:` style guides, or plain-text instructions.
|
||||
doc_standards = ["skill:bmad-review lenses=structure,prose"]
|
||||
|
||||
# Handoffs executed at finalize to route the report beyond local files. Each
|
||||
# entry names the tool and what to do; unavailable tools are skipped and
|
||||
# flagged.
|
||||
#
|
||||
# Examples:
|
||||
# "NotebookLM (notebooklm-mcp): create a notebook from research.md plus the top sources, generate an audio overview, return the notebook URL"
|
||||
# "Confluence (corp:confluence_upload): publish research.md to the RESEARCH space, return the page URL"
|
||||
external_handoffs = []
|
||||
|
||||
# Executed after finalize. A string scalar is one instruction; an array is a
|
||||
# sequence. Empty = the run ends with the finalize summary.
|
||||
on_complete = ""
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
# Research types — subject lenses. Each type is a pack: a policy and craft
|
||||
# card (prioritized dimensions, non-obvious source craft, freshness bars,
|
||||
# two-source classes, downstream bindings) used by all three modes — it
|
||||
# shapes drafted prompts, native runs, and processed-report gap checks
|
||||
# alike. `when` guides type inference from the user's ask; an explicitly
|
||||
# requested type always wins. The decision shape (explore vs select) is
|
||||
# orthogonal — any type can end in a selection matrix.
|
||||
#
|
||||
# Keyed by `code`: an override with a matching code replaces the shipped
|
||||
# type, a new code appends. Empty `pack` disables a type.
|
||||
#
|
||||
# Example (add an org-specific type in team/user override TOML):
|
||||
# [[workflow.research_types]]
|
||||
# code = "regulatory"
|
||||
# name = "Regulatory Research"
|
||||
# when = "Compliance posture, licensing, or regulatory exposure for a product or market."
|
||||
# pack = "file:{project-root}/_bmad/custom/packs/regulatory.md"
|
||||
# ---------------------------------------------------------------------------
|
||||
|
||||
[[workflow.research_types]]
|
||||
code = "market"
|
||||
name = "Market Research"
|
||||
when = "Market opportunity, customers, competition, sizing, or go-to-market for a product or business decision."
|
||||
pack = "types/market.md"
|
||||
|
||||
[[workflow.research_types]]
|
||||
code = "domain"
|
||||
name = "Domain Research"
|
||||
when = "Understanding an industry, sector, or field: structure, players, rules, vocabulary, dynamics."
|
||||
pack = "types/domain.md"
|
||||
|
||||
[[workflow.research_types]]
|
||||
code = "technical"
|
||||
name = "Technical Research"
|
||||
when = "A technology area's landscape, patterns, integration approaches, and implementation reality."
|
||||
pack = "types/technical.md"
|
||||
|
||||
[[workflow.research_types]]
|
||||
code = "competitive"
|
||||
name = "Competitive Research"
|
||||
when = "Teardown of specific named competitors: offers, pricing, positioning, trajectory, their customers' sentiment."
|
||||
pack = "types/competitive.md"
|
||||
|
||||
[[workflow.research_types]]
|
||||
code = "user-voice"
|
||||
name = "User-Voice Research"
|
||||
when = "What users of a product or category actually experience and want: reviews, communities, jobs-to-be-done."
|
||||
pack = "types/user-voice.md"
|
||||
|
||||
[[workflow.research_types]]
|
||||
code = "academic-lit"
|
||||
name = "Academic Literature"
|
||||
when = "Published research: literature review, state of the art, grounding an approach in papers."
|
||||
pack = "types/academic-lit.md"
|
||||
@@ -0,0 +1,8 @@
|
||||
# Draft
|
||||
|
||||
Build a deep-research prompt the user runs themselves — in conversation, fast, not a project. The pack's craft travels inside the prompt so the outside tool works to this harness's standard.
|
||||
|
||||
1. Open the floor before any structured questions: invite the decision they're facing and anything they already have — briefs, links, a prior report, half-formed constraints — in one turn, then ask only what's still missing. Nail the **decision**, topic, and type; load the pack. Ask which tool the prompt is for (it changes phrasing: hosted deep-research agents handle wide scopes and long source lists; social-native tools like Grok earn user-voice and sentiment dimensions; if unknown, write tool-neutral).
|
||||
2. Compose the prompt from the pack: the dimensions as explicit research questions pruned to the decision, the freshness bars as recency requirements, the two-source expectation for its critical claim classes, the audience, the source policy — `{workflow.preferred_sources}` named as sources to prefer, `{workflow.banned_sources}` as sources never to cite — and a **non-negotiable citation demand**: every claim with source URL and publication date, contrary evidence reported, gaps admitted rather than padded. Structure the requested output so Process can extract it cleanly (findings per dimension, a source list).
|
||||
3. Bind `{doc_workspace}`: expand the folder name deterministically (`uv run scripts/recon_kit.py slug "<topic>" --type <type> --pattern "{workflow.run_folder_pattern}"` — same expansion every mode, so the report comes back to the same folder) under `{workflow.research_output_path}`, init the memlog with the decision context, save the prompt as `{doc_workspace}/brief.md`, and present it paste-ready in chat.
|
||||
4. Close the loop: tell the user to run it in their tool and bring the report back — "process it" from here picks up this folder, decision context intact.
|
||||
@@ -0,0 +1,11 @@
|
||||
# Finalize
|
||||
|
||||
Every mode ends here once `research.md` is assembled.
|
||||
|
||||
1. `research.md` is complete per `references/synthesis.md`: decision-first summary, findings, contrary evidence where found, recommendations with downstream bindings, source appendix, staleness map. Frontmatter metadata (`type`, `topic`, `decision`, `source`, `status`, dates) is what lets every downstream consumer trust it without reprocessing.
|
||||
2. **Citation check — mechanical, then semantic.** Run `uv run scripts/recon_kit.py citations {doc_workspace}/research.md` — it diffs inline `[n]` markers against the appendix and lists dangling markers and orphaned rows exactly; fix what it reports. Then a fresh-context subagent does only the judgment half: does each cited source actually say what the text claims? It never rewrites findings — a claim whose source doesn't back it gets its confidence downgraded and the mismatch logged as an `event`.
|
||||
3. Render per `{workflow.output_format}` (see `references/html-briefing.md`): `auto` renders the briefing page on interactive runs, skips on headless/skill-invoked; `html`/`both` always; `md` never. `research.md` always exists — the briefing is its regenerable face.
|
||||
4. Polish: apply each `{workflow.doc_standards}` entry (a `skill:`, `file:`, or plain-text directive) to `research.md`.
|
||||
5. Execute each `{workflow.external_handoffs}` entry (NotebookLM, Confluence, …) — invoke the named tool, surface returned URLs; skip and flag unavailable tools.
|
||||
6. Tell the user what exists and where — report, briefing, imports, memlog — plus what the staleness map says to re-check and when, and that Refresh/Deepen handle it. Invoke `bmad-help` to suggest the next step.
|
||||
7. Run `{workflow.on_complete}` if non-empty — a string is one instruction, an array is a sequence.
|
||||
@@ -0,0 +1,16 @@
|
||||
# HTML Briefing
|
||||
|
||||
Generate `research-briefing.html` in `{doc_workspace}` after `research.md` is final, when `{workflow.output_format}` calls for it: `"auto"` renders on interactive runs and skips on headless/skill-invoked runs (the md is always there to render from later), `"html"`/`"both"` always render, `"md"` never. The page is a full-fidelity presentation of the report, never a second source of truth — same claims, same numbers, same citations; nothing is lost by reading it instead of the markdown.
|
||||
|
||||
## Requirements
|
||||
|
||||
- **Self-contained single file**: inline CSS and JS, no external requests of any kind (no CDN, no fonts, no remote images). It must render from a `file://` open, offline, forever.
|
||||
- **Structure**: a header (topic, type, decision, date, depth, verification level) → the executive summary as the opening card → sticky table of contents → dimension sections → contrary evidence (when present) → recommendations → collapsible source appendix → staleness map.
|
||||
- **Confidence is visual**: every claim carries its badge — verified / medium / low / `unverified` / disputed — color-coded with the status text always present (never color alone). Unverified and disputed must be *more* prominent than verified, not less.
|
||||
- **Sources are live**: inline `[n]` markers link to the appendix row; appendix rows link out to the source URL. Source URLs are untrusted content — never hand-escape them: generate the appendix table with `uv run scripts/recon_kit.py escape-sources {doc_workspace}/research.md` and embed its `html` output, which escapes every cell, anchors each row (`id="src-n"`), and links only validated `http(s)` URLs (anything else renders as plain text; the script lists it in `invalid_urls`). Apply the same escape discipline to any other source-derived text you place in attributes.
|
||||
- **Charts sparingly**: only where the data genuinely benefits (market size trajectory, decision matrix scores) — simple inline SVG, labeled axes, no library.
|
||||
- **Responsive and theme-aware**: readable on a phone; respect `prefers-color-scheme` for light/dark.
|
||||
|
||||
## Theme
|
||||
|
||||
`{workflow.html_theme}` governs: a `file:` path loads a theme/brand spec to follow; inline text is applied as directives; empty means the shipped default — neutral, professional, generous whitespace, system font stack, one restrained accent color. Whatever the theme, the confidence-badge semantics above are non-negotiable.
|
||||
@@ -0,0 +1,11 @@
|
||||
# Refresh and Deepen
|
||||
|
||||
Lifecycle intents on an existing run folder.
|
||||
|
||||
## Refresh
|
||||
|
||||
Read `research.md` and `.memlog.md` — never re-research from scratch. Build the refresh set mechanically: assemble the claims (`claim`, `class`, `pub_date`) from the ledger, map the pack's freshness bars to a months-per-class JSON, and run `uv run scripts/recon_kit.py staleness <claims.json> --windows '<map>'` — the stale flags are the candidate set. Confirm it in one exchange, re-verify just those claims, and deliver a **delta report** (confirmed / changed / overturned, new sources) appended to `research.md` with the frontmatter `updated` bumped. Claims outside the set keep their status. An overturned load-bearing claim triggers an explicit warning naming the downstream artifacts that consumed it.
|
||||
|
||||
## Deepen
|
||||
|
||||
Drill into one dimension or add a new one without touching the rest: mini plan gate, acquire → verify for that slice only (or a drafted follow-up prompt when the user's tool is better placed), merge into `research.md`, update only the synthesis sections the new material affects — a deepening that changes no conclusion says so.
|
||||
@@ -0,0 +1,10 @@
|
||||
# Process
|
||||
|
||||
For a report the user names or drops ("there's a research report at <path>, process it"):
|
||||
|
||||
1. **File it.** Find or create the run folder: if a drafted brief for this topic exists, that folder is the target; otherwise infer type and topic from the report (confirm in one line), bind `{doc_workspace}` (expand the folder name with `uv run scripts/recon_kit.py slug` as in Draft), and init the memlog. Move or copy the original into `{doc_workspace}/imports/` untouched — full fidelity is preserved there, and nowhere else.
|
||||
2. **Record provenance** in the memlog: what produced it (which tool or firm), when (ask if not evident — production date drives staleness), and what the user wants decided from it.
|
||||
3. **Extract.** A subagent (fresh context, firewall rules) reads the import and pulls every claim bearing on the decision into digest files under `{doc_workspace}/digests/` — standard shape `{claim, source, publisher, pub_date, accessed, confidence, class}`, keeping the original's citations (the cited source is the publisher; the import is the via). Multiple imports each get their own digest; contradictions between them are findings, not noise.
|
||||
4. **Check against the pack**: which of the type's dimensions the material covers, which are open, where its claims fall inside two-source classes but rest on one publisher. Verification per the resolved `validation` level (`references/verification.md`) — at `normal` this is a spot-check of the load-bearing claims only, minutes not hours.
|
||||
5. **Distill** into `research.md` per `references/synthesis.md` — the succinct, cited, decision-first summary with full metadata frontmatter (topic, type, decision, `source:` provenance, dates, status). This is the artifact downstream skills read; nobody ever reprocesses the import. Open dimensions are listed honestly with a one-line route: draft a follow-up prompt, or a targeted Run on the gap.
|
||||
6. Finalize per `references/finalize.md`.
|
||||
@@ -0,0 +1,73 @@
|
||||
# Run
|
||||
|
||||
Native research, when chosen: resolve effort, hold the plan gate, then run the acquisition loop once per dimension of the approved plan, in plan order.
|
||||
|
||||
## Effort
|
||||
|
||||
Three knobs bundled in a **preset**; any knob pins individually, and **what the user says in the request beats both**.
|
||||
|
||||
| Preset (`{workflow.preset}`) | subagents | sources/round | depth |
|
||||
|---|---|---|---|
|
||||
| `quick` | low (2) | 5 | 1 |
|
||||
| `standard` (default) | normal (3) | 8 | 2 |
|
||||
| `deep` | high (6) | 12 | 3 |
|
||||
|
||||
- **subagents** — parallel assistants: `none` (0 — inline, sequential; also the no-subagent-harness fallback), `low` (2), `normal` (3), `high` (6, cap 10 — beyond the 3–5 sweet spot only for genuinely wide work).
|
||||
- **max_sources_per_round** — distinct sources actually read per dimension per round (cap 25).
|
||||
- **max_depth** — rounds per dimension: initial pass plus lead-following follow-ups (cap 5). A cap, not a quota — dimensions stop early on coverage or novelty exhaustion.
|
||||
- **validation** (orthogonal to preset, default `normal`) — rigor rises `normal` < `high` < `max`; level semantics live in `references/verification.md`. Verification happens per dimension as material lands, never as an end-of-run rewrite pass.
|
||||
|
||||
`{workflow.subagent_models}` is an ordered model preference for assistants — first available wins; empty means harness default. Keep the lead on the strongest model; researchers at most one tier down; judgment work never on the smallest tier.
|
||||
|
||||
## The plan gate
|
||||
|
||||
The one hard stop, kept light: decision, type and pack-derived dimensions pruned to it, shape, the **decomposition topology** — *breadth-first* (independent sub-questions: assistants split the dimensions), *depth-first* (one question that needs several perspectives: assistants split by angle or methodology, not by dimension), or *straightforward* (a focused ask: one assistant, a handful of calls, no fan-out — never overinvest in a simple query) — knobs in force and where each came from, which search surfaces exist (harness web search; installed search-shaped MCP tools; `{workflow.external_sources}` — check, don't assume), whether to run the fan-out as a workflow when the harness offers orchestration and `{workflow.use_workflows}` allows, and an honest time estimate (a standard run is minutes; deep runs are tens of minutes and many times the tokens).
|
||||
|
||||
Present as a compact checklist, get approval, then: bind `{doc_workspace}` under `{workflow.research_output_path}` — expand the folder name with `uv run scripts/recon_kit.py slug "<topic>" --type <type> --pattern "{workflow.run_folder_pattern}"` so the same topic always resolves to the same folder — seed `research.md` from `{workflow.research_template}`, init the memlog (`uv run {project-root}/_bmad/scripts/memlog.py init --workspace {doc_workspace} --field topic="<topic>" --field type="<type>" --field decision="<decision>" --field preset="<preset>"`), log the approved plan as a `decision`, and tell the user the path.
|
||||
|
||||
Each dimension then runs in **rounds** — up to the resolved `max_depth` — and the report grows as material lands: the user watches the document build, not a spinner. Every digest is written to `{doc_workspace}/digests/` the moment it exists — one file per assistant per round (`<dimension>-r<round>-<n>.md`), the digest shape below, raw enough to re-derive from.
|
||||
|
||||
## Rounds and lead-following
|
||||
|
||||
Round 1 pursues the plan's questions **broad-first**: short, wide queries to map what exists, narrowing as the shape emerges — not long specific queries that return nothing. After each round, harvest the leads: new entities worth chasing, unexpected connections, contradictions between sources, and questions the round opened. Contradictions get priority. Promising leads become the next round's brief; note mid-course discoveries in the checkpoint so the user sees the turn happening.
|
||||
|
||||
A dimension stops before its round cap when either holds:
|
||||
|
||||
- **Coverage** — its plan questions are answered, with the critical claims confirmed per the resolved `validation` level.
|
||||
- **Novelty exhaustion** — a full round surfaced no new load-bearing claim or lead.
|
||||
|
||||
Say which one ended it. Hitting the round cap with open questions is reported as an open question, never silently dropped.
|
||||
|
||||
**Stop-and-write valve.** If the run is dragging well past the plan gate's estimate — rounds queuing, budgets mostly spent — stop spawning, synthesize from the digests already on disk, and report the remainder as open questions with a route (a Deepen later, or a drafted prompt for the user's own tool). A shorter honest report beats a longer stale one.
|
||||
|
||||
## The fan-out
|
||||
|
||||
Fan out researcher assistants for the round — concurrency per the resolved `subagents` level, split by the plan's **topology**: breadth-first gives each assistant independent sub-questions; depth-first gives each a distinct perspective or methodology on the *same* question; straightforward is one assistant with a small budget — never fan out what one focused assistant answers. Each assistant runs behind the **research firewall**: it gets its brief and nothing else — no project files, no ambient context. The brief contains:
|
||||
|
||||
- the questions it owns, the decision they serve, and the topic
|
||||
- its search surfaces (specialized tools first — installed search-shaped MCP tools, `{workflow.external_sources}` entries whose directive matches — then generic search), plus `{workflow.preferred_sources}` first / `{workflow.banned_sources}` never
|
||||
- the pack's source craft and freshness bars, and the source-quality card below
|
||||
- its budgets — sources (the round's share of `max_sources_per_round`) and tool calls, scaled to its task: under 5 for a simple lookup, ~5 medium, ~10 hard, 15 for genuinely multi-part, 20 never exceeded. Either budget spent → synthesize what it has
|
||||
- the query craft: short queries (roughly five words or fewer) beat hyper-specific ones that return nothing; broaden when results are sparse, narrow when abundant; never repeat an identical query on the same tool; after every tool result, pause and evaluate — what did this add, what gap remains, what's the best next query — before firing again
|
||||
- the epistemics rules verbatim, and the return contract: a digest, not raw results — findings as claims, each with `{claim, source, publisher, pub_date, accessed, confidence, class}`, plus leads worth chasing and what it looked for and could not find
|
||||
|
||||
**On each return, write the digest to `{doc_workspace}/digests/` before doing anything else with it.**
|
||||
|
||||
Spawn assistants on `{workflow.subagent_models}` when set (first available wins); otherwise the harness default — judgment work never drops to the smallest tier. When subagents are unavailable (or `subagents` is `none`), run the same rounds yourself, sequentially, under the same budgets and the same files-first discipline.
|
||||
|
||||
When workflow orchestration was approved at the plan gate, run the fan-out as a workflow: dimensions as parallel pipelines, assistants returning structured digests. The budgets, digest contract, firewall, and stopping rules apply unchanged — and however the acquisition parallelizes, digests land as files and the lead alone writes `research.md`, committing sections in plan order.
|
||||
|
||||
## Source quality
|
||||
|
||||
One card, applied by every assistant and the lead alike. Prefer **primary sources** — filings, regulator text, official documentation, original papers, a company's own reported numbers — over aggregators and secondary reporting. Red flags that downgrade confidence on sight: speculative language ("could", "may", projections in future tense presented as findings), marketing register, passive voice with unnamed sources, cherry-picked or unsourced numbers, and aggregators recycling a single upstream report (that's one publisher, however many domains echo it). Answer engines (Perplexity Sonar, Grok, and kin) are aggregators too, however good the synthesis: chase their citations and cite those, never the engine. Conflicts resolve by recency, consistency with adjacent established facts, and publisher quality — never by averaging.
|
||||
|
||||
## Synthesize the dimension
|
||||
|
||||
When a dimension's rounds are done:
|
||||
|
||||
1. Verify at landing per `references/verification.md` — at `normal` validation this is a spot-check of the dimension's load-bearing claims, not a sweep.
|
||||
2. Write the dimension's section per the pack's skeleton from its digest files — findings woven into prose answering the dimension's questions, every load-bearing claim cited inline `[n]`, confidence flagged where below high, contradictions reported with both sides cited. Append to `research.md` and add its sources to the running source table.
|
||||
3. Log one memlog line per source batch (`--type source`) and one per load-bearing claim worth tracking for refresh — `--type claim`, text in the machine-readable shape `ref=[n] status=<verified|unverified|disputed|overturned> class=<class> pub=<YYYY-MM> — <claim>` so `scripts/recon_kit.py tally` and `staleness` can read the ledger; a later status change is a fresh claim line with the same `ref=` (last status wins).
|
||||
4. Checkpoint: one or two lines in chat — what the dimension found, anything surprising, anything unresolved. Keep moving unless the user speaks up; a mid-run scope change is logged as a `decision` and the plan adjusts. Headless: skip checkpoints entirely.
|
||||
|
||||
When all dimensions are done, proceed to `references/synthesis.md` for final assembly.
|
||||
@@ -0,0 +1,13 @@
|
||||
# The Select Shape
|
||||
|
||||
When the decision is **choose between candidates** — technologies, vendors, libraries, platforms, agencies, anything — this method layers over whichever research type fits the subject. The type pack still governs sources, craft, and freshness; this shape governs the flow and the verdict.
|
||||
|
||||
1. **Requirements frame.** What must the winner do, under what constraints — scale, compliance, budget, team skills, existing stack, exit-cost tolerance? Split hard gates from weighted preferences and set the weights. Sources: the project itself (brief, PRD, spine, `{workflow.persistent_facts}`, codebase) and the user — web research does not set requirements. **Agree the frame before any candidate research runs**; interactive runs confirm it even though the plan gate approved the dimension list.
|
||||
2. **Candidate screen.** Establish the credible field — leaders, strong challengers, one wildcard — and cut anything failing a hard gate. Screen to 3–5 finalists; record the cuts and why. Screening sources ≤ 6 months old — this field moves.
|
||||
3. **Evidence per criterion.** Score finalists against the frame using the type pack's dimensions and craft, verified against current versions/offerings. Cite every contested cell; where vendor claims and independent experience diverge, the divergence is a finding.
|
||||
4. **Cost & lock-in.** Total cost over the product's horizon — license/subscription, hosting, operational load, learning curve — and the cost of leaving. Current pricing pages read directly (≤ 3 mo, always); pricing-change history — a vendor that repriced once will again; migration-away accounts for real exit costs.
|
||||
5. **Verdict.** The weighted decision matrix — show the scoring, not just totals; a matrix the user can re-weight is worth more than a verdict they must trust. Then: the pick; the named runner-up and the conditions under which it wins instead; the strongest argument against the pick (from the red-team pass when it ran); the cheapest reversibility hedge (abstraction seam, pilot scope, exit test).
|
||||
|
||||
**Two-source classes (added to the type's own):** pricing figures; performance/scale numbers; any cell that decides between the top two finalists.
|
||||
|
||||
**Staleness:** a selection report older than two quarters should be refreshed before anyone acts on it — say so in the report.
|
||||
@@ -0,0 +1,16 @@
|
||||
# Synthesis
|
||||
|
||||
The report answers the decision — whether the material came from a native Run or a processed import. **Succinct is the contract**: findings and verdicts, not essays; rationale lives in the memlog; a reader gets the decision-relevant truth in minutes. For Process mode this is the whole point — the summary is what downstream consumers read so nobody reprocesses the original, and sections with nothing behind them collapse to a line rather than pad.
|
||||
|
||||
Assemble `research.md` in this order, shaped by `{workflow.audience}` and written in `{document_output_language}`:
|
||||
|
||||
1. **Executive summary** — decision-first: what the evidence says to do, the two or three findings that drive that answer, and the biggest caveat. One page maximum, readable standalone. Written last, placed first.
|
||||
2. **Dimension sections** — already written during the loop; now reconciled: consistent terminology, no duplicated ground, verification statuses and any corrections from the pass applied to the text.
|
||||
3. **Cross-dimension insights** — what only the *combination* shows (e.g. the market is growing but the regulatory dimension caps the reachable segment; the technically superior option loses on ecosystem health). This section is the harness earning its keep — if there are no cross-dimension insights, say so rather than manufacture them.
|
||||
4. **Contrary evidence** — when the red-team pass ran and found material; the strongest surviving counter-arguments, cited.
|
||||
5. **Recommendations** — each bound to the decision and, where the project has them, to the downstream artifact that consumes it (per the pack's `Feeds` entries: brief section, PRD input, architecture constraint). Each recommendation names its confidence basis; a recommendation resting on low-confidence or disputed claims says so in the same sentence.
|
||||
6. **Open questions** — what the research could not answer, and what it would take to answer each.
|
||||
7. **Source appendix** — the numbered source table: `[n] | claim/finding it supports | publisher | pub date | accessed | confidence`, the publisher cell a markdown link to the source URL. Every inline `[n]` resolves here.
|
||||
8. **Staleness map** — the claims that age fastest, computed not hand-derived: build the claims list (`claim`, `class`, `pub_date`) from the ledger, map the pack's freshness bars to months per class, and run `uv run scripts/recon_kit.py staleness <claims.json> --windows '<map>'` — render its re-check dates and close by noting the earliest. This is Refresh's work order.
|
||||
|
||||
Update the frontmatter (`status: complete`, `updated`, and the verified/unverified counts from `uv run scripts/recon_kit.py tally {doc_workspace}/.memlog.md` — never hand-counted), log a final `event` in the memlog, and proceed to `references/finalize.md`.
|
||||
@@ -0,0 +1,29 @@
|
||||
# Verification
|
||||
|
||||
The trust layer — the same rules whatever produced the material (a native run's digests or a processed import). Verification happens **as material lands**, per dimension, in fresh-context verifier subagents reading digest files — never as an end-of-run rewrite pass over an hour of accumulated context. Late-pass rewrites degrade reports; landing-time checks improve them.
|
||||
|
||||
## The claims ledger
|
||||
|
||||
The memlog `claim` entries are the ledger: every claim a decision could rest on, with its class (each pack names its classes — quantitative sizes, pricing, versions/compatibility, regulatory assertions, …), source, publisher, publication date, and status. New claims enter `unverified`; on a Refresh or Deepen run, claims outside the run's scope keep their prior status from the memlog — only new and in-scope claims are (re)checked.
|
||||
|
||||
## Levels
|
||||
|
||||
Per the resolved `validation` level (request > knob > default `normal`):
|
||||
|
||||
- **normal** — spot-check the **load-bearing claims only**: the handful per dimension the recommendation actually rests on. One independent-source check each, at landing. Everything else ships with its single source cited and confidence marked honestly. Fast by design.
|
||||
- **high** — cross-check every claim in the pack's *two-source classes*, and run the red-team pass on major conclusions regardless of `{workflow.red_team}`.
|
||||
- **max** — cross-check every ledger claim, run the red-team pass below at full breadth (every major conclusion), and primary-source-priority ranking: where a primary source (filing, regulator text, official docs, original paper) exists, secondary reporting alone does not verify.
|
||||
|
||||
Verifier assistants run behind the research firewall on `{workflow.subagent_models}` when set; judgment work never drops to the smallest tier.
|
||||
|
||||
**Independent** means a different publisher with different underlying data or reporting — not a syndication, quote, or republication of the first source, and not the same vendor's marketing in two places. An imported report counts as one publisher regardless of how many sources it cites internally; two imports from different tools agreeing is genuine confirmation, and their disagreement is a finding.
|
||||
|
||||
Outcomes per claim: **verified** (independent source agrees within tolerance — for quantitative claims, same order of magnitude and direction), **disputed** (independent sources materially disagree — report both figures, both cited; never average), **unverified** (no independent check within budget — the claim stays, flagged, and joins the staleness map), or **overturned** (the weight of evidence contradicts it — corrected in the text, original noted). Every status change lands in the memlog as a fresh `claim` line with the same `ref=` and the new status — last status wins, which is how `scripts/recon_kit.py tally` reads the ledger. A verification outcome adjusts status and flags — it never licenses rewriting a finding's substance beyond what the new evidence says.
|
||||
|
||||
Confidence rendered in the report: **high** (verified, fresh, credible publishers), **medium** (single credible source, fresh), **low** (stale, weak publisher, or disputed) — plus the explicit `unverified` flag. Confidence is per-claim, never per-section.
|
||||
|
||||
## Red-team pass
|
||||
|
||||
The single adversarial mechanism — no other verifier duplicates it. Off by default (`{workflow.red_team}` = `"off"`; `"offer"` proposes it at the plan gate, `"on"` always runs; `high` validation includes it for major conclusions, `max` runs it at full breadth). When it runs: for each major conclusion, a **fresh-context** skeptic subagent — the conclusion and a search budget, no supporting evidence, no run context — hunts for disconfirming evidence: the bear case, failed attempts, contrary data, the strongest good-faith argument the conclusion is wrong.
|
||||
|
||||
What comes back is weighed, not appended: a conclusion that survives gets its strongest counter-argument acknowledged in the synthesis; one that doesn't is revised before the report states it. Material findings land in a **Contrary Evidence** section with full citation discipline. Zero findings after a real search is itself reportable — say what was searched for and not found.
|
||||
@@ -0,0 +1,322 @@
|
||||
#!/usr/bin/env python3
|
||||
# /// script
|
||||
# requires-python = ">=3.10"
|
||||
# ///
|
||||
"""recon_kit — deterministic helpers for bmad-deep-recon.
|
||||
|
||||
The mechanical half of the research workflow: everything here is exact,
|
||||
repeatable work the LLM should never re-derive by hand. All subcommands
|
||||
print one JSON object to stdout; diagnostics go to stderr. Exit codes:
|
||||
0 = pass, 1 = findings that need attention, 2 = usage/parse error.
|
||||
|
||||
Subcommands:
|
||||
citations RESEARCH_MD
|
||||
Cross-check inline [n] markers against the source-appendix table:
|
||||
dangling markers (no appendix row) and orphaned rows (never cited).
|
||||
tally MEMLOG_MD
|
||||
Count memlog entries by type, and claim entries by status.
|
||||
Claim lines carry `status=<word>` and optionally `ref=[n]`; for a
|
||||
given ref the LAST status wins, so status changes are appends.
|
||||
staleness CLAIMS_JSON --windows JSON [--today YYYY-MM-DD]
|
||||
Given claims [{claim, class, pub_date}] and a months-per-class map
|
||||
(e.g. '{"size/growth": 18, "pricing": 3}'), compute each claim's
|
||||
re-check date, flag stale ones, and report the earliest re-check.
|
||||
slug TOPIC --type TYPE [--pattern P] [--date YYYY-MM-DD]
|
||||
Expand the run-folder pattern deterministically so the same topic
|
||||
always lands in the same folder across draft -> process -> refresh.
|
||||
escape-sources RESEARCH_MD
|
||||
Emit the source-appendix table as HTML with every cell escaped and
|
||||
only validated http(s) URLs turned into links, for the briefing.
|
||||
"""
|
||||
from __future__ import annotations
|
||||
|
||||
import argparse
|
||||
import calendar
|
||||
import html
|
||||
import json
|
||||
import re
|
||||
import sys
|
||||
import unicodedata
|
||||
from datetime import date, datetime
|
||||
from pathlib import Path
|
||||
from urllib.parse import urlparse
|
||||
|
||||
MARKER_RE = re.compile(r"\[(\d+)\](?!\()") # [3] but not a [3](url) link
|
||||
MD_LINK_RE = re.compile(r"\[([^\]]*)\]\((\S+?)\)")
|
||||
BARE_URL_RE = re.compile(r"https?://[^\s|)\]]+")
|
||||
|
||||
|
||||
def out(payload: dict, exit_code: int) -> int:
|
||||
print(json.dumps(payload, indent=2, ensure_ascii=False, default=str))
|
||||
return exit_code
|
||||
|
||||
|
||||
def read_text(path_arg: str) -> str:
|
||||
if path_arg == "-":
|
||||
return sys.stdin.read()
|
||||
return Path(path_arg).read_text(encoding="utf-8")
|
||||
|
||||
|
||||
def strip_fences(text: str) -> str:
|
||||
"""Blank out fenced code blocks so their contents never count as markers or rows."""
|
||||
lines, fenced = [], False
|
||||
for ln in text.splitlines():
|
||||
if ln.lstrip().startswith("```"):
|
||||
fenced = not fenced
|
||||
lines.append("")
|
||||
continue
|
||||
lines.append("" if fenced else ln)
|
||||
return "\n".join(lines)
|
||||
|
||||
|
||||
def table_cells(line: str) -> list[str]:
|
||||
return [c.strip() for c in line.strip().strip("|").split("|")]
|
||||
|
||||
|
||||
def appendix_rows(text: str) -> dict[int, list[str]]:
|
||||
"""Source-appendix rows: markdown table rows whose first cell is a bare [n] / n."""
|
||||
rows: dict[int, list[str]] = {}
|
||||
for ln in text.splitlines():
|
||||
stripped = ln.strip()
|
||||
if not stripped.startswith("|"):
|
||||
continue
|
||||
cells = table_cells(stripped)
|
||||
if not cells or len(cells) < 2:
|
||||
continue
|
||||
m = re.fullmatch(r"\[?(\d+)\]?", cells[0])
|
||||
if m:
|
||||
rows[int(m.group(1))] = cells
|
||||
return rows
|
||||
|
||||
|
||||
# --- citations ---------------------------------------------------------------
|
||||
|
||||
def cmd_citations(args) -> int:
|
||||
text = strip_fences(read_text(args.file))
|
||||
rows = appendix_rows(text)
|
||||
markers: set[int] = set()
|
||||
for ln in text.splitlines():
|
||||
stripped = ln.strip()
|
||||
if stripped.startswith("|"):
|
||||
cells = table_cells(stripped)
|
||||
if cells and re.fullmatch(r"\[?(\d+)\]?", cells[0]):
|
||||
continue # an appendix row is not a citation of itself
|
||||
markers.update(int(n) for n in MARKER_RE.findall(ln))
|
||||
dangling = sorted(markers - set(rows))
|
||||
orphaned = sorted(set(rows) - markers)
|
||||
ok = not dangling and not orphaned
|
||||
return out({
|
||||
"markers": sorted(markers),
|
||||
"appendix_rows": sorted(rows),
|
||||
"dangling_markers": dangling,
|
||||
"orphaned_rows": orphaned,
|
||||
"ok": ok,
|
||||
}, 0 if ok else 1)
|
||||
|
||||
|
||||
# --- tally -------------------------------------------------------------------
|
||||
|
||||
ENTRY_RE = re.compile(r"^- (?:\(([\w-]+)(?: by [^)]*)?\)\s*)?(.*)$")
|
||||
|
||||
|
||||
def cmd_tally(args) -> int:
|
||||
text = read_text(args.file)
|
||||
body = text.split("---", 2)[-1] if text.startswith("---") else text
|
||||
by_type: dict[str, int] = {}
|
||||
by_ref: dict[int, str] = {}
|
||||
unref_status: dict[str, int] = {}
|
||||
entries = 0
|
||||
for ln in body.splitlines():
|
||||
m = ENTRY_RE.match(ln)
|
||||
if not m or not ln.startswith("- "):
|
||||
continue
|
||||
entries += 1
|
||||
etype = m.group(1) or "note"
|
||||
by_type[etype] = by_type.get(etype, 0) + 1
|
||||
if etype == "claim":
|
||||
status_m = re.search(r"status=([\w-]+)", m.group(2))
|
||||
status = status_m.group(1) if status_m else "unknown"
|
||||
ref_m = re.search(r"ref=\[?(\d+)\]?", m.group(2))
|
||||
if ref_m:
|
||||
by_ref[int(ref_m.group(1))] = status # last status wins per ref
|
||||
else:
|
||||
unref_status[status] = unref_status.get(status, 0) + 1
|
||||
claims: dict[str, int] = dict(unref_status)
|
||||
for status in by_ref.values():
|
||||
claims[status] = claims.get(status, 0) + 1
|
||||
return out({
|
||||
"entries": entries,
|
||||
"by_type": dict(sorted(by_type.items())),
|
||||
"claims": dict(sorted(claims.items())),
|
||||
"claims_total": sum(claims.values()),
|
||||
}, 0)
|
||||
|
||||
|
||||
# --- staleness ---------------------------------------------------------------
|
||||
|
||||
def parse_date(raw: str) -> date:
|
||||
raw = raw.strip()
|
||||
for fmt in ("%Y-%m-%d", "%Y-%m", "%Y"):
|
||||
try:
|
||||
return datetime.strptime(raw, fmt).date()
|
||||
except ValueError:
|
||||
continue
|
||||
raise ValueError(f"unparseable date: {raw!r} (want YYYY[-MM[-DD]])")
|
||||
|
||||
|
||||
def add_months(d: date, months: int) -> date:
|
||||
total = d.month - 1 + months
|
||||
year, month = d.year + total // 12, total % 12 + 1
|
||||
return date(year, month, min(d.day, calendar.monthrange(year, month)[1]))
|
||||
|
||||
|
||||
def cmd_staleness(args) -> int:
|
||||
try:
|
||||
payload = json.loads(read_text(args.file))
|
||||
windows = {k.lower(): int(v) for k, v in json.loads(args.windows).items()}
|
||||
today = parse_date(args.today) if args.today else date.today()
|
||||
except (ValueError, json.JSONDecodeError) as e:
|
||||
print(f"error: {e}", file=sys.stderr)
|
||||
return 2
|
||||
claims = payload["claims"] if isinstance(payload, dict) else payload
|
||||
results, no_window, stale_count = [], set(), 0
|
||||
earliest: date | None = None
|
||||
for c in claims:
|
||||
cls = str(c.get("class", "")).lower()
|
||||
try:
|
||||
pub = parse_date(str(c["pub_date"]))
|
||||
except (KeyError, ValueError) as e:
|
||||
print(f"error in claim {c!r}: {e}", file=sys.stderr)
|
||||
return 2
|
||||
months = windows.get(cls)
|
||||
if months is None:
|
||||
no_window.add(cls)
|
||||
results.append({**c, "recheck": None, "stale": None})
|
||||
continue
|
||||
recheck = add_months(pub, months)
|
||||
stale = recheck <= today
|
||||
stale_count += stale
|
||||
earliest = recheck if earliest is None or recheck < earliest else earliest
|
||||
results.append({**c, "recheck": recheck.isoformat(), "stale": stale})
|
||||
return out({
|
||||
"today": today.isoformat(),
|
||||
"claims": results,
|
||||
"stale_count": stale_count,
|
||||
"earliest_recheck": earliest.isoformat() if earliest else None,
|
||||
"no_window_classes": sorted(no_window),
|
||||
}, 1 if stale_count else 0)
|
||||
|
||||
|
||||
# --- slug --------------------------------------------------------------------
|
||||
|
||||
def slugify(text: str, max_len: int = 40) -> str:
|
||||
text = unicodedata.normalize("NFKD", text).encode("ascii", "ignore").decode()
|
||||
text = re.sub(r"[^a-z0-9]+", "-", text.lower()).strip("-")
|
||||
return re.sub(r"-{2,}", "-", text)[:max_len].rstrip("-")
|
||||
|
||||
|
||||
def cmd_slug(args) -> int:
|
||||
slug = slugify(args.topic)
|
||||
if not slug:
|
||||
print("error: topic slugified to an empty string", file=sys.stderr)
|
||||
return 2
|
||||
folder = (args.pattern
|
||||
.replace("{research_type}", args.type)
|
||||
.replace("{topic_slug}", slug)
|
||||
.replace("{date}", args.date or date.today().isoformat()))
|
||||
return out({"topic_slug": slug, "folder": folder}, 0)
|
||||
|
||||
|
||||
# --- escape-sources ----------------------------------------------------------
|
||||
|
||||
def safe_url(raw: str) -> str | None:
|
||||
parsed = urlparse(raw)
|
||||
return raw if parsed.scheme in ("http", "https") and parsed.netloc else None
|
||||
|
||||
|
||||
def cell_html(cell: str, invalid: list[str]) -> str:
|
||||
"""Escape a cell; a markdown link or bare URL becomes an <a> only when http(s)."""
|
||||
link = MD_LINK_RE.search(cell)
|
||||
if link:
|
||||
url = safe_url(link.group(2))
|
||||
label = html.escape(link.group(1) or link.group(2))
|
||||
if url:
|
||||
return html.escape(cell[:link.start()]) + \
|
||||
f'<a href="{html.escape(url, quote=True)}" target="_blank" rel="noopener">{label}</a>' + \
|
||||
html.escape(cell[link.end():])
|
||||
invalid.append(link.group(2))
|
||||
return html.escape(cell.replace(link.group(0), link.group(1) or link.group(2)))
|
||||
bare = BARE_URL_RE.search(cell)
|
||||
if bare:
|
||||
url = safe_url(bare.group(0))
|
||||
if url:
|
||||
escaped = html.escape(url, quote=True)
|
||||
return html.escape(cell[:bare.start()]) + \
|
||||
f'<a href="{escaped}" target="_blank" rel="noopener">{escaped}</a>' + \
|
||||
html.escape(cell[bare.end():])
|
||||
invalid.append(bare.group(0))
|
||||
return html.escape(cell)
|
||||
|
||||
|
||||
def cmd_escape_sources(args) -> int:
|
||||
text = strip_fences(read_text(args.file))
|
||||
rows = appendix_rows(text)
|
||||
if not rows:
|
||||
print("error: no source-appendix table rows found", file=sys.stderr)
|
||||
return 2
|
||||
invalid: list[str] = []
|
||||
body_rows = []
|
||||
for n in sorted(rows):
|
||||
cells = rows[n]
|
||||
tds = "".join(f"<td>{cell_html(c, invalid)}</td>" for c in cells[1:])
|
||||
body_rows.append(f'<tr id="src-{n}"><td>[{n}]</td>{tds}</tr>')
|
||||
table = ('<table class="sources"><tbody>' + "".join(body_rows) + "</tbody></table>")
|
||||
return out({"rows": len(rows), "invalid_urls": invalid, "html": table},
|
||||
1 if invalid else 0)
|
||||
|
||||
|
||||
# --- entry point -------------------------------------------------------------
|
||||
|
||||
def main(argv: list[str] | None = None) -> int:
|
||||
p = argparse.ArgumentParser(description=__doc__,
|
||||
formatter_class=argparse.RawDescriptionHelpFormatter)
|
||||
sub = p.add_subparsers(dest="cmd", required=True)
|
||||
|
||||
pc = sub.add_parser("citations", help="cross-check [n] markers vs the source appendix")
|
||||
pc.add_argument("file", help="path to research.md (or - for stdin)")
|
||||
pc.set_defaults(func=cmd_citations)
|
||||
|
||||
pt = sub.add_parser("tally", help="count memlog entries by type and claims by status")
|
||||
pt.add_argument("file", help="path to .memlog.md (or - for stdin)")
|
||||
pt.set_defaults(func=cmd_tally)
|
||||
|
||||
ps = sub.add_parser("staleness", help="compute re-check dates from freshness windows")
|
||||
ps.add_argument("file", help="claims JSON: [{claim, class, pub_date}] (or - for stdin)")
|
||||
ps.add_argument("--windows", required=True,
|
||||
help='JSON months-per-class map, e.g. \'{"pricing": 3}\'')
|
||||
ps.add_argument("--today", help="override today's date (YYYY-MM-DD)")
|
||||
ps.set_defaults(func=cmd_staleness)
|
||||
|
||||
pg = sub.add_parser("slug", help="expand the run-folder pattern deterministically")
|
||||
pg.add_argument("topic", help="research topic text")
|
||||
pg.add_argument("--type", required=True, help="research type code (e.g. market)")
|
||||
pg.add_argument("--pattern", default="{research_type}-{topic_slug}-{date}",
|
||||
help="folder pattern (default: {research_type}-{topic_slug}-{date})")
|
||||
pg.add_argument("--date", help="override date (YYYY-MM-DD; default today)")
|
||||
pg.set_defaults(func=cmd_slug)
|
||||
|
||||
pe = sub.add_parser("escape-sources",
|
||||
help="source appendix as escaped HTML with validated links")
|
||||
pe.add_argument("file", help="path to research.md (or - for stdin)")
|
||||
pe.set_defaults(func=cmd_escape_sources)
|
||||
|
||||
args = p.parse_args(argv)
|
||||
try:
|
||||
return args.func(args)
|
||||
except FileNotFoundError as e:
|
||||
print(f"error: {e}", file=sys.stderr)
|
||||
return 2
|
||||
|
||||
|
||||
if __name__ == "__main__":
|
||||
sys.exit(main())
|
||||
@@ -0,0 +1,144 @@
|
||||
#!/usr/bin/env python3
|
||||
# /// script
|
||||
# requires-python = ">=3.10"
|
||||
# ///
|
||||
"""Tests for recon_kit.py."""
|
||||
|
||||
import io
|
||||
import json
|
||||
import sys
|
||||
import unittest
|
||||
from contextlib import redirect_stdout
|
||||
from datetime import date
|
||||
from pathlib import Path
|
||||
|
||||
sys.path.insert(0, str(Path(__file__).resolve().parent.parent))
|
||||
|
||||
from recon_kit import add_months, main, parse_date, slugify
|
||||
|
||||
REPORT = """---
|
||||
title: 'market research: widgets'
|
||||
---
|
||||
|
||||
# Report
|
||||
|
||||
The market is growing fast [1] and pricing clusters at $20 [2].
|
||||
An uncited assertion sits here [4].
|
||||
|
||||
```
|
||||
[9] inside a fence never counts
|
||||
```
|
||||
|
||||
## Source appendix
|
||||
|
||||
| [n] | Supports | Publisher | Pub date | Accessed | Confidence |
|
||||
| --- | --- | --- | --- | --- | --- |
|
||||
| [1] | market growth | [Gartner](https://example.com/g) | 2026-01 | 2026-07-01 | high |
|
||||
| [2] | pricing | [Acme](javascript:alert(1)) | 2026-05 | 2026-07-01 | medium |
|
||||
| [3] | never cited | https://example.com/x | 2025-11 | 2026-07-01 | low |
|
||||
"""
|
||||
|
||||
MEMLOG = """---
|
||||
topic: widgets
|
||||
updated: 2026-07-22T10:00
|
||||
---
|
||||
|
||||
- (decision) plan approved
|
||||
- (source) round 1 batch: 4 sources
|
||||
- (claim) ref=[1] status=verified class=size/growth pub=2026-01 — market growing 12% CAGR
|
||||
- (claim) ref=[2] status=unverified class=pricing pub=2026-05 — pricing clusters at $20
|
||||
- (claim) ref=[2] status=verified class=pricing pub=2026-05 — confirmed by second source
|
||||
- (claim) status=unverified class=behavior pub=2025-03 — users churn at day 8
|
||||
- (event) dimension 1 complete
|
||||
"""
|
||||
|
||||
|
||||
def run(argv):
|
||||
buf = io.StringIO()
|
||||
with redirect_stdout(buf):
|
||||
code = main(argv)
|
||||
return code, json.loads(buf.getvalue())
|
||||
|
||||
|
||||
class CitationsTest(unittest.TestCase):
|
||||
def test_cross_check(self):
|
||||
report = Path(__file__).parent / "_report.md"
|
||||
report.write_text(REPORT, encoding="utf-8")
|
||||
try:
|
||||
code, result = run(["citations", str(report)])
|
||||
finally:
|
||||
report.unlink()
|
||||
self.assertEqual(result["dangling_markers"], [4])
|
||||
self.assertEqual(result["orphaned_rows"], [3])
|
||||
self.assertNotIn(9, result["markers"]) # fenced content ignored
|
||||
self.assertEqual(code, 1)
|
||||
|
||||
|
||||
class TallyTest(unittest.TestCase):
|
||||
def test_last_status_wins_per_ref(self):
|
||||
log = Path(__file__).parent / "_memlog.md"
|
||||
log.write_text(MEMLOG, encoding="utf-8")
|
||||
try:
|
||||
code, result = run(["tally", str(log)])
|
||||
finally:
|
||||
log.unlink()
|
||||
self.assertEqual(result["by_type"]["claim"], 4)
|
||||
self.assertEqual(result["claims"], {"unverified": 1, "verified": 2})
|
||||
self.assertEqual(result["claims_total"], 3) # ref=[2] counted once
|
||||
self.assertEqual(code, 0)
|
||||
|
||||
|
||||
class StalenessTest(unittest.TestCase):
|
||||
def test_dates(self):
|
||||
self.assertEqual(parse_date("2026-01"), date(2026, 1, 1))
|
||||
self.assertEqual(add_months(date(2026, 1, 31), 1), date(2026, 2, 28))
|
||||
|
||||
def test_windows(self):
|
||||
claims = json.dumps([
|
||||
{"claim": "sizing", "class": "size/growth", "pub_date": "2024-06"},
|
||||
{"claim": "pricing", "class": "pricing", "pub_date": "2026-06"},
|
||||
{"claim": "odd", "class": "unmapped", "pub_date": "2026-06"},
|
||||
])
|
||||
f = Path(__file__).parent / "_claims.json"
|
||||
f.write_text(claims, encoding="utf-8")
|
||||
try:
|
||||
code, result = run([
|
||||
"staleness", str(f),
|
||||
"--windows", '{"size/growth": 18, "pricing": 3}',
|
||||
"--today", "2026-07-22",
|
||||
])
|
||||
finally:
|
||||
f.unlink()
|
||||
self.assertEqual(result["stale_count"], 1) # sizing recheck 2025-12 < today
|
||||
self.assertEqual(result["earliest_recheck"], "2025-12-01")
|
||||
self.assertEqual(result["no_window_classes"], ["unmapped"])
|
||||
self.assertEqual(code, 1)
|
||||
|
||||
|
||||
class SlugTest(unittest.TestCase):
|
||||
def test_deterministic_folder(self):
|
||||
self.assertEqual(slugify("Créme Brûlée: AI Tools!"), "creme-brulee-ai-tools")
|
||||
code, result = run(["slug", "SMB Accounting SaaS", "--type", "market",
|
||||
"--date", "2026-07-22"])
|
||||
self.assertEqual(result["folder"], "market-smb-accounting-saas-2026-07-22")
|
||||
self.assertEqual(code, 0)
|
||||
|
||||
|
||||
class EscapeSourcesTest(unittest.TestCase):
|
||||
def test_escaping_and_url_validation(self):
|
||||
report = Path(__file__).parent / "_report.md"
|
||||
report.write_text(REPORT, encoding="utf-8")
|
||||
try:
|
||||
code, result = run(["escape-sources", str(report)])
|
||||
finally:
|
||||
report.unlink()
|
||||
self.assertEqual(result["rows"], 3)
|
||||
self.assertTrue(any(u.startswith("javascript:") for u in result["invalid_urls"]))
|
||||
self.assertNotIn("javascript:", result["html"]) # never linked
|
||||
self.assertIn('href="https://example.com/g"', result["html"])
|
||||
self.assertIn('id="src-1"', result["html"])
|
||||
self.assertEqual(code, 1)
|
||||
|
||||
|
||||
if __name__ == "__main__":
|
||||
unittest.main()
|
||||
@@ -0,0 +1,19 @@
|
||||
# Academic Literature Pack
|
||||
|
||||
Serves: ground an approach in published research, scan the state of the art, run a defensible literature review, cite properly in technical writing.
|
||||
|
||||
**Dimensions (priority order — prune to the decision):**
|
||||
|
||||
1. The canon — seminal papers and the best recent surveys of the area
|
||||
2. State of the art — current best results, benchmarks, and how they're measured
|
||||
3. Methods & limitations — what the leading approaches assume and where they break
|
||||
4. Open problems & live debates — what the field disagrees about right now
|
||||
5. Who works on this — the labs and groups whose output to watch
|
||||
|
||||
**Craft (the non-obvious):** find one good survey before reading twenty abstracts; chase citations both directions — who they cite and who cites them (Semantic Scholar/Google Scholar); label preprint vs peer-reviewed on every citation — arXiv is not acceptance; take benchmark numbers from the original paper, never from a competitor's comparison table; check retraction and replication status on any load-bearing empirical claim; a result only ever shown by one lab is a lead, not a fact.
|
||||
|
||||
**Freshness:** state-of-the-art claims ≤ 12 mo (ML ≤ 6 mo) · seminal work has no freshness bar — but check whether it was since superseded.
|
||||
|
||||
**Two-source classes:** any empirical claim a conclusion rests on — independent replication or corroboration, not the same lab twice.
|
||||
|
||||
**Feeds (bmm):** technical and architecture bets · content and writing that cites · build-vs-adopt judgments on research-grade techniques.
|
||||
@@ -0,0 +1,19 @@
|
||||
# Competitive Research Pack
|
||||
|
||||
Serves: position against *named* competitors, build battlecards, sharpen differentiation, anticipate their next move. (Surveying an unnamed field is the market type; this pack is for teardowns of specific players.)
|
||||
|
||||
**Dimensions (priority order — prune to the decision):**
|
||||
|
||||
1. Offer & feature teardown — what they actually ship, tried directly where possible
|
||||
2. Pricing & packaging — models, tiers, what changed recently and which direction
|
||||
3. Positioning & messaging — who they claim to serve, the story they tell, the gap between claim and product
|
||||
4. Trajectory — funding, hiring, release cadence: where they're headed
|
||||
5. Their customers' voice — what users of *their* product praise and complain about
|
||||
|
||||
**Craft (the non-obvious):** their changelog and release notes are roadmap truth; job postings reveal strategy six months early; their customers' 1–3★ reviews are your wedge; archived pricing pages (Wayback) show pricing direction, not just position; sales-facing comparison pages overclaim — verify capability claims against their docs; try the product yourself when a trial exists — an hour in-product beats ten reviews.
|
||||
|
||||
**Freshness:** pricing & features ≤ 3 mo · trajectory signals ≤ 6 mo · customer sentiment ≤ 12 mo.
|
||||
|
||||
**Two-source classes:** traction and market-share claims; any capability claim of theirs that your differentiation rests on.
|
||||
|
||||
**Feeds (bmm):** brief (alternatives) · PRD (differentiation) · GTM battlecards and positioning.
|
||||
@@ -0,0 +1,19 @@
|
||||
# Domain Research Pack
|
||||
|
||||
Serves: commit to building in an industry, talk credibly with domain experts, scope a product for a regulated field, brief a team entering unfamiliar territory.
|
||||
|
||||
**Dimensions (priority order — prune to the decision):**
|
||||
|
||||
1. Industry structure & value chain — how value flows, who captures margin where
|
||||
2. Key players & gatekeepers — incumbents, platforms, whose APIs/standards/marketplaces you build with or against
|
||||
3. Rules of the game — laws, licenses, de-facto standards, what compliance costs a new entrant
|
||||
4. Language & mental models — the vocabulary and implicit workflows practitioners think in; **build the glossary — it's why domain research exists**
|
||||
5. Technology adoption — the current technical baseline and where the industry sits on the adoption curve
|
||||
|
||||
**Craft (the non-obvious):** annual-report industry sections are free structured teardowns; conference keynotes reveal who actually matters; go to regulator sites directly for any load-bearing claim — and read enforcement actions to learn what's actually punished versus merely written; job postings name the real tools and skills; pending regulatory changes matter as much as current text.
|
||||
|
||||
**Freshness:** structure ≤ 3 yr · player landscape ≤ 18 mo · regulatory status: verify current on every load-bearing claim, whatever its date · tech adoption ≤ 18 mo, AI-adoption claims ≤ 6 mo.
|
||||
|
||||
**Two-source classes:** regulatory and compliance assertions; quantitative industry figures a recommendation rests on; claims about a gatekeeper's policy.
|
||||
|
||||
**Feeds (bmm):** brief (context, feasibility) · PRD (constraints, domain vocabulary) · architecture (integration landscape, compliance requirements).
|
||||
@@ -0,0 +1,19 @@
|
||||
# Market Research Pack
|
||||
|
||||
Serves: enter or skip a market, position a product, pick a segment, price an offer, pitch investors.
|
||||
|
||||
**Dimensions (priority order — prune to the decision):**
|
||||
|
||||
1. Market size & growth — the *reachable* market, not the headline TAM
|
||||
2. Customer segments & behavior — who buys, deciding how, valuing what
|
||||
3. Pain points & unmet needs — what they complain about, work around, pay to avoid
|
||||
4. Competitive landscape — who competes for this budget, including substitutes and "do nothing"
|
||||
5. GTM & pricing dynamics — channels, sales motion, accepted pricing models, realistic CAC
|
||||
|
||||
**Craft (the non-obvious):** 1–3★ reviews are the gold for pains; public-company 10-K/S-1 industry sections are free analyst-grade sizing; read competitor pricing pages directly, never roundups; funding history + job postings reveal competitor trajectory; a complaint pattern persisting across years is a stronger finding, not a stale one.
|
||||
|
||||
**Freshness:** size/growth ≤ 18 mo · pricing & feature claims ≤ 3 mo · behavior data ≤ 2 yr · GTM benchmarks ≤ 12 mo.
|
||||
|
||||
**Two-source classes:** market size and growth figures; any quantitative claim a recommendation rests on; competitor traction claims.
|
||||
|
||||
**Feeds (bmm):** brief (opportunity, problem, users) · PRD (personas, differentiation) · pricing and GTM decisions.
|
||||
@@ -0,0 +1,19 @@
|
||||
# Technical Research Pack
|
||||
|
||||
Serves: adopt a technology area, design an integration approach, ground an architecture in current practice, assess feasibility before committing a roadmap.
|
||||
|
||||
**Dimensions (priority order — prune to the decision):**
|
||||
|
||||
1. Landscape & maturity — dominant approaches, what's consolidating vs churning, what the current generation newly makes possible
|
||||
2. Integration & interoperability — protocols, formats, auth patterns, where integrations actually hurt
|
||||
3. Architecture patterns in practice — which named patterns dominate at what scale, and what the failures teach
|
||||
4. Implementation reality — learning curve, tooling, operational burden, what teams say 6–12 months in
|
||||
5. Ecosystem health — contributor/release vitality, backing durability, the five-year regret risk
|
||||
|
||||
**Craft (the non-obvious):** read the retrospective threads, not the launch threads; favor accounts with production numbers over advocacy; before citing a pain point, check whether it was since fixed — an old complaint against a current version is a false claim; read repository metrics over time, never snapshots; issue trackers reveal the gap between docs and reality.
|
||||
|
||||
**Freshness:** versions & compatibility ≤ 1 mo · ecosystem signals ≤ 6 mo · landscape ≤ 12 mo (AI-adjacent ≤ 3 mo) · patterns ≤ 2 yr.
|
||||
|
||||
**Two-source classes:** version/compatibility claims; performance or scale numbers a recommendation rests on; claims that a technology or pattern failed — one post-mortem is an anecdote.
|
||||
|
||||
**Feeds (bmm):** architecture spine (candidate paradigms, operational constraints) · brief (feasibility) · roadmap risk and estimates.
|
||||
@@ -0,0 +1,19 @@
|
||||
# User-Voice Research Pack
|
||||
|
||||
Serves: understand what users of a product or category actually experience and want — personas, jobs-to-be-done, requirements grounded in evidence rather than assumption.
|
||||
|
||||
**Dimensions (priority order — prune to the decision):**
|
||||
|
||||
1. Who they are & their jobs-to-be-done — the progress they're hiring the product to make
|
||||
2. Complaint & workaround patterns — where current options fail them
|
||||
3. Delight & switching triggers — why they stay, what made them move
|
||||
4. Unmet needs & requests — what they ask for, and the deeper need under the ask
|
||||
5. Their language — the words users say, versus the words vendors use
|
||||
|
||||
**Craft (the non-obvious):** mine 1–3★ reviews for pain *and* 5★ for why they stay; a workaround is unpriced demand — someone laboring around a gap has already voted; forums, Discord, and Reddit surface what surveys miss — people lie less when nobody's asking — but they over-sample the loud, so triangulate against reviews and any survey data; keep verbatim quotes, redacted — user words carry evidence paraphrase destroys, but usernames, handles, emails, and identifying links never enter the report or memlog; feature-request boards measure willingness to wait, not willingness to pay; distinguish loud power-users from the silent majority — count distinct voices, not thread length.
|
||||
|
||||
**Freshness:** sentiment ≤ 18 mo · complaints re-checked against the current version before citing.
|
||||
|
||||
**Two-source classes:** any prevalence claim ("most users…", "the top complaint is…") — two independent communities, not two threads in the same one.
|
||||
|
||||
**Feeds (bmm):** PRD (personas, requirements rationale) · UX research inputs · brief (problem) · product copy in the users' own language.
|
||||
@@ -7,3 +7,4 @@ Core,bmad-customize,BMad Customize,BC,"Use when you want to change how an agent
|
||||
Core,bmad-advanced-elicitation,Advanced Elicitation,AE,"Use at any checkpoint to push a just-produced draft, section, or plan past its first version — pick from a menu of elicitation methods (pre-mortem, first principles, red team, socratic) and apply the improvements.",,,anytime,,,false,,
|
||||
Core,bmad-review,Review,RV,"Use to review anything before it ships — a diff, branch, or uncommitted changes; a PRD, spec, story, or architecture doc; any prose document. Runs whichever installed lenses fit the content and reports findings in one shape: shipped lenses cover adversarial critique, edge cases, verification gaps, document structure (cuts, merges, moves), and prose copy-edit, and installs may add more. Reach for it to tighten a bloated or LLM-slop draft, pressure-test a plan before building, or check a change is adequately tested. Run every applicable lens or name the ones you want. Code Review in other modules calls it automatically.",,[path],anytime,,,false,,findings JSON array + markdown report
|
||||
Core,bmad-forge-idea,Forge Idea,FI,"Use to pressure-test and harden an idea — software, business, creative, research, or life — until it proves out, hardens into something buildable, or dies cheaply. Persona-driven interrogation; optional handoff to bmad-spec or bmad-quick-dev.",,,anytime,,,false,{output_folder}/forge,refined-idea brief (optional)
|
||||
Core,bmad-deep-recon,Deep Recon,RS,Decision-grade research three ways: draft a deep-research prompt for your own AI tool then process the returned report into a downstream-ready cited summary — or run the research directly via web fan-out. Types: market domain technical competitive user-voice academic-lit plus a select shape for choose-between decisions; claim verification and refresh lifecycle. Custom types via overrides.,,[type],anytime,,,false,{planning_artifacts}/research,research report/summary + optional html briefing
|
||||
|
||||
|
Reference in New Issue
Block a user