@langadventurellc/task-trellis-mcp 1.3.2 → 1.3.3
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 +14 -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,177 +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. Output Format
|
|
118
|
-
|
|
119
|
-
After successful creation:
|
|
120
|
-
|
|
121
|
-
```
|
|
122
|
-
✅ Successfully created [N] epics for project "[Project Title]"
|
|
123
|
-
|
|
124
|
-
📋 Created Epics:
|
|
125
|
-
1. E-[id1]: [Epic 1 Title]
|
|
126
|
-
→ Dependencies: none
|
|
127
|
-
|
|
128
|
-
2. E-[id2]: [Epic 2 Title]
|
|
129
|
-
→ Dependencies: E-[id1]
|
|
130
|
-
|
|
131
|
-
3. E-[id3]: [Epic 3 Title]
|
|
132
|
-
→ Dependencies: E-[id1], E-[id2]
|
|
133
|
-
|
|
134
|
-
📊 Epic Summary:
|
|
135
|
-
- Total Epics: [N]
|
|
136
|
-
```
|
|
137
|
-
|
|
138
|
-
## Simplicity Principles
|
|
139
|
-
|
|
140
|
-
When creating epics, follow these guidelines:
|
|
141
|
-
|
|
142
|
-
### Keep It Simple:
|
|
143
|
-
|
|
144
|
-
- **No over-engineering** - Create only the epics needed for the project
|
|
145
|
-
- **No extra features** - Don't add functionality that wasn't requested
|
|
146
|
-
- **Choose straightforward approaches** - Simple epic structure over complex hierarchies
|
|
147
|
-
- **Solve the actual problem** - Don't anticipate future requirements
|
|
148
|
-
|
|
149
|
-
### Forbidden Patterns:
|
|
150
|
-
|
|
151
|
-
- **NO premature optimization** - Don't optimize epic structure unless requested
|
|
152
|
-
- **NO feature creep** - Stick to the specified project requirements
|
|
153
|
-
- **NO complex dependencies** - Keep epic relationships simple and clear
|
|
154
|
-
|
|
155
|
-
### Modular Architecture:
|
|
156
|
-
|
|
157
|
-
- **Clear boundaries** - Each epic should have distinct, well-defined responsibilities
|
|
158
|
-
- **Minimal coupling** - Epics should interact through clean interfaces, not internal dependencies
|
|
159
|
-
- **High cohesion** - Related functionality should be grouped within the same epic
|
|
160
|
-
- **Clean interfaces** - Define clear contracts between epics for data and functionality exchange
|
|
161
|
-
|
|
162
|
-
## Question Guidelines
|
|
163
|
-
|
|
164
|
-
Ask questions that:
|
|
165
|
-
|
|
166
|
-
- **Clarify epic boundaries**: What functionality belongs together?
|
|
167
|
-
- **Identify dependencies**: What must be built first?
|
|
168
|
-
- **Consider team structure**: Can epics be worked on in parallel?
|
|
169
|
-
- **Plan for phases**: MVP vs full implementation?
|
|
170
|
-
- **Address non-functionals**: Where do performance/security requirements fit?
|
|
171
|
-
|
|
172
|
-
<rules>
|
|
173
|
-
<critical>Use MCP tools for all operations (create_issue, get_issue, etc.)</critical>
|
|
174
|
-
<critical>Ask one question at a time with specific options</critical>
|
|
175
|
-
<critical>Continue asking questions until you have complete understanding of epic boundaries</critical>
|
|
176
|
-
<important>Epic descriptions must be detailed enough for feature creation</important>
|
|
177
|
-
</rules>
|
|
@@ -1,172 +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. Output Format
|
|
137
|
-
|
|
138
|
-
After successful creation:
|
|
139
|
-
|
|
140
|
-
```
|
|
141
|
-
✅ Successfully created [N] features for epic "[Epic Title]"
|
|
142
|
-
|
|
143
|
-
📋 Created Features:
|
|
144
|
-
1. F-[id1]: [Feature 1 Title]
|
|
145
|
-
→ Dependencies: none
|
|
146
|
-
|
|
147
|
-
2. F-[id2]: [Feature 2 Title]
|
|
148
|
-
→ Dependencies: F-[id1]
|
|
149
|
-
|
|
150
|
-
3. F-[id3]: [Feature 3 Title]
|
|
151
|
-
→ Dependencies: F-[id1], F-[id2]
|
|
152
|
-
|
|
153
|
-
📊 Feature Summary:
|
|
154
|
-
- Total Features: [N]
|
|
155
|
-
```
|
|
156
|
-
|
|
157
|
-
## Question Guidelines
|
|
158
|
-
|
|
159
|
-
Ask questions that:
|
|
160
|
-
|
|
161
|
-
- **Define feature scope**: What's included vs excluded?
|
|
162
|
-
- **Clarify technical approach**: Specific technologies or patterns?
|
|
163
|
-
- **Identify dependencies**: Build order and integration points?
|
|
164
|
-
- **Consider testing**: How to verify feature completeness?
|
|
165
|
-
|
|
166
|
-
<rules>
|
|
167
|
-
<critical>Use MCP tools for all operations (create_issue, get_issue, etc.)</critical>
|
|
168
|
-
<critical>Ask one question at a time with specific options</critical>
|
|
169
|
-
<critical>Continue asking questions until you have complete understanding of feature boundaries</critical>
|
|
170
|
-
<important>Feature descriptions must be detailed enough for task creation</important>
|
|
171
|
-
<important>Include implementation guidance and testing requirements</important>
|
|
172
|
-
</rules>
|
|
@@ -1,128 +0,0 @@
|
|
|
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. Output Format
|
|
110
|
-
|
|
111
|
-
After successful creation:
|
|
112
|
-
|
|
113
|
-
```
|
|
114
|
-
✅ Project created successfully!
|
|
115
|
-
|
|
116
|
-
📁 Project: [Generated Title]
|
|
117
|
-
📍 ID: [generated-id]
|
|
118
|
-
📊 Status: [actual-status]
|
|
119
|
-
|
|
120
|
-
📝 Project Summary:
|
|
121
|
-
[First paragraph of description]
|
|
122
|
-
```
|
|
123
|
-
|
|
124
|
-
<rules>
|
|
125
|
-
<critical>Use MCP tools for all operations (create_issue, get_issue, activate, etc.)</critical>
|
|
126
|
-
<critical>Continue asking questions until you have a complete understanding of the requirements</critical>
|
|
127
|
-
<critical>Ask one question at a time with specific options</critical>
|
|
128
|
-
</rules>
|