@chorus-aidlc/chorus-openclaw-plugin 0.3.1 → 0.4.0
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 +81 -11
- package/openclaw.plugin.json +1 -0
- package/package.json +2 -1
- package/skills/chorus/SKILL.md +396 -0
- package/skills/develop/SKILL.md +290 -0
- package/skills/idea/SKILL.md +306 -0
- package/skills/proposal/SKILL.md +399 -0
- package/skills/quick-dev/SKILL.md +174 -0
- package/skills/review/SKILL.md +282 -0
- package/src/commands.ts +23 -0
- package/src/tools/admin-tools.ts +14 -5
- package/src/tools/common-tools.ts +54 -25
- package/src/tools/dev-tools.ts +12 -4
- package/src/tools/pm-tools.ts +38 -17
|
@@ -0,0 +1,290 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: develop
|
|
3
|
+
description: Chorus Development workflow — claim tasks, report work, and submit for verification.
|
|
4
|
+
metadata:
|
|
5
|
+
openclaw:
|
|
6
|
+
emoji: "🔨"
|
|
7
|
+
---
|
|
8
|
+
|
|
9
|
+
# Develop Skill
|
|
10
|
+
|
|
11
|
+
This skill covers the **Development** stage of the AI-DLC workflow: claiming Tasks, writing code, reporting progress, and submitting for verification.
|
|
12
|
+
|
|
13
|
+
OpenClaw operates as a **single-agent model with SSE wake** — there are no sessions, sub-agents, or Agent Teams. The plugin listens for SSE notification events and wakes the agent when work arrives.
|
|
14
|
+
|
|
15
|
+
---
|
|
16
|
+
|
|
17
|
+
## Overview
|
|
18
|
+
|
|
19
|
+
Developer Agents take Tasks created by PM Agents (via `/proposal`) and turn them into working code. Each task follows this lifecycle:
|
|
20
|
+
|
|
21
|
+
```
|
|
22
|
+
open --> assigned --> in_progress --> to_verify --> done (after admin verification)
|
|
23
|
+
```
|
|
24
|
+
|
|
25
|
+
The agent workflow:
|
|
26
|
+
|
|
27
|
+
```
|
|
28
|
+
claim --> in_progress --> report work --> self-check AC --> submit for verify --> Admin /review
|
|
29
|
+
```
|
|
30
|
+
|
|
31
|
+
---
|
|
32
|
+
|
|
33
|
+
## Task Status Lifecycle
|
|
34
|
+
|
|
35
|
+
| Status | Meaning |
|
|
36
|
+
|--------|---------|
|
|
37
|
+
| `open` | Available for claiming |
|
|
38
|
+
| `assigned` | Claimed by an agent, not yet started |
|
|
39
|
+
| `in_progress` | Active development |
|
|
40
|
+
| `to_verify` | Submitted for admin verification |
|
|
41
|
+
| `done` | Verified by admin — unblocks downstream tasks |
|
|
42
|
+
| `closed` | Closed by admin (also unblocks downstream) |
|
|
43
|
+
|
|
44
|
+
> **Important:** `to_verify` does NOT unblock downstream tasks — only `done` or `closed` does.
|
|
45
|
+
|
|
46
|
+
---
|
|
47
|
+
|
|
48
|
+
## Tools
|
|
49
|
+
|
|
50
|
+
**Task Lifecycle:**
|
|
51
|
+
|
|
52
|
+
| Tool | Purpose |
|
|
53
|
+
|------|---------|
|
|
54
|
+
| `chorus_claim_task` | Claim an open task (open -> assigned) |
|
|
55
|
+
| `chorus_update_task` | Update task status (in_progress / to_verify) or edit fields (title, description, priority, dependencies) |
|
|
56
|
+
| `chorus_submit_for_verify` | Submit task for admin verification with summary |
|
|
57
|
+
|
|
58
|
+
**Work Reporting:**
|
|
59
|
+
|
|
60
|
+
| Tool | Purpose |
|
|
61
|
+
|------|---------|
|
|
62
|
+
| `chorus_report_work` | Report progress or completion (writes comment + records activity, with optional status update) |
|
|
63
|
+
|
|
64
|
+
**Acceptance Criteria:**
|
|
65
|
+
|
|
66
|
+
| Tool | Purpose |
|
|
67
|
+
|------|---------|
|
|
68
|
+
| `chorus_report_criteria_self_check` | Report self-check results (passed/failed + optional evidence) on structured acceptance criteria |
|
|
69
|
+
|
|
70
|
+
**Shared tools** (checkin, query, comment, search, notifications): see `/chorus`
|
|
71
|
+
|
|
72
|
+
---
|
|
73
|
+
|
|
74
|
+
## Workflow
|
|
75
|
+
|
|
76
|
+
### Step 1: Check In
|
|
77
|
+
|
|
78
|
+
```
|
|
79
|
+
chorus_checkin()
|
|
80
|
+
```
|
|
81
|
+
|
|
82
|
+
Review your persona, current assignments, and pending work counts.
|
|
83
|
+
|
|
84
|
+
### Step 2: Find Work
|
|
85
|
+
|
|
86
|
+
```
|
|
87
|
+
chorus_get_available_tasks({ projectUuid: "<project-uuid>" })
|
|
88
|
+
```
|
|
89
|
+
|
|
90
|
+
Or check existing assignments:
|
|
91
|
+
|
|
92
|
+
```
|
|
93
|
+
chorus_get_my_assignments()
|
|
94
|
+
```
|
|
95
|
+
|
|
96
|
+
### Step 3: Claim a Task
|
|
97
|
+
|
|
98
|
+
```
|
|
99
|
+
chorus_get_task({ taskUuid: "<task-uuid>" }) # Review first
|
|
100
|
+
chorus_claim_task({ taskUuid: "<task-uuid>" })
|
|
101
|
+
```
|
|
102
|
+
|
|
103
|
+
Check: description, acceptance criteria, priority, story points, related proposal/documents.
|
|
104
|
+
|
|
105
|
+
### Step 4: Gather Context
|
|
106
|
+
|
|
107
|
+
Each task and proposal includes a `commentCount` field — use it to decide which entities have discussions worth reading.
|
|
108
|
+
|
|
109
|
+
1. **Read the task** and identify dependencies:
|
|
110
|
+
```
|
|
111
|
+
chorus_get_task({ taskUuid: "<task-uuid>" })
|
|
112
|
+
```
|
|
113
|
+
Pay attention to `dependsOn` (upstream tasks) and `commentCount`.
|
|
114
|
+
|
|
115
|
+
2. **Read task comments** (contains previous work reports, progress, feedback):
|
|
116
|
+
```
|
|
117
|
+
chorus_get_comments({ targetType: "task", targetUuid: "<task-uuid>" })
|
|
118
|
+
```
|
|
119
|
+
|
|
120
|
+
3. **Review upstream dependency tasks** — your work likely builds on theirs:
|
|
121
|
+
```
|
|
122
|
+
chorus_get_task({ taskUuid: "<dependency-task-uuid>" })
|
|
123
|
+
chorus_get_comments({ targetType: "task", targetUuid: "<dependency-task-uuid>" })
|
|
124
|
+
```
|
|
125
|
+
Look for: files created, API contracts, interfaces, trade-offs.
|
|
126
|
+
|
|
127
|
+
4. **Read the originating proposal** for design intent:
|
|
128
|
+
```
|
|
129
|
+
chorus_get_proposal({ proposalUuid: "<proposal-uuid>" })
|
|
130
|
+
```
|
|
131
|
+
|
|
132
|
+
5. **Read project documents** (PRD, tech design, ADR):
|
|
133
|
+
```
|
|
134
|
+
chorus_get_documents({ projectUuid: "<project-uuid>" })
|
|
135
|
+
```
|
|
136
|
+
|
|
137
|
+
### Step 5: Start Working
|
|
138
|
+
|
|
139
|
+
```
|
|
140
|
+
chorus_update_task({ taskUuid: "<task-uuid>", status: "in_progress" })
|
|
141
|
+
```
|
|
142
|
+
|
|
143
|
+
> **Dependency enforcement**: If this task has unresolved dependencies (dependsOn tasks not in `done` or `closed`), the call will be rejected with detailed blocker info. Use `chorus_get_unblocked_tasks` to find tasks you can start now.
|
|
144
|
+
|
|
145
|
+
### Step 6: Report Progress
|
|
146
|
+
|
|
147
|
+
Report periodically with `chorus_report_work`. Include:
|
|
148
|
+
- What was completed
|
|
149
|
+
- Files created or modified
|
|
150
|
+
- Git commits and PRs
|
|
151
|
+
- Current status / remaining work
|
|
152
|
+
- Blockers or questions
|
|
153
|
+
|
|
154
|
+
```
|
|
155
|
+
chorus_report_work({
|
|
156
|
+
taskUuid: "<task-uuid>",
|
|
157
|
+
report: "Progress:\n- Created src/services/auth.service.ts\n- Commit: abc1234\n- Remaining: unit tests"
|
|
158
|
+
})
|
|
159
|
+
```
|
|
160
|
+
|
|
161
|
+
Report with status update when complete:
|
|
162
|
+
```
|
|
163
|
+
chorus_report_work({
|
|
164
|
+
taskUuid: "<task-uuid>",
|
|
165
|
+
report: "All implementation complete:\n- Files: ...\n- PR: https://github.com/org/repo/pull/42\n- All tests passing",
|
|
166
|
+
status: "to_verify"
|
|
167
|
+
})
|
|
168
|
+
```
|
|
169
|
+
|
|
170
|
+
### Step 7: Self-Check Acceptance Criteria
|
|
171
|
+
|
|
172
|
+
Before submitting, check structured acceptance criteria:
|
|
173
|
+
|
|
174
|
+
```
|
|
175
|
+
task = chorus_get_task({ taskUuid: "<task-uuid>" })
|
|
176
|
+
|
|
177
|
+
# If task.acceptanceCriteriaItems is non-empty:
|
|
178
|
+
chorus_report_criteria_self_check({
|
|
179
|
+
taskUuid: "<task-uuid>",
|
|
180
|
+
criteria: [
|
|
181
|
+
{ uuid: "<criterion-uuid>", devStatus: "passed", devEvidence: "Unit tests cover this" },
|
|
182
|
+
{ uuid: "<criterion-uuid>", devStatus: "passed", devEvidence: "Verified manually" }
|
|
183
|
+
]
|
|
184
|
+
})
|
|
185
|
+
```
|
|
186
|
+
|
|
187
|
+
> For **required** criteria, keep working until you can self-check as `passed`. Only use `failed` for **optional** criteria that are out of scope.
|
|
188
|
+
|
|
189
|
+
### Step 8: Submit for Verification
|
|
190
|
+
|
|
191
|
+
```
|
|
192
|
+
chorus_submit_for_verify({
|
|
193
|
+
taskUuid: "<task-uuid>",
|
|
194
|
+
summary: "Implemented auth feature:\n- Added login/logout endpoints\n- JWT middleware\n- 95% test coverage\n- All AC self-checked (3/3 passed)"
|
|
195
|
+
})
|
|
196
|
+
```
|
|
197
|
+
|
|
198
|
+
### Step 9: Handle Review Feedback
|
|
199
|
+
|
|
200
|
+
If the task is reopened (verification failed), **all acceptance criteria are reset to pending**.
|
|
201
|
+
|
|
202
|
+
1. Check feedback:
|
|
203
|
+
```
|
|
204
|
+
chorus_get_task({ taskUuid: "<task-uuid>" })
|
|
205
|
+
chorus_get_comments({ targetType: "task", targetUuid: "<task-uuid>" })
|
|
206
|
+
```
|
|
207
|
+
2. Fix issues, report fixes, re-self-check AC, and resubmit.
|
|
208
|
+
|
|
209
|
+
### Step 10: Task Complete
|
|
210
|
+
|
|
211
|
+
Once Admin verifies (status: `done`), move to the next available task (back to Step 2).
|
|
212
|
+
|
|
213
|
+
---
|
|
214
|
+
|
|
215
|
+
## SSE Wake Events
|
|
216
|
+
|
|
217
|
+
The OpenClaw plugin listens for SSE notification events and automatically wakes the agent when relevant events occur. Developer-relevant events:
|
|
218
|
+
|
|
219
|
+
| SSE Event | Trigger | Agent Action |
|
|
220
|
+
|-----------|---------|--------------|
|
|
221
|
+
| `task_assigned` | A task is assigned to you via `chorus_pm_assign_task` | Wake and start work on the task |
|
|
222
|
+
| `task_reopened` | Admin reopened a task for rework | Wake, read feedback, fix issues |
|
|
223
|
+
| `task_verified` | Admin verified a task as done | Check if downstream tasks are unblocked |
|
|
224
|
+
|
|
225
|
+
### autoStart Config
|
|
226
|
+
|
|
227
|
+
When `autoStart` is enabled in the plugin config, the agent will automatically claim assigned tasks before waking. When disabled, the agent wakes with a notification but must manually claim.
|
|
228
|
+
|
|
229
|
+
---
|
|
230
|
+
|
|
231
|
+
## Task Dependencies (DAG)
|
|
232
|
+
|
|
233
|
+
Tasks can depend on other tasks, forming a directed acyclic graph (DAG).
|
|
234
|
+
|
|
235
|
+
- `chorus_update_task(status: "in_progress")` is **rejected** if any `dependsOn` task is not `done` or `closed`
|
|
236
|
+
- Use `chorus_get_unblocked_tasks` to find tasks with all dependencies resolved
|
|
237
|
+
- Use `addDependsOn` / `removeDependsOn` in `chorus_update_task` to manage dependencies
|
|
238
|
+
|
|
239
|
+
**Sequential execution**: When multiple tasks have dependencies, work them in order — finish upstream tasks first, wait for admin verification (`done`), then start downstream tasks.
|
|
240
|
+
|
|
241
|
+
---
|
|
242
|
+
|
|
243
|
+
## Work Report Best Practices
|
|
244
|
+
|
|
245
|
+
**Good report (enables continuity):**
|
|
246
|
+
```
|
|
247
|
+
Implemented password reset flow:
|
|
248
|
+
|
|
249
|
+
Files created/modified:
|
|
250
|
+
- src/services/auth.service.ts (new)
|
|
251
|
+
- src/app/api/auth/reset/route.ts (new)
|
|
252
|
+
- tests/auth/reset.test.ts (new)
|
|
253
|
+
|
|
254
|
+
Git:
|
|
255
|
+
- Commit: a1b2c3d "feat: password reset flow"
|
|
256
|
+
- PR: https://github.com/org/repo/pull/15
|
|
257
|
+
|
|
258
|
+
Implementation details:
|
|
259
|
+
- POST /api/auth/reset-request: sends email with token
|
|
260
|
+
- Token expires after 1 hour, single-use
|
|
261
|
+
- Rate limiting: 3 requests/hour/email
|
|
262
|
+
- 12 new tests, all passing
|
|
263
|
+
|
|
264
|
+
Acceptance criteria:
|
|
265
|
+
- [x] User can request reset via email
|
|
266
|
+
- [x] Reset link expires after 1 hour
|
|
267
|
+
- [x] Rate limiting prevents abuse
|
|
268
|
+
```
|
|
269
|
+
|
|
270
|
+
**Bad report:** `Done.`
|
|
271
|
+
|
|
272
|
+
---
|
|
273
|
+
|
|
274
|
+
## Tips
|
|
275
|
+
|
|
276
|
+
- **Read task comments first** — they contain previous work reports for continuity
|
|
277
|
+
- **Check upstream dependencies** — read `dependsOn` tasks and their comments for interfaces/APIs
|
|
278
|
+
- **Read the originating proposal** — understand design rationale and task DAG
|
|
279
|
+
- **Use `commentCount`** — skip fetching comments on entities with count 0
|
|
280
|
+
- Report progress frequently — include file paths, commits, and PRs
|
|
281
|
+
- Write detailed submit summaries — Admin needs them to verify
|
|
282
|
+
- If blocked, add a comment explaining why
|
|
283
|
+
- One task at a time: finish before claiming another
|
|
284
|
+
|
|
285
|
+
---
|
|
286
|
+
|
|
287
|
+
## Next
|
|
288
|
+
|
|
289
|
+
- After submitting for verification, an Admin reviews using `/review`
|
|
290
|
+
- For platform overview and shared tools, see `/chorus`
|
|
@@ -0,0 +1,306 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: idea
|
|
3
|
+
description: Chorus Idea workflow — claim ideas, run elaboration, and prepare for proposal.
|
|
4
|
+
metadata:
|
|
5
|
+
openclaw:
|
|
6
|
+
emoji: "💡"
|
|
7
|
+
---
|
|
8
|
+
|
|
9
|
+
# Idea Skill
|
|
10
|
+
|
|
11
|
+
This skill covers the **Ideation** stage of the AI-DLC workflow: claiming Ideas, running structured elaboration rounds to clarify requirements, and preparing for Proposal creation.
|
|
12
|
+
|
|
13
|
+
---
|
|
14
|
+
|
|
15
|
+
## Overview
|
|
16
|
+
|
|
17
|
+
Ideas are the starting point of the AI-DLC pipeline. Humans (or Admin agents) create Ideas describing what they need. The PM Agent claims an Idea, runs elaboration to clarify requirements, and then moves on to `/proposal` to create a Proposal with document and task drafts.
|
|
18
|
+
|
|
19
|
+
### Idea Lifecycle
|
|
20
|
+
|
|
21
|
+
```
|
|
22
|
+
open --> elaborating --> proposal_created --> completed
|
|
23
|
+
\--> closed
|
|
24
|
+
```
|
|
25
|
+
|
|
26
|
+
| Status | Meaning |
|
|
27
|
+
|--------|---------|
|
|
28
|
+
| `open` | Idea is available for an agent to claim |
|
|
29
|
+
| `elaborating` | An agent has claimed the idea and is gathering requirements |
|
|
30
|
+
| `proposal_created` | A Proposal has been created from this idea |
|
|
31
|
+
| `completed` | The resulting Proposal was approved and work is done |
|
|
32
|
+
| `closed` | Idea was closed without implementation |
|
|
33
|
+
|
|
34
|
+
Claiming an idea automatically transitions it from `open` to `elaborating`.
|
|
35
|
+
|
|
36
|
+
---
|
|
37
|
+
|
|
38
|
+
## Tools
|
|
39
|
+
|
|
40
|
+
**Idea Management:**
|
|
41
|
+
|
|
42
|
+
| Tool | Purpose |
|
|
43
|
+
|------|---------|
|
|
44
|
+
| `chorus_claim_idea` | Claim an open idea (open -> elaborating) |
|
|
45
|
+
| `chorus_get_available_ideas` | List open ideas in a project available to claim |
|
|
46
|
+
| `chorus_get_idea` | Get detailed information for a single idea |
|
|
47
|
+
| `chorus_get_ideas` | List ideas in a project with optional status filter |
|
|
48
|
+
| `chorus_pm_create_idea` | Create a new idea in a project |
|
|
49
|
+
| `chorus_move_idea` | Move an idea to a different project (also moves linked draft/pending proposals) |
|
|
50
|
+
|
|
51
|
+
**Requirements Elaboration:**
|
|
52
|
+
|
|
53
|
+
| Tool | Purpose |
|
|
54
|
+
|------|---------|
|
|
55
|
+
| `chorus_start_elaboration` | Start an elaboration round with structured questions |
|
|
56
|
+
| `chorus_validate_elaboration` | Validate answers — empty issues = resolved, with issues = follow-up round |
|
|
57
|
+
| `chorus_answer_elaboration` | Submit answers for an elaboration round |
|
|
58
|
+
| `chorus_get_elaboration` | Get full elaboration state (all rounds, questions, answers) |
|
|
59
|
+
|
|
60
|
+
**Shared tools** (checkin, query, comment, search, notifications): see `/chorus`
|
|
61
|
+
|
|
62
|
+
---
|
|
63
|
+
|
|
64
|
+
## SSE Wake Events (OpenClaw-Specific)
|
|
65
|
+
|
|
66
|
+
OpenClaw is a single-agent model with SSE-driven wake. The following notification events trigger the agent to wake and act:
|
|
67
|
+
|
|
68
|
+
| SSE Event | Trigger | Agent Action |
|
|
69
|
+
|-----------|---------|--------------|
|
|
70
|
+
| `idea_claimed` | An idea is assigned to you | Wake, review the idea with `chorus_get_idea`, claim it if not auto-claimed |
|
|
71
|
+
| `elaboration_requested` | Elaboration round started on an idea you own | Wake, review questions with `chorus_get_elaboration` |
|
|
72
|
+
| `elaboration_answered` | Answers submitted for your elaboration round | Wake, review answers, validate or create follow-up round |
|
|
73
|
+
|
|
74
|
+
When an SSE event fires, the plugin's event router fetches the notification details and triggers the agent with context (ideaUuid, projectUuid, action). You do not need to poll — work arrives via these events.
|
|
75
|
+
|
|
76
|
+
---
|
|
77
|
+
|
|
78
|
+
## Workflow
|
|
79
|
+
|
|
80
|
+
### Step 1: Check In
|
|
81
|
+
|
|
82
|
+
```
|
|
83
|
+
chorus_checkin()
|
|
84
|
+
```
|
|
85
|
+
|
|
86
|
+
Review your persona, current assignments, and pending work counts.
|
|
87
|
+
|
|
88
|
+
### Step 2: Find Work
|
|
89
|
+
|
|
90
|
+
```
|
|
91
|
+
chorus_get_available_ideas({ projectUuid: "<project-uuid>" })
|
|
92
|
+
```
|
|
93
|
+
|
|
94
|
+
Or check existing assignments:
|
|
95
|
+
|
|
96
|
+
```
|
|
97
|
+
chorus_get_my_assignments()
|
|
98
|
+
```
|
|
99
|
+
|
|
100
|
+
### Step 3: Claim an Idea
|
|
101
|
+
|
|
102
|
+
Claiming automatically transitions the Idea to `elaborating` status:
|
|
103
|
+
|
|
104
|
+
```
|
|
105
|
+
chorus_claim_idea({ ideaUuid: "<idea-uuid>" })
|
|
106
|
+
```
|
|
107
|
+
|
|
108
|
+
### Step 4: Gather Context
|
|
109
|
+
|
|
110
|
+
Before elaborating, understand the full picture:
|
|
111
|
+
|
|
112
|
+
1. **Read the idea in detail:**
|
|
113
|
+
```
|
|
114
|
+
chorus_get_idea({ ideaUuid: "<idea-uuid>" })
|
|
115
|
+
```
|
|
116
|
+
|
|
117
|
+
2. **Read existing project documents** (for context, tech stack, conventions):
|
|
118
|
+
```
|
|
119
|
+
chorus_get_documents({ projectUuid: "<project-uuid>" })
|
|
120
|
+
chorus_get_document({ documentUuid: "<doc-uuid>" })
|
|
121
|
+
```
|
|
122
|
+
|
|
123
|
+
3. **Review past proposals** (to understand patterns and standards):
|
|
124
|
+
```
|
|
125
|
+
chorus_get_proposals({ projectUuid: "<project-uuid>", status: "approved" })
|
|
126
|
+
```
|
|
127
|
+
|
|
128
|
+
4. **Check existing tasks** (to avoid duplication):
|
|
129
|
+
```
|
|
130
|
+
chorus_list_tasks({ projectUuid: "<project-uuid>" })
|
|
131
|
+
```
|
|
132
|
+
|
|
133
|
+
5. **Read comments** on the idea for additional context:
|
|
134
|
+
```
|
|
135
|
+
chorus_get_comments({ targetType: "idea", targetUuid: "<idea-uuid>" })
|
|
136
|
+
```
|
|
137
|
+
|
|
138
|
+
### Step 5: Elaborate on the Idea
|
|
139
|
+
|
|
140
|
+
**Every Idea should go through elaboration.** Elaboration improves Proposal quality and reduces rejection cycles.
|
|
141
|
+
|
|
142
|
+
#### Elaboration Depth
|
|
143
|
+
|
|
144
|
+
Determine depth based on idea complexity:
|
|
145
|
+
|
|
146
|
+
- `"minimal"` — 2-4 questions (small features, minor enhancements)
|
|
147
|
+
- `"standard"` — 5-10 questions (typical new features)
|
|
148
|
+
- `"comprehensive"` — 10-15 questions (large features, architectural changes)
|
|
149
|
+
|
|
150
|
+
#### Question Categories
|
|
151
|
+
|
|
152
|
+
`functional`, `non_functional`, `business_context`, `technical_context`, `user_scenario`, `scope`
|
|
153
|
+
|
|
154
|
+
#### Starting an Elaboration Round
|
|
155
|
+
|
|
156
|
+
> **Note:** Do NOT include an "Other" option in your questions. The UI automatically adds a free-text "Other" option to every question.
|
|
157
|
+
|
|
158
|
+
```
|
|
159
|
+
chorus_start_elaboration({
|
|
160
|
+
ideaUuid: "<idea-uuid>",
|
|
161
|
+
depth: "standard",
|
|
162
|
+
questions: [
|
|
163
|
+
{
|
|
164
|
+
id: "q1",
|
|
165
|
+
text: "What user roles should have access to this feature?",
|
|
166
|
+
category: "functional",
|
|
167
|
+
options: [
|
|
168
|
+
{ id: "a", label: "All users" },
|
|
169
|
+
{ id: "b", label: "Admin only" },
|
|
170
|
+
{ id: "c", label: "Role-based (configurable)" }
|
|
171
|
+
]
|
|
172
|
+
},
|
|
173
|
+
{
|
|
174
|
+
id: "q2",
|
|
175
|
+
text: "What is the expected data volume?",
|
|
176
|
+
category: "non_functional",
|
|
177
|
+
options: [
|
|
178
|
+
{ id: "a", label: "Low (<1000 records)" },
|
|
179
|
+
{ id: "b", label: "Medium (1K-100K records)" },
|
|
180
|
+
{ id: "c", label: "High (>100K records)" }
|
|
181
|
+
]
|
|
182
|
+
}
|
|
183
|
+
]
|
|
184
|
+
})
|
|
185
|
+
```
|
|
186
|
+
|
|
187
|
+
This triggers an `elaboration_requested` SSE event to stakeholders.
|
|
188
|
+
|
|
189
|
+
#### Submitting Answers
|
|
190
|
+
|
|
191
|
+
When answers arrive (via `elaboration_answered` SSE wake event or manual flow):
|
|
192
|
+
|
|
193
|
+
```
|
|
194
|
+
chorus_answer_elaboration({
|
|
195
|
+
ideaUuid: "<idea-uuid>",
|
|
196
|
+
roundUuid: "<round-uuid>",
|
|
197
|
+
answers: [
|
|
198
|
+
{ questionId: "q1", selectedOptionId: "c", customText: null },
|
|
199
|
+
{ questionId: "q2", selectedOptionId: null, customText: "Custom hybrid approach" }
|
|
200
|
+
]
|
|
201
|
+
})
|
|
202
|
+
```
|
|
203
|
+
|
|
204
|
+
Answer format:
|
|
205
|
+
- **Select an option**: `selectedOptionId: "a", customText: null`
|
|
206
|
+
- **Select an option + add a note**: `selectedOptionId: "a", customText: "additional context"`
|
|
207
|
+
- **Choose "Other" (free text)**: `selectedOptionId: null, customText: "your answer"` — customText is required when no option is selected
|
|
208
|
+
|
|
209
|
+
#### @Mention Workflow After Answers
|
|
210
|
+
|
|
211
|
+
After answers are submitted, **@mention the answerer** with a summary of your understanding. This prevents misinterpretation before you validate.
|
|
212
|
+
|
|
213
|
+
1. **Get mentionable info:**
|
|
214
|
+
```
|
|
215
|
+
chorus_search_mentionables({ query: "owner-name" })
|
|
216
|
+
```
|
|
217
|
+
|
|
218
|
+
2. **Post a summary comment** on the idea:
|
|
219
|
+
```
|
|
220
|
+
chorus_add_comment({
|
|
221
|
+
targetType: "idea",
|
|
222
|
+
targetUuid: "<idea-uuid>",
|
|
223
|
+
content: "@[Owner Name](user:owner-uuid) I've reviewed the elaboration answers. Here's my understanding:\n\n- Key requirement 1: ...\n- Key requirement 2: ...\n\nDoes this match your intent?"
|
|
224
|
+
})
|
|
225
|
+
```
|
|
226
|
+
|
|
227
|
+
3. **Wait for confirmation** via comments or a `mentioned` SSE event.
|
|
228
|
+
|
|
229
|
+
4. **Based on the response:**
|
|
230
|
+
- **Confirmed** — Proceed to validate with empty issues
|
|
231
|
+
- **Additions/corrections** — Incorporate feedback, optionally start a follow-up round
|
|
232
|
+
- **Unclear** — Ask clarifying questions via another comment
|
|
233
|
+
|
|
234
|
+
#### Validating the Elaboration
|
|
235
|
+
|
|
236
|
+
When answers are satisfactory:
|
|
237
|
+
|
|
238
|
+
```
|
|
239
|
+
chorus_validate_elaboration({
|
|
240
|
+
ideaUuid: "<idea-uuid>",
|
|
241
|
+
roundUuid: "<round-uuid>",
|
|
242
|
+
issues: []
|
|
243
|
+
})
|
|
244
|
+
```
|
|
245
|
+
|
|
246
|
+
If issues are found (contradictions, ambiguities, incomplete answers), include them and provide follow-up questions for a new round:
|
|
247
|
+
|
|
248
|
+
```
|
|
249
|
+
chorus_validate_elaboration({
|
|
250
|
+
ideaUuid: "<idea-uuid>",
|
|
251
|
+
roundUuid: "<round-uuid>",
|
|
252
|
+
issues: [
|
|
253
|
+
{ questionId: "q1", type: "ambiguity", description: "Role-based access selected but no roles defined" }
|
|
254
|
+
],
|
|
255
|
+
followUpQuestions: [
|
|
256
|
+
{
|
|
257
|
+
id: "fq1",
|
|
258
|
+
text: "Which specific roles should have access?",
|
|
259
|
+
category: "functional",
|
|
260
|
+
options: [
|
|
261
|
+
{ id: "a", label: "Admin + Editor" },
|
|
262
|
+
{ id: "b", label: "All authenticated users" }
|
|
263
|
+
]
|
|
264
|
+
}
|
|
265
|
+
]
|
|
266
|
+
})
|
|
267
|
+
```
|
|
268
|
+
|
|
269
|
+
This starts a new elaboration round, triggering another `elaboration_requested` event. The cycle repeats until all issues are resolved.
|
|
270
|
+
|
|
271
|
+
**Validation issue types:** `contradiction`, `ambiguity`, `incomplete`
|
|
272
|
+
|
|
273
|
+
#### Multi-Round Elaboration
|
|
274
|
+
|
|
275
|
+
Complex ideas may require multiple rounds:
|
|
276
|
+
|
|
277
|
+
1. Round 1: Broad scoping questions (functional, scope)
|
|
278
|
+
2. Round 2: Follow-up on ambiguous answers (technical_context)
|
|
279
|
+
3. Round 3: Final confirmation of edge cases (user_scenario)
|
|
280
|
+
|
|
281
|
+
Each round preserves the full history. Use `chorus_get_elaboration` at any time to see all rounds and their status.
|
|
282
|
+
|
|
283
|
+
#### Checking Elaboration Status
|
|
284
|
+
|
|
285
|
+
```
|
|
286
|
+
chorus_get_elaboration({ ideaUuid: "<idea-uuid>" })
|
|
287
|
+
```
|
|
288
|
+
|
|
289
|
+
Returns all rounds, questions, answers, and a progress summary.
|
|
290
|
+
|
|
291
|
+
---
|
|
292
|
+
|
|
293
|
+
## Tips
|
|
294
|
+
|
|
295
|
+
- When combining multiple ideas, explain how they relate in the proposal description
|
|
296
|
+
- Elaboration improves Proposal quality — run it for all non-trivial ideas
|
|
297
|
+
- Record decisions made in conversation as elaboration rounds for auditability
|
|
298
|
+
- Always @mention the owner to confirm understanding before validating
|
|
299
|
+
- SSE events mean you do not need to poll — the plugin wakes you when action is needed
|
|
300
|
+
|
|
301
|
+
---
|
|
302
|
+
|
|
303
|
+
## Next
|
|
304
|
+
|
|
305
|
+
- Once elaboration is resolved, use `/proposal` to create a Proposal with document and task drafts
|
|
306
|
+
- For platform overview and shared tools, see `/chorus`
|