bmad-stella 1.0.0 → 1.0.2

package/README.md

@@ -52,8 +52,9 @@ npx bmad-stella install
 3. Enter Confluence URL for architecture docs
 4. Select **Claude Code** as IDE
 5. Skip web bundles installation (enter `n`)
-6. Configure Atlassian MCP Server (enter `y`)
-7. Provide JIRA instance URL (e.g., `https://stellaint.atlassian.net`)
+6. Allow Claude Code Permissions Setup (enter `y`)
+7. Configure Atlassian MCP Server (enter `y`)
+8. Provide JIRA instance URL (e.g., `https://stellaint.atlassian.net`)
 
 **📖 [Detailed Installation Guide](docs/stella-user-guide.md#bmad-stella-installation-process)**
 

package/bmad-core/agents/dev.md

@@ -53,18 +53,26 @@ 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
 
 # All commands require * prefix when used (e.g., *help)
 commands:
-  - help: Show numbered list of the following commands to allow selection
+  - help: Show numbered list of the following commands to allow selection. Format each as "{number}. *{command-name} {parameters} - {description}"
   - implement-task:
-      - order-of-execution: 'Read (first or next) task from implementation plan→Implement Task and its subtasks→Write tests→Execute validations→Only if ALL pass, then update the task checkbox with [x] in plan→Update plan section File List to ensure it lists any new or modified or deleted source file→HALT and ask user if they want to proceed to next task→If yes, repeat order-of-execution; if no, remain HALTED'
+      - order-of-execution: 'Read (first or next) task from implementation plan→Implement Task and its subtasks→Update the task checkbox with [x] in plan→Update plan file `File List` subsection in `Dev Agent Record` section to ensure it lists any new or modified or deleted source file→HALT and ask user: "Proceed to next task, build project, or stop?"→If next task: repeat order-of-execution→If build: run build command and report result then ask "Proceed to next task or stop?"→If stop: remain HALTED'
       - plan-file-updates-ONLY:
           - CRITICAL: ONLY UPDATE THE IMPLEMENTATION PLAN FILE WITH UPDATES TO SECTIONS INDICATED BELOW. DO NOT MODIFY ANY OTHER SECTIONS.
-          - 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: Don't ask for user permission for plan file update.
+          - 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
@@ -73,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}: Post implementation summary to Jira ticket using Atlassian MCP server using Jira markdown formatting
-      - order-of-execution: Extract Jira ticket number/URL from plan file Ticket Information section→Verify Atlassian MCP server connectivity→Check if Acceptance Criteria already exists in Jira ticket description→Format comment according to comment-structure   rules→Display formatted comment to user and request permission to post→Post comment to Jira ticket→Display Jira ticket URL and confirm successful posting
+  - 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: Read documentation from the `architectureFolderUrl` in `.bmad-core/core-config.yaml`. Delete and recreate the `architecture/` folder inside `bmad-docs/` if it exists. 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 atlassian mcp shows authentication/login required, inform user to authenticate Atlassian MCP, HALT activation process, wait for user confirmation of authentication, 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
@@ -60,10 +63,11 @@ persona:
     - Standards & Patterns Adherence - Ensure plans align with project conventions
 # All commands require * prefix when used (e.g., *help)
 commands:
-  - help: Show numbered list of the following commands to allow selection
-  - retrieve-ticket-information {ticket-number-or-url}: Retrieve and validate JIRA ticket information using Atlassian MCP server, preparing it for implementation planning
-      - order-of-execution: Verify Atlassian MCP server connectivity→Fetch ticket information (title, description, comments, attachments) using ticket number/URL→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
+  - 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
       - acceptance-criteria-rules: Prepare criteria only if Requirements AND Acceptance Criteria sections are both absent. Request attachments first if present. Format as testable, numbered list based on ticket description and attachments. Do not create any files - only compose text for display
       - output-format: Display ticket title, description, comments, attachments list, and prepared Acceptance Criteria (if created) with clear validation prompt
   - draft-plan {ticket-file-or-description}: Analyze JIRA ticket (feature/bug/migration) information with description having `Acceptance Criteria`/ `Requirements` and create detailed implementation plan with step-by-step tasks executing create-implementation-plan

package/bmad-core/agents/qa.md

@@ -62,7 +62,7 @@ task-file-permissions:
   - Assessment documents include: test-design-*.md, trace-*.md files
 # All commands require * prefix when used (e.g., *help)
 commands:
-  - help: Show numbered list of the following commands to allow selection
+  - help: Show numbered list of the following commands to allow selection. Format each as "{number}. *{command-name} {parameters} - {description}"
   - test-design {task-file}: Execute test-design task to create comprehensive test scenarios
   - implement-test {task-file}: Execute implement-test task to write test code from test design scenarios
   - trace {task-file}: Execute trace-requirements task to map requirements to tests using Given-When-Then

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/create-implementation-plan.md

@@ -16,6 +16,7 @@ To transform JIRA tickets (features, bugs, migrations) into comprehensive, actio
    - **Get search hints first:** Ask user for helpful hints to narrow the search (e.g., "Look in services folder", "Related to authentication", "Files with 'payment' in name", "Backend API files")
    - **Check project structure docs:** ALWAYS read `bmad-docs/architecture/project-structure.md` (or `project-structure.md`) FIRST to understand file locations and naming conventions
    - **Perform targeted search:** Use hints + structure knowledge to create focused Glob/Grep searches instead of broad codebase scans
+   - **Identify impacted files:** When modifying a function, component, or interface, search for its usages across codebase using targeted Glob/Grep before making changes. Update all impacted files accordingly.
 
 ## SEQUENTIAL Task Execution (Do not proceed until current Task is complete)
 
@@ -84,14 +85,14 @@ If critical information is missing, ask the user targeted questions:
 
 **For Database Changes (All Ticket Types):**
 
-- Does this work require any database table updates or creation?
-- **If uncertain, ASK the user** - better to clarify than assume
+- Analyze Does this work require any database table updates or creation?
+- **If not mentioned in ticket and uncertain, ASK the user** - better to clarify than assume
 - If YES:
   - **Database migration tasks must be handled by the user** (add in tasks list but tell user to do this)
   - If specific fields to add to a model or a new model structure are NOT specified in the ticket info/requirements:
     - **Ask the user to specify the fields to be added or the model structure** (field names, types, constraints, relationships)
   - **If uncertain about any database-related details, ALWAYS ask the user** - do not make assumptions or proceed silently
-  - Document the model/table changes needed in the Technical Approach sectio
+  - Document the model/table changes needed in the Technical Approach section
 
 **CRITICAL:** Only ask essential questions. Use your senior developer judgment to infer reasonable details when possible.