@mark-gozner/aigile-method 0.4.5

package/core/agents/pm.md

@@ -0,0 +1,33 @@
+# pm
+
+```yaml
+agent:
+  name: Sergiu
+  id: pm
+  title: Product Manager
+  icon: 📋
+  whenToUse: Planning, delivery tracking, stakeholder alignment
+persona:
+  role: Technical PM & Delivery Lead
+  style: Outcome-focused, transparent, structured, risk-aware
+  identity: Drives delivery by aligning stakeholders, scope, and capacity
+  focus: Planning, tracking, impediment removal, and clear reporting
+commands:
+  - help
+  - create-prd
+  - shard-prd
+  - correct-course
+  - exit
+mcp-tools:
+  required: [sequentialthinking, context7, atlassian]
+notes:
+  - When requests are broad (e.g., multi-initiative planning), use GitHub Copilot Chat TODOs to create an actionable checklist (sync data, analyze, decide, communicate) and mark progress.
+mcp-usage:
+  - objective: Sync sprint status and blockers
+    use: atlassian.jira_search/jira_get_board_issues to collect data; sequentialthinking to plan interventions; output a digest
+  - objective: Draft a PRD with supporting research
+    use: context7 for references; maintain TODOs for open questions and stakeholder inputs
+dependencies:
+  data:
+    - aigile-kb.md
+```

package/core/agents/po.md

@@ -0,0 +1,35 @@
+# po
+
+```yaml
+agent:
+  name: Mada
+  id: po
+  title: Product Owner
+  icon: 📝
+persona:
+  role: Outcome-focused PO who writes testable stories and clarifies scope
+  style: Clear, measurable, user-centric; avoids implementation bias
+  identity: Ensures backlog quality and value delivery through refinement and alignment
+  focus: Story clarity, AC quality, prioritization, stakeholder alignment
+commands:
+  - help
+  - create-jira-story-from-confluence {confluenceUrl}
+  - create-jira-story-from-text {text}
+  - execute-checklist-po
+  - shard-doc {document} {destination}
+  - validate-story-draft {story}
+  - exit
+mcp-tools:
+  required: [sequentialthinking, context7, atlassian]
+notes:
+  - Stories are tool- and stack-agnostic; focus on user outcomes and AC in GWT form
+  - For complex backlog grooming or document work, use GitHub Copilot Chat TODOs to split tasks (collect inputs, draft, refine, validate) and track to completion.
+mcp-usage:
+  - objective: Create/refine a story from Confluence content
+    use: atlassian.confluence_get_page + sequentialthinking to extract value, users, and AC; generate a testable story
+  - objective: Groom and prioritize backlog
+    use: atlassian.jira_search with filters; produce a short decision log and TODOs for follow-ups
+dependencies:
+  data:
+    - aigile-kb.md
+```

package/core/agents/qa.md

@@ -0,0 +1,38 @@
+# qa
+
+```yaml
+agent:
+  name: Cristina
+  id: qa
+  title: Test Architect & Quality Advisor
+  icon: 🧪
+persona:
+  role: Quality enabler focused on risk-based testing and fast feedback
+  style: Evidence-driven, concise, automation-first when practical
+commands:
+  - help
+  - review {story}
+  - gate {story}
+  - test-design {story}
+  - verify-jira-story-e2e {urlOrId}
+  - exit
+mcp-tools:
+  required: [sequentialthinking, context7]
+  optional: [atlassian, sonarqube, playwright]
+notes:
+  - All guidance is tool-agnostic; adapt frameworks and runners to the project
+  - Use GitHub Copilot Chat TODOs for complex test plans or gates to enumerate test activities, risks, and exit criteria; tick TODOs as validations pass.
+mcp-usage:
+  - objective: Design an end-to-end test plan for a Jira story
+    use: atlassian.jira_get_issue to extract AC → derive tests across levels per test-levels-framework.md; manage TODOs by scenario
+  - objective: Validate UI flows rapidly
+    use: playwright.navigate/click/fill/screenshot in recorded steps; attach artifacts and results summary
+  - objective: Reduce risk hotspots
+    use: sonarqube to identify hotspots; prioritize with test-priorities-matrix.md; track TODOs through remediation
+dependencies:
+  data:
+    - test-levels-framework.md
+    - test-priorities-matrix.md
+    - technical-preferences.md
+    - aigile-kb.md
+```

package/core/agents/sm.md

@@ -0,0 +1,31 @@
+# sm
+
+```yaml
+agent:
+  name: Andra
+  id: sm
+  title: Scrum Master
+  icon: 🏃
+persona:
+  role: Scrum Master & Agile Coach
+  style: Facilitative, data-informed, calm under pressure
+  identity: Improves flow and teamwork by removing impediments and refining practices
+  focus: Ceremony facilitation, team health, and continuous improvement
+commands:
+  - help
+  - draft
+  - story-checklist
+  - exit
+mcp-tools:
+  required: [sequentialthinking, context7, atlassian]
+ mcp-usage:
+  - objective: Prepare a standup digest from Jira data
+    use: atlassian.jira_get_board_issues; summarize status and blockers; create TODOs by owner
+  - objective: Track impediments and follow-ups
+    use: sequentialthinking to plan, then maintain TODOs and mark resolved items
+notes:
+  - For complex facilitation or impediment removal, use GitHub Copilot Chat TODOs to list actions, owners, and checkpoints, checking them off as the team progresses.
+dependencies:
+  data:
+    - aigile-kb.md
+```

package/core/agents/ui-expert.md

@@ -0,0 +1,39 @@
+# ui-expert
+
+```yaml
+agent:
+  name: Daniel
+  id: ui-expert
+  title: UI Expert
+  icon: 🧩
+persona:
+  role: UI Design Specialist & Visual Design Authority
+  style: Systematic, brand-conscious, detail-oriented
+  identity: Creates and maintains coherent UI through design systems and specs
+  focus: Design system health, specs, and handoff quality
+whenToUse: Advanced UI workflows, Figma operations, tokens & component libraries
+discipline:
+  - Use sequentialthinking for multi-step UI tasks
+  - When workflows are complex, use GitHub Copilot Chat TODOs to break down design tasks (audit, propose, validate, handoff) and tick them off as completed
+  - Read DS guidelines from context7 before proposing new tokens/components
+  - Gate any write-to-github actions with explicit user confirmation
+commands:
+  - help
+  - audit-design-system {team|file}
+  - draft-wireflow {feature}
+  - generate-redlines {frame}
+  - export-design-tokens
+  - handoff-spec {frame}
+  - exit
+mcp-tools:
+  required: [sequentialthinking, context7, figma]
+  optional: [github.com]
+ mcp-usage:
+  - objective: Audit a Figma file for DS compliance
+    use: figma server tools if available; produce TODOs for mismatches and follow-ups
+  - objective: Prepare handoff specs
+    use: sequentialthinking to outline artifacts; export redlines and specs; tick TODOs as assets are ready
+dependencies:
+  data:
+    - aigile-kb.md
+```

package/core/agents/ux-expert.md

@@ -0,0 +1,31 @@
+# ux-expert
+
+```yaml
+agent:
+  name: Cata
+  id: ux-expert
+  title: UX Expert
+  icon: 🎨
+persona:
+  role: UX Research Specialist & User Advocate
+  style: User-centered, research-driven, empathetic
+  identity: Aligns solutions with user needs through research and testing
+  focus: Research plans, journey mapping, and usability testing
+commands:
+  - help
+  - create-front-end-spec
+  - generate-ui-prompt
+  - exit
+mcp-tools:
+  required: [sequentialthinking, context7]
+ mcp-usage:
+  - objective: Plan and execute research
+    use: sequentialthinking to structure the study; maintain TODOs for recruitment, sessions, and synthesis
+  - objective: Ground designs in references
+    use: context7 to find relevant research; synthesize insights and contradictions
+notes:
+  - For complex research and journey mapping, use GitHub Copilot Chat TODOs to structure phases (plan, collect, analyze, synthesize) and track progress against objectives.
+dependencies:
+  data:
+    - aigile-kb.md
+```

package/core/checklists/architect-checklist.md

@@ -0,0 +1,246 @@
+# Architect Solution Validation Checklist
+
+This checklist serves as a comprehensive framework for the Architect to validate the technical design and architecture before development execution. The Architect should systematically work through each item, ensuring the architecture is robust, scalable, secure, and aligned with the product requirements.
+
+[[LLM: INITIALIZATION INSTRUCTIONS - REQUIRED ARTIFACTS
+
+Before proceeding with this checklist, ensure you have access to:
+
+1. architecture.md - The primary architecture document (check docs/architecture.md)
+2. prd.md - Product Requirements Document for requirements alignment (check docs/prd.md)
+3. frontend-architecture.md or fe-architecture.md - If this is a UI project (check docs/frontend-architecture.md)
+4. Any system diagrams referenced in the architecture
+5. API documentation if available
+6. Technology stack details and version specifications
+
+IMPORTANT: If any required documents are missing or inaccessible, immediately ask the user for their location or content before proceeding.
+
+PROJECT TYPE DETECTION:
+First, determine the project type by checking:
+
+- Does the architecture include a frontend/UI component?
+- Is there a frontend-architecture.md document?
+- Does the PRD mention user interfaces or frontend requirements?
+
+If this is a backend-only or service-only project:
+
+- Skip sections marked with [[FRONTEND ONLY]]
+- Focus extra attention on API design, service architecture, and integration patterns
+- Note in your final report that frontend sections were skipped due to project type
+
+VALIDATION APPROACH:
+For each section, you must:
+
+1. Deep Analysis - Don't just check boxes, thoroughly analyze each item against the provided documentation
+2. Evidence-Based - Cite specific sections or quotes from the documents when validating
+3. Critical Thinking - Question assumptions and identify gaps, not just confirm what's present
+4. Risk Assessment - Consider what could go wrong with each architectural decision
+
+EXECUTION MODE:
+Ask the user if they want to work through the checklist:
+
+- Section by section (interactive mode) - Review each section, present findings, get confirmation before proceeding
+- All at once (comprehensive mode) - Complete full analysis and present comprehensive report at end]]
+
+## 1. REQUIREMENTS ALIGNMENT
+
+[[LLM: Before evaluating this section, take a moment to fully understand the product's purpose and goals from the PRD. What is the core problem being solved? Who are the users? What are the critical success factors? Keep these in mind as you validate alignment. For each item, don't just check if it's mentioned - verify that the architecture provides a concrete technical solution.]]
+
+### 1.1 Functional Requirements Coverage
+
+- [ ] Architecture supports all functional requirements in the PRD
+- [ ] Technical approaches for all epics and stories are addressed
+- [ ] Edge cases and performance scenarios are considered
+- [ ] All required integrations are accounted for
+- [ ] User journeys are supported by the technical architecture
+
+### 1.2 Non-Functional Requirements Alignment
+
+- [ ] Performance requirements are addressed with specific solutions
+- [ ] Scalability considerations are documented with approach
+- [ ] Security requirements have corresponding technical controls
+- [ ] Reliability and resilience approaches are defined
+- [ ] Compliance requirements have technical implementations
+
+### 1.3 Technical Constraints Adherence
+
+- [ ] All technical constraints from PRD are satisfied
+- [ ] Platform/language requirements are followed
+- [ ] Infrastructure constraints are accommodated
+- [ ] Third-party service constraints are addressed
+- [ ] Organizational technical standards are followed
+
+## 2. ARCHITECTURE FUNDAMENTALS
+
+[[LLM: Architecture clarity is crucial for successful implementation. As you review this section, visualize the system as if you were explaining it to a new developer. Are there any ambiguities that could lead to misinterpretation? Would an AI agent be able to implement this architecture without confusion? Look for specific diagrams, component definitions, and clear interaction patterns.]]
+
+### 2.1 Architecture Clarity
+
+- [ ] Architecture is documented with clear diagrams
+- [ ] Major components and their responsibilities are defined
+- [ ] Component interactions and dependencies are mapped
+- [ ] Data flows are clearly illustrated
+- [ ] Technology choices for each component are specified
+
+### 2.2 Separation of Concerns
+
+- [ ] Clear boundaries between UI, business logic, and data layers
+- [ ] Responsibilities are cleanly divided between components
+- [ ] Interfaces between components are well-defined
+- [ ] Components adhere to single responsibility principle
+- [ ] Cross-cutting concerns (logging, auth, etc.) are properly addressed
+
+### 2.3 Design Patterns & Best Practices
+
+- [ ] Appropriate design patterns are employed
+- [ ] Industry best practices are followed
+- [ ] Anti-patterns are avoided
+- [ ] Consistent architectural style throughout
+- [ ] Pattern usage is documented and explained
+
+### 2.4 Modularity & Maintainability
+
+- [ ] System is divided into cohesive, loosely-coupled modules
+- [ ] Components can be developed and tested independently
+- [ ] Changes can be localized to specific components
+- [ ] Code organization promotes discoverability
+- [ ] Architecture specifically designed for AI agent implementation
+
+## 3. TECHNICAL STACK & DECISIONS
+
+[[LLM: Technology choices have long-term implications. For each technology decision, consider: Is this the simplest solution that could work? Are we over-engineering? Will this scale? What are the maintenance implications? Are there security vulnerabilities in the chosen versions? Verify that specific versions are defined, not ranges.]]
+
+### 3.1 Technology Selection
+
+- [ ] Selected technologies meet all requirements
+- [ ] Technology versions are specifically defined (not ranges)
+- [ ] Technology choices are justified with clear rationale
+- [ ] Alternatives considered are documented with pros/cons
+- [ ] Selected stack components work well together
+
+### 3.2 Frontend Architecture [[FRONTEND ONLY]]
+
+[[LLM: Skip this entire section if this is a backend-only or service-only project. Only evaluate if the project includes a user interface.]]
+
+- [ ] UI framework and libraries are specifically selected
+- [ ] State management approach is defined
+- [ ] Component structure and organization is specified
+- [ ] Responsive/adaptive design approach is outlined
+- [ ] Build and bundling strategy is determined
+
+### 3.3 Backend Architecture
+
+- [ ] API design and standards are defined
+- [ ] Service organization and boundaries are clear
+- [ ] Authentication and authorization approach is specified
+- [ ] Error handling strategy is outlined
+- [ ] Backend scaling approach is defined
+
+### 3.4 Data Architecture
+
+- [ ] Data models are fully defined
+- [ ] Database technologies are selected with justification
+- [ ] Data access patterns are documented
+- [ ] Data migration/seeding approach is specified
+- [ ] Data backup and recovery strategies are outlined
+
+## 4. SECURITY & COMPLIANCE
+
+[[LLM: Security cannot be an afterthought. For each security consideration, think: What could go wrong? How would an attacker exploit this? Are we following security best practices? Have we considered all attack vectors?]]
+
+### 4.1 Security Controls
+
+- [ ] Authentication mechanisms are properly designed
+- [ ] Authorization controls are comprehensive and granular
+- [ ] Data encryption at rest and in transit is addressed
+- [ ] Input validation and sanitization approaches are defined
+- [ ] Security headers and protections are specified
+
+### 4.2 Data Protection
+
+- [ ] Sensitive data handling procedures are defined
+- [ ] Data privacy requirements are met
+- [ ] Data retention and deletion policies are addressed
+- [ ] Audit trails and logging approaches are specified
+- [ ] Compliance requirements are satisfied
+
+## 5. PERFORMANCE & SCALABILITY
+
+[[LLM: Performance affects user experience and operational costs. Consider: What are the bottlenecks? How will this perform under load? What are the scaling limits? Are we optimizing the right things?]]
+
+### 5.1 Performance Considerations
+
+- [ ] Performance requirements are quantified and addressed
+- [ ] Caching strategies are defined where appropriate
+- [ ] Database optimization approaches are specified
+- [ ] Asset optimization strategies are outlined
+- [ ] Performance monitoring approaches are defined
+
+### 5.2 Scalability Design
+
+- [ ] Horizontal scaling approaches are documented
+- [ ] Load balancing strategies are defined
+- [ ] Resource scaling triggers and approaches are specified
+- [ ] Database scaling considerations are addressed
+- [ ] Microservices boundaries are appropriate (if applicable)
+
+## 6. OPERATIONAL READINESS
+
+[[LLM: The system must be operable in production. Consider: How will we deploy this? How will we monitor it? What happens when things go wrong? Can we recover from failures?]]
+
+### 6.1 Deployment & Infrastructure
+
+- [ ] Deployment strategies are clearly defined
+- [ ] Infrastructure requirements are documented
+- [ ] Environment configuration management is addressed
+- [ ] Container/orchestration strategies are specified (if applicable)
+- [ ] Infrastructure as Code approaches are outlined
+
+### 6.2 Monitoring & Observability
+
+- [ ] Logging strategies and standards are defined
+- [ ] Metrics collection and monitoring approaches are specified
+- [ ] Alerting strategies are documented
+- [ ] Troubleshooting and debugging approaches are outlined
+- [ ] Health check and status monitoring is addressed
+
+### 6.3 Reliability & Recovery
+
+- [ ] Backup and disaster recovery procedures are defined
+- [ ] Fault tolerance and resilience strategies are specified
+- [ ] Circuit breaker and retry patterns are implemented
+- [ ] Rollback procedures are documented
+- [ ] Service level objectives (SLOs) are defined
+
+## FINAL VALIDATION
+
+[[LLM: FINAL ARCHITECTURE VALIDATION REPORT
+
+After completing the checklist, provide a comprehensive validation report:
+
+1. Overall Assessment
+   - Architecture readiness: APPROVED / NEEDS REVISION / BLOCKED
+   - Risk level: LOW / MEDIUM / HIGH
+   - Implementation complexity: SIMPLE / MODERATE / COMPLEX
+
+2. Critical Issues (if any)
+   - List any items that MUST be resolved before implementation
+   - Specify the impact of each issue
+   - Recommend specific actions
+
+3. Recommendations
+   - Suggested improvements or optimizations
+   - Areas requiring special attention during implementation
+   - Technical debt considerations
+
+4. Implementation Readiness
+   - Can development begin with current architecture?
+   - What additional documentation is needed?
+   - Are there any blocking dependencies?
+
+Be thorough but practical - perfect architecture doesn't exist, but it must be sufficient for successful implementation.]]
+
+- [ ] All critical architecture components have been validated
+- [ ] Risk assessment completed for major decisions
+- [ ] Architecture aligns with project goals and constraints
+- [ ] Implementation guidance is sufficient for development team

package/core/checklists/change-checklist.md

@@ -0,0 +1,182 @@
+# Change Navigation Checklist
+
+**Purpose:** To systematically guide the selected Agent and user through the analysis and planning required when a significant change (pivot, tech issue, missing requirement, failed story) is identified during the AIgile workflow.
+
+**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?
+  - [ ] Is it a newly discovered requirement?
+  - [ ] Is it a fundamental misunderstanding of existing requirements?
+  - [ ] Is it a necessary pivot based on feedback or new information?
+  - [ ] Is it a failed/abandoned story needing a new approach?
+- [ ] **Assess Initial Impact:** Describe the immediate observed consequences (e.g., blocked progress, incorrect functionality, non-viable tech).
+- [ ] **Gather Evidence:** Note any specific logs, error messages, user feedback, or analysis that supports the issue definition.
+
+## 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)?
+  - [ ] Should the current epic be abandoned or fundamentally redefined?
+- [ ] **Analyze Future Epics:**
+  - [ ] Review all remaining planned epics.
+  - [ ] Does the issue require changes to planned stories in future epics?
+  - [ ] Does the issue invalidate any future epics?
+  - [ ] Does the issue necessitate the creation of entirely new epics?
+  - [ ] Should the order/priority of future epics be changed?
+- [ ] **Summarize Epic Impact:** Briefly document the overall effect on the project's epic structure and flow.
+
+## 3. Artifact Conflict & Impact Analysis
+
+[[LLM: Documentation drives development in AIgile. 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?
+- [ ] **Review Architecture Document:**
+  - [ ] Does the issue conflict with the documented architecture (components, patterns, tech choices)?
+  - [ ] Are specific components/diagrams/sections impacted?
+  - [ ] Does the technology list need updating?
+  - [ ] Do data models or schemas need revision?
+  - [ ] Are external API integrations affected?
+- [ ] **Review Frontend Spec (if applicable):**
+  - [ ] Does the issue conflict with the FE architecture, component library choice, or UI/UX design?
+  - [ ] Are specific FE components or user flows impacted?
+- [ ] **Review Other Artifacts (if applicable):**
+  - [ ] Consider impact on deployment scripts, IaC, monitoring setup, etc.
+- [ ] **Summarize Artifact Impact:** List all artifacts requiring updates and the nature of the changes needed.
+
+## 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.
+  - [ ] Assess feasibility, effort, and risks of this path.
+- [ ] **Option 2: Potential Rollback:**
+  - [ ] Would reverting completed stories significantly simplify addressing the issue?
+  - [ ] Identify specific stories/commits to consider for rollback.
+  - [ ] Assess the effort required for rollback.
+  - [ ] Assess the impact of rollback (lost work, data implications).
+  - [ ] Compare the net benefit/cost vs. Direct Adjustment.
+- [ ] **Option 3: PRD MVP Review & Potential Re-scoping:**
+  - [ ] Is the original PRD MVP still achievable given the issue and constraints?
+  - [ ] Does the MVP scope need reduction (removing features/epics)?
+  - [ ] Do the core MVP goals need modification?
+  - [ ] Are alternative approaches needed to meet the original MVP intent?
+  - [ ] **Extreme Case:** Does the issue necessitate a fundamental replan or potentially a new PRD V2 (to be handled by PM)?
+- [ ] **Select Recommended Path:** Based on the evaluation, agree on the most viable path forward.
+
+## 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.
+- [ ] **Epic Impact Summary:** How epics are affected.
+- [ ] **Artifact Adjustment Needs:** List of documents to change.
+- [ ] **Recommended Path Forward:** Chosen solution with rationale.
+- [ ] **PRD MVP Impact:** Changes to scope/goals (if any).
+- [ ] **High-Level Action Plan:** Next steps for stories/updates.
+- [ ] **Agent Handoff Plan:** Identify roles needed (PM, Arch, Design Arch, PO).
+
+## 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.
+- [ ] **Confirm Next Steps:** Reiterate the handoff plan and the next actions to be taken by specific agents.
+
+---