owflow 0.1.0 → 0.1.2
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/README.md +8 -1
- package/dist/agents/bottleneck-analyzer.md +329 -0
- package/dist/agents/code-quality-pragmatist.md +354 -0
- package/dist/agents/code-reviewer.md +239 -0
- package/dist/agents/codebase-analysis-reporter.md +246 -0
- package/dist/agents/docs-operator.md +23 -0
- package/dist/agents/e2e-test-verifier.md +448 -0
- package/dist/agents/gap-analyzer.md +502 -0
- package/dist/agents/implementation-completeness-checker.md +220 -0
- package/dist/agents/implementation-planner.md +309 -0
- package/dist/agents/information-gatherer.md +691 -0
- package/dist/agents/production-readiness-checker.md +279 -0
- package/dist/agents/project-analyzer.md +404 -0
- package/dist/agents/reality-assessor.md +366 -0
- package/dist/agents/research-planner.md +447 -0
- package/dist/agents/research-synthesizer.md +401 -0
- package/dist/agents/solution-brainstormer.md +257 -0
- package/dist/agents/solution-designer.md +372 -0
- package/dist/agents/spec-auditor.md +298 -0
- package/dist/agents/specification-creator.md +334 -0
- package/dist/agents/task-classifier.md +462 -0
- package/dist/agents/task-group-implementer.md +284 -0
- package/dist/agents/test-suite-runner.md +195 -0
- package/dist/agents/ui-mockup-generator.md +369 -0
- package/dist/agents/user-docs-generator.md +509 -0
- package/dist/commands/development.md +37 -0
- package/dist/commands/flow-init.md +37 -0
- package/dist/commands/migration.md +37 -0
- package/dist/commands/performance.md +37 -0
- package/dist/commands/product-design.md +37 -0
- package/dist/commands/quick-bugfix.md +37 -0
- package/dist/commands/quick-dev.md +140 -0
- package/dist/commands/quick-plan.md +132 -0
- package/dist/commands/research.md +37 -0
- package/dist/commands/reviews-code.md +90 -0
- package/dist/commands/reviews-pragmatic.md +99 -0
- package/dist/commands/reviews-production-readiness.md +113 -0
- package/dist/commands/reviews-reality-check.md +110 -0
- package/dist/commands/reviews-spec-audit.md +114 -0
- package/dist/commands/standards-discover.md +37 -0
- package/dist/commands/standards-update.md +37 -0
- package/dist/commands/work.md +284 -0
- package/dist/skills/codebase-analyzer/SKILL.md +162 -0
- package/dist/skills/codebase-analyzer/references/code-analysis.md +63 -0
- package/dist/skills/codebase-analyzer/references/combined.md +31 -0
- package/dist/skills/codebase-analyzer/references/context-discovery.md +63 -0
- package/dist/skills/codebase-analyzer/references/file-discovery.md +51 -0
- package/dist/skills/codebase-analyzer/references/migration-target.md +23 -0
- package/dist/skills/codebase-analyzer/references/pattern-mining.md +22 -0
- package/dist/skills/development/SKILL.md +669 -0
- package/dist/skills/docs-manager/SKILL.md +379 -0
- package/dist/skills/docs-manager/docs/INDEX.md +199 -0
- package/dist/skills/docs-manager/docs/standards/backend/api.md +25 -0
- package/dist/skills/docs-manager/docs/standards/backend/migrations.md +22 -0
- package/dist/skills/docs-manager/docs/standards/backend/models.md +25 -0
- package/dist/skills/docs-manager/docs/standards/backend/queries.md +22 -0
- package/dist/skills/docs-manager/docs/standards/frontend/accessibility.md +25 -0
- package/dist/skills/docs-manager/docs/standards/frontend/components.md +28 -0
- package/dist/skills/docs-manager/docs/standards/frontend/css.md +16 -0
- package/dist/skills/docs-manager/docs/standards/frontend/responsive.md +28 -0
- package/dist/skills/docs-manager/docs/standards/global/coding-style.md +25 -0
- package/dist/skills/docs-manager/docs/standards/global/commenting.md +10 -0
- package/dist/skills/docs-manager/docs/standards/global/conventions.md +31 -0
- package/dist/skills/docs-manager/docs/standards/global/error-handling.md +22 -0
- package/dist/skills/docs-manager/docs/standards/global/minimal-implementation.md +22 -0
- package/dist/skills/docs-manager/docs/standards/global/validation.md +28 -0
- package/dist/skills/docs-manager/docs/standards/testing/test-writing.md +25 -0
- package/dist/skills/docs-manager/references/claude-md-template.md +29 -0
- package/dist/skills/docs-manager/references/index-md-template.md +73 -0
- package/dist/skills/flow-init/SKILL.md +198 -0
- package/dist/skills/flow-init/references/architecture-template.md +45 -0
- package/dist/skills/flow-init/references/roadmap-templates.md +93 -0
- package/dist/skills/flow-init/references/tech-stack-template.md +70 -0
- package/dist/skills/flow-init/references/vision-templates.md +75 -0
- package/dist/skills/implementation-plan-executor/SKILL.md +378 -0
- package/dist/skills/implementation-verifier/SKILL.md +307 -0
- package/dist/skills/migration/SKILL.md +380 -0
- package/dist/skills/migration/references/migration-strategies.md +397 -0
- package/dist/skills/migration/references/migration-types.md +437 -0
- package/dist/skills/orchestrator-framework/SKILL.md +65 -0
- package/dist/skills/orchestrator-framework/references/orchestrator-creation-checklist.md +47 -0
- package/dist/skills/orchestrator-framework/references/orchestrator-patterns.md +329 -0
- package/dist/skills/performance/SKILL.md +418 -0
- package/dist/skills/performance/references/performance-optimization-guide.md +365 -0
- package/dist/skills/product-design/SKILL.md +843 -0
- package/dist/skills/product-design/references/characteristic-detection.md +92 -0
- package/dist/skills/product-design/references/interaction-patterns.md +206 -0
- package/dist/skills/product-design/references/visual-companion.md +190 -0
- package/dist/skills/product-design/server/index.ts +359 -0
- package/dist/skills/product-design/server/template.html +256 -0
- package/dist/skills/quick-bugfix/SKILL.md +241 -0
- package/dist/skills/research/SKILL.md +493 -0
- package/dist/skills/research/references/brainstorming-techniques.md +84 -0
- package/dist/skills/research/references/design-techniques.md +40 -0
- package/dist/skills/research/references/research-methodologies.md +710 -0
- package/dist/skills/standards-discover/SKILL.md +236 -0
- package/dist/skills/standards-discover/references/aggregation-strategy.md +76 -0
- package/dist/skills/standards-discover/references/code-pattern-prompt.md +68 -0
- package/dist/skills/standards-discover/references/config-analyzer-prompt.md +67 -0
- package/dist/skills/standards-discover/references/docs-extractor-prompt.md +65 -0
- package/dist/skills/standards-discover/references/external-analyzer-prompt.md +75 -0
- package/dist/skills/standards-update/SKILL.md +159 -0
- package/package.json +14 -6
|
@@ -0,0 +1,493 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: research
|
|
3
|
+
description: Orchestrates comprehensive research workflows from question definition through findings documentation. Handles technical, requirements, literature, and mixed research types with adaptive methodology, multi-source gathering, pattern synthesis, and evidence-based reporting. Supports standalone research tasks and embedded research phase in other workflows.
|
|
4
|
+
user-invocable: true
|
|
5
|
+
---
|
|
6
|
+
|
|
7
|
+
# Research Orchestrator
|
|
8
|
+
|
|
9
|
+
Systematic research workflow from question definition to evidence-based documentation.
|
|
10
|
+
|
|
11
|
+
## Initialization
|
|
12
|
+
|
|
13
|
+
**BEFORE executing any phase, you MUST complete these steps:**
|
|
14
|
+
|
|
15
|
+
### Step 1: Load Framework Patterns
|
|
16
|
+
|
|
17
|
+
**Read the framework reference file NOW using the Read tool:**
|
|
18
|
+
|
|
19
|
+
1. `../orchestrator-framework/references/orchestrator-patterns.md` - Delegation rules, interactive mode, state schema, initialization, context passing, issue resolution
|
|
20
|
+
|
|
21
|
+
### Step 2: Initialize Workflow
|
|
22
|
+
|
|
23
|
+
1. **Create Task Items**: Use `TaskCreate` for all phases (see Phase Configuration), then set dependencies with `TaskUpdate addBlockedBy`
|
|
24
|
+
2. **Create Task Directory**: `.owflow/tasks/research/YYYY-MM-DD-task-name/`
|
|
25
|
+
3. **Initialize State**: Create `orchestrator-state.yml` with research context
|
|
26
|
+
|
|
27
|
+
**Output**:
|
|
28
|
+
|
|
29
|
+
```
|
|
30
|
+
🚀 Research Orchestrator Started
|
|
31
|
+
|
|
32
|
+
Task: [research question]
|
|
33
|
+
Directory: [task-path]
|
|
34
|
+
|
|
35
|
+
Starting Phase 1: Initialize research...
|
|
36
|
+
```
|
|
37
|
+
|
|
38
|
+
---
|
|
39
|
+
|
|
40
|
+
## When to Use
|
|
41
|
+
|
|
42
|
+
Use when:
|
|
43
|
+
|
|
44
|
+
- Need comprehensive research on a topic
|
|
45
|
+
- Exploring codebase patterns or architecture
|
|
46
|
+
- Gathering requirements or best practices
|
|
47
|
+
- Want systematic evidence-based answers
|
|
48
|
+
- Research will feed into development workflows
|
|
49
|
+
|
|
50
|
+
**DO NOT use for**: Development tasks, bug fixes, performance optimization.
|
|
51
|
+
|
|
52
|
+
---
|
|
53
|
+
|
|
54
|
+
## Core Principles
|
|
55
|
+
|
|
56
|
+
1. **Evidence-Based**: Every finding must have source citation
|
|
57
|
+
2. **Systematic**: Follow structured methodology for consistent results
|
|
58
|
+
3. **Multi-Source**: Gather from codebase, docs, config, external sources
|
|
59
|
+
4. **Synthesized**: Cross-reference findings, identify patterns
|
|
60
|
+
5. **Actionable**: Produce outputs that enable next steps
|
|
61
|
+
|
|
62
|
+
---
|
|
63
|
+
|
|
64
|
+
## Local References
|
|
65
|
+
|
|
66
|
+
| File | When to Use | Purpose |
|
|
67
|
+
| ---------------------------------------- | ----------- | ---------------------------------------------------------------------------------------------- |
|
|
68
|
+
| `references/research-methodologies.md` | Phase 1 | Research type classification, methodology selection, gathering strategies, analysis frameworks |
|
|
69
|
+
| `references/brainstorming-techniques.md` | Phase 3 | Divergent/convergent thinking, interactive exploration, scope guardrails |
|
|
70
|
+
| `references/design-techniques.md` | Phase 5 | Decision documentation (MADR), ADR guidance, decision linking |
|
|
71
|
+
|
|
72
|
+
---
|
|
73
|
+
|
|
74
|
+
## Phase Configuration
|
|
75
|
+
|
|
76
|
+
| Phase | content | activeForm | Agent/Skill |
|
|
77
|
+
| ----- | ------------------------------------------------------ | --------------------------------------- | ---------------------------------------------------------------------------- |
|
|
78
|
+
| 1 | "Research foundation (init, plan, gather, synthesize)" | "Executing research foundation" | Direct + research-planner + information-gatherer (xN) + research-synthesizer |
|
|
79
|
+
| 2 | "Evaluate brainstorming value" | "Evaluating brainstorming value" | Direct |
|
|
80
|
+
| 3 | "Generate solution alternatives" | "Generating solution alternatives" | solution-brainstormer |
|
|
81
|
+
| 4 | "Evaluate brainstorming alternatives" | "Evaluating brainstorming alternatives" | Direct (interactive) |
|
|
82
|
+
| 5 | "Design high-level architecture" | "Designing high-level architecture" | Direct + solution-designer |
|
|
83
|
+
| 6 | "Summarize research and suggest next steps" | "Completing research" | Direct |
|
|
84
|
+
|
|
85
|
+
---
|
|
86
|
+
|
|
87
|
+
## Research Types
|
|
88
|
+
|
|
89
|
+
| Type | Keywords | Focus | Typical Outputs |
|
|
90
|
+
| ---------------- | ---------------------------------------- | --------------------------- | --------------------------------- |
|
|
91
|
+
| **Technical** | "how does", "where is", "implementation" | Codebase analysis | Knowledge base, architecture docs |
|
|
92
|
+
| **Requirements** | "what are requirements", "user needs" | User/business needs | Specifications, requirements doc |
|
|
93
|
+
| **Literature** | "best practices", "industry standards" | External research | Recommendations, comparisons |
|
|
94
|
+
| **Mixed** | Multiple keywords, broad questions | Comprehensive investigation | All output types |
|
|
95
|
+
|
|
96
|
+
---
|
|
97
|
+
|
|
98
|
+
## Workflow Phases
|
|
99
|
+
|
|
100
|
+
### Phase 1: Research Foundation
|
|
101
|
+
|
|
102
|
+
**Purpose**: Initialize research, plan methodology, gather information from all sources, and synthesize findings into a research report
|
|
103
|
+
**Execute**: Multi-step: Direct + research-planner + information-gatherer (xN) + research-synthesizer
|
|
104
|
+
**Output**: `planning/research-brief.md`, `planning/research-plan.md`, `planning/sources.md`, `analysis/findings/*.md`, `analysis/synthesis.md`, `outputs/research-report.md`
|
|
105
|
+
**State**: Set `research_context.research_type`, `research_question`, `scope`, `methodology`, `sources`, `confidence_level`, `gathering_strategy`
|
|
106
|
+
|
|
107
|
+
This phase executes 4 sequential steps. On resume, check existing artifacts to skip completed steps.
|
|
108
|
+
|
|
109
|
+
#### Step 1: Initialize (Direct)
|
|
110
|
+
|
|
111
|
+
**Artifacts**: `planning/research-brief.md`
|
|
112
|
+
**Resume check**: If `planning/research-brief.md` exists, skip to Step 2
|
|
113
|
+
|
|
114
|
+
1. Parse research question (from command or prompt user)
|
|
115
|
+
2. Classify research type (auto-detect from keywords or use `--type` flag)
|
|
116
|
+
3. Determine scope (included, excluded, constraints)
|
|
117
|
+
4. Define success criteria
|
|
118
|
+
5. Create research brief
|
|
119
|
+
6. Update state: set `research_context.research_type`, `research_question`, `scope`
|
|
120
|
+
7. **Discover project documentation**: Read `.owflow/docs/INDEX.md` (if exists), extract ALL file paths from the "Project Documentation" section — includes predefined docs AND any user-added project docs. Store as `research_context.project_doc_paths` in state.
|
|
121
|
+
|
|
122
|
+
#### Step 2: Plan (Subagent)
|
|
123
|
+
|
|
124
|
+
**Artifacts**: `planning/research-plan.md`, `planning/sources.md`
|
|
125
|
+
**Resume check**: If `planning/research-plan.md` AND `planning/sources.md` exist, skip to Step 3
|
|
126
|
+
|
|
127
|
+
**Read `references/research-methodologies.md` NOW using the Read tool** — research type classification, methodology selection, gathering strategies
|
|
128
|
+
|
|
129
|
+
**INVOKE NOW**: Use Task tool with `subagent_type: research-planner`
|
|
130
|
+
|
|
131
|
+
**Context to pass**: task_path, research_brief_path, research_type, research_question, scope, project_doc_paths (from state)
|
|
132
|
+
|
|
133
|
+
Update state: `research_context.methodology`, `sources`
|
|
134
|
+
|
|
135
|
+
#### Step 3: Gather + Merge (Parallel Subagents + Direct)
|
|
136
|
+
|
|
137
|
+
**Artifacts**: `analysis/findings/*.md` (category-specific)
|
|
138
|
+
**Resume check**: If any `analysis/findings/*.md` files exist, skip to Step 4
|
|
139
|
+
|
|
140
|
+
**Determine gatherer count and categories**:
|
|
141
|
+
|
|
142
|
+
1. Read `planning/research-plan.md` for **Gathering Strategy** section
|
|
143
|
+
2. If gathering strategy found: use specified categories and count (cap at 8 max)
|
|
144
|
+
3. If no gathering strategy: fall back to default 4 categories (codebase, documentation, configuration, external)
|
|
145
|
+
4. Update state: `research_context.gathering_strategy`
|
|
146
|
+
|
|
147
|
+
**CRITICAL: Launch all N agents in ONE message for parallel execution.**
|
|
148
|
+
|
|
149
|
+
**Parallel Execution Pattern**:
|
|
150
|
+
|
|
151
|
+
```
|
|
152
|
+
Read gathering strategy from research-plan.md
|
|
153
|
+
For each category in strategy:
|
|
154
|
+
Use Task tool: source_category=[category_id] → analysis/findings/[prefix]-*.md
|
|
155
|
+
```
|
|
156
|
+
|
|
157
|
+
#### Step 4: Synthesize (Subagent)
|
|
158
|
+
|
|
159
|
+
**Artifacts**: `analysis/synthesis.md`, `outputs/research-report.md`
|
|
160
|
+
**Resume check**: If `analysis/synthesis.md` AND `outputs/research-report.md` exist, skip (Phase 1 complete)
|
|
161
|
+
|
|
162
|
+
**INVOKE NOW**: Use Task tool with `subagent_type: research-synthesizer`
|
|
163
|
+
|
|
164
|
+
**Context to pass**: task_path, findings_directory_path, research_question, research_type, methodology
|
|
165
|
+
|
|
166
|
+
**Synthesizer produces**:
|
|
167
|
+
|
|
168
|
+
- Pattern analysis and cross-references (`analysis/synthesis.md`)
|
|
169
|
+
- Comprehensive research report answering research question (`outputs/research-report.md`)
|
|
170
|
+
- Confidence levels for each finding
|
|
171
|
+
- Documented gaps and uncertainties
|
|
172
|
+
|
|
173
|
+
Update state: `research_context.confidence_level`
|
|
174
|
+
|
|
175
|
+
---
|
|
176
|
+
|
|
177
|
+
→ Pause
|
|
178
|
+
|
|
179
|
+
question - "Research foundation complete (initialized, planned, gathered, synthesized). Continue to brainstorming evaluation?"
|
|
180
|
+
|
|
181
|
+
---
|
|
182
|
+
|
|
183
|
+
### Phase 2: Optional Phases Decision
|
|
184
|
+
|
|
185
|
+
> **Phase gate**: Requires `question` confirmation from Phase 1 before executing.
|
|
186
|
+
|
|
187
|
+
**Purpose**: Evaluate whether brainstorming and/or design phases would be valuable (independently)
|
|
188
|
+
**Execute**: Direct
|
|
189
|
+
**Output**: Updated `orchestrator-state.yml`
|
|
190
|
+
**State**: Set `options.brainstorming_enabled`, `options.design_enabled`
|
|
191
|
+
|
|
192
|
+
**Auto-resolve if**: `--brainstorm`/`--no-brainstorm` flags (brainstorming only), `--design`/`--no-design` flags (design only)
|
|
193
|
+
|
|
194
|
+
**Process**:
|
|
195
|
+
|
|
196
|
+
1. Read `analysis/synthesis.md` summary and `research_type` from state
|
|
197
|
+
2. Evaluate brainstorming value based on:
|
|
198
|
+
- Number of viable approaches identified in synthesis (multiple → valuable)
|
|
199
|
+
- Problem novelty (new domain → valuable; well-understood → less so)
|
|
200
|
+
- Whether synthesis identified competing trade-offs (yes → valuable)
|
|
201
|
+
3. Evaluate design value based on:
|
|
202
|
+
- Whether research suggests architectural decisions (yes → valuable)
|
|
203
|
+
- Research type (requirements/mixed → likely valuable; technical → depends)
|
|
204
|
+
- Whether design artifacts would feed into development workflow
|
|
205
|
+
4. If `brainstorming_enabled` not already set by flag, question:
|
|
206
|
+
- "[Brainstorming recommendation]. Would you like to explore solution alternatives?"
|
|
207
|
+
- Options: "Yes, explore alternatives" / "No, skip brainstorming"
|
|
208
|
+
5. If `design_enabled` not already set by flag, question:
|
|
209
|
+
- "[Design recommendation]. Would you like to generate a high-level design?"
|
|
210
|
+
- Options: "Yes, generate design" / "No, skip design"
|
|
211
|
+
6. Update state: set `brainstorming_enabled` and `design_enabled`
|
|
212
|
+
|
|
213
|
+
→ If brainstorming enabled: continue to Phase 3
|
|
214
|
+
→ If brainstorming disabled AND design enabled: skip to Phase 5
|
|
215
|
+
→ If both disabled: skip to Phase 6
|
|
216
|
+
|
|
217
|
+
---
|
|
218
|
+
|
|
219
|
+
### Phase 3: Solution Generation
|
|
220
|
+
|
|
221
|
+
**Purpose**: Generate solution alternatives from research evidence using specialized brainstormer subagent
|
|
222
|
+
**Execute**: solution-brainstormer subagent
|
|
223
|
+
**Output**: `outputs/solution-exploration.md`
|
|
224
|
+
**State**: Update `phase_summaries.phase-3`
|
|
225
|
+
|
|
226
|
+
**Skip if**: `brainstorming_enabled = false` (user chose to skip in Phase 2, or `--no-brainstorm` flag)
|
|
227
|
+
|
|
228
|
+
**Read `references/brainstorming-techniques.md` NOW using the Read tool** — divergent/convergent thinking techniques, scope guardrails
|
|
229
|
+
|
|
230
|
+
> **ANTI-PATTERN**: Do NOT generate solution alternatives inline. The solution-brainstormer agent has specialized multi-perspective analysis capabilities.
|
|
231
|
+
|
|
232
|
+
**INVOKE NOW**: Use Task tool with `subagent_type: solution-brainstormer`
|
|
233
|
+
|
|
234
|
+
**Context to pass** (Pattern 7):
|
|
235
|
+
|
|
236
|
+
- `task_path`, `synthesis_path`, `research_report_path`
|
|
237
|
+
- `output_path`: `outputs/solution-exploration.md` — brainstormer MUST write to this exact path
|
|
238
|
+
- Accumulated context: `research_type`, `research_question`, `confidence_level`, `phase_summaries` (Phase 1)
|
|
239
|
+
- `project_doc_paths` (from state)
|
|
240
|
+
|
|
241
|
+
> **SELF-CHECK**: After Task tool returns, verify `outputs/solution-exploration.md` exists and contains alternatives. If missing: **STOP. Do NOT proceed to Phase 4 or Phase 5.** Re-invoke the brainstormer with corrected context (ensure `output_path` is `outputs/solution-exploration.md`). If second attempt also fails, use question to report the failure and ask whether to retry or skip brainstorming.
|
|
242
|
+
|
|
243
|
+
→ **AUTO-CONTINUE**
|
|
244
|
+
|
|
245
|
+
---
|
|
246
|
+
|
|
247
|
+
### Phase 4: Solution Convergence
|
|
248
|
+
|
|
249
|
+
**Purpose**: Present brainstorming alternatives to user for decision-making on each decision area
|
|
250
|
+
**Execute**: Direct (interactive)
|
|
251
|
+
**Output**: Updated `orchestrator-state.yml` with chosen approaches
|
|
252
|
+
**State**: Update `phase_summaries.phase-4` with `decision_areas` and `deferred_ideas`
|
|
253
|
+
|
|
254
|
+
**Skip if**: `brainstorming_enabled = false`
|
|
255
|
+
**Resume check**: If `phase_summaries.phase-4.decision_areas` has entries with `chosen_approach` set, skip already-resolved areas
|
|
256
|
+
|
|
257
|
+
> **ANTI-PATTERN**: Do NOT present all decision areas in a single summary table and ask one combined "do you agree?" question. Each area MUST get its own detailed presentation and its own question call.
|
|
258
|
+
>
|
|
259
|
+
> **ANTI-PATTERN**: Do NOT show full alternatives/pros/cons for the first area and then shortcut remaining areas to just a recommendation line + question. EVERY area gets the SAME level of detail — all alternatives with descriptions, pros, and cons. No exceptions.
|
|
260
|
+
|
|
261
|
+
1. Read `outputs/solution-exploration.md`
|
|
262
|
+
2. For each decision area sequentially, output ALL of the following (steps a-d) BEFORE calling question:
|
|
263
|
+
a. **Area header**: area name and why this decision matters (1-2 sentences of context)
|
|
264
|
+
b. **Alternatives detail**: For EVERY alternative in this area, show:
|
|
265
|
+
- Name and description (2-3 sentences)
|
|
266
|
+
- Pros (bullet list)
|
|
267
|
+
- Cons (bullet list)
|
|
268
|
+
c. **Recommendation**: which alternative is recommended and why (1 sentence)
|
|
269
|
+
d. **question**: this area's alternatives as options (mark recommended with "(Recommended)") + "Need more info" option
|
|
270
|
+
e. If user picks → record choice, move to next area
|
|
271
|
+
f. If "Need more info" → present the detailed trade-off analysis for the requested alternative, then re-ask
|
|
272
|
+
|
|
273
|
+
> **SELF-CHECK before each question**: Did you output the alternatives with pros/cons for THIS area? If you only showed a recommendation line without listing all alternatives and their pros/cons, STOP and output the full detail before asking.
|
|
274
|
+
|
|
275
|
+
3. After all areas resolved, present a brief summary of the chosen combination
|
|
276
|
+
4. Update state with chosen approaches per decision area
|
|
277
|
+
|
|
278
|
+
> **GATE CHECK**: Verify that question was called for EACH decision area. If any decision area was skipped for any reason (e.g., output file missing, read failure), STOP and resolve before continuing. Do NOT mark Phase 4 complete without user convergence on all decision areas.
|
|
279
|
+
|
|
280
|
+
→ Pause
|
|
281
|
+
|
|
282
|
+
question - "Brainstorming complete. Continue to high-level design?"
|
|
283
|
+
|
|
284
|
+
---
|
|
285
|
+
|
|
286
|
+
### Phase 5: High-Level Design
|
|
287
|
+
|
|
288
|
+
> **Phase gate**: Requires `question` confirmation from the preceding phase before executing.
|
|
289
|
+
|
|
290
|
+
**Purpose**: Create architecture design from selected solution approach
|
|
291
|
+
**Execute**: Orchestrator-Direct Hybrid
|
|
292
|
+
**Output**: `outputs/high-level-design.md`, `outputs/decision-log.md`
|
|
293
|
+
**State**: Update `phase_summaries.phase-5`
|
|
294
|
+
|
|
295
|
+
**Skip if**: `design_enabled = false`
|
|
296
|
+
|
|
297
|
+
**Read `references/design-techniques.md` NOW using the Read tool** — MADR format, ADR guidance, decision documentation patterns
|
|
298
|
+
|
|
299
|
+
**Part A — Design Direction (Direct)**:
|
|
300
|
+
|
|
301
|
+
1. If Phase 4 ran: confirm selected approaches from convergence
|
|
302
|
+
2. If Phase 4 was skipped: use research report recommendations as design input
|
|
303
|
+
3. question for any design preferences or constraints (e.g., "Any architectural constraints or preferences?")
|
|
304
|
+
|
|
305
|
+
**Part B — Design Generation (Subagent)**:
|
|
306
|
+
|
|
307
|
+
> **ANTI-PATTERN**: Do NOT generate C4 architecture diagrams or ADRs inline. The solution-designer agent has specialized architecture and MADR documentation capabilities.
|
|
308
|
+
|
|
309
|
+
**INVOKE NOW**: Use Task tool with `subagent_type: solution-designer`
|
|
310
|
+
|
|
311
|
+
**Context to pass** (Pattern 7):
|
|
312
|
+
|
|
313
|
+
- `task_path`, `synthesis_path`, `research_report_path`
|
|
314
|
+
- `solution_exploration_path` (only if Phase 3-4 ran)
|
|
315
|
+
- `selected_approach` (from Phase 4 convergence if ran, or from research report recommendations)
|
|
316
|
+
- `design_preferences` (from Part A)
|
|
317
|
+
- Accumulated context: `research_type`, `research_question`, `confidence_level`, `phase_summaries`
|
|
318
|
+
- `project_doc_paths` (from state)
|
|
319
|
+
|
|
320
|
+
> **SELF-CHECK**: After Task tool returns, verify both `outputs/high-level-design.md` and `outputs/decision-log.md` exist. If missing: **STOP. Do NOT proceed to Part C.** Re-invoke the designer with corrected context. If second attempt also fails, use question to report the failure and ask whether to retry or skip design.
|
|
321
|
+
|
|
322
|
+
**Part C — Summary (Direct)**: 3. Read `outputs/high-level-design.md` and `outputs/decision-log.md` 4. Present executive summary to user:
|
|
323
|
+
|
|
324
|
+
- Architecture style and key components
|
|
325
|
+
- Number of architectural decisions recorded
|
|
326
|
+
- Key decision highlights (1 line each)
|
|
327
|
+
- Integration points with existing system (if applicable)
|
|
328
|
+
|
|
329
|
+
→ Pause
|
|
330
|
+
|
|
331
|
+
question - "Design complete. Continue to output generation?"
|
|
332
|
+
|
|
333
|
+
---
|
|
334
|
+
|
|
335
|
+
### Phase 6: Completion
|
|
336
|
+
|
|
337
|
+
> **Phase gate**: Requires `question` confirmation from the preceding phase before executing.
|
|
338
|
+
|
|
339
|
+
**Purpose**: Summarize research results and suggest next steps
|
|
340
|
+
**Execute**: Direct
|
|
341
|
+
**Output**: No new files — summarizes existing outputs
|
|
342
|
+
|
|
343
|
+
**Process**:
|
|
344
|
+
|
|
345
|
+
1. Inventory all generated outputs: `outputs/research-report.md` (always), plus conditional: `solution-exploration.md`, `high-level-design.md`, `decision-log.md`
|
|
346
|
+
2. Present executive summary to user:
|
|
347
|
+
- Key findings and confidence level
|
|
348
|
+
- Which optional phases ran (brainstorming, design)
|
|
349
|
+
- Key decision highlights (if brainstorming/design ran)
|
|
350
|
+
3. If design artifacts exist, suggest starting development in a fresh session:
|
|
351
|
+
```
|
|
352
|
+
To start development based on this research, clear context first or start a new session, then run:
|
|
353
|
+
/development [task-path]
|
|
354
|
+
```
|
|
355
|
+
|
|
356
|
+
→ End of workflow
|
|
357
|
+
|
|
358
|
+
---
|
|
359
|
+
|
|
360
|
+
## Domain Context (State Extensions)
|
|
361
|
+
|
|
362
|
+
Research-specific fields in `orchestrator-state.yml`:
|
|
363
|
+
|
|
364
|
+
```yaml
|
|
365
|
+
research_context:
|
|
366
|
+
research_type: "technical" | "requirements" | "literature" | "mixed"
|
|
367
|
+
research_question: "[user's question]"
|
|
368
|
+
scope:
|
|
369
|
+
included: []
|
|
370
|
+
excluded: []
|
|
371
|
+
constraints: []
|
|
372
|
+
methodology: []
|
|
373
|
+
sources: []
|
|
374
|
+
confidence_level: "high" | "medium" | "low"
|
|
375
|
+
gathering_strategy:
|
|
376
|
+
categories: [] # e.g., ["codebase", "documentation", "external-apis"]
|
|
377
|
+
count: 4 # number of gatherer instances
|
|
378
|
+
source: "planner" | "default" # where strategy came from
|
|
379
|
+
phase_summaries:
|
|
380
|
+
phase-1:
|
|
381
|
+
summary: "..."
|
|
382
|
+
steps_completed: [] # track which steps completed for resume
|
|
383
|
+
phase-3:
|
|
384
|
+
summary: "..."
|
|
385
|
+
phase-4:
|
|
386
|
+
summary: "..."
|
|
387
|
+
decision_areas: [] # list of {area, alternatives_count, chosen_approach}
|
|
388
|
+
deferred_ideas: []
|
|
389
|
+
phase-5:
|
|
390
|
+
summary: "..."
|
|
391
|
+
architecture_style: null
|
|
392
|
+
decisions_count: 0
|
|
393
|
+
|
|
394
|
+
options:
|
|
395
|
+
brainstorming_enabled: null # null=not yet decided, set by Phase 2 or --brainstorm/--no-brainstorm flag
|
|
396
|
+
design_enabled: null # independent, set by Phase 2 or --design/--no-design flag
|
|
397
|
+
```
|
|
398
|
+
|
|
399
|
+
---
|
|
400
|
+
|
|
401
|
+
## Task Structure
|
|
402
|
+
|
|
403
|
+
```
|
|
404
|
+
.owflow/tasks/research/YYYY-MM-DD-research-name/
|
|
405
|
+
├── orchestrator-state.yml
|
|
406
|
+
├── planning/
|
|
407
|
+
│ ├── research-brief.md # Phase 1, Step 1
|
|
408
|
+
│ ├── research-plan.md # Phase 1, Step 2
|
|
409
|
+
│ └── sources.md # Phase 1, Step 2
|
|
410
|
+
├── analysis/
|
|
411
|
+
│ ├── findings/
|
|
412
|
+
│ │ ├── codebase-*.md # Phase 1, Step 3
|
|
413
|
+
│ │ ├── docs-*.md # Phase 1, Step 3
|
|
414
|
+
│ │ ├── config-*.md # Phase 1, Step 3
|
|
415
|
+
│ │ ├── external-*.md # Phase 1, Step 3
|
|
416
|
+
│ │ └── [custom-category]-*.md # Phase 1, Step 3 (dynamic categories)
|
|
417
|
+
│ └── synthesis.md # Phase 1, Step 4 (reasoning log)
|
|
418
|
+
├── outputs/
|
|
419
|
+
│ ├── research-report.md # Phase 1, Step 4 (main deliverable)
|
|
420
|
+
│ ├── solution-exploration.md # Phase 3 (conditional)
|
|
421
|
+
│ ├── high-level-design.md # Phase 5 (conditional)
|
|
422
|
+
│ └── decision-log.md # Phase 5 (conditional)
|
|
423
|
+
```
|
|
424
|
+
|
|
425
|
+
---
|
|
426
|
+
|
|
427
|
+
## Auto-Recovery
|
|
428
|
+
|
|
429
|
+
| Phase | Max Attempts | Strategy |
|
|
430
|
+
| ---------- | ------------ | ------------------------------------------------------------- |
|
|
431
|
+
| 1 (Step 1) | 1 | Prompt user for clarification if question unclear |
|
|
432
|
+
| 1 (Step 2) | 2 | Expand search patterns, use fallback mixed methodology |
|
|
433
|
+
| 1 (Step 3) | 3 | Retry failed agents only, continue with successful categories |
|
|
434
|
+
| 1 (Step 4) | 2 | Request targeted re-gathering for gaps |
|
|
435
|
+
| 2 | 1 | Re-evaluate recommendation if synthesis unclear |
|
|
436
|
+
| 3 | 2 | Re-invoke solution-brainstormer with adjusted context |
|
|
437
|
+
| 4 | 1 | Re-read exploration file, re-present decision areas |
|
|
438
|
+
| 5 | 2 | Re-invoke solution-designer with adjusted context |
|
|
439
|
+
| 6 | 0 | Summary only |
|
|
440
|
+
|
|
441
|
+
---
|
|
442
|
+
|
|
443
|
+
## Integration with Other Workflows
|
|
444
|
+
|
|
445
|
+
### As Standalone Research
|
|
446
|
+
|
|
447
|
+
**Command**: `/research [research-question]`
|
|
448
|
+
**Flow**: Complete all phases, save outputs in task directory
|
|
449
|
+
|
|
450
|
+
### As Embedded Research Phase
|
|
451
|
+
|
|
452
|
+
**Invoked by**: development orchestrator, migration orchestrator
|
|
453
|
+
|
|
454
|
+
**Integration**:
|
|
455
|
+
|
|
456
|
+
1. Parent orchestrator invokes research skill
|
|
457
|
+
2. Research executes phases 1-5 (skip Phase 6 completion — parent orchestrator handles next steps)
|
|
458
|
+
3. Design outputs fed into parent's specification phase
|
|
459
|
+
4. Research report saved in parent task's `analysis/research/` directory
|
|
460
|
+
|
|
461
|
+
**Handoff**:
|
|
462
|
+
|
|
463
|
+
```yaml
|
|
464
|
+
research_outputs:
|
|
465
|
+
research_report: "[path to outputs/research-report.md]"
|
|
466
|
+
findings_directory: "[path to analysis/findings/]"
|
|
467
|
+
solution_exploration: "[path to outputs/solution-exploration.md]"
|
|
468
|
+
high_level_design: "[path to outputs/high-level-design.md]"
|
|
469
|
+
decision_log: "[path to outputs/decision-log.md]"
|
|
470
|
+
```
|
|
471
|
+
|
|
472
|
+
---
|
|
473
|
+
|
|
474
|
+
## Command Integration
|
|
475
|
+
|
|
476
|
+
Invoked via:
|
|
477
|
+
|
|
478
|
+
- `/research [question] [--type=TYPE] [--brainstorm] [--no-brainstorm] [--design] [--no-design]` (new)
|
|
479
|
+
- `/research [task-path] [--from=PHASE]` (resume)
|
|
480
|
+
|
|
481
|
+
**Brainstorming flags**:
|
|
482
|
+
|
|
483
|
+
- `--brainstorm`: Force brainstorming phase (auto-resolves Phase 2 brainstorming decision to "enable")
|
|
484
|
+
- `--no-brainstorm`: Skip brainstorming phase
|
|
485
|
+
- Neither: Phase 2 presents recommendation and asks user
|
|
486
|
+
|
|
487
|
+
**Design flags**:
|
|
488
|
+
|
|
489
|
+
- `--design`: Force high-level design phase (auto-resolves Phase 2 design decision to "enable")
|
|
490
|
+
- `--no-design`: Skip high-level design phase
|
|
491
|
+
- Neither: Phase 2 presents recommendation and asks user
|
|
492
|
+
|
|
493
|
+
Task directory: `.owflow/tasks/research/YYYY-MM-DD-task-name/`
|
|
@@ -0,0 +1,84 @@
|
|
|
1
|
+
# Brainstorming Techniques
|
|
2
|
+
|
|
3
|
+
These techniques guide Phase 3 (Solution Brainstorming) of the research workflow. They provide patterns for expanding the solution space, evaluating alternatives, and managing scope.
|
|
4
|
+
|
|
5
|
+
---
|
|
6
|
+
|
|
7
|
+
### Divergent Thinking Techniques
|
|
8
|
+
|
|
9
|
+
**Purpose**: Expand the solution space before narrowing. Generate quantity of ideas before evaluating quality.
|
|
10
|
+
|
|
11
|
+
**HMW (How Might We) Questions**:
|
|
12
|
+
- Transform research findings into opportunity statements
|
|
13
|
+
- Format: "How might we [desired outcome] while [respecting constraint]?"
|
|
14
|
+
- Generate 3-7 HMW questions from synthesis findings
|
|
15
|
+
- Good HMW questions are neither too broad ("How might we solve everything?") nor too narrow ("How might we add a button?")
|
|
16
|
+
- Each HMW should open multiple solution paths
|
|
17
|
+
|
|
18
|
+
**SCAMPER Framework** (for alternative generation):
|
|
19
|
+
- **S**ubstitute: What if we replaced component X with Y?
|
|
20
|
+
- **C**ombine: What if we merged two approaches?
|
|
21
|
+
- **A**dapt: What pattern from another domain applies here?
|
|
22
|
+
- **M**odify: What if we changed the scale or emphasis?
|
|
23
|
+
- **P**ut to other use: Can existing code serve a new purpose?
|
|
24
|
+
- **E**liminate: What if we removed this constraint?
|
|
25
|
+
- **R**everse: What if we did the opposite of the obvious approach?
|
|
26
|
+
|
|
27
|
+
**Brainstorming Guardrails**:
|
|
28
|
+
- Defer judgment during generation (evaluate later)
|
|
29
|
+
- Build on existing ideas ("yes, and..." not "no, but...")
|
|
30
|
+
- Aim for at least 3 genuine alternatives per decision area
|
|
31
|
+
- Alternatives should be meaningfully different, not minor variations
|
|
32
|
+
- Every alternative should be defensible by someone
|
|
33
|
+
|
|
34
|
+
---
|
|
35
|
+
|
|
36
|
+
### Convergent Thinking Techniques
|
|
37
|
+
|
|
38
|
+
**Purpose**: Evaluate and select from generated alternatives using structured criteria.
|
|
39
|
+
|
|
40
|
+
**5-Perspective Evaluation Matrix**:
|
|
41
|
+
|
|
42
|
+
| Perspective | Assessment Focus | When It Dominates |
|
|
43
|
+
|-------------|-----------------|-------------------|
|
|
44
|
+
| Technical Feasibility | Implementation complexity, technology maturity | Tight timeline, limited expertise |
|
|
45
|
+
| User Impact | UX improvement, adoption barriers, learning curve | User-facing features |
|
|
46
|
+
| Simplicity | Maintenance burden, cognitive load, conceptual clarity | Long-lived systems |
|
|
47
|
+
| Risk | Technical risk, schedule risk, reversibility | Critical systems, tight deadlines |
|
|
48
|
+
| Scalability | Growth handling, performance at scale, extensibility | High-growth scenarios |
|
|
49
|
+
|
|
50
|
+
**Trade-Off Patterns**:
|
|
51
|
+
- **Satisficing**: Choose the first option that meets all minimum thresholds (good for low-stakes decisions)
|
|
52
|
+
- **Optimizing**: Find the best option across weighted criteria (good for high-stakes, irreversible decisions)
|
|
53
|
+
- **Elimination**: Remove options that fail any critical criterion, then compare survivors
|
|
54
|
+
|
|
55
|
+
**Confidence-Weighted Selection**:
|
|
56
|
+
- Weight evidence quality when comparing alternatives
|
|
57
|
+
- High-confidence findings override low-confidence opinions
|
|
58
|
+
- Note assumptions that, if wrong, would change the recommendation
|
|
59
|
+
|
|
60
|
+
---
|
|
61
|
+
|
|
62
|
+
### Scope Guardrail Patterns
|
|
63
|
+
|
|
64
|
+
**Purpose**: Keep brainstorming focused on HOW to solve the identified problem, not WHETHER to expand scope.
|
|
65
|
+
|
|
66
|
+
**Three-Zone Classification**:
|
|
67
|
+
- **In-scope**: Directly addresses the research question as defined
|
|
68
|
+
- **Stretch**: Related and valuable, but could be deferred to a follow-up task
|
|
69
|
+
- **Out-of-scope**: Interesting but separate concern; capture and move on
|
|
70
|
+
|
|
71
|
+
**Detection Signals for Scope Creep**:
|
|
72
|
+
- Alternatives that require solving a different problem first
|
|
73
|
+
- Trade-off analysis revealing missing prerequisites
|
|
74
|
+
- User preferences that imply a larger project than originally scoped
|
|
75
|
+
- "While we're at it" additions during dialogue
|
|
76
|
+
|
|
77
|
+
**Deferred Idea Capture**:
|
|
78
|
+
- Record every out-of-scope idea with a brief rationale for why it's worth considering later
|
|
79
|
+
- Don't dismiss ideas - acknowledge value while maintaining focus
|
|
80
|
+
- Deferred ideas feed into future research or initiative planning
|
|
81
|
+
|
|
82
|
+
---
|
|
83
|
+
|
|
84
|
+
This reference provides patterns and frameworks for the brainstorming phase. Actual implementation adapts these concepts to specific research contexts.
|
|
@@ -0,0 +1,40 @@
|
|
|
1
|
+
# Design Techniques
|
|
2
|
+
|
|
3
|
+
These techniques guide Phase 3 (High-Level Design) of the research workflow. They provide patterns for capturing and documenting design decisions in a durable, traceable format.
|
|
4
|
+
|
|
5
|
+
---
|
|
6
|
+
|
|
7
|
+
### Decision Documentation Patterns
|
|
8
|
+
|
|
9
|
+
**Purpose**: Capture design decisions in a durable, traceable format.
|
|
10
|
+
|
|
11
|
+
**Why Document Decisions**:
|
|
12
|
+
- Future developers ask "why was this done this way?"
|
|
13
|
+
- Prevents re-litigating settled questions
|
|
14
|
+
- Preserves context that would otherwise be lost
|
|
15
|
+
- Enables informed changes when assumptions change
|
|
16
|
+
|
|
17
|
+
**MADR Format Overview** (Markdown Any Decision Record):
|
|
18
|
+
- Lightweight, readable, version-control friendly
|
|
19
|
+
- Sections: Status, Context, Decision Drivers, Considered Options, Decision Outcome, Consequences
|
|
20
|
+
- Each decision is self-contained and independently understandable
|
|
21
|
+
|
|
22
|
+
**When to Create an ADR**:
|
|
23
|
+
- Decision affects system structure or component boundaries
|
|
24
|
+
- Multiple viable alternatives existed (trade-offs involved)
|
|
25
|
+
- Decision is hard to reverse later
|
|
26
|
+
- Decision might be questioned by future developers
|
|
27
|
+
|
|
28
|
+
**Lightweight vs Heavyweight**:
|
|
29
|
+
- Lightweight (1 ADR, 10-20 lines): Simple designs with 1-2 key decisions
|
|
30
|
+
- Standard (2-5 ADRs, 20-40 lines each): Most designs
|
|
31
|
+
- Heavyweight (5+ ADRs): Complex systems with many interacting decisions
|
|
32
|
+
|
|
33
|
+
**Decision Linking**:
|
|
34
|
+
- Reference solution-exploration.md for alternatives already analyzed
|
|
35
|
+
- Link from high-level-design.md decision table to individual ADR entries
|
|
36
|
+
- ADRs from research inform (but don't replace) project-level ADRs in development
|
|
37
|
+
|
|
38
|
+
---
|
|
39
|
+
|
|
40
|
+
This reference provides patterns and frameworks for the design phase. Actual implementation adapts these concepts to specific research contexts.
|