trinity-method-sdk 2.0.0

package/dist/templates/shared/claude-commands/trinity-create-investigation.md.template

@@ -0,0 +1,232 @@
+---
+description: Launch the Investigation Wizard to create structured investigations
+---
+
+Launch the Trinity Method Investigation Wizard to create a structured investigation interactively.
+
+**Investigation Wizard Flow:**
+
+**Step 1: Investigation Type**
+Ask user to select:
+- Bug Investigation
+- Feature Analysis
+- Performance Investigation
+- Security Audit
+- Technical Debt Assessment
+- Architecture Review
+- Custom Investigation
+
+**Step 2: Investigation Details**
+Gather:
+- Investigation title
+- Problem statement
+- Affected components/files
+- Priority (Low/Medium/High/Critical)
+- Estimated complexity
+
+**Step 3: Objectives**
+Define investigation objectives (numbered list):
+- What questions need answering?
+- What hypotheses to test?
+- What outcomes are expected?
+
+**Step 4: Scope**
+Determine investigation scope:
+- Files to analyze
+- Time constraints
+- Resource limits
+- Out-of-scope items
+
+**Step 5: Success Criteria**
+Define completion criteria:
+- What constitutes a successful investigation?
+- Required deliverables
+- Acceptance criteria
+
+**Step 6: Template Selection**
+Offer templates based on investigation type:
+- Standard templates (from trinity/templates/investigations/)
+- Custom templates (from user's template library)
+- Generate new template
+
+**Step 7: Review & Create**
+Show investigation summary and confirm creation.
+
+**Output:**
+Create investigation file at:
+`trinity/investigations/INV-XXX-{title}.md`
+
+**Post-Creation:**
+Ask if user wants to:
+- Start investigation immediately with `/trinity-orchestrate @INV-XXX-{title}.md`
+- Generate investigation plan first (/trinity-plan-investigation)
+- Schedule for later
+
+**Orchestration:**
+Once investigation is created in `trinity/investigations/`, execute it:
+
+```bash
+/trinity-orchestrate @INV-001-example-investigation.md
+```
+
+**AJ MAESTRO** picks up the investigation from `trinity/investigations/` and orchestrates the investigation, leaving findings in `trinity/reports/`.
+
+**CRITICAL: Investigation Protocol**
+⚠️ **INVESTIGATIONS ARE READ-ONLY OPERATIONS**
+
+When executing an investigation:
+- **NO file modifications allowed**
+- **NO code implementations**
+- **NO fixes applied**
+- **ONLY analyze, document, and report findings**
+
+Investigation deliverables:
+- Findings document (what was discovered)
+- Root cause analysis
+- Recommendations (what SHOULD be done)
+- Impact assessment
+
+**Implementation happens SEPARATELY** only after user explicitly requests it based on investigation findings.
+
+---
+
+## Investigation Naming Convention
+
+**Format**: `INV-XXX-{brief-description}.md`
+
+**Components**:
+- **INV**: Investigation prefix (always uppercase)
+- **XXX**: Three-digit sequential number (001, 002, 003...)
+- **brief-description**: Lowercase, hyphenated
+
+**Examples**:
+```
+INV-001-performance-bottleneck-analysis.md
+INV-012-authentication-flow-review.md
+INV-025-database-query-optimization.md
+```
+
+**Auto-Numbering**: System scans `trinity/investigations/` and assigns next number
+
+---
+
+## Real-World Examples
+
+### Example 1: Bug Investigation
+**Title:** "JWT token refresh fails after 24 hours"
+**Template:** Bug Investigation (`bug.md`)
+**Investigation Type:** Bug/Defect
+**Priority:** High
+
+**Key Findings:**
+- Used Five Whys analysis to discover hardcoded 24h token expiration limit
+- Root cause: Configuration constant set during initial development
+- No test coverage for long-lived sessions
+
+**Outcome:**
+- Fixed expiration logic to use configurable value
+- Added tests for token refresh at various time intervals
+- Pattern learned: "Always check for hardcoded time limits in authentication code"
+
+---
+
+### Example 2: Performance Investigation
+**Title:** "Dashboard loads in 8 seconds (target <2s)"
+**Template:** Performance Investigation (`performance.md`)
+**Investigation Type:** Performance Optimization
+**Priority:** Critical
+
+**Key Findings:**
+- Chrome DevTools profiling revealed N+1 query pattern
+- User data loaded individually in loop (500+ queries per page load)
+- No database indexes on frequently queried columns
+
+**Outcome:**
+- Added eager loading to fetch all user data in single query
+- Created compound index on user lookup columns
+- Page load reduced to 1.8s (78% improvement)
+- Set up performance budget alerts to prevent regressions
+
+---
+
+### Example 3: Security Investigation
+**Title:** "SQL injection vulnerability in user search endpoint"
+**Template:** Security Investigation (`security.md`)
+**Investigation Type:** Security Audit
+**Priority:** Critical
+
+**Key Findings:**
+- CVSS Score: 9.1 (Critical)
+- Proof-of-concept demonstrated full database access
+- User input concatenated directly into SQL queries
+- Attack vector: Network-based, no authentication required
+
+**Outcome:**
+- Replaced string concatenation with parameterized queries
+- Added input validation and sanitization layer
+- Implemented Web Application Firewall (WAF) rules
+- Security audit passed, no similar vulnerabilities found
+
+---
+
+### Example 4: Technical Investigation
+**Title:** "Choose state management solution for React dashboard"
+**Template:** Technical Investigation (`technical.md`)
+**Investigation Type:** Architecture Decision
+**Priority:** Medium
+
+**Key Findings:**
+- Evaluated 3 options: Redux, Zustand, React Context
+- Decision matrix weighted: simplicity (30%), performance (25%), learning curve (20%)
+- Zustand scored highest (8.2/10) vs Redux (7.1/10) and Context (6.8/10)
+
+**Outcome:**
+- Architecture Decision Record (ADR) documented choice
+- Zustand selected for lightweight API and minimal boilerplate
+- Migration plan: 3 phases over 2 weeks
+- Team training completed, implementation successful
+
+---
+
+### Example 5: Feature Investigation
+**Title:** "Add two-factor authentication for user accounts"
+**Template:** Feature Investigation (`feature.md`)
+**Investigation Type:** New Feature
+**Priority:** High
+
+**Key Findings:**
+- 12 user stories defined with acceptance criteria
+- Epic breakdown: Setup (2 stories), Core (6 stories), Polish (4 stories)
+- 4-phase implementation plan with rollout strategy
+- Feature flag for gradual deployment (10% → 50% → 100%)
+
+**Outcome:**
+- Successfully launched to 100% of users
+- 40% adoption rate in first 30 days (exceeded 25% target)
+- No security incidents reported
+- User satisfaction (NPS): +15 points
+
+---
+
+## Template Selection Guide
+
+**Use this decision tree:**
+
+```
+Is it a defect or broken functionality?
+  → YES: Use Bug Investigation Template
+
+Is it slow or using too many resources?
+  → YES: Use Performance Investigation Template
+
+Is it a security vulnerability or audit finding?
+  → YES: Use Security Investigation Template
+
+Is it an architecture decision or technical design question?
+  → YES: Use Technical Investigation Template
+
+Is it new functionality or a feature request?
+  → YES: Use Feature Investigation Template
+```
+
+---

package/dist/templates/shared/claude-commands/trinity-decompose.md.template

@@ -0,0 +1,181 @@
+---
+description: Decompose work into atomic tasks using EUS (Task Decomposer)
+---
+
+# Trinity Task Decomposition - EUS
+
+**Agent:** EUS (Task Decomposer)
+**Role:** Break work into atomic tasks following "1 task = 1 commit" rule
+
+## What EUS Does
+
+1. **Atomic Task Breakdown:**
+   - Each task = 1 commit
+   - Maximum 2 hours per task
+   - Single responsibility per task
+   - Clear success criteria
+
+2. **Task Independence:**
+   - Minimal cross-dependencies
+   - Can be tested in isolation
+   - Clear input/output boundaries
+
+3. **Commit Message Planning:**
+   - Conventional commits format
+   - `feat:`, `fix:`, `refactor:`, `test:`, `docs:`
+   - Descriptive and concise
+
+4. **TDD Enforcement:**
+   - RED: Write failing test
+   - GREEN: Minimal code to pass
+   - REFACTOR: Clean up
+   - Each cycle = 1 commit
+
+## Output Format
+
+EUS produces structured JSON handoff:
+```json
+{
+  "atomicTasks": [
+    {
+      "id": 1,
+      "description": "Implement validation logic",
+      "commitMessage": "feat(validator): add input validation",
+      "estimatedTime": "45min",
+      "testStrategy": "Unit tests for edge cases",
+      "successCriteria": "All validation tests pass",
+      "dependencies": []
+    }
+  ],
+  "tddCycles": [
+    {
+      "test": "test description",
+      "implementation": "impl description",
+      "refactor": "refactor description"
+    }
+  ]
+}
+```
+
+## EUS Agent Capabilities
+
+EUS specializes in atomic task decomposition following Trinity principles:
+- **Atomic Breakdown:** "1 task = 1 commit" rule ensures clean version control
+- **TDD Enforcement:** Every task follows RED-GREEN-REFACTOR cycle
+- **Task Independence:** Minimal cross-dependencies enable parallel development
+- **Time Boxing:** Maximum 2 hours per task for manageable implementation
+
+## Integration with Trinity Workflow
+
+EUS's task decomposition follows TRA's strategic planning:
+
+1. **After TRA:** Strategic plan created with high-level tasks
+2. **EUS Decomposition (Claude adopts EUS persona):** Breaks tasks into atomic units (1 commit each)
+3. **KIL Execution:** Each atomic task implemented following TDD cycle
+4. **TDD Cycles:** RED (test) → GREEN (implement) → REFACTOR (clean)
+5. **BAS Quality Gates:** Validate after each atomic task commit
+
+**Example workflow:**
+```
+Phase 3: Implementation
+├── EUS Decomposition: Break plan into atomic tasks
+│   Output: 12 atomic tasks (each ≤2 hours)
+│   Each task = 1 TDD cycle = 1 commit
+│
+└── KIL Implementation: Execute atomic tasks
+    ├── Atomic Task 1: Add validation logic → BAS gates
+    ├── Atomic Task 2: Create service layer → BAS gates
+    ├── Atomic Task 3: Implement error handling → BAS gates
+    └── ... (continue until all tasks complete)
+```
+
+**See Also:** `/trinity-orchestrate` for complete workflow planning
+
+## Scale-Based Task Decomposition
+
+EUS adjusts decomposition granularity based on task scale:
+- **Small workflows:** 2-4 atomic tasks (direct implementation)
+- **Medium workflows:** 6-10 atomic tasks (phased approach)
+- **Large workflows:** 12-20 atomic tasks (comprehensive breakdown)
+
+Each atomic task always follows Trinity principles:
+- Maximum 2 hours duration
+- Single responsibility (one purpose)
+- Clear success criteria (testable)
+- BAS quality gate validation (6 phases)
+
+## Usage
+
+**Provide implementation plan and Claude (as EUS) will decompose into atomic tasks:**
+
+What is the implementation plan? (Or provide TRA's output)
+
+**For complete workflow planning:**
+
+Use `/trinity-orchestrate` to plan your implementation with EUS decomposition as a key phase
+
+---
+
+## Conventional Commits Quick Reference
+
+Trinity uses Conventional Commits for atomic task commits (1 task = 1 commit).
+
+### Format
+
+```
+<type>(<scope>): <subject>
+
+<body>
+
+<footer>
+```
+
+### Types
+
+- **feat**: New feature
+- **fix**: Bug fix
+- **refactor**: Code change (no feature/fix)
+- **test**: Add/update tests
+- **docs**: Documentation only
+- **style**: Formatting (no code change)
+- **perf**: Performance improvement
+- **chore**: Build/tooling changes
+
+### Examples
+
+**Feature**:
+```
+feat(auth): add JWT refresh token endpoint
+
+Implement POST /auth/refresh endpoint with token rotation.
+Uses HttpOnly cookies for security.
+
+Closes #42
+```
+
+**Fix**:
+```
+fix(auth): validate token expiration correctly
+
+Token expiration was checked against wrong timestamp.
+Now uses UTC comparison.
+
+Fixes #128
+```
+
+**Refactor**:
+```
+refactor(validation): extract email validator to utility
+
+Reduces code duplication across 3 files.
+Maintains same validation logic.
+```
+
+### Trinity Best Practices
+
+1. **One Task = One Commit**: Each EUS task gets exactly one commit
+2. **Atomic**: Commit must be complete (tests pass, build succeeds)
+3. **Descriptive**: Subject line explains "what", body explains "why"
+4. **Reference Issues**: Link to work orders (e.g., "WO-042")
+
+---