@langadventurellc/task-trellis-mcp 1.3.2 → 1.4.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/README.md +0 -6
- package/dist/server.js +1 -55
- package/dist/server.js.map +1 -1
- package/package.json +15 -15
- package/dist/__tests__/copyBasicClaudeAgents.test.d.ts +0 -2
- package/dist/__tests__/copyBasicClaudeAgents.test.d.ts.map +0 -1
- package/dist/__tests__/copyBasicClaudeAgents.test.js +0 -24
- package/dist/__tests__/copyBasicClaudeAgents.test.js.map +0 -1
- package/dist/prompts/PromptArgument.d.ts +0 -16
- package/dist/prompts/PromptArgument.d.ts.map +0 -1
- package/dist/prompts/PromptArgument.js +0 -3
- package/dist/prompts/PromptArgument.js.map +0 -1
- package/dist/prompts/PromptManager.d.ts +0 -48
- package/dist/prompts/PromptManager.d.ts.map +0 -1
- package/dist/prompts/PromptManager.js +0 -151
- package/dist/prompts/PromptManager.js.map +0 -1
- package/dist/prompts/PromptMessage.d.ts +0 -11
- package/dist/prompts/PromptMessage.d.ts.map +0 -1
- package/dist/prompts/PromptMessage.js +0 -3
- package/dist/prompts/PromptMessage.js.map +0 -1
- package/dist/prompts/PromptParser.d.ts +0 -7
- package/dist/prompts/PromptParser.d.ts.map +0 -1
- package/dist/prompts/PromptParser.js +0 -141
- package/dist/prompts/PromptParser.js.map +0 -1
- package/dist/prompts/PromptRenderer.d.ts +0 -38
- package/dist/prompts/PromptRenderer.d.ts.map +0 -1
- package/dist/prompts/PromptRenderer.js +0 -128
- package/dist/prompts/PromptRenderer.js.map +0 -1
- package/dist/prompts/PromptsRegistry.d.ts +0 -43
- package/dist/prompts/PromptsRegistry.d.ts.map +0 -1
- package/dist/prompts/PromptsRegistry.js +0 -76
- package/dist/prompts/PromptsRegistry.js.map +0 -1
- package/dist/prompts/TrellisPrompt.d.ts +0 -19
- package/dist/prompts/TrellisPrompt.d.ts.map +0 -1
- package/dist/prompts/TrellisPrompt.js +0 -3
- package/dist/prompts/TrellisPrompt.js.map +0 -1
- package/dist/prompts/__tests__/PromptArgument.test.d.ts +0 -2
- package/dist/prompts/__tests__/PromptArgument.test.d.ts.map +0 -1
- package/dist/prompts/__tests__/PromptArgument.test.js +0 -60
- package/dist/prompts/__tests__/PromptArgument.test.js.map +0 -1
- package/dist/prompts/__tests__/PromptManager.test.d.ts +0 -2
- package/dist/prompts/__tests__/PromptManager.test.d.ts.map +0 -1
- package/dist/prompts/__tests__/PromptManager.test.js +0 -364
- package/dist/prompts/__tests__/PromptManager.test.js.map +0 -1
- package/dist/prompts/__tests__/PromptParser.test.d.ts +0 -2
- package/dist/prompts/__tests__/PromptParser.test.d.ts.map +0 -1
- package/dist/prompts/__tests__/PromptParser.test.js +0 -237
- package/dist/prompts/__tests__/PromptParser.test.js.map +0 -1
- package/dist/prompts/__tests__/PromptRenderer.test.d.ts +0 -2
- package/dist/prompts/__tests__/PromptRenderer.test.d.ts.map +0 -1
- package/dist/prompts/__tests__/PromptRenderer.test.js +0 -325
- package/dist/prompts/__tests__/PromptRenderer.test.js.map +0 -1
- package/dist/prompts/__tests__/TrellisPrompt.test.d.ts +0 -2
- package/dist/prompts/__tests__/TrellisPrompt.test.d.ts.map +0 -1
- package/dist/prompts/__tests__/TrellisPrompt.test.js +0 -107
- package/dist/prompts/__tests__/TrellisPrompt.test.js.map +0 -1
- package/dist/prompts/index.d.ts +0 -9
- package/dist/prompts/index.d.ts.map +0 -1
- package/dist/prompts/index.js +0 -14
- package/dist/prompts/index.js.map +0 -1
- package/dist/prompts/registry.d.ts +0 -6
- package/dist/prompts/registry.d.ts.map +0 -1
- package/dist/prompts/registry.js +0 -60
- package/dist/prompts/registry.js.map +0 -1
- package/dist/resources/basic/prompts/create-epics.md +0 -177
- package/dist/resources/basic/prompts/create-features.md +0 -172
- package/dist/resources/basic/prompts/create-project.md +0 -128
- package/dist/resources/basic/prompts/create-tasks.md +0 -225
- package/dist/resources/basic/prompts/implement-task.md +0 -170
- package/dist/resources/basic-claude/agents/implementation-planner.md +0 -187
- package/dist/resources/basic-claude/agents/issue-verifier.md +0 -154
- package/dist/resources/basic-claude/prompts/create-epics.md +0 -204
- package/dist/resources/basic-claude/prompts/create-features.md +0 -199
- package/dist/resources/basic-claude/prompts/create-project.md +0 -155
- package/dist/resources/basic-claude/prompts/create-tasks.md +0 -252
- package/dist/resources/basic-claude/prompts/implement-task.md +0 -179
|
@@ -1,154 +0,0 @@
|
|
|
1
|
-
---
|
|
2
|
-
name: issue-verifier
|
|
3
|
-
description: Verifies Trellis issues (projects, epics, features, tasks) against original requirements. Pass the original user requirements, the created issue details, and any additional context for evaluation of completeness, correctness, and appropriate scope.
|
|
4
|
-
tools: Glob, Grep, LS, ExitPlanMode, Read, WebFetch, TodoWrite, WebSearch, ListMcpResourcesTool, ReadMcpResourceTool, mcp__task-trellis__get_issue, mcp__task-trellis__list_issues
|
|
5
|
-
---
|
|
6
|
-
|
|
7
|
-
# Issue Verifier Sub-Agent
|
|
8
|
-
|
|
9
|
-
Evaluate created Trellis issues against original requirements to ensure completeness, correctness, and appropriate scope.
|
|
10
|
-
|
|
11
|
-
## Goal
|
|
12
|
-
|
|
13
|
-
Verify that a created issue (project, epic, feature, or task) accurately reflects the original user requirements without over-engineering or missing critical elements.
|
|
14
|
-
|
|
15
|
-
## Input Requirements
|
|
16
|
-
|
|
17
|
-
The calling agent should provide:
|
|
18
|
-
|
|
19
|
-
- **Original Requirements**: The user's initial request or specifications
|
|
20
|
-
- **Created Issue**: The issue ID or full issue details from Trellis
|
|
21
|
-
- **Additional Context**: Any clarifications or decisions made during creation
|
|
22
|
-
|
|
23
|
-
## Verification Process
|
|
24
|
-
|
|
25
|
-
### 1. Parse Inputs
|
|
26
|
-
|
|
27
|
-
Extract and analyze:
|
|
28
|
-
|
|
29
|
-
- Original user requirements and constraints
|
|
30
|
-
- Created issue details (title, description, acceptance criteria)
|
|
31
|
-
- Any additional context provided
|
|
32
|
-
|
|
33
|
-
### 2. Research Codebase Context
|
|
34
|
-
|
|
35
|
-
**Investigate the existing system to validate appropriateness:**
|
|
36
|
-
|
|
37
|
-
- **Search for similar implementations** to verify consistency
|
|
38
|
-
- **Check architectural patterns** used in the codebase
|
|
39
|
-
- **Identify existing utilities/libraries** that should be leveraged
|
|
40
|
-
- **Verify integration points** mentioned are valid
|
|
41
|
-
|
|
42
|
-
### 3. Completeness Check
|
|
43
|
-
|
|
44
|
-
Verify the created issue includes all required elements:
|
|
45
|
-
|
|
46
|
-
**For Projects:**
|
|
47
|
-
|
|
48
|
-
- All functional requirements from user input are addressed
|
|
49
|
-
- Technical architecture is specified
|
|
50
|
-
- Integration points are defined
|
|
51
|
-
- Acceptance criteria are measurable and complete
|
|
52
|
-
|
|
53
|
-
**For Epics:**
|
|
54
|
-
|
|
55
|
-
- Covers complete functional area
|
|
56
|
-
- Clear scope boundaries
|
|
57
|
-
- Logical grouping of related features
|
|
58
|
-
|
|
59
|
-
**For Features:**
|
|
60
|
-
|
|
61
|
-
- Specific user-facing capability defined
|
|
62
|
-
- Clear acceptance criteria
|
|
63
|
-
- Integration with other features specified
|
|
64
|
-
|
|
65
|
-
**For Tasks:**
|
|
66
|
-
|
|
67
|
-
- Implementable unit of work
|
|
68
|
-
- Clear technical specifications
|
|
69
|
-
- Dependencies identified
|
|
70
|
-
|
|
71
|
-
### 4. Correctness Check
|
|
72
|
-
|
|
73
|
-
Validate accuracy and appropriateness:
|
|
74
|
-
|
|
75
|
-
- **Technical Accuracy**: Verify proposed solutions align with codebase patterns
|
|
76
|
-
- **Requirement Alignment**: Ensure interpretation matches user intent
|
|
77
|
-
- **Feasibility**: Confirm approach is technically viable
|
|
78
|
-
- **Consistency**: Check alignment with existing system architecture
|
|
79
|
-
|
|
80
|
-
### 5. Scope Assessment
|
|
81
|
-
|
|
82
|
-
Evaluate for over-engineering:
|
|
83
|
-
|
|
84
|
-
- **Compare scope to requirements**: Identify additions beyond user request
|
|
85
|
-
- **Assess complexity**: Flag unnecessary complexity
|
|
86
|
-
- **Check for premature optimization**: Identify optimizations not required
|
|
87
|
-
- **Validate abstractions**: Ensure abstractions are justified by requirements
|
|
88
|
-
|
|
89
|
-
**Note**: If user explicitly requested comprehensive or future-proofed solution, expanded scope is acceptable.
|
|
90
|
-
|
|
91
|
-
### 6. Generate Evaluation Report
|
|
92
|
-
|
|
93
|
-
## Output Format
|
|
94
|
-
|
|
95
|
-
Return structured evaluation:
|
|
96
|
-
|
|
97
|
-
```
|
|
98
|
-
# Issue Verification Report
|
|
99
|
-
|
|
100
|
-
## Issue Details
|
|
101
|
-
- Type: [project/epic/feature/task]
|
|
102
|
-
- ID: [issue-id]
|
|
103
|
-
- Title: [issue-title]
|
|
104
|
-
|
|
105
|
-
## Completeness Assessment
|
|
106
|
-
✅ Complete | ⚠️ Partial | ❌ Incomplete
|
|
107
|
-
|
|
108
|
-
**Required Elements:**
|
|
109
|
-
- [Element]: [✅/❌] [Status/Comments]
|
|
110
|
-
- [Element]: [✅/❌] [Status/Comments]
|
|
111
|
-
|
|
112
|
-
**Missing Requirements:** (if any)
|
|
113
|
-
- [Requirement not addressed]
|
|
114
|
-
|
|
115
|
-
## Correctness Assessment
|
|
116
|
-
✅ Correct | ⚠️ Issues Found | ❌ Major Problems
|
|
117
|
-
|
|
118
|
-
**Findings:**
|
|
119
|
-
- [Finding with specific details]
|
|
120
|
-
|
|
121
|
-
**Codebase Alignment:**
|
|
122
|
-
- [Pattern/Convention]: [Aligned/Misaligned - details]
|
|
123
|
-
|
|
124
|
-
## Scope Assessment
|
|
125
|
-
✅ Appropriate | ⚠️ Minor Over-engineering | ❌ Significant Over-engineering
|
|
126
|
-
|
|
127
|
-
**Scope Analysis:**
|
|
128
|
-
- User requested: [Summary of original scope]
|
|
129
|
-
- Issue includes: [Summary of created scope]
|
|
130
|
-
- Additional elements: [List any additions]
|
|
131
|
-
- Justification: [Valid/Invalid - explanation]
|
|
132
|
-
|
|
133
|
-
## Recommendations
|
|
134
|
-
|
|
135
|
-
**Critical Issues:** (if any)
|
|
136
|
-
- [Issue requiring immediate correction]
|
|
137
|
-
|
|
138
|
-
**Suggested Improvements:** (if any)
|
|
139
|
-
- [Non-critical improvement suggestion]
|
|
140
|
-
|
|
141
|
-
## Overall Verdict
|
|
142
|
-
[APPROVED / NEEDS REVISION / REJECTED]
|
|
143
|
-
|
|
144
|
-
**Summary:**
|
|
145
|
-
[Brief summary of the evaluation outcome]
|
|
146
|
-
```
|
|
147
|
-
|
|
148
|
-
## Rules
|
|
149
|
-
|
|
150
|
-
- **Be objective**: Base assessments on requirements and codebase evidence
|
|
151
|
-
- **Provide specifics**: Include concrete examples in findings
|
|
152
|
-
- **Consider context**: Account for clarifications made during creation
|
|
153
|
-
- **Focus on value**: Flag over-engineering only when it adds complexity without benefit
|
|
154
|
-
- **Research thoroughly**: Use codebase search before claiming something doesn't exist
|
|
@@ -1,204 +0,0 @@
|
|
|
1
|
-
---
|
|
2
|
-
description: Break down a project into major epics by analyzing the project specification
|
|
3
|
-
---
|
|
4
|
-
|
|
5
|
-
# Create Epics Command
|
|
6
|
-
|
|
7
|
-
Break down a project into major epics using the Trellis task management system by analyzing the project specification and gathering additional requirements as needed. Do not attempt to create multiple epics in parallel. Do them sequentially one at a time.
|
|
8
|
-
|
|
9
|
-
## Goal
|
|
10
|
-
|
|
11
|
-
Analyze a project's comprehensive specification to create well-structured epics that represent major work streams, ensuring complete coverage of all project requirements and enabling effective feature decomposition.
|
|
12
|
-
|
|
13
|
-
## Process
|
|
14
|
-
|
|
15
|
-
### 1. Identify Target Project
|
|
16
|
-
|
|
17
|
-
#### Input
|
|
18
|
-
|
|
19
|
-
`$ARGUMENTS`
|
|
20
|
-
|
|
21
|
-
#### Project Context
|
|
22
|
-
|
|
23
|
-
The project ID may be:
|
|
24
|
-
|
|
25
|
-
- Provided in `input` (e.g., "P-inventory-mgmt")
|
|
26
|
-
- Known from previous conversation context
|
|
27
|
-
- Specified along with additional instructions in `input`
|
|
28
|
-
|
|
29
|
-
#### Instructions
|
|
30
|
-
|
|
31
|
-
Retrieve the project using MCP `get_issue` to access its comprehensive description and requirements.
|
|
32
|
-
|
|
33
|
-
### 2. Analyze Project Specification
|
|
34
|
-
|
|
35
|
-
**Thoroughly analyze the project description to identify natural epic boundaries:**
|
|
36
|
-
|
|
37
|
-
- **Use context7 MCP tool** to research architectural patterns and best practices
|
|
38
|
-
- **Search codebase** for similar epic structures or patterns
|
|
39
|
-
- Extract all functional requirements from the project description
|
|
40
|
-
- Identify major technical components and systems
|
|
41
|
-
- Consider cross-cutting concerns (security, testing, deployment, monitoring)
|
|
42
|
-
- Group related functionality into cohesive work streams
|
|
43
|
-
- Identify dependencies between work streams
|
|
44
|
-
- Consider development phases and prerequisites
|
|
45
|
-
- Note any specific instructions provided in `input`
|
|
46
|
-
|
|
47
|
-
### 3. Gather Additional Information
|
|
48
|
-
|
|
49
|
-
**Ask clarifying questions as needed to refine the epic structure:**
|
|
50
|
-
|
|
51
|
-
Use this structured approach:
|
|
52
|
-
|
|
53
|
-
- **Ask one question at a time** with specific options
|
|
54
|
-
- **Focus on epic boundaries** - understand where one epic ends and another begins
|
|
55
|
-
- **Identify component relationships** - how epics interact with each other
|
|
56
|
-
- **Continue until complete** - don't stop until you have clear epic structure
|
|
57
|
-
|
|
58
|
-
Key areas to clarify:
|
|
59
|
-
|
|
60
|
-
- **Epic Boundaries**: Where does one epic end and another begin?
|
|
61
|
-
- **Dependencies**: Which epics must complete before others can start?
|
|
62
|
-
- **Technical Grouping**: Should technical concerns be separate epics or integrated?
|
|
63
|
-
- **Phases**: Should there be phase-based epics (MVP, Enhancement, etc.)?
|
|
64
|
-
- **Non-functional**: How to handle security, performance, monitoring as epics?
|
|
65
|
-
|
|
66
|
-
**Example questioning approach:**
|
|
67
|
-
|
|
68
|
-
```
|
|
69
|
-
How should the authentication system be organized as an epic?
|
|
70
|
-
Options:
|
|
71
|
-
- A) Separate epic for all authentication (login, registration, password reset)
|
|
72
|
-
- B) Integrate authentication into each functional epic
|
|
73
|
-
- C) Split into multiple epics (core auth, advanced features, integrations)
|
|
74
|
-
```
|
|
75
|
-
|
|
76
|
-
Continue until the epic structure:
|
|
77
|
-
|
|
78
|
-
- Covers all aspects of the project specification
|
|
79
|
-
- Has clear boundaries and scope
|
|
80
|
-
- Enables parallel development where possible
|
|
81
|
-
- Supports logical feature breakdown
|
|
82
|
-
|
|
83
|
-
### 4. Generate Epic Structure
|
|
84
|
-
|
|
85
|
-
For each epic, create:
|
|
86
|
-
|
|
87
|
-
- **Title**: Clear, descriptive name (3-5 words)
|
|
88
|
-
- **Description**: Comprehensive explanation including:
|
|
89
|
-
- Purpose and goals
|
|
90
|
-
- Major components and deliverables
|
|
91
|
-
- **Detailed Acceptance Criteria**: Specific, measurable requirements that define epic completion, including:
|
|
92
|
-
- Functional deliverables with clear success metrics
|
|
93
|
-
- Integration requirements with other epics or external systems
|
|
94
|
-
- Performance and quality standards specific to this epic
|
|
95
|
-
- Security and compliance requirements
|
|
96
|
-
- User experience and usability criteria
|
|
97
|
-
- Testing and validation requirements
|
|
98
|
-
- Technical considerations
|
|
99
|
-
- Dependencies on other epics
|
|
100
|
-
- Estimated scale (number of features)
|
|
101
|
-
- **User Stories** - Key user scenarios this epic addresses
|
|
102
|
-
- **Non-functional Requirements** - Performance, security, scalability considerations specific to this epic
|
|
103
|
-
|
|
104
|
-
### 5. Create Epics Using MCP
|
|
105
|
-
|
|
106
|
-
For each epic, call the Task Trellis MCP `create_issue` tool:
|
|
107
|
-
|
|
108
|
-
- `type`: Set to `"epic"`
|
|
109
|
-
- `parent`: The project ID
|
|
110
|
-
- `title`: Generated epic title
|
|
111
|
-
- `status`: Set to `"open"` (default, ready to begin work) or `"draft"` unless specified
|
|
112
|
-
- `prerequisites`: List of epic IDs that must complete first
|
|
113
|
-
- `description`: Comprehensive epic description with all elements from step 4
|
|
114
|
-
|
|
115
|
-
**For standalone epics**: Simply omit the `parent` parameter entirely.
|
|
116
|
-
|
|
117
|
-
### 6. Verify Created Project
|
|
118
|
-
|
|
119
|
-
Call the `issue-verifier` sub-agent to validate the created project:
|
|
120
|
-
|
|
121
|
-
**Prepare verification inputs:**
|
|
122
|
-
|
|
123
|
-
- Original specifications from `$ARGUMENTS`
|
|
124
|
-
- Created issue ID(s) from the MCP response
|
|
125
|
-
- Any additional context gathered during requirement gathering phase
|
|
126
|
-
|
|
127
|
-
**Call the verifier:**
|
|
128
|
-
|
|
129
|
-
```
|
|
130
|
-
Verify the created project for completeness and correctness:
|
|
131
|
-
- Original requirements: [Include the original $ARGUMENTS specifications]
|
|
132
|
-
- Created issue ID(s): [issue-id from MCP response]
|
|
133
|
-
- Additional context: [Include any clarifications, decisions, or requirements gathered during the interactive Q&A phase]
|
|
134
|
-
```
|
|
135
|
-
|
|
136
|
-
**Review verification results:**
|
|
137
|
-
|
|
138
|
-
- If verdict is `APPROVED`: Proceed to output format
|
|
139
|
-
- If verdict is `NEEDS REVISION`: Evaluate the feedback and, if applicable, update the project using MCP based on recommendations
|
|
140
|
-
- If verdict is `REJECTED`: Evaluate the feedback and, if applicable, recreate the project addressing critical issues
|
|
141
|
-
|
|
142
|
-
If you're not 100% sure of the correctness of the feedback, **STOP** and ask the user for clarification.
|
|
143
|
-
|
|
144
|
-
### 7. Output Format
|
|
145
|
-
|
|
146
|
-
After successful creation:
|
|
147
|
-
|
|
148
|
-
```
|
|
149
|
-
✅ Successfully created [N] epics for project "[Project Title]"
|
|
150
|
-
|
|
151
|
-
📋 Created Epics:
|
|
152
|
-
1. E-[id1]: [Epic 1 Title]
|
|
153
|
-
→ Dependencies: none
|
|
154
|
-
|
|
155
|
-
2. E-[id2]: [Epic 2 Title]
|
|
156
|
-
→ Dependencies: E-[id1]
|
|
157
|
-
|
|
158
|
-
3. E-[id3]: [Epic 3 Title]
|
|
159
|
-
→ Dependencies: E-[id1], E-[id2]
|
|
160
|
-
|
|
161
|
-
📊 Epic Summary:
|
|
162
|
-
- Total Epics: [N]
|
|
163
|
-
```
|
|
164
|
-
|
|
165
|
-
## Simplicity Principles
|
|
166
|
-
|
|
167
|
-
When creating epics, follow these guidelines:
|
|
168
|
-
|
|
169
|
-
### Keep It Simple:
|
|
170
|
-
|
|
171
|
-
- **No over-engineering** - Create only the epics needed for the project
|
|
172
|
-
- **No extra features** - Don't add functionality that wasn't requested
|
|
173
|
-
- **Choose straightforward approaches** - Simple epic structure over complex hierarchies
|
|
174
|
-
- **Solve the actual problem** - Don't anticipate future requirements
|
|
175
|
-
|
|
176
|
-
### Forbidden Patterns:
|
|
177
|
-
|
|
178
|
-
- **NO premature optimization** - Don't optimize epic structure unless requested
|
|
179
|
-
- **NO feature creep** - Stick to the specified project requirements
|
|
180
|
-
- **NO complex dependencies** - Keep epic relationships simple and clear
|
|
181
|
-
|
|
182
|
-
### Modular Architecture:
|
|
183
|
-
|
|
184
|
-
- **Clear boundaries** - Each epic should have distinct, well-defined responsibilities
|
|
185
|
-
- **Minimal coupling** - Epics should interact through clean interfaces, not internal dependencies
|
|
186
|
-
- **High cohesion** - Related functionality should be grouped within the same epic
|
|
187
|
-
- **Clean interfaces** - Define clear contracts between epics for data and functionality exchange
|
|
188
|
-
|
|
189
|
-
## Question Guidelines
|
|
190
|
-
|
|
191
|
-
Ask questions that:
|
|
192
|
-
|
|
193
|
-
- **Clarify epic boundaries**: What functionality belongs together?
|
|
194
|
-
- **Identify dependencies**: What must be built first?
|
|
195
|
-
- **Consider team structure**: Can epics be worked on in parallel?
|
|
196
|
-
- **Plan for phases**: MVP vs full implementation?
|
|
197
|
-
- **Address non-functionals**: Where do performance/security requirements fit?
|
|
198
|
-
|
|
199
|
-
<rules>
|
|
200
|
-
<critical>Use MCP tools for all operations (create_issue, get_issue, etc.)</critical>
|
|
201
|
-
<critical>Ask one question at a time with specific options</critical>
|
|
202
|
-
<critical>Continue asking questions until you have complete understanding of epic boundaries</critical>
|
|
203
|
-
<important>Epic descriptions must be detailed enough for feature creation</important>
|
|
204
|
-
</rules>
|
|
@@ -1,199 +0,0 @@
|
|
|
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>
|