1---2name: requirements-definition-23description: 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---56<purpose>7Provide structured methodology for requirements definition, ensuring comprehensive specification before implementation.8</purpose>910<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>1920<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>3738<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>53Question: "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)58Total: 16 (critical - must answer before proceeding)59</example>60</pattern>6162<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>8485<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>93FR-001: User Authentication94Priority: mandatory95- Users must be able to log in with email and password96- Session must expire after 24 hours of inactivity97- Failed login attempts must be rate-limited (max 5 per hour)98</example>99</pattern>100101<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>109Performance:110- API response time < 200ms for 95th percentile111- Support 1000 concurrent users112113Security:114115- All data encrypted at rest using AES-256116- JWT tokens for authentication117118Maintainability:119120- Test coverage >= 80%121- Documentation for all public APIs122 </example>123 </pattern>124125<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>133Design Decision: Use React Query for data fetching134Rationale:135- Built-in caching reduces API calls136- Automatic background refetching137- TypeScript support138- Widely adopted in existing codebase139140Impact Scope:141142- All components making API calls143- Testing utilities need to mock React Query144 </example>145 </pattern>146147<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>155Feasibility (0-100): Technical achievability given constraints156- 90-100: Straightforward with existing tools157- 70-89: Requires some research or new libraries158- 50-69: Significant technical challenges159- Below 50: May need architecture changes160161Objectivity (0-100): Evidence-based vs. assumption-based162163- 90-100: All requirements verified through investigation164- 70-89: Most requirements verified, some assumptions documented165- 50-69: Mix of verification and assumptions166- Below 50: Mostly assumptions, needs more investigation167 </example>168 </pattern>169 </patterns>170171<output>172<format>173<summary>174- One-sentence request description175- Background and context176- Expected outcomes</summary>177<current_state>178- Existing system description179- Technology stack180- Relevant patterns and conventions</current_state>181<functional_requirements>Format: FR-XXX (FR-001, FR-002, ...)182- Priority: mandatory or optional183- Clear acceptance criteria</functional_requirements>184<non_functional_requirements>185- Performance: response time, throughput186- Security: authentication, authorization, data protection187- Maintainability: code quality, documentation</non_functional_requirements>188<technical_specifications>189- Design policies and patterns190- Impact scope analysis191- Key design decisions with rationale</technical_specifications>192<metrics>193- Feasibility (0-100): Technical achievability194- Objectivity (0-100): Evidence-based specification</metrics>195<constraints>196- Technical constraints: platform, language, framework197- Operational constraints: deployment, maintenance</constraints>198<test_requirements>199- Unit test coverage expectations200- Integration test scenarios201- Acceptance criteria verification</test_requirements>202<task_breakdown>203- Dependency graph: task dependencies and execution order204- Phased tasks: files to modify/create, overview of changes, dependencies205- Execute handoff: key decisions, reference implementations, constraints</task_breakdown>206</format>207</output>208209<rules priority="critical">210<rule>Never proceed without clear answers to critical questions (score >= 15)</rule>211<rule>All requirements must be verifiable and measurable</rule>212<rule>Distinguish mandatory from optional requirements</rule>213</rules>214215<rules priority="standard">216<rule>Present high-score questions first in requirement discussions</rule>217<rule>Document assumptions explicitly when requirements are unclear</rule>218<rule>Include rationale for key design decisions</rule>219<rule>Map requirements to test scenarios</rule>220</rules>221222<best_practices>223<practice priority="critical">Always investigate current state before defining requirements using Serena's symbol-level operations</practice>224<practice priority="critical">Score questions using the 4-criteria scoring system and prioritize high-score questions (>= 15)</practice>225<practice priority="critical">Clearly distinguish mandatory from optional requirements with explicit rationale</practice>226<practice priority="high">Document all assumptions when requirements are unclear or incomplete</practice>227<practice priority="high">Map each requirement to specific test scenarios for verification</practice>228<practice priority="high">Include rationale for key design decisions in technical specifications</practice>229<practice priority="medium">Use Context7 to verify latest library documentation and best practices</practice>230<practice priority="medium">Create dependency graphs showing task execution order</practice>231</best_practices>232233<workflow>234<phase name="gather">235<objective>Gather requirement information</objective>236<step>1. Understand user request and context</step>237<step>2. Investigate existing codebase patterns</step>238<step>3. Identify stakeholders and constraints</step>239</phase>240<phase name="clarify">241<objective>Clarify ambiguous requirements</objective>242<step>1. Score questions by impact (design, irreversibility, effort)</step>243<step>2. Use AskUserQuestion for structured decisions</step>244<step>3. Document answers and implications</step>245</phase>246<phase name="document">247<objective>Document requirements formally</objective>248<step>1. Write functional requirements (FR-XXX format)</step>249<step>2. Write non-functional requirements</step>250<step>3. Define acceptance criteria</step>251</phase>252</workflow>253254<error_escalation>255<level severity="low">256<example>Minor ambiguity in non-critical detail</example>257<action>Note in report, proceed</action>258</level>259<level severity="medium">260<example>Unclear requirement affecting scope</example>261<action>Document issue, use AskUserQuestion for clarification</action>262</level>263<level severity="high">264<example>Technically infeasible requirement</example>265<action>STOP, present options to user</action>266</level>267<level severity="critical">268<example>Requirement violates security or ethics</example>269<action>BLOCK operation, require explicit user acknowledgment</action>270</level>271</error_escalation>272273<constraints>274<must>Investigate before concluding</must>275<must>Ask questions before making assumptions</must>276<must>Include (Recommended) option in AskUserQuestion</must>277<avoid>Proceeding without answering critical questions</avoid>278<avoid>Justifying user preferences over technical validity</avoid>279<avoid>Documenting requirements without evidence</avoid>280</constraints>281282<related_agents>283<agent name="define">Primary agent for requirements definition and specification design</agent>284<agent name="ask">Use for investigating current system state before requirements definition</agent>285<agent name="execute">Delegate to after requirements are fully defined and approved</agent>286</related_agents>287288<related_skills>289<skill name="investigation-patterns">Use to understand current system state before requirements definition</skill>290<skill name="execution-workflow">Use after requirements approval to delegate implementation</skill>291<skill name="testing-patterns">Use to define test requirements and acceptance criteria</skill>292</related_skills>293294<anti_patterns>295<avoid name="vague_requirements">296<description>Requirements that are unclear or unmeasurable</description>297<instead>Write specific, testable requirements with clear acceptance criteria</instead>298</avoid>299<avoid name="implementation_details">300<description>Specifying implementation details instead of requirements</description>301<instead>Describe what needs to be achieved, not how to implement it</instead>302</avoid>303<avoid name="skipping_investigation">304<description>Writing requirements without investigating existing code</description>305<instead>Always investigate current state before defining requirements</instead>306</avoid>307<avoid name="missing_constraints">308<description>Not identifying technical or operational constraints</description>309<instead>Explicitly document all constraints that affect implementation</instead>310</avoid>311<avoid name="undefined_priorities">312<description>Treating all requirements as equally important</description>313<instead>Clearly mark requirements as mandatory or optional with rationale</instead>314</avoid>315</anti_patterns>
majiayu000