@codemcp/workflows-core 3.1.21 → 3.2.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/package.json +9 -5
- package/resources/templates/architecture/arc42/arc42-template-EN.md +1077 -0
- package/resources/templates/architecture/arc42/images/01_2_iso-25010-topics-EN.drawio-2023.png +0 -0
- package/resources/templates/architecture/arc42/images/01_2_iso-25010-topics-EN.drawio.png +0 -0
- package/resources/templates/architecture/arc42/images/05_building_blocks-EN.png +0 -0
- package/resources/templates/architecture/arc42/images/08-concepts-EN.drawio.png +0 -0
- package/resources/templates/architecture/arc42/images/arc42-logo.png +0 -0
- package/resources/templates/architecture/c4.md +224 -0
- package/resources/templates/architecture/freestyle.md +53 -0
- package/resources/templates/architecture/none.md +17 -0
- package/resources/templates/design/comprehensive.md +207 -0
- package/resources/templates/design/freestyle.md +37 -0
- package/resources/templates/design/none.md +17 -0
- package/resources/templates/requirements/ears.md +90 -0
- package/resources/templates/requirements/freestyle.md +42 -0
- package/resources/templates/requirements/none.md +17 -0
- package/resources/workflows/big-bang-conversion.yaml +539 -0
- package/resources/workflows/boundary-testing.yaml +334 -0
- package/resources/workflows/bugfix.yaml +185 -0
- package/resources/workflows/business-analysis.yaml +671 -0
- package/resources/workflows/c4-analysis.yaml +485 -0
- package/resources/workflows/epcc.yaml +161 -0
- package/resources/workflows/greenfield.yaml +189 -0
- package/resources/workflows/minor.yaml +127 -0
- package/resources/workflows/posts.yaml +207 -0
- package/resources/workflows/slides.yaml +256 -0
- package/resources/workflows/tdd.yaml +157 -0
- package/resources/workflows/waterfall.yaml +195 -0
- package/.turbo/turbo-build.log +0 -4
- package/src/config-manager.ts +0 -96
- package/src/conversation-manager.ts +0 -489
- package/src/database.ts +0 -427
- package/src/file-detection-manager.ts +0 -302
- package/src/git-manager.ts +0 -64
- package/src/index.ts +0 -28
- package/src/instruction-generator.ts +0 -210
- package/src/interaction-logger.ts +0 -109
- package/src/logger.ts +0 -353
- package/src/path-validation-utils.ts +0 -261
- package/src/plan-manager.ts +0 -323
- package/src/project-docs-manager.ts +0 -523
- package/src/state-machine-loader.ts +0 -365
- package/src/state-machine-types.ts +0 -72
- package/src/state-machine.ts +0 -370
- package/src/system-prompt-generator.ts +0 -122
- package/src/template-manager.ts +0 -328
- package/src/transition-engine.ts +0 -386
- package/src/types.ts +0 -60
- package/src/workflow-manager.ts +0 -606
- package/test/unit/conversation-manager.test.ts +0 -179
- package/test/unit/custom-workflow-loading.test.ts +0 -174
- package/test/unit/directory-linking-and-extensions.test.ts +0 -338
- package/test/unit/file-linking-integration.test.ts +0 -256
- package/test/unit/git-commit-integration.test.ts +0 -91
- package/test/unit/git-manager.test.ts +0 -86
- package/test/unit/install-workflow.test.ts +0 -138
- package/test/unit/instruction-generator.test.ts +0 -247
- package/test/unit/list-workflows-filtering.test.ts +0 -68
- package/test/unit/none-template-functionality.test.ts +0 -224
- package/test/unit/project-docs-manager.test.ts +0 -337
- package/test/unit/state-machine-loader.test.ts +0 -234
- package/test/unit/template-manager.test.ts +0 -217
- package/test/unit/validate-workflow-name.test.ts +0 -150
- package/test/unit/workflow-domain-filtering.test.ts +0 -75
- package/test/unit/workflow-enum-generation.test.ts +0 -92
- package/test/unit/workflow-manager-enhanced-path-resolution.test.ts +0 -369
- package/test/unit/workflow-manager-path-resolution.test.ts +0 -150
- package/test/unit/workflow-migration.test.ts +0 -155
- package/test/unit/workflow-override-by-name.test.ts +0 -116
- package/test/unit/workflow-prioritization.test.ts +0 -38
- package/test/unit/workflow-validation.test.ts +0 -303
- package/test/utils/e2e-test-setup.ts +0 -453
- package/test/utils/run-server-in-dir.sh +0 -27
- package/test/utils/temp-files.ts +0 -308
- package/test/utils/test-access.ts +0 -79
- package/test/utils/test-helpers.ts +0 -286
- package/test/utils/test-setup.ts +0 -78
- package/tsconfig.build.json +0 -21
- package/tsconfig.json +0 -8
- package/vitest.config.ts +0 -18
package/src/state-machine.ts
DELETED
@@ -1,370 +0,0 @@
|
|
1
|
-
/**
|
2
|
-
* State Machine Definition for Vibe Feature MCP Server
|
3
|
-
*
|
4
|
-
* This module defines the development workflow state machine, including:
|
5
|
-
* - Development phases (states)
|
6
|
-
* - Transition triggers and conditions
|
7
|
-
* - Phase-specific instructions for LLM guidance
|
8
|
-
* - Transition-specific prompts for contextual guidance
|
9
|
-
*/
|
10
|
-
|
11
|
-
export type DevelopmentPhase =
|
12
|
-
| 'idle'
|
13
|
-
| 'requirements'
|
14
|
-
| 'design'
|
15
|
-
| 'implementation'
|
16
|
-
| 'qa'
|
17
|
-
| 'testing'
|
18
|
-
| 'complete';
|
19
|
-
|
20
|
-
export type TransitionTrigger =
|
21
|
-
| 'new_feature_request'
|
22
|
-
| 'refine_requirements'
|
23
|
-
| 'requirements_complete'
|
24
|
-
| 'abandon_feature'
|
25
|
-
| 'refine_design'
|
26
|
-
| 'requirements_unclear'
|
27
|
-
| 'design_complete'
|
28
|
-
| 'refine_implementation'
|
29
|
-
| 'design_issues'
|
30
|
-
| 'implementation_complete'
|
31
|
-
| 'refine_qa'
|
32
|
-
| 'implementation_issues'
|
33
|
-
| 'qa_complete'
|
34
|
-
| 'refine_testing'
|
35
|
-
| 'qa_issues'
|
36
|
-
| 'testing_complete'
|
37
|
-
| 'feature_delivered'
|
38
|
-
| 'direct_transition'; // For user-initiated direct phase changes
|
39
|
-
|
40
|
-
export interface StateTransition {
|
41
|
-
from: DevelopmentPhase;
|
42
|
-
to: DevelopmentPhase;
|
43
|
-
trigger: TransitionTrigger;
|
44
|
-
isModeled: boolean; // Whether this transition is shown in the state diagram
|
45
|
-
instructions: string;
|
46
|
-
transitionReason: string;
|
47
|
-
}
|
48
|
-
|
49
|
-
/**
|
50
|
-
* Complete state transition table
|
51
|
-
*
|
52
|
-
* This table defines all possible transitions between development phases.
|
53
|
-
* - Modeled transitions: Shown in the state diagram, get contextual guidance
|
54
|
-
* - Direct transitions: Not shown in diagram, get general phase instructions
|
55
|
-
*/
|
56
|
-
export const STATE_TRANSITIONS: StateTransition[] = [
|
57
|
-
// FROM IDLE
|
58
|
-
{
|
59
|
-
from: 'idle',
|
60
|
-
to: 'requirements',
|
61
|
-
trigger: 'new_feature_request',
|
62
|
-
isModeled: true,
|
63
|
-
instructions:
|
64
|
-
'New feature request detected! Start requirements analysis by asking the user clarifying questions about WHAT they need. Focus on understanding their goals, scope, and constraints. Break down their needs into specific, actionable tasks and document them in the plan file. Mark completed requirements tasks as you progress.',
|
65
|
-
transitionReason:
|
66
|
-
'New feature request detected, starting requirements analysis',
|
67
|
-
},
|
68
|
-
|
69
|
-
// FROM REQUIREMENTS
|
70
|
-
{
|
71
|
-
from: 'requirements',
|
72
|
-
to: 'requirements',
|
73
|
-
trigger: 'refine_requirements',
|
74
|
-
isModeled: true,
|
75
|
-
instructions:
|
76
|
-
'Continue refining requirements. Ask more detailed questions to clarify scope, constraints, and user needs. Add any new requirements to the plan file and mark completed tasks. Ensure you have a complete understanding of WHAT needs to be built before moving to design.',
|
77
|
-
transitionReason: 'Requirements need further refinement and clarification',
|
78
|
-
},
|
79
|
-
{
|
80
|
-
from: 'requirements',
|
81
|
-
to: 'design',
|
82
|
-
trigger: 'requirements_complete',
|
83
|
-
isModeled: true,
|
84
|
-
instructions:
|
85
|
-
'Requirements are complete! ✅ Now transition to design phase. Help the user design the technical solution by asking about architecture, technologies, quality goals, and implementation approach. Focus on HOW to build what was defined in requirements. Document design decisions in the plan file and mark completed requirements tasks.',
|
86
|
-
transitionReason:
|
87
|
-
'All requirements tasks completed, moving to technical design',
|
88
|
-
},
|
89
|
-
{
|
90
|
-
from: 'requirements',
|
91
|
-
to: 'idle',
|
92
|
-
trigger: 'abandon_feature',
|
93
|
-
isModeled: true,
|
94
|
-
instructions:
|
95
|
-
'Feature development abandoned. Clean up any temporary work and return to idle state. The plan file will remain for future reference if the user wants to resume this feature later.',
|
96
|
-
transitionReason: 'User decided to abandon this feature development',
|
97
|
-
},
|
98
|
-
|
99
|
-
// FROM DESIGN
|
100
|
-
{
|
101
|
-
from: 'design',
|
102
|
-
to: 'design',
|
103
|
-
trigger: 'refine_design',
|
104
|
-
isModeled: true,
|
105
|
-
instructions:
|
106
|
-
'Continue refining the technical design. Ask about architecture details, technology choices, data models, API design, and quality considerations. Update the plan file with design decisions and mark completed design tasks. Ensure the design is solid before implementation.',
|
107
|
-
transitionReason: 'Design needs further refinement and detail',
|
108
|
-
},
|
109
|
-
{
|
110
|
-
from: 'design',
|
111
|
-
to: 'requirements',
|
112
|
-
trigger: 'requirements_unclear',
|
113
|
-
isModeled: true,
|
114
|
-
instructions:
|
115
|
-
'Design phase revealed unclear requirements. Return to requirements analysis to clarify the WHAT before continuing with HOW. Ask specific questions about the unclear aspects and update the plan file with refined requirements.',
|
116
|
-
transitionReason:
|
117
|
-
'Design work revealed gaps or ambiguities in requirements',
|
118
|
-
},
|
119
|
-
{
|
120
|
-
from: 'design',
|
121
|
-
to: 'implementation',
|
122
|
-
trigger: 'design_complete',
|
123
|
-
isModeled: true,
|
124
|
-
instructions:
|
125
|
-
'Design is complete! ✅ Now transition to implementation. Guide the user through building the solution following the design. Focus on coding best practices, proper structure, error handling, and basic testing. Update the plan file with implementation progress and mark completed design tasks.',
|
126
|
-
transitionReason: 'Technical design is complete, ready to start building',
|
127
|
-
},
|
128
|
-
{
|
129
|
-
from: 'design',
|
130
|
-
to: 'idle',
|
131
|
-
trigger: 'abandon_feature',
|
132
|
-
isModeled: true,
|
133
|
-
instructions:
|
134
|
-
'Feature development abandoned during design phase. Clean up any design artifacts and return to idle state. The plan file will remain for future reference.',
|
135
|
-
transitionReason: 'User decided to abandon feature during design phase',
|
136
|
-
},
|
137
|
-
|
138
|
-
// FROM IMPLEMENTATION
|
139
|
-
{
|
140
|
-
from: 'implementation',
|
141
|
-
to: 'implementation',
|
142
|
-
trigger: 'refine_implementation',
|
143
|
-
isModeled: true,
|
144
|
-
instructions:
|
145
|
-
'Continue implementation work. Help with coding, debugging, structure improvements, and adding functionality. Follow best practices and ensure code quality. Update the plan file with progress and mark completed implementation tasks.',
|
146
|
-
transitionReason:
|
147
|
-
'Implementation work continues, adding features or improving code',
|
148
|
-
},
|
149
|
-
{
|
150
|
-
from: 'implementation',
|
151
|
-
to: 'design',
|
152
|
-
trigger: 'design_issues',
|
153
|
-
isModeled: true,
|
154
|
-
instructions:
|
155
|
-
"Implementation revealed issues with the design. Return to design phase to address architectural problems or design gaps. Analyze what's not working and revise the technical approach. Update the plan file with design changes.",
|
156
|
-
transitionReason:
|
157
|
-
'Implementation work revealed problems with the current design',
|
158
|
-
},
|
159
|
-
{
|
160
|
-
from: 'implementation',
|
161
|
-
to: 'qa',
|
162
|
-
trigger: 'implementation_complete',
|
163
|
-
isModeled: true,
|
164
|
-
instructions:
|
165
|
-
"Implementation is complete! ✅ Now transition to quality assurance. Take these specific actions:\n\n1. **Syntax Check**: Run syntax checking tools or validate syntax manually\n2. **Build Project**: Build the project to verify it compiles without errors\n3. **Run Linter**: Execute linting tools to ensure code style consistency\n4. **Execute Tests**: Run existing tests to verify functionality\n\nThen conduct a multi-perspective code review:\n- **Security Perspective**: Check for vulnerabilities, input validation, authentication issues\n- **Performance Perspective**: Identify bottlenecks, inefficient algorithms, resource usage\n- **UX Perspective**: Evaluate from the end-user's viewpoint\n- **Maintainability Perspective**: Assess code readability, documentation, future maintenance\n- **Requirement Compliance**: Verify all requirements are properly implemented\n\nUpdate the plan file and mark completed implementation tasks.",
|
166
|
-
transitionReason:
|
167
|
-
'Core implementation is complete, ready for quality review',
|
168
|
-
},
|
169
|
-
{
|
170
|
-
from: 'implementation',
|
171
|
-
to: 'idle',
|
172
|
-
trigger: 'abandon_feature',
|
173
|
-
isModeled: true,
|
174
|
-
instructions:
|
175
|
-
'Feature development abandoned during implementation. Clean up any incomplete code and return to idle state. The plan file and any completed work will remain for future reference.',
|
176
|
-
transitionReason: 'User decided to abandon feature during implementation',
|
177
|
-
},
|
178
|
-
|
179
|
-
// FROM QA (Quality Assurance)
|
180
|
-
{
|
181
|
-
from: 'qa',
|
182
|
-
to: 'qa',
|
183
|
-
trigger: 'refine_qa',
|
184
|
-
isModeled: true,
|
185
|
-
instructions:
|
186
|
-
"Continue quality assurance work. Take these specific actions if not already completed:\n\n1. **Syntax Check**: Run syntax checking tools or validate syntax manually\n2. **Build Project**: Build the project to verify it compiles without errors\n3. **Run Linter**: Execute linting tools to ensure code style consistency\n4. **Execute Tests**: Run existing tests to verify functionality\n\nContinue multi-perspective code review:\n- **Security Perspective**: Check for vulnerabilities, input validation, authentication issues\n- **Performance Perspective**: Identify bottlenecks, inefficient algorithms, resource usage\n- **UX Perspective**: Evaluate from the end-user's viewpoint\n- **Maintainability Perspective**: Assess code readability, documentation, future maintenance\n- **Requirement Compliance**: Verify all requirements are properly implemented\n\nUpdate the plan file with QA progress and mark completed tasks.",
|
187
|
-
transitionReason:
|
188
|
-
'Quality assurance work continues, improving code quality',
|
189
|
-
},
|
190
|
-
{
|
191
|
-
from: 'qa',
|
192
|
-
to: 'implementation',
|
193
|
-
trigger: 'implementation_issues',
|
194
|
-
isModeled: true,
|
195
|
-
instructions:
|
196
|
-
'Quality assurance revealed implementation issues. Return to implementation phase to fix bugs, improve code quality, or add missing functionality. Focus on addressing the specific issues identified during QA review.',
|
197
|
-
transitionReason:
|
198
|
-
'QA review found issues that require implementation changes',
|
199
|
-
},
|
200
|
-
{
|
201
|
-
from: 'qa',
|
202
|
-
to: 'testing',
|
203
|
-
trigger: 'qa_complete',
|
204
|
-
isModeled: true,
|
205
|
-
instructions:
|
206
|
-
'Quality assurance is complete! ✅ Now transition to testing phase. Create comprehensive test plans, write and execute tests, validate feature completeness, and ensure everything works as expected. Update the plan file and mark completed QA tasks.',
|
207
|
-
transitionReason:
|
208
|
-
'Quality assurance is complete, ready for comprehensive testing',
|
209
|
-
},
|
210
|
-
{
|
211
|
-
from: 'qa',
|
212
|
-
to: 'idle',
|
213
|
-
trigger: 'abandon_feature',
|
214
|
-
isModeled: true,
|
215
|
-
instructions:
|
216
|
-
'Feature development abandoned during QA phase. Clean up any QA artifacts and return to idle state. The plan file and completed work will remain for future reference.',
|
217
|
-
transitionReason:
|
218
|
-
'User decided to abandon feature during quality assurance',
|
219
|
-
},
|
220
|
-
|
221
|
-
// FROM TESTING
|
222
|
-
{
|
223
|
-
from: 'testing',
|
224
|
-
to: 'testing',
|
225
|
-
trigger: 'refine_testing',
|
226
|
-
isModeled: true,
|
227
|
-
instructions:
|
228
|
-
'Continue testing work. Create more test cases, improve test coverage, run integration tests, and validate edge cases. Update the plan file with testing progress and mark completed testing tasks.',
|
229
|
-
transitionReason:
|
230
|
-
'Testing work continues, improving coverage and validation',
|
231
|
-
},
|
232
|
-
{
|
233
|
-
from: 'testing',
|
234
|
-
to: 'qa',
|
235
|
-
trigger: 'qa_issues',
|
236
|
-
isModeled: true,
|
237
|
-
instructions:
|
238
|
-
'Testing revealed quality issues. Return to QA phase to address code quality problems, documentation gaps, or requirement compliance issues identified during testing. Focus on the specific QA issues found.',
|
239
|
-
transitionReason:
|
240
|
-
'Testing found issues that require quality assurance attention',
|
241
|
-
},
|
242
|
-
{
|
243
|
-
from: 'testing',
|
244
|
-
to: 'complete',
|
245
|
-
trigger: 'testing_complete',
|
246
|
-
isModeled: true,
|
247
|
-
instructions:
|
248
|
-
'Testing is complete! ✅ The feature is fully implemented, tested, and ready for delivery. Transition to complete state. Summarize what was accomplished and prepare final documentation. Mark all testing tasks as complete.',
|
249
|
-
transitionReason: 'All testing is complete, feature is ready for delivery',
|
250
|
-
},
|
251
|
-
{
|
252
|
-
from: 'testing',
|
253
|
-
to: 'idle',
|
254
|
-
trigger: 'abandon_feature',
|
255
|
-
isModeled: true,
|
256
|
-
instructions:
|
257
|
-
'Feature development abandoned during testing phase. Clean up any testing artifacts and return to idle state. The plan file and completed work will remain for future reference.',
|
258
|
-
transitionReason: 'User decided to abandon feature during testing phase',
|
259
|
-
},
|
260
|
-
|
261
|
-
// FROM COMPLETE
|
262
|
-
{
|
263
|
-
from: 'complete',
|
264
|
-
to: 'idle',
|
265
|
-
trigger: 'feature_delivered',
|
266
|
-
isModeled: true,
|
267
|
-
instructions:
|
268
|
-
'Feature has been delivered successfully! Return to idle state, ready for the next development task. The completed plan file serves as documentation of what was accomplished.',
|
269
|
-
transitionReason: 'Feature delivery complete, returning to idle state',
|
270
|
-
},
|
271
|
-
{
|
272
|
-
from: 'complete',
|
273
|
-
to: 'requirements',
|
274
|
-
trigger: 'new_feature_request',
|
275
|
-
isModeled: true,
|
276
|
-
instructions:
|
277
|
-
'New feature request while previous feature is complete. Start fresh requirements analysis for the new feature. Ask clarifying questions about what they need and create a new development plan.',
|
278
|
-
transitionReason:
|
279
|
-
'New feature request received, starting new development cycle',
|
280
|
-
},
|
281
|
-
];
|
282
|
-
|
283
|
-
/**
|
284
|
-
* Direct transition instructions for non-modeled transitions
|
285
|
-
* These are used when users jump directly to any phase using proceed_to_phase
|
286
|
-
*/
|
287
|
-
export const DIRECT_PHASE_INSTRUCTIONS: Record<DevelopmentPhase, string> = {
|
288
|
-
idle: 'Returned to idle state. Ready to help with new feature development or other tasks.',
|
289
|
-
|
290
|
-
requirements:
|
291
|
-
'Starting requirements analysis. Ask the user clarifying questions about WHAT they need. Focus on understanding their goals, scope, constraints, and success criteria. Break down their needs into specific, actionable tasks and document them in the plan file. Mark completed requirements tasks as you progress.',
|
292
|
-
|
293
|
-
design:
|
294
|
-
"Starting design phase. Help the user design the technical solution by asking about architecture, technologies, data models, API design, and quality goals. Focus on HOW to implement what's needed. Document design decisions in the plan file and ensure the approach is solid before implementation.",
|
295
|
-
|
296
|
-
implementation:
|
297
|
-
'Starting implementation phase. Guide the user through building the solution following best practices. Focus on code structure, error handling, security, and maintainability. Write clean, well-documented code and include basic testing. Update the plan file with implementation progress.',
|
298
|
-
|
299
|
-
qa: "Starting quality assurance phase. Take the following specific actions:\n\n1. **Syntax Check**: Run syntax checking tools or validate syntax manually\n2. **Build Project**: Build the project to verify it compiles without errors\n3. **Run Linter**: Execute linting tools to ensure code style consistency\n4. **Execute Tests**: Run existing tests to verify functionality\n\nThen conduct a multi-perspective code review:\n- **Security Perspective**: Check for vulnerabilities, input validation, authentication issues\n- **Performance Perspective**: Identify bottlenecks, inefficient algorithms, resource usage\n- **UX Perspective**: Evaluate from the end-user's viewpoint\n- **Maintainability Perspective**: Assess code readability, documentation, future maintenance\n- **Requirement Compliance**: Verify all requirements are properly implemented\n\nUpdate the plan file with QA progress and mark completed tasks.",
|
300
|
-
|
301
|
-
testing:
|
302
|
-
'Starting testing phase. Create comprehensive test plans, write and execute tests, validate feature completeness, and ensure everything works as expected. Focus on test coverage, edge cases, integration testing, and user acceptance validation.',
|
303
|
-
|
304
|
-
complete:
|
305
|
-
'Feature development is complete! All phases have been finished successfully. The feature is implemented, tested, and ready for delivery. Summarize what was accomplished and ensure all documentation is finalized.',
|
306
|
-
};
|
307
|
-
|
308
|
-
/**
|
309
|
-
* Get transition instructions for a specific state change
|
310
|
-
*/
|
311
|
-
export function getTransitionInstructions(
|
312
|
-
fromState: DevelopmentPhase,
|
313
|
-
toState: DevelopmentPhase,
|
314
|
-
trigger?: TransitionTrigger
|
315
|
-
): { instructions: string; transitionReason: string; isModeled: boolean } {
|
316
|
-
// Look for a modeled transition first
|
317
|
-
const modeledTransition = STATE_TRANSITIONS.find(
|
318
|
-
t =>
|
319
|
-
t.from === fromState &&
|
320
|
-
t.to === toState &&
|
321
|
-
(trigger ? t.trigger === trigger : true)
|
322
|
-
);
|
323
|
-
|
324
|
-
if (modeledTransition) {
|
325
|
-
return {
|
326
|
-
instructions: modeledTransition.instructions,
|
327
|
-
transitionReason: modeledTransition.transitionReason,
|
328
|
-
isModeled: true,
|
329
|
-
};
|
330
|
-
}
|
331
|
-
|
332
|
-
// Fall back to direct phase instructions
|
333
|
-
return {
|
334
|
-
instructions: DIRECT_PHASE_INSTRUCTIONS[toState],
|
335
|
-
transitionReason: `Direct transition to ${toState} phase`,
|
336
|
-
isModeled: false,
|
337
|
-
};
|
338
|
-
}
|
339
|
-
|
340
|
-
/**
|
341
|
-
* Get all possible transitions from a given state
|
342
|
-
*/
|
343
|
-
export function getPossibleTransitions(
|
344
|
-
fromState: DevelopmentPhase
|
345
|
-
): StateTransition[] {
|
346
|
-
return STATE_TRANSITIONS.filter(t => t.from === fromState);
|
347
|
-
}
|
348
|
-
|
349
|
-
/**
|
350
|
-
* Check if a transition is modeled (shown in state diagram)
|
351
|
-
*/
|
352
|
-
export function isModeledTransition(
|
353
|
-
fromState: DevelopmentPhase,
|
354
|
-
toState: DevelopmentPhase
|
355
|
-
): boolean {
|
356
|
-
return STATE_TRANSITIONS.some(
|
357
|
-
t => t.from === fromState && t.to === toState && t.isModeled
|
358
|
-
);
|
359
|
-
}
|
360
|
-
|
361
|
-
/**
|
362
|
-
* Get phase-specific instructions for continuing work in current phase
|
363
|
-
*/
|
364
|
-
export function getContinuePhaseInstructions(phase: DevelopmentPhase): string {
|
365
|
-
const continueTransition = STATE_TRANSITIONS.find(
|
366
|
-
t => t.from === phase && t.to === phase
|
367
|
-
);
|
368
|
-
|
369
|
-
return continueTransition?.instructions || DIRECT_PHASE_INSTRUCTIONS[phase];
|
370
|
-
}
|
@@ -1,122 +0,0 @@
|
|
1
|
-
/**
|
2
|
-
* System Prompt Generator for Vibe Feature MCP
|
3
|
-
*
|
4
|
-
* Dynamically generates a comprehensive system prompt for LLMs to properly
|
5
|
-
* integrate with the responsible-vibe-mcp server. The prompt is generated from
|
6
|
-
* the actual state machine definition to ensure accuracy and consistency.
|
7
|
-
*/
|
8
|
-
|
9
|
-
import type { YamlStateMachine } from './state-machine-types.js';
|
10
|
-
import { createLogger } from './logger.js';
|
11
|
-
|
12
|
-
const logger = createLogger('SystemPromptGenerator');
|
13
|
-
|
14
|
-
/**
|
15
|
-
* Generate a system prompt for LLM integration
|
16
|
-
* @param stateMachine The state machine definition to use for generating the prompt
|
17
|
-
* @returns The generated system prompt
|
18
|
-
*/
|
19
|
-
export function generateSystemPrompt(stateMachine: YamlStateMachine): string {
|
20
|
-
logger.debug('Generating system prompt from state machine definition', {
|
21
|
-
stateMachineName: stateMachine.name,
|
22
|
-
phaseCount: Object.keys(stateMachine.states).length,
|
23
|
-
});
|
24
|
-
|
25
|
-
return generateSimpleSystemPrompt(stateMachine);
|
26
|
-
}
|
27
|
-
|
28
|
-
/**
|
29
|
-
* Generate a simple system prompt for LLM integration
|
30
|
-
*/
|
31
|
-
function generateSimpleSystemPrompt(_stateMachine: YamlStateMachine): string {
|
32
|
-
logger.debug('Generating system prompt');
|
33
|
-
|
34
|
-
const systemPrompt = `
|
35
|
-
You are an AI assistant that helps users develop software features.
|
36
|
-
You do this by following a structured development process guided by the responsible-vibe-mcp server.
|
37
|
-
|
38
|
-
IMPORTANT: Use responsible-vibe-mcp tools after each user message!
|
39
|
-
|
40
|
-
Use the start_development() to start a new development.
|
41
|
-
|
42
|
-
## Core Workflow
|
43
|
-
|
44
|
-
Each tool call will return a JSON formatted response with an "instructions" field in it. Follow these instructions immediately after you received them.
|
45
|
-
|
46
|
-
1. **Call whats_next() after each user interaction** to get phase-specific instructions
|
47
|
-
2. **Follow the instructions** provided by responsible-vibe-mcp exactly
|
48
|
-
3. **Update the plan file** as directed to maintain project memory
|
49
|
-
4. **Mark completed tasks** with [x] when instructed
|
50
|
-
5. **Provide conversation context** in each whats_next() call
|
51
|
-
|
52
|
-
## Development Workflow
|
53
|
-
|
54
|
-
The responsible-vibe-mcp server will guide you through development phases specific to the chosen workflow. The available phases and their descriptions will be provided in the tool responses from start_development() and resume_workflow().
|
55
|
-
|
56
|
-
## Using whats_next()
|
57
|
-
|
58
|
-
After each user interaction, call:
|
59
|
-
|
60
|
-
\`\`\`
|
61
|
-
whats_next({
|
62
|
-
context: "Brief description of current situation",
|
63
|
-
user_input: "User's latest message",
|
64
|
-
conversation_summary: "Summary of conversation progress so far",
|
65
|
-
recent_messages: [
|
66
|
-
{ role: "assistant", content: "Your recent message" },
|
67
|
-
{ role: "user", content: "User's recent response" }
|
68
|
-
]
|
69
|
-
})
|
70
|
-
\`\`\`
|
71
|
-
|
72
|
-
## Phase Transitions
|
73
|
-
|
74
|
-
You can transition to the next phase when the tasks of the current phase were completed and the entrance criteria for the current phase have been met.
|
75
|
-
|
76
|
-
Before suggesting any phase transition:
|
77
|
-
- **Check the plan file** for the "Phase Entrance Criteria" section
|
78
|
-
- **Evaluate current progress** against the defined criteria
|
79
|
-
- **Only suggest transitions** when criteria are clearly met
|
80
|
-
- **Be specific** about which criteria have been satisfied
|
81
|
-
- **Ask the user** whether he agrees that the current phase is complete.
|
82
|
-
|
83
|
-
\`\`\`
|
84
|
-
proceed_to_phase({
|
85
|
-
target_phase: "target_phase_name", // Use phase names from the current workflow
|
86
|
-
reason: "Why you're transitioning"
|
87
|
-
})
|
88
|
-
\`\`\`
|
89
|
-
|
90
|
-
## Plan File Management
|
91
|
-
|
92
|
-
- Add new tasks as they are identified
|
93
|
-
- Mark tasks complete [x] when finished
|
94
|
-
- Document important decisions in the Decisions Log
|
95
|
-
- Keep the structure clean and readable
|
96
|
-
|
97
|
-
## Conversation Context Guidelines
|
98
|
-
|
99
|
-
Since responsible-vibe-mcp operates statelessly, provide:
|
100
|
-
|
101
|
-
- **conversation_summary**: What the user wants, key decisions, progress
|
102
|
-
- **recent_messages**: Last 3-5 relevant exchanges
|
103
|
-
- **context**: Current situation and what you're trying to determine
|
104
|
-
|
105
|
-
Remember: responsible-vibe-mcp guides the development process but relies on you to provide conversation context and follow its instructions precisely.`;
|
106
|
-
|
107
|
-
logger.info('System prompt generated successfully', {
|
108
|
-
promptLength: systemPrompt.length,
|
109
|
-
});
|
110
|
-
|
111
|
-
return systemPrompt;
|
112
|
-
}
|
113
|
-
|
114
|
-
/**
|
115
|
-
* Capitalize phase name for display
|
116
|
-
*/
|
117
|
-
// function capitalizePhase(phase: string): string {
|
118
|
-
// return phase
|
119
|
-
// .split('_')
|
120
|
-
// .map(word => word.charAt(0).toUpperCase() + word.slice(1))
|
121
|
-
// .join(' ');
|
122
|
-
// }
|