checklist standardization and improvement with llm eliciatation
This commit is contained in:
@@ -4,10 +4,42 @@
|
||||
|
||||
**Instructions:** Review each item with the user. Mark `[x]` for completed/confirmed, `[N/A]` if not applicable, or add notes for discussion points.
|
||||
|
||||
[[LLM: INITIALIZATION INSTRUCTIONS - CHANGE NAVIGATION
|
||||
|
||||
Changes during development are inevitable, but how we handle them determines project success or failure.
|
||||
|
||||
Before proceeding, understand:
|
||||
|
||||
1. This checklist is for SIGNIFICANT changes that affect the project direction
|
||||
2. Minor adjustments within a story don't require this process
|
||||
3. The goal is to minimize wasted work while adapting to new realities
|
||||
4. User buy-in is critical - they must understand and approve changes
|
||||
|
||||
Required context:
|
||||
|
||||
- The triggering story or issue
|
||||
- Current project state (completed stories, current epic)
|
||||
- Access to PRD, architecture, and other key documents
|
||||
- Understanding of remaining work planned
|
||||
|
||||
APPROACH:
|
||||
This is an interactive process with the user. Work through each section together, discussing implications and options. The user makes final decisions, but provide expert guidance on technical feasibility and impact.
|
||||
|
||||
REMEMBER: Changes are opportunities to improve, not failures. Handle them professionally and constructively.]]
|
||||
|
||||
---
|
||||
|
||||
## 1. Understand the Trigger & Context
|
||||
|
||||
[[LLM: Start by fully understanding what went wrong and why. Don't jump to solutions yet. Ask probing questions:
|
||||
|
||||
- What exactly happened that triggered this review?
|
||||
- Is this a one-time issue or symptomatic of a larger problem?
|
||||
- Could this have been anticipated earlier?
|
||||
- What assumptions were incorrect?
|
||||
|
||||
Be specific and factual, not blame-oriented.]]
|
||||
|
||||
- [ ] **Identify Triggering Story:** Clearly identify the story (or stories) that revealed the issue.
|
||||
- [ ] **Define the Issue:** Articulate the core problem precisely.
|
||||
- [ ] Is it a technical limitation/dead-end?
|
||||
@@ -20,6 +52,15 @@
|
||||
|
||||
## 2. Epic Impact Assessment
|
||||
|
||||
[[LLM: Changes ripple through the project structure. Systematically evaluate:
|
||||
|
||||
1. Can we salvage the current epic with modifications?
|
||||
2. Do future epics still make sense given this change?
|
||||
3. Are we creating or eliminating dependencies?
|
||||
4. Does the epic sequence need reordering?
|
||||
|
||||
Think about both immediate and downstream effects.]]
|
||||
|
||||
- [ ] **Analyze Current Epic:**
|
||||
- [ ] Can the current epic containing the trigger story still be completed?
|
||||
- [ ] Does the current epic need modification (story changes, additions, removals)?
|
||||
@@ -34,6 +75,15 @@
|
||||
|
||||
## 3. Artifact Conflict & Impact Analysis
|
||||
|
||||
[[LLM: Documentation drives development in BMAD. Check each artifact:
|
||||
|
||||
1. Does this change invalidate documented decisions?
|
||||
2. Are architectural assumptions still valid?
|
||||
3. Do user flows need rethinking?
|
||||
4. Are technical constraints different than documented?
|
||||
|
||||
Be thorough - missed conflicts cause future problems.]]
|
||||
|
||||
- [ ] **Review PRD:**
|
||||
- [ ] Does the issue conflict with the core goals or requirements stated in the PRD?
|
||||
- [ ] Does the PRD need clarification or updates based on the new understanding?
|
||||
@@ -52,6 +102,16 @@
|
||||
|
||||
## 4. Path Forward Evaluation
|
||||
|
||||
[[LLM: Present options clearly with pros/cons. For each path:
|
||||
|
||||
1. What's the effort required?
|
||||
2. What work gets thrown away?
|
||||
3. What risks are we taking?
|
||||
4. How does this affect timeline?
|
||||
5. Is this sustainable long-term?
|
||||
|
||||
Be honest about trade-offs. There's rarely a perfect solution.]]
|
||||
|
||||
- [ ] **Option 1: Direct Adjustment / Integration:**
|
||||
- [ ] Can the issue be addressed by modifying/adding future stories within the existing plan?
|
||||
- [ ] Define the scope and nature of these adjustments.
|
||||
@@ -72,6 +132,16 @@
|
||||
|
||||
## 5. Sprint Change Proposal Components
|
||||
|
||||
[[LLM: The proposal must be actionable and clear. Ensure:
|
||||
|
||||
1. The issue is explained in plain language
|
||||
2. Impacts are quantified where possible
|
||||
3. The recommended path has clear rationale
|
||||
4. Next steps are specific and assigned
|
||||
5. Success criteria for the change are defined
|
||||
|
||||
This proposal guides all subsequent work.]]
|
||||
|
||||
(Ensure all agreed-upon points from previous sections are captured in the proposal)
|
||||
|
||||
- [ ] **Identified Issue Summary:** Clear, concise problem statement.
|
||||
@@ -84,6 +154,26 @@
|
||||
|
||||
## 6. Final Review & Handoff
|
||||
|
||||
[[LLM: Changes require coordination. Before concluding:
|
||||
|
||||
1. Is the user fully aligned with the plan?
|
||||
2. Do all stakeholders understand the impacts?
|
||||
3. Are handoffs to other agents clear?
|
||||
4. Is there a rollback plan if the change fails?
|
||||
5. How will we validate the change worked?
|
||||
|
||||
Get explicit approval - implicit agreement causes problems.
|
||||
|
||||
FINAL REPORT:
|
||||
After completing the checklist, provide a concise summary:
|
||||
|
||||
- What changed and why
|
||||
- What we're doing about it
|
||||
- Who needs to do what
|
||||
- When we'll know if it worked
|
||||
|
||||
Keep it action-oriented and forward-looking.]]
|
||||
|
||||
- [ ] **Review Checklist:** Confirm all relevant items were discussed.
|
||||
- [ ] **Review Sprint Change Proposal:** Ensure it accurately reflects the discussion and decisions.
|
||||
- [ ] **User Approval:** Obtain explicit user approval for the proposal.
|
||||
|
||||
Reference in New Issue
Block a user