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>
<best_practices> Always investigate current state before defining requirements using Serena's symbol-level operations Score questions using the 4-criteria scoring system and prioritize high-score questions (>= 15) Clearly distinguish mandatory from optional requirements with explicit rationale Document all assumptions when requirements are unclear or incomplete Map each requirement to specific test scenarios for verification Include rationale for key design decisions in technical specifications Use Context7 to verify latest library documentation and best practices Create dependency graphs showing task execution order </best_practices>
<anti_patterns> Requirements that are unclear or unmeasurable Write specific, testable requirements with clear acceptance criteria Specifying implementation details instead of requirements Describe what needs to be achieved, not how to implement it Writing requirements without investigating existing code Always investigate current state before defining requirements Not identifying technical or operational constraints Explicitly document all constraints that affect implementation Treating all requirements as equally important Clearly mark requirements as mandatory or optional with rationale </anti_patterns>
<error_escalation> Minor ambiguity in non-critical detail Unclear requirement affecting scope Technically infeasible requirement Requirement violates security or ethics </error_escalation>
<related_skills> Use to understand current system state before requirements definition Use after requirements approval to delegate implementation Use to define test requirements and acceptance criteria </related_skills>
<related_agents> Locate existing implementations and patterns to ground requirements in evidence Evaluate architectural feasibility and consistency of proposed requirements Cross-validate requirements document for completeness and consistency </related_agents>