@langadventurellc/task-trellis-mcp 1.2.2 → 1.3.1
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/README.md +5 -4
- package/dist/__tests__/copyBasicClaudeAgents.test.d.ts +2 -0
- package/dist/__tests__/copyBasicClaudeAgents.test.d.ts.map +1 -0
- package/dist/__tests__/copyBasicClaudeAgents.test.js +24 -0
- package/dist/__tests__/copyBasicClaudeAgents.test.js.map +1 -0
- package/dist/__tests__/e2e/crud/createObject.e2e.test.js +4 -4
- package/dist/__tests__/e2e/crud/createObject.e2e.test.js.map +1 -1
- package/dist/__tests__/e2e/crud/fileValidation.e2e.test.js +4 -4
- package/dist/__tests__/e2e/crud/fileValidation.e2e.test.js.map +1 -1
- package/dist/__tests__/e2e/crud/getObject.e2e.test.js +3 -3
- package/dist/__tests__/e2e/crud/getObject.e2e.test.js.map +1 -1
- package/dist/__tests__/e2e/workflow/appendLog.e2e.test.js +10 -10
- package/dist/__tests__/e2e/workflow/appendLog.e2e.test.js.map +1 -1
- package/dist/__tests__/e2e/workflow/appendModifiedFiles.e2e.test.js +1 -1
- package/dist/__tests__/e2e/workflow/appendModifiedFiles.e2e.test.js.map +1 -1
- package/dist/__tests__/e2e/workflow/getNextAvailableIssue.e2e.test.d.ts +2 -0
- package/dist/__tests__/e2e/workflow/getNextAvailableIssue.e2e.test.d.ts.map +1 -0
- package/dist/__tests__/e2e/workflow/getNextAvailableIssue.e2e.test.js +806 -0
- package/dist/__tests__/e2e/workflow/getNextAvailableIssue.e2e.test.js.map +1 -0
- package/dist/__tests__/e2e/workflow/taskLifecycle.e2e.test.js +7 -7
- package/dist/__tests__/e2e/workflow/taskLifecycle.e2e.test.js.map +1 -1
- package/dist/__tests__/serverStartup.test.js +138 -0
- package/dist/__tests__/serverStartup.test.js.map +1 -1
- package/dist/models/TrellisObject.d.ts +1 -1
- package/dist/models/TrellisObject.d.ts.map +1 -1
- package/dist/models/TrellisObjectSummary.d.ts +1 -1
- package/dist/models/TrellisObjectSummary.d.ts.map +1 -1
- package/dist/models/__tests__/isClaimable.test.js +1 -0
- package/dist/models/__tests__/isClaimable.test.js.map +1 -1
- package/dist/models/__tests__/isClosed.test.js +3 -1
- package/dist/models/__tests__/isClosed.test.js.map +1 -1
- package/dist/models/__tests__/isOpen.test.js +3 -1
- package/dist/models/__tests__/isOpen.test.js.map +1 -1
- package/dist/prompts/PromptArgument.d.ts +16 -0
- package/dist/prompts/PromptArgument.d.ts.map +1 -0
- package/dist/prompts/PromptArgument.js +3 -0
- package/dist/prompts/PromptArgument.js.map +1 -0
- package/dist/prompts/PromptManager.d.ts +48 -0
- package/dist/prompts/PromptManager.d.ts.map +1 -0
- package/dist/prompts/PromptManager.js +151 -0
- package/dist/prompts/PromptManager.js.map +1 -0
- package/dist/prompts/PromptMessage.d.ts +11 -0
- package/dist/prompts/PromptMessage.d.ts.map +1 -0
- package/dist/prompts/PromptMessage.js +3 -0
- package/dist/prompts/PromptMessage.js.map +1 -0
- package/dist/prompts/PromptParser.d.ts +7 -0
- package/dist/prompts/PromptParser.d.ts.map +1 -0
- package/dist/prompts/PromptParser.js +141 -0
- package/dist/prompts/PromptParser.js.map +1 -0
- package/dist/prompts/PromptRenderer.d.ts +38 -0
- package/dist/prompts/PromptRenderer.d.ts.map +1 -0
- package/dist/prompts/PromptRenderer.js +128 -0
- package/dist/prompts/PromptRenderer.js.map +1 -0
- package/dist/prompts/PromptsRegistry.d.ts +43 -0
- package/dist/prompts/PromptsRegistry.d.ts.map +1 -0
- package/dist/prompts/PromptsRegistry.js +76 -0
- package/dist/prompts/PromptsRegistry.js.map +1 -0
- package/dist/prompts/TrellisPrompt.d.ts +19 -0
- package/dist/prompts/TrellisPrompt.d.ts.map +1 -0
- package/dist/prompts/TrellisPrompt.js +3 -0
- package/dist/prompts/TrellisPrompt.js.map +1 -0
- package/dist/prompts/__tests__/PromptArgument.test.d.ts +2 -0
- package/dist/prompts/__tests__/PromptArgument.test.d.ts.map +1 -0
- package/dist/prompts/__tests__/PromptArgument.test.js +60 -0
- package/dist/prompts/__tests__/PromptArgument.test.js.map +1 -0
- package/dist/prompts/__tests__/PromptManager.test.d.ts +2 -0
- package/dist/prompts/__tests__/PromptManager.test.d.ts.map +1 -0
- package/dist/prompts/__tests__/PromptManager.test.js +364 -0
- package/dist/prompts/__tests__/PromptManager.test.js.map +1 -0
- package/dist/prompts/__tests__/PromptParser.test.d.ts +2 -0
- package/dist/prompts/__tests__/PromptParser.test.d.ts.map +1 -0
- package/dist/prompts/__tests__/PromptParser.test.js +237 -0
- package/dist/prompts/__tests__/PromptParser.test.js.map +1 -0
- package/dist/prompts/__tests__/PromptRenderer.test.d.ts +2 -0
- package/dist/prompts/__tests__/PromptRenderer.test.d.ts.map +1 -0
- package/dist/prompts/__tests__/PromptRenderer.test.js +325 -0
- package/dist/prompts/__tests__/PromptRenderer.test.js.map +1 -0
- package/dist/prompts/__tests__/TrellisPrompt.test.d.ts +2 -0
- package/dist/prompts/__tests__/TrellisPrompt.test.d.ts.map +1 -0
- package/dist/prompts/__tests__/TrellisPrompt.test.js +107 -0
- package/dist/prompts/__tests__/TrellisPrompt.test.js.map +1 -0
- package/dist/prompts/index.d.ts +9 -0
- package/dist/prompts/index.d.ts.map +1 -0
- package/dist/prompts/index.js +14 -0
- package/dist/prompts/index.js.map +1 -0
- package/dist/prompts/registry.d.ts +6 -0
- package/dist/prompts/registry.d.ts.map +1 -0
- package/dist/prompts/registry.js +60 -0
- package/dist/prompts/registry.js.map +1 -0
- package/dist/repositories/local/__tests__/getObjectByFilePath.test.js +5 -5
- package/dist/repositories/local/__tests__/getObjectByFilePath.test.js.map +1 -1
- package/dist/repositories/local/__tests__/getObjectFilePath.test.js +2 -2
- package/dist/repositories/local/__tests__/getObjectFilePath.test.js.map +1 -1
- package/dist/resources/basic/prompts/create-epics.md +177 -0
- package/dist/resources/basic/prompts/create-features.md +172 -0
- package/dist/resources/basic/prompts/create-project.md +128 -0
- package/dist/resources/basic/prompts/create-tasks.md +225 -0
- package/dist/resources/basic/prompts/implement-task.md +170 -0
- package/dist/resources/basic-claude/agents/implementation-planner.md +187 -0
- package/dist/resources/basic-claude/agents/issue-verifier.md +154 -0
- package/dist/resources/basic-claude/prompts/create-epics.md +204 -0
- package/dist/resources/basic-claude/prompts/create-features.md +199 -0
- package/dist/resources/basic-claude/prompts/create-project.md +155 -0
- package/dist/resources/basic-claude/prompts/create-tasks.md +252 -0
- package/dist/resources/basic-claude/prompts/implement-task.md +179 -0
- package/dist/server.js +59 -2
- package/dist/server.js.map +1 -1
- package/dist/services/TaskTrellisService.d.ts +9 -0
- package/dist/services/TaskTrellisService.d.ts.map +1 -1
- package/dist/services/local/LocalTaskTrellisService.d.ts +6 -0
- package/dist/services/local/LocalTaskTrellisService.d.ts.map +1 -1
- package/dist/services/local/LocalTaskTrellisService.js +24 -0
- package/dist/services/local/LocalTaskTrellisService.js.map +1 -1
- package/dist/services/local/__tests__/appendAffectedFiles.test.js +9 -9
- package/dist/services/local/__tests__/appendAffectedFiles.test.js.map +1 -1
- package/dist/services/local/__tests__/appendModifiedFiles.test.js +1 -1
- package/dist/services/local/__tests__/appendModifiedFiles.test.js.map +1 -1
- package/dist/services/local/__tests__/claimTask.test.js +1 -0
- package/dist/services/local/__tests__/claimTask.test.js.map +1 -1
- package/dist/services/local/__tests__/completeTask.test.js +3 -3
- package/dist/services/local/__tests__/completeTask.test.js.map +1 -1
- package/dist/services/local/__tests__/createObject.test.js +7 -4
- package/dist/services/local/__tests__/createObject.test.js.map +1 -1
- package/dist/services/local/__tests__/getNextAvailableIssue.test.d.ts +2 -0
- package/dist/services/local/__tests__/getNextAvailableIssue.test.d.ts.map +1 -0
- package/dist/services/local/__tests__/getNextAvailableIssue.test.js +314 -0
- package/dist/services/local/__tests__/getNextAvailableIssue.test.js.map +1 -0
- package/dist/services/local/__tests__/listObjects.test.js +1 -0
- package/dist/services/local/__tests__/listObjects.test.js.map +1 -1
- package/dist/services/local/__tests__/pruneClosed.test.js +1 -0
- package/dist/services/local/__tests__/pruneClosed.test.js.map +1 -1
- package/dist/services/local/__tests__/updateObject.test.js +2 -2
- package/dist/services/local/__tests__/updateObject.test.js.map +1 -1
- package/dist/services/local/createObject.d.ts +1 -1
- package/dist/services/local/createObject.d.ts.map +1 -1
- package/dist/services/local/createObject.js +1 -1
- package/dist/services/local/createObject.js.map +1 -1
- package/dist/services/local/getNextAvailableIssue.d.ts +14 -0
- package/dist/services/local/getNextAvailableIssue.d.ts.map +1 -0
- package/dist/services/local/getNextAvailableIssue.js +28 -0
- package/dist/services/local/getNextAvailableIssue.js.map +1 -0
- package/dist/tools/__tests__/claimTaskTool.test.js +1 -0
- package/dist/tools/__tests__/claimTaskTool.test.js.map +1 -1
- package/dist/tools/__tests__/completeTaskTool.test.js +1 -0
- package/dist/tools/__tests__/completeTaskTool.test.js.map +1 -1
- package/dist/tools/__tests__/getObjectTool.test.js +1 -0
- package/dist/tools/__tests__/getObjectTool.test.js.map +1 -1
- package/dist/tools/__tests__/listObjectsTool.test.js +1 -0
- package/dist/tools/__tests__/listObjectsTool.test.js.map +1 -1
- package/dist/tools/getNextAvailableIssueTool.d.ts +34 -0
- package/dist/tools/getNextAvailableIssueTool.d.ts.map +1 -0
- package/dist/tools/getNextAvailableIssueTool.js +94 -0
- package/dist/tools/getNextAvailableIssueTool.js.map +1 -0
- package/dist/tools/index.d.ts +1 -0
- package/dist/tools/index.d.ts.map +1 -1
- package/dist/tools/index.js +4 -1
- package/dist/tools/index.js.map +1 -1
- package/dist/utils/__tests__/checkHierarchicalPrerequisitesComplete.test.js +3 -3
- package/dist/utils/__tests__/checkHierarchicalPrerequisitesComplete.test.js.map +1 -1
- package/dist/utils/__tests__/checkPrerequisitesComplete.test.js +1 -0
- package/dist/utils/__tests__/checkPrerequisitesComplete.test.js.map +1 -1
- package/dist/utils/__tests__/deserializeTrellisObject.test.js +23 -1
- package/dist/utils/__tests__/deserializeTrellisObject.test.js.map +1 -1
- package/dist/utils/__tests__/filterUnavailableObjects.test.js +1 -1
- package/dist/utils/__tests__/filterUnavailableObjects.test.js.map +1 -1
- package/dist/utils/__tests__/isRequiredForOtherObjects.test.js +1 -0
- package/dist/utils/__tests__/isRequiredForOtherObjects.test.js.map +1 -1
- package/dist/utils/__tests__/serializationRoundTrip.test.js +35 -0
- package/dist/utils/__tests__/serializationRoundTrip.test.js.map +1 -1
- package/dist/utils/__tests__/serializeTrellisObject.test.js +8 -2
- package/dist/utils/__tests__/serializeTrellisObject.test.js.map +1 -1
- package/dist/utils/__tests__/sortTrellisObjects.test.js +1 -0
- package/dist/utils/__tests__/sortTrellisObjects.test.js.map +1 -1
- package/dist/utils/__tests__/updateParentHierarchy.test.js +4 -4
- package/dist/utils/__tests__/updateParentHierarchy.test.js.map +1 -1
- package/dist/utils/deserializeTrellisObject.d.ts.map +1 -1
- package/dist/utils/deserializeTrellisObject.js +1 -1
- package/dist/utils/deserializeTrellisObject.js.map +1 -1
- package/dist/utils/serializeTrellisObject.js +1 -1
- package/dist/utils/serializeTrellisObject.js.map +1 -1
- package/dist/utils/updateParentHierarchy.d.ts +1 -1
- package/dist/utils/updateParentHierarchy.d.ts.map +1 -1
- package/dist/utils/updateParentHierarchy.js.map +1 -1
- package/dist/validation/__tests__/validateObjectCreation.test.js +3 -3
- package/dist/validation/__tests__/validateObjectCreation.test.js.map +1 -1
- package/dist/validation/__tests__/validateParentExists.test.js +2 -1
- package/dist/validation/__tests__/validateParentExists.test.js.map +1 -1
- package/dist/validation/validateParentExists.d.ts +1 -1
- package/dist/validation/validateParentExists.d.ts.map +1 -1
- package/dist/validation/validateParentExists.js.map +1 -1
- package/package.json +3 -2
|
@@ -0,0 +1,199 @@
|
|
|
1
|
+
---
|
|
2
|
+
description: Break down an epic into specific features by analyzing the epic specification
|
|
3
|
+
---
|
|
4
|
+
|
|
5
|
+
# Create Features Command
|
|
6
|
+
|
|
7
|
+
Break down an epic into specific features using the Trellis task management system by analyzing the epic specification and gathering additional requirements as needed. Do not attempt to create multiple features in parallel. Do them sequentially one at a time.
|
|
8
|
+
|
|
9
|
+
## Goal
|
|
10
|
+
|
|
11
|
+
Analyze an epic's comprehensive specification to create well-structured features that represent implementable functionality, ensuring complete coverage of the epic's scope and enabling effective task decomposition.
|
|
12
|
+
|
|
13
|
+
**IMPORTANT**: Features must include actual changes, implementations, or deliverables. Do not create features that are purely research tasks or analysis tasks without any tangible output. Since all features and tasks are executed independently without context from other features or tasks, purely analytical work provides no value.
|
|
14
|
+
|
|
15
|
+
## Process
|
|
16
|
+
|
|
17
|
+
### 1. Identify Context and Requirements
|
|
18
|
+
|
|
19
|
+
#### Input
|
|
20
|
+
|
|
21
|
+
`$ARGUMENTS`
|
|
22
|
+
|
|
23
|
+
#### Context Determination
|
|
24
|
+
|
|
25
|
+
The input may contain:
|
|
26
|
+
|
|
27
|
+
- **Epic ID**: (e.g., "E-user-auth") - Create features within an epic hierarchy
|
|
28
|
+
- **Feature Requirements**: Direct description of standalone functionality needed
|
|
29
|
+
- **Mixed**: Epic ID plus additional feature specifications
|
|
30
|
+
|
|
31
|
+
#### Instructions
|
|
32
|
+
|
|
33
|
+
**For Hierarchical Features:**
|
|
34
|
+
|
|
35
|
+
- Retrieve the epic using MCP `get_issue` to access its comprehensive description, requirements, and parent project context
|
|
36
|
+
|
|
37
|
+
**For Standalone Features:**
|
|
38
|
+
|
|
39
|
+
- Analyze the provided requirements directly
|
|
40
|
+
- No parent context needed, focus on the specific functionality described
|
|
41
|
+
|
|
42
|
+
### 2. Analyze Requirements
|
|
43
|
+
|
|
44
|
+
**Thoroughly analyze the requirements (epic description OR standalone requirements) to identify natural feature boundaries:**
|
|
45
|
+
|
|
46
|
+
- **Search codebase** for similar feature patterns or implementations
|
|
47
|
+
- Extract all deliverables and components from the epic description
|
|
48
|
+
- Review architecture diagrams and technical specifications
|
|
49
|
+
- Analyze user stories to identify discrete user-facing functionality
|
|
50
|
+
- Consider non-functional requirements that need specific implementation
|
|
51
|
+
- Group related functionality into cohesive features
|
|
52
|
+
- Identify dependencies between features
|
|
53
|
+
- Note any specific instructions provided in `input`
|
|
54
|
+
|
|
55
|
+
### 3. Gather Additional Information
|
|
56
|
+
|
|
57
|
+
**Ask clarifying questions as needed to refine the feature structure:**
|
|
58
|
+
|
|
59
|
+
Use this structured approach:
|
|
60
|
+
|
|
61
|
+
- **Ask one question at a time** with specific options
|
|
62
|
+
- **Focus on feature boundaries** - understand what constitutes a complete, testable feature
|
|
63
|
+
- **Identify component relationships** - how features interact with each other
|
|
64
|
+
- **Continue until complete** - don't stop until you have clear feature structure
|
|
65
|
+
|
|
66
|
+
Key areas to clarify:
|
|
67
|
+
|
|
68
|
+
- **Feature Boundaries**: What constitutes a complete, testable feature?
|
|
69
|
+
- **Dependencies**: Which features must be implemented before others?
|
|
70
|
+
- **Technical Approach**: How should complex functionality be divided?
|
|
71
|
+
- **Testing Strategy**: How can features be tested independently?
|
|
72
|
+
- **Integration Points**: Where do features interface with each other?
|
|
73
|
+
|
|
74
|
+
**Example questioning approach:**
|
|
75
|
+
|
|
76
|
+
```
|
|
77
|
+
How should the user registration feature be scoped?
|
|
78
|
+
Options:
|
|
79
|
+
- A) Basic registration only (email, password, confirmation)
|
|
80
|
+
- B) Full registration with profile setup and email verification
|
|
81
|
+
- C) Registration with social login integration included
|
|
82
|
+
```
|
|
83
|
+
|
|
84
|
+
Continue until the feature structure:
|
|
85
|
+
|
|
86
|
+
- Covers all aspects of the epic specification
|
|
87
|
+
- Represents 6-20 tasks worth of work per feature
|
|
88
|
+
- Has clear implementation boundaries
|
|
89
|
+
- Enables independent development and testing
|
|
90
|
+
|
|
91
|
+
### 4. Generate Feature Structure
|
|
92
|
+
|
|
93
|
+
For each feature, create:
|
|
94
|
+
|
|
95
|
+
- **Title**: Clear, specific name (3-5 words)
|
|
96
|
+
- **Description**: Comprehensive explanation including:
|
|
97
|
+
- Purpose and functionality
|
|
98
|
+
- Key components to implement
|
|
99
|
+
- **Detailed Acceptance Criteria**: Specific, measurable requirements that define feature completion, including:
|
|
100
|
+
- Functional behavior with specific input/output expectations
|
|
101
|
+
- User interface requirements and interaction patterns
|
|
102
|
+
- Data validation and error handling criteria
|
|
103
|
+
- Integration points with other features or systems
|
|
104
|
+
- Performance benchmarks and response time requirements
|
|
105
|
+
- Security validation and access control requirements
|
|
106
|
+
- Browser/platform compatibility requirements
|
|
107
|
+
- Accessibility and usability standards
|
|
108
|
+
- Technical requirements
|
|
109
|
+
- Dependencies on other features
|
|
110
|
+
- **Implementation Guidance** - Technical approach and patterns to follow
|
|
111
|
+
- **Testing Requirements** - How to verify the feature works correctly
|
|
112
|
+
- **Security Considerations** - Input validation, authorization, data protection needs
|
|
113
|
+
- **Performance Requirements** - Response times, resource usage constraints
|
|
114
|
+
|
|
115
|
+
**Feature Granularity Guidelines:**
|
|
116
|
+
|
|
117
|
+
Each feature should be sized appropriately for task breakdown:
|
|
118
|
+
|
|
119
|
+
- **1-2 hours per task** - When broken down, each task should be completable in 1-2 hours
|
|
120
|
+
- **Independent implementation** - Features should be implementable without blocking other features
|
|
121
|
+
- **Testable boundaries** - Features should have clear success criteria and testing strategies
|
|
122
|
+
|
|
123
|
+
### 5. Create Features Using MCP
|
|
124
|
+
|
|
125
|
+
For each feature, call the Task Trellis MCP `create_issue` tool:
|
|
126
|
+
|
|
127
|
+
- `type`: Set to `"feature"`
|
|
128
|
+
- `parent`: The epic ID (optional - omit for standalone features)
|
|
129
|
+
- `title`: Generated feature title
|
|
130
|
+
- `status`: Set to `"open"` (default, ready to begin work) or `"draft"` unless specified
|
|
131
|
+
- `prerequisites`: List of feature IDs that must complete first
|
|
132
|
+
- `description`: Comprehensive feature description with all elements from step 4
|
|
133
|
+
|
|
134
|
+
**For standalone features**: Simply omit the `parent` parameter entirely.
|
|
135
|
+
|
|
136
|
+
### 6. Verify Created Project
|
|
137
|
+
|
|
138
|
+
Call the `issue-verifier` sub-agent to validate the created project:
|
|
139
|
+
|
|
140
|
+
**Prepare verification inputs:**
|
|
141
|
+
|
|
142
|
+
- Original specifications from `$ARGUMENTS`
|
|
143
|
+
- Created issue ID(s) from the MCP response
|
|
144
|
+
- Any additional context gathered during requirement gathering phase
|
|
145
|
+
|
|
146
|
+
**Call the verifier:**
|
|
147
|
+
|
|
148
|
+
```
|
|
149
|
+
Verify the created project for completeness and correctness:
|
|
150
|
+
- Original requirements: [Include the original $ARGUMENTS specifications]
|
|
151
|
+
- Created issue ID(s): [issue-id from MCP response]
|
|
152
|
+
- Additional context: [Include any clarifications, decisions, or requirements gathered during the interactive Q&A phase]
|
|
153
|
+
```
|
|
154
|
+
|
|
155
|
+
**Review verification results:**
|
|
156
|
+
|
|
157
|
+
- If verdict is `APPROVED`: Proceed to output format
|
|
158
|
+
- If verdict is `NEEDS REVISION`: Evaluate the feedback and, if applicable, update the project using MCP based on recommendations
|
|
159
|
+
- If verdict is `REJECTED`: Evaluate the feedback and, if applicable, recreate the project addressing critical issues
|
|
160
|
+
|
|
161
|
+
If you're not 100% sure of the correctness of the feedback, **STOP** and ask the user for clarification.
|
|
162
|
+
|
|
163
|
+
### 7. Output Format
|
|
164
|
+
|
|
165
|
+
After successful creation:
|
|
166
|
+
|
|
167
|
+
```
|
|
168
|
+
✅ Successfully created [N] features for epic "[Epic Title]"
|
|
169
|
+
|
|
170
|
+
📋 Created Features:
|
|
171
|
+
1. F-[id1]: [Feature 1 Title]
|
|
172
|
+
→ Dependencies: none
|
|
173
|
+
|
|
174
|
+
2. F-[id2]: [Feature 2 Title]
|
|
175
|
+
→ Dependencies: F-[id1]
|
|
176
|
+
|
|
177
|
+
3. F-[id3]: [Feature 3 Title]
|
|
178
|
+
→ Dependencies: F-[id1], F-[id2]
|
|
179
|
+
|
|
180
|
+
📊 Feature Summary:
|
|
181
|
+
- Total Features: [N]
|
|
182
|
+
```
|
|
183
|
+
|
|
184
|
+
## Question Guidelines
|
|
185
|
+
|
|
186
|
+
Ask questions that:
|
|
187
|
+
|
|
188
|
+
- **Define feature scope**: What's included vs excluded?
|
|
189
|
+
- **Clarify technical approach**: Specific technologies or patterns?
|
|
190
|
+
- **Identify dependencies**: Build order and integration points?
|
|
191
|
+
- **Consider testing**: How to verify feature completeness?
|
|
192
|
+
|
|
193
|
+
<rules>
|
|
194
|
+
<critical>Use MCP tools for all operations (create_issue, get_issue, etc.)</critical>
|
|
195
|
+
<critical>Ask one question at a time with specific options</critical>
|
|
196
|
+
<critical>Continue asking questions until you have complete understanding of feature boundaries</critical>
|
|
197
|
+
<important>Feature descriptions must be detailed enough for task creation</important>
|
|
198
|
+
<important>Include implementation guidance and testing requirements</important>
|
|
199
|
+
</rules>
|
|
@@ -0,0 +1,155 @@
|
|
|
1
|
+
---
|
|
2
|
+
description: Create a new project in the Trellis task management system by analyzing specifications and gathering requirements
|
|
3
|
+
---
|
|
4
|
+
|
|
5
|
+
# Create Project Trellis Command
|
|
6
|
+
|
|
7
|
+
Create a new project in the Trellis task management system by analyzing specifications provided and gathering additional requirements as needed.
|
|
8
|
+
|
|
9
|
+
## Goal
|
|
10
|
+
|
|
11
|
+
Transform project specifications into a comprehensive project definition with full context and requirements that enable other agents to effectively create epics, features, and ultimately implementable tasks.
|
|
12
|
+
|
|
13
|
+
## Process
|
|
14
|
+
|
|
15
|
+
### 1. Parse Input Specifications
|
|
16
|
+
|
|
17
|
+
#### Specification Input
|
|
18
|
+
|
|
19
|
+
`$ARGUMENTS`
|
|
20
|
+
|
|
21
|
+
#### Instructions
|
|
22
|
+
|
|
23
|
+
Read and analyze the specifications:
|
|
24
|
+
|
|
25
|
+
- Extract key project goals, requirements, and constraints
|
|
26
|
+
|
|
27
|
+
### 2. Analyze Project Context
|
|
28
|
+
|
|
29
|
+
**Before gathering requirements, research the existing system:**
|
|
30
|
+
|
|
31
|
+
- **Search codebase** for similar projects or patterns
|
|
32
|
+
- **Identify existing architecture** and conventions
|
|
33
|
+
- **Document discovered technologies** for consistency
|
|
34
|
+
|
|
35
|
+
### 3. Gather Additional Requirements
|
|
36
|
+
|
|
37
|
+
**Continue asking questions until you can create a complete project specification:**
|
|
38
|
+
|
|
39
|
+
Use this structured approach:
|
|
40
|
+
|
|
41
|
+
- **Ask one question at a time** with specific options
|
|
42
|
+
- **Focus on decomposition** - break large concepts into smaller components
|
|
43
|
+
- **Clarify boundaries** - understand where one component ends and another begins
|
|
44
|
+
- **Continue until complete** - don't stop until you have full understanding
|
|
45
|
+
|
|
46
|
+
Key areas to explore:
|
|
47
|
+
|
|
48
|
+
- **Functional Requirements**: What specific capabilities must the system provide?
|
|
49
|
+
- **Technical Architecture**: What technologies, frameworks, and patterns should be used?
|
|
50
|
+
- **Integration Points**: What external systems or APIs need to be integrated?
|
|
51
|
+
- **User Types**: Who will use this system and what are their needs?
|
|
52
|
+
- **Performance Requirements**: What are the response time, load, and scaling needs?
|
|
53
|
+
- **Security Requirements**: What authentication, authorization, and data protection is needed?
|
|
54
|
+
- **Deployment Environment**: Where and how will this be deployed?
|
|
55
|
+
- **Timeline & Phases**: Are there specific deadlines or phase requirements?
|
|
56
|
+
- **Success Metrics**: How will project success be measured?
|
|
57
|
+
|
|
58
|
+
**Example questioning approach:**
|
|
59
|
+
|
|
60
|
+
```
|
|
61
|
+
How should user authentication be handled in this project?
|
|
62
|
+
Options:
|
|
63
|
+
- A) Use existing authentication system (specify integration points)
|
|
64
|
+
- B) Implement new authentication mechanism (specify requirements)
|
|
65
|
+
- C) No authentication needed for this project
|
|
66
|
+
```
|
|
67
|
+
|
|
68
|
+
Continue asking clarifying questions until you have enough information to create a comprehensive project description that would enable another agent to:
|
|
69
|
+
|
|
70
|
+
- Understand the full scope and vision
|
|
71
|
+
- Create appropriate epics covering all aspects
|
|
72
|
+
- Make informed technical decisions
|
|
73
|
+
- Understand constraints and requirements
|
|
74
|
+
|
|
75
|
+
### 4. Generate Project Title and Description
|
|
76
|
+
|
|
77
|
+
Based on gathered information:
|
|
78
|
+
|
|
79
|
+
- **Title**: Create a clear, concise project title (5-7 words)
|
|
80
|
+
- **Description**: Write comprehensive project specification including:
|
|
81
|
+
- Executive summary
|
|
82
|
+
- Detailed functional requirements
|
|
83
|
+
- Technical requirements and constraints
|
|
84
|
+
- Architecture overview
|
|
85
|
+
- User stories or personas
|
|
86
|
+
- Non-functional requirements (performance, security, etc.)
|
|
87
|
+
- Integration requirements
|
|
88
|
+
- Deployment strategy
|
|
89
|
+
- **Detailed Acceptance Criteria**: Specific, measurable requirements that define feature completion, including:
|
|
90
|
+
- Functional behavior with specific input/output expectations
|
|
91
|
+
- User interface requirements and interaction patterns
|
|
92
|
+
- Data validation and error handling criteria
|
|
93
|
+
- Integration points with other features or systems
|
|
94
|
+
- Performance benchmarks and response time requirements
|
|
95
|
+
- Security validation and access control requirements
|
|
96
|
+
- Browser/platform compatibility requirements
|
|
97
|
+
- Accessibility and usability standards
|
|
98
|
+
- Any other context needed for epic creation
|
|
99
|
+
|
|
100
|
+
### 5. Create Project Using MCP
|
|
101
|
+
|
|
102
|
+
Call the Task Trellis MCP `create_issue` tool to create the project with the following parameters:
|
|
103
|
+
|
|
104
|
+
- `type`: Set to `"project"`
|
|
105
|
+
- `title`: The generated project title
|
|
106
|
+
- `status`: Set to `"open"` (default, ready to begin work) or `"draft"` unless specified
|
|
107
|
+
- `description`: The comprehensive project description generated in the previous step
|
|
108
|
+
|
|
109
|
+
### 6. Verify Created Project
|
|
110
|
+
|
|
111
|
+
Call the `issue-verifier` sub-agent to validate the created project:
|
|
112
|
+
|
|
113
|
+
**Prepare verification inputs:**
|
|
114
|
+
|
|
115
|
+
- Original specifications from `$ARGUMENTS`
|
|
116
|
+
- Created issue ID(s) from the MCP response
|
|
117
|
+
- Any additional context gathered during requirement gathering phase
|
|
118
|
+
|
|
119
|
+
**Call the verifier:**
|
|
120
|
+
|
|
121
|
+
```
|
|
122
|
+
Verify the created project for completeness and correctness:
|
|
123
|
+
- Original requirements: [Include the original $ARGUMENTS specifications]
|
|
124
|
+
- Created issue ID(s): [issue-id from MCP response]
|
|
125
|
+
- Additional context: [Include any clarifications, decisions, or requirements gathered during the interactive Q&A phase]
|
|
126
|
+
```
|
|
127
|
+
|
|
128
|
+
**Review verification results:**
|
|
129
|
+
|
|
130
|
+
- If verdict is `APPROVED`: Proceed to output format
|
|
131
|
+
- If verdict is `NEEDS REVISION`: Evaluate the feedback and, if applicable, update the project using MCP based on recommendations
|
|
132
|
+
- If verdict is `REJECTED`: Evaluate the feedback and, if applicable, recreate the project addressing critical issues
|
|
133
|
+
|
|
134
|
+
If you're not 100% sure of the correctness of the feedback, **STOP** and ask the user for clarification.
|
|
135
|
+
|
|
136
|
+
### 7. Output Format
|
|
137
|
+
|
|
138
|
+
After successful creation:
|
|
139
|
+
|
|
140
|
+
```
|
|
141
|
+
✅ Project created successfully!
|
|
142
|
+
|
|
143
|
+
📁 Project: [Generated Title]
|
|
144
|
+
📍 ID: [generated-id]
|
|
145
|
+
📊 Status: [actual-status]
|
|
146
|
+
|
|
147
|
+
📝 Project Summary:
|
|
148
|
+
[First paragraph of description]
|
|
149
|
+
```
|
|
150
|
+
|
|
151
|
+
<rules>
|
|
152
|
+
<critical>Use MCP tools for all operations (create_issue, get_issue, activate, etc.)</critical>
|
|
153
|
+
<critical>Continue asking questions until you have a complete understanding of the requirements</critical>
|
|
154
|
+
<critical>Ask one question at a time with specific options</critical>
|
|
155
|
+
</rules>
|
|
@@ -0,0 +1,252 @@
|
|
|
1
|
+
---
|
|
2
|
+
description: Break down a feature into specific, actionable tasks (1-2 hours each)
|
|
3
|
+
---
|
|
4
|
+
|
|
5
|
+
# Create Tasks Command
|
|
6
|
+
|
|
7
|
+
Break down a feature into specific, actionable tasks using the Trellis task management system. Do not attempt to create multiple tasks in parallel. Do them sequentially one at a time.
|
|
8
|
+
|
|
9
|
+
## Goal
|
|
10
|
+
|
|
11
|
+
Analyze a feature's comprehensive specification to create granular tasks that can be individually claimed and completed by developers, ensuring complete implementation of the feature with proper testing and security considerations.
|
|
12
|
+
|
|
13
|
+
## Process
|
|
14
|
+
|
|
15
|
+
### 1. Identify Context and Requirements
|
|
16
|
+
|
|
17
|
+
#### Input
|
|
18
|
+
|
|
19
|
+
`$ARGUMENTS`
|
|
20
|
+
|
|
21
|
+
#### Context Determination
|
|
22
|
+
|
|
23
|
+
The input may contain:
|
|
24
|
+
|
|
25
|
+
- **Feature ID**: (e.g., "F-user-registration") - Create tasks within a feature hierarchy
|
|
26
|
+
- **Task Requirements**: Direct description of standalone work needed
|
|
27
|
+
- **Mixed**: Feature ID plus additional task specifications
|
|
28
|
+
|
|
29
|
+
#### Instructions
|
|
30
|
+
|
|
31
|
+
**For Hierarchical Tasks:**
|
|
32
|
+
|
|
33
|
+
- Retrieve the feature using MCP `get_issue` to access its comprehensive description, requirements, and parent epic/project context
|
|
34
|
+
|
|
35
|
+
**For Standalone Tasks:**
|
|
36
|
+
|
|
37
|
+
- Analyze the provided requirements directly
|
|
38
|
+
- No parent context needed, focus on the specific work described
|
|
39
|
+
|
|
40
|
+
### 2. Analyze Requirements
|
|
41
|
+
|
|
42
|
+
**Thoroughly analyze the requirements (feature description OR standalone requirements) to identify required tasks:**
|
|
43
|
+
|
|
44
|
+
- **Search codebase** for similar task patterns or implementations
|
|
45
|
+
- Extract all components and deliverables from the feature description
|
|
46
|
+
- Review implementation guidance and technical approach
|
|
47
|
+
- Identify testing requirements for comprehensive coverage
|
|
48
|
+
- Consider security considerations that need implementation
|
|
49
|
+
- Analyze performance requirements and constraints
|
|
50
|
+
- Group related implementation work
|
|
51
|
+
- Identify task dependencies and sequencing
|
|
52
|
+
- Note any specific instructions provided in `input`
|
|
53
|
+
|
|
54
|
+
### 3. Gather Additional Information
|
|
55
|
+
|
|
56
|
+
**Ask clarifying questions as needed to refine the task breakdown:**
|
|
57
|
+
|
|
58
|
+
Use this structured approach:
|
|
59
|
+
|
|
60
|
+
- **Ask one question at a time** with specific options
|
|
61
|
+
- **Focus on task boundaries** - understand what constitutes a complete, testable task
|
|
62
|
+
- **Identify implementation details** - specific technical approaches or patterns
|
|
63
|
+
- **Continue until complete** - don't stop until you have clear task structure
|
|
64
|
+
|
|
65
|
+
Key areas to clarify:
|
|
66
|
+
|
|
67
|
+
- **Implementation Details**: Specific technical approaches or patterns?
|
|
68
|
+
- Include unit testing in the tasks for the implementation.
|
|
69
|
+
- **Task Boundaries**: What constitutes a complete, testable task?
|
|
70
|
+
- **Dependencies**: Which tasks must complete before others?
|
|
71
|
+
- **Testing Approach**: Unit tests, integration tests, or both?
|
|
72
|
+
- Do not create separate tasks just for unit tests. Unit tests should always be included in the same task as the changes to the production code.
|
|
73
|
+
- Do create separate tasks for integration tests.
|
|
74
|
+
- If specifically requested, do create separate tasks for performance tests. But, do not add tasks for performance tests unless specifically requested by the user.
|
|
75
|
+
- **Security Implementation**: How to handle validation and authorization?
|
|
76
|
+
|
|
77
|
+
**Example questioning approach:**
|
|
78
|
+
|
|
79
|
+
```
|
|
80
|
+
How should the user model validation be implemented?
|
|
81
|
+
Options:
|
|
82
|
+
- A) Basic field validation only (required fields, data types)
|
|
83
|
+
- B) Advanced validation with custom rules and error messages
|
|
84
|
+
- C) Validation with integration to existing validation framework
|
|
85
|
+
```
|
|
86
|
+
|
|
87
|
+
Continue until the task structure:
|
|
88
|
+
|
|
89
|
+
- Covers all aspects of the feature specification
|
|
90
|
+
- Represents atomic units of work (1-2 hours each)
|
|
91
|
+
- Has clear implementation boundaries
|
|
92
|
+
- Includes adequate testing and security tasks
|
|
93
|
+
|
|
94
|
+
### 4. Generate Task Structure
|
|
95
|
+
|
|
96
|
+
For each task, create:
|
|
97
|
+
|
|
98
|
+
- **Title**: Clear, actionable description
|
|
99
|
+
- **Description**: Detailed explanation including:
|
|
100
|
+
- **Detailed Context**: Enough information for a developer new to the project to complete the work, including:
|
|
101
|
+
- Links to relevant specifications, documentation, or other Trellis issues (tasks, features, epics, projects)
|
|
102
|
+
- References to existing patterns or similar implementations in the codebase
|
|
103
|
+
- Specific technologies, frameworks, or libraries to use
|
|
104
|
+
- File paths and component locations where work should be done
|
|
105
|
+
- **Specific implementation requirements**: What exactly needs to be built
|
|
106
|
+
- **Technical approach to follow**: Step-by-step guidance on implementation
|
|
107
|
+
- **Detailed Acceptance Criteria**: Specific, measurable requirements that define project success, including:
|
|
108
|
+
- Functional deliverables with clear success metrics
|
|
109
|
+
- Performance benchmarks (response times, throughput, capacity)
|
|
110
|
+
- Security requirements and compliance standards
|
|
111
|
+
- User experience criteria and usability standards
|
|
112
|
+
- Integration testing requirements with external systems
|
|
113
|
+
- Deployment and operational readiness criteria
|
|
114
|
+
- **Dependencies on other tasks**: Prerequisites and sequencing
|
|
115
|
+
- **Security considerations**: Validation, authorization, and protection requirements
|
|
116
|
+
- **Testing requirements**: Specific tests to write and coverage expectations
|
|
117
|
+
|
|
118
|
+
**Task Granularity Guidelines:**
|
|
119
|
+
|
|
120
|
+
Each task should be sized appropriately for implementation:
|
|
121
|
+
|
|
122
|
+
- **1-2 hours per task** - Tasks should be completable in one sitting
|
|
123
|
+
- **Atomic units of work** - Each task should produce a meaningful, testable change
|
|
124
|
+
- **Independent implementation** - Tasks should be workable without blocking others
|
|
125
|
+
- **Specific scope** - Implementation approach should be clear from the task description
|
|
126
|
+
- **Testable outcome** - Tasks should have defined acceptance criteria
|
|
127
|
+
|
|
128
|
+
**Default task hierarchy approach:**
|
|
129
|
+
|
|
130
|
+
- **Prefer flat structure** - Most tasks should be at the same level
|
|
131
|
+
- **Only create sub-tasks when necessary** - When a task is genuinely too large (>2 hours)
|
|
132
|
+
- **Keep it simple** - Avoid unnecessary complexity in task organization
|
|
133
|
+
|
|
134
|
+
Group tasks logically:
|
|
135
|
+
|
|
136
|
+
- **Setup/Configuration**: Initial setup tasks
|
|
137
|
+
- **Core Implementation**: Main functionality (includes unit tests and documentation)
|
|
138
|
+
- **Security**: Validation and protection (includes related tests and docs)
|
|
139
|
+
|
|
140
|
+
### 5. Create Tasks Using MCP
|
|
141
|
+
|
|
142
|
+
For each task, call the Task Trellis MCP `create_issue` tool:
|
|
143
|
+
|
|
144
|
+
- `type`: Set to `"task"`
|
|
145
|
+
- `parent`: The feature ID (optional - omit for standalone tasks)
|
|
146
|
+
- `title`: Generated task title
|
|
147
|
+
- `status`: Set to `"open"` (default, ready to claim) or `"draft"`
|
|
148
|
+
- `priority`: Based on criticality and dependencies (`"high"`, `"medium"`, or `"low"`)
|
|
149
|
+
- `prerequisites`: List of task IDs that must complete first
|
|
150
|
+
- `description`: Comprehensive task description
|
|
151
|
+
|
|
152
|
+
**For standalone tasks**: Simply omit the `parent` parameter entirely.
|
|
153
|
+
|
|
154
|
+
### 6. Verify Created Project
|
|
155
|
+
|
|
156
|
+
Call the `issue-verifier` sub-agent to validate the created project:
|
|
157
|
+
|
|
158
|
+
**Prepare verification inputs:**
|
|
159
|
+
|
|
160
|
+
- Original specifications from `$ARGUMENTS`
|
|
161
|
+
- Created issue ID(s) from the MCP response
|
|
162
|
+
- Any additional context gathered during requirement gathering phase
|
|
163
|
+
|
|
164
|
+
**Call the verifier:**
|
|
165
|
+
|
|
166
|
+
```
|
|
167
|
+
Verify the created project for completeness and correctness:
|
|
168
|
+
- Original requirements: [Include the original $ARGUMENTS specifications]
|
|
169
|
+
- Created issue ID(s): [issue-id from MCP response]
|
|
170
|
+
- Additional context: [Include any clarifications, decisions, or requirements gathered during the interactive Q&A phase]
|
|
171
|
+
```
|
|
172
|
+
|
|
173
|
+
**Review verification results:**
|
|
174
|
+
|
|
175
|
+
- If verdict is `APPROVED`: Proceed to output format
|
|
176
|
+
- If verdict is `NEEDS REVISION`: Evaluate the feedback and, if applicable, update the project using MCP based on recommendations
|
|
177
|
+
- If verdict is `REJECTED`: Evaluate the feedback and, if applicable, recreate the project addressing critical issues
|
|
178
|
+
|
|
179
|
+
If you're not 100% sure of the correctness of the feedback, **STOP** and ask the user for clarification.
|
|
180
|
+
|
|
181
|
+
### 7. Output Format
|
|
182
|
+
|
|
183
|
+
After successful creation:
|
|
184
|
+
|
|
185
|
+
```
|
|
186
|
+
✅ Successfully created [N] tasks for feature "[Feature Title]"
|
|
187
|
+
|
|
188
|
+
📋 Created Tasks:
|
|
189
|
+
Database & Models:
|
|
190
|
+
✓ T-[id1]: Create user database model with validation and unit tests
|
|
191
|
+
✓ T-[id2]: Add email verification token system with tests and docs
|
|
192
|
+
|
|
193
|
+
API Development:
|
|
194
|
+
✓ T-[id3]: Create POST /api/register endpoint with tests and validation
|
|
195
|
+
✓ T-[id4]: Implement email verification endpoint with tests
|
|
196
|
+
✓ T-[id5]: Add rate limiting with monitoring and tests
|
|
197
|
+
|
|
198
|
+
Frontend:
|
|
199
|
+
✓ T-[id6]: Create registration form component with tests and error handling
|
|
200
|
+
✓ T-[id7]: Add client-side validation with unit tests
|
|
201
|
+
✓ T-[id8]: Implement success/error states with component tests
|
|
202
|
+
|
|
203
|
+
Integration:
|
|
204
|
+
✓ T-[id9]: Write end-to-end integration tests for full registration flow
|
|
205
|
+
|
|
206
|
+
📊 Task Summary:
|
|
207
|
+
- Total Tasks: [N]
|
|
208
|
+
- High Priority: [X]
|
|
209
|
+
```
|
|
210
|
+
|
|
211
|
+
## Task Creation Guidelines
|
|
212
|
+
|
|
213
|
+
Ensure tasks are:
|
|
214
|
+
|
|
215
|
+
- **Atomic**: Completable in one sitting (1-2 hours)
|
|
216
|
+
- **Specific**: Clear implementation path
|
|
217
|
+
- **Testable**: Defined acceptance criteria. Include instructions for writing unit tests in the same tasks as writing the production code. Integration tests should be in separate tasks.
|
|
218
|
+
- **Independent**: Minimal coupling where possible
|
|
219
|
+
- **Secure**: Include necessary validations
|
|
220
|
+
|
|
221
|
+
Common task patterns:
|
|
222
|
+
|
|
223
|
+
- **Model/Schema**: Create with validation, indexing, unit tests, and docs
|
|
224
|
+
- **API Endpoint**: Implement with input validation, error handling, tests, and docs
|
|
225
|
+
- **Frontend Component**: Create with interactivity, state handling, tests, and docs
|
|
226
|
+
- **Security**: Input validation, authorization, rate limiting with tests and docs
|
|
227
|
+
|
|
228
|
+
## Question Guidelines
|
|
229
|
+
|
|
230
|
+
Ask questions that:
|
|
231
|
+
|
|
232
|
+
- **Clarify implementation**: Specific libraries or approaches?
|
|
233
|
+
- **Define boundaries**: What's included in each task?
|
|
234
|
+
- **Identify prerequisites**: What must be built first?
|
|
235
|
+
- **Confirm testing strategy**: What types of tests are needed?
|
|
236
|
+
|
|
237
|
+
## Priority Assignment
|
|
238
|
+
|
|
239
|
+
Assign priorities based on:
|
|
240
|
+
|
|
241
|
+
- **High**: Blocking other work, security-critical, core functionality
|
|
242
|
+
- **Medium**: Standard implementation tasks
|
|
243
|
+
- **Low**: Enhancements, optimizations, nice-to-have features
|
|
244
|
+
|
|
245
|
+
<rules>
|
|
246
|
+
<critical>Use MCP tools for all operations (create_issue, get_issue, etc.)</critical>
|
|
247
|
+
<critical>Each task must be completable in 1-2 hours</critical>
|
|
248
|
+
<critical>Ask one question at a time with specific options</critical>
|
|
249
|
+
<critical>Continue asking questions until you have complete understanding of task boundaries</critical>
|
|
250
|
+
<important>Include testing and documentation within implementation tasks</important>
|
|
251
|
+
<important>Add security validation with tests where applicable</important>
|
|
252
|
+
</rules>
|