1pub struct Prompts;
2
3impl Prompts {
4 pub fn parse_prd(phase_content: &str, num_tasks: u32, guidance: Option<&str>) -> String {
5 let guidance_section = guidance
6 .filter(|g| !g.is_empty())
7 .map(|g| {
8 format!(
9 r#"
10## Project Guidance
11
12The following project-specific guidance should inform your task breakdown:
13
14{}
15
16"#,
17 g
18 )
19 })
20 .unwrap_or_default();
21
22 format!(
23 r#"You are a Scrum Master parsing a phase into actionable development tasks.
24{}
25Phase Content:
26{}
27
28Parse this phase into approximately {} discrete, actionable tasks. Return a JSON array of tasks with the following structure:
29
30[
31 {{
32 "title": "Task name (concise, action-oriented)",
33 "description": "What needs to be done (2-3 sentences)",
34 "priority": "high|medium|low",
35 "complexity": <1|2|3|5|8|13|21>,
36 "dependencies": [], // Use 1-indexed task references, e.g., ["1", "2"]. NEVER use "0" - indices start at 1.
37 "agent_type": "fast-builder|builder|reviewer|planner|tester" // Which type of agent is best suited for this task
38 }}
39]
40
41Guidelines:
42- Generate approximately {} tasks (can vary by 1-2 if needed for logical breakdown)
43- Each task should be atomic and independently testable
44- Use Fibonacci complexity scale:
45 * 1 = Trivial (~30 min, e.g., update config value)
46 * 2 = Simple (30m-1h, e.g., add basic validation)
47 * 3 = Moderate (1-2h, e.g., create new API endpoint)
48 * 5 = Complex (2-4h, e.g., integrate third-party service)
49 * 8 = Very Complex (4-8h, e.g., build feature with multiple components)
50 * 13 = Extremely Complex (1 day, SHOULD BE SPLIT)
51 * 21 = Too Large (MUST BE SPLIT - only use if absolutely necessary)
52- Dependencies use 1-indexed task references (first task is "1", NOT "0")
53- NEVER reference task "0" - it does not exist
54- Identify dependencies where tasks must be done in specific order (use task indices, e.g., ["1", "2"])
55- Order tasks logically (foundational work first)
56- Each task should have clear success criteria
57- Assign agent_type based on BOTH task nature AND complexity:
58 * "fast-builder" = Simple implementation tasks with complexity 1-2 (quick code changes, config updates, simple features)
59 * "builder" = Complex implementation tasks with complexity 3+ (multi-file changes, new features, integrations)
60 * "reviewer" = Code review, quality checks, refactoring tasks
61 * "planner" = Design, architecture planning, research tasks
62 * "tester" = Test writing, test automation, validation tasks
63- IMPORTANT: Use "fast-builder" for complexity 1-2 implementation tasks, "builder" for complexity 3+ implementation tasks
64
65Return ONLY the JSON array, no additional explanation."#,
66 guidance_section, phase_content, num_tasks, num_tasks
67 )
68 }
69
70 pub fn analyze_complexity(
71 task_title: &str,
72 task_description: &str,
73 existing_details: Option<&str>,
74 ) -> String {
75 let context = existing_details
76 .map(|d| format!("\nExisting Technical Details:\n{}\n", d))
77 .unwrap_or_default();
78
79 format!(
80 r#"You are analyzing the complexity of a development task.
81
82Task: {}
83Description: {}{}
84
85Analyze this task and provide:
861. A complexity score (1, 2, 3, 5, 8, 13, or 21) using Fibonacci scale
872. A brief reasoning explaining the score
88
89Consider:
90- Technical difficulty and unknowns
91- Number of components/files affected
92- Testing requirements
93- Integration points and dependencies
94- Research needed
95- Edge cases to handle
96
97Complexity Scale:
98- 1 = Trivial (~30 min)
99- 2 = Simple (30m-1h)
100- 3 = Moderate (1-2h)
101- 5 = Complex (2-4h)
102- 8 = Very Complex (4-8h)
103- 13 = Extremely Complex (1 day) - Should be split
104- 21 = Too Large - Must be split
105
106Return a JSON object:
107{{
108 "complexity": <number>,
109 "reasoning": "explanation of the score"
110}}
111
112Return ONLY the JSON object, no additional explanation."#,
113 task_title, task_description, context
114 )
115 }
116
117 pub fn expand_task(
118 task_title: &str,
119 task_description: &str,
120 complexity: u32,
121 existing_details: Option<&str>,
122 recommended_subtasks: usize,
123 guidance: Option<&str>,
124 ) -> String {
125 let context = existing_details
126 .map(|d| format!("\nExisting Technical Details:\n{}\n", d))
127 .unwrap_or_default();
128
129 let guidance_section = guidance
130 .filter(|g| !g.is_empty())
131 .map(|g| {
132 format!(
133 r#"
134## Project Guidance
135
136The following project-specific guidance should inform your subtask breakdown:
137
138{}
139
140"#,
141 g
142 )
143 })
144 .unwrap_or_default();
145
146 format!(
147 r#"You are breaking down a development task into smaller, manageable subtasks.
148{}
149Original Task (Complexity {}): {}
150Description: {}{}
151
152Break this task down into approximately {} subtasks based on its complexity.
153
154Create subtasks that:
155- Are small, focused, and independently completable
156- Are independently testable
157- Have clear dependencies between them
158- Cover all aspects of the original task
159- Maintain logical order
160
161Return a JSON array of subtasks:
162[
163 {{
164 "title": "Subtask name",
165 "description": "What needs to be done",
166 "priority": "high|medium|low",
167 "dependencies": [] // 1-indexed subtask refs: ["1", "2"]. NEVER use "0". External deps: ["TASK-123"]
168 }}
169]
170
171Guidelines:
172- Start with foundational work (models, schemas)
173- Then build core logic
174- Then add UI/API layers
175- Finally add tests and documentation
176- Each subtask should be independently completable
177- Use 1-indexed dependencies (e.g., ["1"] = first subtask). "0" is INVALID.
178- Dependency values MUST be strings, not numbers
179- Aim for {} subtasks total (can vary by 1-2 if needed for logical breakdown)
180- DO NOT include "complexity" field - subtasks are all assumed to be small and manageable
181
182Return ONLY the JSON array, no additional explanation."#,
183 guidance_section,
184 complexity,
185 task_title,
186 task_description,
187 context,
188 recommended_subtasks,
189 recommended_subtasks
190 )
191 }
192
193 pub fn reanalyze_dependencies(task_context: &str, phases: &[String]) -> String {
194 format!(
195 r#"You are analyzing a software project's task dependencies across multiple phases.
196
197## Current Task State
198
199{task_context}
200
201## Your Task
202
203Review the tasks above and suggest dependency changes that would improve execution order. Consider:
204
2051. **Logical ordering**: Tasks that produce artifacts another task needs
2062. **Current completion state**: Don't add deps on PENDING tasks for DONE tasks
2073. **Cross-phase dependencies**: Tasks in one phase that should wait for tasks in another
2084. **Remove redundant deps**: If A depends on B, and B depends on C, A doesn't also need C
2095. **Missing dependencies**: If a task clearly requires output from another task, add the dependency
210
211## Rules
212
213- Use full task IDs with phase prefix (e.g., "auth:1", "api:3")
214- Task IDs are 1-indexed. NEVER suggest dependencies on task "0" or any ID ending in ":0"
215- Valid examples: "auth:1", "api:3", "main:10" - Invalid: "auth:0", "0"
216- Only suggest changes for tasks that are PENDING or IN PROGRESS
217- Don't modify DONE, EXPANDED, or SKIPPED tasks
218- Consider that some tasks may intentionally have no dependencies
219- Be conservative - only suggest changes that are clearly needed
220
221## Response Format
222
223Return a JSON array of suggestions:
224```json
225[
226 {{
227 "task_id": "api:3",
228 "add_dependencies": ["auth:1", "core:2"],
229 "remove_dependencies": [],
230 "reasoning": "API endpoints need authentication service and core models"
231 }}
232]
233```
234
235Return empty array [] if no changes are needed.
236
237Phases to analyze: {phases:?}
238"#,
239 task_context = task_context,
240 phases = phases
241 )
242 }
243
244 pub fn validate_tasks_against_prd(prd_content: &str, tasks_json: &str) -> String {
245 format!(
246 r#"You are a QA engineer validating that extracted tasks accurately reflect the original PRD.
247
248## Original PRD/Requirements Document
249
250{prd_content}
251
252## Current Tasks (JSON)
253
254{tasks_json}
255
256## Your Task
257
258Compare the tasks against the PRD and identify:
259
2601. **Missing Requirements**: Features or requirements in the PRD that have NO corresponding task
2612. **Incomplete Coverage**: Requirements that are only partially covered by existing tasks
2623. **Misaligned Tasks**: Tasks that don't accurately reflect what the PRD specifies
2634. **Extra Tasks**: Tasks that go beyond what the PRD requires (not necessarily bad, but note them)
2645. **Dependency Issues**: Tasks that should logically depend on others based on PRD context
2656. **Agent Type Issues**: Tasks with missing or incorrect agent_type assignments
266
267## Analysis Guidelines
268
269- Be thorough - check every requirement in the PRD has corresponding task(s)
270- Consider implicit requirements (e.g., if PRD mentions "user authentication", tasks should cover login, logout, session management, etc.)
271- Check that task descriptions accurately capture the PRD's intent
272- Verify task priorities align with PRD emphasis
273- Look for edge cases mentioned in PRD but missing from tasks
274- Verify every task has an appropriate agent_type assigned based on task nature AND complexity:
275 * "fast-builder" = Simple implementation tasks with complexity 0-2 (quick code changes, config updates, simple features)
276 * "builder" = Complex implementation tasks with complexity 3+ (multi-file changes, new features, integrations)
277 * "reviewer" = Code review, quality checks, refactoring tasks
278 * "planner" = Design, architecture planning, research tasks
279 * "tester" = Test writing, test automation, validation tasks
280- IMPORTANT: Check that complexity matches agent_type - complexity 0-2 should use fast-builder, complexity 3+ should use builder
281
282## Response Format
283
284Return a JSON object:
285```json
286{{
287 "coverage_score": <0-100>,
288 "missing_requirements": [
289 {{
290 "requirement": "Description of missing requirement from PRD",
291 "prd_section": "Where in PRD this appears",
292 "suggested_task": "Brief description of task that should be added"
293 }}
294 ],
295 "incomplete_coverage": [
296 {{
297 "requirement": "Description of partially covered requirement",
298 "existing_tasks": ["task_id1", "task_id2"],
299 "gap": "What aspect is missing"
300 }}
301 ],
302 "misaligned_tasks": [
303 {{
304 "task_id": "ID of misaligned task",
305 "issue": "How the task doesn't match PRD",
306 "suggestion": "How to fix"
307 }}
308 ],
309 "extra_tasks": [
310 {{
311 "task_id": "ID of extra task",
312 "note": "Why this may be beyond PRD scope"
313 }}
314 ],
315 "dependency_suggestions": [
316 {{
317 "task_id": "ID of task",
318 "should_depend_on": ["task_id1"],
319 "reasoning": "Why based on PRD context"
320 }}
321 ],
322 "agent_type_issues": [
323 {{
324 "task_id": "ID of task with wrong or missing agent_type",
325 "current_agent_type": null,
326 "suggested_agent_type": "fast-builder|builder|reviewer|planner|tester",
327 "reasoning": "Why this agent type is more appropriate (consider complexity: 0-2 = fast-builder, 3+ = builder)"
328 }}
329 ],
330 "summary": "Brief overall assessment"
331}}
332```
333
334If tasks perfectly cover the PRD, return:
335```json
336{{
337 "coverage_score": 100,
338 "missing_requirements": [],
339 "incomplete_coverage": [],
340 "misaligned_tasks": [],
341 "extra_tasks": [],
342 "dependency_suggestions": [],
343 "agent_type_issues": [],
344 "summary": "Tasks fully cover all PRD requirements"
345}}
346```
347
348Return ONLY the JSON object, no additional explanation."#,
349 prd_content = prd_content,
350 tasks_json = tasks_json
351 )
352 }
353
354 pub fn fix_prd_issues(
355 prd_content: &str,
356 tasks_json: &str,
357 validation: &crate::commands::check_deps::PrdValidationResult,
358 ) -> String {
359 let validation_json = serde_json::to_string_pretty(validation).unwrap_or_default();
360
361 format!(
362 r#"You are a task management expert fixing tasks to better align with the PRD.
363
364## Original PRD/Requirements Document
365
366{prd_content}
367
368## Current Tasks (JSON)
369
370{tasks_json}
371
372## Validation Results (Issues Found)
373
374{validation_json}
375
376## Your Task
377
378Generate fixes for the issues identified in the validation. Focus on:
379
3801. **Misaligned Tasks**: Update task titles and descriptions to match PRD intent
3812. **Dependency Issues**: Add or remove dependencies based on logical ordering
3823. **Incomplete Coverage**: Update task descriptions to cover gaps
3834. **Agent Type Issues**: Assign or correct agent_type for each task
384
385## Rules
386
387- Only fix issues that can be resolved by updating existing tasks
388- Do NOT suggest adding new tasks (that's a separate operation)
389- Be precise - update only what needs changing
390- Use full task IDs with phase prefix (e.g., "swfix:1", "auth:3")
391- Keep task titles concise and action-oriented
392- Keep descriptions to 2-3 sentences
393
394## Response Format
395
396Return a JSON array of fixes:
397```json
398[
399 {{
400 "action": "update_task",
401 "task_id": "swfix:1",
402 "new_title": "Updated title matching PRD",
403 "new_description": "Updated description that better reflects PRD requirements",
404 "reasoning": "Why this change aligns with PRD"
405 }},
406 {{
407 "action": "update_dependency",
408 "task_id": "swfix:3",
409 "add_dependencies": ["swfix:1"],
410 "remove_dependencies": [],
411 "reasoning": "Task 3 needs output from task 1 per PRD"
412 }},
413 {{
414 "action": "update_agent_type",
415 "task_id": "swfix:2",
416 "new_agent_type": "builder",
417 "reasoning": "Task involves implementation work, builder agent is most appropriate"
418 }}
419]
420```
421
422## Agent Type Guidelines
423
424When assigning agent_type, consider BOTH task nature AND complexity:
425- "fast-builder" = Simple implementation tasks with complexity 0-2 (quick code changes, config updates, simple features)
426- "builder" = Complex implementation tasks with complexity 3+ (multi-file changes, new features, integrations)
427- "reviewer" = Code review, quality checks, refactoring tasks
428- "planner" = Design, architecture planning, research tasks
429- "tester" = Test writing, test automation, validation tasks
430
431CRITICAL RULES:
4321. Every task MUST have an agent_type assigned. If a task has no agent_type (null), generate an update_agent_type fix.
4332. For implementation tasks, use complexity to choose between fast-builder and builder:
434 - Complexity 0, 1, or 2 → "fast-builder"
435 - Complexity 3, 5, 8, 13, or 21 → "builder"
4363. Subtasks (tasks with parent_id) typically have complexity 0 and should use "fast-builder" unless they are test or review tasks.
437
438Return empty array [] if no automatic fixes are possible.
439
440Return ONLY the JSON array, no additional explanation."#,
441 prd_content = prd_content,
442 tasks_json = tasks_json,
443 validation_json = validation_json
444 )
445 }
446}