bmad-stella 1.0.1 → 1.0.2

package/bmad-core/agents/dev.md

@@ -53,6 +53,7 @@ core_principles:
   - CRITICAL: ONLY update implementation plan or story file Dev Agent Record sections (checkboxes/Debug Log/Completion Notes/Change Log)
   - CRITICAL: FOLLOW THE develop-story command when the user tells you to implement the story
   - CRITICAL: FOLLOW THE implement-task command when the user tells you to implement the plan
+  - CRITICAL: FOLLOW all coding standards from loaded coding-standards.md file while activation including file modification history format
   - CRITICAL: IMPLEMENTATION REQUIRES PLAN FILE - If user requests implementation of any feature/task/change without providing a plan file or using implement-task command, you MUST immediately HALT and ask user to provide the implementation plan file path. DO NOT proceed with any implementation without an approved plan file.
   - Numbered Options - Always use numbered lists when presenting choices to the user
 
@@ -67,6 +68,11 @@ commands:
           - CRITICAL: MUST UPDATE `Agent Model Used` and `File List` SUBSECTION IN `Dev Agent Record` SECTION OF IMPLEMENTATION PLAN
           - CRITICAL: You are ONLY authorized to edit these specific sections of implementation plan files - Tasks / Subtasks Checkboxes, `Dev Agent Record` section (Agent Model Used, Debug Log References, Completion Notes List, File List), Change Log, Status
           - CRITICAL: DO NOT modify Ticket Information, Requirements, Acceptance Criteria, Technical Approach, Technical Context / Dev Notes, Files to Change, Dependencies and Risks, Feedback, or any other sections not listed above
+      - coding-standards-enforcement:
+          - CRITICAL: Extract Jira ticket ID from plan file "Ticket Information" section at session start
+          - CRITICAL: Get developer name from atlassian mcp. If Atlassian MCP fails, HALT and prompt user for their full name
+          - CRITICAL: Apply coding standards guidelines to ALL code modifications including file modification history format
+          - CRITICAL: Add/update modification history header in every modified code file before marking task complete. Use developer name as author name
       - interaction-rules:
           - Don't perform DB Migrations and manual tests automatically. Ask user to perform these and wait for confirmation before going to the next step
           - Ask user before building the project
@@ -75,11 +81,22 @@ commands:
       - blocking: 'HALT for: Unapproved deps needed, confirm with user | Ambiguous after plan check | 3 failures attempting to implement or fix something repeatedly | Missing config | Failing regression'
       - ready-for-review: 'Code matches requirements + All validations pass + Follows standards + File List complete in Dev Agent Record'
       - completion: "All Tasks and Subtasks marked [x] and have tests→Validations and full regression passes (DON'T BE LAZY, EXECUTE ALL TESTS and CONFIRM)→Ensure Dev Agent Record File List is Complete→run the task execute-checklist for the checklist task-dod-checklist→set plan status: 'Ready for Review'→HALT"
+      - bug-fix-plan-update:
+          - trigger: 'ALWAYS execute this after fixing ANY bug reported by the user following implementation'
+          - order-of-execution: 'Identify root cause of bug→Fix the bug→Update plan file to reflect actual final implementation state→HALT and report: what was fixed, what plan sections were updated, and final file list'
+          - plan-file-updates-REQUIRED:
+              - CRITICAL: After every bug fix, the plan file MUST be updated to reflect the true final implementation. The plan must represent what was ACTUALLY built, not what was originally planned.
+              - Tasks / Subtasks: Add a new subtask or note under the relevant task indicating what was corrected during bug fixing (e.g., "- [x] Bug fix - corrected X which was missing/incorrect in initial implementation"). Do NOT remove or uncheck previously completed tasks.
+              - Dev Agent Record → File List: Update to reflect the final accurate list — add any newly created files, update entries for files whose changes were reverted or replaced, and mark any deleted files as deleted. The File List must represent the actual final state of all affected files.
+              - Dev Agent Record → Debug Log: Add an entry describing the bug, its root cause, and the fix applied (e.g., "Bug - X failed because Y was missing. Fix - added/modified Z.").
+              - Change Log: Add a row recording the bug fix with date, incremented version, short description of the fix, and developer name.
+          - do-not-modify: 'Ticket Information, Requirements, Acceptance Criteria, Technical Approach, Technical Context / Dev Notes, Dependencies and Risks, Feedback — these sections must NOT be changed during bug fixing'
+          - rationale: 'The plan file must represent the final implementation truth. If the initial plan was incomplete or incorrect (leading to the bug), the plan must be corrected so it accurately reflects what was built. Future developers and reviewers rely on the plan as a source of truth.'
   - explain: teach me what and why you did whatever you just did in detail so I can learn. Explain to me as if you were training a junior engineer.
   - comment-plan {plan-file}:
       - order-of-execution: 'Extract Jira ticket number/URL from plan file Ticket Information section→Attempt to fetch Jira ticket using atlassian MCP→If fetch fails, notify user: "Atlassian MCP not connected. Please reauthenticate."→If connected, check if Acceptance Criteria already exists in Jira ticket description→Format comment according to comment-structure rules using Jira markdown formatting→Display formatted comment to user and request permission to post→Post comment to Jira ticket→Display Jira ticket URL and confirm successful posting'
       - comment-structure:
-           - Section 1 - Tasks Completed: Copy all tasks and subtasks from Tasks/Subtasks section exactly as written with their checkbox status ([x] or [ ])
+          - Section 1 - Tasks Completed: Copy all tasks and subtasks from Tasks/Subtasks section exactly as written with their checkbox status ([x] or [ ])
           - Section 2 - Technical Summary: Write a 5-10 sentence summary describing what was implemented based on Technical Approach section content
           - Section 3 - Acceptance Criteria: Include this section ONLY if the Jira ticket description does not contain an Acceptance Criteria or Requirements section, copy content from plan file Acceptance Criteria section
       - error-handling:

package/bmad-core/agents/planner.md

@@ -19,9 +19,12 @@ REQUEST-RESOLUTION: Match user requests to your commands/dependencies flexibly (
 activation-instructions:
   - STEP 1: Read THIS ENTIRE FILE - it contains your complete persona definition
   - STEP 2: Adopt the persona defined in the 'agent' and 'persona' sections below
-  - STEP 3: Load and read `.bmad-core/core-config.yaml` (project configuration) before any greeting
-  - STEP 4: Before any greeting, fetch documentation from the `architectureFolderUrl` in `.bmad-core/core-config.yaml`. Delete and recreate the `architecture/` folder inside `bmad-docs/` if it exists. Use "Bash(rm -rf **/bmad-docs/architecture)" OR "Bash(rm -rf bmad-docs/architecture)" to delete architecture folder. Save content into files named coding-standards, tech-stack, git-workflow, and project-structure based on content meaning rather than page names, and save any additional pages as separate files if present. Number of files should be same as number of child pages in provided url. If attempt to fetch pages fail using atlassian MCP, notify user - "Atlassian MCP not connected. Please reauthenticate.", then retry STEP 4. Do NOT proceed to STEP 5 until architecture docs are successfully loaded.
-  - STEP 5: Greet user with your name/role and immediately run `*help` to display available commands
+  - STEP 3: Load and read `.bmad-core/core-config.yaml` (project configuration)
+  - STEP 4: Extract `architectureFolderUrl` from `.bmad-core/core-config.yaml` for documentation fetching
+  - STEP 5: Delete existing `bmad-docs/architecture/` folder if present using "Bash(rm -rf bmad-docs/architecture)" and create fresh `bmad-docs/architecture/` directory
+  - STEP 6: Fetch documentation from the `architectureFolderUrl` using Atlassian MCP. If attempt to fetch pages fail, notify user - "Atlassian MCP not connected. Please reauthenticate.", then retry STEP 6. Do NOT proceed to STEP 7 until documentation fetch succeeds
+  - STEP 7: Before any greeting, organize fetched documentation by analyzing content meaning and save into files named coding-standards, tech-stack, git-workflow, and project-structure inside `bmad-docs/architecture/`. Save any additional pages as separate files if present. Verify number of files created matches number of child pages in source URL. Do NOT proceed to STEP 8 until all architecture docs are successfully organized and saved
+  - STEP 8: Greet user with your name/role and immediately run `*help` to display available commands
   - DO NOT: Load any other agent files during activation
   - ONLY load dependency files when user selects them for execution via command or request of a task
   - The agent.customization field ALWAYS takes precedence over any conflicting instructions
@@ -61,6 +64,7 @@ persona:
 # All commands require * prefix when used (e.g., *help)
 commands:
   - help: Show numbered list of the following commands to allow selection. Format each as "{number}. *{command-name} {parameters} - {description}"
+  - identify-dependencies {ticket-number-or-url}: Execute identify-dependencies task to find related past work and assess code modification requirements
   - retrieve-ticket-information {ticket-number-or-url}:
       - order-of-execution: 'Fetch ticket information (title, description, comments, attachments) using ticket number/URL with `atlassian` MCP→If fetch fails, notify user: "Atlassian MCP not connected. Please reauthenticate." and HALT until user confirms reconnection, then retry fetch→Check for Requirements or Acceptance Criteria in ticket description→If absent, check for attached images and request user to provide them via copy/paste (alt+v) or file path if downloaded→Prepare Acceptance Criteria text based on ticket description, comments, and provided attachments→Display ticket contents with prepared Acceptance Criteria and request user validation→Prompt user to proceed with draft-plan command. If no ticket identifier provided, ask for one'
       - attachment-rules: If there exists any attachments in the ticket request user to provide them via copy/paste (alt+v) or file path if downloaded

package/bmad-core/core-config.yaml

@@ -18,7 +18,6 @@ devLoadAlwaysFiles:
   - bmad-docs/architecture/coding-standards.md
   - bmad-docs/architecture/tech-stack.md
   - bmad-docs/architecture/project-structure.md
-  - bmad-docs/architecture/git-workflow.md
 devDebugLog: .ai/debug-log.md
 devStoryLocation:
   - bmad-docs/stories

package/bmad-core/tasks/identify-dependencies.md

@@ -1,347 +1,197 @@
 <!-- Powered by Stella Development Team -->
 
-# Identify Dependencies Task
+# identify-dependencies
 
-## Purpose
-
-To analyze a JIRA ticket or implementation plan and identify all technical dependencies, potential blockers, integration points, and risks that could impact successful implementation. This task surfaces critical information early, enabling better planning and risk mitigation.
-
-## Documentation Framework
-
-When identifying items in sections 2-5, document the following for each item:
-
-### For Dependencies (Code, Infrastructure, Third-Party, Data):
-
-- **What:** Name/description and what it provides
-- **Where:** Location (file path, service URL, package name)
-- **State:** Current status (exists, needs creation, needs modification, version)
-- **Requirements:** Configuration, access, permissions needed
-- **Concerns:** Known issues, limitations, performance considerations, costs
-
-### For Blockers (Technical, Information, Resource):
-
-- **What:** What is blocking or missing
-- **Impact:** Severity level (critical, high, medium, low)
-- **Resolution:** Who can unblock, how to obtain, estimated time
-- **Alternatives:** Workarounds or alternative approaches
-- **Partial Progress:** Can work proceed partially?
-
-### For Integration Points (Internal, External):
-
-- **Type:** Connection type and protocol
-- **Contract:** Data format, API specification
-- **Authentication:** Auth method and credentials management
-- **Reliability:** Error handling, retries, rate limits, fallback strategies
-- **Testing:** How to test and monitor the integration
-
-### For Risks (Technical, Integration, Project):
-
-- **Description:** Clear description of the risk
-- **Assessment:** Likelihood (high/medium/low) and Impact (critical/high/medium/low)
-- **Detection:** Early warning signs or detection strategy
-- **Mitigation:** Strategy to prevent or reduce risk
-- **Contingency:** Fallback plan if risk materializes
-
-## Task Execution
-
-### 1. Understand the Ticket/Plan Context
-
-#### 1.1 Load Ticket or Plan Information
-
-- Read the ticket file, plan file, or description provided
-- Extract key information:
-  - Ticket type (feature, bug, migration)
-  - Technical scope
-  - Components involved
-  - Integration requirements
-  - Timeline constraints (if any)
-
-#### 1.2 Load Architecture Context
-
-First, read the architecture index to understand available documentation:
-
-- Read `architecture/index.md` - Contains brief descriptions of all architecture documents
-
-**Fallback for Architecture Documentation:** If no `architecture/` folder exists inside `bmad-docs/` folder, check for `Claude.md` in the root directory of the project if it exists. This file may contain architecture and project information.
-
-Based on the ticket context and the briefs in the index, decide which architecture files are relevant to explore:
-
-- For technology/package dependencies → Review tech stack documentation
-- For project structure/module dependencies → Review structure documentation
-- For backend-specific work → Review backend architecture documentation
-- For frontend-specific work → Review frontend architecture documentation
-- For external integrations → Review external APIs documentation
-- For data/schema changes → Review database documentation
-
-**Decision Point:** Only load the architecture files that are relevant to your specific ticket context.
-
-### 2. Identify Technical Dependencies
-
-#### 2.1 Code Dependencies
-
-Identify and document (per framework above):
-
-- **Modules/Components** - Existing code this must interact with
-- **Shared Services** - Required utilities or services
-- **Data Models** - Required data structures or schemas
-- **APIs** - Internal APIs to consume
-- **State Management** - Required state or context
+Find related past work, analyze code dependencies, and assess modification requirements for current ticket implementation.
 
-#### 2.2 Infrastructure Dependencies
+## Inputs
 
-Identify and document (per framework above):
+```yaml
+required:
+  - ticket_id: 'Current Jira ticket ID' # e.g., "PROJ-123"
+  - jira_project: 'Jira project key from MCP config'
 
-- **Databases** - Database access, schema changes, migrations
-- **Caching** - Redis, Memcached, or other caching systems
-- **Message Queues** - Kafka, RabbitMQ, or other queuing systems
-- **Storage** - File storage, S3, CDN requirements
-- **Environment Variables** - New configs or secrets
-- **Deployment** - Build pipeline, deployment scripts, infrastructure changes
-
-#### 2.3 Third-Party Dependencies
-
-Identify and document (per framework above):
-
-- **NPM/Package Dependencies** - New libraries or version updates
-- **External APIs** - Third-party services to integrate
-- **SaaS Services** - Payment gateways, analytics, monitoring
-- **Authentication Providers** - OAuth, SAML providers
-- **CDNs or Static Resources** - External resource dependencies
-
-Note: Include license compatibility, rate limits, and cost implications in documentation.
-
-#### 2.4 Data Dependencies
-
-Identify and document (per framework above):
-
-- **Existing Data** - Required data availability
-- **Data Migrations** - Schema or data migrations required
-- **Data Transformations** - Data conversion needs
-- **Data Volume** - Amount of data involved
-- **Data Quality** - Data quality concerns
-- **Data Access** - Permission or privacy requirements
-
-Note: Include migration strategy, validation, backup, and rollback needs in documentation.
-
-### 3. Identify Blockers
-
-#### 3.1 Technical Blockers
-
-Identify and document (per framework above) anything that could prevent implementation:
-
-- **Missing Infrastructure** - Required services not yet provisioned
-- **Incomplete Features** - Depends on other unfinished work
-- **Technical Debt** - Existing code that must be refactored first
-- **Performance Issues** - Current system can't handle new requirements
-- **Security Gaps** - Security requirements not yet met
-- **Technical Limitations** - Platform or technology constraints
-
-#### 3.2 Information Blockers
-
-Identify and document (per framework above) missing information:
-
-- **Unclear Requirements** - Specifications not fully defined
-- **Ambiguous Acceptance Criteria** - Success conditions unclear
-- **Missing Designs** - UI/UX designs not available
-- **Unknown Integration Details** - Third-party API specs unclear
-- **Undecided Architecture** - Technical approach not yet determined
-
-#### 3.3 Resource Blockers
-
-Identify and document (per framework above) resource constraints:
-
-- **Access/Permissions** - Lack of access to systems, repos, or services
-- **Budget Constraints** - Costs exceeding budget
-- **Time Constraints** - Dependencies won't be ready in time
-- **Skill Gaps** - Specialized knowledge required
-- **Tooling** - Required tools not available
-
-### 4. Identify Integration Points
-
-#### 4.1 Internal Integration Points
-
-Identify and document (per framework above) connections within the system:
+optional:
+  - max_related_tickets: 3 # Number of past tickets to analyze (default: 3)
+  - architecture_refs: 'bmad-docs/architecture/**'
+  - code_base_path: 'Root path for code analysis'
+```
 
-- **Frontend-Backend** - API calls, data flows
-- **Service-to-Service** - Microservice communications
-- **Database Connections** - Data access patterns
-- **Event Systems** - Event producers and consumers
-- **Shared State** - Global state or cache dependencies
+## Purpose
 
-#### 4.2 External Integration Points
+Generate comprehensive dependency analysis including:
 
-Identify and document (per framework above) connections to external systems:
+1. Related past tickets (2-3 with semantic similarity)
+2. Code files modified in past work
+3. Code modification assessment for current ticket
+4. Temporary dependency file at `bmad-docs/temporary/{ticket_id}-dependency-tmp.md`
 
-- **Third-Party APIs** - External service calls
-- **Webhooks** - Incoming or outgoing webhook integrations
-- **File Imports/Exports** - Data exchange with external systems
-- **Authentication** - SSO, OAuth providers
-- **Monitoring/Logging** - External monitoring services
+## Process
 
-### 5. Assess Risks
+### 1. Validate Data Sources
 
-#### 5.1 Technical Risks
+Verify Atlassian MCP connection. If unavailable, request Jira URL or fallback to git history analysis.
 
-Identify and document (per framework above):
+### 2. Load Current Ticket Context
 
-- **Complexity** - Solution is technically complex
-- **New Technology** - Using unfamiliar tech stack
-- **Performance** - May not meet performance requirements
-- **Scalability** - Solution may not scale
-- **Security** - Potential security vulnerabilities
-- **Data Loss** - Risk of data corruption or loss (especially migrations)
-- **Browser/Platform Compatibility** - May not work across targets
+**Fetch ticket details** via MCP including summary, description, type, components, and acceptance criteria.
 
-#### 5.2 Integration Risks
+**Analyze attachments** (screenshots, error logs):
 
-Identify and document (per framework above):
+- Extract URLs from browser bars and network tabs
+- Identify file paths from stack traces
+- Note API endpoints and error messages
+- Capture UI routes and console logs
 
-- **API Changes** - Third-party APIs may change
-- **Service Downtime** - External services may be unavailable
-- **Version Incompatibility** - Dependency version conflicts
-- **Data Format Changes** - External data formats may change
-- **Rate Limiting** - May hit rate limits under load
+**Extract technical hints** from ticket content:
 
-#### 5.3 Project Risks
+- Feature keywords and technical components
+- URL patterns and route segments
+- API endpoints and frontend components
+- Function/class names and file references
 
-Identify and document (per framework above):
+### 3. Find Related Past Tickets
 
-- **Scope Creep** - Requirements may expand
-- **Timeline Pressure** - Tight deadlines may force shortcuts
-- **Dependency Delays** - Other teams may delay
-- **Resource Availability** - Key resources may be unavailable
-- **Requirement Changes** - Requirements may change during implementation
+**Build search scope:** Check if current ticket has a parent. If parent exists and differs from project, include parent in JQL query. Otherwise, search at project level only.
 
-### 6. Recommend Mitigation Strategies
+**Search Jira:** Use JQL with project, status (Done/Closed/Resolved), parent (if applicable), keywords, and timeframe (last 6 months).
 
-For identified dependencies and risks, provide strategies:
+**Rank candidates:** Score by similarity (title 40%, description 30%, component 20%, type 10%).
 
-#### 6.1 Dependency Management
+**Select tickets:** Present top candidates for user selection or auto-select top 2-3.
 
-- **Early Validation** - Verify dependencies before main implementation
-- **Parallel Workstreams** - Work on independent parts while waiting
-- **Stub/Mock** - Create mocks for unavailable dependencies
-- **Incremental Approach** - Deliver in phases to reduce risk
-- **Fallback Options** - Identify alternative approaches
+### 4. Analyze Code Changes from Past Tickets
 
-#### 6.2 Risk Mitigation
+**Extract commits:** Check Jira ticket for linked commits (primary source). If none found, search git history with `git log --all --grep="{TICKET-ID}"`.
 
-- **Proof of Concept** - Validate high-risk approaches early
-- **Feature Flags** - Use flags to enable/disable safely
-- **Gradual Rollout** - Deploy incrementally to subset of users
-- **Monitoring** - Add comprehensive monitoring and alerting
-- **Rollback Plan** - Have clear rollback procedures
-- **Testing** - Extra testing for high-risk areas
+**Analyze changes:** For each commit, use `git show --name-status {SHA}` to get modified/added/deleted files.
 
-### 7. Create Temporary Dependency File
+**Group results:** Organize files by component/module, file type (controller, service, model, test), and architectural layer (frontend, backend, database).
 
-Create a temporary file to store the dependency analysis:
+### 5. Assess Current Ticket Code Impact
 
-#### 7.1 File Creation
+**Load architecture context:**
+Read project architecture docs (`bmad-docs/architecture/**`) to extract directory structures, naming conventions, URL routing patterns, and testing patterns. Use these conventions as the primary guide for code location.
 
-- **File name:** `{{ticket_no}}-dependency-tmp.md`
-- **Location:** `bmad-docs/temporary/`
-- **Purpose:** Store dependencies for use by create-implementation-plan task
+**Map URLs to code:**
 
-**Note:** If the `bmad-docs/temporary` folder doesn't exist, create it first.
+- Use architecture-defined routing patterns to map URLs from screenshots/descriptions to controllers and views
+- Apply project-specific conventions (not generic framework patterns)
+- Generate candidate files with confidence scores based on evidence strength
 
-#### 7.2 File Content Structure
+**Trace API calls (Frontend → Backend):**
 
-Write the comprehensive dependency analysis to the temporary file using the following structure:
+- Locate frontend components using routing configuration
+- Extract API calls using project's HTTP client patterns
+- Map API endpoints to backend routes and controllers
+- Follow architectural layers (routes → controllers → services → repositories → models)
 
-```markdown
-# Dependency Analysis Report: [Ticket Number] - [Title]
+**Generate candidate functions:**
+Use architecture-defined naming patterns to predict function names. Search codebase with project conventions (directory structure + naming patterns). Consider multiple naming styles only if architecture doesn't specify.
 
-## Summary
+**Synthesize predictions:**
+Combine evidence from multiple sources with priority:
 
-- Total Dependencies Identified: [N]
-- Critical Blockers: [N]
-- High-Risk Items: [N]
-- External Integrations: [N]
-- Overall Risk Level: [Low/Medium/High/Critical]
+1. Architecture conventions (highest)
+2. Past ticket patterns
+3. URL/route mapping
+4. API endpoint tracing
+5. Function name inference
+6. Generic framework conventions (fallback only)
 
-## Technical Dependencies
+Document each file with evidence trail, predicted methods/changes, and confidence level (HIGH/MEDIUM/LOW).
 
-[List with details]
+**Verify file state:**
+Check existence, last modified date/author, complexity metrics, and whether file appeared in related tickets.
 
-## Infrastructure Dependencies
+### 6. Generate Outputs
 
-[List with details]
+**Console Report:**
+Display minimal summary in terminal with single-line format per related ticket showing ticket ID, similarity percentage, and file count only.
 
-## Third-Party Dependencies
+**Temporary Dependency File:**
+Create `bmad-docs/temporary/{ticket_id}-dependency-tmp.md` containing the following aspects:
 
-[List with details]
+```
 
-## Data Dependencies
+**Summary Section:**
+Provide quantitative overview including total number of files impacted, breakdown of files requiring modification versus new file creation, count of integration points, and overall risk level classification (Simple/Moderate/Complex).
 
-[List with details]
+**Technical Hints Extracted:**
+Document all technical clues organized by source. From screenshots include URLs, file paths from error traces, and console log messages. From ticket description capture URL patterns, API endpoint references, and direct code references. From architecture documentation note project structure conventions, naming patterns, routing configurations, and architectural layers.
 
-## Blockers
+**Related Past Work:**
+For each related ticket identified, include similarity score percentage, completion date, key learnings or patterns discovered, and complete list of files that were modified during that work.
 
-[List with severity, impact, mitigation]
+**Code Dependencies - Files to Modify:**
+For each existing file requiring changes, document its purpose and current state, explain the evidence trail showing how it was identified, describe predicted methods or code sections needing changes, state implementation requirements, assign confidence level (HIGH/MEDIUM/LOW), and note any concerns or complexity factors.
 
-## Integration Points
+**Code Dependencies - Files to Create:**
+For each new file needed, specify its purpose and which template or pattern it should follow, explain how this need was identified through architecture analysis, outline expected interfaces or methods it should implement, assign confidence level, and document any concerns about its creation.
 
-[List with protocols, error handling]
+**Integration Points:**
+Document all integration touchpoints both internal (between modules) and external (third-party services). For each integration specify the contract or interface, note reliability concerns, and define testing requirements.
 
-## Risks
+**Blockers:**
+List technical blockers preventing immediate progress. For each blocker describe its impact on implementation, outline resolution path, suggest alternatives if available, and indicate whether partial progress is possible while blocker remains.
 
-[List with likelihood, impact, mitigation]
+**Risks:**
+Assess technical risks with structured analysis. For each risk specify likelihood (High/Medium/Low), potential impact, detection method during implementation, mitigation strategy, and contingency plan if risk materializes.
 
-## Recommended Approach
+**Recommended Approach:**
+Provide step-by-step implementation approach that leverages patterns from past work, addresses identified blockers, and follows project architectural conventions.
 
-1. [First priority action]
-2. [Second priority action]
-3. [Continue with remaining actions]
+**Critical Path Items:**
+Identify key dependencies that absolutely must be resolved for successful implementation. These are prerequisites that block all progress if not addressed.
 
-## Critical Path Items
+**Next Steps:**
+List immediate actionable items required before proceeding to implementation planning phase.
 
-- [Items that must be resolved before starting]
-- [Items that must be resolved during implementation]
+```
 
-## Next Steps
+**Console Summary:**
+Print single-line completion message containing: dependency file path, total files to modify, total files to create, risk level (Simple/Moderate/Complex), and related ticket IDs (comma-separated). No additional explanatory text or formatting.
 
-1. Resolve critical blockers
-2. Validate high-risk dependencies
-3. Proceed with implementation plan
-```
+## Assessment Criteria
 
-#### 7.3 Present Summary to User
+**Similarity Scoring:**
 
-After creating the file, provide a summary to the user:
+- High (≥80%): Same component/module and feature area
+- Medium (60-79%): Related area with some overlap
+- Low (<60%): Different area with useful patterns
 
-- Location of the temporary file
-- Total dependencies identified
-- Critical blockers that need attention
-- Overall risk level assessment
+**Code Impact Assessment:**
 
-### 8. Integration with Implementation Plan
+- Simple (Low Risk): 1-3 files, clear patterns, no new integrations
+- Moderate (Medium Risk): 4-10 files, some new files, 1-2 integration points
+- Complex (High Risk): 10+ files, many new components, multiple integrations
 
-The `create-implementation-plan` task will read `{{ticket_no}}-dependency-tmp.md` and integrate dependencies into the implementation plan's "Dependencies and Risks" section, "Technical Approach", and "Tasks / Subtasks".
+## Key Principles
 
-#### 8.1 Cleanup Logic
+**Evidence Priority (for code location):**
 
-After integration, the create-implementation-plan task performs cleanup:
+1. Architecture documentation (highest - project conventions)
+2. Screenshots/attachments (URLs, error traces)
+3. Past ticket patterns (proven approaches)
+4. Code tracing (URL → routes → controllers → services)
+5. Semantic inference (function name generation)
+6. Generic framework conventions (fallback only)
 
-**All dependencies addressed:** Delete `{{ticket_no}}-dependency-tmp.md` completely.
+**Best Practices:**
 
-**Dependencies span multiple subtasks:** Remove only addressed dependencies from the temporary file. Keep remaining dependencies for subsequent decomposed subtasks that will reuse the file.
+- Focus on semantic similarity over keyword matching
+- Prioritize recent work (last 6 months)
+- Extract architecture conventions first
+- Combine multiple evidence sources
+- Document uncertainties as risks, not blockers
+- Show evidence trail for transparency
+- Keep console output concise, temp file detailed
 
-#### 8.2 Workflow
+## Integration with Implementation Plan
 
-1. **Identify Dependencies** → Creates `{{ticket_no}}-dependency-tmp.md`
-2. **Decompose Task** (if needed) → Breaks large tasks into smaller subtasks
-3. **Create Implementation Plan** → Integrates dependencies, cleans up file as appropriate
-4. **Repeat** → Subsequent subtasks reuse temporary file until all dependencies addressed
+The `create-implementation-plan` task reads the temporary dependency file and integrates findings. After integration:
 
-## Notes
+- Delete temp file if all dependencies addressed
+- Keep remaining items if dependencies span multiple subtasks
 
-- This task is typically run as part of create-implementation-plan workflow
-- Can also be run standalone for existing plans or tickets
-- Creates a temporary file `{{ticket_no}}-dependency-tmp.md` in `bmad-docs/temporary/` for use by subsequent tasks
-- Temporary file persists across decomposed subtasks and is cleaned up once all dependencies are addressed
-- Supports BMAD decomposition workflow where large tasks (multiple story points) are broken into smaller tasks (max 1 story point each)
-- Dependency identification helps set realistic timelines
-- Early identification prevents surprises during implementation
-- Risk mitigation strategies should be concrete and actionable
-- Document assumptions clearly when dependencies are uncertain
+**Workflow:** identify-dependencies → decompose-task (optional) → create-implementation-plan → repeat for subtasks

package/bmad-core/tasks/review-and-improve.md

@@ -10,26 +10,37 @@ Review code and apply practical improvements directly. Focus on reducing time co
 
 ### 1. Load Files
 
-**If story file:** Extract files from "Dev Agent Record" → "File List"
+**Load and Read `coding-standards.md` file:** from the given location in `devLoadAlwaysFiles` of `.bmad-core/core-config.yaml` file
+**If story/task file:** Extract files from "Dev Agent Record" → "File List"
 **If specific files:** Use provided paths
 
 ### 2. Review Each File
 
+_Suggest Improvements ONLY in Recently Modified or Added Code_
+
 Look for:
 
 **Time Complexity Issues:**
+
 - O(n²) or worse algorithms → Can we make it O(n)?
 - Nested loops → Can we use a Map/Set?
 - Repeated calculations → Can we calculate once?
 - Inefficient searching/sorting → Better algorithm?
 
 **Code Quality:**
+
 - Confusing variable names → Rename
 - Duplicate code → Extract to function
 - Long functions → Break down
 - Missing error handling → Add it
 
+**Code Standards:**
+
+- Standards not followed → Fix to match coding-standards.md
+- Missing or incorrect comments → Add/fix per commenting strategy
+
 **Simple Performance:**
+
 - Database queries in loops → Batch them
 - Large arrays being copied → Use references
 - Unnecessary iterations → Remove
@@ -67,6 +78,7 @@ Apply this improvement? (yes/no)
 ### 6. After All Improvements
 
 Summary:
+
 - Files reviewed: {count}
 - Improvements found: {count}
 - Improvements applied: {count}
@@ -77,6 +89,7 @@ Done!
 ## Rules
 
 **DO suggest:**
+
 - ✅ Better algorithms (O(n²) → O(n))
 - ✅ Using Map/Set instead of nested loops
 - ✅ Removing duplicate code
@@ -85,6 +98,7 @@ Done!
 - ✅ Adding error handling
 
 **DON'T suggest:**
+
 - ❌ Caching layers
 - ❌ Vector embeddings
 - ❌ Redis/persistent memory