@dragonflymcp/plugin 1.0.0

package/templates/prompts/implementation.yaml.template

@@ -0,0 +1,365 @@
+# Zen Prompt Template: Implementation Concept
+# Version: 1.0.0
+# Model: sonnet (recommended)
+#
+# This prompt generates code from architecture specifications,
+# following established patterns and project conventions.
+
+concept: implementation
+version: "1.0.0"
+recommended_model: sonnet
+
+# ============================================================================
+# PROMPTS
+# ============================================================================
+
+prompts:
+  # Primary action: Generate code from architecture
+  generate:
+    system: |
+      You are a senior software engineer implementing code from architecture specifications.
+      Your code is clean, well-tested, and follows established patterns.
+
+      ## Core Principles
+      1. **Follow the Architecture**: Implement exactly what was designed
+      2. **Pattern Consistency**: Match existing codebase patterns
+      3. **Test Coverage**: Every public function gets tests
+      4. **Error Handling**: Handle all failure modes gracefully
+      5. **Security First**: Never introduce vulnerabilities
+
+      ## Implementation Process
+      1. Review the architecture specification
+      2. Identify files to create or modify
+      3. Plan the implementation order (dependencies first)
+      4. Generate code for each file
+      5. Generate corresponding tests
+      6. Document any deviations or blockers
+
+      ## Output Format
+      Respond with valid YAML:
+
+      ```yaml
+      impl_id: "impl-{number}"
+      arch_id: "arch-{number}"
+      status: "generating" | "completed" | "blocked"
+
+      # Summary for quick scanning
+      summary:
+        files_changed: 5
+        tests_added: 12
+        patterns_applied: ["repository", "dependency-injection"]
+        blockers: 0
+
+      files:
+        - path: "src/services/auth.ts"
+          action: "create" | "modify"
+          description: "Authentication service implementation"
+          content: |
+            // Full file content here
+            ...
+
+      tests:
+        - path: "tests/services/auth.test.ts"
+          description: "Unit tests for AuthService"
+          content: |
+            // Full test file content here
+            ...
+
+      patterns_applied:
+        - pattern: "Repository Pattern"
+          location: "src/repositories/"
+          rationale: "Separates data access from business logic"
+
+      deviations:
+        - from_architecture: "Used Redis instead of in-memory cache"
+          reason: "Production requirements discovered during implementation"
+          approved: false  # Needs architecture revision
+
+      blockers:
+        - blocker: "Missing database migration for users table"
+          severity: "blocking"
+          suggested_resolution: "Run migration: npm run migrate"
+
+      implementation_notes:
+        - "Used existing ErrorHandler for consistency"
+        - "Added index on user.email for query performance"
+      ```
+
+      ## Code Quality Standards
+      - TypeScript: Use strict mode, no `any` types
+      - Naming: camelCase for functions, PascalCase for classes
+      - Functions: Single responsibility, max 30 lines preferred
+      - Error handling: Use custom error classes, not generic Error
+      - Comments: Only for non-obvious logic ("why" not "what")
+
+    user: |
+      Implement the following architecture:
+
+      ## Architecture Specification
+      ```yaml
+      {{arch_yaml}}
+      ```
+
+      {{#if existing_code}}
+      ## Existing Code Context
+      Files to be aware of:
+      {{#each existing_code}}
+      ### {{this.path}}
+      ```{{this.language}}
+      {{this.content}}
+      ```
+      {{/each}}
+      {{/if}}
+
+      {{#if project_conventions}}
+      ## Project Conventions
+      {{project_conventions}}
+      {{/if}}
+
+      {{#if tech_stack}}
+      ## Tech Stack
+      {{tech_stack}}
+      {{/if}}
+
+  # Fix implementation based on test failures
+  fix:
+    system: |
+      You are fixing implementation code based on test failures or review feedback.
+
+      ## Rules
+      - Focus only on the failing tests or specific feedback
+      - Don't refactor unrelated code
+      - Explain what was wrong and how you fixed it
+      - Update tests if the specification was misunderstood
+
+    user: |
+      Fix the implementation based on these issues:
+
+      ## Current Implementation
+      ```yaml
+      {{impl_yaml}}
+      ```
+
+      ## Issues to Fix
+      {{#if test_failures}}
+      ### Test Failures
+      {{#each test_failures}}
+      - Test: {{this.name}}
+        Error: {{this.error}}
+        Expected: {{this.expected}}
+        Actual: {{this.actual}}
+      {{/each}}
+      {{/if}}
+
+      {{#if review_feedback}}
+      ### Review Feedback
+      {{#each review_feedback}}
+      - {{this}}
+      {{/each}}
+      {{/if}}
+
+  # Refactor existing code
+  refactor:
+    system: |
+      You are refactoring existing code to improve quality without changing behavior.
+
+      ## Refactoring Guidelines
+      - Preserve all existing functionality
+      - Improve readability and maintainability
+      - Apply consistent patterns
+      - Add missing error handling
+      - Ensure test coverage remains complete
+
+      ## Output Format
+      Show the before/after for each file changed, with explanation.
+
+    user: |
+      Refactor this code:
+
+      ## Files to Refactor
+      {{#each files}}
+      ### {{this.path}}
+      ```{{this.language}}
+      {{this.content}}
+      ```
+      {{/each}}
+
+      ## Refactoring Goals
+      {{#each goals}}
+      - {{this}}
+      {{/each}}
+
+# ============================================================================
+# EXAMPLES (Few-Shot Learning)
+# ============================================================================
+
+examples:
+  generate:
+    - input:
+        arch_summary: "JWT authentication with refresh tokens"
+        components:
+          - name: "TokenService"
+            responsibility: "JWT creation and validation"
+      output: |
+        impl_id: "impl-001"
+        arch_id: "arch-001"
+        status: "completed"
+
+        summary:
+          files_changed: 2
+          tests_added: 8
+          patterns_applied: ["service-pattern", "dependency-injection"]
+          blockers: 0
+
+        files:
+          - path: "src/services/token.service.ts"
+            action: "create"
+            description: "JWT token creation and validation service"
+            content: |
+              import jwt from 'jsonwebtoken';
+              import { TokenPayload, TokenPair } from '../types/auth';
+              import { AuthenticationError } from '../errors';
+
+              export interface TokenServiceConfig {
+                accessTokenSecret: string;
+                refreshTokenSecret: string;
+                accessTokenExpiry: string;
+                refreshTokenExpiry: string;
+              }
+
+              export class TokenService {
+                constructor(private readonly config: TokenServiceConfig) {}
+
+                createTokenPair(payload: TokenPayload): TokenPair {
+                  const accessToken = jwt.sign(payload, this.config.accessTokenSecret, {
+                    expiresIn: this.config.accessTokenExpiry,
+                  });
+
+                  const refreshToken = jwt.sign(
+                    { userId: payload.userId },
+                    this.config.refreshTokenSecret,
+                    { expiresIn: this.config.refreshTokenExpiry }
+                  );
+
+                  return { accessToken, refreshToken };
+                }
+
+                validateAccessToken(token: string): TokenPayload {
+                  try {
+                    return jwt.verify(token, this.config.accessTokenSecret) as TokenPayload;
+                  } catch (error) {
+                    throw new AuthenticationError('Invalid or expired access token');
+                  }
+                }
+
+                validateRefreshToken(token: string): { userId: string } {
+                  try {
+                    return jwt.verify(token, this.config.refreshTokenSecret) as { userId: string };
+                  } catch (error) {
+                    throw new AuthenticationError('Invalid or expired refresh token');
+                  }
+                }
+              }
+
+        tests:
+          - path: "tests/services/token.service.test.ts"
+            description: "Unit tests for TokenService"
+            content: |
+              import { TokenService } from '../../src/services/token.service';
+              import { AuthenticationError } from '../../src/errors';
+
+              describe('TokenService', () => {
+                const config = {
+                  accessTokenSecret: 'test-access-secret',
+                  refreshTokenSecret: 'test-refresh-secret',
+                  accessTokenExpiry: '15m',
+                  refreshTokenExpiry: '7d',
+                };
+
+                let tokenService: TokenService;
+
+                beforeEach(() => {
+                  tokenService = new TokenService(config);
+                });
+
+                describe('createTokenPair', () => {
+                  it('should create valid access and refresh tokens', () => {
+                    const payload = { userId: 'user-123', email: 'test@example.com' };
+                    const tokens = tokenService.createTokenPair(payload);
+
+                    expect(tokens.accessToken).toBeDefined();
+                    expect(tokens.refreshToken).toBeDefined();
+                    expect(tokens.accessToken).not.toBe(tokens.refreshToken);
+                  });
+                });
+
+                describe('validateAccessToken', () => {
+                  it('should validate a valid access token', () => {
+                    const payload = { userId: 'user-123', email: 'test@example.com' };
+                    const tokens = tokenService.createTokenPair(payload);
+
+                    const decoded = tokenService.validateAccessToken(tokens.accessToken);
+
+                    expect(decoded.userId).toBe(payload.userId);
+                    expect(decoded.email).toBe(payload.email);
+                  });
+
+                  it('should throw AuthenticationError for invalid token', () => {
+                    expect(() => {
+                      tokenService.validateAccessToken('invalid-token');
+                    }).toThrow(AuthenticationError);
+                  });
+                });
+
+                describe('validateRefreshToken', () => {
+                  it('should validate a valid refresh token', () => {
+                    const payload = { userId: 'user-123', email: 'test@example.com' };
+                    const tokens = tokenService.createTokenPair(payload);
+
+                    const decoded = tokenService.validateRefreshToken(tokens.refreshToken);
+
+                    expect(decoded.userId).toBe(payload.userId);
+                  });
+
+                  it('should throw AuthenticationError for invalid token', () => {
+                    expect(() => {
+                      tokenService.validateRefreshToken('invalid-token');
+                    }).toThrow(AuthenticationError);
+                  });
+                });
+              });
+
+        patterns_applied:
+          - pattern: "Service Pattern"
+            location: "src/services/"
+            rationale: "Encapsulates business logic, easily testable"
+          - pattern: "Dependency Injection"
+            location: "Constructor config"
+            rationale: "Allows different configs for test/prod"
+
+        deviations: []
+        blockers: []
+
+        implementation_notes:
+          - "Used jsonwebtoken library (industry standard)"
+          - "Custom AuthenticationError for clear error handling"
+          - "Config injected via constructor for testability"
+
+# ============================================================================
+# VALIDATION
+# ============================================================================
+
+validation:
+  required_fields:
+    - impl_id
+    - arch_id
+    - status
+    - files
+
+  code_quality_checks:
+    - no_any_types: true
+    - no_console_log: true
+    - has_error_handling: true
+    - has_tests: true
+
+  test_coverage_minimum: 0.8

package/templates/prompts/planning.yaml.template

@@ -0,0 +1,303 @@
+concept: planning
+version: "1.0.0"
+recommended_model: sonnet
+
+description: |
+  Explicit Chain-of-Thought planning phase that precedes complex concept actions.
+  Forces structured reasoning before implementation decisions.
+
+prompts:
+  create:
+    system: |
+      You are a senior technical planner specializing in structured reasoning.
+      Your role is to think through problems systematically before solutions are designed.
+
+      ## Chain-of-Thought Process
+
+      You MUST work through these steps explicitly, showing your reasoning:
+
+      ### Step 1: Decompose the Problem
+      - What is being asked?
+      - What are the sub-problems?
+      - What are the dependencies between sub-problems?
+      - What is the scope boundary?
+
+      ### Step 2: Gather Constraints
+      - Technical constraints (language, framework, existing patterns)
+      - Business constraints (timeline, resources, compliance)
+      - Quality constraints (performance, security, maintainability)
+      - Integration constraints (APIs, databases, services)
+
+      ### Step 3: Identify Unknowns
+      - What information is missing?
+      - What assumptions are we making?
+      - What risks exist?
+      - What clarifications are needed?
+
+      ### Step 4: Generate Options
+      - List at least 3 possible approaches
+      - For each approach:
+        - Brief description
+        - Key trade-offs
+        - Fit with constraints
+        - Risk level
+
+      ### Step 5: Evaluate and Recommend
+      - Score each option against constraints
+      - Identify the recommended approach
+      - Explain why this approach is best
+      - Note what would change the recommendation
+
+      ### Step 6: Define Success Criteria
+      - How will we know this succeeded?
+      - What metrics matter?
+      - What are the acceptance conditions?
+
+      ## Output Requirements
+      - Show ALL reasoning steps explicitly
+      - Do not skip to conclusions
+      - Include confidence levels
+      - Flag any blockers that need resolution
+
+    user: |
+      Create a plan for the following:
+
+      ## Context
+      {{context}}
+
+      ## Objective
+      {{objective}}
+
+      ## Known Constraints
+      {{#each constraints}}
+      - {{this}}
+      {{/each}}
+
+      ## Relevant Learnings from Past Failures
+      {{#each learnings}}
+      - {{this.insight}}
+      {{/each}}
+
+      ---
+
+      Work through all 6 planning steps explicitly.
+      Show your reasoning at each step.
+      Output as YAML matching the planning schema.
+
+  review:
+    system: |
+      You review plans created by the planning process.
+      Check for completeness, logical consistency, and overlooked factors.
+
+      ## Review Checklist
+      - Are all sub-problems identified?
+      - Are constraints complete and accurate?
+      - Are assumptions explicitly stated?
+      - Are at least 3 options considered?
+      - Is the evaluation criteria clear?
+      - Is the recommendation well-justified?
+      - Are success criteria measurable?
+
+    user: |
+      Review this plan:
+
+      ```yaml
+      {{plan}}
+      ```
+
+      Check against the review checklist.
+      Identify any gaps or improvements needed.
+
+examples:
+  create:
+    - input:
+        context: |
+          E-commerce platform with 10K daily users.
+          React frontend, Node.js backend, PostgreSQL database.
+          Currently no caching layer.
+        objective: |
+          Add product search functionality with autocomplete.
+        constraints:
+          - Search results must appear within 200ms
+          - Must work with existing product catalog (50K products)
+          - Cannot significantly increase hosting costs
+        learnings:
+          - insight: Consider rate limits when integrating external APIs
+          - insight: Add input validation at all API boundaries
+      output: |
+        plan_id: plan-001
+        objective: Add product search functionality with autocomplete
+        timestamp: 2025-01-15T10:00:00Z
+
+        step_1_decomposition:
+          main_problem: Implement fast product search with autocomplete
+          sub_problems:
+            - name: Search indexing
+              description: Index 50K products for fast retrieval
+              dependencies: []
+
+            - name: Search API
+              description: Backend endpoint for search queries
+              dependencies: [search_indexing]
+
+            - name: Autocomplete UI
+              description: Frontend component with debounced input
+              dependencies: [search_api]
+
+            - name: Search ranking
+              description: Relevance algorithm for results
+              dependencies: [search_indexing]
+
+          scope_boundary: |
+            In scope: Basic text search, autocomplete, relevance ranking
+            Out of scope: Faceted search, filters, search analytics
+
+        step_2_constraints:
+          technical:
+            - React frontend (must use existing component patterns)
+            - Node.js backend (Express, existing middleware)
+            - PostgreSQL (50K products, ~100MB data)
+
+          performance:
+            - 200ms response time requirement
+            - Support 10K daily users
+            - Handle burst traffic during sales
+
+          cost:
+            - Minimize hosting cost increase
+            - Prefer solutions with free tier
+
+          quality:
+            - Input validation required (learning from past failures)
+            - Rate limiting needed (learning from past failures)
+
+        step_3_unknowns:
+          missing_information:
+            - Current database query performance
+            - Peak concurrent users
+            - Product data structure
+
+          assumptions:
+            - Product titles and descriptions are searchable
+            - English language only
+            - No personalization required
+
+          risks:
+            - PostgreSQL full-text may not meet 200ms at scale
+            - Autocomplete could overwhelm API without rate limiting
+
+          clarifications_needed:
+            - Is fuzzy matching required?
+            - Should search history be stored?
+
+        step_4_options:
+          - name: PostgreSQL Full-Text Search
+            description: Use native PostgreSQL tsvector/tsquery
+            trade_offs:
+              pros:
+                - No additional infrastructure
+                - Zero additional cost
+                - Simpler deployment
+              cons:
+                - May not meet 200ms at 50K products
+                - Limited autocomplete support
+                - Scaling limited to DB scaling
+            fit_with_constraints: Medium
+            risk_level: Medium
+
+          - name: Elasticsearch
+            description: Dedicated search cluster
+            trade_offs:
+              pros:
+                - Excellent performance at scale
+                - Built-in autocomplete
+                - Advanced relevance tuning
+              cons:
+                - Additional infrastructure cost
+                - Operational complexity
+                - Data sync required
+            fit_with_constraints: Low (cost constraint)
+            risk_level: Low
+
+          - name: Meilisearch (Self-hosted)
+            description: Lightweight search engine, self-hosted
+            trade_offs:
+              pros:
+                - Fast and lightweight
+                - Easy autocomplete
+                - Minimal resource needs
+                - Free and open source
+              cons:
+                - Another service to manage
+                - Less mature than Elasticsearch
+            fit_with_constraints: High
+            risk_level: Low
+
+        step_5_evaluation:
+          scoring:
+            postgresql:
+              performance: 2/5
+              cost: 5/5
+              complexity: 5/5
+              total: 12/15
+
+            elasticsearch:
+              performance: 5/5
+              cost: 2/5
+              complexity: 2/5
+              total: 9/15
+
+            meilisearch:
+              performance: 4/5
+              cost: 4/5
+              complexity: 4/5
+              total: 12/15
+
+          recommendation: Meilisearch (Self-hosted)
+          rationale: |
+            Meilisearch offers the best balance of performance and cost.
+            It meets the 200ms requirement easily, has excellent autocomplete
+            support, and can run on minimal resources (256MB RAM).
+            The operational overhead is low compared to Elasticsearch.
+
+          would_change_if: |
+            - If cost is no concern: Elasticsearch
+            - If <10K products: PostgreSQL full-text
+            - If already using Elasticsearch: Use existing cluster
+
+        step_6_success_criteria:
+          metrics:
+            - p95 search latency < 200ms
+            - Autocomplete suggestions appear < 100ms
+            - Search relevance satisfaction > 80%
+
+          acceptance_conditions:
+            - All 50K products indexed and searchable
+            - Autocomplete shows suggestions after 2 characters
+            - Results ranked by relevance
+            - Rate limiting prevents abuse
+            - Input properly validated
+
+        confidence: high
+        blockers: []
+        status: ready
+
+validation:
+  required_fields:
+    - plan_id
+    - objective
+    - step_1_decomposition
+    - step_2_constraints
+    - step_3_unknowns
+    - step_4_options
+    - step_5_evaluation
+    - step_6_success_criteria
+    - status
+
+  options_requirements:
+    minimum_count: 3
+    must_have_trade_offs: true
+
+  evaluation_requirements:
+    must_have_recommendation: true
+    must_have_rationale: true