@soulcraft/kits 1.0.0

package/kits/technical-specification/skills/data-modeling/SKILL.md

@@ -0,0 +1,159 @@
+---
+id: data-modeling
+name: data-modeling
+description: Design data models with proper normalization and relationship mapping
+version: "1.0.0"
+type: invocable
+requiresVision: true
+requiresData: false
+---
+
+## Data Modeling Skill
+
+When the user invokes `/data-model`, help them design database schemas and data models.
+
+### Invocation Patterns
+
+- `/data-model` - Design data model for current feature
+- `/data-model [entity]` - Model specific entity
+- `/data-model normalize` - Review and normalize existing model
+
+### Entity-Relationship Modeling
+
+**Identify Entities**
+- Nouns in requirements become entities
+- Must have unique identifier
+- Has multiple attributes
+
+**Define Relationships**
+- One-to-One (1:1): User ↔ Profile
+- One-to-Many (1:N): Author → Books
+- Many-to-Many (M:N): Students ↔ Courses
+
+**Cardinality Notation**
+```
+User ||--o{ Order : places
+(one user places zero or more orders)
+
+Order ||--|{ OrderItem : contains
+(one order contains one or more items)
+
+Student }o--o{ Course : enrolls
+(many students enroll in many courses)
+```
+
+### Normalization Forms
+
+**1NF (First Normal Form)**
+- Eliminate repeating groups
+- Create separate tables for related data
+- Identify each row with unique key
+
+**2NF (Second Normal Form)**
+- Meet 1NF requirements
+- Remove partial dependencies
+- All non-key attributes depend on entire primary key
+
+**3NF (Third Normal Form)**
+- Meet 2NF requirements
+- Remove transitive dependencies
+- Non-key attributes depend only on primary key
+
+**When to Denormalize**
+- Read-heavy workloads
+- Reporting/analytics
+- Performance requirements
+- Calculated/derived fields
+
+### Output Format
+
+```markdown
+## Data Model: [Feature/Domain]
+
+### Entity-Relationship Diagram
+```mermaid
+erDiagram
+    USER ||--o{ ORDER : places
+    ORDER ||--|{ ORDER_ITEM : contains
+    PRODUCT ||--o{ ORDER_ITEM : "ordered in"
+```
+
+### Entity Definitions
+
+#### User
+| Field | Type | Constraints | Description |
+|-------|------|-------------|-------------|
+| id | UUID | PK | Unique identifier |
+| email | VARCHAR(255) | UNIQUE, NOT NULL | Login email |
+| created_at | TIMESTAMP | NOT NULL, DEFAULT NOW | Creation time |
+
+#### Order
+| Field | Type | Constraints | Description |
+|-------|------|-------------|-------------|
+| id | UUID | PK | Unique identifier |
+| user_id | UUID | FK → User.id, NOT NULL | Customer |
+| status | ENUM | NOT NULL | Order status |
+| total | DECIMAL(10,2) | NOT NULL | Order total |
+
+### Relationships
+| Relationship | Type | Description |
+|--------------|------|-------------|
+| User → Order | 1:N | A user can have many orders |
+| Order → OrderItem | 1:N | An order has many items |
+
+### Indexes
+| Table | Index | Columns | Type | Rationale |
+|-------|-------|---------|------|-----------|
+| Order | idx_user_orders | user_id | B-tree | Query by user |
+| Order | idx_status | status | B-tree | Filter by status |
+
+### Constraints
+- `user_id` must reference existing user
+- `total` must be >= 0
+- `status` must be valid enum value
+
+### Migration Notes
+[Any migration considerations]
+```
+
+### Best Practices
+
+**Primary Keys**
+- Use UUIDs for distributed systems
+- Auto-increment for simple cases
+- Avoid natural keys as PKs (can change)
+
+**Foreign Keys**
+- Always define FK constraints
+- Consider ON DELETE behavior
+- Index foreign keys
+
+**Naming Conventions**
+- snake_case for columns
+- Singular table names (user, not users)
+- Descriptive relationship names
+
+**Data Types**
+- Use appropriate precision (DECIMAL vs FLOAT)
+- VARCHAR with reasonable limits
+- TIMESTAMP for dates (with timezone)
+
+### Common Patterns
+
+**Soft Deletes**
+```sql
+deleted_at TIMESTAMP NULL
+```
+
+**Audit Fields**
+```sql
+created_at TIMESTAMP NOT NULL DEFAULT NOW()
+updated_at TIMESTAMP NOT NULL DEFAULT NOW()
+created_by UUID REFERENCES user(id)
+```
+
+**Polymorphic Relationships**
+```sql
+commentable_type VARCHAR(50)  -- 'post' or 'photo'
+commentable_id UUID
+```

package/kits/technical-specification/skills/define-component/SKILL.md

@@ -0,0 +1,43 @@
+---
+id: define-component
+name: Define System Component
+description: Document a system component with interfaces and responsibilities
+version: "1.0.0"
+type: invocable
+parameters: [componentName, purpose]
+requiresVision: false
+requiresData: false
+---
+
+## Define System Component
+
+Document a system component with interfaces and responsibilities
+
+### Steps
+
+1. Name and describe the component purpose
+2. Define the component boundaries and responsibilities
+3. Specify the interfaces (APIs) the component exposes
+4. Document dependencies on other components or services
+5. Define data models owned by this component
+6. Specify technology stack and constraints
+7. Document deployment and scaling requirements
+8. Add the component to the architecture diagram
+
+### Inputs Required
+
+- **componentName** (required): Name of the component
+- **purpose** (required): Primary responsibility of the component
+
+### Expected Outputs
+
+- Component specification
+- Updated architecture diagram
+
+### When to Use
+
+This workflow is helpful when the user mentions:
+- "new component"
+- "define component"
+- "service spec"
+- "microservice"

package/kits/technical-specification/skills/kit-expertise/SKILL.md

@@ -0,0 +1,81 @@
+---
+id: kit-expertise
+name: kit-expertise
+description: Domain expertise for Technical Specification - applied automatically when working in this kit
+version: "1.0.0"
+type: background
+requiresVision: false
+requiresData: false
+---
+
+## Your Role
+
+Technical Architect helping you create detailed, implementable technical specifications
+
+## Your Expertise
+
+- Technical writing
+- System architecture design
+- API specification
+- Data modeling
+- Trade-off analysis
+- Security considerations
+- Performance requirements
+- Implementation planning
+
+## Your Approach
+
+Work alongside the user as a creative partner
+
+## Things to Avoid
+
+- Vague technical descriptions
+- Ignoring edge cases
+- Missing security considerations
+- Undocumented assumptions
+
+## Domain Knowledge
+
+### Key Terms
+
+**architecture**
+High-level structure of the system
+
+**component**
+Modular part of the system
+
+**interface**
+Contract between components
+
+**data model**
+Structure of stored information
+
+**sequence diagram**
+Flow of operations over time
+
+**trade-off**
+Decision between competing concerns
+
+**constraint**
+Limitation on the solution
+
+**non-functional requirement**
+Quality attribute (performance, security)
+
+### Best Practices
+
+- Start with problem statement
+- Document all assumptions
+- Include diagrams for architecture
+- Specify error handling
+- Address security explicitly
+- Define testing strategy
+
+### Common Mistakes to Avoid
+
+- Implementation before specification
+- Missing error scenarios
+- Undocumented dependencies
+- No rollback strategy
+- Ignoring scalability
+- Vague performance requirements

package/kits/technical-specification/skills/requirements-analysis/SKILL.md

@@ -0,0 +1,42 @@
+---
+id: requirements-analysis
+name: Analyze Requirements
+description: Break down high-level requirements into detailed specifications
+version: "1.0.0"
+type: invocable
+parameters: [requirement]
+requiresVision: false
+requiresData: false
+---
+
+## Analyze Requirements
+
+Break down high-level requirements into detailed specifications
+
+### Steps
+
+1. Review the high-level requirement or user story
+2. Identify functional requirements - what the system must do
+3. Identify non-functional requirements - quality attributes
+4. Define acceptance criteria for each requirement
+5. Estimate complexity and dependencies
+6. Identify risks and unknowns
+7. Prioritize using MoSCoW or similar framework
+8. Update the requirements section
+
+### Inputs Required
+
+- **requirement** (required): The requirement or user story to analyze
+
+### Expected Outputs
+
+- Detailed requirement specifications
+- Acceptance criteria
+
+### When to Use
+
+This workflow is helpful when the user mentions:
+- "analyze requirement"
+- "break down"
+- "detail requirement"
+- "acceptance criteria"

package/kits/technical-specification/skills/security-review/SKILL.md

@@ -0,0 +1,170 @@
+---
+id: security-review
+name: security-review
+description: Security considerations, threat modeling, and secure design review
+version: "1.0.0"
+type: invocable
+requiresVision: false
+requiresData: false
+---
+
+## Security Review Skill
+
+When the user invokes `/security`, help them identify security considerations and perform threat modeling for their technical specifications.
+
+### Invocation Patterns
+
+- `/security` - Full security review of current spec
+- `/security threats` - Threat modeling (STRIDE)
+- `/security auth` - Authentication/authorization review
+- `/security data` - Data protection review
+
+### STRIDE Threat Model
+
+**S - Spoofing**
+- Can attackers impersonate users/systems?
+- Authentication weaknesses
+- Session hijacking risks
+
+**T - Tampering**
+- Can data be modified in transit/at rest?
+- Input validation gaps
+- Integrity verification
+
+**R - Repudiation**
+- Can users deny actions?
+- Audit logging gaps
+- Non-repudiation measures
+
+**I - Information Disclosure**
+- Can sensitive data leak?
+- Error message exposure
+- Encryption requirements
+
+**D - Denial of Service**
+- Can service be disrupted?
+- Rate limiting needs
+- Resource exhaustion risks
+
+**E - Elevation of Privilege**
+- Can users gain unauthorized access?
+- Authorization bypasses
+- Privilege escalation paths
+
+### Output Format
+
+```markdown
+## Security Review: [Feature/Component]
+
+### Threat Model Summary
+| Threat Category | Risk Level | Mitigations Required |
+|-----------------|------------|---------------------|
+| Spoofing | High | [List] |
+| Tampering | Medium | [List] |
+| Repudiation | Low | [List] |
+| Info Disclosure | High | [List] |
+| Denial of Service | Medium | [List] |
+| Elevation of Privilege | High | [List] |
+
+### Data Flow Diagram
+[ASCII or description of data flows with trust boundaries]
+
+### Assets
+| Asset | Sensitivity | Protection Required |
+|-------|-------------|-------------------|
+| User credentials | Critical | Encryption, hashing |
+| PII | High | Encryption, access control |
+| Session tokens | High | Secure storage, expiration |
+
+### Threat Analysis
+
+#### T1: [Threat Name]
+- **Category**: [STRIDE category]
+- **Attack Vector**: [How attack occurs]
+- **Impact**: [What happens if exploited]
+- **Likelihood**: [High/Medium/Low]
+- **Risk**: [Critical/High/Medium/Low]
+- **Mitigation**: [Required countermeasure]
+
+#### T2: [Threat Name]
+[Same format]
+
+### Security Requirements
+
+#### Authentication
+- [ ] [Requirement 1]
+- [ ] [Requirement 2]
+
+#### Authorization
+- [ ] [Requirement 1]
+
+#### Data Protection
+- [ ] [Requirement 1]
+
+#### Logging & Monitoring
+- [ ] [Requirement 1]
+
+### OWASP Top 10 Checklist
+| Vulnerability | Applicable | Status | Notes |
+|--------------|------------|--------|-------|
+| Injection | Yes/No | [Mitigated/Needs work] | |
+| Broken Auth | Yes/No | | |
+| Sensitive Data | Yes/No | | |
+| XXE | Yes/No | | |
+| Broken Access Control | Yes/No | | |
+| Security Misconfig | Yes/No | | |
+| XSS | Yes/No | | |
+| Insecure Deserialization | Yes/No | | |
+| Vulnerable Components | Yes/No | | |
+| Insufficient Logging | Yes/No | | |
+
+### Recommendations
+1. **Critical**: [Action needed]
+2. **High**: [Action needed]
+3. **Medium**: [Action needed]
+```
+
+### Authentication Checklist
+
+- [ ] Strong password requirements
+- [ ] Account lockout after failed attempts
+- [ ] Secure password storage (bcrypt/argon2)
+- [ ] Multi-factor authentication option
+- [ ] Secure session management
+- [ ] Session timeout
+- [ ] Secure cookie flags (HttpOnly, Secure, SameSite)
+
+### Authorization Checklist
+
+- [ ] Principle of least privilege
+- [ ] Role-based access control
+- [ ] Resource-level permissions
+- [ ] Server-side validation (never trust client)
+- [ ] Indirect object references
+
+### Data Protection Checklist
+
+- [ ] Encryption in transit (TLS 1.3)
+- [ ] Encryption at rest
+- [ ] Data classification
+- [ ] PII handling compliance
+- [ ] Data retention policies
+- [ ] Secure deletion
+
+### Common Vulnerabilities
+
+**Injection**
+- SQL, NoSQL, LDAP, OS commands
+- Mitigation: Parameterized queries, input validation
+
+**XSS**
+- Stored, reflected, DOM-based
+- Mitigation: Output encoding, CSP headers
+
+**CSRF**
+- Cross-site request forgery
+- Mitigation: CSRF tokens, SameSite cookies
+
+**IDOR**
+- Insecure direct object references
+- Mitigation: Authorization checks, indirect references

package/kits/technical-specification/skills/spec-review/SKILL.md

@@ -0,0 +1,39 @@
+---
+id: spec-review
+name: Review Technical Spec
+description: Comprehensive review of technical specification for completeness
+version: "1.0.0"
+type: invocable
+requiresVision: false
+requiresData: false
+---
+
+## Review Technical Spec
+
+Comprehensive review of technical specification for completeness
+
+### Steps
+
+1. Verify problem statement and goals are clear
+2. Check that all functional requirements have acceptance criteria
+3. Verify non-functional requirements have measurable targets
+4. Review architecture for scalability and fault tolerance
+5. Check security considerations are addressed
+6. Verify data model is complete and normalized appropriately
+7. Review API contracts for consistency
+8. Check that deployment and operations are documented
+9. Identify open questions and risks
+10. Provide recommendations for improvement
+
+### Expected Outputs
+
+- Spec review report
+- Open questions list
+
+### When to Use
+
+This workflow is helpful when the user mentions:
+- "review spec"
+- "spec review"
+- "is the spec complete"
+- "check spec"