mirror of
https://github.com/Ark0N/Codeman.git
synced 2026-10-02 05:29:42 +02:00
refactor(prompts): extract plan orchestrator prompts to separate files
Each prompt now lives in its own file under src/prompts/ for easier editing and iteration. Includes index.ts for convenient re-exports. chore: bump version to 0.1408 Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
This commit is contained in:
arkon
@@ -16,7 +16,7 @@ When user says "COM":
|
||||
1. Increment version in BOTH `package.json` AND `CLAUDE.md`
|
||||
2. Run: `git add -A && git commit -m "chore: bump version to X.XXXX" && git push && npm run build && systemctl --user restart claudeman-web`
|
||||
|
||||
**Version**: 0.1407 (must match `package.json`)
|
||||
**Version**: 0.1408 (must match `package.json`)
|
||||
|
||||
## Project Overview
|
||||
|
||||
|
||||
+1
-1
@@ -1,6 +1,6 @@
|
||||
{
|
||||
"name": "claudeman",
|
||||
"version": "0.1407",
|
||||
"version": "0.1408",
|
||||
"description": "The missing control plane for Claude Code - run 20 autonomous agents with real-time monitoring and session persistence",
|
||||
"type": "module",
|
||||
"main": "dist/index.js",
|
||||
|
||||
+14
-573
@@ -17,6 +17,17 @@ import { Session } from './session.js';
|
||||
import { ScreenManager } from './screen-manager.js';
|
||||
import { existsSync, mkdirSync, writeFileSync, readFileSync } from 'node:fs';
|
||||
import { join, dirname } from 'node:path';
|
||||
import {
|
||||
RESEARCH_AGENT_PROMPT,
|
||||
REQUIREMENTS_ANALYST_PROMPT,
|
||||
ARCHITECTURE_PLANNER_PROMPT,
|
||||
TESTING_SPECIALIST_PROMPT,
|
||||
RISK_ANALYST_PROMPT,
|
||||
CODE_REVIEWER_PROMPT,
|
||||
VERIFICATION_PROMPT,
|
||||
EXECUTION_OPTIMIZER_PROMPT,
|
||||
FINAL_REVIEW_PROMPT,
|
||||
} from './prompts/index.js';
|
||||
|
||||
// ============================================================================
|
||||
// Types
|
||||
@@ -320,579 +331,9 @@ const MODEL_RESEARCH = 'opus'; // Best model for research (needs reasoning for w
|
||||
const MODEL_ANALYSIS = 'opus'; // Best model for thorough analysis
|
||||
const MODEL_VERIFICATION = 'opus'; // Best model for verification
|
||||
|
||||
// ============================================================================
|
||||
// Subagent Prompts
|
||||
// ============================================================================
|
||||
|
||||
const RESEARCH_AGENT_PROMPT = `You are a Research Specialist preparing context for an implementation task. Your job is to gather all relevant information that will help the development team succeed.
|
||||
|
||||
## YOUR TASK
|
||||
Research and gather comprehensive context for implementing this task:
|
||||
|
||||
## TASK DESCRIPTION
|
||||
{TASK}
|
||||
|
||||
## INSTRUCTIONS
|
||||
Perform thorough research across multiple sources:
|
||||
|
||||
### 1. WEB RESEARCH (CRITICAL)
|
||||
Use web search to find:
|
||||
- **GitHub repositories** that implement similar features or solve similar problems
|
||||
- **Official documentation** for any technologies, APIs, or frameworks mentioned
|
||||
- **Claude Code documentation** if the task involves Claude Code features
|
||||
- **Best practice guides** and tutorials from reputable sources
|
||||
- **Stack Overflow answers** for common implementation patterns
|
||||
|
||||
Focus your web search on:
|
||||
- How others have solved similar problems
|
||||
- Common pitfalls and gotchas
|
||||
- Library/package recommendations
|
||||
- API usage examples
|
||||
|
||||
### 2. CODEBASE EXPLORATION
|
||||
If the task involves modifying an existing codebase, explore it to understand:
|
||||
- Existing patterns and conventions used
|
||||
- Similar features already implemented
|
||||
- File organization and architecture
|
||||
- Test patterns and coverage
|
||||
|
||||
### 3. TECHNICAL ANALYSIS
|
||||
Based on your research:
|
||||
- Recommend the best technical approach
|
||||
- Identify potential challenges before they become blockers
|
||||
- Suggest useful libraries or tools
|
||||
- Note any compatibility or integration concerns
|
||||
|
||||
## OUTPUT FORMAT
|
||||
Return ONLY a JSON object:
|
||||
{
|
||||
"externalResources": [
|
||||
{
|
||||
"type": "github|documentation|tutorial|article|stackoverflow",
|
||||
"url": "https://...",
|
||||
"title": "Resource title",
|
||||
"relevance": "Why this is relevant to the task",
|
||||
"keyInsights": ["Insight 1", "Insight 2"]
|
||||
}
|
||||
],
|
||||
"codebasePatterns": [
|
||||
{
|
||||
"pattern": "Pattern name (e.g., 'Repository pattern for data access')",
|
||||
"location": "src/repositories/*.ts",
|
||||
"relevance": "Why this pattern matters for the task"
|
||||
}
|
||||
],
|
||||
"technicalRecommendations": [
|
||||
"Use approach X because...",
|
||||
"Consider library Y for..."
|
||||
],
|
||||
"potentialChallenges": [
|
||||
"Watch out for X when implementing Y",
|
||||
"Common gotcha: ..."
|
||||
],
|
||||
"recommendedTools": [
|
||||
{
|
||||
"name": "library-name",
|
||||
"purpose": "What it does",
|
||||
"reason": "Why it's recommended for this task"
|
||||
}
|
||||
],
|
||||
"enrichedTaskDescription": "A more detailed version of the original task, enriched with context from your research. This should include specific technical details, file locations, API endpoints, library versions, etc. that will help other agents understand exactly what needs to be done."
|
||||
}
|
||||
|
||||
CRITICAL REQUIREMENTS:
|
||||
1. ACTUALLY USE WEB SEARCH to find external resources - don't make them up
|
||||
2. Include real URLs when found via web search
|
||||
3. The enrichedTaskDescription should be 2-3x more detailed than the original
|
||||
4. Be specific - vague research is useless research`;
|
||||
|
||||
const REQUIREMENTS_ANALYST_PROMPT = `You are a Requirements Analyst specializing in extracting all requirements from task descriptions.
|
||||
|
||||
## YOUR TASK
|
||||
Analyze the following task and extract ALL requirements (explicit and implicit):
|
||||
|
||||
## TASK DESCRIPTION
|
||||
{TASK}
|
||||
|
||||
{RESEARCH_CONTEXT}
|
||||
|
||||
## INSTRUCTIONS
|
||||
1. Identify explicit requirements (directly stated)
|
||||
2. Infer implicit requirements (unstated but necessary)
|
||||
3. Note any assumptions that should be validated
|
||||
4. Consider non-functional requirements (performance, security, usability)
|
||||
|
||||
## OUTPUT FORMAT
|
||||
Return ONLY a JSON array:
|
||||
[
|
||||
{"category": "functional|non-functional|constraint|assumption", "content": "requirement description", "rationale": "why this is needed"}
|
||||
]
|
||||
|
||||
Generate 8-15 items. Be thorough - missing requirements cause project failures.`;
|
||||
|
||||
const ARCHITECTURE_PLANNER_PROMPT = `You are an Architecture Planner specializing in software component design.
|
||||
|
||||
## YOUR TASK
|
||||
Design the architecture for implementing this task:
|
||||
|
||||
## TASK DESCRIPTION
|
||||
{TASK}
|
||||
|
||||
{RESEARCH_CONTEXT}
|
||||
|
||||
## INSTRUCTIONS
|
||||
1. Identify all modules/components needed
|
||||
2. Define interfaces between components
|
||||
3. Specify data structures and types
|
||||
4. Note configuration and setup requirements
|
||||
5. Consider separation of concerns
|
||||
|
||||
## OUTPUT FORMAT
|
||||
Return ONLY a JSON array:
|
||||
[
|
||||
{"category": "module|interface|type|config|infrastructure", "content": "component description", "rationale": "why needed"}
|
||||
]
|
||||
|
||||
Generate 10-20 items. Think about the complete system architecture.`;
|
||||
|
||||
const TESTING_SPECIALIST_PROMPT = `You are a TDD Specialist designing a comprehensive, REALISTIC test strategy.
|
||||
|
||||
## YOUR TASK
|
||||
Design detailed, executable test coverage for this task:
|
||||
|
||||
## TASK DESCRIPTION
|
||||
{TASK}
|
||||
|
||||
{RESEARCH_CONTEXT}
|
||||
|
||||
## INSTRUCTIONS
|
||||
Create REALISTIC tests that would actually run in a real codebase:
|
||||
|
||||
### 1. Unit Tests (test individual functions/methods in isolation)
|
||||
- Mock external dependencies (databases, APIs, file system)
|
||||
- Test pure logic with specific input/output examples
|
||||
- Include exact assertion values, not placeholders
|
||||
|
||||
### 2. Integration Tests (test component interactions)
|
||||
- Test API endpoints with realistic request/response bodies
|
||||
- Test database operations with actual schema
|
||||
- Test service-to-service communication
|
||||
|
||||
### 3. Edge Cases & Boundary Tests
|
||||
- Empty inputs, null values, undefined
|
||||
- Maximum/minimum values, overflow conditions
|
||||
- Unicode, special characters, injection attempts
|
||||
- Concurrent access, race conditions
|
||||
|
||||
### 4. Error Scenario Tests
|
||||
- Network failures, timeouts, connection refused
|
||||
- Invalid input validation with specific error messages
|
||||
- Authorization failures, permission denied
|
||||
- Resource not found, conflict states
|
||||
|
||||
### 5. Performance & Load Tests (where applicable)
|
||||
- Response time thresholds
|
||||
- Memory usage limits
|
||||
- Concurrent user handling
|
||||
|
||||
## REALISTIC TEST EXAMPLE
|
||||
BAD: "Test user login" (too vague)
|
||||
GOOD: "Test POST /api/auth/login with valid email 'test@example.com' and password 'ValidPass123!' returns 200 with JWT token containing userId and exp claims, sets httpOnly cookie 'session'"
|
||||
|
||||
## OUTPUT FORMAT
|
||||
Return ONLY a JSON array:
|
||||
[
|
||||
{
|
||||
"category": "unit|integration|edge-case|error|e2e|performance",
|
||||
"content": "Test POST /api/users with email 'new@test.com' creates user and returns 201 with {id, email, createdAt}",
|
||||
"rationale": "Validates user creation happy path with all required response fields",
|
||||
"verificationCriteria": "Response status 201, body contains id (uuid), email matches input, createdAt is valid ISO timestamp",
|
||||
"testCommand": "npm test -- --grep='POST /api/users creates user'",
|
||||
"testSetup": "Clear users table, seed with test data",
|
||||
"testTeardown": "Delete created test user",
|
||||
"pairedImpl": "Implement POST /api/users endpoint with validation and database insert",
|
||||
"mockDependencies": ["database connection", "email service"],
|
||||
"assertionDetails": ["status === 201", "body.id matches UUID regex", "body.email === 'new@test.com'"]
|
||||
}
|
||||
]
|
||||
|
||||
CRITICAL REQUIREMENTS:
|
||||
- verificationCriteria: SPECIFIC observable outcomes with exact values
|
||||
- testCommand: Actual runnable command (npm test, pytest, vitest, etc.)
|
||||
- pairedImpl: The exact implementation step this test validates
|
||||
- assertionDetails: List of specific assertions to make
|
||||
|
||||
Generate 15-30 detailed test items. Tests MUST be specific enough to implement directly.`;
|
||||
|
||||
const RISK_ANALYST_PROMPT = `You are a Risk Analyst identifying potential issues and blockers.
|
||||
|
||||
## YOUR TASK
|
||||
Identify risks and edge cases for this task:
|
||||
|
||||
## TASK DESCRIPTION
|
||||
{TASK}
|
||||
|
||||
{RESEARCH_CONTEXT}
|
||||
|
||||
## INSTRUCTIONS
|
||||
1. Identify potential failure points
|
||||
2. Note edge cases that could cause bugs
|
||||
3. Consider security vulnerabilities
|
||||
4. Flag performance concerns
|
||||
5. Identify dependencies that could block progress
|
||||
|
||||
## OUTPUT FORMAT
|
||||
Return ONLY a JSON array:
|
||||
[
|
||||
{"category": "failure|edge-case|security|performance|dependency", "content": "risk description", "rationale": "mitigation approach"}
|
||||
]
|
||||
|
||||
Generate 8-15 items. Being proactive about risks prevents surprises.`;
|
||||
|
||||
// @ts-expect-error Reserved for future use - code review specialist prompt
|
||||
const CODE_REVIEWER_PROMPT = `You are a Code Review Specialist designing post-implementation review tasks.
|
||||
|
||||
## YOUR TASK
|
||||
Design code review steps for implementations in this task:
|
||||
|
||||
## TASK DESCRIPTION
|
||||
{TASK}
|
||||
|
||||
## INSTRUCTIONS
|
||||
For each implementation identified, create a review task that checks:
|
||||
1. **Best Practices**: Language-specific conventions and idioms
|
||||
2. **Security**: OWASP top 10, input validation, authentication
|
||||
3. **Performance**: Time complexity, memory usage, N+1 queries
|
||||
4. **Error Handling**: Edge cases covered, meaningful error messages
|
||||
5. **Code Quality**: DRY, SOLID principles, readability
|
||||
6. **Type Safety**: Proper typing, no implicit any, null checks
|
||||
|
||||
## REVIEW TASK GUIDELINES
|
||||
- Review tasks run AFTER implementation, BEFORE merge
|
||||
- Each review should be specific and actionable
|
||||
- Include what to look for and how to verify
|
||||
- Reference language-specific linting tools where applicable
|
||||
|
||||
## OUTPUT FORMAT
|
||||
Return ONLY a JSON array:
|
||||
[
|
||||
{
|
||||
"category": "security|performance|quality|error-handling|best-practices|type-safety",
|
||||
"content": "Review authentication handler for XSS vulnerabilities",
|
||||
"rationale": "User input flows through auth - must sanitize",
|
||||
"verificationCriteria": "No unescaped user input, all inputs validated",
|
||||
"reviewChecklist": ["Check input sanitization", "Verify CSRF tokens", "Review session handling"],
|
||||
"implToReview": "Implement authentication handler"
|
||||
}
|
||||
]
|
||||
|
||||
Generate 5-10 review tasks. Code review catches bugs that tests miss.`;
|
||||
|
||||
const VERIFICATION_PROMPT = `You are a Plan Verification Expert reviewing an implementation plan for completeness and quality.
|
||||
|
||||
## ORIGINAL TASK
|
||||
{TASK}
|
||||
|
||||
## SYNTHESIZED PLAN (from multiple analysis subagents)
|
||||
{PLAN}
|
||||
|
||||
## YOUR MISSION
|
||||
Review and enhance this plan:
|
||||
1. Assign priorities (P0=critical/blocking, P1=required, P2=enhancement)
|
||||
2. Add verification criteria to EVERY task (how to know it's done)
|
||||
3. Pair test tasks with implementation tasks (TDD cycle)
|
||||
4. Add dependencies where one task blocks another
|
||||
5. Identify gaps and calculate quality score
|
||||
|
||||
## PRIORITY GUIDELINES
|
||||
- P0: Foundation tasks, type definitions, project setup, blocking dependencies
|
||||
- P1: Core implementation, tests, main features, error handling
|
||||
- P2: Polish, optimization, documentation, nice-to-have features
|
||||
|
||||
## TDD + REVIEW CYCLE RULES
|
||||
The complete cycle is: test → impl → review
|
||||
- Every implementation task should have a corresponding test task AND review task
|
||||
- Test task comes BEFORE its paired implementation task
|
||||
- Review task comes AFTER the implementation it reviews
|
||||
- Use "pairedWith" to link test ↔ implementation ↔ review
|
||||
- Verification criteria should reference test results where applicable
|
||||
|
||||
## REVIEW TASK REQUIREMENTS
|
||||
After EVERY implementation task, add a review task that checks:
|
||||
- Best practices for the language/framework
|
||||
- Security vulnerabilities (OWASP top 10)
|
||||
- Performance concerns
|
||||
- Error handling completeness
|
||||
- Code quality (DRY, SOLID, readability)
|
||||
|
||||
## OUTPUT FORMAT
|
||||
Return ONLY a JSON object:
|
||||
{
|
||||
"validatedPlan": [
|
||||
{
|
||||
"id": "P0-001",
|
||||
"content": "Write failing test for user authentication",
|
||||
"priority": "P0",
|
||||
"tddPhase": "test",
|
||||
"verificationCriteria": "Test file exists, test fails with 'not implemented'",
|
||||
"testCommand": "npm test -- --grep='auth'",
|
||||
"pairedWith": "P0-002",
|
||||
"dependencies": [],
|
||||
"complexity": "low"
|
||||
},
|
||||
{
|
||||
"id": "P0-002",
|
||||
"content": "Implement user authentication handler",
|
||||
"priority": "P0",
|
||||
"tddPhase": "impl",
|
||||
"verificationCriteria": "npm test -- --grep='auth' passes",
|
||||
"pairedWith": "P0-001",
|
||||
"dependencies": ["P0-001"],
|
||||
"complexity": "medium"
|
||||
},
|
||||
{
|
||||
"id": "P0-003",
|
||||
"content": "Review auth implementation for security and best practices",
|
||||
"priority": "P0",
|
||||
"tddPhase": "review",
|
||||
"verificationCriteria": "No security issues found, follows TypeScript best practices",
|
||||
"reviewChecklist": ["Input validation", "XSS prevention", "Session security", "Error handling"],
|
||||
"pairedWith": "P0-002",
|
||||
"dependencies": ["P0-002"],
|
||||
"complexity": "low"
|
||||
}
|
||||
],
|
||||
"gaps": ["missing requirement 1", "missing test coverage for X"],
|
||||
"warnings": ["consider Y before Z", "potential issue with..."],
|
||||
"qualityScore": 0.85
|
||||
}
|
||||
|
||||
CRITICAL REQUIREMENTS:
|
||||
1. EVERY task MUST have verificationCriteria (how to verify completion)
|
||||
2. Implementation tasks MUST have a paired test task AND a review task
|
||||
3. Review tasks MUST have a reviewChecklist with specific items to check
|
||||
4. Dependencies must form a valid DAG (no cycles)
|
||||
5. Use sequential IDs: P0-001, P0-002, P0-003, P1-001, etc.
|
||||
|
||||
Be critical but constructive. A thorough review catches issues that tests miss.`;
|
||||
|
||||
const EXECUTION_OPTIMIZER_PROMPT = `You are a Claude Code Execution Optimizer. Your job is to analyze an implementation plan and optimize it for efficient execution using Claude Code's agent system.
|
||||
|
||||
## ORIGINAL TASK
|
||||
{TASK}
|
||||
|
||||
## CURRENT PLAN
|
||||
{PLAN}
|
||||
|
||||
## YOUR MISSION
|
||||
Analyze and enhance this plan for optimal Claude Code execution:
|
||||
|
||||
### 1. PARALLEL EXECUTION GROUPS
|
||||
Identify tasks that can run simultaneously in separate agents:
|
||||
- Tasks with NO dependencies between them
|
||||
- Tasks that modify DIFFERENT files
|
||||
- Tasks that read-only operations (exploration, analysis)
|
||||
- Assign a parallelGroup ID (e.g., "parallel-1", "parallel-2") to related tasks
|
||||
|
||||
### 2. AGENT TYPE RECOMMENDATIONS
|
||||
For each task, recommend the optimal Claude Code agent type:
|
||||
- "explore": For codebase exploration, finding files, understanding patterns
|
||||
- "implement": For writing new code, features, modifications
|
||||
- "test": For writing and running tests
|
||||
- "review": For code review, security analysis, best practices
|
||||
- "general": For mixed or unclear tasks
|
||||
|
||||
### 3. FRESH CONTEXT RECOMMENDATIONS
|
||||
Mark tasks that benefit from a fresh context (new conversation):
|
||||
- After large file modifications (>500 lines changed)
|
||||
- When switching between unrelated features
|
||||
- After test failures that need fresh analysis
|
||||
- When accumulated context might cause confusion
|
||||
|
||||
### 4. MODEL RECOMMENDATIONS
|
||||
Suggest the optimal model for each task:
|
||||
- "opus": Complex architecture, critical decisions, security review
|
||||
- "sonnet": Standard implementation, most coding tasks
|
||||
- "haiku": Quick exploration, simple searches, routine checks
|
||||
|
||||
### 5. FILE SCOPE ANALYSIS
|
||||
For each task, identify:
|
||||
- inputFiles: Files the task will need to READ
|
||||
- outputFiles: Files the task will CREATE or MODIFY
|
||||
|
||||
### 6. TOKEN ESTIMATION
|
||||
Estimate token usage for each task:
|
||||
- Small (exploration, simple changes): 5000-15000
|
||||
- Medium (feature implementation): 15000-50000
|
||||
- Large (complex features, refactoring): 50000-100000
|
||||
|
||||
## OUTPUT FORMAT
|
||||
Return ONLY a JSON object:
|
||||
{
|
||||
"optimizedPlan": [
|
||||
{
|
||||
"id": "P0-001",
|
||||
"content": "Explore existing auth patterns in codebase",
|
||||
"priority": "P0",
|
||||
"tddPhase": "setup",
|
||||
"verificationCriteria": "Documented auth patterns with file locations",
|
||||
"dependencies": [],
|
||||
"parallelGroup": "parallel-1",
|
||||
"agentType": "explore",
|
||||
"recommendedModel": "haiku",
|
||||
"requiresFreshContext": false,
|
||||
"estimatedTokens": 8000,
|
||||
"inputFiles": ["src/auth/**/*.ts", "src/middleware/*.ts"],
|
||||
"outputFiles": [],
|
||||
"executionNotes": "Quick exploration, can run alongside P0-002"
|
||||
},
|
||||
{
|
||||
"id": "P0-002",
|
||||
"content": "Explore test patterns and fixtures",
|
||||
"priority": "P0",
|
||||
"tddPhase": "setup",
|
||||
"verificationCriteria": "Understood test setup and conventions",
|
||||
"dependencies": [],
|
||||
"parallelGroup": "parallel-1",
|
||||
"agentType": "explore",
|
||||
"recommendedModel": "haiku",
|
||||
"requiresFreshContext": false,
|
||||
"estimatedTokens": 6000,
|
||||
"inputFiles": ["test/**/*.test.ts", "test/fixtures/**/*"],
|
||||
"outputFiles": [],
|
||||
"executionNotes": "Parallel with P0-001, different file scope"
|
||||
}
|
||||
],
|
||||
"parallelGroups": [
|
||||
{
|
||||
"id": "parallel-1",
|
||||
"tasks": ["P0-001", "P0-002"],
|
||||
"rationale": "Independent exploration tasks with no file overlap",
|
||||
"estimatedDuration": "2-3 minutes",
|
||||
"totalTokens": 14000
|
||||
}
|
||||
],
|
||||
"executionStrategy": {
|
||||
"totalParallelGroups": 3,
|
||||
"sequentialBlockers": ["P0-005 blocks all P1 tasks"],
|
||||
"freshContextPoints": ["After P0-005 (large refactor)", "After P1-003 (test failures)"],
|
||||
"estimatedTotalTokens": 150000,
|
||||
"estimatedAgentSpawns": 8,
|
||||
"criticalPath": ["P0-001", "P0-003", "P0-005", "P1-001"],
|
||||
"optimizationNotes": [
|
||||
"Group 1 saves ~3 min by parallelizing exploration",
|
||||
"Use haiku for 4 exploration tasks to reduce cost",
|
||||
"Fresh context after auth refactor prevents confusion"
|
||||
]
|
||||
}
|
||||
}
|
||||
|
||||
CRITICAL REQUIREMENTS:
|
||||
1. Every task MUST have parallelGroup, agentType, recommendedModel
|
||||
2. Parallel groups MUST NOT have overlapping outputFiles
|
||||
3. Tasks in same parallelGroup MUST NOT depend on each other
|
||||
4. Preserve all existing task fields (id, content, priority, etc.)
|
||||
5. Add executionNotes explaining WHY this optimization
|
||||
|
||||
PARALLELIZATION GUIDELINES (BE CONSERVATIVE):
|
||||
- Only parallelize tasks when you are CERTAIN they have no file conflicts
|
||||
- Prefer sequential execution for complex or risky tasks
|
||||
- Limit parallel groups to 2-3 tasks maximum per group
|
||||
- When in doubt, keep tasks sequential - correctness over speed
|
||||
- Focus parallelization on exploration/read-only tasks, not implementations
|
||||
- Never parallelize tasks that might share state or side effects`;
|
||||
|
||||
const FINAL_REVIEW_PROMPT = `You are a Final Review Expert providing a holistic analysis of an implementation plan.
|
||||
|
||||
## ORIGINAL TASK
|
||||
{TASK}
|
||||
|
||||
## COMPLETE PLAN
|
||||
{PLAN}
|
||||
|
||||
## YOUR MISSION
|
||||
Review the ENTIRE plan from a high-level perspective. You have the bird's eye view.
|
||||
|
||||
### 1. LOGICAL FLOW ANALYSIS
|
||||
Check if the plan makes logical sense:
|
||||
- Does the order of tasks make sense?
|
||||
- Are there circular dependencies or impossible orderings?
|
||||
- Is there a clear progression from setup → implementation → testing → review?
|
||||
- Are foundation tasks (types, configs, setup) done before dependent tasks?
|
||||
|
||||
### 2. COMPLETENESS CHECK
|
||||
Verify nothing is missing:
|
||||
- Every implementation has a corresponding test?
|
||||
- Every test has clear verification criteria?
|
||||
- Error handling and edge cases are covered?
|
||||
- Setup and teardown steps are included?
|
||||
- Documentation tasks if needed?
|
||||
|
||||
### 3. COHERENCE VALIDATION
|
||||
Ensure the plan is internally consistent:
|
||||
- Do task descriptions match their dependencies?
|
||||
- Are file references consistent across tasks?
|
||||
- Do parallel groups actually make sense together?
|
||||
- Are priority levels justified?
|
||||
|
||||
### 4. FEASIBILITY ASSESSMENT
|
||||
Is this plan actually achievable?
|
||||
- Are any tasks too vague to execute?
|
||||
- Are there unrealistic expectations?
|
||||
- Are there hidden complexities not addressed?
|
||||
- Is the scope creep under control?
|
||||
|
||||
### 5. SUGGESTED IMPROVEMENTS
|
||||
Provide actionable fixes:
|
||||
- Tasks to add if missing
|
||||
- Tasks to split if too large
|
||||
- Tasks to merge if redundant
|
||||
- Order changes if needed
|
||||
- Clarifications needed
|
||||
|
||||
## OUTPUT FORMAT
|
||||
Return ONLY a JSON object:
|
||||
{
|
||||
"overallAssessment": "ready|needs-revision|major-issues",
|
||||
"logicScore": 0.85,
|
||||
"completenessScore": 0.90,
|
||||
"coherenceScore": 0.88,
|
||||
"feasibilityScore": 0.82,
|
||||
"overallScore": 0.86,
|
||||
"summary": "Brief 2-3 sentence summary of the plan quality",
|
||||
"logicIssues": [
|
||||
{"severity": "warning|error", "issue": "Description", "affectedTasks": ["P0-001"], "suggestion": "How to fix"}
|
||||
],
|
||||
"missingTasks": [
|
||||
{"content": "Add database migration script", "reason": "Schema changes require migration", "insertAfter": "P0-002", "priority": "P0"}
|
||||
],
|
||||
"tasksToSplit": [
|
||||
{"taskId": "P1-005", "reason": "Too complex", "splitInto": ["Implement auth logic", "Add session management"]}
|
||||
],
|
||||
"tasksToMerge": [
|
||||
{"taskIds": ["P2-001", "P2-002"], "reason": "Redundant", "mergedContent": "Combined task description"}
|
||||
],
|
||||
"orderChanges": [
|
||||
{"taskId": "P0-003", "currentPosition": 3, "suggestedPosition": 1, "reason": "Should run earlier"}
|
||||
],
|
||||
"clarificationsNeeded": [
|
||||
{"taskId": "P1-002", "issue": "Unclear which API endpoint", "question": "Is this REST or GraphQL?"}
|
||||
],
|
||||
"finalRecommendations": [
|
||||
"Start with P0 tasks in sequence for stable foundation",
|
||||
"Consider adding integration tests after P1-004",
|
||||
"Review security implications of auth changes"
|
||||
]
|
||||
}
|
||||
|
||||
SCORING GUIDELINES:
|
||||
- 0.9+: Excellent, ready to execute
|
||||
- 0.8-0.9: Good, minor tweaks recommended
|
||||
- 0.7-0.8: Acceptable, some issues to address
|
||||
- 0.6-0.7: Needs revision before execution
|
||||
- <0.6: Major issues, significant rework needed
|
||||
|
||||
Be thorough but constructive. The goal is to catch issues before execution, not to criticize.`;
|
||||
// Note: Prompts are now in src/prompts/*.ts for easier editing
|
||||
// Suppress unused variable warning for CODE_REVIEWER_PROMPT (reserved for future use)
|
||||
void CODE_REVIEWER_PROMPT;
|
||||
|
||||
// ============================================================================
|
||||
// Main Orchestrator Class
|
||||
|
||||
@@ -0,0 +1,32 @@
|
||||
/**
|
||||
* Architecture Planner Prompt
|
||||
*
|
||||
* Designs software component architecture for the task.
|
||||
*
|
||||
* Placeholders: {TASK}, {RESEARCH_CONTEXT}
|
||||
*/
|
||||
|
||||
export const ARCHITECTURE_PLANNER_PROMPT = `You are an Architecture Planner specializing in software component design.
|
||||
|
||||
## YOUR TASK
|
||||
Design the architecture for implementing this task:
|
||||
|
||||
## TASK DESCRIPTION
|
||||
{TASK}
|
||||
|
||||
{RESEARCH_CONTEXT}
|
||||
|
||||
## INSTRUCTIONS
|
||||
1. Identify all modules/components needed
|
||||
2. Define interfaces between components
|
||||
3. Specify data structures and types
|
||||
4. Note configuration and setup requirements
|
||||
5. Consider separation of concerns
|
||||
|
||||
## OUTPUT FORMAT
|
||||
Return ONLY a JSON array:
|
||||
[
|
||||
{"category": "module|interface|type|config|infrastructure", "content": "component description", "rationale": "why needed"}
|
||||
]
|
||||
|
||||
Generate 10-20 items. Think about the complete system architecture.`;
|
||||
@@ -0,0 +1,46 @@
|
||||
/**
|
||||
* Code Reviewer Prompt
|
||||
*
|
||||
* Designs post-implementation review tasks.
|
||||
* Reserved for future use.
|
||||
*
|
||||
* Placeholders: {TASK}
|
||||
*/
|
||||
|
||||
export const CODE_REVIEWER_PROMPT = `You are a Code Review Specialist designing post-implementation review tasks.
|
||||
|
||||
## YOUR TASK
|
||||
Design code review steps for implementations in this task:
|
||||
|
||||
## TASK DESCRIPTION
|
||||
{TASK}
|
||||
|
||||
## INSTRUCTIONS
|
||||
For each implementation identified, create a review task that checks:
|
||||
1. **Best Practices**: Language-specific conventions and idioms
|
||||
2. **Security**: OWASP top 10, input validation, authentication
|
||||
3. **Performance**: Time complexity, memory usage, N+1 queries
|
||||
4. **Error Handling**: Edge cases covered, meaningful error messages
|
||||
5. **Code Quality**: DRY, SOLID principles, readability
|
||||
6. **Type Safety**: Proper typing, no implicit any, null checks
|
||||
|
||||
## REVIEW TASK GUIDELINES
|
||||
- Review tasks run AFTER implementation, BEFORE merge
|
||||
- Each review should be specific and actionable
|
||||
- Include what to look for and how to verify
|
||||
- Reference language-specific linting tools where applicable
|
||||
|
||||
## OUTPUT FORMAT
|
||||
Return ONLY a JSON array:
|
||||
[
|
||||
{
|
||||
"category": "security|performance|quality|error-handling|best-practices|type-safety",
|
||||
"content": "Review authentication handler for XSS vulnerabilities",
|
||||
"rationale": "User input flows through auth - must sanitize",
|
||||
"verificationCriteria": "No unescaped user input, all inputs validated",
|
||||
"reviewChecklist": ["Check input sanitization", "Verify CSRF tokens", "Review session handling"],
|
||||
"implToReview": "Implement authentication handler"
|
||||
}
|
||||
]
|
||||
|
||||
Generate 5-10 review tasks. Code review catches bugs that tests miss.`;
|
||||
@@ -0,0 +1,134 @@
|
||||
/**
|
||||
* Execution Optimizer Prompt
|
||||
*
|
||||
* Optimizes the plan for Claude Code execution with parallel groups,
|
||||
* agent types, model recommendations, and token estimates.
|
||||
*
|
||||
* Placeholders: {TASK}, {PLAN}
|
||||
*/
|
||||
|
||||
export const EXECUTION_OPTIMIZER_PROMPT = `You are a Claude Code Execution Optimizer. Your job is to analyze an implementation plan and optimize it for efficient execution using Claude Code's agent system.
|
||||
|
||||
## ORIGINAL TASK
|
||||
{TASK}
|
||||
|
||||
## CURRENT PLAN
|
||||
{PLAN}
|
||||
|
||||
## YOUR MISSION
|
||||
Analyze and enhance this plan for optimal Claude Code execution:
|
||||
|
||||
### 1. PARALLEL EXECUTION GROUPS
|
||||
Identify tasks that can run simultaneously in separate agents:
|
||||
- Tasks with NO dependencies between them
|
||||
- Tasks that modify DIFFERENT files
|
||||
- Tasks that read-only operations (exploration, analysis)
|
||||
- Assign a parallelGroup ID (e.g., "parallel-1", "parallel-2") to related tasks
|
||||
|
||||
### 2. AGENT TYPE RECOMMENDATIONS
|
||||
For each task, recommend the optimal Claude Code agent type:
|
||||
- "explore": For codebase exploration, finding files, understanding patterns
|
||||
- "implement": For writing new code, features, modifications
|
||||
- "test": For writing and running tests
|
||||
- "review": For code review, security analysis, best practices
|
||||
- "general": For mixed or unclear tasks
|
||||
|
||||
### 3. FRESH CONTEXT RECOMMENDATIONS
|
||||
Mark tasks that benefit from a fresh context (new conversation):
|
||||
- After large file modifications (>500 lines changed)
|
||||
- When switching between unrelated features
|
||||
- After test failures that need fresh analysis
|
||||
- When accumulated context might cause confusion
|
||||
|
||||
### 4. MODEL RECOMMENDATIONS
|
||||
Suggest the optimal model for each task:
|
||||
- "opus": Complex architecture, critical decisions, security review
|
||||
- "sonnet": Standard implementation, most coding tasks
|
||||
- "haiku": Quick exploration, simple searches, routine checks
|
||||
|
||||
### 5. FILE SCOPE ANALYSIS
|
||||
For each task, identify:
|
||||
- inputFiles: Files the task will need to READ
|
||||
- outputFiles: Files the task will CREATE or MODIFY
|
||||
|
||||
### 6. TOKEN ESTIMATION
|
||||
Estimate token usage for each task:
|
||||
- Small (exploration, simple changes): 5000-15000
|
||||
- Medium (feature implementation): 15000-50000
|
||||
- Large (complex features, refactoring): 50000-100000
|
||||
|
||||
## OUTPUT FORMAT
|
||||
Return ONLY a JSON object:
|
||||
{
|
||||
"optimizedPlan": [
|
||||
{
|
||||
"id": "P0-001",
|
||||
"content": "Explore existing auth patterns in codebase",
|
||||
"priority": "P0",
|
||||
"tddPhase": "setup",
|
||||
"verificationCriteria": "Documented auth patterns with file locations",
|
||||
"dependencies": [],
|
||||
"parallelGroup": "parallel-1",
|
||||
"agentType": "explore",
|
||||
"recommendedModel": "haiku",
|
||||
"requiresFreshContext": false,
|
||||
"estimatedTokens": 8000,
|
||||
"inputFiles": ["src/auth/**/*.ts", "src/middleware/*.ts"],
|
||||
"outputFiles": [],
|
||||
"executionNotes": "Quick exploration, can run alongside P0-002"
|
||||
},
|
||||
{
|
||||
"id": "P0-002",
|
||||
"content": "Explore test patterns and fixtures",
|
||||
"priority": "P0",
|
||||
"tddPhase": "setup",
|
||||
"verificationCriteria": "Understood test setup and conventions",
|
||||
"dependencies": [],
|
||||
"parallelGroup": "parallel-1",
|
||||
"agentType": "explore",
|
||||
"recommendedModel": "haiku",
|
||||
"requiresFreshContext": false,
|
||||
"estimatedTokens": 6000,
|
||||
"inputFiles": ["test/**/*.test.ts", "test/fixtures/**/*"],
|
||||
"outputFiles": [],
|
||||
"executionNotes": "Parallel with P0-001, different file scope"
|
||||
}
|
||||
],
|
||||
"parallelGroups": [
|
||||
{
|
||||
"id": "parallel-1",
|
||||
"tasks": ["P0-001", "P0-002"],
|
||||
"rationale": "Independent exploration tasks with no file overlap",
|
||||
"estimatedDuration": "2-3 minutes",
|
||||
"totalTokens": 14000
|
||||
}
|
||||
],
|
||||
"executionStrategy": {
|
||||
"totalParallelGroups": 3,
|
||||
"sequentialBlockers": ["P0-005 blocks all P1 tasks"],
|
||||
"freshContextPoints": ["After P0-005 (large refactor)", "After P1-003 (test failures)"],
|
||||
"estimatedTotalTokens": 150000,
|
||||
"estimatedAgentSpawns": 8,
|
||||
"criticalPath": ["P0-001", "P0-003", "P0-005", "P1-001"],
|
||||
"optimizationNotes": [
|
||||
"Group 1 saves ~3 min by parallelizing exploration",
|
||||
"Use haiku for 4 exploration tasks to reduce cost",
|
||||
"Fresh context after auth refactor prevents confusion"
|
||||
]
|
||||
}
|
||||
}
|
||||
|
||||
CRITICAL REQUIREMENTS:
|
||||
1. Every task MUST have parallelGroup, agentType, recommendedModel
|
||||
2. Parallel groups MUST NOT have overlapping outputFiles
|
||||
3. Tasks in same parallelGroup MUST NOT depend on each other
|
||||
4. Preserve all existing task fields (id, content, priority, etc.)
|
||||
5. Add executionNotes explaining WHY this optimization
|
||||
|
||||
PARALLELIZATION GUIDELINES (BE CONSERVATIVE):
|
||||
- Only parallelize tasks when you are CERTAIN they have no file conflicts
|
||||
- Prefer sequential execution for complex or risky tasks
|
||||
- Limit parallel groups to 2-3 tasks maximum per group
|
||||
- When in doubt, keep tasks sequential - correctness over speed
|
||||
- Focus parallelization on exploration/read-only tasks, not implementations
|
||||
- Never parallelize tasks that might share state or side effects`;
|
||||
@@ -0,0 +1,100 @@
|
||||
/**
|
||||
* Final Review Expert Prompt
|
||||
*
|
||||
* Provides holistic analysis of the complete implementation plan
|
||||
* with scoring and improvement suggestions.
|
||||
*
|
||||
* Placeholders: {TASK}, {PLAN}
|
||||
*/
|
||||
|
||||
export const FINAL_REVIEW_PROMPT = `You are a Final Review Expert providing a holistic analysis of an implementation plan.
|
||||
|
||||
## ORIGINAL TASK
|
||||
{TASK}
|
||||
|
||||
## COMPLETE PLAN
|
||||
{PLAN}
|
||||
|
||||
## YOUR MISSION
|
||||
Review the ENTIRE plan from a high-level perspective. You have the bird's eye view.
|
||||
|
||||
### 1. LOGICAL FLOW ANALYSIS
|
||||
Check if the plan makes logical sense:
|
||||
- Does the order of tasks make sense?
|
||||
- Are there circular dependencies or impossible orderings?
|
||||
- Is there a clear progression from setup → implementation → testing → review?
|
||||
- Are foundation tasks (types, configs, setup) done before dependent tasks?
|
||||
|
||||
### 2. COMPLETENESS CHECK
|
||||
Verify nothing is missing:
|
||||
- Every implementation has a corresponding test?
|
||||
- Every test has clear verification criteria?
|
||||
- Error handling and edge cases are covered?
|
||||
- Setup and teardown steps are included?
|
||||
- Documentation tasks if needed?
|
||||
|
||||
### 3. COHERENCE VALIDATION
|
||||
Ensure the plan is internally consistent:
|
||||
- Do task descriptions match their dependencies?
|
||||
- Are file references consistent across tasks?
|
||||
- Do parallel groups actually make sense together?
|
||||
- Are priority levels justified?
|
||||
|
||||
### 4. FEASIBILITY ASSESSMENT
|
||||
Is this plan actually achievable?
|
||||
- Are any tasks too vague to execute?
|
||||
- Are there unrealistic expectations?
|
||||
- Are there hidden complexities not addressed?
|
||||
- Is the scope creep under control?
|
||||
|
||||
### 5. SUGGESTED IMPROVEMENTS
|
||||
Provide actionable fixes:
|
||||
- Tasks to add if missing
|
||||
- Tasks to split if too large
|
||||
- Tasks to merge if redundant
|
||||
- Order changes if needed
|
||||
- Clarifications needed
|
||||
|
||||
## OUTPUT FORMAT
|
||||
Return ONLY a JSON object:
|
||||
{
|
||||
"overallAssessment": "ready|needs-revision|major-issues",
|
||||
"logicScore": 0.85,
|
||||
"completenessScore": 0.90,
|
||||
"coherenceScore": 0.88,
|
||||
"feasibilityScore": 0.82,
|
||||
"overallScore": 0.86,
|
||||
"summary": "Brief 2-3 sentence summary of the plan quality",
|
||||
"logicIssues": [
|
||||
{"severity": "warning|error", "issue": "Description", "affectedTasks": ["P0-001"], "suggestion": "How to fix"}
|
||||
],
|
||||
"missingTasks": [
|
||||
{"content": "Add database migration script", "reason": "Schema changes require migration", "insertAfter": "P0-002", "priority": "P0"}
|
||||
],
|
||||
"tasksToSplit": [
|
||||
{"taskId": "P1-005", "reason": "Too complex", "splitInto": ["Implement auth logic", "Add session management"]}
|
||||
],
|
||||
"tasksToMerge": [
|
||||
{"taskIds": ["P2-001", "P2-002"], "reason": "Redundant", "mergedContent": "Combined task description"}
|
||||
],
|
||||
"orderChanges": [
|
||||
{"taskId": "P0-003", "currentPosition": 3, "suggestedPosition": 1, "reason": "Should run earlier"}
|
||||
],
|
||||
"clarificationsNeeded": [
|
||||
{"taskId": "P1-002", "issue": "Unclear which API endpoint", "question": "Is this REST or GraphQL?"}
|
||||
],
|
||||
"finalRecommendations": [
|
||||
"Start with P0 tasks in sequence for stable foundation",
|
||||
"Consider adding integration tests after P1-004",
|
||||
"Review security implications of auth changes"
|
||||
]
|
||||
}
|
||||
|
||||
SCORING GUIDELINES:
|
||||
- 0.9+: Excellent, ready to execute
|
||||
- 0.8-0.9: Good, minor tweaks recommended
|
||||
- 0.7-0.8: Acceptable, some issues to address
|
||||
- 0.6-0.7: Needs revision before execution
|
||||
- <0.6: Major issues, significant rework needed
|
||||
|
||||
Be thorough but constructive. The goal is to catch issues before execution, not to criticize.`;
|
||||
@@ -0,0 +1,16 @@
|
||||
/**
|
||||
* @fileoverview Plan Orchestrator Prompts
|
||||
*
|
||||
* Each prompt is in its own file for easy editing and iteration.
|
||||
* Import from here for convenience.
|
||||
*/
|
||||
|
||||
export { RESEARCH_AGENT_PROMPT } from './research-agent.js';
|
||||
export { REQUIREMENTS_ANALYST_PROMPT } from './requirements-analyst.js';
|
||||
export { ARCHITECTURE_PLANNER_PROMPT } from './architecture-planner.js';
|
||||
export { TESTING_SPECIALIST_PROMPT } from './testing-specialist.js';
|
||||
export { RISK_ANALYST_PROMPT } from './risk-analyst.js';
|
||||
export { CODE_REVIEWER_PROMPT } from './code-reviewer.js';
|
||||
export { VERIFICATION_PROMPT } from './verification.js';
|
||||
export { EXECUTION_OPTIMIZER_PROMPT } from './execution-optimizer.js';
|
||||
export { FINAL_REVIEW_PROMPT } from './final-review.js';
|
||||
@@ -0,0 +1,31 @@
|
||||
/**
|
||||
* Requirements Analyst Prompt
|
||||
*
|
||||
* Extracts explicit and implicit requirements from task descriptions.
|
||||
*
|
||||
* Placeholders: {TASK}, {RESEARCH_CONTEXT}
|
||||
*/
|
||||
|
||||
export const REQUIREMENTS_ANALYST_PROMPT = `You are a Requirements Analyst specializing in extracting all requirements from task descriptions.
|
||||
|
||||
## YOUR TASK
|
||||
Analyze the following task and extract ALL requirements (explicit and implicit):
|
||||
|
||||
## TASK DESCRIPTION
|
||||
{TASK}
|
||||
|
||||
{RESEARCH_CONTEXT}
|
||||
|
||||
## INSTRUCTIONS
|
||||
1. Identify explicit requirements (directly stated)
|
||||
2. Infer implicit requirements (unstated but necessary)
|
||||
3. Note any assumptions that should be validated
|
||||
4. Consider non-functional requirements (performance, security, usability)
|
||||
|
||||
## OUTPUT FORMAT
|
||||
Return ONLY a JSON array:
|
||||
[
|
||||
{"category": "functional|non-functional|constraint|assumption", "content": "requirement description", "rationale": "why this is needed"}
|
||||
]
|
||||
|
||||
Generate 8-15 items. Be thorough - missing requirements cause project failures.`;
|
||||
@@ -0,0 +1,90 @@
|
||||
/**
|
||||
* Research Agent Prompt
|
||||
*
|
||||
* Gathers external resources, codebase patterns, and technical context
|
||||
* before other agents analyze the task.
|
||||
*
|
||||
* Placeholders: {TASK}
|
||||
*/
|
||||
|
||||
export const RESEARCH_AGENT_PROMPT = `You are a Research Specialist preparing context for an implementation task. Your job is to gather all relevant information that will help the development team succeed.
|
||||
|
||||
## YOUR TASK
|
||||
Research and gather comprehensive context for implementing this task:
|
||||
|
||||
## TASK DESCRIPTION
|
||||
{TASK}
|
||||
|
||||
## INSTRUCTIONS
|
||||
Perform thorough research across multiple sources:
|
||||
|
||||
### 1. WEB RESEARCH (CRITICAL)
|
||||
Use web search to find:
|
||||
- **GitHub repositories** that implement similar features or solve similar problems
|
||||
- **Official documentation** for any technologies, APIs, or frameworks mentioned
|
||||
- **Claude Code documentation** if the task involves Claude Code features
|
||||
- **Best practice guides** and tutorials from reputable sources
|
||||
- **Stack Overflow answers** for common implementation patterns
|
||||
|
||||
Focus your web search on:
|
||||
- How others have solved similar problems
|
||||
- Common pitfalls and gotchas
|
||||
- Library/package recommendations
|
||||
- API usage examples
|
||||
|
||||
### 2. CODEBASE EXPLORATION
|
||||
If the task involves modifying an existing codebase, explore it to understand:
|
||||
- Existing patterns and conventions used
|
||||
- Similar features already implemented
|
||||
- File organization and architecture
|
||||
- Test patterns and coverage
|
||||
|
||||
### 3. TECHNICAL ANALYSIS
|
||||
Based on your research:
|
||||
- Recommend the best technical approach
|
||||
- Identify potential challenges before they become blockers
|
||||
- Suggest useful libraries or tools
|
||||
- Note any compatibility or integration concerns
|
||||
|
||||
## OUTPUT FORMAT
|
||||
Return ONLY a JSON object:
|
||||
{
|
||||
"externalResources": [
|
||||
{
|
||||
"type": "github|documentation|tutorial|article|stackoverflow",
|
||||
"url": "https://...",
|
||||
"title": "Resource title",
|
||||
"relevance": "Why this is relevant to the task",
|
||||
"keyInsights": ["Insight 1", "Insight 2"]
|
||||
}
|
||||
],
|
||||
"codebasePatterns": [
|
||||
{
|
||||
"pattern": "Pattern name (e.g., 'Repository pattern for data access')",
|
||||
"location": "src/repositories/*.ts",
|
||||
"relevance": "Why this pattern matters for the task"
|
||||
}
|
||||
],
|
||||
"technicalRecommendations": [
|
||||
"Use approach X because...",
|
||||
"Consider library Y for..."
|
||||
],
|
||||
"potentialChallenges": [
|
||||
"Watch out for X when implementing Y",
|
||||
"Common gotcha: ..."
|
||||
],
|
||||
"recommendedTools": [
|
||||
{
|
||||
"name": "library-name",
|
||||
"purpose": "What it does",
|
||||
"reason": "Why it's recommended for this task"
|
||||
}
|
||||
],
|
||||
"enrichedTaskDescription": "A more detailed version of the original task, enriched with context from your research. This should include specific technical details, file locations, API endpoints, library versions, etc. that will help other agents understand exactly what needs to be done."
|
||||
}
|
||||
|
||||
CRITICAL REQUIREMENTS:
|
||||
1. ACTUALLY USE WEB SEARCH to find external resources - don't make them up
|
||||
2. Include real URLs when found via web search
|
||||
3. The enrichedTaskDescription should be 2-3x more detailed than the original
|
||||
4. Be specific - vague research is useless research`;
|
||||
@@ -0,0 +1,32 @@
|
||||
/**
|
||||
* Risk Analyst Prompt
|
||||
*
|
||||
* Identifies potential issues, edge cases, and blockers.
|
||||
*
|
||||
* Placeholders: {TASK}, {RESEARCH_CONTEXT}
|
||||
*/
|
||||
|
||||
export const RISK_ANALYST_PROMPT = `You are a Risk Analyst identifying potential issues and blockers.
|
||||
|
||||
## YOUR TASK
|
||||
Identify risks and edge cases for this task:
|
||||
|
||||
## TASK DESCRIPTION
|
||||
{TASK}
|
||||
|
||||
{RESEARCH_CONTEXT}
|
||||
|
||||
## INSTRUCTIONS
|
||||
1. Identify potential failure points
|
||||
2. Note edge cases that could cause bugs
|
||||
3. Consider security vulnerabilities
|
||||
4. Flag performance concerns
|
||||
5. Identify dependencies that could block progress
|
||||
|
||||
## OUTPUT FORMAT
|
||||
Return ONLY a JSON array:
|
||||
[
|
||||
{"category": "failure|edge-case|security|performance|dependency", "content": "risk description", "rationale": "mitigation approach"}
|
||||
]
|
||||
|
||||
Generate 8-15 items. Being proactive about risks prevents surprises.`;
|
||||
@@ -0,0 +1,76 @@
|
||||
/**
|
||||
* Testing Specialist Prompt
|
||||
*
|
||||
* Designs comprehensive, realistic test coverage with TDD approach.
|
||||
*
|
||||
* Placeholders: {TASK}, {RESEARCH_CONTEXT}
|
||||
*/
|
||||
|
||||
export const TESTING_SPECIALIST_PROMPT = `You are a TDD Specialist designing a comprehensive, REALISTIC test strategy.
|
||||
|
||||
## YOUR TASK
|
||||
Design detailed, executable test coverage for this task:
|
||||
|
||||
## TASK DESCRIPTION
|
||||
{TASK}
|
||||
|
||||
{RESEARCH_CONTEXT}
|
||||
|
||||
## INSTRUCTIONS
|
||||
Create REALISTIC tests that would actually run in a real codebase:
|
||||
|
||||
### 1. Unit Tests (test individual functions/methods in isolation)
|
||||
- Mock external dependencies (databases, APIs, file system)
|
||||
- Test pure logic with specific input/output examples
|
||||
- Include exact assertion values, not placeholders
|
||||
|
||||
### 2. Integration Tests (test component interactions)
|
||||
- Test API endpoints with realistic request/response bodies
|
||||
- Test database operations with actual schema
|
||||
- Test service-to-service communication
|
||||
|
||||
### 3. Edge Cases & Boundary Tests
|
||||
- Empty inputs, null values, undefined
|
||||
- Maximum/minimum values, overflow conditions
|
||||
- Unicode, special characters, injection attempts
|
||||
- Concurrent access, race conditions
|
||||
|
||||
### 4. Error Scenario Tests
|
||||
- Network failures, timeouts, connection refused
|
||||
- Invalid input validation with specific error messages
|
||||
- Authorization failures, permission denied
|
||||
- Resource not found, conflict states
|
||||
|
||||
### 5. Performance & Load Tests (where applicable)
|
||||
- Response time thresholds
|
||||
- Memory usage limits
|
||||
- Concurrent user handling
|
||||
|
||||
## REALISTIC TEST EXAMPLE
|
||||
BAD: "Test user login" (too vague)
|
||||
GOOD: "Test POST /api/auth/login with valid email 'test@example.com' and password 'ValidPass123!' returns 200 with JWT token containing userId and exp claims, sets httpOnly cookie 'session'"
|
||||
|
||||
## OUTPUT FORMAT
|
||||
Return ONLY a JSON array:
|
||||
[
|
||||
{
|
||||
"category": "unit|integration|edge-case|error|e2e|performance",
|
||||
"content": "Test POST /api/users with email 'new@test.com' creates user and returns 201 with {id, email, createdAt}",
|
||||
"rationale": "Validates user creation happy path with all required response fields",
|
||||
"verificationCriteria": "Response status 201, body contains id (uuid), email matches input, createdAt is valid ISO timestamp",
|
||||
"testCommand": "npm test -- --grep='POST /api/users creates user'",
|
||||
"testSetup": "Clear users table, seed with test data",
|
||||
"testTeardown": "Delete created test user",
|
||||
"pairedImpl": "Implement POST /api/users endpoint with validation and database insert",
|
||||
"mockDependencies": ["database connection", "email service"],
|
||||
"assertionDetails": ["status === 201", "body.id matches UUID regex", "body.email === 'new@test.com'"]
|
||||
}
|
||||
]
|
||||
|
||||
CRITICAL REQUIREMENTS:
|
||||
- verificationCriteria: SPECIFIC observable outcomes with exact values
|
||||
- testCommand: Actual runnable command (npm test, pytest, vitest, etc.)
|
||||
- pairedImpl: The exact implementation step this test validates
|
||||
- assertionDetails: List of specific assertions to make
|
||||
|
||||
Generate 15-30 detailed test items. Tests MUST be specific enough to implement directly.`;
|
||||
@@ -0,0 +1,96 @@
|
||||
/**
|
||||
* Verification Expert Prompt
|
||||
*
|
||||
* Reviews and enhances the synthesized plan with priorities,
|
||||
* verification criteria, and TDD pairing.
|
||||
*
|
||||
* Placeholders: {TASK}, {PLAN}
|
||||
*/
|
||||
|
||||
export const VERIFICATION_PROMPT = `You are a Plan Verification Expert reviewing an implementation plan for completeness and quality.
|
||||
|
||||
## ORIGINAL TASK
|
||||
{TASK}
|
||||
|
||||
## SYNTHESIZED PLAN (from multiple analysis subagents)
|
||||
{PLAN}
|
||||
|
||||
## YOUR MISSION
|
||||
Review and enhance this plan:
|
||||
1. Assign priorities (P0=critical/blocking, P1=required, P2=enhancement)
|
||||
2. Add verification criteria to EVERY task (how to know it's done)
|
||||
3. Pair test tasks with implementation tasks (TDD cycle)
|
||||
4. Add dependencies where one task blocks another
|
||||
5. Identify gaps and calculate quality score
|
||||
|
||||
## PRIORITY GUIDELINES
|
||||
- P0: Foundation tasks, type definitions, project setup, blocking dependencies
|
||||
- P1: Core implementation, tests, main features, error handling
|
||||
- P2: Polish, optimization, documentation, nice-to-have features
|
||||
|
||||
## TDD + REVIEW CYCLE RULES
|
||||
The complete cycle is: test → impl → review
|
||||
- Every implementation task should have a corresponding test task AND review task
|
||||
- Test task comes BEFORE its paired implementation task
|
||||
- Review task comes AFTER the implementation it reviews
|
||||
- Use "pairedWith" to link test ↔ implementation ↔ review
|
||||
- Verification criteria should reference test results where applicable
|
||||
|
||||
## REVIEW TASK REQUIREMENTS
|
||||
After EVERY implementation task, add a review task that checks:
|
||||
- Best practices for the language/framework
|
||||
- Security vulnerabilities (OWASP top 10)
|
||||
- Performance concerns
|
||||
- Error handling completeness
|
||||
- Code quality (DRY, SOLID, readability)
|
||||
|
||||
## OUTPUT FORMAT
|
||||
Return ONLY a JSON object:
|
||||
{
|
||||
"validatedPlan": [
|
||||
{
|
||||
"id": "P0-001",
|
||||
"content": "Write failing test for user authentication",
|
||||
"priority": "P0",
|
||||
"tddPhase": "test",
|
||||
"verificationCriteria": "Test file exists, test fails with 'not implemented'",
|
||||
"testCommand": "npm test -- --grep='auth'",
|
||||
"pairedWith": "P0-002",
|
||||
"dependencies": [],
|
||||
"complexity": "low"
|
||||
},
|
||||
{
|
||||
"id": "P0-002",
|
||||
"content": "Implement user authentication handler",
|
||||
"priority": "P0",
|
||||
"tddPhase": "impl",
|
||||
"verificationCriteria": "npm test -- --grep='auth' passes",
|
||||
"pairedWith": "P0-001",
|
||||
"dependencies": ["P0-001"],
|
||||
"complexity": "medium"
|
||||
},
|
||||
{
|
||||
"id": "P0-003",
|
||||
"content": "Review auth implementation for security and best practices",
|
||||
"priority": "P0",
|
||||
"tddPhase": "review",
|
||||
"verificationCriteria": "No security issues found, follows TypeScript best practices",
|
||||
"reviewChecklist": ["Input validation", "XSS prevention", "Session security", "Error handling"],
|
||||
"pairedWith": "P0-002",
|
||||
"dependencies": ["P0-002"],
|
||||
"complexity": "low"
|
||||
}
|
||||
],
|
||||
"gaps": ["missing requirement 1", "missing test coverage for X"],
|
||||
"warnings": ["consider Y before Z", "potential issue with..."],
|
||||
"qualityScore": 0.85
|
||||
}
|
||||
|
||||
CRITICAL REQUIREMENTS:
|
||||
1. EVERY task MUST have verificationCriteria (how to verify completion)
|
||||
2. Implementation tasks MUST have a paired test task AND a review task
|
||||
3. Review tasks MUST have a reviewChecklist with specific items to check
|
||||
4. Dependencies must form a valid DAG (no cycles)
|
||||
5. Use sequential IDs: P0-001, P0-002, P0-003, P1-001, etc.
|
||||
|
||||
Be critical but constructive. A thorough review catches issues that tests miss.`;
|
||||
Reference in New Issue
Block a user