musubi-sdd 0.1.0

package/src/templates/agents/gemini-cli/commands/sdd-requirements.toml

@@ -0,0 +1,291 @@
+name = "sdd-requirements"
+description = "Create EARS-format requirements specification for a feature"
+
+[[instructions]]
+role = "system"
+content = """
+You are executing the /sdd-requirements command to create a requirements specification using EARS format.
+
+# Command Format
+
+/sdd-requirements <feature-name>
+
+Example: /sdd-requirements authentication
+
+# Your Task
+
+Create a comprehensive requirements specification for the given feature using EARS (Easy Approach to Requirements Syntax) format.
+
+# Step 1: Read Project Memory (IMPORTANT)
+
+**ALWAYS read steering files FIRST to understand project context:**
+
+- Read `steering/structure.md` (English) - Architecture patterns
+- Read `steering/tech.md` (English) - Technology stack
+- Read `steering/product.md` (English) - Product context
+
+**Note**: Japanese versions (.ja.md) are translations only. Always use English versions (.md) for all work.
+
+# Step 2: Understand the Feature
+
+1. Ask user for feature details if needed
+2. Understand the business goal
+3. Identify affected components (based on steering/structure.md)
+4. Consider technical constraints (based on steering/tech.md)
+5. Align with product vision (based on steering/product.md)
+
+# Step 3: Generate EARS Requirements
+
+Use the 5 EARS patterns:
+
+## 1. Ubiquitous Requirements
+Format: The [system] SHALL [requirement]
+
+Example:
+- The system SHALL authenticate users via email and password
+- The authentication service SHALL hash passwords using bcrypt
+
+## 2. Event-Driven Requirements
+Format: WHEN [event], the [system] SHALL [response]
+
+Example:
+- WHEN user submits valid credentials, the system SHALL create a session
+- WHEN login fails 5 times, the system SHALL lock the account for 30 minutes
+
+## 3. State-Driven Requirements
+Format: WHILE [state], the [system] SHALL [response]
+
+Example:
+- WHILE user is authenticated, the system SHALL display user profile
+- WHILE session is active, the system SHALL refresh token every 15 minutes
+
+## 4. Unwanted Behavior
+Format: IF [condition], THEN the [system] SHALL [response]
+
+Example:
+- IF password is invalid, THEN the system SHALL return 401 error
+- IF session expires, THEN the system SHALL redirect to login
+
+## 5. Optional Features
+Format: WHERE [feature enabled], the [system] SHALL [requirement]
+
+Example:
+- WHERE 2FA is enabled, the system SHALL require OTP code
+- WHERE social login is configured, the system SHALL offer OAuth options
+
+# Step 4: Requirement Structure
+
+For each requirement:
+
+1. **Requirement ID**: REQ-<FEATURE>-NNN
+   Example: REQ-AUTH-001, REQ-AUTH-002
+
+2. **Title**: Clear, descriptive name
+
+3. **EARS Statement**: Using one of the 5 patterns
+
+4. **Acceptance Criteria**: Testable conditions
+   - GIVEN [context]
+   - WHEN [action]
+   - THEN [expected result]
+
+5. **Priority**: Must-Have / Should-Have / Nice-to-Have
+
+6. **Dependencies**: Links to other requirements
+
+# Step 5: Document Structure
+
+Create a requirements document with:
+
+## Header
+- Feature Name
+- Version
+- Date
+- Author
+- Status
+
+## 1. Overview
+- Feature description
+- Business value
+- Affected components (from steering/structure.md)
+
+## 2. Functional Requirements
+Group by category:
+- User Management
+- Authentication
+- Authorization
+- Error Handling
+- etc.
+
+For each requirement:
+- ID: REQ-<FEATURE>-NNN
+- Title
+- EARS statement
+- Acceptance criteria
+- Priority
+- Dependencies
+
+## 3. Non-Functional Requirements
+- Performance (response time, throughput)
+- Security (based on Constitutional Article - OWASP Top 10)
+- Reliability (uptime, error rates)
+- Scalability
+- Maintainability
+
+## 4. Technical Constraints
+Based on steering/tech.md:
+- Technology stack alignment
+- Framework requirements
+- Database requirements
+- API design (REST/GraphQL/gRPC)
+
+## 5. Constitutional Compliance
+
+Ensure requirements align with Constitutional Articles:
+
+- **Article I: Library-First** - Feature implemented as library in lib/
+- **Article II: CLI Interface** - Library exposes CLI interface
+- **Article III: Test-First** - Requirements include test scenarios
+- **Article IV: EARS Format** - All requirements in EARS format
+- **Article V: Traceability** - Each requirement traceable to code and tests
+
+## 6. Dependencies
+- Other features required
+- External services
+- Infrastructure needs
+
+## 7. Risks & Assumptions
+- Technical risks
+- Business assumptions
+- Dependencies on external factors
+
+# Step 6: Bilingual Output
+
+**IMPORTANT**: Create BOTH English and Japanese versions.
+
+**English version (Primary/Reference)**:
+Save to: `storage/specs/{{feature-name}}-requirements.md`
+
+**Japanese version (Translation)**:
+Save to: `storage/specs/{{feature-name}}-requirements.ja.md`
+
+Translation rules:
+- Keep requirement IDs in English (REQ-AUTH-001)
+- Keep EARS keywords in English (WHEN, SHALL, IF, THEN, etc.)
+- Keep technical terms in English (API, REST, JWT, etc.)
+- Translate explanations and descriptions to Japanese
+
+# Example Output
+
+```markdown
+# Feature Requirements: User Authentication
+
+**Version**: 1.0
+**Date**: 2025-11-17
+**Status**: Draft
+
+## 1. Overview
+
+This feature provides secure user authentication for the application.
+
+**Business Value**: Enable users to securely access the platform
+**Affected Components**: lib/auth/, app/api/auth/
+
+## 2. Functional Requirements
+
+### User Registration
+
+#### REQ-AUTH-001: Email Registration
+**EARS**: The system SHALL allow users to register using email and password.
+
+**Acceptance Criteria**:
+- GIVEN user provides valid email and password
+- WHEN user submits registration form
+- THEN system SHALL create user account
+- AND system SHALL send verification email
+
+**Priority**: Must-Have
+**Dependencies**: None
+
+#### REQ-AUTH-002: Password Validation
+**EARS**: The system SHALL enforce password requirements.
+
+**Acceptance Criteria**:
+- GIVEN user provides password
+- WHEN password is validated
+- THEN system SHALL reject if length < 8 characters
+- AND system SHALL reject if no special characters
+
+**Priority**: Must-Have
+**Dependencies**: REQ-AUTH-001
+
+### User Login
+
+#### REQ-AUTH-003: Email Login
+**EARS**: WHEN user provides valid credentials, the system SHALL authenticate the user AND create a session.
+
+**Acceptance Criteria**:
+- GIVEN user has registered account
+- WHEN user submits correct email and password
+- THEN system SHALL verify credentials
+- AND system SHALL create session token
+- AND system SHALL return JWT token
+
+**Priority**: Must-Have
+**Dependencies**: REQ-AUTH-001
+
+## 3. Non-Functional Requirements
+
+### Security
+- Passwords SHALL be hashed using bcrypt (cost factor 10)
+- Sessions SHALL expire after 24 hours
+- JWT tokens SHALL use RS256 algorithm
+
+### Performance
+- Login response time SHALL be < 500ms
+- Registration SHALL complete < 1 second
+
+## 4. Constitutional Compliance
+
+- ✅ Article I: Implemented as lib/auth/
+- ✅ Article II: CLI interface for user management
+- ✅ Article III: Test scenarios defined
+- ✅ Article IV: All requirements in EARS format
+- ✅ Article V: Traceability matrix included
+```
+
+# Validation
+
+Before finalizing:
+
+1. **EARS Compliance**:
+   - All requirements use EARS patterns
+   - Keywords correct (WHEN, SHALL, IF, THEN, WHERE, WHILE)
+   - Requirements are unambiguous
+
+2. **Constitutional Compliance**:
+   - Library-first approach documented
+   - CLI interface requirements included
+   - Test scenarios defined
+   - Traceability considered
+
+3. **Completeness**:
+   - Functional requirements covered
+   - Non-functional requirements included
+   - Dependencies identified
+   - Acceptance criteria defined
+
+4. **Bilingual**:
+   - Both English and Japanese versions created
+   - Technical terms consistent
+   - Requirements IDs identical
+
+# Next Steps
+
+After requirements are complete:
+1. User reviews and approves
+2. Proceed to design: /sdd-design {{feature-name}}
+3. Or validate compliance: /sdd-validate {{feature-name}}
+
+**Execute requirements generation now.**
+"""

package/src/templates/agents/gemini-cli/commands/sdd-steering.toml

@@ -0,0 +1,209 @@
+name = "sdd-steering"
+description = "Generate or update project memory (steering context)"
+
+[[instructions]]
+role = "system"
+content = """
+You are executing the /sdd-steering command to generate or update the project's steering context.
+
+# What is Steering?
+
+Steering provides **project memory** for all AI agents. It consists of 3 core files that document:
+1. **structure.md** - Architecture patterns, directory structure, naming conventions
+2. **tech.md** - Technology stack, frameworks, tools
+3. **product.md** - Business context, product goals, users
+
+# Mode Detection
+
+Determine which mode to use:
+
+1. **Bootstrap Mode** - No steering files exist
+   - Analyze entire codebase
+   - Generate initial steering files
+   - Create both English (.md) and Japanese (.ja.md) versions
+
+2. **Sync Mode** - Steering files exist, codebase has changed
+   - Compare current steering with codebase
+   - Identify discrepancies
+   - Update steering files to match reality
+   - Preserve both English and Japanese versions
+
+3. **Review Mode** - User wants to review/improve steering
+   - Present current steering
+   - Suggest improvements
+   - Ask user for feedback
+
+# Mode 1: Bootstrap (First Time)
+
+## Detection
+- `steering/` directory doesn't exist OR
+- `steering/structure.md`, `steering/tech.md`, `steering/product.md` don't exist
+
+## Steps
+
+1. **Analyze Codebase**:
+   - Directory structure
+   - File organization patterns
+   - Technology stack (package.json, requirements.txt, go.mod, etc.)
+   - Frameworks detected
+   - Database technologies
+   - API patterns
+   - Testing frameworks
+   - Build tools
+   - Deployment configurations
+
+2. **Infer Product Context**:
+   - README.md analysis
+   - Package descriptions
+   - Domain concepts from code
+   - User types from code
+
+3. **Generate Steering Files** (Bilingual):
+
+   **IMPORTANT**: Create BOTH English and Japanese versions for each file.
+   **English version is always the reference/source.**
+
+   Create `steering/structure.md` (English) with:
+   - Architecture pattern (monolith, microservices, library-first, etc.)
+   - Directory organization rules
+   - Naming conventions
+   - Component boundaries
+   - Integration patterns
+
+   Create `steering/structure.ja.md` (Japanese) with:
+   - Translation of structure.md content
+   - All technical terms consistent with English version
+
+   Create `steering/tech.md` (English) with:
+   - Primary language(s) and versions
+   - Frameworks and versions
+   - Database(s) and versions
+   - API technologies (REST, GraphQL, gRPC)
+   - Testing frameworks
+   - Build/deployment tools
+   - Development tools
+
+   Create `steering/tech.ja.md` (Japanese) with:
+   - Translation of tech.md content
+   - Technology names kept in English with Japanese explanations
+
+   Create `steering/product.md` (English) with:
+   - Product vision (inferred from README)
+   - Target users (inferred from code)
+   - Core capabilities
+   - Business domain
+   - Success metrics (if available)
+
+   Create `steering/product.ja.md` (Japanese) with:
+   - Translation of product.md content
+   - Product terminology consistent with English version
+
+4. **Bilingual File Generation**:
+   - Generate English version (.md) FIRST
+   - Then generate Japanese translation (.ja.md)
+   - English version is the reference for all agents
+   - Japanese version for Japanese-speaking team members
+
+5. **Create Rules Directory**:
+   - Copy constitutional governance files
+   - Copy workflow guide
+   - Copy EARS format guide
+
+## Output
+
+Present summary with created files and key findings.
+
+# Mode 2: Sync (Update Existing)
+
+## Detection
+- Steering files exist
+- Codebase may have changed since last steering update
+
+## Steps
+
+1. **Read Current Steering**:
+   - Read `steering/structure.md`
+   - Read `steering/tech.md`
+   - Read `steering/product.md`
+
+2. **Analyze Current Codebase**:
+   - Same analysis as Bootstrap mode
+   - Compare with current steering
+
+3. **Detect Discrepancies**:
+   - New technologies added?
+   - Architecture changed?
+   - New components added?
+   - Directory structure evolved?
+
+4. **Update Steering Files** (Bilingual):
+   - Update English version (.md) FIRST
+   - Update sections that changed
+   - Preserve sections that are still accurate
+   - Add changelog entries
+   - Then update Japanese version (.ja.md) to match
+   - Ensure both versions stay synchronized
+
+5. **Generate Sync Report**:
+   - List changes detected
+   - Show updated files
+   - Note files with no changes
+
+# Mode 3: Review (User-Initiated Review)
+
+## Steps
+
+1. **Present Current Steering**:
+   - Show current structure.md summary
+   - Show current tech.md summary
+   - Show current product.md summary
+
+2. **Identify Improvement Opportunities**:
+   - Missing information
+   - Outdated information
+   - Unclear sections
+   - Inconsistencies
+
+3. **Ask User for Feedback**:
+   - Get user confirmation on changes
+   - Update based on feedback
+
+# Constitutional Compliance
+
+This command supports **Article VI: Project Memory**:
+> All agents SHALL consult project memory (steering files) before making decisions.
+
+By maintaining accurate steering files, all agents can:
+- Make context-aware decisions
+- Follow established patterns
+- Align with product goals
+- Use correct technologies
+
+# Validation
+
+After generating/updating steering:
+
+1. **Completeness Check**:
+   - All 3 core files present
+   - Both English and Japanese versions
+   - Rules directory populated
+
+2. **Accuracy Check**:
+   - Technologies match package.json
+   - Architecture matches codebase structure
+   - Product context aligns with README
+
+3. **Consistency Check**:
+   - English and Japanese versions match
+   - No contradictions between files
+   - Steering aligns with constitutional articles
+
+# Next Steps
+
+Once steering is complete, users can:
+1. Review and adjust steering files manually
+2. Proceed with requirements analysis: /sdd-requirements [feature]
+3. Use any command (they will now have project context)
+
+**Execute steering generation/update now.**
+"""