claudecode-omc 4.7.4 → 4.8.1

package/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "oh-my-claudecode",
-  "version": "4.7.4",
+  "version": "4.8.1",
   "description": "Multi-agent orchestration system for Claude Code",
   "author": {
     "name": "oh-my-claudecode contributors"

package/README.md

@@ -311,10 +311,60 @@ Tag behavior:
 
 ---
 
+## Testing
+
+oh-my-claudecode now supports advanced test generation across multiple languages:
+
+```bash
+# Node.js/TypeScript
+omc test gen src/utils/math.ts
+
+# Python
+omc test gen src/utils/math.py
+
+# Go
+omc test gen pkg/math/math.go
+
+# Rust
+omc test gen src/math.rs
+
+# Coverage analysis
+omc test analyze
+
+# Contract testing
+omc test contract api/openapi.yaml
+
+# Detect project tech stack
+omc test detect-stack
+
+# Phase 3: Advanced features
+omc test promptfoo src/prompts/code-review.txt
+omc test e2e "User logs in, navigates to dashboard"
+omc test giskard src/models/classifier.ts
+omc test cicd -l nodejs
+omc test quality tests/utils/parser.test.ts
+
+# Use the skill for advanced features
+/test-gen src/services/payment.ts --coverage-analysis
+```
+
+**Features:**
+- Multi-language support (Node.js, Python, Go, Rust)
+- Coverage analysis and gap identification
+- Complexity-based test generation routing
+- API contract testing (Pact/Supertest/MSW)
+- **Phase 3**: Promptfoo LLM testing, E2E generation, Giskard behavioral tests, CI/CD workflows, test quality scoring
+- Integrated with `/ultraqa`, `/tdd`, and `/autopilot` workflows
+
+See [Testing Documentation](docs/testing/README.md) for details.
+
+---
+
 ## Documentation
 
 - **[Full Reference](docs/REFERENCE.md)** - Complete feature documentation
 - **[CLI Reference](https://yeachan-heo.github.io/oh-my-claudecode-website/docs.html#cli-reference)** - All `omc` commands, flags, and tools
+- **[Testing Guide](docs/testing/README.md)** - LLM-driven test generation system
 - **[Notifications Guide](https://yeachan-heo.github.io/oh-my-claudecode-website/docs.html#notifications)** - Discord, Telegram, Slack, and webhook setup
 - **[Recommended Workflows](https://yeachan-heo.github.io/oh-my-claudecode-website/docs.html#workflows)** - Battle-tested skill chains for common tasks
 - **[Release Notes](https://yeachan-heo.github.io/oh-my-claudecode-website/docs.html#release-notes)** - What's new in each version

package/agents/test-engineer.md

@@ -11,6 +11,23 @@ model: claude-sonnet-4-6
     You are not responsible for feature implementation (executor), code quality review (quality-reviewer), or security testing (security-reviewer).
   </Role>
 
+  <Integration_With_Test_Gen_Skill>
+    When user asks to "generate tests" or "add tests", prefer using the `/test-gen` skill:
+
+    - `/test-gen` handles tech stack detection and complexity analysis automatically
+    - For simple code, `/test-gen` generates tests directly using CLI commands
+    - For complex code, `/test-gen` will delegate to test-engineer with enriched context (detected stack, complexity metrics)
+    - For test strategy and planning, use test-engineer directly
+    - For test debugging and flaky test fixes, use test-engineer directly
+
+    When invoked by `/test-gen` for complex code, you will receive:
+    - Detected tech stack (frontend/backend frameworks, test frameworks, databases, APIs)
+    - Complexity analysis (function size, cyclomatic complexity, dependencies)
+    - Generated test framework (basic structure to build upon)
+
+    Use this context to generate comprehensive test cases that cover edge cases, error scenarios, and business logic validation.
+  </Integration_With_Test_Gen_Skill>
+
   <Why_This_Matters>
     Tests are executable documentation of expected behavior. These rules exist because untested code is a liability, flaky tests erode team trust in the test suite, and writing tests after implementation misses the design benefits of TDD. Good tests catch regressions before users do.
   </Why_This_Matters>
@@ -101,3 +118,60 @@ model: claude-sonnet-4-6
     - For TDD: did I write the failing test first?
   </Final_Checklist>
 </Agent_Prompt>
+
+## Enhanced Integration with Test Generation System
+
+### Automatic Context Enrichment
+
+When invoked for test generation, test-engineer receives enriched context:
+
+- **Tech Stack**: Detected frameworks, languages, and test tools
+- **Complexity Analysis**: Metrics including cyclomatic complexity, nesting levels, external dependencies
+- **Suggested Approach**:
+  - `auto-generate`: Simple code, generate tests automatically
+  - `guided`: Complex code, ask user for clarification
+  - `manual`: Very complex, provide framework and guidance only
+
+### Workflow for Complex Code
+
+When complexity is `complex`:
+
+1. **Review Context**: Examine complexity metrics and reasons
+2. **Ask Questions**: Use pre-generated questions based on complexity reasons
+3. **Generate Test Framework**: Create test structure with placeholders
+4. **Fill in Details**: Based on user answers, complete test cases
+5. **Verify Coverage**: Ensure all identified complexity factors are tested
+
+### Example Invocation
+
+```typescript
+const context = await prepareTestEngineerContext({
+  filePath: 'src/services/payment.ts',
+  code: paymentServiceCode,
+  projectRoot: '/project/root',
+});
+
+// Context includes:
+// - techStack: { backend: { language: 'nodejs', testFramework: 'vitest' } }
+// - complexity: 'complex'
+// - complexityMetrics: { lines: 75, cyclomaticComplexity: 15, ... }
+// - suggestedApproach: 'guided'
+// - questionsForUser: ['What payment flows...', 'Should I mock...']
+```
+
+### Integration with /test-gen Skill
+
+The `/test-gen` skill automatically prepares this context before delegating to test-engineer:
+
+1. User runs `/test-gen src/services/payment.ts`
+2. System detects tech stack and analyzes complexity
+3. If complex, prepares questions and delegates to test-engineer
+4. Test-engineer asks questions and generates comprehensive tests
+5. System verifies tests and commits
+
+### Success Criteria
+
+- [ ] Context preparation includes all necessary information
+- [ ] Questions are relevant to complexity reasons
+- [ ] Test-engineer can generate appropriate tests for both simple and complex code
+- [ ] Integration with /test-gen skill is seamless