bmad-method 4.15.0 → 4.16.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/.bmad-core/agent-teams/team-all.yml +14 -0
- package/.bmad-core/agent-teams/team-fullstack.yml +18 -0
- package/.bmad-core/agent-teams/team-ide-minimal.yml +10 -0
- package/.bmad-core/agent-teams/team-no-ui.yml +13 -0
- package/.bmad-core/agents/analyst.md +64 -0
- package/.bmad-core/agents/architect.md +64 -0
- package/.bmad-core/agents/bmad-master.md +101 -0
- package/.bmad-core/agents/bmad-orchestrator.md +126 -0
- package/.bmad-core/agents/dev.md +65 -0
- package/.bmad-core/agents/pm.md +61 -0
- package/.bmad-core/agents/po.md +63 -0
- package/.bmad-core/agents/qa.md +50 -0
- package/.bmad-core/agents/sm.md +51 -0
- package/.bmad-core/agents/ux-expert.md +63 -0
- package/.bmad-core/checklists/architect-checklist.md +443 -0
- package/.bmad-core/checklists/change-checklist.md +182 -0
- package/.bmad-core/checklists/pm-checklist.md +375 -0
- package/.bmad-core/checklists/po-master-checklist.md +441 -0
- package/.bmad-core/checklists/story-dod-checklist.md +101 -0
- package/.bmad-core/checklists/story-draft-checklist.md +156 -0
- package/.bmad-core/core-config.yml +20 -0
- package/.bmad-core/data/bmad-kb.md +814 -0
- package/.bmad-core/data/technical-preferences.md +3 -0
- package/.bmad-core/install-manifest.yml +196 -0
- package/.bmad-core/tasks/advanced-elicitation.md +92 -0
- package/.bmad-core/tasks/brainstorming-techniques.md +238 -0
- package/.bmad-core/tasks/brownfield-create-epic.md +160 -0
- package/.bmad-core/tasks/brownfield-create-story.md +147 -0
- package/.bmad-core/tasks/core-dump.md +74 -0
- package/.bmad-core/tasks/correct-course.md +73 -0
- package/.bmad-core/tasks/create-deep-research-prompt.md +301 -0
- package/.bmad-core/tasks/create-doc.md +74 -0
- package/.bmad-core/tasks/create-next-story.md +242 -0
- package/.bmad-core/tasks/doc-migration-task.md +151 -0
- package/.bmad-core/tasks/document-project.md +350 -0
- package/.bmad-core/tasks/execute-checklist.md +97 -0
- package/.bmad-core/tasks/generate-ai-frontend-prompt.md +51 -0
- package/.bmad-core/tasks/index-docs.md +178 -0
- package/.bmad-core/tasks/kb-mode-interaction.md +77 -0
- package/.bmad-core/tasks/review-story.md +153 -0
- package/.bmad-core/tasks/shard-doc.md +191 -0
- package/.bmad-core/templates/architecture-tmpl.md +776 -0
- package/.bmad-core/templates/brownfield-architecture-tmpl.md +544 -0
- package/.bmad-core/templates/brownfield-prd-tmpl.md +242 -0
- package/.bmad-core/templates/competitor-analysis-tmpl.md +291 -0
- package/.bmad-core/templates/front-end-architecture-tmpl.md +175 -0
- package/.bmad-core/templates/front-end-spec-tmpl.md +413 -0
- package/.bmad-core/templates/fullstack-architecture-tmpl.md +1018 -0
- package/.bmad-core/templates/market-research-tmpl.md +263 -0
- package/.bmad-core/templates/prd-tmpl.md +202 -0
- package/.bmad-core/templates/project-brief-tmpl.md +230 -0
- package/.bmad-core/templates/story-tmpl.md +69 -0
- package/.bmad-core/utils/file-resolution-context.md +10 -0
- package/.bmad-core/utils/template-format.md +26 -0
- package/.bmad-core/utils/web-agent-startup-instructions.md +39 -0
- package/.bmad-core/utils/workflow-management.md +223 -0
- package/.bmad-core/workflows/brownfield-fullstack.yml +112 -0
- package/.bmad-core/workflows/brownfield-service.yml +113 -0
- package/.bmad-core/workflows/brownfield-ui.yml +123 -0
- package/.bmad-core/workflows/greenfield-fullstack.yml +166 -0
- package/.bmad-core/workflows/greenfield-service.yml +132 -0
- package/.bmad-core/workflows/greenfield-ui.yml +161 -0
- package/.claude/commands/analyst.md +68 -0
- package/.claude/commands/architect.md +68 -0
- package/.claude/commands/bmad-master.md +105 -0
- package/.claude/commands/bmad-orchestrator.md +130 -0
- package/.claude/commands/dev.md +69 -0
- package/.claude/commands/pm.md +65 -0
- package/.claude/commands/po.md +67 -0
- package/.claude/commands/qa.md +54 -0
- package/.claude/commands/sm.md +55 -0
- package/.claude/commands/ux-expert.md +67 -0
- package/.clinerules/01-bmad-master.md +116 -0
- package/.clinerules/02-bmad-orchestrator.md +141 -0
- package/.clinerules/03-pm.md +76 -0
- package/.clinerules/04-analyst.md +79 -0
- package/.clinerules/05-architect.md +79 -0
- package/.clinerules/06-po.md +78 -0
- package/.clinerules/07-sm.md +66 -0
- package/.clinerules/08-dev.md +80 -0
- package/.clinerules/09-qa.md +65 -0
- package/.clinerules/10-ux-expert.md +78 -0
- package/.cursor/rules/analyst.mdc +82 -0
- package/.cursor/rules/architect.mdc +82 -0
- package/.cursor/rules/bmad-master.mdc +119 -0
- package/.cursor/rules/bmad-orchestrator.mdc +144 -0
- package/.cursor/rules/dev.mdc +83 -0
- package/.cursor/rules/pm.mdc +79 -0
- package/.cursor/rules/po.mdc +81 -0
- package/.cursor/rules/qa.mdc +68 -0
- package/.cursor/rules/sm.mdc +69 -0
- package/.cursor/rules/ux-expert.mdc +81 -0
- package/.gemini/agents/analyst.md +64 -0
- package/.gemini/agents/architect.md +64 -0
- package/.gemini/agents/bmad-master.md +101 -0
- package/.gemini/agents/bmad-orchestrator.md +126 -0
- package/.gemini/agents/dev.md +65 -0
- package/.gemini/agents/pm.md +61 -0
- package/.gemini/agents/po.md +63 -0
- package/.gemini/agents/qa.md +50 -0
- package/.gemini/agents/sm.md +51 -0
- package/.gemini/agents/ux-expert.md +63 -0
- package/.gemini/settings.json +14 -0
- package/.roomodes +95 -0
- package/.windsurf/rules/analyst.md +76 -0
- package/.windsurf/rules/architect.md +76 -0
- package/.windsurf/rules/bmad-master.md +113 -0
- package/.windsurf/rules/bmad-orchestrator.md +138 -0
- package/.windsurf/rules/dev.md +77 -0
- package/.windsurf/rules/pm.md +73 -0
- package/.windsurf/rules/po.md +75 -0
- package/.windsurf/rules/qa.md +62 -0
- package/.windsurf/rules/sm.md +63 -0
- package/.windsurf/rules/ux-expert.md +75 -0
- package/CHANGELOG.md +7 -0
- package/README.md +2 -1
- package/package.json +1 -1
- package/tools/installer/package.json +1 -1
|
@@ -0,0 +1,147 @@
|
|
|
1
|
+
# Create Brownfield Story Task
|
|
2
|
+
|
|
3
|
+
## Purpose
|
|
4
|
+
|
|
5
|
+
Create a single user story for very small brownfield enhancements that can be completed in one focused development session. This task is for minimal additions or bug fixes that require existing system integration awareness.
|
|
6
|
+
|
|
7
|
+
## When to Use This Task
|
|
8
|
+
|
|
9
|
+
**Use this task when:**
|
|
10
|
+
|
|
11
|
+
- The enhancement can be completed in a single story
|
|
12
|
+
- No new architecture or significant design is required
|
|
13
|
+
- The change follows existing patterns exactly
|
|
14
|
+
- Integration is straightforward with minimal risk
|
|
15
|
+
- Change is isolated with clear boundaries
|
|
16
|
+
|
|
17
|
+
**Use brownfield-create-epic when:**
|
|
18
|
+
|
|
19
|
+
- The enhancement requires 2-3 coordinated stories
|
|
20
|
+
- Some design work is needed
|
|
21
|
+
- Multiple integration points are involved
|
|
22
|
+
|
|
23
|
+
**Use the full brownfield PRD/Architecture process when:**
|
|
24
|
+
|
|
25
|
+
- The enhancement requires multiple coordinated stories
|
|
26
|
+
- Architectural planning is needed
|
|
27
|
+
- Significant integration work is required
|
|
28
|
+
|
|
29
|
+
## Instructions
|
|
30
|
+
|
|
31
|
+
### 1. Quick Project Assessment
|
|
32
|
+
|
|
33
|
+
Gather minimal but essential context about the existing project:
|
|
34
|
+
|
|
35
|
+
**Current System Context:**
|
|
36
|
+
|
|
37
|
+
- [ ] Relevant existing functionality identified
|
|
38
|
+
- [ ] Technology stack for this area noted
|
|
39
|
+
- [ ] Integration point(s) clearly understood
|
|
40
|
+
- [ ] Existing patterns for similar work identified
|
|
41
|
+
|
|
42
|
+
**Change Scope:**
|
|
43
|
+
|
|
44
|
+
- [ ] Specific change clearly defined
|
|
45
|
+
- [ ] Impact boundaries identified
|
|
46
|
+
- [ ] Success criteria established
|
|
47
|
+
|
|
48
|
+
### 2. Story Creation
|
|
49
|
+
|
|
50
|
+
Create a single focused story following this structure:
|
|
51
|
+
|
|
52
|
+
#### Story Title
|
|
53
|
+
|
|
54
|
+
{{Specific Enhancement}} - Brownfield Addition
|
|
55
|
+
|
|
56
|
+
#### User Story
|
|
57
|
+
|
|
58
|
+
As a {{user type}},
|
|
59
|
+
I want {{specific action/capability}},
|
|
60
|
+
So that {{clear benefit/value}}.
|
|
61
|
+
|
|
62
|
+
#### Story Context
|
|
63
|
+
|
|
64
|
+
**Existing System Integration:**
|
|
65
|
+
|
|
66
|
+
- Integrates with: {{existing component/system}}
|
|
67
|
+
- Technology: {{relevant tech stack}}
|
|
68
|
+
- Follows pattern: {{existing pattern to follow}}
|
|
69
|
+
- Touch points: {{specific integration points}}
|
|
70
|
+
|
|
71
|
+
#### Acceptance Criteria
|
|
72
|
+
|
|
73
|
+
**Functional Requirements:**
|
|
74
|
+
|
|
75
|
+
1. {{Primary functional requirement}}
|
|
76
|
+
2. {{Secondary functional requirement (if any)}}
|
|
77
|
+
3. {{Integration requirement}}
|
|
78
|
+
|
|
79
|
+
**Integration Requirements:** 4. Existing {{relevant functionality}} continues to work unchanged 5. New functionality follows existing {{pattern}} pattern 6. Integration with {{system/component}} maintains current behavior
|
|
80
|
+
|
|
81
|
+
**Quality Requirements:** 7. Change is covered by appropriate tests 8. Documentation is updated if needed 9. No regression in existing functionality verified
|
|
82
|
+
|
|
83
|
+
#### Technical Notes
|
|
84
|
+
|
|
85
|
+
- **Integration Approach:** {{how it connects to existing system}}
|
|
86
|
+
- **Existing Pattern Reference:** {{link or description of pattern to follow}}
|
|
87
|
+
- **Key Constraints:** {{any important limitations or requirements}}
|
|
88
|
+
|
|
89
|
+
#### Definition of Done
|
|
90
|
+
|
|
91
|
+
- [ ] Functional requirements met
|
|
92
|
+
- [ ] Integration requirements verified
|
|
93
|
+
- [ ] Existing functionality regression tested
|
|
94
|
+
- [ ] Code follows existing patterns and standards
|
|
95
|
+
- [ ] Tests pass (existing and new)
|
|
96
|
+
- [ ] Documentation updated if applicable
|
|
97
|
+
|
|
98
|
+
### 3. Risk and Compatibility Check
|
|
99
|
+
|
|
100
|
+
**Minimal Risk Assessment:**
|
|
101
|
+
|
|
102
|
+
- **Primary Risk:** {{main risk to existing system}}
|
|
103
|
+
- **Mitigation:** {{simple mitigation approach}}
|
|
104
|
+
- **Rollback:** {{how to undo if needed}}
|
|
105
|
+
|
|
106
|
+
**Compatibility Verification:**
|
|
107
|
+
|
|
108
|
+
- [ ] No breaking changes to existing APIs
|
|
109
|
+
- [ ] Database changes (if any) are additive only
|
|
110
|
+
- [ ] UI changes follow existing design patterns
|
|
111
|
+
- [ ] Performance impact is negligible
|
|
112
|
+
|
|
113
|
+
### 4. Validation Checklist
|
|
114
|
+
|
|
115
|
+
Before finalizing the story, confirm:
|
|
116
|
+
|
|
117
|
+
**Scope Validation:**
|
|
118
|
+
|
|
119
|
+
- [ ] Story can be completed in one development session
|
|
120
|
+
- [ ] Integration approach is straightforward
|
|
121
|
+
- [ ] Follows existing patterns exactly
|
|
122
|
+
- [ ] No design or architecture work required
|
|
123
|
+
|
|
124
|
+
**Clarity Check:**
|
|
125
|
+
|
|
126
|
+
- [ ] Story requirements are unambiguous
|
|
127
|
+
- [ ] Integration points are clearly specified
|
|
128
|
+
- [ ] Success criteria are testable
|
|
129
|
+
- [ ] Rollback approach is simple
|
|
130
|
+
|
|
131
|
+
## Success Criteria
|
|
132
|
+
|
|
133
|
+
The story creation is successful when:
|
|
134
|
+
|
|
135
|
+
1. Enhancement is clearly defined and appropriately scoped for single session
|
|
136
|
+
2. Integration approach is straightforward and low-risk
|
|
137
|
+
3. Existing system patterns are identified and will be followed
|
|
138
|
+
4. Rollback plan is simple and feasible
|
|
139
|
+
5. Acceptance criteria include existing functionality verification
|
|
140
|
+
|
|
141
|
+
## Important Notes
|
|
142
|
+
|
|
143
|
+
- This task is for VERY SMALL brownfield changes only
|
|
144
|
+
- If complexity grows during analysis, escalate to brownfield-create-epic
|
|
145
|
+
- Always prioritize existing system integrity
|
|
146
|
+
- When in doubt about integration complexity, use brownfield-create-epic instead
|
|
147
|
+
- Stories should take no more than 4 hours of focused development work
|
|
@@ -0,0 +1,74 @@
|
|
|
1
|
+
# Core Dump Task
|
|
2
|
+
|
|
3
|
+
## Purpose
|
|
4
|
+
|
|
5
|
+
To create a concise memory recording file (`.ai/core-dump-n.md`) that captures the essential context of the current agent session, enabling seamless continuation of work in future agent sessions. This task ensures persistent context across agent conversations while maintaining minimal token usage for efficient context loading.
|
|
6
|
+
|
|
7
|
+
## Inputs for this Task
|
|
8
|
+
|
|
9
|
+
- Current session conversation history and accomplishments
|
|
10
|
+
- Files created, modified, or deleted during the session
|
|
11
|
+
- Key decisions made and procedures followed
|
|
12
|
+
- Current project state and next logical steps
|
|
13
|
+
- User requests and agent responses that shaped the session
|
|
14
|
+
|
|
15
|
+
## Task Execution Instructions
|
|
16
|
+
|
|
17
|
+
### 0. Check Existing Core Dump
|
|
18
|
+
|
|
19
|
+
Before proceeding, check if `.ai/core-dump.md` already exists:
|
|
20
|
+
|
|
21
|
+
- If file exists, ask user: "Core dump file exists. Should I: 1. Overwrite, 2. Update, 3. Append or 4. Create new?"
|
|
22
|
+
- **Overwrite**: Replace entire file with new content
|
|
23
|
+
- **Update**: Merge new session info with existing content, updating relevant sections
|
|
24
|
+
- **Append**: Add new session as a separate entry while preserving existing content
|
|
25
|
+
- **Create New**: Create a new file, appending the next possible -# to the file, such as core-dump-3.md if 1 and 2 already exist.
|
|
26
|
+
- If file doesn't exist, proceed with creation of `core-dump-1.md`
|
|
27
|
+
|
|
28
|
+
### 1. Analyze Session Context
|
|
29
|
+
|
|
30
|
+
- Review the entire conversation to identify key accomplishments
|
|
31
|
+
- Note any specific tasks, procedures, or workflows that were executed
|
|
32
|
+
- Identify important decisions made or problems solved
|
|
33
|
+
- Capture the user's working style and preferences observed during the session
|
|
34
|
+
|
|
35
|
+
### 2. Document What Was Accomplished
|
|
36
|
+
|
|
37
|
+
- **Primary Actions**: List the main tasks completed concisely
|
|
38
|
+
- **Story Progress**: For story work, use format "Tasks Complete: 1-6, 8. Next Task Pending: 7, 9"
|
|
39
|
+
- **Problem Solving**: Document any challenges encountered and how they were resolved
|
|
40
|
+
- **User Communications**: Summarize key user requests, preferences, and discussion points
|
|
41
|
+
|
|
42
|
+
### 3. Record File System Changes (Concise Format)
|
|
43
|
+
|
|
44
|
+
- **Files Created**: `filename.ext` (brief purpose/size)
|
|
45
|
+
- **Files Modified**: `filename.ext` (what changed)
|
|
46
|
+
- **Files Deleted**: `filename.ext` (why removed)
|
|
47
|
+
- Focus on essential details, avoid verbose descriptions
|
|
48
|
+
|
|
49
|
+
### 4. Capture Current Project State
|
|
50
|
+
|
|
51
|
+
- **Project Progress**: Where the project stands after this session
|
|
52
|
+
- **Current Issues**: Any blockers or problems that need resolution
|
|
53
|
+
- **Next Logical Steps**: What would be the natural next actions to take
|
|
54
|
+
|
|
55
|
+
### 5. Create/Update Core Dump File
|
|
56
|
+
|
|
57
|
+
Based on user's choice from step 0, handle the file accordingly:
|
|
58
|
+
|
|
59
|
+
### 6. Optimize for Minimal Context
|
|
60
|
+
|
|
61
|
+
- Keep descriptions concise but informative
|
|
62
|
+
- Use abbreviated formats where possible (file sizes, task numbers)
|
|
63
|
+
- Focus on actionable information rather than detailed explanations
|
|
64
|
+
- Avoid redundant information that can be found in project documentation
|
|
65
|
+
- Prioritize information that would be lost without this recording
|
|
66
|
+
- Ensure the file can be quickly scanned and understood
|
|
67
|
+
|
|
68
|
+
### 7. Validate Completeness
|
|
69
|
+
|
|
70
|
+
- Verify all significant session activities are captured
|
|
71
|
+
- Ensure a future agent could understand the current state
|
|
72
|
+
- Check that file changes are accurately recorded
|
|
73
|
+
- Confirm next steps are clear and actionable
|
|
74
|
+
- Verify user communication style and preferences are noted
|
|
@@ -0,0 +1,73 @@
|
|
|
1
|
+
# Correct Course Task
|
|
2
|
+
|
|
3
|
+
## Purpose
|
|
4
|
+
|
|
5
|
+
- Guide a structured response to a change trigger using the `change-checklist`.
|
|
6
|
+
- Analyze the impacts of the change on epics, project artifacts, and the MVP, guided by the checklist's structure.
|
|
7
|
+
- Explore potential solutions (e.g., adjust scope, rollback elements, rescope features) as prompted by the checklist.
|
|
8
|
+
- Draft specific, actionable proposed updates to any affected project artifacts (e.g., epics, user stories, PRD sections, architecture document sections) based on the analysis.
|
|
9
|
+
- Produce a consolidated "Sprint Change Proposal" document that contains the impact analysis and the clearly drafted proposed edits for user review and approval.
|
|
10
|
+
- Ensure a clear handoff path if the nature of the changes necessitates fundamental replanning by other core agents (like PM or Architect).
|
|
11
|
+
|
|
12
|
+
## Instructions
|
|
13
|
+
|
|
14
|
+
### 1. Initial Setup & Mode Selection
|
|
15
|
+
|
|
16
|
+
- **Acknowledge Task & Inputs:**
|
|
17
|
+
- Confirm with the user that the "Correct Course Task" (Change Navigation & Integration) is being initiated.
|
|
18
|
+
- Verify the change trigger and ensure you have the user's initial explanation of the issue and its perceived impact.
|
|
19
|
+
- Confirm access to all relevant project artifacts (e.g., PRD, Epics/Stories, Architecture Documents, UI/UX Specifications) and, critically, the `change-checklist` (e.g., `change-checklist`).
|
|
20
|
+
- **Establish Interaction Mode:**
|
|
21
|
+
- Ask the user their preferred interaction mode for this task:
|
|
22
|
+
- **"Incrementally (Default & Recommended):** Shall we work through the `change-checklist` section by section, discussing findings and collaboratively drafting proposed changes for each relevant part before moving to the next? This allows for detailed, step-by-step refinement."
|
|
23
|
+
- **"YOLO Mode (Batch Processing):** Or, would you prefer I conduct a more batched analysis based on the checklist and then present a consolidated set of findings and proposed changes for a broader review? This can be quicker for initial assessment but might require more extensive review of the combined proposals."
|
|
24
|
+
- Request the user to select their preferred mode.
|
|
25
|
+
- Once the user chooses, confirm the selected mode (e.g., "Okay, we will proceed in Incremental mode."). This chosen mode will govern how subsequent steps in this task are executed.
|
|
26
|
+
- **Explain Process:** Briefly inform the user: "We will now use the `change-checklist` to analyze the change and draft proposed updates. I will guide you through the checklist items based on our chosen interaction mode."
|
|
27
|
+
<rule>When asking multiple questions or presenting multiple points for user input at once, number them clearly (e.g., 1., 2a., 2b.) to make it easier for the user to provide specific responses.</rule>
|
|
28
|
+
|
|
29
|
+
### 2. Execute Checklist Analysis (Iteratively or Batched, per Interaction Mode)
|
|
30
|
+
|
|
31
|
+
- Systematically work through Sections 1-4 of the `change-checklist` (typically covering Change Context, Epic/Story Impact Analysis, Artifact Conflict Resolution, and Path Evaluation/Recommendation).
|
|
32
|
+
- For each checklist item or logical group of items (depending on interaction mode):
|
|
33
|
+
- Present the relevant prompt(s) or considerations from the checklist to the user.
|
|
34
|
+
- Request necessary information and actively analyze the relevant project artifacts (PRD, epics, architecture documents, story history, etc.) to assess the impact.
|
|
35
|
+
- Discuss your findings for each item with the user.
|
|
36
|
+
- Record the status of each checklist item (e.g., `[x] Addressed`, `[N/A]`, `[!] Further Action Needed`) and any pertinent notes or decisions.
|
|
37
|
+
- Collaboratively agree on the "Recommended Path Forward" as prompted by Section 4 of the checklist.
|
|
38
|
+
|
|
39
|
+
### 3. Draft Proposed Changes (Iteratively or Batched)
|
|
40
|
+
|
|
41
|
+
- Based on the completed checklist analysis (Sections 1-4) and the agreed "Recommended Path Forward" (excluding scenarios requiring fundamental replans that would necessitate immediate handoff to PM/Architect):
|
|
42
|
+
- Identify the specific project artifacts that require updates (e.g., specific epics, user stories, PRD sections, architecture document components, diagrams).
|
|
43
|
+
- **Draft the proposed changes directly and explicitly for each identified artifact.** Examples include:
|
|
44
|
+
- Revising user story text, acceptance criteria, or priority.
|
|
45
|
+
- Adding, removing, reordering, or splitting user stories within epics.
|
|
46
|
+
- Proposing modified architecture diagram snippets (e.g., providing an updated Mermaid diagram block or a clear textual description of the change to an existing diagram).
|
|
47
|
+
- Updating technology lists, configuration details, or specific sections within the PRD or architecture documents.
|
|
48
|
+
- Drafting new, small supporting artifacts if necessary (e.g., a brief addendum for a specific decision).
|
|
49
|
+
- If in "Incremental Mode," discuss and refine these proposed edits for each artifact or small group of related artifacts with the user as they are drafted.
|
|
50
|
+
- If in "YOLO Mode," compile all drafted edits for presentation in the next step.
|
|
51
|
+
|
|
52
|
+
### 4. Generate "Sprint Change Proposal" with Edits
|
|
53
|
+
|
|
54
|
+
- Synthesize the complete `change-checklist` analysis (covering findings from Sections 1-4) and all the agreed-upon proposed edits (from Instruction 3) into a single document titled "Sprint Change Proposal." This proposal should align with the structure suggested by Section 5 of the `change-checklist` (Proposal Components).
|
|
55
|
+
- The proposal must clearly present:
|
|
56
|
+
- **Analysis Summary:** A concise overview of the original issue, its analyzed impact (on epics, artifacts, MVP scope), and the rationale for the chosen path forward.
|
|
57
|
+
- **Specific Proposed Edits:** For each affected artifact, clearly show or describe the exact changes (e.g., "Change Story X.Y from: [old text] To: [new text]", "Add new Acceptance Criterion to Story A.B: [new AC]", "Update Section 3.2 of Architecture Document as follows: [new/modified text or diagram description]").
|
|
58
|
+
- Present the complete draft of the "Sprint Change Proposal" to the user for final review and feedback. Incorporate any final adjustments requested by the user.
|
|
59
|
+
|
|
60
|
+
### 5. Finalize & Determine Next Steps
|
|
61
|
+
|
|
62
|
+
- Obtain explicit user approval for the "Sprint Change Proposal," including all the specific edits documented within it.
|
|
63
|
+
- Provide the finalized "Sprint Change Proposal" document to the user.
|
|
64
|
+
- **Based on the nature of the approved changes:**
|
|
65
|
+
- **If the approved edits sufficiently address the change and can be implemented directly or organized by a PO/SM:** State that the "Correct Course Task" is complete regarding analysis and change proposal, and the user can now proceed with implementing or logging these changes (e.g., updating actual project documents, backlog items). Suggest handoff to a PO/SM agent for backlog organization if appropriate.
|
|
66
|
+
- **If the analysis and proposed path (as per checklist Section 4 and potentially Section 6) indicate that the change requires a more fundamental replan (e.g., significant scope change, major architectural rework):** Clearly state this conclusion. Advise the user that the next step involves engaging the primary PM or Architect agents, using the "Sprint Change Proposal" as critical input and context for that deeper replanning effort.
|
|
67
|
+
|
|
68
|
+
## Output Deliverables
|
|
69
|
+
|
|
70
|
+
- **Primary:** A "Sprint Change Proposal" document (in markdown format). This document will contain:
|
|
71
|
+
- A summary of the `change-checklist` analysis (issue, impact, rationale for the chosen path).
|
|
72
|
+
- Specific, clearly drafted proposed edits for all affected project artifacts.
|
|
73
|
+
- **Implicit:** An annotated `change-checklist` (or the record of its completion) reflecting the discussions, findings, and decisions made during the process.
|
|
@@ -0,0 +1,301 @@
|
|
|
1
|
+
# Create Deep Research Prompt Task
|
|
2
|
+
|
|
3
|
+
This task helps create comprehensive research prompts for various types of deep analysis. It can process inputs from brainstorming sessions, project briefs, market research, or specific research questions to generate targeted prompts for deeper investigation.
|
|
4
|
+
|
|
5
|
+
## Purpose
|
|
6
|
+
|
|
7
|
+
Generate well-structured research prompts that:
|
|
8
|
+
|
|
9
|
+
- Define clear research objectives and scope
|
|
10
|
+
- Specify appropriate research methodologies
|
|
11
|
+
- Outline expected deliverables and formats
|
|
12
|
+
- Guide systematic investigation of complex topics
|
|
13
|
+
- Ensure actionable insights are captured
|
|
14
|
+
|
|
15
|
+
## Research Type Selection
|
|
16
|
+
|
|
17
|
+
[[LLM: First, help the user select the most appropriate research focus based on their needs and any input documents they've provided.]]
|
|
18
|
+
|
|
19
|
+
### 1. Research Focus Options
|
|
20
|
+
|
|
21
|
+
Present these numbered options to the user:
|
|
22
|
+
|
|
23
|
+
1. **Product Validation Research**
|
|
24
|
+
|
|
25
|
+
- Validate product hypotheses and market fit
|
|
26
|
+
- Test assumptions about user needs and solutions
|
|
27
|
+
- Assess technical and business feasibility
|
|
28
|
+
- Identify risks and mitigation strategies
|
|
29
|
+
|
|
30
|
+
2. **Market Opportunity Research**
|
|
31
|
+
|
|
32
|
+
- Analyze market size and growth potential
|
|
33
|
+
- Identify market segments and dynamics
|
|
34
|
+
- Assess market entry strategies
|
|
35
|
+
- Evaluate timing and market readiness
|
|
36
|
+
|
|
37
|
+
3. **User & Customer Research**
|
|
38
|
+
|
|
39
|
+
- Deep dive into user personas and behaviors
|
|
40
|
+
- Understand jobs-to-be-done and pain points
|
|
41
|
+
- Map customer journeys and touchpoints
|
|
42
|
+
- Analyze willingness to pay and value perception
|
|
43
|
+
|
|
44
|
+
4. **Competitive Intelligence Research**
|
|
45
|
+
|
|
46
|
+
- Detailed competitor analysis and positioning
|
|
47
|
+
- Feature and capability comparisons
|
|
48
|
+
- Business model and strategy analysis
|
|
49
|
+
- Identify competitive advantages and gaps
|
|
50
|
+
|
|
51
|
+
5. **Technology & Innovation Research**
|
|
52
|
+
|
|
53
|
+
- Assess technology trends and possibilities
|
|
54
|
+
- Evaluate technical approaches and architectures
|
|
55
|
+
- Identify emerging technologies and disruptions
|
|
56
|
+
- Analyze build vs. buy vs. partner options
|
|
57
|
+
|
|
58
|
+
6. **Industry & Ecosystem Research**
|
|
59
|
+
|
|
60
|
+
- Map industry value chains and dynamics
|
|
61
|
+
- Identify key players and relationships
|
|
62
|
+
- Analyze regulatory and compliance factors
|
|
63
|
+
- Understand partnership opportunities
|
|
64
|
+
|
|
65
|
+
7. **Strategic Options Research**
|
|
66
|
+
|
|
67
|
+
- Evaluate different strategic directions
|
|
68
|
+
- Assess business model alternatives
|
|
69
|
+
- Analyze go-to-market strategies
|
|
70
|
+
- Consider expansion and scaling paths
|
|
71
|
+
|
|
72
|
+
8. **Risk & Feasibility Research**
|
|
73
|
+
|
|
74
|
+
- Identify and assess various risk factors
|
|
75
|
+
- Evaluate implementation challenges
|
|
76
|
+
- Analyze resource requirements
|
|
77
|
+
- Consider regulatory and legal implications
|
|
78
|
+
|
|
79
|
+
9. **Custom Research Focus**
|
|
80
|
+
[[LLM: Allow user to define their own specific research focus.]]
|
|
81
|
+
- User-defined research objectives
|
|
82
|
+
- Specialized domain investigation
|
|
83
|
+
- Cross-functional research needs
|
|
84
|
+
|
|
85
|
+
### 2. Input Processing
|
|
86
|
+
|
|
87
|
+
[[LLM: Based on the selected research type and any provided inputs (project brief, brainstorming results, etc.), extract relevant context and constraints.]]
|
|
88
|
+
|
|
89
|
+
**If Project Brief provided:**
|
|
90
|
+
|
|
91
|
+
- Extract key product concepts and goals
|
|
92
|
+
- Identify target users and use cases
|
|
93
|
+
- Note technical constraints and preferences
|
|
94
|
+
- Highlight uncertainties and assumptions
|
|
95
|
+
|
|
96
|
+
**If Brainstorming Results provided:**
|
|
97
|
+
|
|
98
|
+
- Synthesize main ideas and themes
|
|
99
|
+
- Identify areas needing validation
|
|
100
|
+
- Extract hypotheses to test
|
|
101
|
+
- Note creative directions to explore
|
|
102
|
+
|
|
103
|
+
**If Market Research provided:**
|
|
104
|
+
|
|
105
|
+
- Build on identified opportunities
|
|
106
|
+
- Deepen specific market insights
|
|
107
|
+
- Validate initial findings
|
|
108
|
+
- Explore adjacent possibilities
|
|
109
|
+
|
|
110
|
+
**If Starting Fresh:**
|
|
111
|
+
|
|
112
|
+
- Gather essential context through questions
|
|
113
|
+
- Define the problem space
|
|
114
|
+
- Clarify research objectives
|
|
115
|
+
- Establish success criteria
|
|
116
|
+
|
|
117
|
+
## Process
|
|
118
|
+
|
|
119
|
+
### 3. Research Prompt Structure
|
|
120
|
+
|
|
121
|
+
[[LLM: Based on the selected research type and context, collaboratively develop a comprehensive research prompt with these components.]]
|
|
122
|
+
|
|
123
|
+
#### A. Research Objectives
|
|
124
|
+
|
|
125
|
+
[[LLM: Work with the user to articulate clear, specific objectives for the research.]]
|
|
126
|
+
|
|
127
|
+
- Primary research goal and purpose
|
|
128
|
+
- Key decisions the research will inform
|
|
129
|
+
- Success criteria for the research
|
|
130
|
+
- Constraints and boundaries
|
|
131
|
+
|
|
132
|
+
#### B. Research Questions
|
|
133
|
+
|
|
134
|
+
[[LLM: Develop specific, actionable research questions organized by theme.]]
|
|
135
|
+
|
|
136
|
+
**Core Questions:**
|
|
137
|
+
|
|
138
|
+
- Central questions that must be answered
|
|
139
|
+
- Priority ranking of questions
|
|
140
|
+
- Dependencies between questions
|
|
141
|
+
|
|
142
|
+
**Supporting Questions:**
|
|
143
|
+
|
|
144
|
+
- Additional context-building questions
|
|
145
|
+
- Nice-to-have insights
|
|
146
|
+
- Future-looking considerations
|
|
147
|
+
|
|
148
|
+
#### C. Research Methodology
|
|
149
|
+
|
|
150
|
+
[[LLM: Specify appropriate research methods based on the type and objectives.]]
|
|
151
|
+
|
|
152
|
+
**Data Collection Methods:**
|
|
153
|
+
|
|
154
|
+
- Secondary research sources
|
|
155
|
+
- Primary research approaches (if applicable)
|
|
156
|
+
- Data quality requirements
|
|
157
|
+
- Source credibility criteria
|
|
158
|
+
|
|
159
|
+
**Analysis Frameworks:**
|
|
160
|
+
|
|
161
|
+
- Specific frameworks to apply
|
|
162
|
+
- Comparison criteria
|
|
163
|
+
- Evaluation methodologies
|
|
164
|
+
- Synthesis approaches
|
|
165
|
+
|
|
166
|
+
#### D. Output Requirements
|
|
167
|
+
|
|
168
|
+
[[LLM: Define how research findings should be structured and presented.]]
|
|
169
|
+
|
|
170
|
+
**Format Specifications:**
|
|
171
|
+
|
|
172
|
+
- Executive summary requirements
|
|
173
|
+
- Detailed findings structure
|
|
174
|
+
- Visual/tabular presentations
|
|
175
|
+
- Supporting documentation
|
|
176
|
+
|
|
177
|
+
**Key Deliverables:**
|
|
178
|
+
|
|
179
|
+
- Must-have sections and insights
|
|
180
|
+
- Decision-support elements
|
|
181
|
+
- Action-oriented recommendations
|
|
182
|
+
- Risk and uncertainty documentation
|
|
183
|
+
|
|
184
|
+
### 4. Prompt Generation
|
|
185
|
+
|
|
186
|
+
[[LLM: Synthesize all elements into a comprehensive, ready-to-use research prompt.]]
|
|
187
|
+
|
|
188
|
+
**Research Prompt Template:**
|
|
189
|
+
|
|
190
|
+
```markdown
|
|
191
|
+
## Research Objective
|
|
192
|
+
|
|
193
|
+
[Clear statement of what this research aims to achieve]
|
|
194
|
+
|
|
195
|
+
## Background Context
|
|
196
|
+
|
|
197
|
+
[Relevant information from project brief, brainstorming, or other inputs]
|
|
198
|
+
|
|
199
|
+
## Research Questions
|
|
200
|
+
|
|
201
|
+
### Primary Questions (Must Answer)
|
|
202
|
+
|
|
203
|
+
1. [Specific, actionable question]
|
|
204
|
+
2. [Specific, actionable question]
|
|
205
|
+
...
|
|
206
|
+
|
|
207
|
+
### Secondary Questions (Nice to Have)
|
|
208
|
+
|
|
209
|
+
1. [Supporting question]
|
|
210
|
+
2. [Supporting question]
|
|
211
|
+
...
|
|
212
|
+
|
|
213
|
+
## Research Methodology
|
|
214
|
+
|
|
215
|
+
### Information Sources
|
|
216
|
+
|
|
217
|
+
- [Specific source types and priorities]
|
|
218
|
+
|
|
219
|
+
### Analysis Frameworks
|
|
220
|
+
|
|
221
|
+
- [Specific frameworks to apply]
|
|
222
|
+
|
|
223
|
+
### Data Requirements
|
|
224
|
+
|
|
225
|
+
- [Quality, recency, credibility needs]
|
|
226
|
+
|
|
227
|
+
## Expected Deliverables
|
|
228
|
+
|
|
229
|
+
### Executive Summary
|
|
230
|
+
|
|
231
|
+
- Key findings and insights
|
|
232
|
+
- Critical implications
|
|
233
|
+
- Recommended actions
|
|
234
|
+
|
|
235
|
+
### Detailed Analysis
|
|
236
|
+
|
|
237
|
+
[Specific sections needed based on research type]
|
|
238
|
+
|
|
239
|
+
### Supporting Materials
|
|
240
|
+
|
|
241
|
+
- Data tables
|
|
242
|
+
- Comparison matrices
|
|
243
|
+
- Source documentation
|
|
244
|
+
|
|
245
|
+
## Success Criteria
|
|
246
|
+
|
|
247
|
+
[How to evaluate if research achieved its objectives]
|
|
248
|
+
|
|
249
|
+
## Timeline and Priority
|
|
250
|
+
|
|
251
|
+
[If applicable, any time constraints or phasing]
|
|
252
|
+
```
|
|
253
|
+
|
|
254
|
+
### 5. Review and Refinement
|
|
255
|
+
|
|
256
|
+
[[LLM: Present the draft research prompt for user review and refinement.]]
|
|
257
|
+
|
|
258
|
+
1. **Present Complete Prompt**
|
|
259
|
+
|
|
260
|
+
- Show the full research prompt
|
|
261
|
+
- Explain key elements and rationale
|
|
262
|
+
- Highlight any assumptions made
|
|
263
|
+
|
|
264
|
+
2. **Gather Feedback**
|
|
265
|
+
|
|
266
|
+
- Are the objectives clear and correct?
|
|
267
|
+
- Do the questions address all concerns?
|
|
268
|
+
- Is the scope appropriate?
|
|
269
|
+
- Are output requirements sufficient?
|
|
270
|
+
|
|
271
|
+
3. **Refine as Needed**
|
|
272
|
+
- Incorporate user feedback
|
|
273
|
+
- Adjust scope or focus
|
|
274
|
+
- Add missing elements
|
|
275
|
+
- Clarify ambiguities
|
|
276
|
+
|
|
277
|
+
### 6. Next Steps Guidance
|
|
278
|
+
|
|
279
|
+
[[LLM: Provide clear guidance on how to use the research prompt.]]
|
|
280
|
+
|
|
281
|
+
**Execution Options:**
|
|
282
|
+
|
|
283
|
+
1. **Use with AI Research Assistant**: Provide this prompt to an AI model with research capabilities
|
|
284
|
+
2. **Guide Human Research**: Use as a framework for manual research efforts
|
|
285
|
+
3. **Hybrid Approach**: Combine AI and human research using this structure
|
|
286
|
+
|
|
287
|
+
**Integration Points:**
|
|
288
|
+
|
|
289
|
+
- How findings will feed into next phases
|
|
290
|
+
- Which team members should review results
|
|
291
|
+
- How to validate findings
|
|
292
|
+
- When to revisit or expand research
|
|
293
|
+
|
|
294
|
+
## Important Notes
|
|
295
|
+
|
|
296
|
+
- The quality of the research prompt directly impacts the quality of insights gathered
|
|
297
|
+
- Be specific rather than general in research questions
|
|
298
|
+
- Consider both current state and future implications
|
|
299
|
+
- Balance comprehensiveness with focus
|
|
300
|
+
- Document assumptions and limitations clearly
|
|
301
|
+
- Plan for iterative refinement based on initial findings
|
|
@@ -0,0 +1,74 @@
|
|
|
1
|
+
# Create Document from Template Task
|
|
2
|
+
|
|
3
|
+
## Purpose
|
|
4
|
+
|
|
5
|
+
- Generate documents from any specified template following embedded instructions from the perspective of the selected agent persona
|
|
6
|
+
|
|
7
|
+
## Instructions
|
|
8
|
+
|
|
9
|
+
### 1. Identify Template and Context
|
|
10
|
+
|
|
11
|
+
- Determine which template to use (user-provided or list available for selection to user)
|
|
12
|
+
|
|
13
|
+
- Agent-specific templates are listed in the agent's dependencies under `templates`. For each template listed, consider it a document the agent can create. So if an agent has:
|
|
14
|
+
|
|
15
|
+
@{example}
|
|
16
|
+
dependencies:
|
|
17
|
+
templates: - prd-tmpl - architecture-tmpl
|
|
18
|
+
@{/example}
|
|
19
|
+
|
|
20
|
+
You would offer to create "PRD" and "Architecture" documents when the user asks what you can help with.
|
|
21
|
+
|
|
22
|
+
- Gather all relevant inputs, or ask for them, or else rely on user providing necessary details to complete the document
|
|
23
|
+
- Understand the document purpose and target audience
|
|
24
|
+
|
|
25
|
+
### 2. Determine Interaction Mode
|
|
26
|
+
|
|
27
|
+
Confirm with the user their preferred interaction style:
|
|
28
|
+
|
|
29
|
+
- **Incremental:** Work through chunks of the document.
|
|
30
|
+
- **YOLO Mode:** Draft complete document making reasonable assumptions in one shot. (Can be entered also after starting incremental by just typing /yolo)
|
|
31
|
+
|
|
32
|
+
### 3. Execute Template
|
|
33
|
+
|
|
34
|
+
- Load specified template from `templates#*` or the /templates directory
|
|
35
|
+
- Follow ALL embedded LLM instructions within the template
|
|
36
|
+
- Process template markup according to `utils#template-format` conventions
|
|
37
|
+
|
|
38
|
+
### 4. Template Processing Rules
|
|
39
|
+
|
|
40
|
+
#### CRITICAL: Never display template markup, LLM instructions, or examples to users
|
|
41
|
+
|
|
42
|
+
- Replace all {{placeholders}} with actual content
|
|
43
|
+
- Execute all [[LLM: instructions]] internally
|
|
44
|
+
- Process `<<REPEAT>>` sections as needed
|
|
45
|
+
- Evaluate ^^CONDITION^^ blocks and include only if applicable
|
|
46
|
+
- Use @{examples} for guidance but never output them
|
|
47
|
+
|
|
48
|
+
### 5. Content Generation
|
|
49
|
+
|
|
50
|
+
- **Incremental Mode**: Present each major section for review before proceeding
|
|
51
|
+
- **YOLO Mode**: Generate all sections, then review complete document with user
|
|
52
|
+
- Apply any elicitation protocols specified in template
|
|
53
|
+
- Incorporate user feedback and iterate as needed
|
|
54
|
+
|
|
55
|
+
### 6. Validation
|
|
56
|
+
|
|
57
|
+
If template specifies a checklist:
|
|
58
|
+
|
|
59
|
+
- Run the appropriate checklist against completed document
|
|
60
|
+
- Document completion status for each item
|
|
61
|
+
- Address any deficiencies found
|
|
62
|
+
- Present validation summary to user
|
|
63
|
+
|
|
64
|
+
### 7. Final Presentation
|
|
65
|
+
|
|
66
|
+
- Present clean, formatted content only
|
|
67
|
+
- Ensure all sections are complete
|
|
68
|
+
- DO NOT truncate or summarize content
|
|
69
|
+
- Begin directly with document content (no preamble)
|
|
70
|
+
- Include any handoff prompts specified in template
|
|
71
|
+
|
|
72
|
+
## Important Notes
|
|
73
|
+
|
|
74
|
+
- Template markup is for AI processing only - never expose to users
|