@vpxa/aikit 0.1.144 → 0.1.146

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.
@@ -10,325 +10,109 @@ metadata:
10
10
  relatedSkills: [brainstorming]
11
11
  ---
12
12
 
13
- # Requirements Clarity Skill
13
+ # Requirements Clarity
14
14
 
15
- ## Description
15
+ ## When to Skip
16
16
 
17
- Automatically transforms vague requirements into actionable PRDs through systematic clarification with a 100-point scoring system.
18
-
19
-
20
- ## Instructions
21
-
22
- When invoked, detect vague requirements:
23
-
24
- 1. **Vague Feature Requests**
25
- - User says: "add login feature", "implement payment", "create dashboard"
26
- - Missing: How, with what technology, what constraints?
27
-
28
- 2. **Missing Technical Context**
29
- - No technology stack mentioned
30
- - No integration points identified
31
- - No performance/security constraints
32
-
33
- 3. **Incomplete Specifications**
34
- - No acceptance criteria
35
- - No success metrics
36
- - No edge cases considered
37
- - No error handling mentioned
38
-
39
- 4. **Ambiguous Scope**
40
- - Unclear boundaries ("user management" - what exactly?)
41
- - No distinction between MVP and future enhancements
42
- - Missing "what's NOT included"
43
-
44
- **Do NOT activate when**:
17
+ Do NOT activate when:
45
18
  - Specific file paths mentioned (e.g., "auth.go:45")
46
- - Code snippets included
47
- - Existing functions/classes referenced
19
+ - Code snippets or existing functions/classes referenced
48
20
  - Bug fixes with clear reproduction steps
21
+ - Task is a single-file change with obvious scope
49
22
 
50
- ## Core Principles
23
+ ## Protocol
51
24
 
52
- 1. **Systematic Questioning**
53
- - Ask focused, specific questions
54
- - One category at a time (2-3 questions per round)
55
- - Build on previous answers
56
- - Avoid overwhelming users
25
+ ### 1. YAGNI/KISS Gate
57
26
 
58
- 2. **Quality-Driven Iteration**
59
- - Continuously assess clarity score (0-100)
60
- - Identify gaps systematically
61
- - Iterate until ≥ 90 points
62
- - Document all clarification rounds
27
+ Before ANY scoring, ask:
28
+ - **Why?** Is this needed now? YAGNI check.
29
+ - **Simpler?** Is there a simpler approach? KISS check.
63
30
 
64
- 3. **Actionable Output**
65
- - Generate concrete specifications
66
- - Include measurable acceptance criteria
67
- - Provide executable phases
68
- - Enable direct implementation
31
+ If the answers show the feature is not needed now, should be deferred, or has a trivial solution, advise that directly instead of continuing to scoring.
69
32
 
70
- ## Clarification Process
33
+ ### 2. Score (0-100)
71
34
 
72
- ### Step 1: Initial Requirement Analysis
35
+ Assess the requirement against this rubric:
73
36
 
74
- **Input**: User's requirement description
37
+ | Category | Points | Criteria |
38
+ |----------|--------|----------|
39
+ | Functional Clarity | /30 | Clear inputs/outputs (10), user interaction defined (10), success criteria stated (10) |
40
+ | Technical Specificity | /25 | Tech stack mentioned (8), integration points (8), constraints specified (9) |
41
+ | Implementation Completeness | /25 | Edge cases (8), error handling (9), data validation (8) |
42
+ | Business Context | /20 | Problem statement (7), target users (7), success metrics (6) |
75
43
 
76
- **Tasks**:
77
- 1. Parse and understand core requirement
78
- 2. Generate feature name (kebab-case format)
79
- 3. Determine document version (default \`1.0\` unless user specifies otherwise)
80
- 4. Ensure \`.spec/{feature_name}/\` exists for PRD output
81
- 5. Perform initial clarity assessment (0-100)
44
+ If you present this rubric or a score update to the user, use \`present({ format: 'html' })\` with a metrics block when visual formatting would help.
82
45
 
83
- **Assessment Rubric**:
84
- \`\`\`
85
- Functional Clarity: /30 points
86
- - Clear inputs/outputs: 10 pts
87
- - User interaction defined: 10 pts
88
- - Success criteria stated: 10 pts
89
-
90
- Technical Specificity: /25 points
91
- - Technology stack mentioned: 8 pts
92
- - Integration points identified: 8 pts
93
- - Constraints specified: 9 pts
94
-
95
-
96
- If you present this rubric or a requirements scorecard to the user, use \`present({ format: 'html' })\` to display a rich dashboard when visual formatting would help.
97
- Implementation Completeness: /25 points
98
- - Edge cases considered: 8 pts
99
- - Error handling mentioned: 9 pts
100
- - Data validation specified: 8 pts
46
+ ### 3. Iterate Until ≥ 90
101
47
 
102
- Business Context: /20 points
103
- - Problem statement clear: 7 pts
104
- - Target users identified: 7 pts
105
- - Success metrics defined: 6 pts
106
- \`\`\`
48
+ For each clarification round:
49
+ 1. Score the current requirement.
50
+ 2. Identify the 2-3 highest-impact gaps.
51
+ 3. Ask focused questions for one category at a time.
52
+ 4. Update the score after each user response.
53
+ 5. Capture clarified details in a working outline.
54
+ 6. Repeat until the score is at least 90.
107
55
 
108
- **Initial Response Format**:
109
- \`\`\`markdown
110
- I understand your requirement. Let me help you refine this specification.
56
+ Prefer short, targeted questions over long questionnaires. Build on previous answers instead of repeating the whole requirement.
111
57
 
112
- **Current Clarity Score**: X/100
58
+ **HARD RULE:** Do not generate the requirements document with a score below 90.
113
59
 
114
- **Clear Aspects**:
115
- - [List what's clear]
60
+ ### 4. Generate Requirements Document
116
61
 
117
- **Needs Clarification**:
118
- - [List gaps]
62
+ **Output path (flow-aware):**
63
+ - If a flow is active: \`flow({ action: 'status' })\` → write to \`{{artifacts_path}}/requirements.md\`
64
+ - If no flow active: write to \`.spec/{feature_name}/requirements.md\`
119
65
 
120
- Let me systematically clarify these points...
66
+ To detect active flow:
121
67
  \`\`\`
122
-
123
- ### Step 2: Gap Analysis
124
-
125
- Identify missing information across four dimensions:
126
-
127
- **1. Functional Scope**
128
- - What is the core functionality?
129
- - What are the boundaries?
130
- - What is out of scope?
131
- - What are edge cases?
132
-
133
- **2. User Interaction**
134
- - How do users interact?
135
- - What are the inputs?
136
- - What are the outputs?
137
- - What are success/failure scenarios?
138
-
139
- **3. Technical Constraints**
140
- - Performance requirements?
141
- - Compatibility requirements?
142
- - Security considerations?
143
- - Scalability needs?
144
-
145
- **4. Business Value**
146
- - What problem does this solve?
147
- - Who are the target users?
148
- - What are success metrics?
149
- - What is the priority?
150
-
151
- ### Step 3: Interactive Clarification
152
-
153
- **Question Strategy**:
154
- 1. Start with highest-impact gaps
155
- 2. Ask 2-3 questions per round
156
- 3. Build context progressively
157
- 4. Use user's language
158
- 5. Provide examples when helpful
159
-
160
- **Question Format**:
161
- \`\`\`markdown
162
- I need to clarify the following points to complete the requirements document:
163
-
164
- 1. **[Category]**: [Specific question]?
165
- - For example: [Example if helpful]
166
-
167
- 2. **[Category]**: [Specific question]?
168
-
169
- 3. **[Category]**: [Specific question]?
170
-
171
- Please provide your answers, and I'll continue refining the PRD.
68
+ const flowStatus = flow({ action: 'status' });
69
+ if (flowStatus.active) {
70
+ // Output to: .flows/{topic}/.spec/requirements.md
71
+ outputPath = \`\${flowStatus.artifactsPath}/requirements.md\`;
72
+ } else {
73
+ outputPath = \`.spec/\${featureName}/requirements.md\`;
74
+ }
172
75
  \`\`\`
173
76
 
174
- **After Each User Response**:
175
- 1. Update clarity score
176
- 2. Capture new information in the working PRD outline
177
- 3. Identify remaining gaps
178
- 4. If score < 90: Continue with next round of questions
179
- 5. If score ≥ 90: Proceed to PRD generation
180
-
181
- **Score Update Format**:
182
- \`\`\`markdown
183
- Thank you for the additional information!
184
-
185
- **Clarity Score Update**: X/100 → Y/100
186
-
187
- **New Clarified Content**:
188
- - [Summarize new information]
189
-
190
- **Remaining Points to Clarify**:
191
- - [List remaining gaps if score < 90]
192
-
193
- [If score < 90: Continue with next round of questions]
194
- [If score ≥ 90: "Perfect! I will now generate the complete PRD document..."]
77
+ Use \`create_file\` to save the document after the score reaches 90 or higher.
78
+
79
+ Required structure:
80
+ - **Requirements Description**
81
+ - Background
82
+ - Feature overview
83
+ - Detailed requirements
84
+ - Edge cases
85
+ - **Design Decisions**
86
+ - Technical approach
87
+ - Constraints
88
+ - Risk assessment
89
+ - **Acceptance Criteria**
90
+ - Functional acceptance checkboxes
91
+ - Quality standards
92
+ - User acceptance
93
+ - **Execution Phases**
94
+ - Preparation
95
+ - Core development
96
+ - Integration and testing
97
+ - Deployment
98
+
99
+ Each section must contain concrete, implementation-ready content. Do not leave placeholders.
100
+
101
+ Footer fields:
102
+ - Document Version
103
+ - Created timestamp
104
+ - Clarification Rounds count
105
+ - Quality Score /100
106
+
107
+ **After writing:** Also store a compact summary in flow-scoped knowledge for downstream step consumption:
195
108
  \`\`\`
196
-
197
- ### Step 4: PRD Generation
198
-
199
- Once clarity score ≥ 90, generate comprehensive PRD.
200
-
201
- **Output File**:
202
-
203
- 1. **Final PRD**: \`.spec/{feature_name}/requirements.md\`
204
-
205
- Use \`create_file\` to save this file. Derive \`{version}\` from the document version recorded in the PRD (default \`1.0\`).
206
-
207
- ## PRD Document Structure
208
-
209
- \`\`\`markdown
210
- # {Feature Name} - Product Requirements Document (PRD)
211
-
212
- ## Requirements Description
213
-
214
- ### Background
215
- - **Business Problem**: [Describe the business problem to solve]
216
- - **Target Users**: [Target user groups]
217
- - **Value Proposition**: [Value this feature brings]
218
-
219
- ### Feature Overview
220
- - **Core Features**: [List of main features]
221
- - **Feature Boundaries**: [What is and isn't included]
222
- - **User Scenarios**: [Typical usage scenarios]
223
-
224
- ### Detailed Requirements
225
- - **Input/Output**: [Specific input/output specifications]
226
- - **User Interaction**: [User operation flow]
227
- - **Data Requirements**: [Data structures and validation rules]
228
- - **Edge Cases**: [Edge case handling]
229
-
230
- ## Design Decisions
231
-
232
- ### Technical Approach
233
- - **Architecture Choice**: [Technical architecture decisions and rationale]
234
- - **Key Components**: [List of main technical components]
235
- - **Data Storage**: [Data models and storage solutions]
236
- - **Interface Design**: [API/interface specifications]
237
-
238
- ### Constraints
239
- - **Performance Requirements**: [Response time, throughput, etc.]
240
- - **Compatibility**: [System compatibility requirements]
241
- - **Security**: [Security considerations]
242
- - **Scalability**: [Future expansion considerations]
243
-
244
- ### Risk Assessment
245
- - **Technical Risks**: [Potential technical risks and mitigation plans]
246
- - **Dependency Risks**: [External dependencies and alternatives]
247
- - **Schedule Risks**: [Timeline risks and response strategies]
248
-
249
- ## Acceptance Criteria
250
-
251
- ### Functional Acceptance
252
- - [ ] Feature 1: [Specific acceptance conditions]
253
- - [ ] Feature 2: [Specific acceptance conditions]
254
- - [ ] Feature 3: [Specific acceptance conditions]
255
-
256
- ### Quality Standards
257
- - [ ] Code Quality: [Code standards and review requirements]
258
- - [ ] Test Coverage: [Testing requirements and coverage]
259
- - [ ] Performance Metrics: [Performance test pass criteria]
260
- - [ ] Security Review: [Security review requirements]
261
-
262
- ### User Acceptance
263
- - [ ] User Experience: [UX acceptance criteria]
264
- - [ ] Documentation: [Documentation delivery requirements]
265
- - [ ] Training Materials: [If needed, training material requirements]
266
-
267
- ## Execution Phases
268
-
269
- ### Phase 1: Preparation
270
- **Goal**: Environment preparation and technical validation
271
- - [ ] Task 1: [Specific task description]
272
- - [ ] Task 2: [Specific task description]
273
- - **Deliverables**: [Phase deliverables]
274
- - **Time**: [Estimated time]
275
-
276
- ### Phase 2: Core Development
277
- **Goal**: Implement core functionality
278
- - [ ] Task 1: [Specific task description]
279
- - [ ] Task 2: [Specific task description]
280
- - **Deliverables**: [Phase deliverables]
281
- - **Time**: [Estimated time]
282
-
283
- ### Phase 3: Integration & Testing
284
- **Goal**: Integration and quality assurance
285
- - [ ] Task 1: [Specific task description]
286
- - [ ] Task 2: [Specific task description]
287
- - **Deliverables**: [Phase deliverables]
288
- - **Time**: [Estimated time]
289
-
290
- ### Phase 4: Deployment
291
- **Goal**: Release and monitoring
292
- - [ ] Task 1: [Specific task description]
293
- - [ ] Task 2: [Specific task description]
294
- - **Deliverables**: [Phase deliverables]
295
- - **Time**: [Estimated time]
296
-
297
- ---
298
-
299
- **Document Version**: 1.0
300
- **Created**: {timestamp}
301
- **Clarification Rounds**: {clarification_rounds}
302
- **Quality Score**: {quality_score}/100
109
+ knowledge({
110
+ action: "remember",
111
+ scope: "flow",
112
+ category: "context",
113
+ title: "Requirements: <feature>",
114
+ content: "Score: <X>/100\\nKey Requirements:\\n- <req1>\\n- <req2>\\nAcceptance Criteria:\\n- <criteria1>\\nConstraints:\\n- <constraint1>"
115
+ })
303
116
  \`\`\`
304
-
305
- ## Behavioral Guidelines
306
-
307
- ### DO
308
- - Ask specific, targeted questions
309
- - Build on previous answers
310
- - Provide examples to guide users
311
- - Maintain conversational tone
312
- - Summarize clarification rounds within the PRD
313
- - Use clear, professional English
314
- - Generate concrete specifications
315
- - Stay in clarification mode until score ≥ 90
316
-
317
- ### DON'T
318
- - Ask all questions at once
319
- - Make assumptions without confirmation
320
- - Generate PRD before 90+ score
321
- - Skip any required sections
322
- - Use vague or abstract language
323
- - Proceed without user responses
324
- - Exit skill mode prematurely
325
-
326
- ## Success Criteria
327
-
328
- - Clarity score ≥ 90/100
329
- - All PRD sections complete with substance
330
- - Acceptance criteria checklistable (using \`- [ ]\` format)
331
- - Execution phases actionable with concrete tasks
332
- - User approves final PRD
333
- - Ready for development handoff
117
+ This ensures downstream steps (Spec, Plan, Implementation) can access requirements via \`withdraw\` even without reading the file.
334
118
  `}];export{e as default};