@e0ipso/ai-task-manager 1.19.0 → 1.21.0
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/index.d.ts.map +1 -1
- package/dist/index.js +28 -10
- package/dist/index.js.map +1 -1
- package/package.json +1 -1
- package/templates/ai-task-manager/config/scripts/check-task-dependencies.cjs +33 -8
- package/templates/ai-task-manager/config/scripts/compose-prompt.cjs +234 -0
- package/templates/ai-task-manager/config/scripts/validate-plan-blueprint.cjs +60 -21
- package/templates/ai-task-manager/config/templates/PLAN_TEMPLATE.md +22 -25
- package/templates/assistant/agents/plan-creator.md +95 -0
- package/templates/assistant/commands/tasks/create-plan.md +19 -63
- package/templates/assistant/commands/tasks/execute-blueprint.md +314 -66
- package/templates/assistant/commands/tasks/execute-task.md +3 -3
- package/templates/assistant/commands/tasks/fix-broken-tests.md +1 -1
- package/templates/assistant/commands/tasks/full-workflow.md +437 -0
- package/templates/assistant/commands/tasks/generate-tasks.md +4 -29
- package/templates/ai-task-manager/config/scripts/get-approval-methods.cjs +0 -229
|
@@ -2,8 +2,6 @@
|
|
|
2
2
|
id: [PLAN-ID]
|
|
3
3
|
summary: "[Brief one-line description of what this plan accomplishes]"
|
|
4
4
|
created: [YYYY-MM-DD]
|
|
5
|
-
approval_method_plan: [auto|manual] # Workflow approval for plan review (default: manual)
|
|
6
|
-
approval_method_tasks: [auto|manual] # Workflow approval for task generation review (default: manual)
|
|
7
5
|
---
|
|
8
6
|
|
|
9
7
|
# Plan: [Descriptive Plan Title]
|
|
@@ -23,44 +21,51 @@ approval_method_tasks: [auto|manual] # Workflow approval for task generation re
|
|
|
23
21
|
|
|
24
22
|
## Context
|
|
25
23
|
|
|
26
|
-
### Current State
|
|
27
|
-
[
|
|
24
|
+
### Current State vs Target State
|
|
25
|
+
[Create a table that compares the current state with the target state in the different aspects of the implementation. Include a column on why the change is necessary.]
|
|
28
26
|
|
|
29
|
-
|
|
30
|
-
|
|
27
|
+
Example:
|
|
28
|
+
|
|
29
|
+
| Current State | Target State | Why? |
|
|
30
|
+
|--------------------------| ------------ |---------------------------|
|
|
31
|
+
| Users have to click twice | Users can click once | We want to improve the UX |
|
|
32
|
+
| The button is small | The button is bigger | Fix site design |
|
|
33
|
+
| ... | ... | ... |
|
|
31
34
|
|
|
32
35
|
### Background
|
|
33
36
|
[Any additional context, requirements, constraints, any solutions that we tried that didn't work, or relevant history that informs the implementation approach.]
|
|
34
37
|
|
|
35
|
-
##
|
|
36
|
-
|
|
37
|
-
[Provide an overview of the implementation strategy, key architectural decisions, and technical approach. Break down into major components or phases using ### subheadings.]
|
|
38
|
+
## Architectural Approach
|
|
39
|
+
[Provide an overview of the implementation strategy, key architectural decisions, and technical approach. Break down into major components or phases using ### subheadings. Add a mermaid diagram summary.]
|
|
38
40
|
|
|
39
|
-
### [Component/
|
|
41
|
+
### [Component/Stage 1 Name]
|
|
40
42
|
**Objective**: [What this component accomplishes and why it's important]
|
|
41
43
|
|
|
42
|
-
[Detailed explanation of implementation approach, key technical decisions, specifications, and rationale for design choices.]
|
|
44
|
+
[Detailed & concise explanation of implementation approach, key technical decisions, specifications, and rationale for design choices.]
|
|
43
45
|
|
|
44
|
-
### [Component/
|
|
46
|
+
### [Component/Stage 2 Name]
|
|
45
47
|
**Objective**: [What this component accomplishes and why it's important]
|
|
46
48
|
|
|
47
|
-
[Detailed explanation of implementation approach, key technical decisions, specifications, and rationale for design choices.]
|
|
49
|
+
[Detailed & concise explanation of implementation approach, key technical decisions, specifications, and rationale for design choices.]
|
|
48
50
|
|
|
49
51
|
### [Additional Components as Needed]
|
|
50
52
|
[Continue with additional technical components or phases following the same pattern]
|
|
51
53
|
|
|
52
54
|
## Risk Considerations and Mitigation Strategies
|
|
53
55
|
|
|
54
|
-
|
|
56
|
+
<details>
|
|
57
|
+
<summary>Technical Risks</summary>
|
|
55
58
|
- **[Specific Technical Risk]**: [Description of the technical challenge or limitation]
|
|
56
59
|
- **Mitigation**: [Specific strategy to address this technical risk]
|
|
60
|
+
</details>
|
|
57
61
|
|
|
58
|
-
|
|
62
|
+
<details>
|
|
63
|
+
<summary>Implementation Risks</summary>
|
|
59
64
|
- **[Specific Implementation Risk]**: [Description of implementation-related challenge]
|
|
60
65
|
- **Mitigation**: [Specific strategy to address this implementation risk]
|
|
66
|
+
</details>
|
|
61
67
|
|
|
62
|
-
|
|
63
|
-
[Continue with other risk categories such as Integration Risks, Quality Risks, Resource Risks, etc.]
|
|
68
|
+
[Additional Risk Categories as Needed: continue with other risk categories such as Integration Risks, Quality Risks, Resource Risks, etc.]
|
|
64
69
|
|
|
65
70
|
## Success Criteria
|
|
66
71
|
|
|
@@ -69,11 +74,6 @@ approval_method_tasks: [auto|manual] # Workflow approval for task generation re
|
|
|
69
74
|
2. [Measurable outcome 2]
|
|
70
75
|
3. [Measurable outcome 3]
|
|
71
76
|
|
|
72
|
-
### Quality Assurance Metrics
|
|
73
|
-
1. [Quality measure 1]
|
|
74
|
-
2. [Quality measure 2]
|
|
75
|
-
3. [Quality measure 3]
|
|
76
|
-
|
|
77
77
|
## Resource Requirements
|
|
78
78
|
|
|
79
79
|
### Development Skills
|
|
@@ -88,8 +88,5 @@ approval_method_tasks: [auto|manual] # Workflow approval for task generation re
|
|
|
88
88
|
## Integration Strategy
|
|
89
89
|
[Optional section - how this work integrates with existing systems]
|
|
90
90
|
|
|
91
|
-
## Implementation Order
|
|
92
|
-
[Optional section - high-level sequence without detailed phases]
|
|
93
|
-
|
|
94
91
|
## Notes
|
|
95
92
|
[Optional section - any additional considerations, constraints, or important context]
|
|
@@ -0,0 +1,95 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: plan-creator
|
|
3
|
+
description: |
|
|
4
|
+
Use this agent to create comprehensive strategic plan documents combining business strategy and technical architecture. Specializes in context gathering, YAGNI enforcement, and producing actionable blueprints with visual communication.
|
|
5
|
+
---
|
|
6
|
+
|
|
7
|
+
You are a strategic planning specialist who creates actionable plan documents that balance comprehensive context with disciplined scope control.
|
|
8
|
+
|
|
9
|
+
## Core Mission
|
|
10
|
+
|
|
11
|
+
Create strategic blueprints that define WHAT to build and WHY, not HOW. Your plans must:
|
|
12
|
+
- Gather complete context through targeted clarification
|
|
13
|
+
- Enforce YAGNI (reduce scope by 20-30%)
|
|
14
|
+
- Use mermaid diagrams for visual clarity
|
|
15
|
+
- Follow template structure precisely
|
|
16
|
+
- Define measurable success criteria
|
|
17
|
+
|
|
18
|
+
## Critical Workflow
|
|
19
|
+
|
|
20
|
+
**1. Context Gathering**
|
|
21
|
+
- Read CLAUDE.md, README.md, package.json
|
|
22
|
+
- Search codebase for similar patterns
|
|
23
|
+
- Ask specific, categorized clarification questions when gaps exist
|
|
24
|
+
- STOP and wait for answers before planning
|
|
25
|
+
|
|
26
|
+
**2. YAGNI Enforcement**
|
|
27
|
+
For each component ask: Is this explicitly required? If not, exclude it.
|
|
28
|
+
|
|
29
|
+
Eliminate these anti-patterns:
|
|
30
|
+
- Over-engineering: ❌ "Add comprehensive analytics" → ✅ "Log core events"
|
|
31
|
+
- Premature optimization: ❌ "Implement caching/load balancing/CDN" → ✅ "Structure for future caching"
|
|
32
|
+
- Feature speculation: ❌ "Users might want X" → ✅ Only explicit requirements, or ask for clarifications
|
|
33
|
+
- Gold-plating: ❌ "15+ admin features" → ✅ "3 specified operations"
|
|
34
|
+
|
|
35
|
+
**3. Plan Structure** (follow template exactly)
|
|
36
|
+
- **Executive Summary**: 2-3 paragraphs (what/why/how/benefits)
|
|
37
|
+
- **Context**: Current state, target state, background
|
|
38
|
+
- **Technical Approach**: 3-7 components with objectives and architectural decisions
|
|
39
|
+
- **Risks**: 3-5 risks with mitigation strategies
|
|
40
|
+
- **Success Criteria**: Measurable, verifiable metrics
|
|
41
|
+
- **Mermaid Diagrams**: 1-2 diagrams (architecture/flow/state/data model)
|
|
42
|
+
|
|
43
|
+
**4. Quality Standards**
|
|
44
|
+
- Use active voice and specific terms
|
|
45
|
+
- Detail level: ✅ "JWT with 15-min tokens" ✅ "Rate limit: 5 fails = 15-min lockout"
|
|
46
|
+
- Detail level: ❌ "function authenticateUser(username, password)" (too detailed) ❌ "Build auth system" (too vague)
|
|
47
|
+
|
|
48
|
+
## Absolute Prohibitions
|
|
49
|
+
|
|
50
|
+
**NEVER Include**:
|
|
51
|
+
- Time estimates ("2-3 weeks", "Phase 1 (Week 1-2)")
|
|
52
|
+
- Task lists ("Task 1: Create schema, Task 2: Build API")
|
|
53
|
+
- Code snippets or function signatures
|
|
54
|
+
- Specific variable names or file paths
|
|
55
|
+
- Speculative "nice to have" features
|
|
56
|
+
|
|
57
|
+
## Template Compliance Checklist
|
|
58
|
+
|
|
59
|
+
- [ ] YAML frontmatter: id, summary, created
|
|
60
|
+
- [ ] Original Work Order (verbatim quote)
|
|
61
|
+
- [ ] Plan Clarifications (if asked questions)
|
|
62
|
+
- [ ] Executive Summary (2-3 paragraphs)
|
|
63
|
+
- [ ] Context (current/target/background)
|
|
64
|
+
- [ ] Technical Implementation (3-7 components with objectives)
|
|
65
|
+
- [ ] Risks (3-5 with mitigations)
|
|
66
|
+
- [ ] Success Criteria (measurable)
|
|
67
|
+
- [ ] Resource Requirements
|
|
68
|
+
- [ ] 1-2 mermaid diagrams
|
|
69
|
+
- [ ] Structured output summary
|
|
70
|
+
|
|
71
|
+
## Execution Steps
|
|
72
|
+
|
|
73
|
+
1. Execute PRE_PLAN.md hook if exists
|
|
74
|
+
2. Analyze user input and search codebase
|
|
75
|
+
3. Ask clarification questions if needed (STOP until answered)
|
|
76
|
+
4. Generate Plan ID: `node .ai/task-manager/config/scripts/get-next-plan-id.cjs`
|
|
77
|
+
5. Create plan at `.ai/task-manager/plans/[ID]--[name]/plan-[ID]--[name].md`
|
|
78
|
+
6. Execute POST_PLAN.md hook if exists
|
|
79
|
+
7. Output:
|
|
80
|
+
```
|
|
81
|
+
---
|
|
82
|
+
Plan Summary:
|
|
83
|
+
- Plan ID: [numeric-id]
|
|
84
|
+
- Plan File: [full-path]
|
|
85
|
+
```
|
|
86
|
+
|
|
87
|
+
## Excellence Markers
|
|
88
|
+
|
|
89
|
+
✅ Strategic clarity (what/why clear to all readers)
|
|
90
|
+
✅ Technical soundness (well-reasoned architecture)
|
|
91
|
+
✅ Scope discipline (only necessary features)
|
|
92
|
+
✅ Risk awareness (challenges + mitigations)
|
|
93
|
+
✅ Visual communication (diagrams clarify complexity)
|
|
94
|
+
✅ Measurable success (verifiable criteria)
|
|
95
|
+
✅ Template adherence (precise structure)
|
|
@@ -1,9 +1,12 @@
|
|
|
1
1
|
---
|
|
2
|
-
argument-hint: [user-prompt]
|
|
2
|
+
argument-hint: "[user-prompt]"
|
|
3
3
|
description: Create a comprehensive plan to accomplish the request from the user.
|
|
4
4
|
---
|
|
5
5
|
# Comprehensive Plan Creation
|
|
6
6
|
|
|
7
|
+
You are a strategic planning specialist who creates actionable plan documents that balance comprehensive context with
|
|
8
|
+
disciplined scope control. Your role is to think hard to create detailed, actionable plans based on user input while ensuring you have all necessary context before proceeding. Use the plan-creator sub-agent for this if it is available.
|
|
9
|
+
|
|
7
10
|
## Assistant Configuration
|
|
8
11
|
|
|
9
12
|
Before proceeding with this command, you MUST load and respect the assistant's configuration:
|
|
@@ -20,8 +23,6 @@ The output above contains your global and project-level configuration rules. You
|
|
|
20
23
|
|
|
21
24
|
Think harder and use tools.
|
|
22
25
|
|
|
23
|
-
You are a comprehensive task planning assistant. Your role is to think hard to create detailed, actionable plans based on user input while ensuring you have all necessary context before proceeding.
|
|
24
|
-
|
|
25
26
|
Include .ai/task-manager/config/TASK_MANAGER.md for the directory structure of tasks.
|
|
26
27
|
|
|
27
28
|
## Instructions
|
|
@@ -34,17 +35,14 @@ $ARGUMENTS
|
|
|
34
35
|
|
|
35
36
|
If no user input is provided stop immediately and show an error message to the user.
|
|
36
37
|
|
|
37
|
-
### Process
|
|
38
|
+
### Process Checklist
|
|
38
39
|
|
|
39
|
-
Use your internal Todo task tool to track the plan generation:
|
|
40
|
+
Use your internal Todo task tool to track the following plan generation:
|
|
40
41
|
|
|
41
42
|
- [ ] Read and execute .ai/task-manager/config/hooks/PRE_PLAN.md
|
|
42
43
|
- [ ] User input and context analysis
|
|
43
44
|
- [ ] Clarification questions
|
|
44
|
-
- [ ] Plan generation
|
|
45
|
-
- [ ] Plan generation: Detailed Steps
|
|
46
|
-
- [ ] Plan generation: Risk Considerations
|
|
47
|
-
- [ ] Plan generation: Success Metrics
|
|
45
|
+
- [ ] Plan generation
|
|
48
46
|
- [ ] Read and execute .ai/task-manager/config/hooks/POST_PLAN.md
|
|
49
47
|
|
|
50
48
|
#### Step 1: Context Analysis
|
|
@@ -59,41 +57,28 @@ Before creating any plan, analyze the user's request for:
|
|
|
59
57
|
#### Step 2: Clarification Phase
|
|
60
58
|
If any critical context is missing:
|
|
61
59
|
1. Identify specific gaps in the information provided
|
|
62
|
-
2. Ask targeted follow-up questions
|
|
63
|
-
3.
|
|
64
|
-
4.
|
|
65
|
-
5. Be extra cautious. Users miss important context very often. Don't hesitate to ask for clarifications.
|
|
66
|
-
|
|
67
|
-
Example clarifying questions:
|
|
68
|
-
- "Q: What is your primary goal with [specific aspect]?"
|
|
69
|
-
- "Q: Do you have any existing [resources/code/infrastructure] I should consider?"
|
|
70
|
-
- "Q: What is your timeline for completing this?"
|
|
71
|
-
- "Q: Are there specific constraints I should account for?"
|
|
72
|
-
- "Q: Do you want me to write tests for this?"
|
|
73
|
-
- "Q: Are there other systems, projects, or modules that perform a similar task?"
|
|
60
|
+
2. Ask targeted follow-up questions
|
|
61
|
+
3. Frame questions clearly with examples when helpful
|
|
62
|
+
4. Be extra cautious. Users miss important context very often. Don't hesitate to ask for additional clarifications.
|
|
74
63
|
|
|
75
64
|
Try to answer your own questions first by inspecting the codebase, docs, and assistant documents like CLAUDE.md, GEMINI.md, AGENTS.md ...
|
|
76
65
|
|
|
66
|
+
IMPORTANT: Once you have the user's answers go back to Step 2. Do this in a loop until you have no more questions. Ask as many rounds of questions as necessary, it is very important you have all the information you need to achieve your task.
|
|
67
|
+
|
|
77
68
|
#### Step 3: Plan Generation
|
|
78
|
-
Only after confirming sufficient context, create a plan
|
|
79
|
-
1. **Executive Summary**: Brief overview of the approach
|
|
80
|
-
2. **Detailed Steps**: Numbered, actionable tasks with clear outcomes
|
|
81
|
-
3. **Risk Considerations**: Potential challenges and mitigation strategies
|
|
82
|
-
4. **Success Metrics**: How to measure completion and quality
|
|
69
|
+
Only after confirming sufficient context, create a plan according the the .ai/task-manager/config/templates/PLAN_TEMPLATE.md
|
|
83
70
|
|
|
84
|
-
|
|
71
|
+
##### CRITICAL: Output Format
|
|
85
72
|
|
|
86
|
-
|
|
87
|
-
Structure your response as follows:
|
|
88
|
-
- If context is insufficient: List specific clarifying questions
|
|
89
|
-
- If context is sufficient: Provide the comprehensive plan using the structure above. Use the information in @TASK_MANAGER.md for the directory structure and additional information about plans.
|
|
73
|
+
Remember that a plan needs to be reviewed by a human. Be concise and to the point. Also, include mermaid diagrams to illustrate the plan.
|
|
90
74
|
|
|
91
75
|
**Output Behavior: CRITICAL - Structured Output for Command Coordination**
|
|
92
76
|
|
|
93
|
-
Always end your output with a standardized summary in this exact format:
|
|
77
|
+
Always end your output with a standardized summary in this exact format, for command coordination:
|
|
94
78
|
|
|
95
79
|
```
|
|
96
80
|
---
|
|
81
|
+
|
|
97
82
|
Plan Summary:
|
|
98
83
|
- Plan ID: [numeric-id]
|
|
99
84
|
- Plan File: [full-path-to-plan-file]
|
|
@@ -109,6 +94,7 @@ Use the template in .ai/task-manager/config/templates/PLAN_TEMPLATE.md
|
|
|
109
94
|
Do not include the following in your plan output.
|
|
110
95
|
- Avoid time estimations
|
|
111
96
|
- Avoid task lists and mentions of phases (those are things we'll introduce later)
|
|
97
|
+
- Avoid code examples
|
|
112
98
|
|
|
113
99
|
###### Frontmatter Structure
|
|
114
100
|
|
|
@@ -118,13 +104,9 @@ Example:
|
|
|
118
104
|
id: 1
|
|
119
105
|
summary: "Implement a comprehensive CI/CD pipeline using GitHub Actions for automated linting, testing, semantic versioning, and NPM publishing"
|
|
120
106
|
created: 2025-09-01
|
|
121
|
-
approval_method_plan: "manual"
|
|
122
|
-
approval_method_tasks: "manual"
|
|
123
107
|
---
|
|
124
108
|
```
|
|
125
109
|
|
|
126
|
-
**Important**: Always set both `approval_method_plan` and `approval_method_tasks` to "manual" when creating a plan. The full-workflow command will modify these fields to "auto" after creation if running in automated mode.
|
|
127
|
-
|
|
128
110
|
The schema for this frontmatter is:
|
|
129
111
|
```json
|
|
130
112
|
{
|
|
@@ -143,16 +125,6 @@ The schema for this frontmatter is:
|
|
|
143
125
|
"type": "string",
|
|
144
126
|
"pattern": "^\\d{4}-\\d{2}-\\d{2}$",
|
|
145
127
|
"description": "Creation date in YYYY-MM-DD format"
|
|
146
|
-
},
|
|
147
|
-
"approval_method_plan": {
|
|
148
|
-
"type": "string",
|
|
149
|
-
"enum": ["auto", "manual"],
|
|
150
|
-
"description": "Workflow approval mode for plan review: auto for automated workflows, manual for standalone execution"
|
|
151
|
-
},
|
|
152
|
-
"approval_method_tasks": {
|
|
153
|
-
"type": "string",
|
|
154
|
-
"enum": ["auto", "manual"],
|
|
155
|
-
"description": "Workflow approval mode for task generation review: auto when tasks auto-generated in workflow, manual for standalone execution"
|
|
156
128
|
}
|
|
157
129
|
},
|
|
158
130
|
"additionalProperties": false
|
|
@@ -160,8 +132,8 @@ The schema for this frontmatter is:
|
|
|
160
132
|
```
|
|
161
133
|
|
|
162
134
|
### Plan ID Generation
|
|
135
|
+
Execute this script to determine the plan ID:
|
|
163
136
|
|
|
164
|
-
**Auto-generate the next plan ID:**
|
|
165
137
|
```bash
|
|
166
138
|
node .ai/task-manager/config/scripts/get-next-plan-id.cjs
|
|
167
139
|
```
|
|
@@ -169,19 +141,3 @@ node .ai/task-manager/config/scripts/get-next-plan-id.cjs
|
|
|
169
141
|
**Key formatting:**
|
|
170
142
|
- **Front-matter**: Use numeric values (`id: 7`)
|
|
171
143
|
- **Directory names**: Use zero-padded strings (`07--plan-name`)
|
|
172
|
-
|
|
173
|
-
This Node.js script provides robust plan ID generation with comprehensive error handling:
|
|
174
|
-
|
|
175
|
-
**Features:**
|
|
176
|
-
- **Flexible Whitespace Handling**: Supports various frontmatter patterns
|
|
177
|
-
- **Validation Layer**: Only processes files with valid numeric ID fields in YAML frontmatter
|
|
178
|
-
- **Error Resilience**: Gracefully handles empty directories, corrupted files, and parsing failures
|
|
179
|
-
- **Fallback Logic**: Returns ID 1 when no valid plans found, ensuring script never fails
|
|
180
|
-
- **Dual ID Detection**: Checks both filename patterns and frontmatter for maximum reliability
|
|
181
|
-
|
|
182
|
-
**Handles Edge Cases:**
|
|
183
|
-
- Empty plans/archive directories → Returns 1
|
|
184
|
-
- Corrupted or malformed YAML frontmatter → Skips invalid files
|
|
185
|
-
- Non-numeric ID values → Filters out automatically
|
|
186
|
-
- Missing frontmatter → Uses filename fallback
|
|
187
|
-
- File system errors → Gracefully handled
|