myaidev-method 0.2.23 → 0.2.24-2

package/skills/sparc-coder/SKILL.md

@@ -0,0 +1,136 @@
+---
+name: sparc-coder
+description: SPARC Pseudocode/Architecture phase - Implementation and coding
+argument-hint: [spec-file] [--implement]
+allowed-tools: [Read, Write, Edit, Glob, Grep, Bash, Task]
+user-invocable: true
+category: development
+version: 1.0.0
+platforms: [claude-code, gemini-cli, codex-cli]
+---
+
+# SPARC Coder Skill
+
+The Pseudocode and Architecture implementation phases of the SPARC methodology. Transform specifications into working code following established patterns.
+
+## SPARC Methodology
+
+**S**pecification → **P**seudocode → **A**rchitecture → **R**efinement → **C**ompletion
+
+This skill handles the **Pseudocode (P)** and **Architecture (A)** phases, transforming designs into implementation.
+
+## Capabilities
+
+- Implement features from specifications
+- Follow existing codebase patterns and conventions
+- Generate clean, well-documented code
+- Create necessary tests alongside implementation
+- Handle error cases and edge conditions
+- Integrate with existing systems
+
+## Process
+
+1. **Specification Review**
+   - Read and understand the technical specification
+   - Identify implementation requirements
+   - Map components to files/modules
+
+2. **Pseudocode Planning**
+   - Create pseudocode for complex logic
+   - Plan function signatures and interfaces
+   - Identify shared utilities needed
+
+3. **Implementation**
+   - Write code following project conventions
+   - Implement in logical, testable chunks
+   - Add appropriate comments and documentation
+   - Handle errors gracefully
+
+4. **Self-Review**
+   - Check against specification
+   - Verify edge cases handled
+   - Ensure code is readable and maintainable
+
+## Coding Standards
+
+### General Principles
+- Follow existing codebase conventions
+- Prefer composition over inheritance
+- Write self-documenting code
+- Keep functions small and focused
+- Handle errors at appropriate levels
+
+### Documentation
+- Add JSDoc/docstrings for public APIs
+- Explain "why" not "what" in comments
+- Document non-obvious decisions
+
+### Error Handling
+```javascript
+// Good: Specific error handling
+try {
+  await saveUser(user);
+} catch (error) {
+  if (error instanceof ValidationError) {
+    return { success: false, errors: error.details };
+  }
+  throw error; // Re-throw unexpected errors
+}
+```
+
+## Parameters
+
+| Parameter | Description | Default |
+|-----------|-------------|---------|
+| `spec-file` | Path to specification file | Required |
+| `--implement` | Start implementation immediately | false |
+| `--module` | Target module/directory | auto-detect |
+| `--tests` | Generate tests alongside code | true |
+| `--dry-run` | Show plan without writing code | false |
+
+## Example Usage
+
+```bash
+# Implement from specification
+/myaidev-method:coder "./specs/auth-feature.md" --implement
+
+# Preview implementation plan
+/myaidev-method:coder "./specs/payment-integration.md" --dry-run
+
+# Implement specific module
+/myaidev-method:coder "./specs/api-endpoints.md" --module=src/api
+
+# Legacy command
+/myai-dev-code "./specs/user-management.md"
+```
+
+## Integration
+
+- Receives input from `/myaidev-method:architect`
+- Output reviewed by `/myaidev-method:reviewer`
+- Tests validated by `/myaidev-method:tester`
+- Part of `/myaidev-method:sparc` full workflow
+
+## Output Structure
+
+```
+src/
+├── [feature]/
+│   ├── index.ts          # Public API
+│   ├── [component].ts    # Implementation
+│   ├── types.ts          # TypeScript types
+│   └── utils.ts          # Utilities
+tests/
+└── [feature]/
+    ├── [component].test.ts
+    └── integration.test.ts
+```
+
+## Best Practices
+
+1. **Read Before Write**: Always understand existing patterns first
+2. **Small Commits**: Make incremental, focused changes
+3. **Test Coverage**: Write tests for new functionality
+4. **Clean as You Go**: Don't leave TODO comments in committed code
+5. **Error Messages**: Make errors helpful for debugging
+6. **Security**: Never commit secrets or sensitive data

package/skills/sparc-documenter/SKILL.md

@@ -0,0 +1,195 @@
+---
+name: sparc-documenter
+description: SPARC Completion phase - Documentation generation and maintenance
+argument-hint: [path] [--type=api]
+allowed-tools: [Read, Write, Edit, Glob, Grep, Task]
+user-invocable: true
+category: development
+version: 1.0.0
+platforms: [claude-code, gemini-cli, codex-cli]
+---
+
+# SPARC Documenter Skill
+
+The Completion phase of the SPARC methodology focused on documentation. Generate comprehensive documentation for code, APIs, and features.
+
+## SPARC Methodology
+
+**S**pecification → **P**seudocode → **A**rchitecture → **R**efinement → **C**ompletion
+
+This skill handles the **Completion (C)** phase, ensuring proper documentation.
+
+## Capabilities
+
+- Generate API documentation
+- Create README files
+- Document code with JSDoc/docstrings
+- Generate architecture documentation
+- Create user guides and tutorials
+- Update changelog entries
+- Generate TypeScript declarations
+
+## Documentation Types
+
+| Type | Output | Use Case |
+|------|--------|----------|
+| `api` | API reference | HTTP endpoints, SDK methods |
+| `code` | JSDoc/docstrings | Functions, classes, modules |
+| `readme` | README.md | Project overview |
+| `architecture` | Architecture docs | System design |
+| `guide` | User guide | How-to documentation |
+| `changelog` | CHANGELOG.md | Version history |
+| `types` | TypeScript .d.ts | Type definitions |
+
+## Process
+
+1. **Code Analysis**
+   - Parse source files
+   - Extract function signatures
+   - Identify public APIs
+   - Understand code purpose
+
+2. **Documentation Generation**
+   - Generate appropriate doc format
+   - Add usage examples
+   - Include parameter descriptions
+   - Document return values and errors
+
+3. **Quality Check**
+   - Verify completeness
+   - Check for accuracy
+   - Ensure consistency
+
+4. **Integration**
+   - Update existing docs
+   - Add to documentation site
+   - Update README links
+
+## API Documentation Template
+
+```markdown
+# API Reference
+
+## Overview
+[Brief description of the API]
+
+## Authentication
+[Auth requirements and examples]
+
+## Endpoints
+
+### `POST /api/resource`
+Create a new resource.
+
+**Request Body:**
+```json
+{
+  "name": "string",
+  "value": "number"
+}
+```
+
+**Response:**
+```json
+{
+  "id": "string",
+  "name": "string",
+  "createdAt": "ISO8601"
+}
+```
+
+**Errors:**
+| Code | Description |
+|------|-------------|
+| 400 | Invalid request body |
+| 401 | Unauthorized |
+| 409 | Resource already exists |
+
+**Example:**
+```bash
+curl -X POST https://api.example.com/resource \
+  -H "Authorization: Bearer TOKEN" \
+  -d '{"name": "test"}'
+```
+```
+
+## JSDoc Template
+
+```javascript
+/**
+ * Process user data and return formatted result.
+ *
+ * @param {Object} user - The user object to process
+ * @param {string} user.id - Unique user identifier
+ * @param {string} user.name - User's display name
+ * @param {Object} [options] - Optional processing options
+ * @param {boolean} [options.includeMetadata=false] - Include metadata
+ * @returns {Promise<ProcessedUser>} Processed user data
+ * @throws {ValidationError} If user data is invalid
+ * @example
+ * const processed = await processUser({ id: '123', name: 'John' });
+ */
+async function processUser(user, options = {}) {
+  // Implementation
+}
+```
+
+## Parameters
+
+| Parameter | Description | Default |
+|-----------|-------------|---------|
+| `path` | File or directory to document | Required |
+| `--type` | Documentation type | api |
+| `--output` | Output directory | ./docs |
+| `--format` | markdown, html, json | markdown |
+| `--update` | Update existing docs | false |
+
+## Example Usage
+
+```bash
+# Generate API documentation
+/myaidev-method:documenter ./src/api --type=api
+
+# Add JSDoc to code
+/myaidev-method:documenter ./src/utils --type=code
+
+# Generate README
+/myaidev-method:documenter ./ --type=readme
+
+# Update changelog
+/myaidev-method:documenter --type=changelog --update
+
+# Legacy command
+/myai-dev-docs ./src
+```
+
+## Integration
+
+- Documents code from `/myaidev-method:coder`
+- Uses review insights from `/myaidev-method:reviewer`
+- Final phase of `/myaidev-method:sparc` workflow
+
+## Output Structure
+
+```
+docs/
+├── README.md           # Project overview
+├── API.md              # API reference
+├── ARCHITECTURE.md     # System design
+├── CHANGELOG.md        # Version history
+├── guides/
+│   ├── getting-started.md
+│   └── advanced-usage.md
+└── api/
+    ├── endpoints.md
+    └── types.md
+```
+
+## Best Practices
+
+1. **Write for the Reader**: Consider who will read the docs
+2. **Include Examples**: Code examples clarify usage
+3. **Keep Updated**: Stale docs are worse than none
+4. **Be Concise**: Brevity is valuable
+5. **Link Related Content**: Help readers navigate
+6. **Version Docs**: Match docs to code versions

package/skills/sparc-reviewer/SKILL.md

@@ -0,0 +1,179 @@
+---
+name: sparc-reviewer
+description: SPARC Refinement phase - Code review and quality assessment
+argument-hint: [path] [--focus=security]
+allowed-tools: [Read, Glob, Grep, Task, WebSearch]
+user-invocable: true
+category: development
+version: 1.0.0
+platforms: [claude-code, gemini-cli, codex-cli]
+---
+
+# SPARC Reviewer Skill
+
+The Refinement phase of the SPARC methodology focused on code review. Perform comprehensive code reviews, identify issues, and suggest improvements.
+
+## SPARC Methodology
+
+**S**pecification → **P**seudocode → **A**rchitecture → **R**efinement → **C**ompletion
+
+This skill handles the **Refinement (R)** phase, ensuring code quality through review.
+
+## Capabilities
+
+- Code quality assessment
+- Security vulnerability detection
+- Performance issue identification
+- Best practice verification
+- Style and convention checking
+- Documentation completeness review
+- Dependency audit
+
+## Review Categories
+
+| Category | Focus Areas |
+|----------|-------------|
+| **Quality** | Readability, maintainability, complexity |
+| **Security** | Vulnerabilities, input validation, secrets |
+| **Performance** | Efficiency, memory usage, async patterns |
+| **Architecture** | Design patterns, SOLID principles, coupling |
+| **Testing** | Coverage, test quality, edge cases |
+| **Documentation** | Comments, README, API docs |
+
+## Process
+
+1. **Code Analysis**
+   - Read and understand the code
+   - Identify the purpose and context
+   - Note patterns and anti-patterns
+
+2. **Issue Detection**
+   - Check for bugs and logic errors
+   - Identify security vulnerabilities
+   - Find performance bottlenecks
+   - Note code smells
+
+3. **Improvement Suggestions**
+   - Recommend refactoring opportunities
+   - Suggest better patterns
+   - Propose documentation additions
+
+4. **Report Generation**
+   - Categorize findings by severity
+   - Provide actionable recommendations
+   - Highlight positive aspects
+
+## Review Output Format
+
+```markdown
+# Code Review: [File/Feature Name]
+
+## Summary
+- **Files Reviewed**: X
+- **Critical Issues**: X
+- **Warnings**: X
+- **Suggestions**: X
+- **Overall Score**: X/10
+
+## Critical Issues 🔴
+### [Issue Title]
+- **Location**: `file.ts:123`
+- **Description**: [What's wrong]
+- **Impact**: [Why it matters]
+- **Suggestion**: [How to fix]
+
+## Warnings 🟡
+### [Warning Title]
+- **Location**: `file.ts:45`
+- **Description**: [The concern]
+- **Suggestion**: [Improvement]
+
+## Suggestions 🟢
+### [Suggestion Title]
+- **Description**: [What could be better]
+- **Benefit**: [Why it helps]
+
+## Positive Highlights ✨
+- [Good practice observed]
+- [Well-written code example]
+
+## Recommendations
+1. [Priority action 1]
+2. [Priority action 2]
+3. [Priority action 3]
+```
+
+## Severity Levels
+
+| Level | Icon | Criteria |
+|-------|------|----------|
+| Critical | 🔴 | Security vulnerabilities, data loss, crashes |
+| Warning | 🟡 | Bugs, performance issues, bad practices |
+| Suggestion | 🟢 | Improvements, refactoring, style |
+| Info | 🔵 | Notes, alternatives, best practices |
+
+## Parameters
+
+| Parameter | Description | Default |
+|-----------|-------------|---------|
+| `path` | File or directory to review | Required |
+| `--focus` | security, performance, quality, all | all |
+| `--severity` | Filter by minimum severity | suggestion |
+| `--output` | Output format: markdown, json | markdown |
+| `--pr` | Review as PR (GitHub integration) | false |
+
+## Example Usage
+
+```bash
+# Full code review
+/myaidev-method:reviewer ./src/auth
+
+# Security-focused review
+/myaidev-method:reviewer ./src/api --focus=security
+
+# Performance review
+/myaidev-method:reviewer ./src/utils --focus=performance
+
+# Review a specific file
+/myaidev-method:reviewer ./src/auth/login.ts
+
+# Legacy command
+/myai-dev-review ./src
+```
+
+## Integration
+
+- Reviews code from `/myaidev-method:coder`
+- Validates test coverage from `/myaidev-method:tester`
+- Part of `/myaidev-method:sparc` full workflow
+
+## Common Issues Detected
+
+### Security
+- Hardcoded secrets
+- SQL injection vulnerabilities
+- XSS vulnerabilities
+- Insecure dependencies
+- Missing input validation
+
+### Performance
+- N+1 queries
+- Unnecessary re-renders
+- Memory leaks
+- Inefficient algorithms
+- Missing caching
+
+### Quality
+- Complex functions (high cyclomatic complexity)
+- Duplicate code
+- Inconsistent naming
+- Missing error handling
+- Poor separation of concerns
+
+## Best Practices
+
+1. **Be Constructive**: Focus on improvement, not criticism
+2. **Explain Why**: Context helps more than just "fix this"
+3. **Prioritize**: Focus on impactful issues first
+4. **Acknowledge Good Code**: Positive feedback matters
+5. **Be Specific**: Vague feedback is unhelpful

package/skills/sparc-tester/SKILL.md

@@ -0,0 +1,156 @@
+---
+name: sparc-tester
+description: SPARC Refinement phase - Testing and quality assurance
+argument-hint: [path] [--coverage] [--type=unit]
+allowed-tools: [Read, Write, Edit, Bash, Glob, Grep, Task]
+user-invocable: true
+category: development
+version: 1.0.0
+platforms: [claude-code, gemini-cli, codex-cli]
+---
+
+# SPARC Tester Skill
+
+The Refinement phase of the SPARC methodology focused on testing. Create comprehensive tests, run test suites, and ensure code quality through systematic testing.
+
+## SPARC Methodology
+
+**S**pecification → **P**seudocode → **A**rchitecture → **R**efinement → **C**ompletion
+
+This skill handles the **Refinement (R)** phase, ensuring code quality through testing.
+
+## Capabilities
+
+- Generate unit tests for components
+- Create integration tests for workflows
+- Run existing test suites
+- Analyze code coverage
+- Identify untested code paths
+- Generate test fixtures and mocks
+- Validate against specifications
+
+## Test Types
+
+| Type | Scope | Tools |
+|------|-------|-------|
+| Unit | Single function/component | Jest, Vitest, Mocha |
+| Integration | Multiple components | Jest, Playwright |
+| E2E | Full user flow | Playwright, Cypress |
+| API | HTTP endpoints | Supertest, REST Client |
+| Performance | Load/stress | Artillery, k6 |
+
+## Process
+
+1. **Analysis**
+   - Identify testable units
+   - Map code paths to test cases
+   - Check existing coverage
+
+2. **Test Generation**
+   - Write test cases for happy paths
+   - Add edge case tests
+   - Create error scenario tests
+   - Generate fixtures/mocks
+
+3. **Execution**
+   - Run test suites
+   - Collect coverage data
+   - Report failures
+
+4. **Validation**
+   - Verify against specifications
+   - Check coverage thresholds
+   - Document test gaps
+
+## Test Template
+
+```javascript
+import { describe, it, expect, beforeEach, vi } from 'vitest';
+import { functionUnderTest } from './module';
+
+describe('functionUnderTest', () => {
+  beforeEach(() => {
+    // Setup
+  });
+
+  describe('happy path', () => {
+    it('should handle valid input correctly', () => {
+      const result = functionUnderTest(validInput);
+      expect(result).toEqual(expectedOutput);
+    });
+  });
+
+  describe('edge cases', () => {
+    it('should handle empty input', () => {
+      expect(() => functionUnderTest('')).toThrow();
+    });
+
+    it('should handle boundary values', () => {
+      // Test boundary conditions
+    });
+  });
+
+  describe('error handling', () => {
+    it('should throw on invalid input', () => {
+      expect(() => functionUnderTest(null)).toThrow(TypeError);
+    });
+  });
+});
+```
+
+## Parameters
+
+| Parameter | Description | Default |
+|-----------|-------------|---------|
+| `path` | File or directory to test | ./src |
+| `--type` | unit, integration, e2e, all | unit |
+| `--coverage` | Generate coverage report | false |
+| `--watch` | Run in watch mode | false |
+| `--update-snapshots` | Update snapshot tests | false |
+| `--generate` | Generate missing tests | false |
+
+## Example Usage
+
+```bash
+# Run all tests
+/myaidev-method:tester --type=all
+
+# Generate tests for a module
+/myaidev-method:tester ./src/auth --generate
+
+# Run with coverage
+/myaidev-method:tester ./src --coverage
+
+# Integration tests only
+/myaidev-method:tester --type=integration
+
+# Legacy command
+/myai-dev-test ./src/api
+```
+
+## Coverage Thresholds
+
+Default thresholds for quality gates:
+
+| Metric | Minimum |
+|--------|---------|
+| Statements | 80% |
+| Branches | 75% |
+| Functions | 80% |
+| Lines | 80% |
+
+## Integration
+
+- Tests code from `/myaidev-method:coder`
+- Results feed into `/myaidev-method:reviewer`
+- Part of `/myaidev-method:sparc` full workflow
+
+## Best Practices
+
+1. **Test Behavior, Not Implementation**: Focus on what code does, not how
+2. **One Assertion Per Test**: Keep tests focused and clear
+3. **Arrange-Act-Assert**: Structure tests consistently
+4. **Descriptive Names**: Test names should describe expected behavior
+5. **Isolated Tests**: Tests shouldn't depend on each other
+6. **Fast Tests**: Unit tests should run in milliseconds
+7. **Realistic Fixtures**: Use production-like test data