Initial commit

2025-11-29 18:48:05 +08:00
commit 694b4f5c2c
12 changed files with 3661 additions and 0 deletions
--- a/commands/sng-requirements.md
+++ b/commands/sng-requirements.md
@@ -0,0 +1,239 @@
+# Requirements Analysis Command
+
+You are helping the user analyze, document, and manage project requirements following Sngular's project management best practices.
+
+## Instructions
+
+1. **Determine the scope**:
+   - Ask what feature or project needs requirements analysis
+   - Identify if this is for a new feature, enhancement, or bug fix
+   - Determine if there's an existing GitHub issue to update
+   - Check for existing documentation to review
+
+2. **Gather context**:
+   - Review project documentation in `./docs`
+   - Analyze relevant codebase sections
+   - Check existing requirements or specifications
+   - Review similar features or patterns in the project
+   - Identify stakeholders and their needs
+
+3. **Analyze requirements**:
+   - **Functional Requirements**: What the system must do
+   - **Non-Functional Requirements**: Performance, security, scalability, accessibility
+   - **User Stories**: As a [user], I want [goal], so that [benefit]
+   - **Acceptance Criteria**: Clear, testable conditions for completion
+   - **Dependencies**: Other features, services, or systems required
+   - **Constraints**: Technical, business, or time limitations
+   - **Assumptions**: Things we're assuming to be true
+   - **Risks**: Potential issues or challenges
+
+4. **Structure the documentation**:
+   ```markdown
+   ## [Feature Name] - Requirements
+
+   ### Overview
+   Brief description of the feature and its purpose.
+
+   ### Business Context
+   - Why is this needed?
+   - What problem does it solve?
+   - What is the expected business impact?
+
+   ### Functional Requirements
+
+   #### FR-1: [Requirement Title]
+   **Priority**: Must-have / Should-have / Could-have / Won't-have
+   **Description**: Detailed description of what needs to be implemented
+   **Acceptance Criteria**:
+   - [ ] Criterion 1
+   - [ ] Criterion 2
+   - [ ] Criterion 3
+
+   #### FR-2: [Next Requirement]
+   ...
+
+   ### Non-Functional Requirements
+
+   #### NFR-1: Performance
+   - Response time: < 200ms for API calls
+   - Page load time: < 2 seconds
+   - Support for 1000 concurrent users
+
+   #### NFR-2: Security
+   - Authentication required
+   - Role-based access control
+   - Data encryption at rest and in transit
+
+   #### NFR-3: Accessibility
+   - WCAG 2.1 AA compliance
+   - Screen reader support
+   - Keyboard navigation
+
+   ### User Stories
+
+   **US-1**: As a [user type], I want to [action], so that [benefit]
+   - Acceptance Criteria:
+     - [ ] Criterion 1
+     - [ ] Criterion 2
+
+   ### Technical Specifications
+
+   #### Data Models
+   ```typescript
+   interface Model {
+     id: string
+     // ...
+   }
+   ```
+
+   #### API Endpoints
+   - `POST /api/resource` - Create new resource
+   - `GET /api/resource/:id` - Retrieve resource
+
+   #### UI Components
+   - ComponentName: Description and purpose
+
+   ### Dependencies
+   - External APIs or services required
+   - Third-party libraries needed
+   - Database schema changes
+   - Infrastructure requirements
+
+   ### Assumptions
+   - List of assumptions made during analysis
+
+   ### Risks & Mitigation
+   | Risk | Impact | Likelihood | Mitigation Strategy |
+   |------|--------|------------|---------------------|
+   | Risk 1 | High | Medium | Mitigation plan |
+
+   ### Testing Strategy
+   - Unit tests for business logic
+   - Integration tests for API endpoints
+   - E2E tests for user workflows
+   - Performance testing approach
+   - Security testing considerations
+
+   ### Implementation Phases
+
+   **Phase 1**: Core functionality (2 weeks)
+   - [ ] Task 1
+   - [ ] Task 2
+
+   **Phase 2**: Advanced features (1 week)
+   - [ ] Task 3
+   - [ ] Task 4
+
+   **Phase 3**: Polish & optimization (3 days)
+   - [ ] Task 5
+   - [ ] Task 6
+
+   ### Success Metrics
+   - How will we measure success?
+   - KPIs to track
+   - User adoption goals
+
+   ### Open Questions
+   - [ ] Question 1 that needs clarification
+   - [ ] Question 2 requiring stakeholder input
+   ```
+
+5. **GitHub Integration** (if applicable):
+   - Check if working in a GitHub repository
+   - Ask for issue number to update
+   - Create or update GitHub issue with requirements
+   - Add appropriate labels: `requirements`, `documentation`
+   - Link related issues if any
+
+6. **Save documentation**:
+   - Save requirements to `./docs/requirements/[feature-name].md`
+   - Update main requirements index if it exists
+   - Create a summary for quick reference
+
+## GitHub Commands
+
+```bash
+# View repository info
+gh repo view
+
+# List existing issues
+gh issue list
+
+# View specific issue
+gh issue view <issue-number>
+
+# Create new issue with requirements
+gh issue create --title "Requirements: [Feature Name]" --body "$(cat requirements.md)" --label "requirements,documentation"
+
+# Add requirements as comment to existing issue
+gh issue comment <issue-number> --body "$(cat requirements.md)"
+
+# Update issue labels
+gh issue edit <issue-number> --add-label "requirements-defined"
+
+# Link issues
+gh issue comment <issue-number> --body "Related to #<other-issue-number>"
+```
+
+## Requirements Prioritization (MoSCoW Method)
+
+- **Must-have**: Critical for launch, non-negotiable
+- **Should-have**: Important but not critical, can be scheduled for later if needed
+- **Could-have**: Nice to have, adds value but not essential
+- **Won't-have**: Not planned for this release, explicitly excluded
+
+## Best Practices
+
+### Writing Good Requirements
+
+✅ **Good**:
+- "The system shall allow users to export data in CSV, JSON, and XML formats"
+- "API response time must be under 200ms for 95% of requests"
+- "The login form must be accessible via keyboard navigation"
+
+❌ **Bad**:
+- "The system should be fast" (not measurable)
+- "It should be user-friendly" (too vague)
+- "We might need export functionality" (not decisive)
+
+### Acceptance Criteria Guidelines
+
+Each acceptance criterion should be:
+- **Specific**: Clearly defined without ambiguity
+- **Measurable**: Can be verified through testing
+- **Achievable**: Technically feasible within constraints
+- **Relevant**: Directly related to the requirement
+- **Testable**: Can write automated or manual tests
+
+### INVEST Principles for User Stories
+
+- **Independent**: Can be developed separately
+- **Negotiable**: Open to discussion and refinement
+- **Valuable**: Provides clear value to users
+- **Estimable**: Team can estimate effort
+- **Small**: Can be completed in one sprint
+- **Testable**: Can verify it's done
+
+## Questions to Ask
+
+Before starting requirements analysis:
+1. "What is the main goal or problem this feature addresses?"
+2. "Who are the primary users and what are their needs?"
+3. "Are there existing issues or documentation I should review?"
+4. "What are the must-have features vs. nice-to-have?"
+5. "Are there any technical constraints or dependencies?"
+6. "What is the expected timeline or deadline?"
+7. "How will success be measured?"
+8. "Should I create a new GitHub issue or update an existing one?"
+
+## Example Workflow
+
+1. User: "Analyze requirements for user authentication feature"
+2. Claude: Reviews codebase, checks for existing auth patterns
+3. Claude: Asks clarifying questions about auth method (OAuth, JWT, etc.)
+4. Claude: Creates comprehensive requirements document
+5. Claude: Saves to `./docs/requirements/user-authentication.md`
+6. Claude: Creates GitHub issue or updates existing one
+7. Claude: Provides summary and next steps
+
+Ask the user: "What feature or project would you like me to analyze requirements for?"