@exaudeus/workrail 0.1.9 → 0.1.10
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/dist/application/decorators/simple-output-decorator.js +1 -1
- package/package.json +1 -1
- package/spec/mcp-api-v1.0.md +2 -2
- package/spec/examples/coding-task-workflow.json +0 -160
- package/workflows/coding-task-workflow.json +0 -352
- package/workflows/systemic-bug-investigation.json +0 -398
- package/workflows/systemic-bug-investigation.json.bak +0 -196
|
@@ -33,7 +33,7 @@ The MCP server is STATELESS. You MUST send required data with each request:
|
|
|
33
33
|
**EXAMPLE - Loop Context:**
|
|
34
34
|
\`\`\`json
|
|
35
35
|
{
|
|
36
|
-
"workflowId": "coding-task-workflow",
|
|
36
|
+
"workflowId": "coding-task-workflow-with-loops",
|
|
37
37
|
"completedSteps": ["phase-1", "phase-2", "loop-step-1"],
|
|
38
38
|
"context": {
|
|
39
39
|
// Required: condition/template variables
|
package/package.json
CHANGED
package/spec/mcp-api-v1.0.md
CHANGED
|
@@ -175,7 +175,7 @@ Retrieves workflow information with configurable detail level. Supports progress
|
|
|
175
175
|
"jsonrpc": "2.0",
|
|
176
176
|
"id": 2,
|
|
177
177
|
"result": {
|
|
178
|
-
"id": "coding-task-workflow",
|
|
178
|
+
"id": "coding-task-workflow-with-loops",
|
|
179
179
|
"name": "Excellent Adaptive Coding Workflow",
|
|
180
180
|
"description": "A comprehensive workflow for AI-assisted coding",
|
|
181
181
|
"version": "0.1.0",
|
|
@@ -201,7 +201,7 @@ Retrieves workflow information with configurable detail level. Supports progress
|
|
|
201
201
|
"jsonrpc": "2.0",
|
|
202
202
|
"id": 2,
|
|
203
203
|
"result": {
|
|
204
|
-
"id": "coding-task-workflow",
|
|
204
|
+
"id": "coding-task-workflow-with-loops",
|
|
205
205
|
"name": "Excellent Adaptive Coding Workflow",
|
|
206
206
|
"description": "A comprehensive workflow for AI-assisted coding",
|
|
207
207
|
"version": "0.1.0",
|
|
@@ -1,160 +0,0 @@
|
|
|
1
|
-
{
|
|
2
|
-
"id": "coding-task-workflow",
|
|
3
|
-
"name": "Excellent Adaptive Coding Workflow with Devil's Advocate Review",
|
|
4
|
-
"version": "0.0.1",
|
|
5
|
-
"description": "A comprehensive and resilient workflow for AI-assisted coding. It adaptively sizes tasks, performs a critical self-review of its own plans, provides efficiency options, enforces closed-loop validation, and defines a robust protocol for handling failures.",
|
|
6
|
-
"preconditions": [
|
|
7
|
-
"User has a clear task description (e.g., from Jira, a dev doc, or a BRD).",
|
|
8
|
-
"The agent has access to necessary tools like `grep`, file readers/editors, and a terminal for commands.",
|
|
9
|
-
"The agent has access to the relevant codebase files."
|
|
10
|
-
],
|
|
11
|
-
"metaGuidance": [
|
|
12
|
-
"This workflow follows the PREP -> IMPLEMENT -> VERIFY pattern for each step in the plan.",
|
|
13
|
-
"Human approval is required after the Devil's Advocate review and before final completion.",
|
|
14
|
-
"Each implementation step should be a small, logical, and committable chunk of work.",
|
|
15
|
-
"The agent should never guess or assume. Always ask for clarification or use tools to find missing information.",
|
|
16
|
-
"Maintain existing coding conventions and architectural patterns found in the codebase."
|
|
17
|
-
],
|
|
18
|
-
"steps": [
|
|
19
|
-
{
|
|
20
|
-
"id": "phase-0-intelligent-triage",
|
|
21
|
-
"title": "Phase 0: Intelligent Task Triage & Complexity Analysis",
|
|
22
|
-
"prompt": "**ANALYZE**: Evaluate the provided task for complexity indicators:\n\n**Small Path Indicators:**\n- Single function changes or minor refactoring\n- Clear bug fixes with obvious solutions\n- Simple configuration changes\n- Low risk of side effects\n- Well-defined, narrow scope\n\n**Medium Path Indicators:**\n- Multi-file changes or moderate features\n- Standard development work\n- Some unknowns but manageable scope\n- Moderate complexity with clear boundaries\n- Requires planning but not architectural analysis\n\n**Large Path Indicators:**\n- Architectural changes or major features\n- Unfamiliar codebase areas\n- High complexity or significant risk\n- Multiple system interactions\n- Requires deep analysis and careful planning\n\n**IMPLEMENT**: \n1. Analyze the task description for the above indicators\n2. Recommend a complexity level (Small/Medium/Large) with detailed reasoning\n3. Set the taskComplexity context variable\n4. Ask user if they agree or want to override your classification\n5. For Medium tasks, ask: \"Would you like optional deep codebase analysis?\" (sets requestDeepAnalysis context variable)\n\n**VERIFY**: Confirm the complexity classification and any optional analysis preferences before proceeding.",
|
|
23
|
-
"guidance": [
|
|
24
|
-
"Be thorough in your analysis - this determines the entire workflow path",
|
|
25
|
-
"Consider both technical complexity and business risk",
|
|
26
|
-
"When in doubt, err on the side of more thorough analysis (higher complexity)",
|
|
27
|
-
"Always allow human override of your classification",
|
|
28
|
-
"Set context variables that will be used for conditional step execution"
|
|
29
|
-
],
|
|
30
|
-
"requireConfirmation": true
|
|
31
|
-
},
|
|
32
|
-
{
|
|
33
|
-
"id": "phase-1-scoping",
|
|
34
|
-
"runCondition": {
|
|
35
|
-
"var": "taskComplexity",
|
|
36
|
-
"not_equals": "Small"
|
|
37
|
-
},
|
|
38
|
-
"title": "Phase 1: Task Briefing & Scope Definition",
|
|
39
|
-
"prompt": "Your first goal is to understand the task. Analyze the following request, summarize your understanding, ask clarifying questions, and assess which parts of the codebase are relevant.\n\n**Task Description:**\n[User inserts detailed task description here]\n\n**Key Objectives & Success Criteria:**\n[User lists specific, measurable success criteria here]\n\n**Scope and Constraints:**\n[User defines boundaries or areas to avoid here]\n\nFinally, based on your analysis, perform a sanity check on the initial complexity sizing. If you believe the classification is incorrect, state your reasoning and ask for confirmation before proceeding. For example: 'You classified this as Medium, but my analysis shows it impacts several core architectural components. I recommend we upgrade to the Large path to perform a Deep Analysis. Do you agree?'",
|
|
40
|
-
"guidance": [
|
|
41
|
-
"Provide a complete task description. Vague requests will lead to poor plans and wasted effort.",
|
|
42
|
-
"This step is automatically skipped for Small tasks based on the complexity classification"
|
|
43
|
-
]
|
|
44
|
-
},
|
|
45
|
-
{
|
|
46
|
-
"id": "phase-1b-deep-analysis-mandatory",
|
|
47
|
-
"runCondition": {
|
|
48
|
-
"var": "taskComplexity",
|
|
49
|
-
"equals": "Large"
|
|
50
|
-
},
|
|
51
|
-
"title": "Phase 1b: Mandatory Deep Codebase Analysis",
|
|
52
|
-
"prompt": "Your goal is to become an expert on the attached codebase. This deep analysis is mandatory for Large tasks due to their complexity and risk. Your analysis must include:\n1. **Architecture:** Main modules, layers, and patterns.\n2. **Key Concepts:** Core models, conventions, and important components.\n3. **Execution Flow:** Trace major features or entry points.\n4. **Code Quality Assessment:** Note maintainability, readability, or coupling issues.\n5. **Testing Strategy:** Describe how the code is tested.\n6. **Opportunities:** Suggest refactorings or improvements.\n\nProvide summaries and code examples to illustrate your findings. Be exhaustive, as if preparing onboarding documentation for a senior engineer.",
|
|
53
|
-
"askForFiles": true,
|
|
54
|
-
"guidance": [
|
|
55
|
-
"This step is mandatory for Large tasks due to their complexity and risk",
|
|
56
|
-
"Ensure all relevant source files are attached or accessible to the agent before running this step",
|
|
57
|
-
"Be thorough - this analysis will inform the entire implementation strategy"
|
|
58
|
-
]
|
|
59
|
-
},
|
|
60
|
-
{
|
|
61
|
-
"id": "phase-1b-deep-analysis-optional",
|
|
62
|
-
"runCondition": {
|
|
63
|
-
"and": [
|
|
64
|
-
{
|
|
65
|
-
"var": "taskComplexity",
|
|
66
|
-
"equals": "Medium"
|
|
67
|
-
},
|
|
68
|
-
{
|
|
69
|
-
"var": "requestDeepAnalysis",
|
|
70
|
-
"equals": true
|
|
71
|
-
}
|
|
72
|
-
]
|
|
73
|
-
},
|
|
74
|
-
"title": "Phase 1b: Optional Deep Codebase Analysis",
|
|
75
|
-
"prompt": "You requested optional deep analysis for this Medium task. Your goal is to become an expert on the attached codebase. Your analysis must include:\n1. **Architecture:** Main modules, layers, and patterns.\n2. **Key Concepts:** Core models, conventions, and important components.\n3. **Execution Flow:** Trace major features or entry points.\n4. **Code Quality Assessment:** Note maintainability, readability, or coupling issues.\n5. **Testing Strategy:** Describe how the code is tested.\n6. **Opportunities:** Suggest refactorings or improvements.\n\nProvide summaries and code examples to illustrate your findings. Be exhaustive, as if preparing onboarding documentation for a senior engineer.",
|
|
76
|
-
"askForFiles": true,
|
|
77
|
-
"guidance": [
|
|
78
|
-
"This optional analysis was requested for a Medium task",
|
|
79
|
-
"Ensure all relevant source files are attached or accessible to the agent before running this step",
|
|
80
|
-
"Focus on areas most relevant to the current task"
|
|
81
|
-
]
|
|
82
|
-
},
|
|
83
|
-
{
|
|
84
|
-
"id": "phase-2-planning",
|
|
85
|
-
"runCondition": {
|
|
86
|
-
"var": "taskComplexity",
|
|
87
|
-
"not_equals": "Small"
|
|
88
|
-
},
|
|
89
|
-
"title": "Phase 2: Create Detailed Implementation Plan",
|
|
90
|
-
"prompt": "Your goal is to produce a thorough and actionable plan of attack. Do not write any code. Your plan must be detailed, broken into committable phases, and justified.\n\nYour plan must include these sections:\n1. **Goal Clarification:** Your understanding of the goal, assumptions, and success criteria.\n2. **Impact Assessment:** Affected codebase parts, dependencies, and risks.\n3. **Implementation Strategy:** A list of discrete, actionable steps. Each step must detail the task, its rationale, inputs, and outputs.\n4. **Final Review Checklist:** A specific checklist of items that must be verified to consider this entire task complete. This will be used in the final review phase.\n\nPresent this as a formal proposal.",
|
|
91
|
-
"guidance": [
|
|
92
|
-
"The agent will now proceed to critique its own plan in the next step. Withhold your final approval until after that critique.",
|
|
93
|
-
"This step is automatically skipped for Small tasks based on the complexity classification"
|
|
94
|
-
]
|
|
95
|
-
},
|
|
96
|
-
{
|
|
97
|
-
"id": "phase-2b-devil-advocate-review",
|
|
98
|
-
"runCondition": {
|
|
99
|
-
"var": "taskComplexity",
|
|
100
|
-
"not_equals": "Small"
|
|
101
|
-
},
|
|
102
|
-
"title": "Phase 2b: Devil's Advocate Plan Review",
|
|
103
|
-
"prompt": "Your new goal is to act as a skeptical but fair senior principal engineer. Your task is to perform a 'devil's advocate' review of the implementation plan you just created in Phase 2. The objective is not to discard the plan, but to rigorously stress-test it and make it stronger. Your critique must be balanced and evidence-based.\n\nAnalyze the plan through the following lenses. For every point you make (positive or negative), you must cite specific evidence from the plan, the codebase, or the initial task description.\n\n1. **Hidden Assumptions:** What assumptions does this plan make about the codebase, user behavior, or existing data that might be incorrect?\n2. **Potential Risks & Unintended Side Effects:** What is the biggest risk of this plan? Could it impact performance, security, or another feature in a negative way?\n3. **Overlooked Complexities or Edge Cases:** What specific edge cases (e.g., empty states, invalid inputs, race conditions) does the plan fail to explicitly address?\n4. **Alternative Approaches:** Briefly propose at least one alternative technical approach. What are the pros and cons of the alternative versus the current plan?\n5. **Plan Strengths:** To ensure a balanced review, explicitly state the strongest parts of the plan. What aspects are well-thought-out and likely to succeed?\n\nConclude with a balanced summary. If you found issues, provide concrete suggestions for how to amend the plan. Finally, give a confidence score (1-10) for the plan *if* your suggestions are implemented.",
|
|
104
|
-
"guidance": [
|
|
105
|
-
"This is a critical thinking step. The agent's goal is to find weaknesses in its *own* prior work to improve it. This is a sign of a high-functioning process.",
|
|
106
|
-
"Evaluate the agent's points. Not all 'risks' it identifies may be realistic. Use your judgment to decide which suggestions to incorporate into the plan.",
|
|
107
|
-
"After this review, you can ask the agent to create a final, amended version of the plan before you give your final approval to proceed with implementation.",
|
|
108
|
-
"This step is automatically skipped for Small tasks based on the complexity classification"
|
|
109
|
-
],
|
|
110
|
-
"requireConfirmation": true
|
|
111
|
-
},
|
|
112
|
-
{
|
|
113
|
-
"id": "phase-3-iterative-implementation",
|
|
114
|
-
"title": "Phase 3: Iterative Implementation (PREP -> IMPLEMENT -> VERIFY)",
|
|
115
|
-
"prompt": "The implementation phase has now begun. **Please provide me with the next single step from the approved plan.** If we are on the 'Small' path, provide a single, clear implementation instruction.\n\nI will execute *only* that step using the PREP -> IMPLEMENT -> VERIFY cycle defined in the guidance below, and then await your command for the subsequent step. This process will repeat until all steps are complete.",
|
|
116
|
-
"guidance": [
|
|
117
|
-
"**Efficiency Tip:** For high-confidence plans, you may provide multiple step instructions at once. I will execute them sequentially, performing the P->I->V cycle for each, and will only pause to ask for input if I encounter a verification failure or ambiguity.",
|
|
118
|
-
"**PREP:** Before implementing each step, you must first PREPARE. Re-read the step's description, confirm the previous step was completed correctly, verify the plan for this step is still valid in the current codebase, and list all required inputs or files. Do not proceed if anything is unclear.",
|
|
119
|
-
"**IMPLEMENT:** After preparation is confirmed, you will IMPLEMENT the step. Focus only on this single step. Use your tools to make the necessary code changes, adhering to all quality standards. Provide a commit message upon completion.",
|
|
120
|
-
"**VERIFY:** Immediately after implementation, you must VERIFY your work. Your verification for this step **is not complete until you have**:\n1. **Written necessary unit/integration tests** for the new logic.\n2. **Run the full test suite** to ensure no regressions were introduced.\n3. **Performed a critical self-review** of the changes against the plan, checking for code quality, side effects, and architectural alignment.\n\n**Failure Protocol:** If a verification failure cannot be resolved after two attempts, you must halt. Do not try a third time. Instead, present a summary of the problem, detail your failed attempts, and recommend a course of action to the user (e.g., 'revert this step and re-plan', 'request more information', 'proceed with a known issue')."
|
|
121
|
-
]
|
|
122
|
-
},
|
|
123
|
-
{
|
|
124
|
-
"id": "phase-4-final-review",
|
|
125
|
-
"title": "Phase 4: Final Review & Completion",
|
|
126
|
-
"prompt": "All planned steps have been implemented and verified. Your final goal is to perform a holistic review by validating the work against the **'Final Review Checklist'** created and approved during Phase 2.\n\nFor each item on that checklist, provide a confirmation and evidence that it has been met. Conclude with a summary of any potential follow-ups or new dependencies to note.",
|
|
127
|
-
"guidance": [
|
|
128
|
-
"This is the final quality check. Ensure the agent's summary and checklist validation align with your understanding of the completed work."
|
|
129
|
-
],
|
|
130
|
-
"requireConfirmation": true,
|
|
131
|
-
"validationCriteria": [
|
|
132
|
-
{
|
|
133
|
-
"type": "contains",
|
|
134
|
-
"value": "checklist",
|
|
135
|
-
"message": "Should reference the final review checklist"
|
|
136
|
-
},
|
|
137
|
-
{
|
|
138
|
-
"type": "contains",
|
|
139
|
-
"value": "complete",
|
|
140
|
-
"message": "Should confirm completion of all requirements"
|
|
141
|
-
},
|
|
142
|
-
{
|
|
143
|
-
"type": "length",
|
|
144
|
-
"min": 150,
|
|
145
|
-
"condition": {
|
|
146
|
-
"var": "taskComplexity",
|
|
147
|
-
"not_equals": "Small"
|
|
148
|
-
},
|
|
149
|
-
"message": "Complex tasks require detailed final review"
|
|
150
|
-
},
|
|
151
|
-
{
|
|
152
|
-
"type": "regex",
|
|
153
|
-
"pattern": "(?!.*TODO)",
|
|
154
|
-
"message": "Should not contain TODO items"
|
|
155
|
-
}
|
|
156
|
-
],
|
|
157
|
-
"hasValidation": true
|
|
158
|
-
}
|
|
159
|
-
]
|
|
160
|
-
}
|
|
@@ -1,352 +0,0 @@
|
|
|
1
|
-
{
|
|
2
|
-
"id": "coding-task-workflow",
|
|
3
|
-
"name": "[DEPRECATED] Excellent Adaptive Coding Workflow with Devil's Advocate Review",
|
|
4
|
-
"version": "0.8.0",
|
|
5
|
-
"description": "[DEPRECATED] This workflow has been superseded by 'coding-task-workflow-with-loops' which includes enhanced loop capabilities for better iterative development. Use 'coding-task-workflow-with-loops' for new projects. Comprehensive AI coding workflow with bidirectional re-triage, deep analysis, intelligent clarification, devil's advocate review, automation levels, failure bounds, tool fallbacks, and context documentation for production-ready development.",
|
|
6
|
-
|
|
7
|
-
"preconditions": [
|
|
8
|
-
"User has a clear task description (e.g., from Jira, a dev doc, or a BRD).",
|
|
9
|
-
"The agent has access to necessary tools like `grep`, file readers/editors, and a terminal for commands.",
|
|
10
|
-
"The agent has access to the relevant codebase files.",
|
|
11
|
-
"Git repository is recommended for version control and commits (workflow degrades gracefully if unavailable)."
|
|
12
|
-
],
|
|
13
|
-
"metaGuidance": [
|
|
14
|
-
"⚠️ DEPRECATION NOTICE: This workflow is deprecated. Use 'coding-task-workflow-with-loops' instead for enhanced iterative development capabilities with loop support.",
|
|
15
|
-
"This workflow follows the ANALYZE -> CLARIFY -> PREP -> IMPLEMENT -> VERIFY pattern with bidirectional dynamic re-triage capabilities.",
|
|
16
|
-
"Deep codebase analysis occurs early to inform intelligent requirements clarification and all subsequent planning phases.",
|
|
17
|
-
"Dynamic re-triage allows complexity upgrades and safe downgrades based on new insights from analysis and clarifications.",
|
|
18
|
-
"Automation levels (Low/Medium/High) control confirmation requirements to balance autonomy with safety.",
|
|
19
|
-
"Failure bounds prevent resource waste: word limits (2000), step tracking (>20), and escalation protocols.",
|
|
20
|
-
"Context documentation is maintained throughout to enable seamless handoffs between chat sessions, with updates triggered by progress milestones, failures, or user interventions.",
|
|
21
|
-
"For specialized tasks (e.g., debugging), call sub-workflows via workflow_get tool when available.",
|
|
22
|
-
"Limit all documentation outputs to 2000 words max; use bullet points for scannability.",
|
|
23
|
-
"Output markdown content in response; use read_file/edit_file tools to create/update actual files if available, else request user upload.",
|
|
24
|
-
"Align with custom instructions: Use --quiet flags for commands; output to files; prefer workflows for debugging.",
|
|
25
|
-
"Human approval is required after the Devil's Advocate review and before final completion.",
|
|
26
|
-
"Each implementation step should be a small, logical, and committable chunk of work.",
|
|
27
|
-
"The agent should never guess or assume. Always ask for clarification or use tools to find missing information.",
|
|
28
|
-
"If you fail to get test results or other tool outputs on the first attempt, ask the user to run it manually.",
|
|
29
|
-
"Document all user interventions, change requests, and feedback immediately in context documentation to ensure continuity.",
|
|
30
|
-
"**Git Fallback Strategy:** If git not initialized or tools fail, gracefully skip commits/branches, log changes manually in CONTEXT.md with timestamps, and warn user at phase-6 start. Document all file modifications for manual version control.",
|
|
31
|
-
"**Git Error Handling:** Use run_terminal_cmd for git operations; if fails, output exact command for user manual execution. Never halt workflow due to git unavailability.",
|
|
32
|
-
"Persist all variables across steps using conversation context, external state, or by including them in every response metadata; reset flags like proposedDowngrade after confirmation.",
|
|
33
|
-
"Use safe git practices: Create feature branches for isolation, commit on successful verification, generate clear commit messages, revert on failures. Log commit hashes in CONTEXT.md for traceability.",
|
|
34
|
-
"Maintain existing coding conventions and architectural patterns found in the codebase.",
|
|
35
|
-
"COMMIT STRATEGY: Auto-commit after successful steps for High automation; suggest for Medium/Low. Use conventional format: type(scope): description. Commit at milestones and after verification passes."
|
|
36
|
-
],
|
|
37
|
-
"steps": [
|
|
38
|
-
{
|
|
39
|
-
"id": "phase-0-intelligent-triage",
|
|
40
|
-
"title": "Phase 0: Intelligent Task Triage & Complexity Analysis",
|
|
41
|
-
"prompt": "**ANALYZE**: Evaluate the provided task for complexity indicators:\n\n**Small Path Indicators:**\n- Single function changes or minor refactoring\n- Clear bug fixes with obvious solutions\n- Simple configuration changes\n- Low risk of side effects\n- Well-defined, narrow scope\n\n**Medium Path Indicators:**\n- Multi-file changes or moderate features\n- Standard development work\n- Some unknowns but manageable scope\n- Moderate complexity with clear boundaries\n- Requires planning but not architectural analysis\n\n**Large Path Indicators:**\n- Architectural changes or major features\n- Unfamiliar codebase areas\n- High complexity or significant risk\n- Multiple system interactions\n- Requires deep analysis and careful planning\n\n**IMPLEMENT**: \n1. Analyze the task description for the above indicators\n2. Recommend a complexity level (Small/Medium/Large) with detailed reasoning\n3. Set the taskComplexity context variable\n4. Ask user if they agree or want to override your classification\n5. For Medium tasks, ask: \"Would you like optional deep codebase analysis?\" (sets requestDeepAnalysis context variable)\n6. Ask: \"What automation level would you prefer? High (auto-approve low-risk decisions), Medium (standard confirmations), or Low (extra confirmations for safety)?\" (sets automationLevel context variable)\n\n**VERIFY**: Confirm the complexity classification, optional analysis preferences, and automation level before proceeding.",
|
|
42
|
-
"agentRole": "You are a technical assessment specialist with expertise in evaluating software development complexity. Your role is to accurately classify tasks based on technical risk, scope, and architectural impact. Be thorough in your analysis while remaining decisive and clear in your recommendations.",
|
|
43
|
-
"guidance": [
|
|
44
|
-
"Be thorough in your analysis - this determines the entire workflow path",
|
|
45
|
-
"Consider both technical complexity and business risk",
|
|
46
|
-
"When in doubt, err on the side of more thorough analysis (higher complexity)",
|
|
47
|
-
"Always allow human override of your classification",
|
|
48
|
-
"Set context variables that will be used for conditional step execution and automation",
|
|
49
|
-
"Automation levels: High=auto-approve confidence >8, Medium=standard, Low=extra confirmations"
|
|
50
|
-
],
|
|
51
|
-
"requireConfirmation": true
|
|
52
|
-
},
|
|
53
|
-
{
|
|
54
|
-
"id": "phase-1-deep-analysis-mandatory",
|
|
55
|
-
"runCondition": {"var": "taskComplexity", "equals": "Large"},
|
|
56
|
-
"title": "Phase 1: Mandatory Deep Codebase Analysis",
|
|
57
|
-
"prompt": "Your goal is to become an expert on the attached codebase before any planning begins. This deep analysis is mandatory for Large tasks due to their complexity and risk.\n\n**ANALYSIS BOUNDS: Limit output to 1500 words; prioritize task-relevant sections.**\n\nYour analysis must include:\n1. **Architecture:** Main modules, layers, and patterns.\n2. **Key Concepts:** Core models, conventions, and important components.\n3. **Execution Flow:** Trace major features or entry points.\n4. **Code Quality Assessment:** Note maintainability, readability, or coupling issues.\n5. **Testing Strategy:** Describe how the code is tested.\n6. **Opportunities:** Suggest refactorings or improvements.\n7. **Task Relevance:** Identify which parts of the codebase are most relevant to the current task.\n8. **Potential Ambiguities:** Note areas where the initial task description might be unclear given the codebase structure.\n9. **Complexity Indicators:** Note any discoveries that might affect the initial complexity assessment.\n\nProvide summaries and code examples to illustrate your findings. Be exhaustive within the word limit, as if preparing onboarding documentation for a senior engineer. This analysis will inform all subsequent requirements clarification, specification, and design work.",
|
|
58
|
-
"agentRole": "You are an expert codebase analyst with 10+ years of experience in software architecture and legacy system analysis. Your specialty is quickly understanding complex codebases and identifying architectural patterns, risks, and opportunities. Approach this with the thoroughness of a senior engineer conducting a technical due diligence review.",
|
|
59
|
-
"askForFiles": true,
|
|
60
|
-
"guidance": [
|
|
61
|
-
"This step is mandatory for Large tasks due to their complexity and risk",
|
|
62
|
-
"Ensure all relevant source files are attached or accessible to the agent before running this step",
|
|
63
|
-
"Be thorough but respect the 1500-word limit - focus on task-relevant insights",
|
|
64
|
-
"This analysis will inform requirements clarification, specification, design, and implementation strategy",
|
|
65
|
-
"Pay special attention to areas of the codebase relevant to the current task",
|
|
66
|
-
"Note potential ambiguities in the task description that become apparent after understanding the codebase",
|
|
67
|
-
"Flag any complexity indicators that might warrant re-triaging the task complexity"
|
|
68
|
-
],
|
|
69
|
-
"requireConfirmation": false
|
|
70
|
-
},
|
|
71
|
-
{
|
|
72
|
-
"id": "phase-1-deep-analysis-optional",
|
|
73
|
-
"runCondition": {
|
|
74
|
-
"and": [
|
|
75
|
-
{"var": "taskComplexity", "equals": "Medium"},
|
|
76
|
-
{"var": "requestDeepAnalysis", "equals": true}
|
|
77
|
-
]
|
|
78
|
-
},
|
|
79
|
-
"title": "Phase 1: Optional Deep Codebase Analysis",
|
|
80
|
-
"prompt": "You requested optional deep analysis for this Medium task. Your goal is to become an expert on the attached codebase before planning begins.\n\n**ANALYSIS BOUNDS: Limit output to 1500 words; prioritize task-relevant sections.**\n\nYour analysis must include:\n1. **Architecture:** Main modules, layers, and patterns.\n2. **Key Concepts:** Core models, conventions, and important components.\n3. **Execution Flow:** Trace major features or entry points.\n4. **Code Quality Assessment:** Note maintainability, readability, or coupling issues.\n5. **Testing Strategy:** Describe how the code is tested.\n6. **Opportunities:** Suggest refactorings or improvements.\n7. **Task Relevance:** Identify which parts of the codebase are most relevant to the current task.\n8. **Potential Ambiguities:** Note areas where the initial task description might be unclear given the codebase structure.\n9. **Complexity Indicators:** Note any discoveries that might affect the initial complexity assessment.\n\nProvide summaries and code examples to illustrate your findings. Focus on areas most relevant to the current task while maintaining architectural awareness. This analysis will inform all subsequent requirements clarification, specification, and design work.",
|
|
81
|
-
"agentRole": "You are a focused codebase analyst specializing in targeted technical analysis for medium-complexity projects. Your approach balances thoroughness with efficiency, focusing on areas most relevant to the current task while maintaining architectural awareness.",
|
|
82
|
-
"askForFiles": true,
|
|
83
|
-
"guidance": [
|
|
84
|
-
"This optional analysis was requested for a Medium task",
|
|
85
|
-
"Ensure all relevant source files are attached or accessible to the agent before running this step",
|
|
86
|
-
"Focus on areas most relevant to the current task while maintaining broader architectural context",
|
|
87
|
-
"Respect the 1500-word limit - prioritize task-relevant insights",
|
|
88
|
-
"This analysis will inform requirements clarification, specification, and design phases",
|
|
89
|
-
"Note potential ambiguities in the task description that become apparent after understanding the codebase",
|
|
90
|
-
"Flag any complexity indicators that might warrant re-triaging the task complexity"
|
|
91
|
-
],
|
|
92
|
-
"requireConfirmation": false
|
|
93
|
-
},
|
|
94
|
-
{
|
|
95
|
-
"id": "phase-2-informed-clarification",
|
|
96
|
-
"runCondition": {"var": "taskComplexity", "not_equals": "Small"},
|
|
97
|
-
"title": "Phase 2: Informed Requirements Clarification",
|
|
98
|
-
"prompt": "Based on your deep understanding of the codebase from Phase 1, you are now in a position to ask intelligent, targeted questions to clarify the requirements. Your codebase analysis may have revealed ambiguities, missing details, or potential issues that weren't apparent from the initial task description.\n\n**Your goal is to ask specific, informed questions that will lead to a clear, unambiguous specification. Consider:**\n\n1. **Technical Ambiguities:** Are there aspects of the task that could be implemented in multiple ways given the existing architecture? Which approach is preferred?\n\n2. **Integration Questions:** How should the new functionality integrate with existing systems, APIs, or workflows you discovered?\n\n3. **Scope Boundaries:** Given the existing codebase structure, what should be included/excluded from this task?\n\n4. **Convention Alignment:** Should the implementation follow existing patterns you observed, or is this an opportunity to establish new patterns?\n\n5. **Edge Cases:** What should happen in edge cases that are now apparent given the existing data models and business logic?\n\n6. **Dependencies:** Are there existing components, services, or data that the task should leverage or avoid?\n\n7. **Testing Strategy:** Given the existing test patterns, what level and type of testing is expected?\n\n8. **Complexity Concerns:** Based on your analysis, are there risk factors that might indicate this task is more complex than initially classified?\n\n**Present 3-7 well-formulated questions that will significantly improve the clarity and implementability of the final specification.**",
|
|
99
|
-
"agentRole": "You are a senior business analyst and technical consultant specializing in requirements elicitation. Your expertise lies in translating deep technical understanding into precise business questions that eliminate ambiguity and prevent costly rework. You excel at identifying the critical gaps between initial requirements and implementation reality.",
|
|
100
|
-
"guidance": [
|
|
101
|
-
"This step is automatically skipped for Small tasks based on complexity classification",
|
|
102
|
-
"Ask questions that could only be formulated after understanding the codebase",
|
|
103
|
-
"Focus on questions that will significantly impact the specification and implementation approach",
|
|
104
|
-
"Avoid generic questions - make them specific to the codebase and task at hand",
|
|
105
|
-
"Present questions in a clear, prioritized manner",
|
|
106
|
-
"Include questions about potential complexity changes based on your analysis"
|
|
107
|
-
],
|
|
108
|
-
"requireConfirmation": {
|
|
109
|
-
"or": [
|
|
110
|
-
{"var": "automationLevel", "equals": "Low"},
|
|
111
|
-
{"var": "automationLevel", "equals": "Medium"}
|
|
112
|
-
]
|
|
113
|
-
}
|
|
114
|
-
},
|
|
115
|
-
{
|
|
116
|
-
"id": "phase-2b-dynamic-retriage",
|
|
117
|
-
"runCondition": {"var": "taskComplexity", "not_equals": "Small"},
|
|
118
|
-
"title": "Phase 2b: Dynamic Complexity Re-Triage",
|
|
119
|
-
"prompt": "Based on your codebase analysis and requirements clarification, re-evaluate the initial complexity classification. New insights may have revealed:\n\n- Hidden architectural dependencies\n- Unforeseen integration complexities\n- Risk factors not apparent in the initial description\n- Scope expansion based on clarified requirements\n- Technical constraints that increase difficulty\n- **OR existing utilities/patterns that simplify the task**\n\n**EVALUATE:**\n1. Review the original taskComplexity classification\n2. Consider new information from codebase analysis and clarifications\n3. Assess if the complexity should be upgraded (e.g., Medium → Large) OR downgraded (e.g., Large → Medium)\n4. Provide detailed reasoning for any recommended changes\n\n**If you recommend upgrading complexity:**\n- Clearly explain what new insights led to this recommendation\n- Describe the additional risks or complexity discovered\n- Justify why the higher complexity path would be beneficial\n- Ask for user confirmation to change the taskComplexity context variable\n\n**If you recommend downgrading complexity:**\n- Set proposedDowngrade context variable to true\n- Clearly explain what existing utilities, patterns, or simplified scope led to this recommendation\n- Provide evidence of reduced risk and scope\n- Require user confirmation and evidence of reduced risk unless automationLevel=High and confidence >8\n- Justify why the lower complexity path is safe and appropriate\n\n**If current classification remains appropriate:**\n- Briefly confirm the classification is still accurate\n- Proceed without requesting changes\n\n**Note:** Both upgrades and downgrades are allowed with proper justification to ensure optimal workflow efficiency.",
|
|
120
|
-
"agentRole": "You are a senior technical risk assessor specializing in project complexity evaluation. Your expertise lies in identifying hidden risks and complexity factors that emerge during analysis phases, as well as recognizing when tasks are simpler than initially assessed. You excel at making decisive recommendations to ensure projects follow the appropriate rigor level.",
|
|
121
|
-
"guidance": [
|
|
122
|
-
"This step allows both upgrading and downgrading complexity based on new insights",
|
|
123
|
-
"Only change complexity if there are clear, justifiable reasons",
|
|
124
|
-
"For downgrades, set proposedDowngrade flag and require explicit user approval unless automationLevel=High and confidence >8",
|
|
125
|
-
"Be specific about what new information led to the reassessment",
|
|
126
|
-
"If changing complexity, the workflow will continue with the new complexity path",
|
|
127
|
-
"Downgrades must be justified with evidence of reduced risk/scope",
|
|
128
|
-
"Reset proposedDowngrade to false after user confirmation or rejection"
|
|
129
|
-
],
|
|
130
|
-
"requireConfirmation": {
|
|
131
|
-
"or": [
|
|
132
|
-
{"var": "automationLevel", "equals": "Low"},
|
|
133
|
-
{"var": "automationLevel", "equals": "Medium"},
|
|
134
|
-
{"var": "proposedDowngrade", "equals": true}
|
|
135
|
-
]
|
|
136
|
-
}
|
|
137
|
-
},
|
|
138
|
-
{
|
|
139
|
-
"id": "phase-3-specification",
|
|
140
|
-
"runCondition": {"var": "taskComplexity", "not_equals": "Small"},
|
|
141
|
-
"title": "Phase 3: Create Specification",
|
|
142
|
-
"prompt": "Using your codebase analysis from Phase 1, the clarified requirements from Phase 2, and any complexity re-assessment from Phase 2b, create a specification document that aligns with the existing system and addresses all identified ambiguities. Your specification should be precise, unambiguous, and fully implementable.\n\n**Task Description:**\n[Updated based on clarifications from Phase 2]\n\n**Key Objectives & Success Criteria:**\n[Refined based on codebase understanding and clarifications]\n\n**Scope and Constraints:**\n[Updated to reflect codebase realities and clarified boundaries]\n\n**IMPORTANT**: Your specification must consider:\n- Existing architectural patterns and conventions identified in your codebase analysis\n- How the proposed changes fit within the current system design\n- Potential impacts on existing components and workflows\n- Alignment with current testing strategies and code quality standards\n- All clarifications and decisions made in Phase 2\n- Any complexity insights from the re-triage assessment\n\nOutput markdown content in response; use edit_file tool to create actual spec.md file if available, else request user upload.\n\nFinally, perform a sanity check on the current complexity classification. If you believe further adjustment is needed given your comprehensive understanding, state your reasoning and ask for confirmation before proceeding.",
|
|
143
|
-
"agentRole": "You are a senior business analyst and technical lead specializing in requirement gathering and scope definition. Your goal is to produce a clear, comprehensive `spec.md` file that leverages your deep understanding of the existing codebase and incorporates all clarified requirements to serve as an unambiguous foundation for design and implementation.",
|
|
144
|
-
"guidance": [
|
|
145
|
-
"Provide a complete task description based on all previous analysis and clarifications",
|
|
146
|
-
"The output of this step should be the content for `spec.md`",
|
|
147
|
-
"This step is automatically skipped for Small tasks based on the complexity classification",
|
|
148
|
-
"Leverage your codebase analysis and clarifications to ensure the specification is precise and implementable",
|
|
149
|
-
"Reference specific decisions made during the clarification phase",
|
|
150
|
-
"Consider any complexity changes from the re-triage phase"
|
|
151
|
-
],
|
|
152
|
-
"requireConfirmation": false
|
|
153
|
-
},
|
|
154
|
-
{
|
|
155
|
-
"id": "phase-3b-create-context-doc",
|
|
156
|
-
"runCondition": {"var": "taskComplexity", "not_equals": "Small"},
|
|
157
|
-
"title": "Phase 3b: Create Context Documentation",
|
|
158
|
-
"prompt": "Create a comprehensive context documentation file (`CONTEXT.md`) that captures all critical information from the workflow so far. This document is essential for enabling seamless handoffs between chat sessions when context limits are reached.\n\n**For automationLevel=High, generate a summary-only version (limit 1000 words); otherwise, full update (limit 2000 words).**\n\n**Your `CONTEXT.md` must include:**\n\n## 1. ORIGINAL TASK CONTEXT\n- Original task description and requirements\n- Complexity classification (Small/Medium/Large) and reasoning\n- Any re-triage decisions made and why\n- Automation level selected and its implications\n\n## 2. CODEBASE ANALYSIS SUMMARY\n- Key architectural patterns and conventions found\n- Relevant components, modules, and their locations\n- Testing strategies and patterns in use\n- Critical dependencies and integration points\n- Any complexity indicators discovered\n\n## 3. CLARIFICATIONS AND DECISIONS\n- Questions asked and answers received\n- Ambiguities resolved and how\n- Scope boundaries clearly defined\n- Technical approach decisions made\n\n## 4. SPECIFICATION SUMMARY\n- Core objectives and success criteria\n- Key constraints and requirements\n- Design principles to follow\n- Integration requirements\n\n## 5. WORKFLOW PROGRESS TRACKING\n- ✅ Completed phases (0, 1, 2, 2b, 3, 3b)\n- 🔄 Current phase: Architecture Design (Phase 4)\n- ⏳ Remaining phases: 4, 5, 5b, 5c, 5d, 5e, 6, 7\n- 📋 Context variables set (taskComplexity, automationLevel, etc.)\n\n## 6. HANDOFF INSTRUCTIONS\n- Files to attach when resuming (e.g., spec.md via tool or user upload)\n- Key context to provide to new chat session\n- Critical decisions that must not be forgotten\n\n**Format this as a clear, scannable document using bullet points that a new agent could quickly read to understand the full project context.**",
|
|
159
|
-
"agentRole": "You are a meticulous technical documentation specialist with expertise in creating comprehensive project handoff documents. Your role is to capture all critical context in a way that enables seamless continuity across different team members or chat sessions. You excel at synthesizing complex technical information into clear, actionable documentation.",
|
|
160
|
-
"guidance": [
|
|
161
|
-
"This step is automatically skipped for Small tasks",
|
|
162
|
-
"Create a document that would allow a completely new agent to pick up the work seamlessly",
|
|
163
|
-
"Include specific file paths, component names, and technical details discovered",
|
|
164
|
-
"Reference all key decisions made in previous phases",
|
|
165
|
-
"Make the progress tracking section very clear for workflow continuation",
|
|
166
|
-
"Consider this document as critical as the specification itself",
|
|
167
|
-
"Use bullet points for scannability; limit to word count based on automation level"
|
|
168
|
-
],
|
|
169
|
-
"requireConfirmation": false
|
|
170
|
-
},
|
|
171
|
-
{
|
|
172
|
-
"id": "phase-4-architectural-design",
|
|
173
|
-
"runCondition": {"var": "taskComplexity", "not_equals": "Small"},
|
|
174
|
-
"title": "Phase 4: Architectural Design",
|
|
175
|
-
"prompt": "Using the `spec.md` from the previous step, your deep codebase analysis, and all clarified requirements, create a high-level architectural design that seamlessly integrates with the existing system. Your output should be a `design.md` document that includes:\n1. **High-Level Approach:** A summary of the proposed solution that builds on existing patterns.\n2. **Component Breakdown:** Identify new or modified components, classes, or modules, showing how they fit within the current architecture.\n3. **Data Models:** Describe any changes to data structures or database schemas, considering existing data patterns.\n4. **API Contracts:** Define any new or changed API endpoints, following existing API conventions and patterns.\n5. **Key Interactions:** A diagram or description of how the major components will interact, both new and existing.\n6. **Integration Points:** Clearly identify how new components will integrate with existing systems and workflows.\n7. **Clarification Decisions:** Reference how the clarified requirements from Phase 2 influenced design decisions.\n8. **Complexity Considerations:** Address any complexity factors identified during re-triage.\n\nOutput markdown content in response; use edit_file tool to create actual design.md file if available, else request user upload.",
|
|
176
|
-
"agentRole": "You are a software architect specializing in translating business requirements into robust and scalable technical designs that seamlessly integrate with existing systems. Your task is to create a clear and comprehensive `design.md` that leverages existing architectural patterns while introducing necessary changes and incorporating all clarified requirements.",
|
|
177
|
-
"guidance": [
|
|
178
|
-
"The `design.md` should be detailed enough for an engineer to write an implementation plan from it.",
|
|
179
|
-
"This step is automatically skipped for Small tasks.",
|
|
180
|
-
"Ensure the design builds upon and aligns with the existing codebase architecture identified in your analysis",
|
|
181
|
-
"Reference specific clarification decisions that influenced the design",
|
|
182
|
-
"Consider complexity factors identified during re-triage"
|
|
183
|
-
],
|
|
184
|
-
"requireConfirmation": false
|
|
185
|
-
},
|
|
186
|
-
{
|
|
187
|
-
"id": "phase-small-prep",
|
|
188
|
-
"runCondition": {"var": "taskComplexity", "equals": "Small"},
|
|
189
|
-
"title": "Phase Small: Preparation and Simplified Execution",
|
|
190
|
-
"prompt": "For this Small task, perform quick preparation before implementation:\n\n**QUICK PREP:**\n1. **Verify Assumptions:** Use tools (e.g., list_dir, grep_search) to confirm:\n - Target files exist where expected\n - Functions/components mentioned are present\n - Dependencies are available\n\n2. **Complexity Check:** If you discover:\n - Unexpected dependencies or architectural complexity\n - Multiple integration points\n - Significant testing requirements\n **ESCALATE:** Recommend upgrading via re-triage (set proposedUpgrade=true) and pause for user confirmation.\n\n3. **Simple Plan:** Otherwise, create a brief plan with 2-5 discrete steps:\n - What will be changed\n - How it will be tested\n - Expected outcomes\n\n**ESCAPE HATCH:** If complexities arise during this prep, recommend upgrading to Medium/Large via phase-2b re-triage rather than proceeding with insufficient analysis.\n\n**Report your findings as a simple checklist:**\nChecklist example:\n- [✅] File `src/utils.js` exists (verified via list_dir)\n- [✅] Function `calculateTotal()` found (verified via grep_search)\n- [✅] Dependencies confirmed in package.json\n- [✅] Simple 3-step plan created\n\nProceed to implementation if all checks pass, otherwise recommend re-triage.",
|
|
191
|
-
"agentRole": "You are an efficient task executor specializing in low-complexity work. Your strength is quickly validating assumptions and creating lightweight plans while maintaining awareness of when tasks exceed their initial scope. You excel at recognizing when to escalate rather than proceeding with insufficient analysis.",
|
|
192
|
-
"guidance": [
|
|
193
|
-
"This is a mini-version of PREP->IMPLEMENT->VERIFY for Small tasks",
|
|
194
|
-
"Use available tools to verify basic assumptions quickly",
|
|
195
|
-
"Escape to phase-2b re-triage if complexities are discovered",
|
|
196
|
-
"Keep the plan simple but actionable",
|
|
197
|
-
"Better to escalate than to proceed with insufficient preparation"
|
|
198
|
-
],
|
|
199
|
-
"requireConfirmation": false
|
|
200
|
-
},
|
|
201
|
-
{
|
|
202
|
-
"id": "phase-5-planning",
|
|
203
|
-
"runCondition": {"var": "taskComplexity", "not_equals": "Small"},
|
|
204
|
-
"title": "Phase 5: Create Detailed Implementation Plan",
|
|
205
|
-
"prompt": "Your goal is to produce a thorough and actionable `implementation_plan.md` based on the `spec.md`, `design.md`, your deep codebase analysis, and all clarified requirements. Do not write any code. Your plan must be detailed, broken into committable phases, and justified.\n\nYour plan must include these sections:\n1. **Goal Clarification:** Your understanding of the goal, assumptions, and success criteria from the spec and clarifications.\n2. **Impact Assessment:** Affected codebase parts, dependencies, and risks based on the design, codebase analysis, and clarified requirements.\n3. **Implementation Strategy:** A list of discrete, actionable steps. Each step must detail the task, its rationale, inputs, and outputs.\n4. **Testing Strategy:** Describe how the changes will be tested, building on existing testing patterns identified in your codebase analysis. Mandate achieving >80% test coverage where applicable.\n5. **Failure Handling:** Define what to do if tests fail, tools don't work, or unexpected issues arise.\n6. **Final Review Checklist:** A specific checklist of items that must be verified to consider this entire task complete. This will be used in the final review phase.\n\nOutput markdown content in response; use edit_file tool to create actual implementation_plan.md file if available, else request user upload.\n\nPresent this as a formal proposal that demonstrates deep understanding of the requirements, clarifications, and the existing codebase.",
|
|
206
|
-
"agentRole": "You are an experienced technical architect and project planner with expertise in breaking down complex development tasks into manageable, logical phases. Your strength is creating detailed, actionable plans that minimize risk while maximizing development efficiency and code quality, all while working within existing system constraints and incorporating all clarified requirements.",
|
|
207
|
-
"guidance": [
|
|
208
|
-
"The agent will now proceed to critique its own plan in the next step. Withhold your final approval until after that critique.",
|
|
209
|
-
"This step is automatically skipped for Small tasks based on the complexity classification",
|
|
210
|
-
"Leverage your codebase analysis and clarified requirements to ensure the plan works within existing architectural constraints",
|
|
211
|
-
"Reference how clarified requirements influenced the planning decisions",
|
|
212
|
-
"Include explicit failure handling protocols and quantitative metrics where applicable"
|
|
213
|
-
],
|
|
214
|
-
"requireConfirmation": false
|
|
215
|
-
},
|
|
216
|
-
{
|
|
217
|
-
"id": "phase-5b-devil-advocate-review",
|
|
218
|
-
"runCondition": {"var": "taskComplexity", "not_equals": "Small"},
|
|
219
|
-
"title": "Phase 5b: Devil's Advocate Plan Review",
|
|
220
|
-
"prompt": "Your task is to perform a 'devil's advocate' review of the implementation plan you just created in Phase 5. The objective is not to discard the plan, but to rigorously stress-test it and make it stronger. Your critique must be balanced and evidence-based.\n\nAnalyze the plan through the following lenses. For every point you make (positive or negative), you must cite specific evidence from the plan, the codebase analysis, clarified requirements, or the initial task description.\n\n1. **Hidden Assumptions:** What assumptions does this plan make about the codebase, user behavior, or existing data that might be incorrect?\n2. **Potential Risks & Unintended Side Effects:** What is the biggest risk of this plan? Could it impact performance, security, or another feature in a negative way?\n3. **Overlooked Complexities or Edge Cases:** What specific edge cases (e.g., empty states, invalid inputs, race conditions) does the plan fail to explicitly address?\n4. **Alternative Approaches:** Briefly propose at least one alternative technical approach. What are the pros and cons of the alternative versus the current plan?\n5. **Plan Strengths:** To ensure a balanced review, explicitly state the strongest parts of the plan. What aspects are well-thought-out and likely to succeed?\n\nConclude with a balanced summary. If you found issues, provide concrete suggestions for how to amend the plan. Finally, **set the confidenceScore variable to your 1-10 rating** for the plan *if* your suggestions are implemented.",
|
|
221
|
-
"agentRole": "You are a skeptical but fair senior principal engineer with 15+ years of experience in critical system development. Your role is to identify potential failure points, hidden assumptions, and overlooked complexities in technical plans. You excel at constructive criticism that strengthens plans rather than destroys them. Approach this with the rigor of a senior engineer reviewing a mission-critical system design.",
|
|
222
|
-
"guidance": [
|
|
223
|
-
"This is a critical thinking step. The agent's goal is to find weaknesses in its *own* prior work to improve it. This is a sign of a high-functioning process.",
|
|
224
|
-
"Evaluate the agent's points. Not all 'risks' it identifies may be realistic. Use your judgment to decide which suggestions to incorporate into the plan.",
|
|
225
|
-
"After this review, you can ask the agent to create a final, amended version of the plan before you give your final approval to proceed with implementation.",
|
|
226
|
-
"This step is automatically skipped for Small tasks based on the complexity classification",
|
|
227
|
-
"CRITICAL: Set confidenceScore variable (1-10) in your response",
|
|
228
|
-
"For automationLevel=High with confidenceScore >8, auto-approve if no critical risks identified"
|
|
229
|
-
],
|
|
230
|
-
"requireConfirmation": {
|
|
231
|
-
"or": [
|
|
232
|
-
{"var": "automationLevel", "equals": "Low"},
|
|
233
|
-
{"var": "automationLevel", "equals": "Medium"},
|
|
234
|
-
{"and": [
|
|
235
|
-
{"var": "automationLevel", "equals": "High"},
|
|
236
|
-
{"var": "confidenceScore", "lt": 8}
|
|
237
|
-
]}
|
|
238
|
-
]
|
|
239
|
-
}
|
|
240
|
-
},
|
|
241
|
-
{
|
|
242
|
-
"id": "phase-5c-finalize-plan",
|
|
243
|
-
"runCondition": {"var": "taskComplexity", "not_equals": "Small"},
|
|
244
|
-
"title": "Phase 5c: Finalize Implementation Plan",
|
|
245
|
-
"prompt": "Review the initial `implementation_plan.md` from Phase 5 and the Devil's Advocate critique from Phase 5b. Your task is to create a final, consolidated implementation plan that incorporates the valid feedback from the review.\n\nYour output must be the final `implementation_plan.md`.\n\nAdditionally, explicitly list any suggestions from the review that you believe are valuable but out-of-scope for the current task. These should be formatted as potential tickets for future work.\n\nOutput updated markdown content in response; use edit_file tool to update actual implementation_plan.md file if available, else request user upload.",
|
|
246
|
-
"agentRole": "You are a pragmatic technical project manager. Your goal is to synthesize feedback, make decisive trade-offs, and produce a final, actionable plan that is ready for execution.",
|
|
247
|
-
"guidance": [
|
|
248
|
-
"This is the final plan that will be executed. Ensure it is clear, actionable, and reflects the best path forward.",
|
|
249
|
-
"The list of out-of-scope items helps capture valuable ideas without derailing the current task."
|
|
250
|
-
],
|
|
251
|
-
"requireConfirmation": {
|
|
252
|
-
"or": [
|
|
253
|
-
{"var": "automationLevel", "equals": "Low"},
|
|
254
|
-
{"var": "automationLevel", "equals": "Medium"}
|
|
255
|
-
]
|
|
256
|
-
}
|
|
257
|
-
},
|
|
258
|
-
{
|
|
259
|
-
"id": "phase-5d-plan-sanity-check",
|
|
260
|
-
"runCondition": { "var": "taskComplexity", "not_equals": "Small" },
|
|
261
|
-
"title": "Phase 5d: Plan Sanity Check",
|
|
262
|
-
"prompt": "Before starting implementation, perform a sanity check on the final `implementation_plan.md`. Your goal is to use your tools to quickly verify the plan's core assumptions against the current codebase. This is not a deep analysis, but a quick check for obvious errors.\n\nFor the key files, functions, classes, or APIs mentioned in the plan, perform the following checks:\n1. **Existence Check:** Use tools like `grep_search` or `list_dir` to confirm that the files and primary functions/classes you plan to modify actually exist where you expect them to.\n2. **Signature/API Check (if applicable):** Briefly check the function signatures or API endpoints you intend to use. Do they match the plan's assumptions? For example, if the plan assumes a function takes two arguments, verify that.\n3. **Dependency Check:** If the plan relies on a specific library or module being available, quickly verify its presence (e.g., check `package.json`, `requirements.txt`, etc.).\n\n**If tools are unavailable, note fallback and proceed with manual verification request.**\n\n**Report your findings as a simple checklist:**\nChecklist example:\n- [✅] File `src/example.js` exists (verified via list_dir)\n- [✅] Function `calculateTotal()` found in `src/utils.js` (verified via grep_search)\n- [✅] Dependency `moment` is listed in `package.json`\n\nIf any check fails (❌), briefly explain the discrepancy and ask the user if the plan needs to be revised before proceeding.",
|
|
263
|
-
"agentRole": "You are a pragmatic QA engineer double-checking a plan before the development team starts work. Your job is to be quick, efficient, and focused on verifying concrete facts using tools. You are not re-evaluating the plan's logic, only its tangible connection to the codebase.",
|
|
264
|
-
"guidance": [
|
|
265
|
-
"This is a quick verification step, not a full re-analysis. The goal is to catch glaring errors before implementation begins.",
|
|
266
|
-
"Use your code-browsing tools (grep_search, list_dir) to validate the plan's assumptions.",
|
|
267
|
-
"If tools fail, fall back to alternatives like file_search or request manual verification",
|
|
268
|
-
"If a check fails, it's crucial to pause and get human confirmation before proceeding with a potentially flawed plan."
|
|
269
|
-
],
|
|
270
|
-
"requireConfirmation": false
|
|
271
|
-
},
|
|
272
|
-
{
|
|
273
|
-
"id": "phase-5e-update-context-doc",
|
|
274
|
-
"runCondition": {"var": "taskComplexity", "not_equals": "Small"},
|
|
275
|
-
"title": "Phase 5e: Update Context Documentation with Final Plans",
|
|
276
|
-
"prompt": "Update the `CONTEXT.md` file with all the planning work completed in Phases 4-5. This ensures the context document remains current and comprehensive for potential handoffs.\n\n**For automationLevel=High, generate a summary-only version (limit 500 words); otherwise, full update.**\n\n**Add/Update these sections in `CONTEXT.md`:**\n\n## 4. ARCHITECTURAL DESIGN SUMMARY\n- High-level approach and rationale\n- Key components being added/modified\n- Integration points with existing systems\n- Design decisions and alternatives considered\n\n## 5. IMPLEMENTATION PLAN OVERVIEW\n- Goal clarification and success criteria\n- Implementation strategy overview\n- Key risks identified and mitigation strategies\n- Testing approach and patterns to follow\n- Failure handling protocols\n\n## 6. DEVILS ADVOCATE REVIEW INSIGHTS\n- Key concerns raised and how they were addressed\n- Plan improvements made based on the review\n- Confidence score and reasoning\n- Out-of-scope items identified for future work\n\n## 7. UPDATED WORKFLOW PROGRESS\n- ✅ Completed phases (0, 1, 2, 2b, 3, 3b, 4, 5, 5b, 5c, 5d, 5e)\n- 🔄 Current phase: Implementation (Phase 6)\n- ⏳ Remaining phases: 6, 7\n- 📁 Key files created: spec.md, design.md, implementation_plan.md, CONTEXT.md\n\n## 8. IMPLEMENTATION READINESS\n- Plan sanity check results\n- Files and dependencies verified\n- Ready-to-execute implementation steps\n- Potential handoff points during implementation\n\n**Use bullet points for scannability and maintain all previous sections while adding the new planning context.**",
|
|
277
|
-
"agentRole": "You are a meticulous technical documentation specialist focused on maintaining comprehensive project context. Your expertise lies in synthesizing complex planning work into clear, actionable documentation that enables seamless workflow continuation.",
|
|
278
|
-
"guidance": [
|
|
279
|
-
"This step is automatically skipped for Small tasks",
|
|
280
|
-
"Maintain the scannable structure while adding substantial new planning context",
|
|
281
|
-
"Ensure all critical planning decisions are captured for potential handoffs",
|
|
282
|
-
"Update progress tracking to reflect the current state accurately",
|
|
283
|
-
"Consider this update as crucial as the original context document creation",
|
|
284
|
-
"Limit output based on automation level; use bullet points for readability",
|
|
285
|
-
"After updating CONTEXT.md, commit the planning completion: 'docs(planning): finalize implementation plan and context' (auto-commit for High automation, suggest for Medium/Low)"
|
|
286
|
-
],
|
|
287
|
-
"requireConfirmation": false
|
|
288
|
-
},
|
|
289
|
-
{
|
|
290
|
-
"id": "phase-6-iterative-implementation",
|
|
291
|
-
"title": "Phase 6: Iterative Implementation (PREP -> IMPLEMENT -> VERIFY)",
|
|
292
|
-
"prompt": "The implementation phase has now begun. You will now execute the approved `implementation_plan.md` step-by-step. Announce which step you are starting.\n\n**BRANCH SETUP:** Check git availability first with 'git status'. If git available, create a feature branch for isolation: Use a tool to run 'git checkout -b wip-[unique-task-id]' (generate a unique ID, e.g., from timestamp or task description) and track the featureBranch variable for later use. **If git not initialized or fails:** Skip branching/commits, log changes manually in CONTEXT.md with timestamps, warn user of no-git mode, and proceed with file-based tracking. Output exact git commands for user manual execution if needed.\n\n**STEP TRACKING:** Track total steps executed. If >20 steps without completion, pause and summarize progress for user intervention.\n\n**CONTEXT DOCUMENTATION:** Update `CONTEXT.md` after every 3 implementation steps, on failures, or when user requests changes/improvements with:\n- Progress summary (steps completed vs total)\n- Current implementation status\n- Issues encountered and resolutions\n- Files modified so far\n- Remaining work overview\n- Any changes to the original plan\n- Commit hashes from successful phases\n\nYou will execute each step using the PREP -> IMPLEMENT -> VERIFY cycle defined in the guidance below. This process will repeat until all steps in the plan are complete.",
|
|
293
|
-
"agentRole": "You are a meticulous senior software engineer focused on high-quality implementation. Your approach emphasizes careful preparation, precise execution, and thorough verification. You excel at following plans while adapting to unexpected discoveries during implementation, and you maintain excellent documentation for project continuity.",
|
|
294
|
-
"guidance": [
|
|
295
|
-
"**IMPORTANT**: Do not proceed to the next workflow phase (Final Review) until all steps in the `implementation_plan.md` are marked as complete and verified.",
|
|
296
|
-
"**STEP BOUNDS**: Track total steps executed. If >20 steps without completion, pause and ask user for guidance.",
|
|
297
|
-
"**CONTEXT UPDATES**: Update CONTEXT.md after every 3 steps, on failures, or when user requests changes",
|
|
298
|
-
"**Efficiency Tip:** For high-confidence plans, you may provide multiple step instructions at once. I will execute them sequentially, performing the P->I->V cycle for each, and will only pause to ask for input if I encounter a verification failure or ambiguity.",
|
|
299
|
-
"**PREP:** Before implementing each step, you must first PREPARE. Re-read the step's description, confirm the previous step was completed correctly, verify the plan for this step is still valid in the current codebase, and list all required inputs or files. Do not proceed if anything is unclear.",
|
|
300
|
-
"**IMPLEMENT:** After preparation is confirmed, you will IMPLEMENT the step. Focus only on this single step. Use your tools to make the necessary code changes, adhering to all quality standards.",
|
|
301
|
-
"**VERIFY:** Immediately after implementation, you must VERIFY your work. Your verification for this step **is not complete until you have**:\n1. **Written necessary unit/integration tests** for the new logic (as per the testing strategy). Report metrics: Achieve >80% test coverage (use tools to measure); 0 regressions expected.\n2. **Run the full test suite** to ensure no regressions were introduced. Use --quiet flags and output to files per custom instructions.\n3. **Performed a critical self-review** of the changes against the plan, checking for code quality, side effects, and architectural alignment.\n\n**COMMIT:** After successful verification, commit your changes (if git available):\n- **For automationLevel=High:** Automatically commit with descriptive message using conventional commit format (e.g., 'feat(auth): add user login validation', 'fix(api): handle null response in getUserData', 'refactor(utils): extract common validation logic')\n- **For automationLevel=Medium/Low:** Suggest commit with message and ask for user confirmation\n- **If git unavailable:** Log changes in CONTEXT.md with timestamp, file list, and change summary for manual version control\n- **Commit Message Guidelines:** Use format 'type(scope): description' where type is feat/fix/refactor/test/docs, scope is the affected component/module, description is concise and imperative mood\n- **Always commit after:** Each completed implementation step (if verification passes), major milestones, before context updates, when user requests changes\n- **Never commit:** Broken code, failing tests, or unverified changes\n\n**ENHANCED FAILURE PROTOCOL:** If a verification failure cannot be resolved after two attempts:\n1. **Do not try a third time**\n2. **For tool failures (e.g., grep):** Fall back to alternatives like `file_search` or `web_search`\n3. **If test failures occur:** Output command for user (e.g., './gradlew test --quiet --warning-mode=none --info > test_output.txt') and request manual execution per custom instructions\n4. **For critical failures:** Revert changes on the branch (e.g., 'git reset --hard HEAD'). For irrecoverable failures, delete branch to clean up: 'git checkout main && git branch -D [featureBranch]'\n5. **Update CONTEXT.md** with the failure details and current status\n6. **Present a summary** of the problem, detail your failed attempts, and recommend a course of action to the user (e.g., 'revert this step and re-plan', 'request more information', 'proceed with known issue')\n\n**USER INTERVENTION PROTOCOL:** When user requests changes, improvements, or provides feedback:\n1. **Immediately update CONTEXT.md** with the user's request and reasoning\n2. **Document the current state** before making any changes\n3. **Record the modification** made and its impact on the overall plan\n4. **Update progress tracking** to reflect any plan adjustments or scope changes"
|
|
302
|
-
],
|
|
303
|
-
"requireConfirmation": false
|
|
304
|
-
},
|
|
305
|
-
{
|
|
306
|
-
"id": "phase-6b-refinement-check",
|
|
307
|
-
"title": "Phase 6b: Agile Refinement Check",
|
|
308
|
-
"prompt": "After completing a chunk of implementation, evaluate if refinements are needed based on new insights. Set 'needsRefinement' context variable to true if updates to spec, design, or plan are required. If true, proceed to refinement steps; else, continue implementation or move to final review.",
|
|
309
|
-
"agentRole": "Agile refinement checker",
|
|
310
|
-
"runCondition": {"var": "implementationInProgress", "equals": true},
|
|
311
|
-
"requireConfirmation": true
|
|
312
|
-
},
|
|
313
|
-
{
|
|
314
|
-
"id": "phase-6c-update-spec",
|
|
315
|
-
"title": "Phase 6c: Update Specification",
|
|
316
|
-
"prompt": "Based on implementation insights, update spec.md with necessary changes. Justify updates and get user confirmation.",
|
|
317
|
-
"agentRole": "Specification updater",
|
|
318
|
-
"runCondition": {"var": "needsRefinement", "equals": true},
|
|
319
|
-
"requireConfirmation": true
|
|
320
|
-
},
|
|
321
|
-
{
|
|
322
|
-
"id": "phase-6d-update-design",
|
|
323
|
-
"title": "Phase 6d: Update Design",
|
|
324
|
-
"prompt": "Update design.md based on new insights. Maintain alignment with codebase.",
|
|
325
|
-
"agentRole": "Design updater",
|
|
326
|
-
"runCondition": {"var": "needsRefinement", "equals": true},
|
|
327
|
-
"requireConfirmation": true
|
|
328
|
-
},
|
|
329
|
-
{
|
|
330
|
-
"id": "phase-6e-update-plan",
|
|
331
|
-
"title": "Phase 6e: Update Implementation Plan",
|
|
332
|
-
"prompt": "Revise implementation_plan.md incorporating refinements. Reset 'needsRefinement' to false after updates.",
|
|
333
|
-
"agentRole": "Plan updater",
|
|
334
|
-
"runCondition": {"var": "needsRefinement", "equals": true},
|
|
335
|
-
"requireConfirmation": true
|
|
336
|
-
},
|
|
337
|
-
{
|
|
338
|
-
"id": "phase-7-final-review",
|
|
339
|
-
"title": "Phase 7: Final Review & Completion",
|
|
340
|
-
"prompt": "All planned steps have been implemented and verified. Your final goal is to perform a holistic review by validating the work against the **'Final Review Checklist'** from the `implementation_plan.md`.\n\nFor each item on that checklist, provide a confirmation and evidence that it has been met. Validate metrics against checklist (e.g., coverage percentage, test results).\n\n**After validation, create a final commit:**\n- Use conventional commit format: 'feat|fix|refactor(scope): final implementation - <brief summary>'\n- Include metrics in commit body (e.g., 'test coverage: 85%, all tests passing')\n- For automationLevel=High: auto-commit; Medium/Low: suggest and confirm\n\n**BRANCH CLEANUP:** Complete feature branch lifecycle (if git available):\n1. **Merge:** Propose 'git checkout main && git merge --squash [featureBranch] && git commit -m \"chore(merge): [task summary] with [metrics]\"'\n2. **Delete:** After merge: 'git branch -d [featureBranch]'\n3. **Automation:** High with confidenceScore >8 auto-executes; otherwise confirm\n4. **Conflicts:** Pause for user resolution if conflicts occur\n5. **No git:** Document final state in CONTEXT.md with file modification summary\n6. **Log merge hash** in CONTEXT.md (or timestamp if no git)\n\n**Additionally, create a comprehensive handoff document by updating `CONTEXT.md` with a final section:**\n\n## 9. FINAL COMPLETION STATUS\n- ✅ Implementation steps completed\n- ✅ Tests passing (metrics: coverage %, test count)\n- ✅ Review checklist validated\n- 📁 Files created/modified (with descriptions)\n- 🧪 Testing completed\n- 📋 Known issues/limitations\n- 🔄 Deployment/next steps\n- 📜 Git history: commits and merge hash\n\n## 10. HANDOFF SUMMARY\n- Accomplishments vs requirements\n- Key architectural decisions\n- Implementation details for maintainers\n- Recommended follow-up work\n- Contact points/documentation\n\nConclude with a summary of any potential follow-ups or new dependencies to note.",
|
|
341
|
-
"agentRole": "You are a quality assurance specialist and technical lead responsible for final project validation and comprehensive handoff documentation. Your expertise lies in comprehensive system testing, requirement verification, and ensuring deliverables meet all specified criteria while creating documentation that enables seamless future maintenance.",
|
|
342
|
-
"guidance": [
|
|
343
|
-
"This is the final quality check. Ensure the agent's summary and checklist validation align with your understanding of the completed work.",
|
|
344
|
-
"The final CONTEXT.md update should serve as a complete project archive",
|
|
345
|
-
"Include specific details that would help future developers understand and maintain the work",
|
|
346
|
-
"Ensure all promised deliverables have been completed and documented",
|
|
347
|
-
"Include quantitative metrics and validation results in the final status"
|
|
348
|
-
],
|
|
349
|
-
"requireConfirmation": true
|
|
350
|
-
}
|
|
351
|
-
]
|
|
352
|
-
}
|