agent-bober 0.9.0 → 0.10.1

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
Files changed (68) hide show
  1. package/README.md +16 -0
  2. package/agents/bober-architect.md +495 -0
  3. package/dist/cli/commands/init.js +3 -1
  4. package/dist/cli/commands/init.js.map +1 -1
  5. package/dist/config/defaults.d.ts.map +1 -1
  6. package/dist/config/defaults.js +3 -0
  7. package/dist/config/defaults.js.map +1 -1
  8. package/dist/config/loader.d.ts.map +1 -1
  9. package/dist/config/loader.js +1 -0
  10. package/dist/config/loader.js.map +1 -1
  11. package/dist/config/schema.d.ts +13 -0
  12. package/dist/config/schema.d.ts.map +1 -1
  13. package/dist/config/schema.js +2 -0
  14. package/dist/config/schema.js.map +1 -1
  15. package/dist/mcp/tools/anchor.d.ts +2 -0
  16. package/dist/mcp/tools/anchor.d.ts.map +1 -0
  17. package/dist/mcp/tools/anchor.js +63 -0
  18. package/dist/mcp/tools/anchor.js.map +1 -0
  19. package/dist/mcp/tools/architect.d.ts +2 -0
  20. package/dist/mcp/tools/architect.d.ts.map +1 -0
  21. package/dist/mcp/tools/architect.js +78 -0
  22. package/dist/mcp/tools/architect.js.map +1 -0
  23. package/dist/mcp/tools/brownfield.d.ts +2 -0
  24. package/dist/mcp/tools/brownfield.d.ts.map +1 -0
  25. package/dist/mcp/tools/brownfield.js +65 -0
  26. package/dist/mcp/tools/brownfield.js.map +1 -0
  27. package/dist/mcp/tools/index.d.ts +18 -11
  28. package/dist/mcp/tools/index.d.ts.map +1 -1
  29. package/dist/mcp/tools/index.js +33 -11
  30. package/dist/mcp/tools/index.js.map +1 -1
  31. package/dist/mcp/tools/playwright.d.ts +2 -0
  32. package/dist/mcp/tools/playwright.d.ts.map +1 -0
  33. package/dist/mcp/tools/playwright.js +110 -0
  34. package/dist/mcp/tools/playwright.js.map +1 -0
  35. package/dist/mcp/tools/react.d.ts +2 -0
  36. package/dist/mcp/tools/react.d.ts.map +1 -0
  37. package/dist/mcp/tools/react.js +69 -0
  38. package/dist/mcp/tools/react.js.map +1 -0
  39. package/dist/mcp/tools/research.d.ts +2 -0
  40. package/dist/mcp/tools/research.d.ts.map +1 -0
  41. package/dist/mcp/tools/research.js +72 -0
  42. package/dist/mcp/tools/research.js.map +1 -0
  43. package/dist/mcp/tools/solidity.d.ts +2 -0
  44. package/dist/mcp/tools/solidity.d.ts.map +1 -0
  45. package/dist/mcp/tools/solidity.js +63 -0
  46. package/dist/mcp/tools/solidity.js.map +1 -0
  47. package/dist/orchestrator/architect-agent.d.ts +34 -0
  48. package/dist/orchestrator/architect-agent.d.ts.map +1 -0
  49. package/dist/orchestrator/architect-agent.js +243 -0
  50. package/dist/orchestrator/architect-agent.js.map +1 -0
  51. package/dist/orchestrator/pipeline.d.ts.map +1 -1
  52. package/dist/orchestrator/pipeline.js +39 -1
  53. package/dist/orchestrator/pipeline.js.map +1 -1
  54. package/dist/orchestrator/planner-agent.d.ts +1 -1
  55. package/dist/orchestrator/planner-agent.d.ts.map +1 -1
  56. package/dist/orchestrator/planner-agent.js +16 -2
  57. package/dist/orchestrator/planner-agent.js.map +1 -1
  58. package/dist/state/architect-state.d.ts +25 -0
  59. package/dist/state/architect-state.d.ts.map +1 -0
  60. package/dist/state/architect-state.js +96 -0
  61. package/dist/state/architect-state.js.map +1 -0
  62. package/dist/state/index.d.ts +1 -0
  63. package/dist/state/index.d.ts.map +1 -1
  64. package/dist/state/index.js +2 -1
  65. package/dist/state/index.js.map +1 -1
  66. package/package.json +1 -1
  67. package/skills/bober.architect/SKILL.md +418 -0
  68. package/skills/bober.research/SKILL.md +219 -0
@@ -1 +1 @@
1
- {"version":3,"file":"index.js","sourceRoot":"","sources":["../../src/state/index.ts"],"names":[],"mappings":"AAAA,OAAO,EAAE,IAAI,EAAE,MAAM,WAAW,CAAC;AACjC,OAAO,EAAE,SAAS,EAAE,MAAM,cAAc,CAAC;AAEzC,OAAO,EACL,YAAY,EACZ,YAAY,EACZ,aAAa,EACb,cAAc,GACf,MAAM,mBAAmB,CAAC;AAE3B,OAAO,EACL,QAAQ,EACR,QAAQ,EACR,cAAc,EACd,SAAS,GACV,MAAM,iBAAiB,CAAC;AAEzB,OAAO;AACL,cAAc;AACd,WAAW,EACX,kBAAkB;AAIlB,YAAY;AACZ,aAAa,EACb,WAAW,EACX,cAAc,GACf,MAAM,cAAc,CAAC;AAEtB,OAAO,EACL,YAAY,EACZ,YAAY,EACZ,YAAY,GACb,MAAM,qBAAqB,CAAC;AAE7B,OAAO,EACL,UAAU,EACV,UAAU,GACX,MAAM,mBAAmB,CAAC;AAE3B,OAAO,EACL,WAAW,EACX,WAAW,GACZ,MAAM,oBAAoB,CAAC;AAE5B,MAAM,SAAS,GAAG,QAAQ,CAAC;AAC3B,MAAM,OAAO,GAAG,CAAC,WAAW,EAAE,OAAO,EAAE,UAAU,EAAE,SAAS,EAAE,UAAU,CAAU,CAAC;AAEnF;;;GAGG;AACH,MAAM,CAAC,KAAK,UAAU,cAAc,CAAC,WAAmB;IACtD,MAAM,SAAS,GAAG,IAAI,CAAC,WAAW,EAAE,SAAS,CAAC,CAAC;IAC/C,MAAM,SAAS,CAAC,SAAS,CAAC,CAAC;IAE3B,KAAK,MAAM,GAAG,IAAI,OAAO,EAAE,CAAC;QAC1B,MAAM,SAAS,CAAC,IAAI,CAAC,SAAS,EAAE,GAAG,CAAC,CAAC,CAAC;IACxC,CAAC;AACH,CAAC"}
1
+ {"version":3,"file":"index.js","sourceRoot":"","sources":["../../src/state/index.ts"],"names":[],"mappings":"AAAA,OAAO,EAAE,IAAI,EAAE,MAAM,WAAW,CAAC;AACjC,OAAO,EAAE,SAAS,EAAE,MAAM,cAAc,CAAC;AAEzC,OAAO,EACL,YAAY,EACZ,YAAY,EACZ,aAAa,EACb,cAAc,GACf,MAAM,mBAAmB,CAAC;AAE3B,OAAO,EACL,QAAQ,EACR,QAAQ,EACR,cAAc,EACd,SAAS,GACV,MAAM,iBAAiB,CAAC;AAEzB,OAAO;AACL,cAAc;AACd,WAAW,EACX,kBAAkB;AAIlB,YAAY;AACZ,aAAa,EACb,WAAW,EACX,cAAc,GACf,MAAM,cAAc,CAAC;AAEtB,OAAO,EACL,YAAY,EACZ,YAAY,EACZ,YAAY,GACb,MAAM,qBAAqB,CAAC;AAE7B,OAAO,EACL,UAAU,EACV,UAAU,GACX,MAAM,mBAAmB,CAAC;AAE3B,OAAO,EACL,WAAW,EACX,WAAW,GACZ,MAAM,oBAAoB,CAAC;AAE5B,OAAO,EACL,gBAAgB,EAChB,gBAAgB,EAChB,OAAO,EACP,QAAQ,EACR,iBAAiB,GAClB,MAAM,sBAAsB,CAAC;AAE9B,MAAM,SAAS,GAAG,QAAQ,CAAC;AAC3B,MAAM,OAAO,GAAG,CAAC,WAAW,EAAE,OAAO,EAAE,UAAU,EAAE,SAAS,EAAE,UAAU,EAAE,cAAc,CAAU,CAAC;AAEnG;;;GAGG;AACH,MAAM,CAAC,KAAK,UAAU,cAAc,CAAC,WAAmB;IACtD,MAAM,SAAS,GAAG,IAAI,CAAC,WAAW,EAAE,SAAS,CAAC,CAAC;IAC/C,MAAM,SAAS,CAAC,SAAS,CAAC,CAAC;IAE3B,KAAK,MAAM,GAAG,IAAI,OAAO,EAAE,CAAC;QAC1B,MAAM,SAAS,CAAC,IAAI,CAAC,SAAS,EAAE,GAAG,CAAC,CAAC,CAAC;IACxC,CAAC;AACH,CAAC"}
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "agent-bober",
3
- "version": "0.9.0",
3
+ "version": "0.10.1",
4
4
  "description": "Generator-Evaluator multi-agent harness for building applications autonomously with any LLM. Supports Claude, GPT, Gemini, Ollama. Includes MCP server for Cursor/Windsurf.",
5
5
  "type": "module",
6
6
  "main": "dist/index.js",
@@ -0,0 +1,418 @@
1
+ ---
2
+ name: bober.architect
3
+ description: Run the 5-checkpoint architecture discussion flow — problem framing, approach selection, component design, integration strategy, and final assembly. Produces an architecture document with ADRs saved to .bober/architecture/.
4
+ argument-hint: <feature-or-spec-description>
5
+ handoffs:
6
+ - label: "Plan Feature"
7
+ command: /bober-plan
8
+ prompt: "Plan the architecture as sprint contracts"
9
+ - label: "Full Autonomous Run"
10
+ command: /bober-run
11
+ prompt: "Run all sprints from the plan autonomously"
12
+ ---
13
+
14
+ # bober.architect — Architecture Skill
15
+
16
+ You are running the **bober.architect** skill. Your job is to orchestrate a structured 5-checkpoint architecture discussion, producing an architecture document and Architecture Decision Records (ADRs). You do NOT write application code.
17
+
18
+ You use the **Agent tool** to spawn subagents at each checkpoint. Between checkpoints, you present output to the user and wait for review before proceeding.
19
+
20
+ ## Step 1: Read Project Configuration
21
+
22
+ Read `bober.config.json` from the project root. If it does not exist, tell the user to run `/bober-plan` first to initialize the project.
23
+
24
+ Read `.bober/principles.md` if it exists — include relevant principles in subagent prompts.
25
+
26
+ ## Step 2: Generate Architecture ID
27
+
28
+ Generate a unique architecture ID using the format: `arch-<YYYYMMDD>-<slug>`
29
+
30
+ Where `<slug>` is derived from the first 5 words of the feature description, lowercased, spaces replaced with hyphens, special characters removed.
31
+
32
+ Example: For "Payment processing service with retry logic", the ID is `arch-20260331-payment-processing-service-with-retry`.
33
+
34
+ ## Step 3: Check for Existing Research
35
+
36
+ Check `.bober/research/` for any research document related to this spec. Look for files matching `*<keyword>*-research.md` where keywords come from the feature description. If found, read it and include the research findings in the Checkpoint 1 subagent prompt as additional context.
37
+
38
+ ## Step 4: Read Agent Definition
39
+
40
+ Read `agents/bober-architect.md`. Include this as the system prompt for each checkpoint subagent.
41
+
42
+ ## Step 5: Checkpoint 1 — Problem Framing
43
+
44
+ Spawn a subagent with this prompt structure:
45
+
46
+ ```
47
+ You are the Bober Architect agent running Checkpoint 1: Problem Framing.
48
+
49
+ ## Architecture ID
50
+ <ARCH_ID>
51
+
52
+ ## Feature Description
53
+ <FEATURE_DESCRIPTION>
54
+
55
+ ## Research Context (if available)
56
+ <RESEARCH_FINDINGS or "No prior research available.">
57
+
58
+ ## Project Root
59
+ <PROJECT_ROOT>
60
+
61
+ ## Agent Definition
62
+ <BOBER_ARCHITECT_AGENT_DEFINITION>
63
+
64
+ ## Your Task
65
+
66
+ Run Checkpoint 1 (Problem Framing) from your agent definition.
67
+
68
+ Ask and self-answer the 6 Checkpoint 1 questions by reading the codebase. For each question:
69
+ 1. Use Glob/Grep/Read to find evidence in the codebase
70
+ 2. Answer the question directly based on evidence
71
+ 3. If no codebase evidence exists for a constraint, state the assumption explicitly
72
+
73
+ Produce the Problem Statement section exactly as specified in your agent definition.
74
+
75
+ ## Output Format
76
+
77
+ Respond with:
78
+ {
79
+ "checkpoint": 1,
80
+ "problemStatement": "<full markdown Problem Statement section>",
81
+ "assumptions": ["<assumption 1>", "..."],
82
+ "questionsAnswered": <number>
83
+ }
84
+ ```
85
+
86
+ Wait for the subagent to complete. Parse its output.
87
+
88
+ Present the Problem Statement to the user:
89
+
90
+ ```
91
+ ## Checkpoint 1 Complete: Problem Framing
92
+
93
+ <problemStatement content>
94
+
95
+ ---
96
+
97
+ **Review this checkpoint.** You can:
98
+ - **(A) Approve and continue** to Checkpoint 2: Approach Selection
99
+ - **(B) Challenge specific constraints** — tell me what is wrong or missing
100
+ - **(C) Restart this checkpoint** with different framing
101
+
102
+ What would you like to do?
103
+ ```
104
+
105
+ Wait for user response. If (B) or (C): respawn the subagent with the user's feedback included in the prompt. Repeat until the user approves.
106
+
107
+ ## Step 6: Checkpoint 2 — Approach Selection
108
+
109
+ Spawn a subagent with the approved Problem Statement included:
110
+
111
+ ```
112
+ You are the Bober Architect agent running Checkpoint 2: Approach Selection.
113
+
114
+ ## Architecture ID
115
+ <ARCH_ID>
116
+
117
+ ## Problem Statement (approved at Checkpoint 1)
118
+ <APPROVED_PROBLEM_STATEMENT>
119
+
120
+ ## Project Root
121
+ <PROJECT_ROOT>
122
+
123
+ ## Agent Definition
124
+ <BOBER_ARCHITECT_AGENT_DEFINITION>
125
+
126
+ ## Your Task
127
+
128
+ Run Checkpoint 2 (Approach Selection) from your agent definition.
129
+
130
+ CRITICAL RULES:
131
+ - Present exactly 2 or 3 approaches. Never 1, never 4+.
132
+ - Use the structured format from your agent definition — NOT paragraphs.
133
+ - Each approach must have: Description (1 sentence), Pros (bullets), Cons (bullets), Best-for (1 sentence).
134
+ - Select one approach with rationale citing Checkpoint 1 constraints.
135
+ - Draft an ADR for this decision (do not save yet — the orchestrator will save it).
136
+
137
+ ## Output Format
138
+
139
+ Respond with:
140
+ {
141
+ "checkpoint": 2,
142
+ "approachesSection": "<full markdown Approaches section>",
143
+ "selectedApproach": "<Approach A/B/C name>",
144
+ "selectionRationale": "<1 sentence rationale>",
145
+ "adrDraft": "<full ADR-1 markdown content>"
146
+ }
147
+ ```
148
+
149
+ Present the approaches to the user:
150
+
151
+ ```
152
+ ## Checkpoint 2 Complete: Approach Selection
153
+
154
+ <approachesSection content>
155
+
156
+ ---
157
+
158
+ **Review this checkpoint.** You can:
159
+ - **(A) Approve the selected approach** and continue to Checkpoint 3: Component Design
160
+ - **(B) Select a different approach** — tell me which one and why
161
+ - **(C) Request a different set of approaches** — describe what you want to see instead
162
+
163
+ What would you like to do?
164
+ ```
165
+
166
+ Wait for user response. Handle (B)/(C) by respawning with feedback.
167
+
168
+ ## Step 7: Checkpoint 3 — Component Design
169
+
170
+ Spawn a subagent with Problem Statement and selected approach:
171
+
172
+ ```
173
+ You are the Bober Architect agent running Checkpoint 3: Component Design.
174
+
175
+ ## Architecture ID
176
+ <ARCH_ID>
177
+
178
+ ## Problem Statement (Checkpoint 1)
179
+ <APPROVED_PROBLEM_STATEMENT>
180
+
181
+ ## Selected Approach (Checkpoint 2)
182
+ <SELECTED_APPROACH_NAME>: <SELECTION_RATIONALE>
183
+
184
+ ## Project Root
185
+ <PROJECT_ROOT>
186
+
187
+ ## Agent Definition
188
+ <BOBER_ARCHITECT_AGENT_DEFINITION>
189
+
190
+ ## Your Task
191
+
192
+ Run Checkpoint 3 (Component Design) from your agent definition.
193
+
194
+ CRITICAL RULES:
195
+ - TypeScript-style interfaces are mandatory for every component. No prose descriptions.
196
+ - Responsibility is exactly 1 sentence. No more.
197
+ - List component dependencies explicitly.
198
+ - Read the actual codebase to ground interface designs in existing patterns.
199
+ - Draft ADRs for any significant component boundary decisions.
200
+
201
+ ## Output Format
202
+
203
+ Respond with:
204
+ {
205
+ "checkpoint": 3,
206
+ "componentBreakdownSection": "<full markdown Component Breakdown section>",
207
+ "componentCount": <number>,
208
+ "adrDrafts": ["<ADR-2 markdown>", "<ADR-3 markdown if needed>"]
209
+ }
210
+ ```
211
+
212
+ Present components to user:
213
+
214
+ ```
215
+ ## Checkpoint 3 Complete: Component Design
216
+
217
+ <componentBreakdownSection content>
218
+
219
+ ---
220
+
221
+ **Review this checkpoint.** You can:
222
+ - **(A) Approve and continue** to Checkpoint 4: Integration Strategy
223
+ - **(B) Challenge component boundaries** — tell me which components need redesigning
224
+ - **(C) Request different interface signatures** — specify what should change
225
+
226
+ What would you like to do?
227
+ ```
228
+
229
+ Handle (B)/(C) by respawning with feedback.
230
+
231
+ ## Step 8: Checkpoint 4 — Integration Strategy
232
+
233
+ Spawn a subagent with all prior outputs:
234
+
235
+ ```
236
+ You are the Bober Architect agent running Checkpoint 4: Integration Strategy.
237
+
238
+ ## Architecture ID
239
+ <ARCH_ID>
240
+
241
+ ## Problem Statement (Checkpoint 1)
242
+ <APPROVED_PROBLEM_STATEMENT>
243
+
244
+ ## Selected Approach (Checkpoint 2)
245
+ <SELECTED_APPROACH>
246
+
247
+ ## Component Breakdown (Checkpoint 3)
248
+ <APPROVED_COMPONENT_BREAKDOWN>
249
+
250
+ ## Project Root
251
+ <PROJECT_ROOT>
252
+
253
+ ## Agent Definition
254
+ <BOBER_ARCHITECT_AGENT_DEFINITION>
255
+
256
+ ## Your Task
257
+
258
+ Run Checkpoint 4 (Integration Strategy) from your agent definition.
259
+
260
+ CRITICAL RULES:
261
+ - Data flow must be a concrete call chain (A → B.method(x) → C.method(y)), not an abstract description.
262
+ - Every integration risk must have: Risk, Severity (critical/high/medium/low), Mitigation.
263
+ - API Contracts table must include Error Cases column.
264
+ - Draft ADRs for key integration decisions.
265
+
266
+ ## Output Format
267
+
268
+ Respond with:
269
+ {
270
+ "checkpoint": 4,
271
+ "integrationStrategySection": "<full markdown Integration Strategy section>",
272
+ "riskCount": <number of risks identified>,
273
+ "adrDrafts": ["<ADR markdown if needed>"]
274
+ }
275
+ ```
276
+
277
+ Present integration strategy to user:
278
+
279
+ ```
280
+ ## Checkpoint 4 Complete: Integration Strategy
281
+
282
+ <integrationStrategySection content>
283
+
284
+ ---
285
+
286
+ **Review this checkpoint.** You can:
287
+ - **(A) Approve and continue** to Checkpoint 5: Final Assembly
288
+ - **(B) Challenge the data flow** — describe what is wrong or missing
289
+ - **(C) Add integration risks** — tell me what risks were missed
290
+
291
+ What would you like to do?
292
+ ```
293
+
294
+ Handle (B)/(C) by respawning with feedback.
295
+
296
+ ## Step 9: Checkpoint 5 — Final Assembly
297
+
298
+ Spawn a subagent to compile the complete architecture document:
299
+
300
+ ```
301
+ You are the Bober Architect agent running Checkpoint 5: Final Assembly.
302
+
303
+ ## Architecture ID
304
+ <ARCH_ID>
305
+
306
+ ## Feature Description
307
+ <FEATURE_DESCRIPTION>
308
+
309
+ ## All Checkpoint Outputs
310
+
311
+ ### Problem Statement (Checkpoint 1)
312
+ <APPROVED_PROBLEM_STATEMENT>
313
+
314
+ ### Approaches (Checkpoint 2)
315
+ <APPROVED_APPROACHES_SECTION>
316
+
317
+ ### Component Breakdown (Checkpoint 3)
318
+ <APPROVED_COMPONENT_BREAKDOWN>
319
+
320
+ ### Integration Strategy (Checkpoint 4)
321
+ <APPROVED_INTEGRATION_STRATEGY>
322
+
323
+ ## ADR Drafts
324
+ <ALL_ADR_DRAFTS from prior checkpoints>
325
+
326
+ ## Project Root
327
+ <PROJECT_ROOT>
328
+
329
+ ## Agent Definition
330
+ <BOBER_ARCHITECT_AGENT_DEFINITION>
331
+
332
+ ## Your Task
333
+
334
+ Compile the complete architecture document per the output format in your agent definition.
335
+
336
+ CRITICAL RULES:
337
+ - The complete document MUST NOT exceed 500 lines.
338
+ - Each ADR MUST NOT exceed 50 lines.
339
+ - Executive Summary is exactly 3-5 sentences — no filler.
340
+ - Number ADRs sequentially: ADR-1, ADR-2, etc.
341
+ - Include ALL 10 required sections in the exact order specified.
342
+ - If content exceeds 500 lines, distill — remove filler, shorten descriptions, combine redundant sections.
343
+ - Save the architecture document to .bober/architecture/<id>-architecture.md
344
+ - Save each ADR to .bober/architecture/<id>-adr-<N>.md (separate files)
345
+ - Ensure .bober/architecture/ directory exists before writing.
346
+
347
+ ## Required Document Sections (in this order)
348
+ 1. Executive Summary
349
+ 2. Problem Statement
350
+ 3. System Overview
351
+ 4. Component Breakdown
352
+ 5. Data Model
353
+ 6. API Contracts
354
+ 7. Integration Strategy
355
+ 8. Architecture Decision Records
356
+ 9. Risk Assessment
357
+ 10. Open Questions
358
+
359
+ ## Output Format
360
+
361
+ After saving all files, respond with:
362
+ {
363
+ "checkpoint": 5,
364
+ "architectureId": "<ARCH_ID>",
365
+ "documentPath": ".bober/architecture/<id>-architecture.md",
366
+ "adrPaths": [".bober/architecture/<id>-adr-1.md", "..."],
367
+ "componentCount": <number>,
368
+ "decisionCount": <number of ADRs>,
369
+ "documentLineCount": <actual line count>,
370
+ "summary": "<2-3 sentence summary of the architecture>"
371
+ }
372
+ ```
373
+
374
+ Wait for the subagent to complete.
375
+
376
+ ## Step 10: Save History and Present Final Output
377
+
378
+ Append to `.bober/history.jsonl`:
379
+
380
+ ```json
381
+ {"event":"architecture-completed","architectureId":"...","feature":"...","componentCount":N,"decisionCount":N,"timestamp":"..."}
382
+ ```
383
+
384
+ Present the final output to the user:
385
+
386
+ ```
387
+ ## Architecture Complete: <feature description>
388
+
389
+ **Architecture ID:** <arch_id>
390
+ **Document:** .bober/architecture/<id>-architecture.md
391
+ **ADRs:** <list each ADR path>
392
+
393
+ ### Summary
394
+ <summary from Checkpoint 5>
395
+
396
+ ### Components (<count>)
397
+ <list component names>
398
+
399
+ ### Decisions (<count> ADRs)
400
+ <list ADR titles>
401
+
402
+ ### Next Steps
403
+ - Run `/bober-plan <feature-description>` to decompose this architecture into sprint contracts
404
+ - Run `/bober-sprint` to start building
405
+ ```
406
+
407
+ ## Error Handling
408
+
409
+ - If a subagent produces invalid JSON: retry once with the same prompt, then present the raw output to the user and ask them to proceed manually
410
+ - If the architecture directory cannot be created: report the filesystem error clearly
411
+ - If the user rejects a checkpoint 3+ times: ask if they want to restart from Checkpoint 1 with different framing
412
+ - If the feature description argument is empty: tell the user the skill requires a feature description argument
413
+
414
+ ## Important: Checkpoint Isolation
415
+
416
+ Each checkpoint subagent receives only the outputs from PRIOR approved checkpoints — not the raw outputs of ongoing checkpoints. This prevents circular reasoning and ensures each checkpoint builds on approved decisions.
417
+
418
+ The skill (this document) is the coordinator. Subagents produce; the skill assembles.
@@ -0,0 +1,219 @@
1
+ ---
2
+ name: bober.research
3
+ description: Run the two-phase research process for a feature — generates exploration questions then explores the codebase to produce a factual research document.
4
+ argument-hint: <feature-description>
5
+ handoffs:
6
+ - label: "Plan Feature"
7
+ command: /bober-plan
8
+ prompt: "Plan the researched feature"
9
+ ---
10
+
11
+ # bober.research — Research Skill
12
+
13
+ You are running the **bober.research** skill. Your job is to orchestrate the two-phase research process for a feature description, producing a factual codebase research document that can inform planning.
14
+
15
+ You do NOT implement code. You do NOT plan sprints. You spawn subagents using the **Agent tool** and coordinate their outputs.
16
+
17
+ ## Step 1: Read Project Configuration
18
+
19
+ Read `bober.config.json` from the project root. If it does not exist, tell the user to run `/bober-plan` first to initialize the project.
20
+
21
+ Read `.bober/principles.md` if it exists. Include it in subagent prompts.
22
+
23
+ ## Step 2: Generate a Research ID
24
+
25
+ Generate a unique research ID using the format: `research-<YYYYMMDD>-<slug>`
26
+
27
+ Where `<slug>` is derived from the first 5 words of the feature description, lowercased, spaces replaced with hyphens, special characters removed.
28
+
29
+ Example: For "Add user authentication with email", the slug is `add-user-authentication-with-email`, giving ID `research-20260331-add-user-authentication-with-email`.
30
+
31
+ ## Step 3: Phase 1 — Question Generation
32
+
33
+ Spawn a subagent using the Agent tool with this prompt structure:
34
+
35
+ ```
36
+ You are the Bober Researcher agent, Phase 1: Question Generation.
37
+
38
+ ## Your Task
39
+
40
+ Given the feature description below, generate 5–8 specific exploration questions that will guide codebase exploration. These questions will be passed to a SEPARATE agent that has NO knowledge of the feature — so your questions must be self-contained and answerable by reading the codebase.
41
+
42
+ ## Rules
43
+
44
+ - Generate ONLY questions, no preamble, no explanation
45
+ - Questions must be specific to what a developer would need to explore
46
+ - Questions must be answerable by reading files (not by building or running code)
47
+ - Do NOT suggest implementations or make recommendations
48
+ - Do NOT explore the codebase yourself — just generate questions
49
+
50
+ ## Feature Description
51
+
52
+ <FEATURE_DESCRIPTION>
53
+
54
+ ## Project Root
55
+
56
+ <PROJECT_ROOT>
57
+
58
+ ## Agent Definition
59
+
60
+ <BOBER_RESEARCHER_SYSTEM_PROMPT>
61
+
62
+ ## Output Format
63
+
64
+ Respond with ONLY a JSON array of question strings. No markdown fences, no explanation.
65
+ ```
66
+
67
+ Wait for the Phase 1 subagent to complete. Parse its output as a JSON array of strings.
68
+
69
+ **If Phase 1 fails or produces fewer than 3 questions:** Log the error and abort. Tell the user what went wrong.
70
+
71
+ ## Step 4: Phase 2 — Codebase Exploration
72
+
73
+ Spawn a second subagent using the Agent tool. This subagent receives ONLY the questions, NOT the feature description. This isolation is mandatory.
74
+
75
+ Use this prompt structure:
76
+
77
+ ```
78
+ You are the Bober Researcher agent, Phase 2: Codebase Exploration.
79
+
80
+ ## Your Task
81
+
82
+ You have been given a list of exploration questions. Your job is to explore the codebase and answer each question with factual findings. You do NOT know what feature is being built — this is intentional to prevent bias in your research.
83
+
84
+ ## Exploration Questions
85
+
86
+ <QUESTIONS_FROM_PHASE_1>
87
+
88
+ ## Research ID
89
+
90
+ <RESEARCH_ID>
91
+
92
+ ## Project Root
93
+
94
+ <PROJECT_ROOT>
95
+
96
+ ## Agent Definition
97
+
98
+ <BOBER_RESEARCHER_SYSTEM_PROMPT>
99
+
100
+ ## Instructions
101
+
102
+ 1. Work through each question systematically using Read, Grep, and Glob tools
103
+ 2. Record exact file paths and line numbers for every finding
104
+ 3. Produce a factual research document with ONLY these sections:
105
+ - Architecture Overview
106
+ - Existing Patterns (with file:line refs)
107
+ - Key Files
108
+ - Integration Points
109
+ - Test Coverage
110
+ - Risk Areas
111
+ 4. No recommendations. No opinions. Facts only.
112
+
113
+ ## Output Format
114
+
115
+ Respond with a JSON object:
116
+ {
117
+ "researchId": "<research ID>",
118
+ "sections": {
119
+ "architectureOverview": "<string>",
120
+ "existingPatterns": "<string>",
121
+ "keyFiles": "<string>",
122
+ "integrationPoints": "<string>",
123
+ "testCoverage": "<string>",
124
+ "riskAreas": "<string>"
125
+ },
126
+ "filesExplored": ["<list of file paths you read>"],
127
+ "questionsAnswered": <number>
128
+ }
129
+
130
+ No markdown fences, no explanation. Only the JSON object.
131
+ ```
132
+
133
+ Wait for the Phase 2 subagent to complete.
134
+
135
+ ## Step 5: Save Research Document
136
+
137
+ Save the research output to `.bober/research/<researchId>-research.md` using this markdown format:
138
+
139
+ ```markdown
140
+ # Research: <feature description (first 80 chars)>
141
+
142
+ **Research ID:** <researchId>
143
+ **Generated:** <ISO-8601 timestamp>
144
+ **Questions Explored:** <count>
145
+ **Files Explored:** <count>
146
+
147
+ ---
148
+
149
+ ## Architecture Overview
150
+
151
+ <architectureOverview>
152
+
153
+ ## Existing Patterns
154
+
155
+ <existingPatterns>
156
+
157
+ ## Key Files
158
+
159
+ <keyFiles>
160
+
161
+ ## Integration Points
162
+
163
+ <integrationPoints>
164
+
165
+ ## Test Coverage
166
+
167
+ <testCoverage>
168
+
169
+ ## Risk Areas
170
+
171
+ <riskAreas>
172
+
173
+ ---
174
+
175
+ *Generated by bober.research — factual findings only, no implementation recommendations.*
176
+ ```
177
+
178
+ Ensure the `.bober/research/` directory exists before writing. Create it if needed.
179
+
180
+ Also append to `.bober/history.jsonl`:
181
+ ```json
182
+ {"event":"research-completed","researchId":"...","feature":"...","questionsGenerated":N,"filesExplored":N,"timestamp":"..."}
183
+ ```
184
+
185
+ ## Step 6: Output Summary
186
+
187
+ Present a summary to the user:
188
+
189
+ ```
190
+ ## Research Complete: <feature description>
191
+
192
+ **Research ID:** <researchId>
193
+ **Saved to:** .bober/research/<researchId>-research.md
194
+
195
+ ### Questions Explored (<count>)
196
+ 1. <question 1>
197
+ 2. <question 2>
198
+ ...
199
+
200
+ ### Files Explored (<count>)
201
+ <list key files>
202
+
203
+ ### Key Findings
204
+ <3-5 bullet points with the most important factual findings>
205
+
206
+ ### Next Steps
207
+ Run `/bober-plan <feature-description>` to use this research to create a plan.
208
+ ```
209
+
210
+ ## Error Handling
211
+
212
+ - If Phase 1 produces invalid JSON: retry once with the same prompt, then abort
213
+ - If Phase 2 produces invalid JSON: save whatever text was produced as a raw research note, log a warning, but do NOT fail silently
214
+ - If the research directory cannot be created: report the filesystem error clearly
215
+ - If the feature description argument is empty: tell the user the skill requires a feature description argument
216
+
217
+ ## Important: Two-Phase Isolation
218
+
219
+ The feature description MUST NOT be passed to the Phase 2 subagent. This is the entire point of the two-phase process. Phase 2's research is unbiased because the exploring agent does not know what is being built — it only knows what to look for.