Security:
- All data encrypted at rest using AES-256
- JWT tokens for authentication
Maintainability:
- Test coverage >= 80%
- Documentation for all public APIs
</example>
Impact Scope:
- All components making API calls
- Testing utilities need to mock React Query
</example>
Objectivity (0-100): Evidence-based vs. assumption-based
- 90-100: All requirements verified through investigation
- 70-89: Most requirements verified, some assumptions documented
- 50-69: Mix of verification and assumptions
- Below 50: Mostly assumptions, needs more investigation
</example>
1---2name: requirements-definition3description: This skill should be used when the user asks to "define requirements", "create specification", "clarify requirements", "write requirements document", or mentions requirement analysis. Provides comprehensive requirements definition methodology.4---5
6<purpose>
7 Provide structured methodology for requirements definition, ensuring comprehensive specification before implementation.
8</purpose>
9
10<tools>
11 <tool name="Glob">Directory structure analysis</tool>
12 <tool name="get_symbols_overview">Symbol analysis via Serena</tool>
13 <tool name="Grep">Keyword search</tool>
14 <tool name="find_symbol">Symbol search via Serena</tool>
15 <tool name="find_referencing_symbols">Dependency mapping via Serena</tool>
16 <tool name="Read">Specific content details</tool>
17 <tool name="Context7">Latest API documentation and best practices</tool>
18</tools>
19
20<patterns>
21 <pattern name="investigation_workflow">
22 <description>Sequential investigation process for gathering requirements context</description>
23 <decision_tree name="when_to_use">
24 <question>Is the current system state unclear or unknown?</question>
25 <if_yes>Apply investigation workflow to gather context before requirements definition</if_yes>
26 <if_no>Proceed directly to functional requirements if context is clear</if_no>
27 </decision_tree>
28 <steps>
29 <step>Directory structure analysis using Glob</step>
30 <step>Symbol analysis using get_symbols_overview</step>
31 <step>Keyword search using Grep or find_symbol</step>
32 <step>Dependency mapping using find_referencing_symbols</step>
33 <step>Specific content details using Read</step>
34 <step>Latest API documentation using Context7</step>
35 </steps>
36 </pattern>
37
38 <pattern name="question_scoring">
39 <description>Score each question by these criteria (1-5 each) to prioritize requirement clarification</description>
40 <decision_tree name="when_to_use">
41 <question>Have unclear or ambiguous requirements been identified?</question>
42 <if_yes>Apply question scoring to prioritize critical clarifications</if_yes>
43 <if_no>Proceed with documenting clear requirements</if_no>
44 </decision_tree>
45 <criteria>
46 <criterion name="design_branching">How much does the answer affect design direction?</criterion>
47 <criterion name="irreversibility">How difficult to change after implementation?</criterion>
48 <criterion name="investigation_impossibility">Cannot be determined through code investigation alone?</criterion>
49 <criterion name="effort_impact">How much does it affect implementation effort?</criterion>
50 </criteria>
51 <note>Present high-score questions first. Do not proceed without clear answers to critical questions (score >= 15)</note>
52 <example>
53 Question: "Should we use TypeScript's strict mode?"
54 - Design Branching: 5 (affects all type decisions)
55 - Irreversibility: 4 (hard to change later)
56 - Investigation Impossibility: 3 (requires policy decision)
57 - Effort Impact: 4 (affects development effort)
58 Total: 16 (critical - must answer before proceeding)
59 </example>
60 </pattern>
61
62 <pattern name="question_classification">
63 <description>Categories of questions that arise during requirements definition</description>
64 <decision_tree name="when_to_use">
65 <question>Do you need to categorize questions for stakeholder communication?</question>
66 <if_yes>Apply question classification to organize by type</if_yes>
67 <if_no>Use question scoring to prioritize by impact</if_no>
68 </decision_tree>
69 <types>
70 <type name="spec_confirmation">Confirming existing behavior or constraints</type>
71 <type name="design_choice">Choosing between valid alternatives</type>
72 <type name="constraint">Technical or business limitations</type>
73 <type name="scope">Boundaries of implementation</type>
74 <type name="priority">Order and importance of features</type>
75 </types>
76 <example>
77 - Spec Confirmation: "Does the API return null or empty array for no results?"
78 - Design Choice: "Should we use REST or GraphQL?"
79 - Constraint: "Must support IE11 browsers?"
80 - Scope: "Should admin features be included in v1?"
81 - Priority: "Which feature should be implemented first?"
82 </example>
83 </pattern>
84
85 <pattern name="functional_requirements">
86 <description>Format functional requirements with clear identifiers and acceptance criteria</description>
87 <decision_tree name="when_to_use">
88 <question>Are feature behaviors and capabilities clearly defined?</question>
89 <if_yes>Apply functional requirements format with acceptance criteria</if_yes>
90 <if_no>Use question scoring to clarify unclear behaviors first</if_no>
91 </decision_tree>
92 <example>
93 FR-001: User Authentication
94 Priority: mandatory
95 - Users must be able to log in with email and password
96 - Session must expire after 24 hours of inactivity
97 - Failed login attempts must be rate-limited (max 5 per hour)
98 </example>
99 </pattern>
100
101 <pattern name="non_functional_requirements">
102 <description>Specify measurable non-functional requirements across key dimensions</description>
103 <decision_tree name="when_to_use">
104 <question>Are quality attributes and constraints important for this feature?</question>
105 <if_yes>Apply non-functional requirements with measurable targets</if_yes>
106 <if_no>Focus on functional requirements only</if_no>
107 </decision_tree>
108 <example>
109 Performance:
110 - API response time < 200ms for 95th percentile
111 - Support 1000 concurrent users
112
113 Security:
114
115 - All data encrypted at rest using AES-256
116 - JWT tokens for authentication
117
118 Maintainability:
119
120 - Test coverage >= 80%
121 - Documentation for all public APIs
122 </example>
123 </pattern>
124
125 <pattern name="technical_specifications">
126 <description>Document design policies, patterns, and key decisions with rationale</description>
127 <decision_tree name="when_to_use">
128 <question>Have key technical decisions been made or identified?</question>
129 <if_yes>Apply technical specifications pattern with rationale and impact analysis</if_yes>
130 <if_no>Continue requirements gathering to identify decision points</if_no>
131 </decision_tree>
132 <example>
133 Design Decision: Use React Query for data fetching
134 Rationale:
135 - Built-in caching reduces API calls
136 - Automatic background refetching
137 - TypeScript support
138 - Widely adopted in existing codebase
139
140 Impact Scope:
141
142 - All components making API calls
143 - Testing utilities need to mock React Query
144 </example>
145 </pattern>
146
147 <pattern name="requirement_quality_metrics">
148 <description>Quantitative measures of requirement quality</description>
149 <decision_tree name="when_to_use">
150 <question>Are all requirements documented and ready for handoff?</question>
151 <if_yes>Apply quality metrics to assess requirement completeness</if_yes>
152 <if_no>Continue requirements definition until complete</if_no>
153 </decision_tree>
154 <example>
155 Feasibility (0-100): Technical achievability given constraints
156 - 90-100: Straightforward with existing tools
157 - 70-89: Requires some research or new libraries
158 - 50-69: Significant technical challenges
159 - Below 50: May need architecture changes
160
161 Objectivity (0-100): Evidence-based vs. assumption-based
162
163 - 90-100: All requirements verified through investigation
164 - 70-89: Most requirements verified, some assumptions documented
165 - 50-69: Mix of verification and assumptions
166 - Below 50: Mostly assumptions, needs more investigation
167 </example>
168 </pattern>
169</patterns>
170
171<output>
172 <format>
173 <summary>
174 - One-sentence request description
175 - Background and context
176 - Expected outcomes
177 </summary>
178 <current_state>
179 - Existing system description
180 - Technology stack
181 - Relevant patterns and conventions
182 </current_state>
183 <functional_requirements>
184 Format: FR-XXX (FR-001, FR-002, ...)
185 - Priority: mandatory or optional
186 - Clear acceptance criteria
187 </functional_requirements>
188 <non_functional_requirements>
189 - Performance: response time, throughput
190 - Security: authentication, authorization, data protection
191 - Maintainability: code quality, documentation
192 </non_functional_requirements>
193 <technical_specifications>
194 - Design policies and patterns
195 - Impact scope analysis
196 - Key design decisions with rationale
197 </technical_specifications>
198 <metrics>
199 - Feasibility (0-100): Technical achievability
200 - Objectivity (0-100): Evidence-based specification
201 </metrics>
202 <constraints>
203 - Technical constraints: platform, language, framework
204 - Operational constraints: deployment, maintenance
205 </constraints>
206 <test_requirements>
207 - Unit test coverage expectations
208 - Integration test scenarios
209 - Acceptance criteria verification
210 </test_requirements>
211 <task_breakdown>
212 - Dependency graph: task dependencies and execution order
213 - Phased tasks: files to modify/create, overview of changes, dependencies
214 - Execute handoff: key decisions, reference implementations, constraints
215 </task_breakdown>
216 </format>
217</output>
218
219<rules priority="critical">
220 <rule>Never proceed without clear answers to critical questions (score >= 15)</rule>
221 <rule>All requirements must be verifiable and measurable</rule>
222 <rule>Distinguish mandatory from optional requirements</rule>
223</rules>
224
225<rules priority="standard">
226 <rule>Present high-score questions first in requirement discussions</rule>
227 <rule>Document assumptions explicitly when requirements are unclear</rule>
228 <rule>Include rationale for key design decisions</rule>
229 <rule>Map requirements to test scenarios</rule>
230</rules>
231
232<best_practices>
233 <practice priority="critical">Always investigate current state before defining requirements using Serena's symbol-level operations</practice>
234 <practice priority="critical">Score questions using the 4-criteria scoring system and prioritize high-score questions (>= 15)</practice>
235 <practice priority="critical">Clearly distinguish mandatory from optional requirements with explicit rationale</practice>
236 <practice priority="high">Document all assumptions when requirements are unclear or incomplete</practice>
237 <practice priority="high">Map each requirement to specific test scenarios for verification</practice>
238 <practice priority="high">Include rationale for key design decisions in technical specifications</practice>
239 <practice priority="medium">Use Context7 to verify latest library documentation and best practices</practice>
240 <practice priority="medium">Create dependency graphs showing task execution order</practice>
241</best_practices>
242
243<workflow>
244 <phase name="gather">
245 <objective>Gather requirement information</objective>
246 <step>1. Understand user request and context</step>
247 <step>2. Investigate existing codebase patterns</step>
248 <step>3. Identify stakeholders and constraints</step>
249 </phase>
250 <phase name="clarify">
251 <objective>Clarify ambiguous requirements</objective>
252 <step>1. Score questions by impact (design, irreversibility, effort)</step>
253 <step>2. Use AskUserQuestion for structured decisions</step>
254 <step>3. Document answers and implications</step>
255 </phase>
256 <phase name="document">
257 <objective>Document requirements formally</objective>
258 <step>1. Write functional requirements (FR-XXX format)</step>
259 <step>2. Write non-functional requirements</step>
260 <step>3. Define acceptance criteria</step>
261 </phase>
262</workflow>
263
264<error_escalation>
265 <level severity="low">
266 <example>Minor ambiguity in non-critical detail</example>
267 <action>Note in report, proceed</action>
268 </level>
269 <level severity="medium">
270 <example>Unclear requirement affecting scope</example>
271 <action>Document issue, use AskUserQuestion for clarification</action>
272 </level>
273 <level severity="high">
274 <example>Technically infeasible requirement</example>
275 <action>STOP, present options to user</action>
276 </level>
277 <level severity="critical">
278 <example>Requirement violates security or ethics</example>
279 <action>BLOCK operation, require explicit user acknowledgment</action>
280 </level>
281</error_escalation>
282
283<constraints>
284 <must>Investigate before concluding</must>
285 <must>Ask questions before making assumptions</must>
286 <must>Include (Recommended) option in AskUserQuestion</must>
287 <avoid>Proceeding without answering critical questions</avoid>
288 <avoid>Justifying user preferences over technical validity</avoid>
289 <avoid>Documenting requirements without evidence</avoid>
290</constraints>
291
292<related_agents>
293 <agent name="define">Primary agent for requirements definition and specification design</agent>
294 <agent name="ask">Use for investigating current system state before requirements definition</agent>
295 <agent name="execute">Delegate to after requirements are fully defined and approved</agent>
296</related_agents>
297
298<related_skills>
299 <skill name="investigation-patterns">Use to understand current system state before requirements definition</skill>
300 <skill name="execution-workflow">Use after requirements approval to delegate implementation</skill>
301 <skill name="testing-patterns">Use to define test requirements and acceptance criteria</skill>
302</related_skills>
303
304<anti_patterns>
305 <avoid name="vague_requirements">
306 <description>Requirements that are unclear or unmeasurable</description>
307 <instead>Write specific, testable requirements with clear acceptance criteria</instead>
308 </avoid>
309 <avoid name="implementation_details">
310 <description>Specifying implementation details instead of requirements</description>
311 <instead>Describe what needs to be achieved, not how to implement it</instead>
312 </avoid>
313 <avoid name="skipping_investigation">
314 <description>Writing requirements without investigating existing code</description>
315 <instead>Always investigate current state before defining requirements</instead>
316 </avoid>
317 <avoid name="missing_constraints">
318 <description>Not identifying technical or operational constraints</description>
319 <instead>Explicitly document all constraints that affect implementation</instead>
320 </avoid>
321 <avoid name="undefined_priorities">
322 <description>Treating all requirements as equally important</description>
323 <instead>Clearly mark requirements as mandatory or optional with rationale</instead>
324 </avoid>
325</anti_patterns>
majiayu000