@dragonflymcp/plugin 1.0.0

package/templates/skills/synchronization-patterns.md.template

@@ -0,0 +1,303 @@
+---
+name: Synchronization Patterns
+description: Common patterns and best practices for writing effective synchronization rules in Zen WYSIWID workflows
+version: 1.0.0
+trigger_keywords: [synchronization, sync, workflow, orchestration, rules, patterns, when, where, then]
+author: Zen Architecture
+---
+
+# Synchronization Patterns - Expert Skill
+
+Master patterns for writing effective, maintainable synchronization rules.
+
+## Core Synchronization Structure
+
+```yaml
+synchronizations:
+  - id: "unique-rule-id"
+    when:
+      concept: "source-concept"
+      action: "action-name"
+      status: "completed"
+    where:
+      query: "conditional-expression"
+    then:
+      - concept: "target-concept"
+        action: "action-name"
+        model: "sonnet|opus"
+        inputs: {...}
+    provenance:
+      flow_id: "auto|${parent.flow_id}"
+      reason: "Why this rule triggers"
+```
+
+## Common Patterns
+
+### 1. Sequential Chain
+```yaml
+story → architecture → implementation → quality → version
+```
+
+### 2. Conditional Branch
+```yaml
+architecture → implementation (if risk == 'low')
+            → human-review (if risk == 'high')
+```
+
+### 3. Parallel Execution
+
+**Pattern**: Multiple independent actions triggered by same completion.
+
+```yaml
+implementation → quality.review  [parallel]
+              → quality.test     [parallel]
+```
+
+**Example**:
+```yaml
+synchronizations:
+  - id: "impl-to-quality-review"
+    when:
+      concept: "implementation"
+      action: "generate"
+      status: "completed"
+    where:
+      query: "implementation.status == 'completed' AND implementation.blockers.length == 0"
+    then:
+      - concept: "quality"
+        action: "review"
+        model: "sonnet"
+        parallel: true  # Can run concurrently with other rules
+        inputs:
+          implementation_id: "${implementation.id}"
+          files: "${implementation.files_changed}"
+
+  - id: "impl-to-quality-test"
+    when:
+      concept: "implementation"
+      action: "generate"
+      status: "completed"
+    where:
+      query: "implementation.status == 'completed' AND implementation.test_files.length > 0"
+    then:
+      - concept: "quality"
+        action: "test"
+        model: "sonnet"
+        parallel: true  # Can run concurrently with impl-to-quality-review
+        inputs:
+          implementation_id: "${implementation.id}"
+          test_paths: "${implementation.test_files}"
+```
+
+**Benefits**:
+- 50% faster execution (review + test run simultaneously)
+- Same total cost (both actions run anyway)
+- Independent actions don't block each other
+- Better resource utilization
+
+**Requirements**:
+- Actions must be truly independent (no shared state)
+- Both read from implementation, neither modifies it
+- Results collected before next sync evaluation
+
+**Implementation**:
+When multiple sync rules match with `parallel: true`:
+1. Invoke all matched concepts simultaneously (single message with multiple Task tool calls)
+2. Wait for all to complete
+3. Evaluate next synchronization with all results
+
+### 4. Error Recovery
+```yaml
+quality → version.commit (if approved)
+       → implementation.refactor (if needs_changes)
+```
+
+### 5. Iterative Refinement
+```yaml
+story → architecture → story.clarify (if ambiguous)
+     → architecture (retry)
+```
+
+## Query Language Reference
+
+### Field Access
+```yaml
+story.status                    # Access field
+architecture.decisions.length   # Array length
+quality.issues.filter(...)      # Array filter
+```
+
+### Comparisons
+```yaml
+==, !=    # Equality
+<, >, <=, >= # Numeric comparison
+```
+
+### Logical Operators
+```yaml
+AND, OR, NOT
+```
+
+### Examples
+```yaml
+# Multiple conditions
+story.status == 'ready' AND
+story.acceptance_criteria.length > 0 AND
+story.ambiguities.length == 0
+
+# Numeric comparison
+architecture.complexity < 8 AND
+architecture.risk_score <= 5
+
+# Array operations
+implementation.test_files.length > 0 AND
+quality.issues.filter(i => i.severity == 'high').length == 0
+```
+
+## Parallel Execution Guidelines
+
+### When to Use Parallel
+
+✅ **Good candidates for parallelization**:
+- Quality review + test execution (independent checks)
+- Multiple validation steps (security, lint, type check)
+- Documentation generation + test generation
+- Multiple independent transformations
+
+❌ **Bad candidates for parallelization**:
+- Architecture → Implementation (implementation needs arch complete)
+- Implementation → Version (version needs impl complete)
+- Any sequence where B needs output from A
+
+### Detecting Parallel Opportunities
+
+Questions to ask:
+1. Do both actions read from the same completed concept?
+2. Neither action modifies what the other reads?
+3. Neither action depends on the other's results?
+4. Both actions can be evaluated independently?
+
+If all YES → parallel is safe and beneficial.
+
+### Performance Impact
+
+**Sequential** (traditional):
+```
+Implementation complete → Quality review (2min) → Quality test (2min) = 4min
+```
+
+**Parallel** (with parallel: true):
+```
+Implementation complete → Quality review (2min) } = 2min
+                       → Quality test (2min)  }
+```
+
+**Savings**: 50% faster (4min → 2min)
+
+## Best Practices
+
+1. **Clear IDs**: Use descriptive sync IDs (`story-to-arch`, not `sync1`)
+2. **Explicit Models**: Always specify model in `then` section
+3. **Document Reasons**: Use `provenance.reason` to explain why
+4. **Test Queries**: Verify query logic matches intent
+5. **Handle Errors**: Add syncs for failure/blocked states
+6. **Use Parallel**: Mark independent actions with `parallel: true`
+7. **Validate Independence**: Ensure parallel actions don't conflict
+
+## Anti-Patterns
+
+❌ Complex logic in queries (use separate rules)
+❌ Missing where conditions (triggers too often)
+❌ Ambiguous concept references
+❌ Circular dependencies
+❌ Marking dependent actions as parallel
+❌ Parallelizing actions that modify shared state
+
+✅ Simple, clear conditions
+✅ Specific trigger conditions
+✅ Explicit concept names
+✅ Directed acyclic graph (DAG)
+✅ Parallel for truly independent actions
+✅ Sequential for dependent actions
+
+## Example: Complete Feature Workflow
+
+```yaml
+# .claude/synchronizations/feature-development.yaml
+synchronizations:
+  # Story → Architecture (sequential)
+  - id: "story-to-arch"
+    when: {concept: "story", action: "create", status: "completed"}
+    where: {query: "story.status == 'ready' AND story.acceptance_criteria.length > 0"}
+    then:
+      - concept: "architecture"
+        action: "design"
+        model: "sonnet"  # Complex reasoning
+        inputs: {story_id: "${story.id}"}
+
+  # Architecture → Implementation (sequential)
+  - id: "arch-to-impl"
+    when: {concept: "architecture", action: "design", status: "completed"}
+    where: {query: "architecture.estimated_risk != 'high'"}
+    then:
+      - concept: "implementation"
+        action: "generate"
+        model: "sonnet"  # Spec-driven
+        inputs: {architecture_id: "${architecture.id}"}
+
+  # Implementation → Quality Review + Test (PARALLEL)
+  - id: "impl-to-quality-review"
+    when: {concept: "implementation", action: "generate", status: "completed"}
+    where: {query: "implementation.status == 'completed'"}
+    then:
+      - concept: "quality"
+        action: "review"
+        model: "sonnet"
+        parallel: true  # ← Enables parallel execution
+        inputs: {implementation_id: "${implementation.id}"}
+
+  - id: "impl-to-quality-test"
+    when: {concept: "implementation", action: "generate", status: "completed"}
+    where: {query: "implementation.test_files.length > 0"}
+    then:
+      - concept: "quality"
+        action: "test"
+        model: "sonnet"
+        parallel: true  # ← Runs simultaneously with review
+        inputs: {implementation_id: "${implementation.id}"}
+
+  # Quality → Version (sequential, wait for both quality checks)
+  - id: "quality-to-version"
+    when: {concept: "quality", action: "review|test", status: "completed"}
+    where: {query: "review.status == 'approved' AND test.status == 'passed'"}
+    then:
+      - concept: "version"
+        action: "commit"
+        model: "sonnet"
+        inputs:
+          implementation_id: "${implementation.id}"
+          flow_id: "${flow.id}"
+```
+
+**Execution Flow**:
+```
+Story (Sonnet)
+  ↓
+Architecture (Sonnet)
+  ↓
+Implementation (Sonnet)
+  ↓
+  ├─→ Quality Review (Sonnet) ──┐
+  └─→ Quality Test (Sonnet) ────┤ [PARALLEL: 50% faster]
+                                ↓
+                           Version (Sonnet)
+```
+
+**Performance**:
+- Traditional: Story → Arch → Impl → Review → Test → Version = 18-20 min
+- With Parallel: Story → Arch → Impl → (Review+Test) → Version = 16-18 min
+- **Savings**: 2-4 minutes per feature (10-20% faster)
+
+---
+
+**Use this skill when**: Writing synchronization rules, debugging workflow logic, designing new workflows, or optimizing orchestration patterns.

package/templates/skills/test-generation-strategy.md.template

@@ -0,0 +1,247 @@
+---
+name: Test Generation Strategy
+description: Intelligent test generation with coverage optimization and edge case detection
+version: 1.0.0
+author: Zen Framework
+applies_to:
+  - implementation-concept
+trigger_keywords:
+  - test
+  - testing
+  - coverage
+  - unit test
+  - integration test
+  - edge case
+priority: P1
+impact: high
+---
+
+# Test Generation Strategy Skill
+
+## Purpose
+
+Guide the Implementation Concept agent in generating comprehensive, maintainable tests that maximize coverage while minimizing redundancy.
+
+## Test Type Selection Matrix
+
+| Code Type | Primary Tests | Secondary Tests | Optional |
+|-----------|---------------|-----------------|----------|
+| Pure functions | Unit tests | Property-based | Fuzz |
+| API endpoints | Integration | Contract | Load |
+| UI components | Component | E2E | Visual regression |
+| Data transforms | Unit + snapshot | Integration | - |
+| Event handlers | Unit + mocks | Integration | - |
+| State management | Unit | Integration | E2E |
+
+## Coverage Strategy
+
+### 1. Code Path Analysis
+
+```yaml
+coverage_targets:
+  minimum_line: 80%
+  minimum_branch: 75%
+  minimum_function: 90%
+  
+priority_paths:
+  critical:
+    - authentication flows
+    - payment processing
+    - data validation
+    - error handlers
+  high:
+    - business logic
+    - API endpoints
+    - state transitions
+  medium:
+    - utility functions
+    - formatters
+    - helpers
+```
+
+### 2. Edge Case Detection
+
+Automatically identify edge cases based on:
+
+```yaml
+edge_case_patterns:
+  numeric:
+    - zero
+    - negative
+    - MAX_VALUE / MIN_VALUE
+    - NaN / Infinity
+    - floating point precision
+    
+  string:
+    - empty string
+    - whitespace only
+    - unicode characters
+    - very long strings
+    - special characters
+    - null bytes
+    
+  collection:
+    - empty array/object
+    - single element
+    - large collections
+    - nested structures
+    - circular references
+    
+  temporal:
+    - midnight
+    - DST transitions
+    - timezone boundaries
+    - leap years
+    - epoch edge cases
+    
+  boundary:
+    - off-by-one
+    - array bounds
+    - pagination limits
+    - rate limits
+```
+
+### 3. Test Structure Template
+
+```typescript
+// Template for comprehensive test structure
+describe('[ComponentName]', () => {
+  // Setup and teardown
+  beforeAll(() => { /* one-time setup */ });
+  afterAll(() => { /* cleanup */ });
+  beforeEach(() => { /* per-test setup */ });
+  afterEach(() => { /* per-test cleanup */ });
+
+  describe('[MethodName]', () => {
+    // Happy path tests
+    describe('when valid input provided', () => {
+      it('should [expected behavior]', () => {});
+    });
+
+    // Edge cases
+    describe('edge cases', () => {
+      it('should handle empty input', () => {});
+      it('should handle boundary values', () => {});
+    });
+
+    // Error cases
+    describe('error handling', () => {
+      it('should throw [ErrorType] when [condition]', () => {});
+      it('should return error result when [condition]', () => {});
+    });
+
+    // Integration points
+    describe('integration', () => {
+      it('should interact correctly with [dependency]', () => {});
+    });
+  });
+});
+```
+
+## Test Quality Checklist
+
+### Naming Convention
+- [ ] Test names describe behavior, not implementation
+- [ ] Names follow pattern: `should [behavior] when [condition]`
+- [ ] Describe blocks group related tests logically
+
+### Assertions
+- [ ] One logical assertion per test (multiple asserts OK if testing one concept)
+- [ ] Assertions are specific (not just "truthy")
+- [ ] Error messages are descriptive
+- [ ] Async assertions properly awaited
+
+### Isolation
+- [ ] Tests don't depend on execution order
+- [ ] No shared mutable state between tests
+- [ ] External dependencies mocked appropriately
+- [ ] Database/file state cleaned up
+
+### Maintainability
+- [ ] No magic numbers (use constants)
+- [ ] Test data factories for complex objects
+- [ ] Helper functions for repeated patterns
+- [ ] Comments explain non-obvious test logic
+
+## Mock Strategy
+
+```yaml
+mock_guidelines:
+  always_mock:
+    - external APIs
+    - file system (unless integration test)
+    - network requests
+    - time/date (when testing temporal logic)
+    - random number generation
+    
+  never_mock:
+    - the code under test
+    - simple data structures
+    - pure utility functions
+    
+  mock_sparingly:
+    - database (prefer test database)
+    - internal services (prefer integration)
+    - framework internals
+```
+
+## Test Data Management
+
+### Factory Pattern
+
+```typescript
+// Use factories for test data
+const createUser = (overrides = {}) => ({
+  id: faker.string.uuid(),
+  email: faker.internet.email(),
+  name: faker.person.fullName(),
+  createdAt: new Date(),
+  ...overrides,
+});
+
+// Usage
+const adminUser = createUser({ role: 'admin' });
+const newUser = createUser({ createdAt: new Date() });
+```
+
+### Fixtures
+
+```yaml
+fixture_organization:
+  location: __fixtures__/ or test/fixtures/
+  naming: [entity].[scenario].json
+  examples:
+    - user.valid.json
+    - user.invalid-email.json
+    - order.large.json
+    - response.error-500.json
+```
+
+## Performance Considerations
+
+```yaml
+test_performance:
+  unit_tests:
+    target: < 100ms per test
+    total_suite: < 30 seconds
+    
+  integration_tests:
+    target: < 1 second per test
+    total_suite: < 5 minutes
+    
+  optimizations:
+    - parallel execution where safe
+    - shared setup for read-only fixtures
+    - lazy initialization of heavy resources
+    - test database pooling
+```
+
+## Output Format
+
+When generating tests, provide:
+
+1. **Test file location** following project conventions
+2. **Complete test code** with all imports
+3. **Coverage report** showing paths tested
+4. **Edge cases covered** as checklist
+5. **Suggested manual tests** for non-automatable scenarios