Make BMAD-Jira fully standalone with complete workflow coverage
Phase 2 of the Atlassian adapter: removes all dependencies on BMAD-METHOD (bmm), adds missing workflow overrides for all 4 phases, implements cross-agent handoff communication, and adds comprehensive documentation. Key changes: - Remove depends_on: bmm and all bmm path references (zero remaining) - Remove dual-write/output_mode — all output goes exclusively to Jira/Confluence - Replace 6 injection YAMLs with 7 full standalone agent definitions - Inline 8 templates and 5 checklists from BMAD-METHOD - Add Phase 1-3 workflow overrides (product brief, research, PRD, UX design, architecture, implementation readiness) - Add Phase 4 workflow overrides (retrospective, correct-course, sprint-status) - Add post-handoff task for cross-agent communication via Jira labels - Update orchestrator with handoff detection and full artefact scanning - Update artefact-mapping with template/checklist references, remove local paths - Add README with installation, MCP setup, configuration, and architecture docs 58 files across agents, templates, checklists, tasks, orchestrator, and workflow-overrides for a fully self-contained Jira/Confluence adapter. https://claude.ai/code/session_01GE7R9vLGsTa785ieSmeTT4
This commit is contained in:
Claude
parent
c34898cdba
commit
417e4dde94
|
|
@ -0,0 +1,283 @@
|
|||
# BMAD-Jira: Atlassian-Native Agentic Development
|
||||
|
||||
A standalone Jira/Confluence-native implementation of the [BMAD agentic development method](https://github.com/bmadcode/BMAD-METHOD). Instead of writing artefacts to local markdown files, BMAD agents create and manage Jira issues (Epics, Stories, Subtasks) and Confluence pages (PRDs, architecture docs, UX designs) via the Atlassian MCP server.
|
||||
|
||||
## How It Works
|
||||
|
||||
BMAD-Jira provides 7 AI agent personas that collaborate through a structured 4-phase development workflow:
|
||||
|
||||
1. **Analysis** — Analyst creates product briefs and research reports on Confluence
|
||||
2. **Planning** — PM creates PRDs and Epics/Stories in Jira; UX Designer creates design docs on Confluence
|
||||
3. **Solutioning** — Architect creates architecture decisions on Confluence; SM validates implementation readiness
|
||||
4. **Implementation** — SM manages sprints and prepares stories; Dev implements code; QA reviews via Jira
|
||||
|
||||
All agent output goes exclusively to Jira and Confluence. An automated orchestrator polls Jira via JQL to determine which agent should work next, enabling autonomous project progression.
|
||||
|
||||
## Prerequisites
|
||||
|
||||
- **Claude Code** (or compatible LLM tool with MCP support)
|
||||
- **Jira Cloud** project with Agile board
|
||||
- **Confluence Cloud** space for documentation
|
||||
- **Atlassian API token** ([Generate here](https://id.atlassian.com/manage-profile/security/api-tokens))
|
||||
|
||||
## MCP Server Dependency
|
||||
|
||||
BMAD-Jira requires the **mcp-atlassian** MCP server for all Jira and Confluence operations.
|
||||
|
||||
### Installation
|
||||
|
||||
**Using uvx (recommended):**
|
||||
|
||||
```json
|
||||
{
|
||||
"mcpServers": {
|
||||
"atlassian": {
|
||||
"command": "uvx",
|
||||
"args": ["mcp-atlassian"],
|
||||
"env": {
|
||||
"JIRA_URL": "https://your-domain.atlassian.net",
|
||||
"JIRA_USERNAME": "your-email@example.com",
|
||||
"JIRA_API_TOKEN": "your-api-token",
|
||||
"CONFLUENCE_URL": "https://your-domain.atlassian.net/wiki",
|
||||
"CONFLUENCE_USERNAME": "your-email@example.com",
|
||||
"CONFLUENCE_API_TOKEN": "your-api-token"
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
**Using Docker:**
|
||||
|
||||
```json
|
||||
{
|
||||
"mcpServers": {
|
||||
"atlassian": {
|
||||
"command": "docker",
|
||||
"args": [
|
||||
"run", "-i", "--rm",
|
||||
"-e", "JIRA_URL",
|
||||
"-e", "JIRA_USERNAME",
|
||||
"-e", "JIRA_API_TOKEN",
|
||||
"-e", "CONFLUENCE_URL",
|
||||
"-e", "CONFLUENCE_USERNAME",
|
||||
"-e", "CONFLUENCE_API_TOKEN",
|
||||
"ghcr.io/sooperset/mcp-atlassian:latest"
|
||||
],
|
||||
"env": {
|
||||
"JIRA_URL": "https://your-domain.atlassian.net",
|
||||
"JIRA_USERNAME": "your-email@example.com",
|
||||
"JIRA_API_TOKEN": "your-api-token",
|
||||
"CONFLUENCE_URL": "https://your-domain.atlassian.net/wiki",
|
||||
"CONFLUENCE_USERNAME": "your-email@example.com",
|
||||
"CONFLUENCE_API_TOKEN": "your-api-token"
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
**Using pip:**
|
||||
|
||||
```bash
|
||||
pip install mcp-atlassian
|
||||
```
|
||||
|
||||
The MCP server provides 72 tools (45 Jira, 27 Confluence) that BMAD agents use for all operations.
|
||||
|
||||
## Installation
|
||||
|
||||
1. **Clone this repository** into your project:
|
||||
|
||||
```bash
|
||||
git clone https://github.com/your-org/BMAD-GUI.git
|
||||
cp -r BMAD-GUI/src/atlassian/ your-project/_bmad/atlassian/
|
||||
```
|
||||
|
||||
2. **Configure** `_bmad/atlassian/config.yaml` with your project settings (see Configuration below)
|
||||
|
||||
3. **Run transition discovery** to map your Jira workflow's transition IDs:
|
||||
|
||||
```
|
||||
Load the workflow: _bmad/atlassian/transition-discovery.md
|
||||
Follow the 7-step process to discover and record your Jira transition IDs
|
||||
```
|
||||
|
||||
4. **Set up the MCP server** in your Claude Code or IDE configuration (see MCP Server Dependency above)
|
||||
|
||||
## Configuration
|
||||
|
||||
All configuration lives in `module.yaml`. Key settings:
|
||||
|
||||
| Variable | Description | Default |
|
||||
|---|---|---|
|
||||
| `project_name` | Your project name | Directory name |
|
||||
| `user_name` | Your name for agent communication | "Developer" |
|
||||
| `communication_language` | Language agents communicate in | "English" |
|
||||
| `document_output_language` | Language for generated documents | "English" |
|
||||
| `user_skill_level` | beginner / intermediate / expert | "intermediate" |
|
||||
| `jira_project_key` | Your Jira project key (e.g., PROJ) | "PROJ" |
|
||||
| `jira_board_id` | Your Jira Agile board ID | (discover via transition-discovery) |
|
||||
| `confluence_space_key` | Your Confluence space key | Same as project key |
|
||||
| `confluence_parent_page_id` | Parent page ID for BMAD pages | (root of space) |
|
||||
| `status_transitions` | Jira transition ID mapping | (populate via transition-discovery) |
|
||||
| `agent_label_prefix` | Prefix for agent-applied labels | "bmad-agent-" |
|
||||
| `lock_label` | Label for agent locking | "agent-active" |
|
||||
|
||||
### Status Transition Mapping
|
||||
|
||||
BMAD uses abstract statuses that must be mapped to your Jira project's specific transition IDs:
|
||||
|
||||
```yaml
|
||||
status_transitions:
|
||||
epic:
|
||||
backlog_to_in_progress: "21" # Your transition ID
|
||||
in_progress_to_done: "31" # Your transition ID
|
||||
story:
|
||||
backlog_to_ready_for_dev: "11"
|
||||
ready_for_dev_to_in_progress: "21"
|
||||
in_progress_to_review: "31"
|
||||
review_to_done: "41"
|
||||
```
|
||||
|
||||
Transition IDs vary per Jira project. Run `transition-discovery.md` to auto-discover yours.
|
||||
|
||||
## Agent Roster
|
||||
|
||||
| Agent | Persona | Role | Phase |
|
||||
|---|---|---|---|
|
||||
| **Analyst** | Mary | Creates product briefs and conducts research | 1 - Analysis |
|
||||
| **PM** | John | Creates PRDs, defines epics and stories | 2 - Planning |
|
||||
| **UX Designer** | Sally | Creates UX design specifications | 2 - Planning |
|
||||
| **Architect** | Winston | Defines architecture and technology decisions | 3 - Solutioning |
|
||||
| **SM (Scrum Master)** | Bob | Manages sprints, prepares stories, runs retros | 3-4 - Solutioning/Implementation |
|
||||
| **Dev** | Amelia | Implements stories, writes code | 4 - Implementation |
|
||||
| **QA** | Quinn | Reviews code, validates acceptance criteria | 4 - Implementation |
|
||||
|
||||
## Workflow Reference
|
||||
|
||||
### Phase 1 — Analysis
|
||||
| Workflow | Agent | Jira/Confluence Output |
|
||||
|---|---|---|
|
||||
| Create Product Brief | Analyst | Confluence page (bmad-brief label) |
|
||||
| Research | Analyst | Confluence page(s) (bmad-research label) |
|
||||
|
||||
### Phase 2 — Planning
|
||||
| Workflow | Agent | Jira/Confluence Output |
|
||||
|---|---|---|
|
||||
| Create PRD | PM | Confluence page + Remote Issue Links to Epics |
|
||||
| Create UX Design | UX Designer | Confluence page + Remote Issue Links to Epics |
|
||||
| Create Epics and Stories | PM | Jira Epics + Stories (Batch Create, Link to Epic) |
|
||||
|
||||
### Phase 3 — Solutioning
|
||||
| Workflow | Agent | Jira/Confluence Output |
|
||||
|---|---|---|
|
||||
| Create Architecture | Architect | Confluence page + Remote Issue Links to Epics |
|
||||
| Check Implementation Readiness | SM | Confluence readiness report + Epic comments |
|
||||
|
||||
### Phase 4 — Implementation
|
||||
| Workflow | Agent | Jira/Confluence Output |
|
||||
|---|---|---|
|
||||
| Sprint Planning | SM | Create Sprint, Add Issues to Sprint, Epic transitions |
|
||||
| Create Story | SM | Update Issue (enrich description), Create Subtasks, Transition to Ready for Dev |
|
||||
| Dev Story | Dev | Lock Issue, Transition In Progress, Add Comment (Dev Record), Transition to Review |
|
||||
| Code Review | QA | Add Comment (review findings), Transition to Done |
|
||||
| Sprint Status | SM | JQL-based status dashboard (read-only) |
|
||||
| Correct Course | SM | Update Issue, Create Issue (remediation), Add Comment |
|
||||
| Retrospective | SM | Confluence page + Epic comment, Transition Epic to Done |
|
||||
|
||||
## Architecture
|
||||
|
||||
```
|
||||
src/atlassian/
|
||||
module.yaml # Configuration schema
|
||||
artefact-mapping.yaml # Maps artefacts to MCP tool calls
|
||||
transition-discovery.md # Setup workflow for transition IDs
|
||||
|
||||
agents/ # Full standalone agent definitions
|
||||
analyst.agent.yaml
|
||||
pm.agent.yaml
|
||||
architect.agent.yaml
|
||||
sm.agent.yaml
|
||||
dev.agent.yaml
|
||||
qa.agent.yaml
|
||||
ux-designer.agent.yaml
|
||||
|
||||
templates/ # Document templates (from BMAD-METHOD)
|
||||
product-brief-template.md
|
||||
research-template.md
|
||||
prd-template.md
|
||||
ux-design-template.md
|
||||
epics-template.md
|
||||
story-template.md
|
||||
architecture-decision-template.md
|
||||
readiness-report-template.md
|
||||
|
||||
checklists/ # Quality checklists
|
||||
code-review-checklist.md
|
||||
dev-story-checklist.md
|
||||
create-story-checklist.md
|
||||
correct-course-checklist.md
|
||||
sprint-planning-checklist.md
|
||||
|
||||
tasks/ # Reusable MCP task procedures
|
||||
write-to-confluence.md # Idempotent Confluence page create/update
|
||||
transition-jira-issue.md # Safe status transitions with guard checks
|
||||
lock-issue.md # Agent locking via labels
|
||||
read-jira-context.md # Context loading from Jira/Confluence
|
||||
post-handoff.md # Cross-agent handoff notifications
|
||||
|
||||
orchestrator/ # Automated dispatch system
|
||||
jira-state-reader.md # Polls Jira/Confluence for project state
|
||||
agent-dispatch-rules.md # Priority-ordered rules for agent selection
|
||||
|
||||
workflow-overrides/ # Jira-specific workflow implementations
|
||||
1-analysis/ # Product brief, research
|
||||
2-plan-workflows/ # PRD, UX design
|
||||
3-solutioning/ # Architecture, readiness, epics/stories
|
||||
4-implementation/ # Sprint planning, stories, dev, review, retro
|
||||
|
||||
data/
|
||||
.jira-key-map.yaml.template # Template for BMAD→Jira key mapping
|
||||
```
|
||||
|
||||
### Key Concepts
|
||||
|
||||
- **Key Map** (`.jira-key-map.yaml`): Local file that maps BMAD identifiers (e.g., `epic-1`) to Jira issue keys (e.g., `PROJ-42`) and Confluence page IDs. Updated automatically by workflows.
|
||||
|
||||
- **Agent Locking**: When an agent starts work on a Jira issue, it applies the `agent-active` label to prevent concurrent work. The orchestrator detects and clears stale locks (>1 hour inactive).
|
||||
|
||||
- **Handoff Labels**: When an agent completes work, it applies a `bmad-handoff-{agent}` label to signal the next agent. The orchestrator prioritises these over state-based inference.
|
||||
|
||||
- **Reusable Tasks**: Common MCP operations (write to Confluence, transition issues, lock/unlock, read context) are encapsulated as task files that workflows invoke. This ensures consistent behaviour across all agents.
|
||||
|
||||
## Orchestrator
|
||||
|
||||
The orchestrator runs in automated polling mode:
|
||||
|
||||
1. **Poll** — `jira-state-reader` queries Jira and Confluence for current project state
|
||||
2. **Evaluate** — `agent-dispatch-rules` checks 16 priority-ordered rules against the state
|
||||
3. **Dispatch** — Invokes the matching agent with its workflow and pre-loaded context
|
||||
4. **Repeat** — After agent completion, returns to step 1
|
||||
|
||||
The orchestrator handles: handoff signal detection, agent locking/conflict prevention, stale lock cleanup, and project completion detection.
|
||||
|
||||
## Differences from BMAD-METHOD
|
||||
|
||||
| Aspect | BMAD-METHOD | BMAD-Jira |
|
||||
|---|---|---|
|
||||
| Output | Local markdown files | Jira issues + Confluence pages |
|
||||
| Tracking | `sprint-status.yaml` file | Jira Sprints API |
|
||||
| Status transitions | Manual file edits | Jira Transition API |
|
||||
| Cross-references | File paths | Jira issue keys + Confluence page IDs |
|
||||
| Agent communication | Shared file system | Jira comments + handoff labels |
|
||||
| Quick Flow | Included (Barry agent) | Excluded (not applicable to Jira workflows) |
|
||||
| Dependencies | Standalone | Requires mcp-atlassian MCP server |
|
||||
|
||||
## Contributing
|
||||
|
||||
This project extends the [BMAD-METHOD](https://github.com/bmadcode/BMAD-METHOD) for Atlassian environments. Templates and checklists are adapted from the original project.
|
||||
|
||||
## License
|
||||
|
||||
See [LICENSE](LICENSE) for details.
|
||||
|
|
@ -1,15 +0,0 @@
|
|||
# Atlassian Adapter Injection for Analyst Agent (Mary)
|
||||
# Appended to analyst.agent.yaml critical_actions when atlassian module is installed
|
||||
|
||||
target_agent: bmad-analyst
|
||||
injection_point: critical_actions
|
||||
|
||||
inject:
|
||||
- "When tracking_system is 'jira': use Atlassian MCP tools for all artefact output instead of writing local files"
|
||||
- "Read artefact mapping from {project-root}/_bmad/atlassian/artefact-mapping.yaml for output routing"
|
||||
- "Use {key_map_file} for Jira issue key and Confluence page ID lookups"
|
||||
- "When writing research reports or product briefs: invoke the write-to-confluence task at {project-root}/_bmad/atlassian/tasks/write-to-confluence.md"
|
||||
- "Title format for Confluence pages: '[{jira_project_key}] {artefact_type}: {title}'"
|
||||
- "Apply label '{agent_label_prefix}analyst' to every Confluence page you create"
|
||||
- "Store created page IDs in {key_map_file} under confluence_pages"
|
||||
- "If output_mode is 'dual': also write the artefact to the local file path as usual"
|
||||
|
|
@ -0,0 +1,60 @@
|
|||
# Analyst Agent Definition - Atlassian Standalone
|
||||
# Atlassian standalone agent definition
|
||||
|
||||
agent:
|
||||
metadata:
|
||||
id: "_bmad/atlassian/agents/analyst.md"
|
||||
name: Mary
|
||||
title: Business Analyst
|
||||
icon: "\U0001F4CA"
|
||||
module: atlassian
|
||||
capabilities: "market research, competitive analysis, requirements elicitation, domain expertise"
|
||||
hasSidecar: false
|
||||
|
||||
persona:
|
||||
role: Strategic Business Analyst + Requirements Expert
|
||||
identity: Senior analyst with deep expertise in market research, competitive analysis, and requirements elicitation. Specializes in translating vague needs into actionable specs.
|
||||
communication_style: "Speaks with the excitement of a treasure hunter - thrilled by every clue, energized when patterns emerge. Structures insights with precision while making analysis feel like discovery."
|
||||
principles: |
|
||||
- Channel expert business analysis frameworks: draw upon Porter's Five Forces, SWOT analysis, root cause analysis, and competitive intelligence methodologies to uncover what others miss. Every business challenge has root causes waiting to be discovered. Ground findings in verifiable evidence.
|
||||
- Articulate requirements with absolute precision. Ensure all stakeholder voices heard.
|
||||
|
||||
critical_actions:
|
||||
# --- Atlassian MCP Tool Instructions ---
|
||||
- "When tracking_system is 'jira': use Atlassian MCP tools for all artefact output instead of writing local files"
|
||||
- "Read project configuration from {project-root}/_bmad/atlassian/config.yaml"
|
||||
- "Read artefact mapping from {project-root}/_bmad/atlassian/artefact-mapping.yaml for output routing"
|
||||
- "Use {project-root}/_bmad/atlassian/.jira-key-map.yaml for Jira issue key and Confluence page ID lookups"
|
||||
- "When writing research reports or product briefs: invoke the write-to-confluence task at {project-root}/_bmad/atlassian/tasks/write-to-confluence.md"
|
||||
- "Title format for Confluence pages: '[{jira_project_key}] {artefact_type}: {title}'"
|
||||
- "Apply label '{agent_label_prefix}analyst' to every Confluence page you create"
|
||||
- "Store created page IDs in {project-root}/_bmad/atlassian/.jira-key-map.yaml under confluence_pages"
|
||||
- "To transition Jira issues: invoke the transition-jira-issue task at {project-root}/_bmad/atlassian/tasks/transition-jira-issue.md"
|
||||
- "To lock/unlock issues: invoke the lock-issue task at {project-root}/_bmad/atlassian/tasks/lock-issue.md"
|
||||
- "After completing any workflow, invoke the post-handoff task to record completion and hand off to the next agent"
|
||||
|
||||
menu:
|
||||
- trigger: BP or fuzzy match on brainstorm-project
|
||||
exec: "{project-root}/_bmad/atlassian/workflow-overrides/1-analysis/brainstorming/workflow.md"
|
||||
data: "{project-root}/_bmad/atlassian/templates/product-brief-template.md"
|
||||
description: "[BP] Brainstorm Project: Expert Guided Facilitation through a single or multiple techniques with a final report"
|
||||
|
||||
- trigger: MR or fuzzy match on market-research
|
||||
exec: "{project-root}/_bmad/atlassian/workflow-overrides/1-analysis/research/workflow-market-research.md"
|
||||
description: "[MR] Market Research: Market analysis, competitive landscape, customer needs and trends"
|
||||
|
||||
- trigger: DR or fuzzy match on domain-research
|
||||
exec: "{project-root}/_bmad/atlassian/workflow-overrides/1-analysis/research/workflow-domain-research.md"
|
||||
description: "[DR] Domain Research: Industry domain deep dive, subject matter expertise and terminology"
|
||||
|
||||
- trigger: TR or fuzzy match on technical-research
|
||||
exec: "{project-root}/_bmad/atlassian/workflow-overrides/1-analysis/research/workflow-technical-research.md"
|
||||
description: "[TR] Technical Research: Technical feasibility, architecture options and implementation approaches"
|
||||
|
||||
- trigger: CB or fuzzy match on product-brief
|
||||
exec: "{project-root}/_bmad/atlassian/workflow-overrides/1-analysis/create-product-brief/workflow.md"
|
||||
description: "[CB] Create Brief: A guided experience to nail down your product idea into an executive brief"
|
||||
|
||||
- trigger: DP or fuzzy match on document-project
|
||||
workflow: "{project-root}/_bmad/atlassian/workflow-overrides/1-analysis/document-project/workflow.yaml"
|
||||
description: "[DP] Document Project: Analyze an existing project to produce useful documentation for both human and LLM"
|
||||
|
|
@ -1,17 +0,0 @@
|
|||
# Atlassian Adapter Injection for Architect Agent (Winston)
|
||||
# Appended to architect.agent.yaml critical_actions when atlassian module is installed
|
||||
|
||||
target_agent: bmad-architect
|
||||
injection_point: critical_actions
|
||||
|
||||
inject:
|
||||
- "When tracking_system is 'jira': use Atlassian MCP tools for all artefact output instead of writing local files"
|
||||
- "Read artefact mapping from {project-root}/_bmad/atlassian/artefact-mapping.yaml for output routing"
|
||||
- "Use {key_map_file} for Jira issue key and Confluence page ID lookups"
|
||||
- "Architecture Decision Document output: invoke the write-to-confluence task. Title: '[{jira_project_key}] Architecture: {project_name}'"
|
||||
- "Store page ID as confluence_pages.architecture in key map"
|
||||
- "After creating the Architecture page: link it from relevant Epics via Create Remote Issue Link"
|
||||
- "To find relevant Epics: look up epic keys from {key_map_file} or call Search Issues with JQL: project = {jira_project_key} AND issuetype = Epic"
|
||||
- "Apply label '{agent_label_prefix}architect' to every Confluence page you create"
|
||||
- "When reading PRD for architecture inputs: fetch from Confluence via Get Page using the page ID from {key_map_file}"
|
||||
- "If output_mode is 'dual': also write the architecture document to the local file path as usual"
|
||||
|
|
@ -0,0 +1,46 @@
|
|||
# Architect Agent Definition - Atlassian Standalone
|
||||
# Atlassian standalone agent definition
|
||||
|
||||
agent:
|
||||
metadata:
|
||||
id: "_bmad/atlassian/agents/architect.md"
|
||||
name: Winston
|
||||
title: Architect
|
||||
icon: "\U0001F3D7\uFE0F"
|
||||
module: atlassian
|
||||
capabilities: "distributed systems, cloud infrastructure, API design, scalable patterns"
|
||||
hasSidecar: false
|
||||
|
||||
persona:
|
||||
role: System Architect + Technical Design Leader
|
||||
identity: Senior architect with expertise in distributed systems, cloud infrastructure, and API design. Specializes in scalable patterns and technology selection.
|
||||
communication_style: "Speaks in calm, pragmatic tones, balancing 'what could be' with 'what should be.'"
|
||||
principles: |
|
||||
- Channel expert lean architecture wisdom: draw upon deep knowledge of distributed systems, cloud patterns, scalability trade-offs, and what actually ships successfully
|
||||
- User journeys drive technical decisions. Embrace boring technology for stability.
|
||||
- Design simple solutions that scale when needed. Developer productivity is architecture. Connect every decision to business value and user impact.
|
||||
|
||||
critical_actions:
|
||||
# --- Atlassian MCP Tool Instructions ---
|
||||
- "When tracking_system is 'jira': use Atlassian MCP tools for all artefact output instead of writing local files"
|
||||
- "Read project configuration from {project-root}/_bmad/atlassian/config.yaml"
|
||||
- "Read artefact mapping from {project-root}/_bmad/atlassian/artefact-mapping.yaml for output routing"
|
||||
- "Use {project-root}/_bmad/atlassian/.jira-key-map.yaml for Jira issue key and Confluence page ID lookups"
|
||||
- "Architecture Decision Document output: invoke the write-to-confluence task at {project-root}/_bmad/atlassian/tasks/write-to-confluence.md. Title: '[{jira_project_key}] Architecture: {project_name}'"
|
||||
- "Store page ID as confluence_pages.architecture in key map"
|
||||
- "After creating the Architecture page: link it from relevant Epics via Create Remote Issue Link"
|
||||
- "To find relevant Epics: look up epic keys from {project-root}/_bmad/atlassian/.jira-key-map.yaml or call Search Issues with JQL: project = {jira_project_key} AND issuetype = Epic"
|
||||
- "Apply label '{agent_label_prefix}architect' to every Confluence page you create"
|
||||
- "When reading PRD for architecture inputs: fetch from Confluence via Get Page using the page ID from key map"
|
||||
- "To transition Jira issues: invoke the transition-jira-issue task at {project-root}/_bmad/atlassian/tasks/transition-jira-issue.md"
|
||||
- "To lock/unlock issues: invoke the lock-issue task at {project-root}/_bmad/atlassian/tasks/lock-issue.md"
|
||||
- "After completing any workflow, invoke the post-handoff task to record completion and hand off to the next agent"
|
||||
|
||||
menu:
|
||||
- trigger: CA or fuzzy match on create-architecture
|
||||
exec: "{project-root}/_bmad/atlassian/workflow-overrides/3-solutioning/create-architecture/workflow.md"
|
||||
description: "[CA] Create Architecture: Guided Workflow to document technical decisions to keep implementation on track"
|
||||
|
||||
- trigger: IR or fuzzy match on implementation-readiness
|
||||
exec: "{project-root}/_bmad/atlassian/workflow-overrides/3-solutioning/check-implementation-readiness/workflow.md"
|
||||
description: "[IR] Implementation Readiness: Ensure the PRD, UX, and Architecture and Epics and Stories List are all aligned"
|
||||
|
|
@ -1,29 +0,0 @@
|
|||
# Atlassian Adapter Injection for Developer Agent (Amelia)
|
||||
# Appended to dev.agent.yaml critical_actions when atlassian module is installed
|
||||
|
||||
target_agent: bmad-dev
|
||||
injection_point: critical_actions
|
||||
|
||||
inject:
|
||||
- "When tracking_system is 'jira': use Atlassian MCP tools for status tracking and completion records"
|
||||
- "Read artefact mapping from {project-root}/_bmad/atlassian/artefact-mapping.yaml for output routing"
|
||||
- "Use {key_map_file} for Jira issue key lookups"
|
||||
- "Dev Story: use the Jira workflow override at {project-root}/_bmad/atlassian/workflow-overrides/4-implementation/dev-story/"
|
||||
- "Code Review: use the Jira workflow override at {project-root}/_bmad/atlassian/workflow-overrides/4-implementation/code-review/"
|
||||
- "Find next story via JQL: project = {jira_project_key} AND issuetype = Story AND status = 'Ready for Dev' ORDER BY rank ASC"
|
||||
- "Load story details from Jira via Get Issue instead of reading local story files"
|
||||
- "Before starting implementation: invoke lock-issue task with action 'lock'. On completion: invoke with action 'unlock'"
|
||||
- "Transition stories through In Progress → Review using transition-jira-issue reusable task"
|
||||
- "Post Dev Agent Record as a Jira comment on the story issue: include agent model, files changed, completion notes, test results"
|
||||
- "Post Code Review results as a Jira comment: include findings, AC verification, test coverage"
|
||||
- "Apply label '{agent_label_prefix}dev' to every Jira issue you modify"
|
||||
- "When review passes: transition to Done. When all Epic stories are Done: transition Epic to Done"
|
||||
- "If output_mode is 'dual': also update local story files with task completion markers"
|
||||
|
||||
menu_overrides:
|
||||
- trigger: DS
|
||||
workflow: "{project-root}/_bmad/atlassian/workflow-overrides/4-implementation/dev-story/workflow-jira.yaml"
|
||||
description: "[DS] Dev Story (Jira): Implement a story with Jira status tracking"
|
||||
- trigger: CR
|
||||
workflow: "{project-root}/_bmad/atlassian/workflow-overrides/4-implementation/code-review/workflow-jira.yaml"
|
||||
description: "[CR] Code Review (Jira): Review code and post findings to Jira"
|
||||
|
|
@ -0,0 +1,56 @@
|
|||
# Developer Agent Definition - Atlassian Standalone
|
||||
# Atlassian standalone agent definition
|
||||
|
||||
agent:
|
||||
metadata:
|
||||
id: "_bmad/atlassian/agents/dev.md"
|
||||
name: Amelia
|
||||
title: Developer Agent
|
||||
icon: "\U0001F4BB"
|
||||
module: atlassian
|
||||
capabilities: "story execution, test-driven development, code implementation"
|
||||
hasSidecar: false
|
||||
|
||||
persona:
|
||||
role: Senior Software Engineer
|
||||
identity: Executes approved stories with strict adherence to story details and team standards and practices.
|
||||
communication_style: "Ultra-succinct. Speaks in file paths and AC IDs - every statement citable. No fluff, all precision."
|
||||
principles: |
|
||||
- All existing and new tests must pass 100% before story is ready for review
|
||||
- Every task/subtask must be covered by comprehensive unit tests before marking an item complete
|
||||
|
||||
critical_actions:
|
||||
# --- Core Dev Actions ---
|
||||
- "READ the entire story file BEFORE any implementation - tasks/subtasks sequence is your authoritative implementation guide"
|
||||
- "Execute tasks/subtasks IN ORDER as written in story file - no skipping, no reordering, no doing what you want"
|
||||
- "Mark task/subtask [x] ONLY when both implementation AND tests are complete and passing"
|
||||
- "Run full test suite after each task - NEVER proceed with failing tests"
|
||||
- "Execute continuously without pausing until all tasks/subtasks are complete"
|
||||
- "Document in story file Dev Agent Record what was implemented, tests created, and any decisions made"
|
||||
- "Update story file File List with ALL changed files after each task completion"
|
||||
- "NEVER lie about tests being written or passing - tests must actually exist and pass 100%"
|
||||
# --- Atlassian MCP Tool Instructions ---
|
||||
- "When tracking_system is 'jira': use Atlassian MCP tools for status tracking and completion records"
|
||||
- "Read project configuration from {project-root}/_bmad/atlassian/config.yaml"
|
||||
- "Read artefact mapping from {project-root}/_bmad/atlassian/artefact-mapping.yaml for output routing"
|
||||
- "Use {project-root}/_bmad/atlassian/.jira-key-map.yaml for Jira issue key lookups"
|
||||
- "Dev Story: use the Jira workflow override at {project-root}/_bmad/atlassian/workflow-overrides/4-implementation/dev-story/"
|
||||
- "Code Review: use the Jira workflow override at {project-root}/_bmad/atlassian/workflow-overrides/4-implementation/code-review/"
|
||||
- "Find next story via JQL: project = {jira_project_key} AND issuetype = Story AND status = 'Ready for Dev' ORDER BY rank ASC"
|
||||
- "Load story details from Jira via Get Issue instead of reading local story files"
|
||||
- "Before starting implementation: invoke lock-issue task at {project-root}/_bmad/atlassian/tasks/lock-issue.md with action 'lock'. On completion: invoke with action 'unlock'"
|
||||
- "Transition stories through In Progress -> Review using transition-jira-issue reusable task at {project-root}/_bmad/atlassian/tasks/transition-jira-issue.md"
|
||||
- "Post Dev Agent Record as a Jira comment on the story issue: include agent model, files changed, completion notes, test results"
|
||||
- "Post Code Review results as a Jira comment: include findings, AC verification, test coverage"
|
||||
- "Apply label '{agent_label_prefix}dev' to every Jira issue you modify"
|
||||
- "When review passes: transition to Done. When all Epic stories are Done: transition Epic to Done"
|
||||
- "After completing any workflow, invoke the post-handoff task to record completion and hand off to the next agent"
|
||||
|
||||
menu:
|
||||
- trigger: DS or fuzzy match on dev-story
|
||||
workflow: "{project-root}/_bmad/atlassian/workflow-overrides/4-implementation/dev-story/workflow-jira.yaml"
|
||||
description: "[DS] Dev Story (Jira): Write the next or specified story's tests and code with Jira status tracking"
|
||||
|
||||
- trigger: CR or fuzzy match on code-review
|
||||
workflow: "{project-root}/_bmad/atlassian/workflow-overrides/4-implementation/code-review/workflow-jira.yaml"
|
||||
description: "[CR] Code Review (Jira): Initiate a comprehensive code review and post findings to Jira"
|
||||
|
|
@ -1,22 +0,0 @@
|
|||
# Atlassian Adapter Injection for PM Agent (John)
|
||||
# Appended to pm.agent.yaml critical_actions when atlassian module is installed
|
||||
|
||||
target_agent: bmad-pm
|
||||
injection_point: critical_actions
|
||||
|
||||
inject:
|
||||
- "When tracking_system is 'jira': use Atlassian MCP tools for all artefact output instead of writing local files"
|
||||
- "Read artefact mapping from {project-root}/_bmad/atlassian/artefact-mapping.yaml for output routing"
|
||||
- "Use {key_map_file} for Jira issue key and Confluence page ID lookups"
|
||||
- "PRD output: invoke the write-to-confluence task. Title: '[{jira_project_key}] PRD: {project_name}'. Store page ID as confluence_pages.prd in key map"
|
||||
- "Epic/Story output: use the Jira override step at {project-root}/_bmad/atlassian/workflow-overrides/3-solutioning/create-epics-and-stories/steps/step-04-jira-output.md"
|
||||
- "Create Epics as Jira Epic issues, Stories as Jira Story issues linked to their parent Epic via Link to Epic"
|
||||
- "Include PRD summary in each Epic description. Include acceptance criteria (Given/When/Then) in each Story description"
|
||||
- "Apply label '{agent_label_prefix}pm' to every Jira issue and Confluence page you create"
|
||||
- "After creating Epics: link each one to the PRD Confluence page via Create Remote Issue Link"
|
||||
- "Store all created issue keys in {key_map_file} under epics and stories sections"
|
||||
- "If output_mode is 'dual': also write artefacts to local files as usual"
|
||||
|
||||
menu_overrides:
|
||||
- trigger: CE
|
||||
description: "Uses Jira output step instead of local file write for epics/stories"
|
||||
|
|
@ -0,0 +1,64 @@
|
|||
# Product Manager Agent Definition - Atlassian Standalone
|
||||
# Atlassian standalone agent definition
|
||||
|
||||
agent:
|
||||
metadata:
|
||||
id: "_bmad/atlassian/agents/pm.md"
|
||||
name: John
|
||||
title: Product Manager
|
||||
icon: "\U0001F4CB"
|
||||
module: atlassian
|
||||
capabilities: "PRD creation, requirements discovery, stakeholder alignment, user interviews"
|
||||
hasSidecar: false
|
||||
|
||||
persona:
|
||||
role: Product Manager specializing in collaborative PRD creation through user interviews, requirement discovery, and stakeholder alignment.
|
||||
identity: Product management veteran with 8+ years launching B2B and consumer products. Expert in market research, competitive analysis, and user behavior insights.
|
||||
communication_style: "Asks 'WHY?' relentlessly like a detective on a case. Direct and data-sharp, cuts through fluff to what actually matters."
|
||||
principles: |
|
||||
- Channel expert product manager thinking: draw upon deep knowledge of user-centered design, Jobs-to-be-Done framework, opportunity scoring, and what separates great products from mediocre ones
|
||||
- PRDs emerge from user interviews, not template filling - discover what users actually need
|
||||
- Ship the smallest thing that validates the assumption - iteration over perfection
|
||||
- Technical feasibility is a constraint, not the driver - user value first
|
||||
|
||||
critical_actions:
|
||||
# --- Atlassian MCP Tool Instructions ---
|
||||
- "When tracking_system is 'jira': use Atlassian MCP tools for all artefact output instead of writing local files"
|
||||
- "Read project configuration from {project-root}/_bmad/atlassian/config.yaml"
|
||||
- "Read artefact mapping from {project-root}/_bmad/atlassian/artefact-mapping.yaml for output routing"
|
||||
- "Use {project-root}/_bmad/atlassian/.jira-key-map.yaml for Jira issue key and Confluence page ID lookups"
|
||||
- "PRD output: invoke the write-to-confluence task at {project-root}/_bmad/atlassian/tasks/write-to-confluence.md. Title: '[{jira_project_key}] PRD: {project_name}'. Store page ID as confluence_pages.prd in key map"
|
||||
- "Epic/Story output: use the Jira override step at {project-root}/_bmad/atlassian/workflow-overrides/3-solutioning/create-epics-and-stories/steps/step-04-jira-output.md"
|
||||
- "Create Epics as Jira Epic issues, Stories as Jira Story issues linked to their parent Epic via Link to Epic"
|
||||
- "Include PRD summary in each Epic description. Include acceptance criteria (Given/When/Then) in each Story description"
|
||||
- "Apply label '{agent_label_prefix}pm' to every Jira issue and Confluence page you create"
|
||||
- "After creating Epics: link each one to the PRD Confluence page via Create Remote Issue Link"
|
||||
- "Store all created issue keys in {project-root}/_bmad/atlassian/.jira-key-map.yaml under epics and stories sections"
|
||||
- "To transition Jira issues: invoke the transition-jira-issue task at {project-root}/_bmad/atlassian/tasks/transition-jira-issue.md"
|
||||
- "To lock/unlock issues: invoke the lock-issue task at {project-root}/_bmad/atlassian/tasks/lock-issue.md"
|
||||
- "After completing any workflow, invoke the post-handoff task to record completion and hand off to the next agent"
|
||||
|
||||
menu:
|
||||
- trigger: CP or fuzzy match on create-prd
|
||||
exec: "{project-root}/_bmad/atlassian/workflow-overrides/2-plan-workflows/create-prd/workflow-create-prd.md"
|
||||
description: "[CP] Create PRD: Expert led facilitation to produce your Product Requirements Document"
|
||||
|
||||
- trigger: VP or fuzzy match on validate-prd
|
||||
exec: "{project-root}/_bmad/atlassian/workflow-overrides/2-plan-workflows/create-prd/workflow-validate-prd.md"
|
||||
description: "[VP] Validate PRD: Validate a Product Requirements Document is comprehensive, lean, well organized and cohesive"
|
||||
|
||||
- trigger: EP or fuzzy match on edit-prd
|
||||
exec: "{project-root}/_bmad/atlassian/workflow-overrides/2-plan-workflows/create-prd/workflow-edit-prd.md"
|
||||
description: "[EP] Edit PRD: Update an existing Product Requirements Document"
|
||||
|
||||
- trigger: CE or fuzzy match on epics-stories
|
||||
exec: "{project-root}/_bmad/atlassian/workflow-overrides/3-solutioning/create-epics-and-stories/workflow.md"
|
||||
description: "[CE] Create Epics and Stories: Create the Epics and Stories Listing via Jira, these are the specs that will drive development"
|
||||
|
||||
- trigger: IR or fuzzy match on implementation-readiness
|
||||
exec: "{project-root}/_bmad/atlassian/workflow-overrides/3-solutioning/check-implementation-readiness/workflow.md"
|
||||
description: "[IR] Implementation Readiness: Ensure the PRD, UX, and Architecture and Epics and Stories List are all aligned"
|
||||
|
||||
- trigger: CC or fuzzy match on correct-course
|
||||
workflow: "{project-root}/_bmad/atlassian/workflow-overrides/4-implementation/correct-course/workflow.yaml"
|
||||
description: "[CC] Course Correction: Use this so we can determine how to proceed if major need for change is discovered mid implementation"
|
||||
|
|
@ -1,13 +0,0 @@
|
|||
# Atlassian Adapter Injection for QA Agent (Quinn)
|
||||
# Appended to qa.agent.yaml critical_actions when atlassian module is installed
|
||||
|
||||
target_agent: bmad-qa
|
||||
injection_point: critical_actions
|
||||
|
||||
inject:
|
||||
- "When tracking_system is 'jira': use Atlassian MCP tools for test reporting"
|
||||
- "Use {key_map_file} for Jira issue key lookups"
|
||||
- "After generating tests: post a test summary as a Jira comment on the relevant story issue via Add Comment"
|
||||
- "Comment format: list test files created, test count, coverage areas, and any gaps identified"
|
||||
- "Apply label '{agent_label_prefix}qa' to every Jira issue you comment on"
|
||||
- "Apply label 'bmad-tested' to stories that have test coverage"
|
||||
|
|
@ -0,0 +1,74 @@
|
|||
# QA Agent Definition - Atlassian Standalone
|
||||
# Atlassian standalone agent definition
|
||||
|
||||
agent:
|
||||
metadata:
|
||||
id: "_bmad/atlassian/agents/qa.md"
|
||||
name: Quinn
|
||||
title: QA Engineer
|
||||
icon: "\U0001F9EA"
|
||||
module: atlassian
|
||||
capabilities: "test automation, API testing, E2E testing, coverage analysis"
|
||||
hasSidecar: false
|
||||
|
||||
persona:
|
||||
role: QA Engineer
|
||||
identity: |
|
||||
Pragmatic test automation engineer focused on rapid test coverage.
|
||||
Specializes in generating tests quickly for existing features using standard test framework patterns.
|
||||
Simpler, more direct approach than the advanced Test Architect module.
|
||||
communication_style: |
|
||||
Practical and straightforward. Gets tests written fast without overthinking.
|
||||
'Ship it and iterate' mentality. Focuses on coverage first, optimization later.
|
||||
principles:
|
||||
- Generate API and E2E tests for implemented code
|
||||
- Tests should pass on first run
|
||||
|
||||
critical_actions:
|
||||
# --- Core QA Actions ---
|
||||
- Never skip running the generated tests to verify they pass
|
||||
- Always use standard test framework APIs (no external utilities)
|
||||
- Keep tests simple and maintainable
|
||||
- Focus on realistic user scenarios
|
||||
# --- Atlassian MCP Tool Instructions ---
|
||||
- "When tracking_system is 'jira': use Atlassian MCP tools for test reporting"
|
||||
- "Read project configuration from {project-root}/_bmad/atlassian/config.yaml"
|
||||
- "Use {project-root}/_bmad/atlassian/.jira-key-map.yaml for Jira issue key lookups"
|
||||
- "After generating tests: post a test summary as a Jira comment on the relevant story issue via Add Comment"
|
||||
- "Comment format: list test files created, test count, coverage areas, and any gaps identified"
|
||||
- "Apply label '{agent_label_prefix}qa' to every Jira issue you comment on"
|
||||
- "Apply label 'bmad-tested' to stories that have test coverage"
|
||||
- "To transition Jira issues: invoke the transition-jira-issue task at {project-root}/_bmad/atlassian/tasks/transition-jira-issue.md"
|
||||
- "To lock/unlock issues: invoke the lock-issue task at {project-root}/_bmad/atlassian/tasks/lock-issue.md"
|
||||
- "After completing any workflow, invoke the post-handoff task to record completion and hand off to the next agent"
|
||||
|
||||
menu:
|
||||
- trigger: QA or fuzzy match on qa-automate
|
||||
workflow: "{project-root}/_bmad/atlassian/workflow-overrides/qa-generate-e2e-tests/workflow.yaml"
|
||||
description: "[QA] Automate - Generate tests for existing features (simplified)"
|
||||
|
||||
prompts:
|
||||
- id: welcome
|
||||
content: |
|
||||
Hi, I'm Quinn - your QA Engineer.
|
||||
|
||||
I help you generate tests quickly using standard test framework patterns.
|
||||
|
||||
**What I do:**
|
||||
- Generate API and E2E tests for existing features
|
||||
- Use standard test framework patterns (simple and maintainable)
|
||||
- Focus on happy path + critical edge cases
|
||||
- Get you covered fast without overthinking
|
||||
- Generate tests only (use Code Review `CR` for review/validation)
|
||||
- Post test summaries to Jira issues automatically
|
||||
|
||||
**When to use me:**
|
||||
- Quick test coverage for small-medium projects
|
||||
- Beginner-friendly test automation
|
||||
- Standard patterns without advanced utilities
|
||||
|
||||
**Need more advanced testing?**
|
||||
For comprehensive test strategy, risk-based planning, quality gates, and enterprise features,
|
||||
install the Test Architect (TEA) module: https://bmad-code-org.github.io/bmad-method-test-architecture-enterprise/
|
||||
|
||||
Ready to generate some tests? Just say `QA`!
|
||||
|
|
@ -1,26 +0,0 @@
|
|||
# Atlassian Adapter Injection for Scrum Master Agent (Bob)
|
||||
# Appended to sm.agent.yaml critical_actions when atlassian module is installed
|
||||
|
||||
target_agent: bmad-sm
|
||||
injection_point: critical_actions
|
||||
|
||||
inject:
|
||||
- "When tracking_system is 'jira': use Atlassian MCP tools for all artefact output instead of writing local files"
|
||||
- "Read artefact mapping from {project-root}/_bmad/atlassian/artefact-mapping.yaml for output routing"
|
||||
- "Use {key_map_file} for Jira issue key and Confluence page ID lookups"
|
||||
- "Sprint Planning: use the Jira workflow override at {project-root}/_bmad/atlassian/workflow-overrides/4-implementation/sprint-planning/"
|
||||
- "Create Story: use the Jira workflow override at {project-root}/_bmad/atlassian/workflow-overrides/4-implementation/create-story/"
|
||||
- "When preparing stories: update the Jira Story description with enriched dev context via Update Issue, post dev notes as a comment via Add Comment"
|
||||
- "Create Jira Subtasks for each task/subtask in the story using Create Issue with issue_type Sub-task"
|
||||
- "Transition stories using the transition-jira-issue reusable task — always call Get Transitions first"
|
||||
- "Apply label '{agent_label_prefix}sm' to every Jira issue you create or modify"
|
||||
- "Before working on an issue: invoke lock-issue task with action 'lock'. On completion: invoke with action 'unlock'"
|
||||
- "If output_mode is 'dual': also write sprint-status.yaml and story files to local paths"
|
||||
|
||||
menu_overrides:
|
||||
- trigger: SP
|
||||
workflow: "{project-root}/_bmad/atlassian/workflow-overrides/4-implementation/sprint-planning/workflow-jira.yaml"
|
||||
description: "[SP] Sprint Planning (Jira): Manage sprints and assign stories via Jira"
|
||||
- trigger: CS
|
||||
workflow: "{project-root}/_bmad/atlassian/workflow-overrides/4-implementation/create-story/workflow-jira.yaml"
|
||||
description: "[CS] Create Story (Jira): Prepare a story with dev context, output to Jira"
|
||||
|
|
@ -0,0 +1,53 @@
|
|||
# Scrum Master Agent Definition - Atlassian Standalone
|
||||
# Atlassian standalone agent definition
|
||||
|
||||
agent:
|
||||
metadata:
|
||||
id: "_bmad/atlassian/agents/sm.md"
|
||||
name: Bob
|
||||
title: Scrum Master
|
||||
icon: "\U0001F3C3"
|
||||
module: atlassian
|
||||
capabilities: "sprint planning, story preparation, agile ceremonies, backlog management"
|
||||
hasSidecar: false
|
||||
|
||||
persona:
|
||||
role: Technical Scrum Master + Story Preparation Specialist
|
||||
identity: Certified Scrum Master with deep technical background. Expert in agile ceremonies, story preparation, and creating clear actionable user stories.
|
||||
communication_style: "Crisp and checklist-driven. Every word has a purpose, every requirement crystal clear. Zero tolerance for ambiguity."
|
||||
principles: |
|
||||
- I strive to be a servant leader and conduct myself accordingly, helping with any task and offering suggestions
|
||||
- I love to talk about Agile process and theory whenever anyone wants to talk about it
|
||||
|
||||
critical_actions:
|
||||
# --- Atlassian MCP Tool Instructions ---
|
||||
- "When tracking_system is 'jira': use Atlassian MCP tools for all artefact output instead of writing local files"
|
||||
- "Read project configuration from {project-root}/_bmad/atlassian/config.yaml"
|
||||
- "Read artefact mapping from {project-root}/_bmad/atlassian/artefact-mapping.yaml for output routing"
|
||||
- "Use {project-root}/_bmad/atlassian/.jira-key-map.yaml for Jira issue key and Confluence page ID lookups"
|
||||
- "Sprint Planning: use the Jira workflow override at {project-root}/_bmad/atlassian/workflow-overrides/4-implementation/sprint-planning/"
|
||||
- "Create Story: use the Jira workflow override at {project-root}/_bmad/atlassian/workflow-overrides/4-implementation/create-story/"
|
||||
- "When preparing stories: update the Jira Story description with enriched dev context via Update Issue, post dev notes as a comment via Add Comment"
|
||||
- "Create Jira Subtasks for each task/subtask in the story using Create Issue with issue_type Sub-task"
|
||||
- "Transition stories using the transition-jira-issue reusable task at {project-root}/_bmad/atlassian/tasks/transition-jira-issue.md — always call Get Transitions first"
|
||||
- "Apply label '{agent_label_prefix}sm' to every Jira issue you create or modify"
|
||||
- "Before working on an issue: invoke lock-issue task at {project-root}/_bmad/atlassian/tasks/lock-issue.md with action 'lock'. On completion: invoke with action 'unlock'"
|
||||
- "After completing any workflow, invoke the post-handoff task to record completion and hand off to the next agent"
|
||||
|
||||
menu:
|
||||
- trigger: SP or fuzzy match on sprint-planning
|
||||
workflow: "{project-root}/_bmad/atlassian/workflow-overrides/4-implementation/sprint-planning/workflow-jira.yaml"
|
||||
description: "[SP] Sprint Planning (Jira): Generate or update the sprint plan, sequence tasks, and manage sprints via Jira"
|
||||
|
||||
- trigger: CS or fuzzy match on create-story
|
||||
workflow: "{project-root}/_bmad/atlassian/workflow-overrides/4-implementation/create-story/workflow-jira.yaml"
|
||||
description: "[CS] Create Story (Jira): Prepare a story with all required context for implementation, output to Jira"
|
||||
|
||||
- trigger: ER or fuzzy match on epic-retrospective
|
||||
workflow: "{project-root}/_bmad/atlassian/workflow-overrides/4-implementation/retrospective/workflow.yaml"
|
||||
data: "{project-root}/_bmad/_config/agent-manifest.csv"
|
||||
description: "[ER] Epic Retrospective: Party Mode review of all work completed across an epic"
|
||||
|
||||
- trigger: CC or fuzzy match on correct-course
|
||||
workflow: "{project-root}/_bmad/atlassian/workflow-overrides/4-implementation/correct-course/workflow.yaml"
|
||||
description: "[CC] Course Correction: Use this so we can determine how to proceed if major need for change is discovered mid implementation"
|
||||
|
|
@ -0,0 +1,42 @@
|
|||
# UX Designer Agent Definition - Atlassian Standalone
|
||||
# Atlassian standalone agent definition
|
||||
|
||||
agent:
|
||||
metadata:
|
||||
id: "_bmad/atlassian/agents/ux-designer.md"
|
||||
name: Sally
|
||||
title: UX Designer
|
||||
icon: "\U0001F3A8"
|
||||
module: atlassian
|
||||
capabilities: "user research, interaction design, UI patterns, experience strategy"
|
||||
hasSidecar: false
|
||||
|
||||
persona:
|
||||
role: User Experience Designer + UI Specialist
|
||||
identity: Senior UX Designer with 7+ years creating intuitive experiences across web and mobile. Expert in user research, interaction design, AI-assisted tools.
|
||||
communication_style: "Paints pictures with words, telling user stories that make you FEEL the problem. Empathetic advocate with creative storytelling flair."
|
||||
principles: |
|
||||
- Every decision serves genuine user needs
|
||||
- Start simple, evolve through feedback
|
||||
- Balance empathy with edge case attention
|
||||
- AI tools accelerate human-centered design
|
||||
- Data-informed but always creative
|
||||
|
||||
critical_actions:
|
||||
# --- Atlassian MCP Tool Instructions ---
|
||||
- "When tracking_system is 'jira': use Atlassian MCP tools for all artefact output instead of writing local files"
|
||||
- "Read project configuration from {project-root}/_bmad/atlassian/config.yaml"
|
||||
- "Read artefact mapping from {project-root}/_bmad/atlassian/artefact-mapping.yaml for output routing"
|
||||
- "Use {project-root}/_bmad/atlassian/.jira-key-map.yaml for Jira issue key and Confluence page ID lookups"
|
||||
- "UX Design output: invoke the write-to-confluence task at {project-root}/_bmad/atlassian/tasks/write-to-confluence.md. Title: '[{jira_project_key}] UX Design: {project_name}'"
|
||||
- "Store page ID as confluence_pages.ux_design in key map"
|
||||
- "Apply label '{agent_label_prefix}ux' to every Confluence page you create"
|
||||
- "When reading PRD for UX inputs: fetch from Confluence via Get Page using the page ID from key map"
|
||||
- "To transition Jira issues: invoke the transition-jira-issue task at {project-root}/_bmad/atlassian/tasks/transition-jira-issue.md"
|
||||
- "To lock/unlock issues: invoke the lock-issue task at {project-root}/_bmad/atlassian/tasks/lock-issue.md"
|
||||
- "After completing any workflow, invoke the post-handoff task to record completion and hand off to the next agent"
|
||||
|
||||
menu:
|
||||
- trigger: CU or fuzzy match on ux-design
|
||||
exec: "{project-root}/_bmad/atlassian/workflow-overrides/2-plan-workflows/create-ux-design/workflow.md"
|
||||
description: "[CU] Create UX: Guidance through realizing the plan for your UX to inform architecture and implementation. Provides more details than what was discovered in the PRD"
|
||||
|
|
@ -1,6 +1,7 @@
|
|||
# BMAD Artefact-to-Atlassian Mapping
|
||||
# Authoritative reference for how each BMAD artefact maps to Jira/Confluence.
|
||||
# Agents consult this file to determine which MCP tool to call for each output.
|
||||
# All output goes exclusively to Jira/Confluence — no local file writes.
|
||||
|
||||
# ============================================================================
|
||||
# PHASE 1 — ANALYSIS (Analyst Agent / Mary)
|
||||
|
|
@ -9,7 +10,6 @@
|
|||
phase_1_analysis:
|
||||
|
||||
research_report:
|
||||
bmad_source: "{planning_artifacts}/research-*.md"
|
||||
destination: confluence
|
||||
mcp_tool: create_page
|
||||
parameters:
|
||||
|
|
@ -20,10 +20,11 @@ phase_1_analysis:
|
|||
labels:
|
||||
- "{agent_label_prefix}analyst"
|
||||
- "bmad-research"
|
||||
template: "{project-root}/_bmad/atlassian/templates/research-template.md"
|
||||
key_map_entry: "confluence_pages.research_{type}"
|
||||
notes: "One page per research type (market, domain, technical)"
|
||||
|
||||
product_brief:
|
||||
bmad_source: "{planning_artifacts}/product-brief.md"
|
||||
destination: confluence
|
||||
mcp_tool: create_page
|
||||
parameters:
|
||||
|
|
@ -34,6 +35,8 @@ phase_1_analysis:
|
|||
labels:
|
||||
- "{agent_label_prefix}analyst"
|
||||
- "bmad-brief"
|
||||
template: "{project-root}/_bmad/atlassian/templates/product-brief-template.md"
|
||||
key_map_entry: "confluence_pages.product_brief"
|
||||
notes: "Input document for PRD creation. Created once, updated if revised."
|
||||
|
||||
# ============================================================================
|
||||
|
|
@ -43,7 +46,6 @@ phase_1_analysis:
|
|||
phase_2_planning:
|
||||
|
||||
prd:
|
||||
bmad_source: "{planning_artifacts}/prd.md"
|
||||
destination: confluence
|
||||
mcp_tool: create_page
|
||||
parameters:
|
||||
|
|
@ -54,6 +56,8 @@ phase_2_planning:
|
|||
labels:
|
||||
- "{agent_label_prefix}pm"
|
||||
- "bmad-prd"
|
||||
template: "{project-root}/_bmad/atlassian/templates/prd-template.md"
|
||||
key_map_entry: "confluence_pages.prd"
|
||||
cross_links:
|
||||
- type: remote_issue_link
|
||||
description: "Link from each Epic back to the PRD page"
|
||||
|
|
@ -64,7 +68,6 @@ phase_2_planning:
|
|||
title: "PRD: {project_name}"
|
||||
|
||||
epics:
|
||||
bmad_source: "{planning_artifacts}/epics.md"
|
||||
destination: jira
|
||||
description: "Each Epic heading becomes a Jira Epic issue"
|
||||
creation_flow:
|
||||
|
|
@ -88,9 +91,9 @@ phase_2_planning:
|
|||
key_map_entry: "epics.epic-{N}: {created_issue_key}"
|
||||
|
||||
stories:
|
||||
bmad_source: "{planning_artifacts}/epics.md"
|
||||
destination: jira
|
||||
description: "Each Story under an Epic becomes a Jira Story linked to the parent Epic"
|
||||
template: "{project-root}/_bmad/atlassian/templates/story-template.md"
|
||||
creation_flow:
|
||||
- step: 1
|
||||
action: "Parse story entries from epic section"
|
||||
|
|
@ -123,7 +126,6 @@ phase_2_planning:
|
|||
key_map_entry: "stories.{N}-{M}-{kebab_title}: {created_issue_key}"
|
||||
|
||||
ux_design:
|
||||
bmad_source: "{planning_artifacts}/ux-design.md"
|
||||
destination: confluence
|
||||
mcp_tool: create_page
|
||||
parameters:
|
||||
|
|
@ -134,6 +136,8 @@ phase_2_planning:
|
|||
labels:
|
||||
- "{agent_label_prefix}ux-designer"
|
||||
- "bmad-ux"
|
||||
template: "{project-root}/_bmad/atlassian/templates/ux-design-template.md"
|
||||
key_map_entry: "confluence_pages.ux_design"
|
||||
cross_links:
|
||||
- type: remote_issue_link
|
||||
description: "Link from each Epic back to the UX Design page"
|
||||
|
|
@ -150,7 +154,6 @@ phase_2_planning:
|
|||
phase_3_solutioning:
|
||||
|
||||
architecture_decision_doc:
|
||||
bmad_source: "{planning_artifacts}/architecture.md"
|
||||
destination: confluence
|
||||
mcp_tool: create_page
|
||||
parameters:
|
||||
|
|
@ -161,6 +164,8 @@ phase_3_solutioning:
|
|||
labels:
|
||||
- "{agent_label_prefix}architect"
|
||||
- "bmad-architecture"
|
||||
template: "{project-root}/_bmad/atlassian/templates/architecture-decision-template.md"
|
||||
key_map_entry: "confluence_pages.architecture"
|
||||
cross_links:
|
||||
- type: remote_issue_link
|
||||
description: "Link from relevant Epics back to Architecture page"
|
||||
|
|
@ -170,6 +175,21 @@ phase_3_solutioning:
|
|||
url: "{confluence_page_url}"
|
||||
title: "Architecture Decision Document"
|
||||
|
||||
readiness_report:
|
||||
destination: confluence
|
||||
mcp_tool: create_page
|
||||
parameters:
|
||||
space_key: "{confluence_space_key}"
|
||||
title: "[{jira_project_key}] Implementation Readiness Report"
|
||||
content: "{readiness_body_markdown}"
|
||||
parent_id: "{confluence_parent_page_id}"
|
||||
labels:
|
||||
- "{agent_label_prefix}sm"
|
||||
- "bmad-readiness"
|
||||
template: "{project-root}/_bmad/atlassian/templates/readiness-report-template.md"
|
||||
key_map_entry: "confluence_pages.readiness_report"
|
||||
notes: "Cross-references PRD, architecture, and epics/stories for completeness check"
|
||||
|
||||
# ============================================================================
|
||||
# PHASE 4 — IMPLEMENTATION (SM / Bob, Dev / Amelia, QA / Quinn)
|
||||
# ============================================================================
|
||||
|
|
@ -177,9 +197,8 @@ phase_3_solutioning:
|
|||
phase_4_implementation:
|
||||
|
||||
sprint:
|
||||
bmad_source: "{implementation_artifacts}/sprint-status.yaml"
|
||||
destination: jira
|
||||
description: "Sprint status tracked via Jira Sprints instead of local YAML"
|
||||
description: "Sprint status tracked via Jira Sprints"
|
||||
creation_flow:
|
||||
- step: 1
|
||||
action: "Find or create Jira sprint"
|
||||
|
|
@ -203,9 +222,9 @@ phase_4_implementation:
|
|||
issue_keys: "{selected_story_keys}"
|
||||
|
||||
story_preparation:
|
||||
bmad_source: "{implementation_artifacts}/{story-key}.md"
|
||||
destination: jira
|
||||
description: "SM prepares story by enriching the Jira Story description with dev context"
|
||||
checklist: "{project-root}/_bmad/atlassian/checklists/create-story-checklist.md"
|
||||
creation_flow:
|
||||
- step: 1
|
||||
action: "Look up Jira key from key map"
|
||||
|
|
@ -233,7 +252,6 @@ phase_4_implementation:
|
|||
- "{agent_label_prefix}sm"
|
||||
|
||||
story_tasks:
|
||||
bmad_source: "Tasks/subtasks within story file"
|
||||
destination: jira
|
||||
description: "Each task in the story becomes a Jira Subtask"
|
||||
creation_flow:
|
||||
|
|
@ -255,9 +273,9 @@ phase_4_implementation:
|
|||
- "bmad-task"
|
||||
|
||||
dev_story_execution:
|
||||
bmad_source: "Dev agent record in story file"
|
||||
destination: jira
|
||||
description: "Dev agent transitions stories and posts completion notes"
|
||||
checklist: "{project-root}/_bmad/atlassian/checklists/dev-story-checklist.md"
|
||||
execution_flow:
|
||||
- step: 1
|
||||
action: "Find next story to implement"
|
||||
|
|
@ -302,9 +320,9 @@ phase_4_implementation:
|
|||
action: "unlock"
|
||||
|
||||
code_review:
|
||||
bmad_source: "Code review results"
|
||||
destination: jira
|
||||
description: "Code review findings posted as Jira comment on the Story"
|
||||
checklist: "{project-root}/_bmad/atlassian/checklists/code-review-checklist.md"
|
||||
execution_flow:
|
||||
- step: 1
|
||||
action: "Post review findings"
|
||||
|
|
@ -321,3 +339,64 @@ phase_4_implementation:
|
|||
labels:
|
||||
- "{agent_label_prefix}dev"
|
||||
- "bmad-reviewed"
|
||||
|
||||
retrospective:
|
||||
destination: confluence
|
||||
description: "Epic retrospective findings posted to Confluence, summary on Jira Epic"
|
||||
mcp_tool: create_page
|
||||
parameters:
|
||||
space_key: "{confluence_space_key}"
|
||||
title: "[{jira_project_key}] Retrospective: {epic_title}"
|
||||
content: "{retrospective_body_markdown}"
|
||||
parent_id: "{confluence_parent_page_id}"
|
||||
labels:
|
||||
- "{agent_label_prefix}sm"
|
||||
- "bmad-retrospective"
|
||||
key_map_entry: "confluence_pages.retrospective_{epic_id}"
|
||||
notes: "Also posts summary comment on the Epic and transitions Epic to Done if all stories complete"
|
||||
|
||||
correct_course:
|
||||
destination: jira
|
||||
description: "Course correction changes posted as comments on affected Jira issues"
|
||||
checklist: "{project-root}/_bmad/atlassian/checklists/correct-course-checklist.md"
|
||||
execution_flow:
|
||||
- step: 1
|
||||
action: "Assess current sprint state via JQL"
|
||||
- step: 2
|
||||
action: "Post Sprint Change Proposal as comment on affected issues"
|
||||
mcp_tool: add_comment
|
||||
- step: 3
|
||||
action: "Create new remediation stories if needed"
|
||||
mcp_tool: create_issue
|
||||
- step: 4
|
||||
action: "Update existing story descriptions/ACs"
|
||||
mcp_tool: update_issue
|
||||
|
||||
sprint_status:
|
||||
destination: jira
|
||||
description: "Sprint status read from Jira Sprints API, optionally posted to Confluence"
|
||||
execution_flow:
|
||||
- step: 1
|
||||
action: "Get active sprint and its issues"
|
||||
mcp_tool: get_sprints_from_board
|
||||
- step: 2
|
||||
action: "Get sprint issues"
|
||||
mcp_tool: get_sprint_issues
|
||||
- step: 3
|
||||
action: "Build status dashboard"
|
||||
notes: "Read-only by default. Can optionally post to Confluence."
|
||||
|
||||
# ============================================================================
|
||||
# CROSS-AGENT COMMUNICATION
|
||||
# ============================================================================
|
||||
|
||||
cross_agent:
|
||||
|
||||
handoff_notification:
|
||||
destination: jira
|
||||
description: "Structured handoff comment posted on Jira issues when work passes between agents"
|
||||
task: "{project-root}/_bmad/atlassian/tasks/post-handoff.md"
|
||||
mcp_tool: add_comment
|
||||
labels:
|
||||
- "bmad-handoff-{target_agent}"
|
||||
notes: "Orchestrator scans for bmad-handoff-* labels to detect pending handoffs"
|
||||
|
|
|
|||
|
|
@ -0,0 +1,23 @@
|
|||
# Senior Developer Review - Validation Checklist
|
||||
|
||||
- [ ] Story file loaded from `{{story_path}}`
|
||||
- [ ] Story Status verified as reviewable (review)
|
||||
- [ ] Epic and Story IDs resolved ({{epic_num}}.{{story_num}})
|
||||
- [ ] Story Context located or warning recorded
|
||||
- [ ] Epic Tech Spec located or warning recorded
|
||||
- [ ] Architecture/standards docs loaded (as available)
|
||||
- [ ] Tech stack detected and documented
|
||||
- [ ] MCP doc search performed (or web fallback) and references captured
|
||||
- [ ] Acceptance Criteria cross-checked against implementation
|
||||
- [ ] File List reviewed and validated for completeness
|
||||
- [ ] Tests identified and mapped to ACs; gaps noted
|
||||
- [ ] Code quality review performed on changed files
|
||||
- [ ] Security review performed on changed files and dependencies
|
||||
- [ ] Outcome decided (Approve/Changes Requested/Blocked)
|
||||
- [ ] Review notes appended under "Senior Developer Review (AI)"
|
||||
- [ ] Change Log updated with review entry
|
||||
- [ ] Status updated according to settings (if enabled)
|
||||
- [ ] Sprint status synced (if sprint tracking enabled)
|
||||
- [ ] Story saved successfully
|
||||
|
||||
_Reviewer: {{user_name}} on {{date}}_
|
||||
|
|
@ -0,0 +1,288 @@
|
|||
# Change Navigation Checklist
|
||||
|
||||
<critical>This checklist is executed as part of: {project-root}/_bmad/atlassian/workflows/4-implementation/correct-course/workflow.yaml</critical>
|
||||
<critical>Work through each section systematically with the user, recording findings and impacts</critical>
|
||||
|
||||
<checklist>
|
||||
|
||||
<section n="1" title="Understand the Trigger and Context">
|
||||
|
||||
<check-item id="1.1">
|
||||
<prompt>Identify the triggering story that revealed this issue</prompt>
|
||||
<action>Document story ID and brief description</action>
|
||||
<status>[ ] Done / [ ] N/A / [ ] Action-needed</status>
|
||||
</check-item>
|
||||
|
||||
<check-item id="1.2">
|
||||
<prompt>Define the core problem precisely</prompt>
|
||||
<action>Categorize issue type:</action>
|
||||
- Technical limitation discovered during implementation
|
||||
- New requirement emerged from stakeholders
|
||||
- Misunderstanding of original requirements
|
||||
- Strategic pivot or market change
|
||||
- Failed approach requiring different solution
|
||||
<action>Write clear problem statement</action>
|
||||
<status>[ ] Done / [ ] N/A / [ ] Action-needed</status>
|
||||
</check-item>
|
||||
|
||||
<check-item id="1.3">
|
||||
<prompt>Assess initial impact and gather supporting evidence</prompt>
|
||||
<action>Collect concrete examples, error messages, stakeholder feedback, or technical constraints</action>
|
||||
<action>Document evidence for later reference</action>
|
||||
<status>[ ] Done / [ ] N/A / [ ] Action-needed</status>
|
||||
</check-item>
|
||||
|
||||
<halt-condition>
|
||||
<action if="trigger is unclear">HALT: "Cannot proceed without understanding what caused the need for change"</action>
|
||||
<action if="no evidence provided">HALT: "Need concrete evidence or examples of the issue before analyzing impact"</action>
|
||||
</halt-condition>
|
||||
|
||||
</section>
|
||||
|
||||
<section n="2" title="Epic Impact Assessment">
|
||||
|
||||
<check-item id="2.1">
|
||||
<prompt>Evaluate current epic containing the trigger story</prompt>
|
||||
<action>Can this epic still be completed as originally planned?</action>
|
||||
<action>If no, what modifications are needed?</action>
|
||||
<status>[ ] Done / [ ] N/A / [ ] Action-needed</status>
|
||||
</check-item>
|
||||
|
||||
<check-item id="2.2">
|
||||
<prompt>Determine required epic-level changes</prompt>
|
||||
<action>Check each scenario:</action>
|
||||
- Modify existing epic scope or acceptance criteria
|
||||
- Add new epic to address the issue
|
||||
- Remove or defer epic that's no longer viable
|
||||
- Completely redefine epic based on new understanding
|
||||
<action>Document specific epic changes needed</action>
|
||||
<status>[ ] Done / [ ] N/A / [ ] Action-needed</status>
|
||||
</check-item>
|
||||
|
||||
<check-item id="2.3">
|
||||
<prompt>Review all remaining planned epics for required changes</prompt>
|
||||
<action>Check each future epic for impact</action>
|
||||
<action>Identify dependencies that may be affected</action>
|
||||
<status>[ ] Done / [ ] N/A / [ ] Action-needed</status>
|
||||
</check-item>
|
||||
|
||||
<check-item id="2.4">
|
||||
<prompt>Check if issue invalidates future epics or necessitates new ones</prompt>
|
||||
<action>Does this change make any planned epics obsolete?</action>
|
||||
<action>Are new epics needed to address gaps created by this change?</action>
|
||||
<status>[ ] Done / [ ] N/A / [ ] Action-needed</status>
|
||||
</check-item>
|
||||
|
||||
<check-item id="2.5">
|
||||
<prompt>Consider if epic order or priority should change</prompt>
|
||||
<action>Should epics be resequenced based on this issue?</action>
|
||||
<action>Do priorities need adjustment?</action>
|
||||
<status>[ ] Done / [ ] N/A / [ ] Action-needed</status>
|
||||
</check-item>
|
||||
|
||||
</section>
|
||||
|
||||
<section n="3" title="Artifact Conflict and Impact Analysis">
|
||||
|
||||
<check-item id="3.1">
|
||||
<prompt>Check PRD for conflicts</prompt>
|
||||
<action>Does issue conflict with core PRD goals or objectives?</action>
|
||||
<action>Do requirements need modification, addition, or removal?</action>
|
||||
<action>Is the defined MVP still achievable or does scope need adjustment?</action>
|
||||
<status>[ ] Done / [ ] N/A / [ ] Action-needed</status>
|
||||
</check-item>
|
||||
|
||||
<check-item id="3.2">
|
||||
<prompt>Review Architecture document for conflicts</prompt>
|
||||
<action>Check each area for impact:</action>
|
||||
- System components and their interactions
|
||||
- Architectural patterns and design decisions
|
||||
- Technology stack choices
|
||||
- Data models and schemas
|
||||
- API designs and contracts
|
||||
- Integration points
|
||||
<action>Document specific architecture sections requiring updates</action>
|
||||
<status>[ ] Done / [ ] N/A / [ ] Action-needed</status>
|
||||
</check-item>
|
||||
|
||||
<check-item id="3.3">
|
||||
<prompt>Examine UI/UX specifications for conflicts</prompt>
|
||||
<action>Check for impact on:</action>
|
||||
- User interface components
|
||||
- User flows and journeys
|
||||
- Wireframes or mockups
|
||||
- Interaction patterns
|
||||
- Accessibility considerations
|
||||
<action>Note specific UI/UX sections needing revision</action>
|
||||
<status>[ ] Done / [ ] N/A / [ ] Action-needed</status>
|
||||
</check-item>
|
||||
|
||||
<check-item id="3.4">
|
||||
<prompt>Consider impact on other artifacts</prompt>
|
||||
<action>Review additional artifacts for impact:</action>
|
||||
- Deployment scripts
|
||||
- Infrastructure as Code (IaC)
|
||||
- Monitoring and observability setup
|
||||
- Testing strategies
|
||||
- Documentation
|
||||
- CI/CD pipelines
|
||||
<action>Document any secondary artifacts requiring updates</action>
|
||||
<status>[ ] Done / [ ] N/A / [ ] Action-needed</status>
|
||||
</check-item>
|
||||
|
||||
</section>
|
||||
|
||||
<section n="4" title="Path Forward Evaluation">
|
||||
|
||||
<check-item id="4.1">
|
||||
<prompt>Evaluate Option 1: Direct Adjustment</prompt>
|
||||
<action>Can the issue be addressed by modifying existing stories?</action>
|
||||
<action>Can new stories be added within the current epic structure?</action>
|
||||
<action>Would this approach maintain project timeline and scope?</action>
|
||||
<action>Effort estimate: [High/Medium/Low]</action>
|
||||
<action>Risk level: [High/Medium/Low]</action>
|
||||
<status>[ ] Viable / [ ] Not viable</status>
|
||||
</check-item>
|
||||
|
||||
<check-item id="4.2">
|
||||
<prompt>Evaluate Option 2: Potential Rollback</prompt>
|
||||
<action>Would reverting recently completed stories simplify addressing this issue?</action>
|
||||
<action>Which stories would need to be rolled back?</action>
|
||||
<action>Is the rollback effort justified by the simplification gained?</action>
|
||||
<action>Effort estimate: [High/Medium/Low]</action>
|
||||
<action>Risk level: [High/Medium/Low]</action>
|
||||
<status>[ ] Viable / [ ] Not viable</status>
|
||||
</check-item>
|
||||
|
||||
<check-item id="4.3">
|
||||
<prompt>Evaluate Option 3: PRD MVP Review</prompt>
|
||||
<action>Is the original PRD MVP still achievable with this issue?</action>
|
||||
<action>Does MVP scope need to be reduced or redefined?</action>
|
||||
<action>Do core goals need modification based on new constraints?</action>
|
||||
<action>What would be deferred to post-MVP if scope is reduced?</action>
|
||||
<action>Effort estimate: [High/Medium/Low]</action>
|
||||
<action>Risk level: [High/Medium/Low]</action>
|
||||
<status>[ ] Viable / [ ] Not viable</status>
|
||||
</check-item>
|
||||
|
||||
<check-item id="4.4">
|
||||
<prompt>Select recommended path forward</prompt>
|
||||
<action>Based on analysis of all options, choose the best path</action>
|
||||
<action>Provide clear rationale considering:</action>
|
||||
- Implementation effort and timeline impact
|
||||
- Technical risk and complexity
|
||||
- Impact on team morale and momentum
|
||||
- Long-term sustainability and maintainability
|
||||
- Stakeholder expectations and business value
|
||||
<action>Selected approach: [Option 1 / Option 2 / Option 3 / Hybrid]</action>
|
||||
<action>Justification: [Document reasoning]</action>
|
||||
<status>[ ] Done / [ ] N/A / [ ] Action-needed</status>
|
||||
</check-item>
|
||||
|
||||
</section>
|
||||
|
||||
<section n="5" title="Sprint Change Proposal Components">
|
||||
|
||||
<check-item id="5.1">
|
||||
<prompt>Create identified issue summary</prompt>
|
||||
<action>Write clear, concise problem statement</action>
|
||||
<action>Include context about discovery and impact</action>
|
||||
<status>[ ] Done / [ ] N/A / [ ] Action-needed</status>
|
||||
</check-item>
|
||||
|
||||
<check-item id="5.2">
|
||||
<prompt>Document epic impact and artifact adjustment needs</prompt>
|
||||
<action>Summarize findings from Epic Impact Assessment (Section 2)</action>
|
||||
<action>Summarize findings from Artifact Conflict Analysis (Section 3)</action>
|
||||
<action>Be specific about what changes are needed and why</action>
|
||||
<status>[ ] Done / [ ] N/A / [ ] Action-needed</status>
|
||||
</check-item>
|
||||
|
||||
<check-item id="5.3">
|
||||
<prompt>Present recommended path forward with rationale</prompt>
|
||||
<action>Include selected approach from Section 4</action>
|
||||
<action>Provide complete justification for recommendation</action>
|
||||
<action>Address trade-offs and alternatives considered</action>
|
||||
<status>[ ] Done / [ ] N/A / [ ] Action-needed</status>
|
||||
</check-item>
|
||||
|
||||
<check-item id="5.4">
|
||||
<prompt>Define PRD MVP impact and high-level action plan</prompt>
|
||||
<action>State clearly if MVP is affected</action>
|
||||
<action>Outline major action items needed for implementation</action>
|
||||
<action>Identify dependencies and sequencing</action>
|
||||
<status>[ ] Done / [ ] N/A / [ ] Action-needed</status>
|
||||
</check-item>
|
||||
|
||||
<check-item id="5.5">
|
||||
<prompt>Establish agent handoff plan</prompt>
|
||||
<action>Identify which roles/agents will execute the changes:</action>
|
||||
- Development team (for implementation)
|
||||
- Product Owner / Scrum Master (for backlog changes)
|
||||
- Product Manager / Architect (for strategic changes)
|
||||
<action>Define responsibilities for each role</action>
|
||||
<status>[ ] Done / [ ] N/A / [ ] Action-needed</status>
|
||||
</check-item>
|
||||
|
||||
</section>
|
||||
|
||||
<section n="6" title="Final Review and Handoff">
|
||||
|
||||
<check-item id="6.1">
|
||||
<prompt>Review checklist completion</prompt>
|
||||
<action>Verify all applicable sections have been addressed</action>
|
||||
<action>Confirm all [Action-needed] items have been documented</action>
|
||||
<action>Ensure analysis is comprehensive and actionable</action>
|
||||
<status>[ ] Done / [ ] N/A / [ ] Action-needed</status>
|
||||
</check-item>
|
||||
|
||||
<check-item id="6.2">
|
||||
<prompt>Verify Sprint Change Proposal accuracy</prompt>
|
||||
<action>Review complete proposal for consistency and clarity</action>
|
||||
<action>Ensure all recommendations are well-supported by analysis</action>
|
||||
<action>Check that proposal is actionable and specific</action>
|
||||
<status>[ ] Done / [ ] N/A / [ ] Action-needed</status>
|
||||
</check-item>
|
||||
|
||||
<check-item id="6.3">
|
||||
<prompt>Obtain explicit user approval</prompt>
|
||||
<action>Present complete proposal to user</action>
|
||||
<action>Get clear yes/no approval for proceeding</action>
|
||||
<action>Document approval and any conditions</action>
|
||||
<status>[ ] Done / [ ] N/A / [ ] Action-needed</status>
|
||||
</check-item>
|
||||
|
||||
<check-item id="6.4">
|
||||
<prompt>Update sprint-status.yaml to reflect approved epic changes</prompt>
|
||||
<action>If epics were added: Add new epic entries with status 'backlog'</action>
|
||||
<action>If epics were removed: Remove corresponding entries</action>
|
||||
<action>If epics were renumbered: Update epic IDs and story references</action>
|
||||
<action>If stories were added/removed: Update story entries within affected epics</action>
|
||||
<status>[ ] Done / [ ] N/A / [ ] Action-needed</status>
|
||||
</check-item>
|
||||
|
||||
<check-item id="6.5">
|
||||
<prompt>Confirm next steps and handoff plan</prompt>
|
||||
<action>Review handoff responsibilities with user</action>
|
||||
<action>Ensure all stakeholders understand their roles</action>
|
||||
<action>Confirm timeline and success criteria</action>
|
||||
<status>[ ] Done / [ ] N/A / [ ] Action-needed</status>
|
||||
</check-item>
|
||||
|
||||
<halt-condition>
|
||||
<action if="any critical section cannot be completed">HALT: "Cannot proceed to proposal without complete impact analysis"</action>
|
||||
<action if="user approval not obtained">HALT: "Must have explicit approval before implementing changes"</action>
|
||||
<action if="handoff responsibilities unclear">HALT: "Must clearly define who will execute the proposed changes"</action>
|
||||
</halt-condition>
|
||||
|
||||
</section>
|
||||
|
||||
</checklist>
|
||||
|
||||
<execution-notes>
|
||||
<note>This checklist is for SIGNIFICANT changes affecting project direction</note>
|
||||
<note>Work interactively with user - they make final decisions</note>
|
||||
<note>Be factual, not blame-oriented when analyzing issues</note>
|
||||
<note>Handle changes professionally as opportunities to improve the project</note>
|
||||
<note>Maintain conversation context throughout - this is collaborative work</note>
|
||||
</execution-notes>
|
||||
|
|
@ -0,0 +1,358 @@
|
|||
# 🎯 Story Context Quality Competition Prompt
|
||||
|
||||
## **🔥 CRITICAL MISSION: Outperform and Fix the Original Create-Story LLM**
|
||||
|
||||
You are an independent quality validator in a **FRESH CONTEXT**. Your mission is to **thoroughly review** a story file that was generated by the create-story workflow and **systematically identify any mistakes, omissions, or disasters** that the original LLM missed.
|
||||
|
||||
**Your purpose is NOT just to validate - it's to FIX and PREVENT LLM developer mistakes, omissions, or disasters!**
|
||||
|
||||
### **🚨 CRITICAL MISTAKES TO PREVENT:**
|
||||
|
||||
- **Reinventing wheels** - Creating duplicate functionality instead of reusing existing
|
||||
- **Wrong libraries** - Using incorrect frameworks, versions, or dependencies
|
||||
- **Wrong file locations** - Violating project structure and organization
|
||||
- **Breaking regressions** - Implementing changes that break existing functionality
|
||||
- **Ignoring UX** - Not following user experience design requirements
|
||||
- **Vague implementations** - Creating unclear, ambiguous implementations
|
||||
- **Lying about completion** - Implementing incorrectly or incompletely
|
||||
- **Not learning from past work** - Ignoring previous story learnings and patterns
|
||||
|
||||
### **🚨 EXHAUSTIVE ANALYSIS REQUIRED:**
|
||||
|
||||
You must thoroughly analyze **ALL artifacts** to extract critical context - do NOT be lazy or skim! This is the most important quality control function in the entire development process!
|
||||
|
||||
### **🔬 UTILIZE SUBPROCESSES AND SUBAGENTS:**
|
||||
|
||||
Use research subagents, subprocesses, or parallel processing if available to thoroughly analyze different artifacts **simultaneously and thoroughly**. Leave no stone unturned!
|
||||
|
||||
### **🎯 COMPETITIVE EXCELLENCE:**
|
||||
|
||||
This is a COMPETITION to create the **ULTIMATE story context** that makes LLM developer mistakes **IMPOSSIBLE**!
|
||||
|
||||
## **🚀 HOW TO USE THIS CHECKLIST**
|
||||
|
||||
### **When Running from Create-Story Workflow:**
|
||||
|
||||
- The `{project-root}/_bmad/core/tasks/workflow.xml` framework will automatically:
|
||||
- Load this checklist file
|
||||
- Load the newly created story file (`{story_file_path}`)
|
||||
- Load workflow variables from `{installed_path}/workflow.yaml`
|
||||
- Execute the validation process
|
||||
|
||||
### **When Running in Fresh Context:**
|
||||
|
||||
- User should provide the story file path being reviewed
|
||||
- Load the story file directly
|
||||
- Load the corresponding workflow.yaml for variable context
|
||||
- Proceed with systematic analysis
|
||||
|
||||
### **Required Inputs:**
|
||||
|
||||
- **Story file**: The story file to review and improve
|
||||
- **Workflow variables**: From workflow.yaml (implementation_artifacts, epics_file, etc.)
|
||||
- **Source documents**: Epics, architecture, etc. (discovered or provided)
|
||||
- **Validation framework**: `validate-workflow.xml` (handles checklist execution)
|
||||
|
||||
---
|
||||
|
||||
## **🔬 SYSTEMATIC RE-ANALYSIS APPROACH**
|
||||
|
||||
You will systematically re-do the entire story creation process, but with a critical eye for what the original LLM might have missed:
|
||||
|
||||
### **Step 1: Load and Understand the Target**
|
||||
|
||||
1. **Load the workflow configuration**: `{installed_path}/workflow.yaml` for variable inclusion
|
||||
2. **Load the story file**: `{story_file_path}` (provided by user or discovered)
|
||||
3. **Load validation framework**: `{project-root}/_bmad/core/tasks/workflow.xml`
|
||||
4. **Extract metadata**: epic_num, story_num, story_key, story_title from story file
|
||||
5. **Resolve all workflow variables**: implementation_artifacts, epics_file, architecture_file, etc.
|
||||
6. **Understand current status**: What story implementation guidance is currently provided?
|
||||
|
||||
**Note:** If running in fresh context, user should provide the story file path being reviewed. If running from create-story workflow, the validation framework will automatically discover the checklist and story file.
|
||||
|
||||
### **Step 2: Exhaustive Source Document Analysis**
|
||||
|
||||
**🔥 CRITICAL: Treat this like YOU are creating the story from scratch to PREVENT DISASTERS!**
|
||||
**Discover everything the original LLM missed that could cause developer mistakes, omissions, or disasters!**
|
||||
|
||||
#### **2.1 Epics and Stories Analysis**
|
||||
|
||||
- Load `{epics_file}` (or sharded equivalents)
|
||||
- Extract **COMPLETE Epic {{epic_num}} context**:
|
||||
- Epic objectives and business value
|
||||
- ALL stories in this epic (for cross-story context)
|
||||
- Our specific story's requirements, acceptance criteria
|
||||
- Technical requirements and constraints
|
||||
- Cross-story dependencies and prerequisites
|
||||
|
||||
#### **2.2 Architecture Deep-Dive**
|
||||
|
||||
- Load `{architecture_file}` (single or sharded)
|
||||
- **Systematically scan for ANYTHING relevant to this story:**
|
||||
- Technical stack with versions (languages, frameworks, libraries)
|
||||
- Code structure and organization patterns
|
||||
- API design patterns and contracts
|
||||
- Database schemas and relationships
|
||||
- Security requirements and patterns
|
||||
- Performance requirements and optimization strategies
|
||||
- Testing standards and frameworks
|
||||
- Deployment and environment patterns
|
||||
- Integration patterns and external services
|
||||
|
||||
#### **2.3 Previous Story Intelligence (if applicable)**
|
||||
|
||||
- If `story_num > 1`, load the previous story file
|
||||
- Extract **actionable intelligence**:
|
||||
- Dev notes and learnings
|
||||
- Review feedback and corrections needed
|
||||
- Files created/modified and their patterns
|
||||
- Testing approaches that worked/didn't work
|
||||
- Problems encountered and solutions found
|
||||
- Code patterns and conventions established
|
||||
|
||||
#### **2.4 Git History Analysis (if available)**
|
||||
|
||||
- Analyze recent commits for patterns:
|
||||
- Files created/modified in previous work
|
||||
- Code patterns and conventions used
|
||||
- Library dependencies added/changed
|
||||
- Architecture decisions implemented
|
||||
- Testing approaches used
|
||||
|
||||
#### **2.5 Latest Technical Research**
|
||||
|
||||
- Identify any libraries/frameworks mentioned
|
||||
- Research latest versions and critical information:
|
||||
- Breaking changes or security updates
|
||||
- Performance improvements or deprecations
|
||||
- Best practices for current versions
|
||||
|
||||
### **Step 3: Disaster Prevention Gap Analysis**
|
||||
|
||||
**🚨 CRITICAL: Identify every mistake the original LLM missed that could cause DISASTERS!**
|
||||
|
||||
#### **3.1 Reinvention Prevention Gaps**
|
||||
|
||||
- **Wheel reinvention:** Areas where developer might create duplicate functionality
|
||||
- **Code reuse opportunities** not identified that could prevent redundant work
|
||||
- **Existing solutions** not mentioned that developer should extend instead of replace
|
||||
|
||||
#### **3.2 Technical Specification DISASTERS**
|
||||
|
||||
- **Wrong libraries/frameworks:** Missing version requirements that could cause compatibility issues
|
||||
- **API contract violations:** Missing endpoint specifications that could break integrations
|
||||
- **Database schema conflicts:** Missing requirements that could corrupt data
|
||||
- **Security vulnerabilities:** Missing security requirements that could expose the system
|
||||
- **Performance disasters:** Missing requirements that could cause system failures
|
||||
|
||||
#### **3.3 File Structure DISASTERS**
|
||||
|
||||
- **Wrong file locations:** Missing organization requirements that could break build processes
|
||||
- **Coding standard violations:** Missing conventions that could create inconsistent codebase
|
||||
- **Integration pattern breaks:** Missing data flow requirements that could cause system failures
|
||||
- **Deployment failures:** Missing environment requirements that could prevent deployment
|
||||
|
||||
#### **3.4 Regression DISASTERS**
|
||||
|
||||
- **Breaking changes:** Missing requirements that could break existing functionality
|
||||
- **Test failures:** Missing test requirements that could allow bugs to reach production
|
||||
- **UX violations:** Missing user experience requirements that could ruin the product
|
||||
- **Learning failures:** Missing previous story context that could repeat same mistakes
|
||||
|
||||
#### **3.5 Implementation DISASTERS**
|
||||
|
||||
- **Vague implementations:** Missing details that could lead to incorrect or incomplete work
|
||||
- **Completion lies:** Missing acceptance criteria that could allow fake implementations
|
||||
- **Scope creep:** Missing boundaries that could cause unnecessary work
|
||||
- **Quality failures:** Missing quality requirements that could deliver broken features
|
||||
|
||||
### **Step 4: LLM-Dev-Agent Optimization Analysis**
|
||||
|
||||
**CRITICAL STEP: Optimize story context for LLM developer agent consumption**
|
||||
|
||||
**Analyze current story for LLM optimization issues:**
|
||||
|
||||
- **Verbosity problems:** Excessive detail that wastes tokens without adding value
|
||||
- **Ambiguity issues:** Vague instructions that could lead to multiple interpretations
|
||||
- **Context overload:** Too much information not directly relevant to implementation
|
||||
- **Missing critical signals:** Key requirements buried in verbose text
|
||||
- **Poor structure:** Information not organized for efficient LLM processing
|
||||
|
||||
**Apply LLM Optimization Principles:**
|
||||
|
||||
- **Clarity over verbosity:** Be precise and direct, eliminate fluff
|
||||
- **Actionable instructions:** Every sentence should guide implementation
|
||||
- **Scannable structure:** Use clear headings, bullet points, and emphasis
|
||||
- **Token efficiency:** Pack maximum information into minimum text
|
||||
- **Unambiguous language:** Clear requirements with no room for interpretation
|
||||
|
||||
### **Step 5: Improvement Recommendations**
|
||||
|
||||
**For each gap identified, provide specific, actionable improvements:**
|
||||
|
||||
#### **5.1 Critical Misses (Must Fix)**
|
||||
|
||||
- Missing essential technical requirements
|
||||
- Missing previous story context that could cause errors
|
||||
- Missing anti-pattern prevention that could lead to duplicate code
|
||||
- Missing security or performance requirements
|
||||
|
||||
#### **5.2 Enhancement Opportunities (Should Add)**
|
||||
|
||||
- Additional architectural guidance that would help developer
|
||||
- More detailed technical specifications
|
||||
- Better code reuse opportunities
|
||||
- Enhanced testing guidance
|
||||
|
||||
#### **5.3 Optimization Suggestions (Nice to Have)**
|
||||
|
||||
- Performance optimization hints
|
||||
- Additional context for complex scenarios
|
||||
- Enhanced debugging or development tips
|
||||
|
||||
#### **5.4 LLM Optimization Improvements**
|
||||
|
||||
- Token-efficient phrasing of existing content
|
||||
- Clearer structure for LLM processing
|
||||
- More actionable and direct instructions
|
||||
- Reduced verbosity while maintaining completeness
|
||||
|
||||
---
|
||||
|
||||
## **🎯 COMPETITION SUCCESS METRICS**
|
||||
|
||||
**You WIN against the original LLM if you identify:**
|
||||
|
||||
### **Category 1: Critical Misses (Blockers)**
|
||||
|
||||
- Essential technical requirements the developer needs but aren't provided
|
||||
- Previous story learnings that would prevent errors if ignored
|
||||
- Anti-pattern prevention that would prevent code duplication
|
||||
- Security or performance requirements that must be followed
|
||||
|
||||
### **Category 2: Enhancement Opportunities**
|
||||
|
||||
- Architecture guidance that would significantly help implementation
|
||||
- Technical specifications that would prevent wrong approaches
|
||||
- Code reuse opportunities the developer should know about
|
||||
- Testing guidance that would improve quality
|
||||
|
||||
### **Category 3: Optimization Insights**
|
||||
|
||||
- Performance or efficiency improvements
|
||||
- Development workflow optimizations
|
||||
- Additional context for complex scenarios
|
||||
|
||||
---
|
||||
|
||||
## **📋 INTERACTIVE IMPROVEMENT PROCESS**
|
||||
|
||||
After completing your systematic analysis, present your findings to the user interactively:
|
||||
|
||||
### **Step 5: Present Improvement Suggestions**
|
||||
|
||||
```
|
||||
🎯 **STORY CONTEXT QUALITY REVIEW COMPLETE**
|
||||
|
||||
**Story:** {{story_key}} - {{story_title}}
|
||||
|
||||
I found {{critical_count}} critical issues, {{enhancement_count}} enhancements, and {{optimization_count}} optimizations.
|
||||
|
||||
## **🚨 CRITICAL ISSUES (Must Fix)**
|
||||
|
||||
{{list each critical issue with clear, actionable description}}
|
||||
|
||||
## **⚡ ENHANCEMENT OPPORTUNITIES (Should Add)**
|
||||
|
||||
{{list each enhancement with clear benefit description}}
|
||||
|
||||
## **✨ OPTIMIZATIONS (Nice to Have)**
|
||||
|
||||
{{list each optimization with benefit description}}
|
||||
|
||||
## **🤖 LLM OPTIMIZATION (Token Efficiency & Clarity)**
|
||||
|
||||
{{list each LLM optimization that will improve dev agent performance:
|
||||
- Reduce verbosity while maintaining completeness
|
||||
- Improve structure for better LLM processing
|
||||
- Make instructions more actionable and direct
|
||||
- Enhance clarity and reduce ambiguity}}
|
||||
```
|
||||
|
||||
### **Step 6: Interactive User Selection**
|
||||
|
||||
After presenting the suggestions, ask the user:
|
||||
|
||||
```
|
||||
**IMPROVEMENT OPTIONS:**
|
||||
|
||||
Which improvements would you like me to apply to the story?
|
||||
|
||||
**Select from the numbered list above, or choose:**
|
||||
- **all** - Apply all suggested improvements
|
||||
- **critical** - Apply only critical issues
|
||||
- **select** - I'll choose specific numbers
|
||||
- **none** - Keep story as-is
|
||||
- **details** - Show me more details about any suggestion
|
||||
|
||||
Your choice:
|
||||
```
|
||||
|
||||
### **Step 7: Apply Selected Improvements**
|
||||
|
||||
When user accepts improvements:
|
||||
|
||||
- **Load the story file**
|
||||
- **Apply accepted changes** (make them look natural, as if they were always there)
|
||||
- **DO NOT reference** the review process, original LLM, or that changes were "added" or "enhanced"
|
||||
- **Ensure clean, coherent final story** that reads as if it was created perfectly the first time
|
||||
|
||||
### **Step 8: Confirmation**
|
||||
|
||||
After applying changes:
|
||||
|
||||
```
|
||||
✅ **STORY IMPROVEMENTS APPLIED**
|
||||
|
||||
Updated {{count}} sections in the story file.
|
||||
|
||||
The story now includes comprehensive developer guidance to prevent common implementation issues and ensure flawless execution.
|
||||
|
||||
**Next Steps:**
|
||||
1. Review the updated story
|
||||
2. Run `dev-story` for implementation
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## **💪 COMPETITIVE EXCELLENCE MINDSET**
|
||||
|
||||
**Your goal:** Improve the story file with dev agent needed context that makes flawless implementation inevitable while being optimized for LLM developer agent consumption. Remember the dev agent will ONLY have this file to use.
|
||||
|
||||
**Success Criteria:** The LLM developer agent that processes your improved story will have:
|
||||
|
||||
- ✅ Clear technical requirements they must follow
|
||||
- ✅ Previous work context they can build upon
|
||||
- ✅ Anti-pattern prevention to avoid common mistakes
|
||||
- ✅ Comprehensive guidance for efficient implementation
|
||||
- ✅ **Optimized content structure** for maximum clarity and minimum token waste
|
||||
- ✅ **Actionable instructions** with no ambiguity or verbosity
|
||||
- ✅ **Efficient information density** - maximum guidance in minimum text
|
||||
|
||||
**Every improvement should make it IMPOSSIBLE for the developer to:**
|
||||
|
||||
- Reinvent existing solutions
|
||||
- Use wrong approaches or libraries
|
||||
- Create duplicate functionality
|
||||
- Miss critical requirements
|
||||
- Make implementation errors
|
||||
|
||||
**LLM Optimization Should Make it IMPOSSIBLE for the developer agent to:**
|
||||
|
||||
- Misinterpret requirements due to ambiguity
|
||||
- Waste tokens on verbose, non-actionable content
|
||||
- Struggle to find critical information buried in text
|
||||
- Get confused by poor structure or organization
|
||||
- Miss key implementation signals due to inefficient communication
|
||||
|
||||
**Go create the ultimate developer implementation guide! 🚀**
|
||||
|
|
@ -0,0 +1,80 @@
|
|||
---
|
||||
title: 'Enhanced Dev Story Definition of Done Checklist'
|
||||
validation-target: 'Story markdown ({{story_path}})'
|
||||
validation-criticality: 'HIGHEST'
|
||||
required-inputs:
|
||||
- 'Story markdown file with enhanced Dev Notes containing comprehensive implementation context'
|
||||
- 'Completed Tasks/Subtasks section with all items marked [x]'
|
||||
- 'Updated File List section with all changed files'
|
||||
- 'Updated Dev Agent Record with implementation notes'
|
||||
optional-inputs:
|
||||
- 'Test results output'
|
||||
- 'CI logs'
|
||||
- 'Linting reports'
|
||||
validation-rules:
|
||||
- 'Only permitted story sections modified: Tasks/Subtasks checkboxes, Dev Agent Record, File List, Change Log, Status'
|
||||
- 'All implementation requirements from story Dev Notes must be satisfied'
|
||||
- 'Definition of Done checklist must pass completely'
|
||||
- 'Enhanced story context must contain sufficient technical guidance'
|
||||
---
|
||||
|
||||
# 🎯 Enhanced Definition of Done Checklist
|
||||
|
||||
**Critical validation:** Story is truly ready for review only when ALL items below are satisfied
|
||||
|
||||
## 📋 Context & Requirements Validation
|
||||
|
||||
- [ ] **Story Context Completeness:** Dev Notes contains ALL necessary technical requirements, architecture patterns, and implementation guidance
|
||||
- [ ] **Architecture Compliance:** Implementation follows all architectural requirements specified in Dev Notes
|
||||
- [ ] **Technical Specifications:** All technical specifications (libraries, frameworks, versions) from Dev Notes are implemented correctly
|
||||
- [ ] **Previous Story Learnings:** Previous story insights incorporated (if applicable) and build upon appropriately
|
||||
|
||||
## ✅ Implementation Completion
|
||||
|
||||
- [ ] **All Tasks Complete:** Every task and subtask marked complete with [x]
|
||||
- [ ] **Acceptance Criteria Satisfaction:** Implementation satisfies EVERY Acceptance Criterion in the story
|
||||
- [ ] **No Ambiguous Implementation:** Clear, unambiguous implementation that meets story requirements
|
||||
- [ ] **Edge Cases Handled:** Error conditions and edge cases appropriately addressed
|
||||
- [ ] **Dependencies Within Scope:** Only uses dependencies specified in story or project-context.md
|
||||
|
||||
## 🧪 Testing & Quality Assurance
|
||||
|
||||
- [ ] **Unit Tests:** Unit tests added/updated for ALL core functionality introduced/changed by this story
|
||||
- [ ] **Integration Tests:** Integration tests added/updated for component interactions when story requirements demand them
|
||||
- [ ] **End-to-End Tests:** End-to-end tests created for critical user flows when story requirements specify them
|
||||
- [ ] **Test Coverage:** Tests cover acceptance criteria and edge cases from story Dev Notes
|
||||
- [ ] **Regression Prevention:** ALL existing tests pass (no regressions introduced)
|
||||
- [ ] **Code Quality:** Linting and static checks pass when configured in project
|
||||
- [ ] **Test Framework Compliance:** Tests use project's testing frameworks and patterns from Dev Notes
|
||||
|
||||
## 📝 Documentation & Tracking
|
||||
|
||||
- [ ] **File List Complete:** File List includes EVERY new, modified, or deleted file (paths relative to repo root)
|
||||
- [ ] **Dev Agent Record Updated:** Contains relevant Implementation Notes and/or Debug Log for this work
|
||||
- [ ] **Change Log Updated:** Change Log includes clear summary of what changed and why
|
||||
- [ ] **Review Follow-ups:** All review follow-up tasks (marked [AI-Review]) completed and corresponding review items marked resolved (if applicable)
|
||||
- [ ] **Story Structure Compliance:** Only permitted sections of story file were modified
|
||||
|
||||
## 🔚 Final Status Verification
|
||||
|
||||
- [ ] **Story Status Updated:** Story Status set to "review"
|
||||
- [ ] **Sprint Status Updated:** Sprint status updated to "review" (when sprint tracking is used)
|
||||
- [ ] **Quality Gates Passed:** All quality checks and validations completed successfully
|
||||
- [ ] **No HALT Conditions:** No blocking issues or incomplete work remaining
|
||||
- [ ] **User Communication Ready:** Implementation summary prepared for user review
|
||||
|
||||
## 🎯 Final Validation Output
|
||||
|
||||
```
|
||||
Definition of Done: {{PASS/FAIL}}
|
||||
|
||||
✅ **Story Ready for Review:** {{story_key}}
|
||||
📊 **Completion Score:** {{completed_items}}/{{total_items}} items passed
|
||||
🔍 **Quality Gates:** {{quality_gates_status}}
|
||||
📋 **Test Results:** {{test_results_summary}}
|
||||
📝 **Documentation:** {{documentation_status}}
|
||||
```
|
||||
|
||||
**If FAIL:** List specific failures and required actions before story can be marked Ready for Review
|
||||
|
||||
**If PASS:** Story is fully ready for code review and production consideration
|
||||
|
|
@ -0,0 +1,33 @@
|
|||
# Sprint Planning Validation Checklist
|
||||
|
||||
## Core Validation
|
||||
|
||||
### Complete Coverage Check
|
||||
|
||||
- [ ] Every epic found in epic\*.md files appears in sprint-status.yaml
|
||||
- [ ] Every story found in epic\*.md files appears in sprint-status.yaml
|
||||
- [ ] Every epic has a corresponding retrospective entry
|
||||
- [ ] No items in sprint-status.yaml that don't exist in epic files
|
||||
|
||||
### Parsing Verification
|
||||
|
||||
Compare epic files against generated sprint-status.yaml:
|
||||
|
||||
```
|
||||
Epic Files Contains: Sprint Status Contains:
|
||||
✓ Epic 1 ✓ epic-1: [status]
|
||||
✓ Story 1.1: User Auth ✓ 1-1-user-auth: [status]
|
||||
✓ Story 1.2: Account Mgmt ✓ 1-2-account-mgmt: [status]
|
||||
✓ Story 1.3: Plant Naming ✓ 1-3-plant-naming: [status]
|
||||
✓ epic-1-retrospective: [status]
|
||||
✓ Epic 2 ✓ epic-2: [status]
|
||||
✓ Story 2.1: Personality Model ✓ 2-1-personality-model: [status]
|
||||
✓ Story 2.2: Chat Interface ✓ 2-2-chat-interface: [status]
|
||||
✓ epic-2-retrospective: [status]
|
||||
```
|
||||
|
||||
### Final Check
|
||||
|
||||
- [ ] Total count of epics matches
|
||||
- [ ] Total count of stories matches
|
||||
- [ ] All items are in the expected order (epic, stories, retrospective)
|
||||
|
|
@ -1,8 +1,41 @@
|
|||
code: atlassian
|
||||
name: "Atlassian Jira/Confluence Adapter"
|
||||
description: "Routes BMAD artefacts to Jira and Confluence via the Atlassian MCP server"
|
||||
default_selected: false
|
||||
depends_on: bmm
|
||||
name: "BMAD-Jira: Atlassian-Native Agentic Development"
|
||||
description: "Jira/Confluence-native implementation of the BMAD agentic development method via Atlassian MCP server"
|
||||
default_selected: true
|
||||
|
||||
# --- Project Configuration ---
|
||||
|
||||
project_name:
|
||||
prompt: "What is your project called?"
|
||||
default: "{directory_name}"
|
||||
result: "{value}"
|
||||
|
||||
user_name:
|
||||
prompt: "What is your name?"
|
||||
default: "Developer"
|
||||
result: "{value}"
|
||||
|
||||
communication_language:
|
||||
prompt: "What language should agents communicate in?"
|
||||
default: "English"
|
||||
result: "{value}"
|
||||
|
||||
document_output_language:
|
||||
prompt: "What language should documents be written in?"
|
||||
default: "English"
|
||||
result: "{value}"
|
||||
|
||||
user_skill_level:
|
||||
prompt: "What is your development experience level?"
|
||||
default: "intermediate"
|
||||
result: "{value}"
|
||||
single-select:
|
||||
- value: "beginner"
|
||||
label: "Beginner - Explain things clearly"
|
||||
- value: "intermediate"
|
||||
label: "Intermediate - Balance detail with speed"
|
||||
- value: "expert"
|
||||
label: "Expert - Be direct and technical"
|
||||
|
||||
# --- Jira Configuration ---
|
||||
|
||||
|
|
@ -32,23 +65,8 @@ confluence_parent_page_id:
|
|||
default: ""
|
||||
result: "{value}"
|
||||
|
||||
# --- Output Mode ---
|
||||
|
||||
output_mode:
|
||||
prompt:
|
||||
- "How should artefacts be written?"
|
||||
- "Dual mode writes to both Jira/Confluence AND local files. Jira-only skips local files."
|
||||
default: "dual"
|
||||
result: "{value}"
|
||||
single-select:
|
||||
- value: "dual"
|
||||
label: "Dual - Write to Jira/Confluence and local files"
|
||||
- value: "jira-only"
|
||||
label: "Jira Only - Write exclusively to Jira/Confluence"
|
||||
|
||||
# --- Status Transition Mapping ---
|
||||
# Maps BMAD abstract statuses to Jira transition IDs.
|
||||
# Users must populate these for their specific Jira workflow.
|
||||
# Run transition-discovery.md to auto-discover these values.
|
||||
|
||||
status_transitions:
|
||||
|
|
@ -76,8 +94,7 @@ lock_label:
|
|||
default: "agent-active"
|
||||
result: "{value}"
|
||||
|
||||
# --- Tracking System Override ---
|
||||
# These override the bmm module defaults to route through Jira
|
||||
# --- Tracking System ---
|
||||
|
||||
tracking_system:
|
||||
result: "jira"
|
||||
|
|
@ -89,7 +106,6 @@ story_location:
|
|||
result: "jira://{jira_project_key}"
|
||||
|
||||
# --- Key Map ---
|
||||
# Local file mapping BMAD identifiers to Jira issue keys and Confluence page IDs
|
||||
|
||||
key_map_file:
|
||||
result: "{project-root}/_bmad/atlassian/.jira-key-map.yaml"
|
||||
|
|
|
|||
|
|
@ -14,6 +14,19 @@ Rules are evaluated in order. The first matching rule fires. If no rule matches,
|
|||
|
||||
<rules>
|
||||
|
||||
<rule n="0" name="Handoff Signal Detected">
|
||||
<condition>project_state.pending_handoffs is not empty</condition>
|
||||
<action>Dispatch the agent indicated by the handoff label</action>
|
||||
<procedure>
|
||||
1. Take the first pending handoff from the list
|
||||
2. Read the handoff comment on the issue for context (look for "## Agent Handoff:" comments)
|
||||
3. Dispatch the target agent with the recommended workflow from the handoff comment
|
||||
4. After dispatching, remove the `bmad-handoff-{agent}` label from the issue via Update Issue
|
||||
</procedure>
|
||||
<message>Handoff detected: {target_agent} should work on {issue_key}. Dispatching.</message>
|
||||
<notes>Handoff labels take absolute priority over state-based rules below. This ensures agents respond to explicit signals from the previous agent rather than re-inferring state.</notes>
|
||||
</rule>
|
||||
|
||||
<rule n="1" name="Blocked — Agent Active">
|
||||
<condition>project_state.locked_issues is not empty (after stale lock clearing)</condition>
|
||||
<action>WAIT — another agent is currently working</action>
|
||||
|
|
|
|||
|
|
@ -24,9 +24,11 @@ project_state:
|
|||
# Planning artefacts (from Confluence)
|
||||
artefacts:
|
||||
product_brief: { exists: bool, page_id: str }
|
||||
research: { exists: bool, page_ids: [str] }
|
||||
prd: { exists: bool, page_id: str }
|
||||
ux_design: { exists: bool, page_id: str }
|
||||
architecture: { exists: bool, page_id: str }
|
||||
readiness_report: { exists: bool, page_id: str }
|
||||
|
||||
# Jira state
|
||||
epics:
|
||||
|
|
@ -42,6 +44,9 @@ project_state:
|
|||
locked_issues: [{ key: str, summary: str, locked_since: str }]
|
||||
stale_locks: [{ key: str, summary: str, locked_since: str }]
|
||||
|
||||
# Handoff signals
|
||||
pending_handoffs: [{ issue_key: str, target_agent: str, label: str }]
|
||||
|
||||
# Sprint
|
||||
active_sprint: { exists: bool, name: str, sprint_id: str, story_count: int }
|
||||
```
|
||||
|
|
@ -59,10 +64,12 @@ project_state:
|
|||
<action>For any missing entries, search Confluence:</action>
|
||||
|
||||
```
|
||||
Search Content: query = "space = {confluence_space_key} AND label = bmad-brief" → product_brief
|
||||
Search Content: query = "space = {confluence_space_key} AND label = bmad-prd" → prd
|
||||
Search Content: query = "space = {confluence_space_key} AND label = bmad-ux" → ux_design
|
||||
Search Content: query = "space = {confluence_space_key} AND label = bmad-architecture" → architecture
|
||||
Search Content: query = "space = {confluence_space_key} AND label = bmad-brief" → product_brief
|
||||
Search Content: query = "space = {confluence_space_key} AND label = bmad-research" → research (may return multiple)
|
||||
Search Content: query = "space = {confluence_space_key} AND label = bmad-prd" → prd
|
||||
Search Content: query = "space = {confluence_space_key} AND label = bmad-ux" → ux_design
|
||||
Search Content: query = "space = {confluence_space_key} AND label = bmad-architecture" → architecture
|
||||
Search Content: query = "space = {confluence_space_key} AND label = bmad-readiness" → readiness_report
|
||||
```
|
||||
|
||||
<action>Record existence and page IDs for each</action>
|
||||
|
|
@ -116,13 +123,27 @@ project = {jira_project_key} AND labels = "{lock_label}"
|
|||
<action>Record locked issues and flag stale locks</action>
|
||||
</step>
|
||||
|
||||
<step n="5" goal="Check active sprint">
|
||||
<step n="5" goal="Scan for handoff labels">
|
||||
<action>Call `Search Issues` with JQL:</action>
|
||||
|
||||
```
|
||||
project = {jira_project_key} AND labels in ("bmad-handoff-analyst", "bmad-handoff-pm", "bmad-handoff-ux-designer", "bmad-handoff-architect", "bmad-handoff-sm", "bmad-handoff-dev", "bmad-handoff-qa")
|
||||
```
|
||||
|
||||
`fields: "summary,labels"`
|
||||
|
||||
<action>For each issue with a handoff label, extract the target agent name from the label (e.g., `bmad-handoff-sm` → SM)</action>
|
||||
<action>Record in `pending_handoffs` array with issue_key, target_agent, and label</action>
|
||||
<action>Handoff labels take priority over state-based dispatch in the agent dispatch rules</action>
|
||||
</step>
|
||||
|
||||
<step n="6" goal="Check active sprint">
|
||||
<action>If `{jira_board_id}` is configured:</action>
|
||||
<action>Call `Get Sprints from Board` with `board_id: "{jira_board_id}"` and `state: "active"`</action>
|
||||
<action>If active sprint found, call `Get Sprint Issues` with `sprint_id` and count stories</action>
|
||||
</step>
|
||||
|
||||
<step n="6" goal="Clear stale locks (if any)">
|
||||
<step n="7" goal="Clear stale locks (if any)">
|
||||
<action>For each stale lock found in step 4:</action>
|
||||
<action>Call `Get Issue` with `issue_key` and `fields: "labels"` to get current labels</action>
|
||||
<action>Build new labels array without `{lock_label}`</action>
|
||||
|
|
@ -130,7 +151,7 @@ project = {jira_project_key} AND labels = "{lock_label}"
|
|||
<action>Call `Add Comment`: "🔓 Stale lock cleared by orchestrator (locked for >1 hour with no activity)"</action>
|
||||
</step>
|
||||
|
||||
<step n="7" goal="Sync key map">
|
||||
<step n="8" goal="Sync key map">
|
||||
<action>Update `{key_map_file}` with any newly discovered Jira keys or Confluence page IDs that weren't previously recorded</action>
|
||||
<action>Update `last_updated` timestamp</action>
|
||||
</step>
|
||||
|
|
|
|||
|
|
@ -0,0 +1,116 @@
|
|||
# Post Handoff — Cross-Agent Communication
|
||||
|
||||
<critical>This is a reusable task. It is invoked by workflows at completion to notify the next agent.</critical>
|
||||
|
||||
## Purpose
|
||||
|
||||
Posts a structured handoff notification on relevant Jira issues when an agent completes its workflow and work is ready for the next agent. This enables traceability and automated orchestrator dispatch.
|
||||
|
||||
---
|
||||
|
||||
## Required Inputs
|
||||
|
||||
| Input | Description |
|
||||
|---|---|
|
||||
| `handoff_to` | The target agent name (e.g., "PM", "Architect", "SM", "Dev", "QA") |
|
||||
| `handoff_type` | The type of handoff (e.g., "product_brief_complete", "prd_complete", "architecture_complete", "sprint_planned", "story_prepared", "dev_complete", "review_complete") |
|
||||
| `summary` | Brief description of what was completed and what the next agent should do |
|
||||
| `jira_issue_keys` | (Optional) Specific Jira issue keys to post the handoff comment on. If not provided, posts on the most relevant Epic. |
|
||||
| `confluence_page` | (Optional) Confluence page ID of the artefact produced |
|
||||
|
||||
---
|
||||
|
||||
## Procedure
|
||||
|
||||
### Step 1 — Determine target issues
|
||||
|
||||
If `jira_issue_keys` are provided, use those directly.
|
||||
|
||||
If not, determine the most relevant issues based on `handoff_type`:
|
||||
|
||||
- **product_brief_complete / research_complete**: Find the first Epic via JQL: `project = {jira_project_key} AND issuetype = Epic ORDER BY rank ASC LIMIT 1`. If no Epics exist yet, skip Jira comment (Confluence page is the primary artefact).
|
||||
- **prd_complete / ux_design_complete / architecture_complete / readiness_complete**: Post on all Epics: `project = {jira_project_key} AND issuetype = Epic ORDER BY rank ASC`
|
||||
- **sprint_planned**: Post on each Epic that has stories in the sprint.
|
||||
- **story_prepared**: Post on the specific story issue.
|
||||
- **dev_complete / review_complete**: Post on the specific story issue.
|
||||
- **retrospective_complete**: Post on the Epic being retrospected.
|
||||
- **correct_course_complete**: Post on all affected issues.
|
||||
|
||||
### Step 2 — Post handoff comment
|
||||
|
||||
For each target Jira issue, call `Add Comment` with:
|
||||
|
||||
```
|
||||
issue_key: "{target_issue_key}"
|
||||
body: |
|
||||
## Agent Handoff: {current_agent} → {handoff_to}
|
||||
|
||||
**Completed:** {handoff_type}
|
||||
**Summary:** {summary}
|
||||
**Artefact:** {confluence_page_url or "See Jira issue updates"}
|
||||
**Next Action:** {recommended_next_workflow}
|
||||
|
||||
---
|
||||
_Posted by BMAD Agent System_
|
||||
```
|
||||
|
||||
### Step 3 — Apply handoff label
|
||||
|
||||
For each target Jira issue, add a handoff label to signal the orchestrator:
|
||||
|
||||
Call `Get Issue` for the target issue to read current labels.
|
||||
|
||||
Call `Update Issue` with:
|
||||
|
||||
```
|
||||
issue_key: "{target_issue_key}"
|
||||
additional_fields:
|
||||
labels: [{existing_labels}, "bmad-handoff-{handoff_to_lowercase}"]
|
||||
```
|
||||
|
||||
Where `{handoff_to_lowercase}` is the target agent name in lowercase (e.g., "bmad-handoff-sm", "bmad-handoff-dev").
|
||||
|
||||
### Step 4 — Update key map (if applicable)
|
||||
|
||||
If a `confluence_page` ID was provided, ensure it is recorded in `{key_map_file}` under the appropriate `confluence_pages` entry.
|
||||
|
||||
### Step 5 — Log completion
|
||||
|
||||
Report the handoff:
|
||||
|
||||
```
|
||||
Handoff posted: {current_agent} → {handoff_to}
|
||||
Issues notified: {issue_key_list}
|
||||
Label applied: bmad-handoff-{handoff_to_lowercase}
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Handoff Type Reference
|
||||
|
||||
| Handoff Type | From Agent | To Agent | Next Workflow |
|
||||
|---|---|---|---|
|
||||
| `product_brief_complete` | Analyst | PM | Create PRD |
|
||||
| `research_complete` | Analyst | PM | Create PRD |
|
||||
| `prd_complete` | PM | UX Designer | Create UX Design |
|
||||
| `ux_design_complete` | UX Designer | Architect | Create Architecture |
|
||||
| `architecture_complete` | Architect | SM | Create Epics and Stories |
|
||||
| `readiness_complete` | SM | SM | Sprint Planning |
|
||||
| `sprint_planned` | SM | SM | Create Story |
|
||||
| `story_prepared` | SM | Dev | Dev Story |
|
||||
| `dev_complete` | Dev | QA | Code Review |
|
||||
| `review_complete` | QA | SM | Next Story or Retrospective |
|
||||
| `retrospective_complete` | SM | SM | Next Epic or Complete |
|
||||
| `correct_course_complete` | SM | Dev/SM | Resume work |
|
||||
|
||||
---
|
||||
|
||||
## Orchestrator Integration
|
||||
|
||||
The orchestrator's `jira-state-reader` scans for `bmad-handoff-*` labels during its polling cycle. When detected:
|
||||
|
||||
1. The label indicates which agent should be dispatched next
|
||||
2. The orchestrator reads the handoff comment for context
|
||||
3. After dispatching the agent, the `bmad-handoff-*` label is removed
|
||||
|
||||
This creates a reliable, label-based signalling mechanism that survives across sessions and is visible in the Jira UI.
|
||||
|
|
@ -77,8 +77,6 @@ summary: "BMAD artefact published to Confluence"
|
|||
<action>Update `{key_map_file}` under `confluence_pages.{key_map_id}` with the `page_id`</action>
|
||||
<action>Update `last_updated` timestamp</action>
|
||||
|
||||
**If output_mode is "dual":**
|
||||
<action>Also write the content to the local file path as specified by the calling workflow</action>
|
||||
</step>
|
||||
|
||||
</workflow>
|
||||
|
|
|
|||
|
|
@ -0,0 +1,12 @@
|
|||
---
|
||||
stepsCompleted: []
|
||||
inputDocuments: []
|
||||
workflowType: 'architecture'
|
||||
project_name: '{{project_name}}'
|
||||
user_name: '{{user_name}}'
|
||||
date: '{{date}}'
|
||||
---
|
||||
|
||||
# Architecture Decision Document
|
||||
|
||||
_This document builds collaboratively through step-by-step discovery. Sections are appended as we work through each architectural decision together._
|
||||
|
|
@ -0,0 +1,57 @@
|
|||
---
|
||||
stepsCompleted: []
|
||||
inputDocuments: []
|
||||
---
|
||||
|
||||
# {{project_name}} - Epic Breakdown
|
||||
|
||||
## Overview
|
||||
|
||||
This document provides the complete epic and story breakdown for {{project_name}}, decomposing the requirements from the PRD, UX Design if it exists, and Architecture requirements into implementable stories.
|
||||
|
||||
## Requirements Inventory
|
||||
|
||||
### Functional Requirements
|
||||
|
||||
{{fr_list}}
|
||||
|
||||
### NonFunctional Requirements
|
||||
|
||||
{{nfr_list}}
|
||||
|
||||
### Additional Requirements
|
||||
|
||||
{{additional_requirements}}
|
||||
|
||||
### FR Coverage Map
|
||||
|
||||
{{requirements_coverage_map}}
|
||||
|
||||
## Epic List
|
||||
|
||||
{{epics_list}}
|
||||
|
||||
<!-- Repeat for each epic in epics_list (N = 1, 2, 3...) -->
|
||||
|
||||
## Epic {{N}}: {{epic_title_N}}
|
||||
|
||||
{{epic_goal_N}}
|
||||
|
||||
<!-- Repeat for each story (M = 1, 2, 3...) within epic N -->
|
||||
|
||||
### Story {{N}}.{{M}}: {{story_title_N_M}}
|
||||
|
||||
As a {{user_type}},
|
||||
I want {{capability}},
|
||||
So that {{value_benefit}}.
|
||||
|
||||
**Acceptance Criteria:**
|
||||
|
||||
<!-- for each AC on this story -->
|
||||
|
||||
**Given** {{precondition}}
|
||||
**When** {{action}}
|
||||
**Then** {{expected_outcome}}
|
||||
**And** {{additional_criteria}}
|
||||
|
||||
<!-- End story repeat -->
|
||||
|
|
@ -0,0 +1,10 @@
|
|||
---
|
||||
stepsCompleted: []
|
||||
inputDocuments: []
|
||||
workflowType: 'prd'
|
||||
---
|
||||
|
||||
# Product Requirements Document - {{project_name}}
|
||||
|
||||
**Author:** {{user_name}}
|
||||
**Date:** {{date}}
|
||||
|
|
@ -0,0 +1,10 @@
|
|||
---
|
||||
stepsCompleted: []
|
||||
inputDocuments: []
|
||||
date: { system-date }
|
||||
author: { user }
|
||||
---
|
||||
|
||||
# Product Brief: {{project_name}}
|
||||
|
||||
<!-- Content will be appended sequentially through collaborative workflow steps -->
|
||||
|
|
@ -0,0 +1,4 @@
|
|||
# Implementation Readiness Assessment Report
|
||||
|
||||
**Date:** {{date}}
|
||||
**Project:** {{project_name}}
|
||||
|
|
@ -0,0 +1,29 @@
|
|||
---
|
||||
stepsCompleted: []
|
||||
inputDocuments: []
|
||||
workflowType: 'research'
|
||||
lastStep: 1
|
||||
research_type: '{{research_type}}'
|
||||
research_topic: '{{research_topic}}'
|
||||
research_goals: '{{research_goals}}'
|
||||
user_name: '{{user_name}}'
|
||||
date: '{{date}}'
|
||||
web_research_enabled: true
|
||||
source_verification: true
|
||||
---
|
||||
|
||||
# Research Report: {{research_type}}
|
||||
|
||||
**Date:** {{date}}
|
||||
**Author:** {{user_name}}
|
||||
**Research Type:** {{research_type}}
|
||||
|
||||
---
|
||||
|
||||
## Research Overview
|
||||
|
||||
[Research overview and methodology will be appended here]
|
||||
|
||||
---
|
||||
|
||||
<!-- Content will be appended sequentially through research workflow steps -->
|
||||
|
|
@ -0,0 +1,49 @@
|
|||
# Story {{epic_num}}.{{story_num}}: {{story_title}}
|
||||
|
||||
Status: ready-for-dev
|
||||
|
||||
<!-- Note: Validation is optional. Run validate-create-story for quality check before dev-story. -->
|
||||
|
||||
## Story
|
||||
|
||||
As a {{role}},
|
||||
I want {{action}},
|
||||
so that {{benefit}}.
|
||||
|
||||
## Acceptance Criteria
|
||||
|
||||
1. [Add acceptance criteria from epics/PRD]
|
||||
|
||||
## Tasks / Subtasks
|
||||
|
||||
- [ ] Task 1 (AC: #)
|
||||
- [ ] Subtask 1.1
|
||||
- [ ] Task 2 (AC: #)
|
||||
- [ ] Subtask 2.1
|
||||
|
||||
## Dev Notes
|
||||
|
||||
- Relevant architecture patterns and constraints
|
||||
- Source tree components to touch
|
||||
- Testing standards summary
|
||||
|
||||
### Project Structure Notes
|
||||
|
||||
- Alignment with unified project structure (paths, modules, naming)
|
||||
- Detected conflicts or variances (with rationale)
|
||||
|
||||
### References
|
||||
|
||||
- Cite all technical details with source paths and sections, e.g. [Source: docs/<file>.md#Section]
|
||||
|
||||
## Dev Agent Record
|
||||
|
||||
### Agent Model Used
|
||||
|
||||
{{agent_model_name_version}}
|
||||
|
||||
### Debug Log References
|
||||
|
||||
### Completion Notes List
|
||||
|
||||
### File List
|
||||
|
|
@ -0,0 +1,13 @@
|
|||
---
|
||||
stepsCompleted: []
|
||||
inputDocuments: []
|
||||
---
|
||||
|
||||
# UX Design Specification {{project_name}}
|
||||
|
||||
**Author:** {{user_name}}
|
||||
**Date:** {{date}}
|
||||
|
||||
---
|
||||
|
||||
<!-- UX design content will be appended sequentially through collaborative workflow steps -->
|
||||
|
|
@ -0,0 +1,107 @@
|
|||
# Create Product Brief — Confluence Output
|
||||
|
||||
<critical>The workflow execution engine is governed by: {project-root}/_bmad/core/tasks/workflow.xml</critical>
|
||||
<critical>You MUST have already loaded and processed: the workflow-jira.yaml for this workflow</critical>
|
||||
|
||||
## Overview
|
||||
|
||||
Creates a product brief through collaborative step-by-step discovery. Steps 1-5 are unchanged elicitation steps from the standard workflow. Step 6 (completion) writes the product brief to Confluence and posts a handoff to the PM agent.
|
||||
|
||||
---
|
||||
|
||||
<workflow>
|
||||
|
||||
<step n="1" goal="Initialize and load context from Jira/Confluence">
|
||||
<action>Communicate in {communication_language} with {user_name}</action>
|
||||
<action>Invoke the `read-jira-context` task with `context_type: "project_overview"` to check for any existing Confluence pages or Jira project metadata</action>
|
||||
<action>Load the product brief template from `{template}`</action>
|
||||
<action>Begin collaborative elicitation with the user as a creative Business Analyst peer</action>
|
||||
|
||||
<action>Ask the user to describe their product idea, vision, or problem space</action>
|
||||
<action>This is a partnership — you bring structured thinking and facilitation, the user brings domain expertise and product vision</action>
|
||||
</step>
|
||||
|
||||
<step n="2" goal="Vision and problem space elicitation">
|
||||
<action>Explore the product vision through collaborative dialogue:</action>
|
||||
|
||||
1. What problem does this product solve?
|
||||
2. Who experiences this problem most acutely?
|
||||
3. What is the envisioned solution at a high level?
|
||||
4. What makes this approach unique or compelling?
|
||||
|
||||
<action>Capture key insights and confirm understanding with the user before proceeding</action>
|
||||
</step>
|
||||
|
||||
<step n="3" goal="Target users and personas elicitation">
|
||||
<action>Identify and characterize the target user segments:</action>
|
||||
|
||||
1. Who are the primary users?
|
||||
2. What are their key characteristics, behaviours, and pain points?
|
||||
3. Are there secondary user segments?
|
||||
4. How do these users currently solve the problem?
|
||||
|
||||
<action>Summarise the user profiles and confirm with the user</action>
|
||||
</step>
|
||||
|
||||
<step n="4" goal="Success metrics and goals elicitation">
|
||||
<action>Define measurable success criteria:</action>
|
||||
|
||||
1. What does success look like for this product?
|
||||
2. What are the key metrics to track?
|
||||
3. What are the business goals and constraints?
|
||||
4. What is the minimum viable scope?
|
||||
|
||||
<action>Confirm the metrics framework with the user</action>
|
||||
</step>
|
||||
|
||||
<step n="5" goal="Scope and boundaries elicitation">
|
||||
<action>Establish clear boundaries for the product:</action>
|
||||
|
||||
1. What is explicitly in scope for the initial release?
|
||||
2. What is explicitly out of scope?
|
||||
3. Are there known technical constraints or dependencies?
|
||||
4. What are the key risks and assumptions?
|
||||
|
||||
<action>Present a concise scope summary and confirm alignment</action>
|
||||
</step>
|
||||
|
||||
<step n="6" goal="Write product brief to Confluence and hand off">
|
||||
<action>Compile the complete product brief from all elicitation steps using the template at `{template}`</action>
|
||||
<action>Generate the document in {document_output_language}</action>
|
||||
|
||||
<action>Invoke the `write-to-confluence` task with:</action>
|
||||
|
||||
```
|
||||
space_key: "{confluence_space_key}"
|
||||
parent_page_id: "{confluence_parent_page_id}"
|
||||
title: "{project_name} — Product Brief"
|
||||
content: "{compiled_product_brief_content}"
|
||||
key_map_entry: "confluence_pages.product_brief"
|
||||
```
|
||||
|
||||
<action>Update `{key_map_file}` with the new Confluence page ID under `confluence_pages.product_brief`</action>
|
||||
|
||||
<action>Invoke the `post-handoff` task with:</action>
|
||||
|
||||
```
|
||||
handoff_to: "PM"
|
||||
handoff_type: "product_brief_complete"
|
||||
summary: "Product brief created and published to Confluence. Ready for PRD creation."
|
||||
confluence_page: "{product_brief_page_id}"
|
||||
```
|
||||
|
||||
<action>Report to user:</action>
|
||||
|
||||
**Product Brief Complete**
|
||||
|
||||
- **Confluence Page:** {product_brief_page_url}
|
||||
- **Status:** Published
|
||||
- **Handoff:** PM agent notified for PRD creation
|
||||
|
||||
**Next Steps:**
|
||||
1. Review the product brief on Confluence
|
||||
2. PM agent can begin PRD creation with [Create PRD]
|
||||
3. Optionally run Research workflows for deeper analysis
|
||||
</step>
|
||||
|
||||
</workflow>
|
||||
|
|
@ -0,0 +1,30 @@
|
|||
name: create-product-brief-jira
|
||||
description: 'Create product brief with output to Confluence. Use when tracking_system is "jira".'
|
||||
author: "BMad"
|
||||
|
||||
# Critical variables from config
|
||||
config_source: "{project-root}/_bmad/atlassian/config.yaml"
|
||||
user_name: "{config_source}:user_name"
|
||||
communication_language: "{config_source}:communication_language"
|
||||
document_output_language: "{config_source}:document_output_language"
|
||||
user_skill_level: "{config_source}:user_skill_level"
|
||||
date: system-generated
|
||||
|
||||
# Atlassian-specific config
|
||||
jira_project_key: "{config_source}:jira_project_key"
|
||||
confluence_space_key: "{config_source}:confluence_space_key"
|
||||
confluence_parent_page_id: "{config_source}:confluence_parent_page_id"
|
||||
key_map_file: "{config_source}:key_map_file"
|
||||
|
||||
# Workflow components
|
||||
installed_path: "{project-root}/_bmad/atlassian/workflow-overrides/1-analysis/create-product-brief"
|
||||
instructions: "{installed_path}/instructions-jira.md"
|
||||
template: "{project-root}/_bmad/atlassian/templates/product-brief.template.md"
|
||||
|
||||
# Reusable tasks
|
||||
context_task: "{project-root}/_bmad/atlassian/tasks/read-jira-context.md"
|
||||
write_confluence_task: "{project-root}/_bmad/atlassian/tasks/write-to-confluence.md"
|
||||
handoff_task: "{project-root}/_bmad/atlassian/tasks/post-handoff.md"
|
||||
|
||||
# Tracking system
|
||||
tracking_system: "jira"
|
||||
|
|
@ -0,0 +1,95 @@
|
|||
# Research — Confluence Output
|
||||
|
||||
<critical>The workflow execution engine is governed by: {project-root}/_bmad/core/tasks/workflow.xml</critical>
|
||||
<critical>You MUST have already loaded and processed: the workflow-jira.yaml for this workflow</critical>
|
||||
|
||||
## Overview
|
||||
|
||||
Conducts research (market, domain, or technical) using web search and verified sources. The research type is determined by `{research_type}`. Output is written to Confluence as a research report page.
|
||||
|
||||
**Prerequisite:** Web search capability required. If unavailable, abort and inform the user.
|
||||
|
||||
---
|
||||
|
||||
<workflow>
|
||||
|
||||
<step n="1" goal="Initialize and discover research context">
|
||||
<action>Communicate in {communication_language} with {user_name}</action>
|
||||
<action>Invoke the `read-jira-context` task with `context_type: "project_overview"` to check for existing product brief or other context on Confluence</action>
|
||||
|
||||
<action>Greet the user and begin topic discovery:</action>
|
||||
|
||||
"Welcome {user_name}! Let's get started with your **{research_type} research**.
|
||||
|
||||
**What topic, problem, or area do you want to research?**"
|
||||
|
||||
<action>Clarify with the user:</action>
|
||||
1. **Core Topic**: What exactly about the topic are you most interested in?
|
||||
2. **Research Goals**: What do you hope to achieve with this research?
|
||||
3. **Scope**: Should we focus broadly or dive deep into specific aspects?
|
||||
|
||||
<action>Set `research_topic` and `research_goals` from the discussion</action>
|
||||
</step>
|
||||
|
||||
<step n="2" goal="Execute research steps">
|
||||
<action>Follow the standard {research_type} research step files for the research methodology</action>
|
||||
|
||||
The research steps vary by type:
|
||||
- **Market**: Customer behaviour, pain points, decisions, competitive analysis
|
||||
- **Domain**: Domain analysis, competitive landscape, regulatory focus, technical trends
|
||||
- **Technical**: Technical overview, integration patterns, architectural patterns, implementation research
|
||||
|
||||
<action>Use web search to gather current data and verified sources</action>
|
||||
<action>Build the research document progressively, citing all sources</action>
|
||||
</step>
|
||||
|
||||
<step n="3" goal="Synthesise research findings">
|
||||
<action>Compile the final research synthesis:</action>
|
||||
|
||||
1. Executive summary of key findings
|
||||
2. Detailed analysis sections (per research type methodology)
|
||||
3. Recommendations and implications
|
||||
4. Source citations with URLs
|
||||
|
||||
<action>Format using the research template at `{template}`</action>
|
||||
<action>Generate the document in {document_output_language}</action>
|
||||
</step>
|
||||
|
||||
<step n="4" goal="Write research report to Confluence and hand off">
|
||||
<action>Invoke the `write-to-confluence` task with:</action>
|
||||
|
||||
```
|
||||
space_key: "{confluence_space_key}"
|
||||
parent_page_id: "{confluence_parent_page_id}"
|
||||
title: "{project_name} — {research_type} Research: {research_topic}"
|
||||
content: "{compiled_research_report}"
|
||||
key_map_entry: "confluence_pages.research_{research_type}"
|
||||
```
|
||||
|
||||
<action>Update `{key_map_file}` with the new Confluence page ID under `confluence_pages.research_{research_type}`</action>
|
||||
|
||||
<action>Invoke the `post-handoff` task with:</action>
|
||||
|
||||
```
|
||||
handoff_to: "PM"
|
||||
handoff_type: "research_complete"
|
||||
summary: "{research_type} research on '{research_topic}' published to Confluence."
|
||||
confluence_page: "{research_page_id}"
|
||||
```
|
||||
|
||||
<action>Report to user:</action>
|
||||
|
||||
**Research Complete: {research_type}**
|
||||
|
||||
- **Topic:** {research_topic}
|
||||
- **Confluence Page:** {research_page_url}
|
||||
- **Sources Cited:** {source_count}
|
||||
- **Handoff:** PM agent notified
|
||||
|
||||
**Next Steps:**
|
||||
1. Review the research report on Confluence
|
||||
2. Run additional research types if needed (market, domain, technical)
|
||||
3. PM agent can incorporate findings into PRD creation
|
||||
</step>
|
||||
|
||||
</workflow>
|
||||
|
|
@ -0,0 +1,32 @@
|
|||
name: research-jira
|
||||
description: 'Conduct research (market, domain, or technical) with output to Confluence. Use when tracking_system is "jira".'
|
||||
author: "BMad"
|
||||
|
||||
# Critical variables from config
|
||||
config_source: "{project-root}/_bmad/atlassian/config.yaml"
|
||||
user_name: "{config_source}:user_name"
|
||||
communication_language: "{config_source}:communication_language"
|
||||
document_output_language: "{config_source}:document_output_language"
|
||||
user_skill_level: "{config_source}:user_skill_level"
|
||||
date: system-generated
|
||||
|
||||
# Atlassian-specific config
|
||||
confluence_space_key: "{config_source}:confluence_space_key"
|
||||
confluence_parent_page_id: "{config_source}:confluence_parent_page_id"
|
||||
key_map_file: "{config_source}:key_map_file"
|
||||
|
||||
# Research type — set by caller: "market", "domain", or "technical"
|
||||
research_type: "{research_type}"
|
||||
|
||||
# Workflow components
|
||||
installed_path: "{project-root}/_bmad/atlassian/workflow-overrides/1-analysis/research"
|
||||
instructions: "{installed_path}/instructions-jira.md"
|
||||
template: "{project-root}/_bmad/atlassian/templates/research.template.md"
|
||||
|
||||
# Reusable tasks
|
||||
context_task: "{project-root}/_bmad/atlassian/tasks/read-jira-context.md"
|
||||
write_confluence_task: "{project-root}/_bmad/atlassian/tasks/write-to-confluence.md"
|
||||
handoff_task: "{project-root}/_bmad/atlassian/tasks/post-handoff.md"
|
||||
|
||||
# Tracking system
|
||||
tracking_system: "jira"
|
||||
|
|
@ -0,0 +1,121 @@
|
|||
# Create PRD — Confluence Output
|
||||
|
||||
<critical>The workflow execution engine is governed by: {project-root}/_bmad/core/tasks/workflow.xml</critical>
|
||||
<critical>You MUST have already loaded and processed: the workflow-jira.yaml for this workflow</critical>
|
||||
|
||||
## Overview
|
||||
|
||||
Creates a PRD through structured collaborative workflow facilitation. The multi-step elicitation follows the standard create-prd methodology. All output is written to Confluence exclusively. After creation, links the PRD to any existing Epics via Jira Remote Issue Links and posts a handoff to the Architect and SM agents.
|
||||
|
||||
---
|
||||
|
||||
<workflow>
|
||||
|
||||
<step n="1" goal="Initialize and load context from Jira/Confluence">
|
||||
<action>Communicate in {communication_language} with {user_name}</action>
|
||||
<action>Invoke the `read-jira-context` task with `context_type: "project_overview"` to fetch existing project context from Confluence (product brief, research reports)</action>
|
||||
<action>Load the PRD template from `{template}`</action>
|
||||
<action>Load the PRD checklist from `{checklist}`</action>
|
||||
|
||||
<action>Check for existing product brief on Confluence:</action>
|
||||
<action>Invoke `read-jira-context` with `context_type: "confluence_artefact"` and `scope_key: "product_brief"` to load the product brief if it exists</action>
|
||||
|
||||
<action>Begin collaborative PRD creation with the user as a PM facilitator peer</action>
|
||||
<action>Announce: "**Create Mode: Creating a new PRD from scratch.**"</action>
|
||||
</step>
|
||||
|
||||
<step n="2" goal="Discovery and vision elicitation">
|
||||
<action>Follow the standard PRD creation steps for discovery:</action>
|
||||
|
||||
1. **Product Discovery** — Understand the product context, existing brief, and research
|
||||
2. **Vision Statement** — Craft a clear, compelling vision statement
|
||||
3. **Executive Summary** — Write a concise executive summary
|
||||
|
||||
<action>If a product brief was loaded from Confluence, use it as the foundation rather than re-asking questions already answered</action>
|
||||
<action>Capture key insights and confirm understanding with the user</action>
|
||||
</step>
|
||||
|
||||
<step n="3" goal="Success metrics and user journeys">
|
||||
<action>Continue the standard PRD creation steps:</action>
|
||||
|
||||
1. **Success Metrics** — Define measurable KPIs and success criteria
|
||||
2. **User Journeys** — Map primary and secondary user journeys
|
||||
3. **Domain Model** — Establish domain concepts and relationships
|
||||
|
||||
<action>Validate each section with the user before proceeding</action>
|
||||
</step>
|
||||
|
||||
<step n="4" goal="Innovation, scoping, and requirements">
|
||||
<action>Continue the standard PRD creation steps:</action>
|
||||
|
||||
1. **Innovation Opportunities** — Identify areas for differentiation
|
||||
2. **Project Type Classification** — Classify the project (greenfield, brownfield, etc.)
|
||||
3. **Scoping** — Define MVP scope boundaries
|
||||
4. **Functional Requirements** — Detail functional requirements with traceability
|
||||
5. **Non-Functional Requirements** — Define NFRs (performance, security, scalability)
|
||||
|
||||
<action>Use the checklist at `{checklist}` to validate completeness of each section</action>
|
||||
</step>
|
||||
|
||||
<step n="5" goal="Polish and review">
|
||||
<action>Complete the standard PRD creation steps:</action>
|
||||
|
||||
1. **Polish** — Review for consistency, clarity, and completeness
|
||||
2. **Cross-reference validation** — Ensure all sections align
|
||||
|
||||
<action>Present a summary of the complete PRD to the user for final approval</action>
|
||||
<action>Ask: "Review the PRD summary above. Continue [C] to publish, or Edit [E] to revise?"</action>
|
||||
</step>
|
||||
|
||||
<step n="6" goal="Write PRD to Confluence, link to Epics, and hand off">
|
||||
<action>Compile the complete PRD using the template at `{template}`</action>
|
||||
<action>Generate the document in {document_output_language}</action>
|
||||
|
||||
<action>Invoke the `write-to-confluence` task with:</action>
|
||||
|
||||
```
|
||||
space_key: "{confluence_space_key}"
|
||||
parent_page_id: "{confluence_parent_page_id}"
|
||||
title: "{project_name} — Product Requirements Document"
|
||||
content: "{compiled_prd_content}"
|
||||
key_map_entry: "confluence_pages.prd"
|
||||
```
|
||||
|
||||
<action>Update `{key_map_file}` with the new Confluence page ID under `confluence_pages.prd`</action>
|
||||
|
||||
<action>Link PRD to any existing Epics in Jira:</action>
|
||||
<action>Call `Search Issues` with JQL: `project = {jira_project_key} AND issuetype = Epic ORDER BY rank ASC`</action>
|
||||
<action>For each Epic found, call `Create Remote Issue Link` with:</action>
|
||||
|
||||
```
|
||||
issue_key: "{epic_key}"
|
||||
url: "{prd_confluence_page_url}"
|
||||
title: "PRD: {project_name}"
|
||||
relationship: "documented by"
|
||||
```
|
||||
|
||||
<action>Invoke the `post-handoff` task with:</action>
|
||||
|
||||
```
|
||||
handoff_to: "Architect,SM"
|
||||
handoff_type: "prd_complete"
|
||||
summary: "PRD created and published to Confluence. Ready for architecture design and epic planning."
|
||||
confluence_page: "{prd_page_id}"
|
||||
```
|
||||
|
||||
<action>Report to user:</action>
|
||||
|
||||
**PRD Complete**
|
||||
|
||||
- **Confluence Page:** {prd_page_url}
|
||||
- **Status:** Published
|
||||
- **Epic Links:** {linked_epic_count} epics linked
|
||||
- **Handoff:** Architect and SM agents notified
|
||||
|
||||
**Next Steps:**
|
||||
1. Review the PRD on Confluence
|
||||
2. Architect can begin architecture design with [Create Architecture]
|
||||
3. UX designer can begin UX design with [Create UX Design]
|
||||
</step>
|
||||
|
||||
</workflow>
|
||||
|
|
@ -0,0 +1,31 @@
|
|||
name: create-prd-jira
|
||||
description: 'Create a PRD with output to Confluence. Use when tracking_system is "jira".'
|
||||
author: "BMad"
|
||||
|
||||
# Critical variables from config
|
||||
config_source: "{project-root}/_bmad/atlassian/config.yaml"
|
||||
user_name: "{config_source}:user_name"
|
||||
communication_language: "{config_source}:communication_language"
|
||||
document_output_language: "{config_source}:document_output_language"
|
||||
user_skill_level: "{config_source}:user_skill_level"
|
||||
date: system-generated
|
||||
|
||||
# Atlassian-specific config
|
||||
jira_project_key: "{config_source}:jira_project_key"
|
||||
confluence_space_key: "{config_source}:confluence_space_key"
|
||||
confluence_parent_page_id: "{config_source}:confluence_parent_page_id"
|
||||
key_map_file: "{config_source}:key_map_file"
|
||||
|
||||
# Workflow components
|
||||
installed_path: "{project-root}/_bmad/atlassian/workflow-overrides/2-plan-workflows/create-prd"
|
||||
instructions: "{installed_path}/instructions-jira.md"
|
||||
template: "{project-root}/_bmad/atlassian/templates/prd-template.md"
|
||||
checklist: "{project-root}/_bmad/atlassian/checklists/prd-checklist.md"
|
||||
|
||||
# Reusable tasks
|
||||
context_task: "{project-root}/_bmad/atlassian/tasks/read-jira-context.md"
|
||||
write_confluence_task: "{project-root}/_bmad/atlassian/tasks/write-to-confluence.md"
|
||||
handoff_task: "{project-root}/_bmad/atlassian/tasks/post-handoff.md"
|
||||
|
||||
# Tracking system
|
||||
tracking_system: "jira"
|
||||
|
|
@ -0,0 +1,172 @@
|
|||
# Create UX Design — Confluence Output
|
||||
|
||||
<critical>The workflow execution engine is governed by: {project-root}/_bmad/core/tasks/workflow.xml</critical>
|
||||
<critical>You MUST have already loaded and processed: the workflow-jira.yaml for this workflow</critical>
|
||||
|
||||
## Overview
|
||||
|
||||
Creates a comprehensive UX design specification through a 14-step collaborative visual exploration workflow. All output is written to Confluence exclusively. After creation, links the UX design to any existing Epics via Jira Remote Issue Links and posts a handoff.
|
||||
|
||||
---
|
||||
|
||||
<workflow>
|
||||
|
||||
<step n="1" goal="Initialize and load context from Jira/Confluence">
|
||||
<action>Communicate in {communication_language} with {user_name}</action>
|
||||
<action>Invoke the `read-jira-context` task with `context_type: "project_overview"` to fetch existing project context from Confluence</action>
|
||||
<action>Invoke `read-jira-context` with `context_type: "confluence_artefact"` and `scope_key: "prd"` to load the PRD if it exists</action>
|
||||
<action>Invoke `read-jira-context` with `context_type: "confluence_artefact"` and `scope_key: "product_brief"` to load the product brief if it exists</action>
|
||||
<action>Load the UX design template from `{template}`</action>
|
||||
<action>Begin collaborative UX design facilitation with the user</action>
|
||||
</step>
|
||||
|
||||
<step n="2" goal="Discovery — understand the product context">
|
||||
<action>Review the PRD and product brief loaded from Confluence</action>
|
||||
<action>Identify the core user personas, journeys, and requirements that the UX must address</action>
|
||||
<action>Discuss with the user: target platforms, design constraints, brand guidelines, and inspiration</action>
|
||||
</step>
|
||||
|
||||
<step n="3" goal="Core experience definition">
|
||||
<action>Define the core experience principles that will guide the design:</action>
|
||||
1. What is the primary user emotion we want to evoke?
|
||||
2. What is the single most important interaction?
|
||||
3. What differentiates this experience from competitors?
|
||||
<action>Confirm the core experience pillars with the user</action>
|
||||
</step>
|
||||
|
||||
<step n="4" goal="Emotional response mapping">
|
||||
<action>Map the desired emotional responses across user journeys:</action>
|
||||
- First impression / onboarding
|
||||
- Core task execution
|
||||
- Error handling and recovery
|
||||
- Achievement and completion
|
||||
<action>Validate with the user</action>
|
||||
</step>
|
||||
|
||||
<step n="5" goal="Design inspiration and references">
|
||||
<action>Explore design inspiration with the user:</action>
|
||||
- Reference applications and design systems
|
||||
- Visual style preferences (minimal, rich, playful, professional)
|
||||
- Industry benchmarks and best practices
|
||||
<action>Document agreed-upon design direction</action>
|
||||
</step>
|
||||
|
||||
<step n="6" goal="Design system foundations">
|
||||
<action>Establish the design system foundations:</action>
|
||||
- Typography scale and hierarchy
|
||||
- Color palette (primary, secondary, semantic)
|
||||
- Spacing and grid system
|
||||
- Iconography style
|
||||
<action>Confirm with the user</action>
|
||||
</step>
|
||||
|
||||
<step n="7" goal="Defining the experience — information architecture">
|
||||
<action>Define the information architecture:</action>
|
||||
- Navigation structure and hierarchy
|
||||
- Content organization patterns
|
||||
- User flow mapping
|
||||
<action>Present and validate with the user</action>
|
||||
</step>
|
||||
|
||||
<step n="8" goal="Visual foundation — layout patterns">
|
||||
<action>Establish visual layout patterns:</action>
|
||||
- Page layout templates
|
||||
- Content density guidelines
|
||||
- Responsive breakpoint strategy
|
||||
<action>Confirm with the user</action>
|
||||
</step>
|
||||
|
||||
<step n="9" goal="Design directions — key screens">
|
||||
<action>Create design direction specifications for key screens:</action>
|
||||
- Landing / home screen
|
||||
- Primary task screens
|
||||
- Settings and configuration
|
||||
<action>Present options and gather user feedback</action>
|
||||
</step>
|
||||
|
||||
<step n="10" goal="User journey wireframes">
|
||||
<action>Specify wireframe details for primary user journeys:</action>
|
||||
- Step-by-step flow descriptions
|
||||
- Screen transitions and interactions
|
||||
- State management (empty, loading, error, success)
|
||||
<action>Validate with the user</action>
|
||||
</step>
|
||||
|
||||
<step n="11" goal="Component strategy">
|
||||
<action>Define the component strategy:</action>
|
||||
- Reusable component library plan
|
||||
- Component hierarchy and composition
|
||||
- Interaction patterns (buttons, forms, modals, etc.)
|
||||
<action>Confirm with the user</action>
|
||||
</step>
|
||||
|
||||
<step n="12" goal="UX patterns and micro-interactions">
|
||||
<action>Specify UX patterns and micro-interactions:</action>
|
||||
- Feedback mechanisms (success, error, progress)
|
||||
- Animation and transition guidelines
|
||||
- Gesture and shortcut patterns
|
||||
<action>Validate with the user</action>
|
||||
</step>
|
||||
|
||||
<step n="13" goal="Responsive design and accessibility">
|
||||
<action>Define responsive and accessibility specifications:</action>
|
||||
- Responsive breakpoints and adaptation rules
|
||||
- WCAG compliance targets
|
||||
- Keyboard navigation patterns
|
||||
- Screen reader considerations
|
||||
- Colour contrast requirements
|
||||
<action>Confirm with the user</action>
|
||||
</step>
|
||||
|
||||
<step n="14" goal="Write UX design to Confluence, link to Epics, and hand off">
|
||||
<action>Compile the complete UX design specification using the template at `{template}`</action>
|
||||
<action>Generate the document in {document_output_language}</action>
|
||||
|
||||
<action>Invoke the `write-to-confluence` task with:</action>
|
||||
|
||||
```
|
||||
space_key: "{confluence_space_key}"
|
||||
parent_page_id: "{confluence_parent_page_id}"
|
||||
title: "{project_name} — UX Design Specification"
|
||||
content: "{compiled_ux_design_content}"
|
||||
key_map_entry: "confluence_pages.ux_design"
|
||||
```
|
||||
|
||||
<action>Update `{key_map_file}` with the new Confluence page ID under `confluence_pages.ux_design`</action>
|
||||
|
||||
<action>Link UX design to any existing Epics in Jira:</action>
|
||||
<action>Call `Search Issues` with JQL: `project = {jira_project_key} AND issuetype = Epic ORDER BY rank ASC`</action>
|
||||
<action>For each Epic found, call `Create Remote Issue Link` with:</action>
|
||||
|
||||
```
|
||||
issue_key: "{epic_key}"
|
||||
url: "{ux_design_confluence_page_url}"
|
||||
title: "UX Design: {project_name}"
|
||||
relationship: "documented by"
|
||||
```
|
||||
|
||||
<action>Invoke the `post-handoff` task with:</action>
|
||||
|
||||
```
|
||||
handoff_to: "Architect,SM"
|
||||
handoff_type: "ux_design_complete"
|
||||
summary: "UX design specification created and published to Confluence. Ready for architecture alignment and story creation."
|
||||
confluence_page: "{ux_design_page_id}"
|
||||
```
|
||||
|
||||
<action>Report to user:</action>
|
||||
|
||||
**UX Design Complete**
|
||||
|
||||
- **Confluence Page:** {ux_design_page_url}
|
||||
- **Status:** Published
|
||||
- **Epic Links:** {linked_epic_count} epics linked
|
||||
- **Handoff:** Architect and SM agents notified
|
||||
|
||||
**Next Steps:**
|
||||
1. Review the UX design specification on Confluence
|
||||
2. Architect can align the architecture with UX requirements
|
||||
3. SM can incorporate UX specifications into story acceptance criteria
|
||||
</step>
|
||||
|
||||
</workflow>
|
||||
|
|
@ -0,0 +1,30 @@
|
|||
name: create-ux-design-jira
|
||||
description: 'Create UX design specification with output to Confluence. Use when tracking_system is "jira".'
|
||||
author: "BMad"
|
||||
|
||||
# Critical variables from config
|
||||
config_source: "{project-root}/_bmad/atlassian/config.yaml"
|
||||
user_name: "{config_source}:user_name"
|
||||
communication_language: "{config_source}:communication_language"
|
||||
document_output_language: "{config_source}:document_output_language"
|
||||
user_skill_level: "{config_source}:user_skill_level"
|
||||
date: system-generated
|
||||
|
||||
# Atlassian-specific config
|
||||
jira_project_key: "{config_source}:jira_project_key"
|
||||
confluence_space_key: "{config_source}:confluence_space_key"
|
||||
confluence_parent_page_id: "{config_source}:confluence_parent_page_id"
|
||||
key_map_file: "{config_source}:key_map_file"
|
||||
|
||||
# Workflow components
|
||||
installed_path: "{project-root}/_bmad/atlassian/workflow-overrides/2-plan-workflows/create-ux-design"
|
||||
instructions: "{installed_path}/instructions-jira.md"
|
||||
template: "{project-root}/_bmad/atlassian/templates/ux-design-template.md"
|
||||
|
||||
# Reusable tasks
|
||||
context_task: "{project-root}/_bmad/atlassian/tasks/read-jira-context.md"
|
||||
write_confluence_task: "{project-root}/_bmad/atlassian/tasks/write-to-confluence.md"
|
||||
handoff_task: "{project-root}/_bmad/atlassian/tasks/post-handoff.md"
|
||||
|
||||
# Tracking system
|
||||
tracking_system: "jira"
|
||||
|
|
@ -0,0 +1,153 @@
|
|||
# Check Implementation Readiness — Jira/Confluence Integration
|
||||
|
||||
<critical>The workflow execution engine is governed by: {project-root}/_bmad/core/tasks/workflow.xml</critical>
|
||||
<critical>You MUST have already loaded and processed: the workflow-jira.yaml for this workflow</critical>
|
||||
|
||||
## Overview
|
||||
|
||||
Validates that PRD, UX Design, Architecture, and Epics/Stories are complete and aligned before Phase 4 implementation begins. Reads all artefacts from Confluence and Jira. Generates a readiness report using the template, publishes it to Confluence, and posts a summary comment on each Epic.
|
||||
|
||||
---
|
||||
|
||||
<workflow>
|
||||
|
||||
<step n="1" goal="Load context — read project artefacts from Confluence and Epics/Stories from Jira">
|
||||
<action>Communicate in {communication_language} with {user_name}</action>
|
||||
<action>Invoke the `read-jira-context` task with `context_type: "project_overview"` to discover all available project artefacts</action>
|
||||
|
||||
<action>Load each artefact from Confluence:</action>
|
||||
<action>Invoke `read-jira-context` with `context_type: "confluence_artefact"` and `scope_key: "prd"` to load the PRD</action>
|
||||
<action>Invoke `read-jira-context` with `context_type: "confluence_artefact"` and `scope_key: "architecture"` to load the Architecture</action>
|
||||
<action>Invoke `read-jira-context` with `context_type: "confluence_artefact"` and `scope_key: "ux_design"` to load the UX design (if exists)</action>
|
||||
<action>Invoke `read-jira-context` with `context_type: "confluence_artefact"` and `scope_key: "product_brief"` to load the product brief</action>
|
||||
|
||||
<action>Load Epics and Stories from Jira:</action>
|
||||
<action>Call `Search Issues` with JQL: `project = {jira_project_key} AND issuetype = Epic ORDER BY rank ASC`</action>
|
||||
<action>For each Epic, call `Search Issues` with JQL: `"Epic Link" = {epic_key} AND issuetype = Story ORDER BY rank ASC`</action>
|
||||
<action>Call `Get Issue` for each Epic and Story to load full descriptions and acceptance criteria</action>
|
||||
|
||||
<action>Report discovery results to the user:</action>
|
||||
|
||||
| Artefact | Status |
|
||||
|---|---|
|
||||
| PRD | {found/missing} |
|
||||
| Architecture | {found/missing} |
|
||||
| UX Design | {found/missing} |
|
||||
| Product Brief | {found/missing} |
|
||||
| Epics | {count} found |
|
||||
| Stories | {count} found |
|
||||
|
||||
<action>If any critical artefact is missing, warn the user and ask whether to proceed with a partial readiness check</action>
|
||||
</step>
|
||||
|
||||
<step n="2" goal="Requirements coverage check — verify every PRD requirement maps to at least one Epic/Story">
|
||||
<action>Extract all functional and non-functional requirements from the PRD</action>
|
||||
<action>Map each requirement to one or more Epics/Stories</action>
|
||||
<action>Identify any requirements that are not covered by any Epic or Story</action>
|
||||
<action>Identify any Epics that do not trace back to a PRD requirement</action>
|
||||
<action>Record coverage gaps for the readiness report</action>
|
||||
</step>
|
||||
|
||||
<step n="3" goal="Architecture alignment check — verify tech stack, patterns, and ADRs are reflected in story structure">
|
||||
<action>Review the Architecture document for tech stack decisions, patterns, and ADRs</action>
|
||||
<action>Verify that stories reference or align with the chosen tech stack and patterns</action>
|
||||
<action>Check that ADR decisions are reflected in story constraints or implementation notes</action>
|
||||
<action>Identify any architectural decisions that lack corresponding stories or tasks</action>
|
||||
<action>Record alignment findings for the readiness report</action>
|
||||
</step>
|
||||
|
||||
<step n="4" goal="Story completeness check — verify all stories have acceptance criteria and proper subtasks">
|
||||
<action>Review each Story in Jira for completeness:</action>
|
||||
|
||||
1. Does every story have clear, testable acceptance criteria?
|
||||
2. Are stories appropriately sized (not too large or too small)?
|
||||
3. Do stories have proper subtasks where needed?
|
||||
4. Are dependencies between stories identified and linked?
|
||||
5. Is the story ordering logical for implementation?
|
||||
6. Do stories align with the architecture's component structure?
|
||||
|
||||
<action>Record quality findings for the readiness report</action>
|
||||
</step>
|
||||
|
||||
<step n="5" goal="Risk assessment — identify gaps, missing stories, and unaddressed requirements">
|
||||
<action>Compile all findings from Steps 2–4 into a risk assessment:</action>
|
||||
|
||||
1. **Critical gaps** — requirements with no coverage, architectural misalignment
|
||||
2. **Major gaps** — incomplete stories, missing acceptance criteria
|
||||
3. **Minor gaps** — ordering issues, missing subtasks, cosmetic concerns
|
||||
|
||||
<action>Assign an overall readiness verdict:</action>
|
||||
|
||||
- **READY**: All checks pass, implementation can begin
|
||||
- **READY WITH NOTES**: Minor gaps identified, can proceed with awareness
|
||||
- **NOT READY**: Critical gaps that must be addressed first
|
||||
|
||||
<action>Record the risk assessment for the readiness report</action>
|
||||
</step>
|
||||
|
||||
<step n="6" goal="Generate readiness report, write to Confluence, post comments, and hand off">
|
||||
<action>Compile the complete readiness report using the template at `{template}`</action>
|
||||
<action>Generate the report in {document_output_language}</action>
|
||||
|
||||
<action>Invoke the `write-to-confluence` task with:</action>
|
||||
|
||||
```
|
||||
space_key: "{confluence_space_key}"
|
||||
parent_page_id: "{confluence_parent_page_id}"
|
||||
title: "{project_name} — Implementation Readiness Report ({date})"
|
||||
content: "{compiled_readiness_report}"
|
||||
key_map_entry: "confluence_pages.readiness_report"
|
||||
```
|
||||
|
||||
<action>Update `{key_map_file}` with the new Confluence page ID under `confluence_pages.readiness_report`</action>
|
||||
|
||||
<action>Post a summary comment on each Epic in Jira:</action>
|
||||
<action>For each Epic, call `Add Comment` with:</action>
|
||||
|
||||
```
|
||||
issue_key: "{epic_key}"
|
||||
body: |
|
||||
## Implementation Readiness: {verdict}
|
||||
|
||||
**Date:** {date}
|
||||
**Report:** {readiness_report_confluence_url}
|
||||
|
||||
### Epic-Specific Findings
|
||||
{findings_for_this_epic}
|
||||
|
||||
### Action Items
|
||||
{action_items_for_this_epic}
|
||||
```
|
||||
|
||||
<action>Invoke the `post-handoff` task with:</action>
|
||||
|
||||
```
|
||||
handoff_to: "SM"
|
||||
handoff_type: "readiness_check_complete"
|
||||
summary: "Implementation readiness check completed. Verdict: {verdict}. Report published to Confluence."
|
||||
confluence_page: "{readiness_report_page_id}"
|
||||
```
|
||||
|
||||
<action>Report to user:</action>
|
||||
|
||||
**Implementation Readiness: {verdict}**
|
||||
|
||||
- **Confluence Report:** {readiness_report_page_url}
|
||||
- **Epics Reviewed:** {epic_count}
|
||||
- **Stories Reviewed:** {story_count}
|
||||
- **Findings:** {critical_count} critical, {major_count} major, {minor_count} minor
|
||||
|
||||
{if_ready}
|
||||
**Next Steps:**
|
||||
1. Begin Phase 4 with [Sprint Planning] to create the first sprint
|
||||
2. Use [Create Story] to prepare stories with full dev context
|
||||
{end_if}
|
||||
|
||||
{if_not_ready}
|
||||
**Action Required:**
|
||||
{list_of_critical_gaps}
|
||||
Address these gaps before beginning implementation.
|
||||
{end_if}
|
||||
</step>
|
||||
|
||||
</workflow>
|
||||
|
|
@ -0,0 +1,31 @@
|
|||
name: check-implementation-readiness-jira
|
||||
description: 'Validate PRD, UX, Architecture, and Epics are complete. Use when tracking_system is "jira".'
|
||||
author: "BMad"
|
||||
|
||||
# Critical variables from config
|
||||
config_source: "{project-root}/_bmad/atlassian/config.yaml"
|
||||
user_name: "{config_source}:user_name"
|
||||
communication_language: "{config_source}:communication_language"
|
||||
document_output_language: "{config_source}:document_output_language"
|
||||
user_skill_level: "{config_source}:user_skill_level"
|
||||
date: system-generated
|
||||
|
||||
# Atlassian-specific config
|
||||
jira_project_key: "{config_source}:jira_project_key"
|
||||
confluence_space_key: "{config_source}:confluence_space_key"
|
||||
confluence_parent_page_id: "{config_source}:confluence_parent_page_id"
|
||||
key_map_file: "{config_source}:key_map_file"
|
||||
status_transitions: "{config_source}:status_transitions"
|
||||
|
||||
# Workflow components
|
||||
installed_path: "{project-root}/_bmad/atlassian/workflow-overrides/3-solutioning/check-implementation-readiness"
|
||||
instructions: "{installed_path}/instructions-jira.md"
|
||||
template: "{project-root}/_bmad/atlassian/templates/readiness-report-template.md"
|
||||
|
||||
# Reusable tasks
|
||||
context_task: "{project-root}/_bmad/atlassian/tasks/read-jira-context.md"
|
||||
write_confluence_task: "{project-root}/_bmad/atlassian/tasks/write-to-confluence.md"
|
||||
handoff_task: "{project-root}/_bmad/atlassian/tasks/post-handoff.md"
|
||||
|
||||
# Tracking system
|
||||
tracking_system: "jira"
|
||||
|
|
@ -0,0 +1,147 @@
|
|||
# Create Architecture — Confluence Output
|
||||
|
||||
<critical>The workflow execution engine is governed by: {project-root}/_bmad/core/tasks/workflow.xml</critical>
|
||||
<critical>You MUST have already loaded and processed: the workflow-jira.yaml for this workflow</critical>
|
||||
|
||||
## Overview
|
||||
|
||||
Creates comprehensive architecture decisions through an 8-step collaborative workflow. All output is written to Confluence exclusively. After creation, links the architecture document to any existing Epics via Jira Remote Issue Links and posts a handoff.
|
||||
|
||||
---
|
||||
|
||||
<workflow>
|
||||
|
||||
<step n="1" goal="Initialize and load context from Jira/Confluence">
|
||||
<action>Communicate in {communication_language} with {user_name}</action>
|
||||
<action>Invoke the `read-jira-context` task with `context_type: "project_overview"` to fetch existing project context from Confluence</action>
|
||||
<action>Invoke `read-jira-context` with `context_type: "confluence_artefact"` and `scope_key: "prd"` to load the PRD</action>
|
||||
<action>Invoke `read-jira-context` with `context_type: "confluence_artefact"` and `scope_key: "product_brief"` to load the product brief</action>
|
||||
<action>Invoke `read-jira-context` with `context_type: "confluence_artefact"` and `scope_key: "ux_design"` to load the UX design (if exists)</action>
|
||||
<action>Load the architecture template from `{template}`</action>
|
||||
<action>Begin collaborative architecture facilitation as an architectural peer</action>
|
||||
<action>Ask the user to describe the technical context, constraints, and any existing systems</action>
|
||||
</step>
|
||||
|
||||
<step n="2" goal="Context analysis">
|
||||
<action>Analyse the PRD, product brief, and UX design loaded from Confluence:</action>
|
||||
|
||||
1. Identify core functional requirements with architectural implications
|
||||
2. Extract non-functional requirements (performance, scalability, security)
|
||||
3. Map technical constraints and integration points
|
||||
4. Identify domain complexity and project type
|
||||
|
||||
<action>Present a technical context summary and confirm with the user</action>
|
||||
</step>
|
||||
|
||||
<step n="3" goal="Starter architecture — technology selection">
|
||||
<action>Propose and discuss technology selections:</action>
|
||||
|
||||
1. Programming languages and frameworks
|
||||
2. Database and storage technologies
|
||||
3. Infrastructure and deployment approach
|
||||
4. Third-party services and integrations
|
||||
|
||||
<action>Present recommendations with rationale and trade-offs</action>
|
||||
<action>Confirm selections with the user</action>
|
||||
</step>
|
||||
|
||||
<step n="4" goal="Architecture decisions (ADRs)">
|
||||
<action>Document key architecture decisions using the ADR format:</action>
|
||||
|
||||
For each significant decision:
|
||||
- **Context**: What is the situation?
|
||||
- **Decision**: What was decided?
|
||||
- **Rationale**: Why was this chosen over alternatives?
|
||||
- **Consequences**: What are the trade-offs?
|
||||
|
||||
<action>Validate each decision with the user</action>
|
||||
</step>
|
||||
|
||||
<step n="5" goal="Architecture patterns">
|
||||
<action>Define the architectural patterns to be used:</action>
|
||||
|
||||
1. Overall architecture style (monolith, microservices, serverless, etc.)
|
||||
2. Data flow patterns
|
||||
3. Authentication and authorisation patterns
|
||||
4. Error handling and resilience patterns
|
||||
5. Testing strategy alignment
|
||||
|
||||
<action>Confirm patterns with the user</action>
|
||||
</step>
|
||||
|
||||
<step n="6" goal="System structure and component design">
|
||||
<action>Define the system structure:</action>
|
||||
|
||||
1. Component/module breakdown
|
||||
2. Layer boundaries and responsibilities
|
||||
3. API contracts between components
|
||||
4. Data model and schema design
|
||||
5. File and folder structure conventions
|
||||
|
||||
<action>Present the structure and validate with the user</action>
|
||||
</step>
|
||||
|
||||
<step n="7" goal="Validation and cross-reference check">
|
||||
<action>Validate the architecture against the PRD and UX design:</action>
|
||||
|
||||
1. All functional requirements have architectural support
|
||||
2. NFRs are addressed by specific patterns or decisions
|
||||
3. UX requirements are technically feasible
|
||||
4. No unresolved conflicts or gaps
|
||||
|
||||
<action>Present validation results and resolve any issues with the user</action>
|
||||
</step>
|
||||
|
||||
<step n="8" goal="Write architecture to Confluence, link to Epics, and hand off">
|
||||
<action>Compile the complete architecture document using the template at `{template}`</action>
|
||||
<action>Generate the document in {document_output_language}</action>
|
||||
|
||||
<action>Invoke the `write-to-confluence` task with:</action>
|
||||
|
||||
```
|
||||
space_key: "{confluence_space_key}"
|
||||
parent_page_id: "{confluence_parent_page_id}"
|
||||
title: "{project_name} — Architecture Design"
|
||||
content: "{compiled_architecture_content}"
|
||||
key_map_entry: "confluence_pages.architecture"
|
||||
```
|
||||
|
||||
<action>Update `{key_map_file}` with the new Confluence page ID under `confluence_pages.architecture`</action>
|
||||
|
||||
<action>Link architecture to any existing Epics in Jira:</action>
|
||||
<action>Call `Search Issues` with JQL: `project = {jira_project_key} AND issuetype = Epic ORDER BY rank ASC`</action>
|
||||
<action>For each Epic found, call `Create Remote Issue Link` with:</action>
|
||||
|
||||
```
|
||||
issue_key: "{epic_key}"
|
||||
url: "{architecture_confluence_page_url}"
|
||||
title: "Architecture: {project_name}"
|
||||
relationship: "documented by"
|
||||
```
|
||||
|
||||
<action>Invoke the `post-handoff` task with:</action>
|
||||
|
||||
```
|
||||
handoff_to: "SM"
|
||||
handoff_type: "architecture_complete"
|
||||
summary: "Architecture design created and published to Confluence. Ready for epic and story creation."
|
||||
confluence_page: "{architecture_page_id}"
|
||||
```
|
||||
|
||||
<action>Report to user:</action>
|
||||
|
||||
**Architecture Design Complete**
|
||||
|
||||
- **Confluence Page:** {architecture_page_url}
|
||||
- **Status:** Published
|
||||
- **ADRs Documented:** {adr_count}
|
||||
- **Epic Links:** {linked_epic_count} epics linked
|
||||
- **Handoff:** SM agent notified
|
||||
|
||||
**Next Steps:**
|
||||
1. Review the architecture document on Confluence
|
||||
2. SM can create Epics and Stories with [Create Epics and Stories]
|
||||
3. Run [Check Implementation Readiness] to validate completeness
|
||||
</step>
|
||||
|
||||
</workflow>
|
||||
|
|
@ -0,0 +1,30 @@
|
|||
name: create-architecture-jira
|
||||
description: 'Create architecture design with output to Confluence. Use when tracking_system is "jira".'
|
||||
author: "BMad"
|
||||
|
||||
# Critical variables from config
|
||||
config_source: "{project-root}/_bmad/atlassian/config.yaml"
|
||||
user_name: "{config_source}:user_name"
|
||||
communication_language: "{config_source}:communication_language"
|
||||
document_output_language: "{config_source}:document_output_language"
|
||||
user_skill_level: "{config_source}:user_skill_level"
|
||||
date: system-generated
|
||||
|
||||
# Atlassian-specific config
|
||||
jira_project_key: "{config_source}:jira_project_key"
|
||||
confluence_space_key: "{config_source}:confluence_space_key"
|
||||
confluence_parent_page_id: "{config_source}:confluence_parent_page_id"
|
||||
key_map_file: "{config_source}:key_map_file"
|
||||
|
||||
# Workflow components
|
||||
installed_path: "{project-root}/_bmad/atlassian/workflow-overrides/3-solutioning/create-architecture"
|
||||
instructions: "{installed_path}/instructions-jira.md"
|
||||
template: "{project-root}/_bmad/atlassian/templates/architecture-template.md"
|
||||
|
||||
# Reusable tasks
|
||||
context_task: "{project-root}/_bmad/atlassian/tasks/read-jira-context.md"
|
||||
write_confluence_task: "{project-root}/_bmad/atlassian/tasks/write-to-confluence.md"
|
||||
handoff_task: "{project-root}/_bmad/atlassian/tasks/post-handoff.md"
|
||||
|
||||
# Tracking system
|
||||
tracking_system: "jira"
|
||||
|
|
@ -88,10 +88,9 @@ summary: "Product Requirements Document"
|
|||
```
|
||||
</step>
|
||||
|
||||
<step n="4.4" goal="Dual-write to local files (if configured)">
|
||||
<action>If `{output_mode}` is `"dual"`:</action>
|
||||
<action>Also write the complete epics/stories document to `{planning_artifacts}/epics.md` using the standard bmm template</action>
|
||||
<action>This ensures local file access remains available as a cache</action>
|
||||
<step n="4.4" goal="Verify key map is updated">
|
||||
<action>Confirm all created epic and story keys have been recorded in `{key_map_file}`</action>
|
||||
<action>This ensures downstream workflows can look up Jira issue keys</action>
|
||||
</step>
|
||||
|
||||
<step n="4.5" goal="Report results">
|
||||
|
|
|
|||
|
|
@ -5,7 +5,7 @@
|
|||
|
||||
## Overview
|
||||
|
||||
Runs the standard bmm code review checklist and posts the results as a structured Jira comment on the story. If the review passes, transitions the story to Done. If it fails, adds findings and keeps the story in Review for fixes.
|
||||
Runs the code review checklist and posts the results as a structured Jira comment on the story. If the review passes, transitions the story to Done. If it fails, adds findings and keeps the story in Review for fixes.
|
||||
|
||||
---
|
||||
|
||||
|
|
@ -28,7 +28,7 @@ project = {jira_project_key} AND issuetype = Story AND status = "Review" ORDER B
|
|||
<step n="2" goal="Lock the story and run code review">
|
||||
<action>Invoke `lock-issue` task with `issue_key: "{selected_issue_key}"`, `action: "lock"`, `agent_name: "code-review"`</action>
|
||||
|
||||
<action>Follow the standard bmm code review checklist at `{bmm_checklist}`</action>
|
||||
<action>Follow the code review checklist at `{checklist}`</action>
|
||||
|
||||
Review the implementation across all quality facets:
|
||||
- Code correctness and completeness against acceptance criteria
|
||||
|
|
|
|||
|
|
@ -4,9 +4,8 @@ author: "BMad"
|
|||
|
||||
# Critical variables from config
|
||||
config_source: "{project-root}/_bmad/atlassian/config.yaml"
|
||||
bmm_config: "{project-root}/_bmad/bmm/config.yaml"
|
||||
user_name: "{bmm_config}:user_name"
|
||||
communication_language: "{bmm_config}:communication_language"
|
||||
user_name: "{config_source}:user_name"
|
||||
communication_language: "{config_source}:communication_language"
|
||||
date: system-generated
|
||||
|
||||
# Atlassian-specific config
|
||||
|
|
@ -17,11 +16,13 @@ status_transitions: "{config_source}:status_transitions"
|
|||
# Workflow components
|
||||
installed_path: "{project-root}/_bmad/atlassian/workflow-overrides/4-implementation/code-review"
|
||||
instructions: "{installed_path}/instructions-jira.md"
|
||||
bmm_checklist: "{project-root}/_bmad/bmm/workflows/4-implementation/code-review/checklist.md"
|
||||
checklist: "{project-root}/_bmad/atlassian/workflows/4-implementation/code-review/checklist.md"
|
||||
|
||||
# Reusable tasks
|
||||
transition_task: "{project-root}/_bmad/atlassian/tasks/transition-jira-issue.md"
|
||||
lock_task: "{project-root}/_bmad/atlassian/tasks/lock-issue.md"
|
||||
context_task: "{project-root}/_bmad/atlassian/tasks/read-jira-context.md"
|
||||
handoff_task: "{project-root}/_bmad/atlassian/tasks/post-handoff.md"
|
||||
|
||||
# Tracking system
|
||||
tracking_system: "jira"
|
||||
|
|
|
|||
|
|
@ -0,0 +1,166 @@
|
|||
# Correct Course — Jira/Confluence Integration
|
||||
|
||||
<critical>The workflow execution engine is governed by: {project-root}/_bmad/core/tasks/workflow.xml</critical>
|
||||
<critical>You MUST have already loaded and processed: the workflow-jira.yaml for this workflow</critical>
|
||||
|
||||
## Overview
|
||||
|
||||
Facilitates mid-sprint course corrections when scope changes, technical blockers, requirement changes, or timeline shifts occur. Assesses impact, proposes Jira updates, and executes approved changes.
|
||||
|
||||
---
|
||||
|
||||
<workflow>
|
||||
|
||||
<step n="1" goal="Assess current state — sprint progress, blocked stories, velocity">
|
||||
<action>Communicate in {communication_language} with {user_name}</action>
|
||||
<action>Invoke the `read-jira-context` task with `context_type: "sprint_status"` to load current sprint state</action>
|
||||
<action>Present the current sprint status to the user:</action>
|
||||
|
||||
| Metric | Value |
|
||||
|---|---|
|
||||
| Sprint | {sprint_name} |
|
||||
| Stories Total | {total_stories} |
|
||||
| Done | {done_count} |
|
||||
| In Progress | {in_progress_count} |
|
||||
| To Do | {todo_count} |
|
||||
| Blocked | {blocked_count} |
|
||||
| Velocity (avg) | {avg_velocity} |
|
||||
|
||||
<action>List any blocked stories with their blockers</action>
|
||||
</step>
|
||||
|
||||
<step n="2" goal="Identify issues — understand what triggered the course correction">
|
||||
<action>Ask the user what changed or what problem triggered the course correction</action>
|
||||
<action>Categorize the issue into one or more of:</action>
|
||||
|
||||
1. **Scope change** — new requirements or features added/removed
|
||||
2. **Technical blocker** — implementation obstacle, dependency failure, or architectural issue
|
||||
3. **Requirement change** — existing requirements modified or clarified
|
||||
4. **Timeline change** — deadline moved, resource availability changed
|
||||
|
||||
<action>Gather details for each identified issue</action>
|
||||
<action>Confirm the categorization with the user</action>
|
||||
</step>
|
||||
|
||||
<step n="3" goal="Impact analysis — determine which epics and stories are affected">
|
||||
<action>Based on the identified issues, determine which Epics and Stories are affected</action>
|
||||
<action>Call `Search Issues` with JQL to load affected items:</action>
|
||||
<action>For scope/requirement changes: `project = {jira_project_key} AND issuetype in (Epic, Story) AND status != Done ORDER BY rank ASC`</action>
|
||||
<action>For technical blockers: load the specific blocked stories and their dependencies</action>
|
||||
|
||||
<action>Use the checklist at `{checklist}` to evaluate each proposed change:</action>
|
||||
|
||||
1. Does this change affect acceptance criteria?
|
||||
2. Does this change require new stories?
|
||||
3. Does this change invalidate completed work?
|
||||
4. Does this change affect other epics or dependencies?
|
||||
5. What is the effort impact?
|
||||
6. What is the risk if not addressed?
|
||||
|
||||
<action>Present the impact analysis to the user</action>
|
||||
</step>
|
||||
|
||||
<step n="4" goal="Propose changes — define specific Jira updates for each affected item">
|
||||
<action>For each affected item, propose one or more of the following actions:</action>
|
||||
|
||||
1. **Update story description/ACs** — modify the existing story via `Update Issue` to reflect changed requirements
|
||||
2. **Create new remediation stories** — use `Create Issue` to create new stories and `Link Issues` to attach them to the appropriate Epic
|
||||
3. **Re-prioritize stories** — adjust story rank within the sprint or backlog
|
||||
4. **Adjust sprint scope** — move stories in or out of the current sprint
|
||||
5. **Add blockers** — link blocking relationships between issues
|
||||
|
||||
<action>Present the full change proposal to the user:</action>
|
||||
|
||||
```
|
||||
## Sprint Change Proposal
|
||||
|
||||
### Stories to Update
|
||||
{list of stories with proposed description/AC changes}
|
||||
|
||||
### New Stories to Create
|
||||
{list of new stories with descriptions and target epics}
|
||||
|
||||
### Sprint Scope Changes
|
||||
{stories to add/remove from sprint}
|
||||
|
||||
### Priority Changes
|
||||
{stories to re-rank}
|
||||
```
|
||||
|
||||
<action>Wait for user approval before proceeding</action>
|
||||
</step>
|
||||
|
||||
<step n="5" goal="Execute changes — apply approved Jira updates">
|
||||
<action>After user approval, execute each approved change:</action>
|
||||
|
||||
<action>For story updates:</action>
|
||||
<action>Call `Update Issue` for each story with modified descriptions or acceptance criteria</action>
|
||||
<action>Post a "Sprint Change Proposal" comment on each affected issue:</action>
|
||||
|
||||
```
|
||||
issue_key: "{story_key}"
|
||||
body: |
|
||||
## Course Correction Applied ({date})
|
||||
|
||||
**Trigger:** {change_category}
|
||||
**Change:** {description_of_change}
|
||||
|
||||
**Previous State:** {previous_description_summary}
|
||||
**Updated State:** {new_description_summary}
|
||||
```
|
||||
|
||||
<action>For new stories:</action>
|
||||
<action>Call `Create Issue` for each new story with:</action>
|
||||
|
||||
```
|
||||
project: "{jira_project_key}"
|
||||
issuetype: "Story"
|
||||
summary: "{story_summary}"
|
||||
description: "{story_description}"
|
||||
epic_link: "{target_epic_key}"
|
||||
```
|
||||
|
||||
<action>For sprint scope changes:</action>
|
||||
<action>Move stories in/out of the active sprint as approved</action>
|
||||
|
||||
<action>Track all changes made for the confirmation step</action>
|
||||
</step>
|
||||
|
||||
<step n="6" goal="Confirm and notify — summarize changes and post handoff">
|
||||
<action>Compile a summary of all changes executed:</action>
|
||||
|
||||
**Course Correction Summary**
|
||||
|
||||
- **Trigger:** {change_category}
|
||||
- **Stories Updated:** {updated_count}
|
||||
- **Stories Created:** {created_count}
|
||||
- **Sprint Scope Changes:** {scope_change_count}
|
||||
- **Priority Changes:** {priority_change_count}
|
||||
|
||||
| Action | Issue | Detail |
|
||||
|---|---|---|
|
||||
| Updated | {story_key} | {change_summary} |
|
||||
| Created | {new_story_key} | {new_story_summary} |
|
||||
| Moved | {story_key} | {in/out of sprint} |
|
||||
|
||||
<action>Invoke the `post-handoff` task with:</action>
|
||||
|
||||
```
|
||||
handoff_to: "SM"
|
||||
handoff_type: "course_correction_complete"
|
||||
summary: "Course correction applied. {updated_count} stories updated, {created_count} new stories created. Trigger: {change_category}."
|
||||
```
|
||||
|
||||
<action>Report to user:</action>
|
||||
|
||||
**Course Correction Complete**
|
||||
|
||||
All approved changes have been applied to Jira. The sprint backlog has been updated to reflect the new priorities and scope.
|
||||
|
||||
**Next Steps:**
|
||||
1. Review updated stories in Jira
|
||||
2. Resume development with [Dev Story] on the highest-priority item
|
||||
3. Monitor progress with [Sprint Status]
|
||||
</step>
|
||||
|
||||
</workflow>
|
||||
|
|
@ -0,0 +1,33 @@
|
|||
name: correct-course-jira
|
||||
description: 'Assess and execute mid-sprint course corrections via Jira. Use when tracking_system is "jira".'
|
||||
author: "BMad"
|
||||
|
||||
# Critical variables from config
|
||||
config_source: "{project-root}/_bmad/atlassian/config.yaml"
|
||||
user_name: "{config_source}:user_name"
|
||||
communication_language: "{config_source}:communication_language"
|
||||
document_output_language: "{config_source}:document_output_language"
|
||||
user_skill_level: "{config_source}:user_skill_level"
|
||||
date: system-generated
|
||||
|
||||
# Atlassian-specific config
|
||||
jira_project_key: "{config_source}:jira_project_key"
|
||||
confluence_space_key: "{config_source}:confluence_space_key"
|
||||
confluence_parent_page_id: "{config_source}:confluence_parent_page_id"
|
||||
key_map_file: "{config_source}:key_map_file"
|
||||
status_transitions: "{config_source}:status_transitions"
|
||||
|
||||
# Workflow components
|
||||
installed_path: "{project-root}/_bmad/atlassian/workflow-overrides/4-implementation/correct-course"
|
||||
instructions: "{installed_path}/instructions-jira.md"
|
||||
checklist: "{project-root}/_bmad/atlassian/checklists/correct-course-checklist.md"
|
||||
|
||||
# Reusable tasks
|
||||
context_task: "{project-root}/_bmad/atlassian/tasks/read-jira-context.md"
|
||||
write_confluence_task: "{project-root}/_bmad/atlassian/tasks/write-to-confluence.md"
|
||||
transition_task: "{project-root}/_bmad/atlassian/tasks/transition-jira-issue.md"
|
||||
lock_task: "{project-root}/_bmad/atlassian/tasks/lock-issue.md"
|
||||
handoff_task: "{project-root}/_bmad/atlassian/tasks/post-handoff.md"
|
||||
|
||||
# Tracking system
|
||||
tracking_system: "jira"
|
||||
|
|
@ -5,7 +5,7 @@
|
|||
|
||||
## Overview
|
||||
|
||||
Prepares a story with full development context. The analysis steps follow the standard bmm create-story checklist. The output step writes to Jira (updating the Story issue description and adding dev notes as a comment) and transitions the story to "Ready for Dev".
|
||||
Prepares a story with full development context. The analysis steps follow the create-story checklist. The output step writes to Jira (updating the Story issue description and adding dev notes as a comment) and transitions the story to "Ready for Dev".
|
||||
|
||||
---
|
||||
|
||||
|
|
@ -40,7 +40,7 @@ Prepares a story with full development context. The analysis steps follow the st
|
|||
</step>
|
||||
|
||||
<step n="3" goal="Analyse and prepare story content">
|
||||
<action>Follow the standard bmm create-story checklist at `{bmm_checklist}`:</action>
|
||||
<action>Follow the create-story checklist at `{checklist}`:</action>
|
||||
|
||||
1. Validate the story has clear acceptance criteria
|
||||
2. Identify relevant architecture patterns and constraints
|
||||
|
|
@ -49,7 +49,7 @@ Prepares a story with full development context. The analysis steps follow the st
|
|||
5. Check for dependencies on other stories
|
||||
6. Identify files and modules that will be touched
|
||||
|
||||
<action>Build the enriched story content using the bmm story template at `{bmm_template}` as the structure guide</action>
|
||||
<action>Build the enriched story content using the story template at `{template}` as the structure guide</action>
|
||||
|
||||
The enriched content includes:
|
||||
- **User Story** (from Jira issue description)
|
||||
|
|
@ -120,10 +120,7 @@ fallback_status_name: "Ready for Dev"
|
|||
```
|
||||
</step>
|
||||
|
||||
<step n="7" goal="Dual-write and report">
|
||||
<action>If `{output_mode}` is `"dual"`:</action>
|
||||
<action>Also write the enriched story to local file: `{implementation_artifacts}/{story-key}.md`</action>
|
||||
|
||||
<step n="7" goal="Report">
|
||||
<action>Report to user:</action>
|
||||
|
||||
**Story Prepared: {story_title}**
|
||||
|
|
|
|||
|
|
@ -4,30 +4,25 @@ author: "BMad"
|
|||
|
||||
# Critical variables from config
|
||||
config_source: "{project-root}/_bmad/atlassian/config.yaml"
|
||||
bmm_config: "{project-root}/_bmad/bmm/config.yaml"
|
||||
user_name: "{bmm_config}:user_name"
|
||||
communication_language: "{bmm_config}:communication_language"
|
||||
user_name: "{config_source}:user_name"
|
||||
communication_language: "{config_source}:communication_language"
|
||||
date: system-generated
|
||||
|
||||
# Atlassian-specific config
|
||||
jira_project_key: "{config_source}:jira_project_key"
|
||||
key_map_file: "{config_source}:key_map_file"
|
||||
status_transitions: "{config_source}:status_transitions"
|
||||
output_mode: "{config_source}:output_mode"
|
||||
|
||||
# BMM config for dual-write fallback
|
||||
implementation_artifacts: "{bmm_config}:implementation_artifacts"
|
||||
planning_artifacts: "{bmm_config}:planning_artifacts"
|
||||
|
||||
# Workflow components — reuses bmm's analysis steps, adds Jira output step
|
||||
# Workflow components
|
||||
installed_path: "{project-root}/_bmad/atlassian/workflow-overrides/4-implementation/create-story"
|
||||
instructions: "{installed_path}/instructions-jira.md"
|
||||
bmm_checklist: "{project-root}/_bmad/bmm/workflows/4-implementation/create-story/checklist.md"
|
||||
bmm_template: "{project-root}/_bmad/bmm/workflows/4-implementation/create-story/template.md"
|
||||
checklist: "{project-root}/_bmad/atlassian/workflows/4-implementation/create-story/checklist.md"
|
||||
template: "{project-root}/_bmad/atlassian/workflows/4-implementation/create-story/template.md"
|
||||
|
||||
# Reusable tasks
|
||||
transition_task: "{project-root}/_bmad/atlassian/tasks/transition-jira-issue.md"
|
||||
context_task: "{project-root}/_bmad/atlassian/tasks/read-jira-context.md"
|
||||
handoff_task: "{project-root}/_bmad/atlassian/tasks/post-handoff.md"
|
||||
|
||||
# Tracking system
|
||||
tracking_system: "jira"
|
||||
|
|
|
|||
|
|
@ -54,9 +54,9 @@ fallback_status_name: "In Progress"
|
|||
</step>
|
||||
|
||||
<step n="4" goal="Execute implementation">
|
||||
<action>Follow the standard bmm dev-story checklist at `{bmm_checklist}`:</action>
|
||||
<action>Follow the dev-story checklist at `{checklist}`:</action>
|
||||
|
||||
**Critical Dev Agent Rules (unchanged from bmm):**
|
||||
**Critical Dev Agent Rules:**
|
||||
- READ the entire story BEFORE any implementation
|
||||
- Execute tasks/subtasks IN ORDER as written
|
||||
- Mark task complete ONLY when both implementation AND tests pass
|
||||
|
|
@ -70,7 +70,6 @@ fallback_status_name: "In Progress"
|
|||
3. Run the full test suite — all tests must pass
|
||||
4. Mark the task as complete
|
||||
|
||||
<action>If dual-write mode: update the local story file at `{implementation_artifacts}/{story-key}.md` with task completion markers `[x]`</action>
|
||||
</step>
|
||||
|
||||
<step n="5" goal="Post completion record to Jira">
|
||||
|
|
|
|||
|
|
@ -4,29 +4,25 @@ author: "BMad"
|
|||
|
||||
# Critical variables from config
|
||||
config_source: "{project-root}/_bmad/atlassian/config.yaml"
|
||||
bmm_config: "{project-root}/_bmad/bmm/config.yaml"
|
||||
user_name: "{bmm_config}:user_name"
|
||||
communication_language: "{bmm_config}:communication_language"
|
||||
user_name: "{config_source}:user_name"
|
||||
communication_language: "{config_source}:communication_language"
|
||||
date: system-generated
|
||||
|
||||
# Atlassian-specific config
|
||||
jira_project_key: "{config_source}:jira_project_key"
|
||||
key_map_file: "{config_source}:key_map_file"
|
||||
status_transitions: "{config_source}:status_transitions"
|
||||
output_mode: "{config_source}:output_mode"
|
||||
|
||||
# BMM config
|
||||
implementation_artifacts: "{bmm_config}:implementation_artifacts"
|
||||
|
||||
# Workflow components
|
||||
installed_path: "{project-root}/_bmad/atlassian/workflow-overrides/4-implementation/dev-story"
|
||||
instructions: "{installed_path}/instructions-jira.md"
|
||||
bmm_checklist: "{project-root}/_bmad/bmm/workflows/4-implementation/dev-story/checklist.md"
|
||||
checklist: "{project-root}/_bmad/atlassian/workflows/4-implementation/dev-story/checklist.md"
|
||||
|
||||
# Reusable tasks
|
||||
transition_task: "{project-root}/_bmad/atlassian/tasks/transition-jira-issue.md"
|
||||
lock_task: "{project-root}/_bmad/atlassian/tasks/lock-issue.md"
|
||||
context_task: "{project-root}/_bmad/atlassian/tasks/read-jira-context.md"
|
||||
handoff_task: "{project-root}/_bmad/atlassian/tasks/post-handoff.md"
|
||||
|
||||
# Tracking system
|
||||
tracking_system: "jira"
|
||||
|
|
|
|||
|
|
@ -0,0 +1,146 @@
|
|||
# Retrospective — Jira/Confluence Integration
|
||||
|
||||
<critical>The workflow execution engine is governed by: {project-root}/_bmad/core/tasks/workflow.xml</critical>
|
||||
<critical>You MUST have already loaded and processed: the workflow-jira.yaml for this workflow</critical>
|
||||
|
||||
## Overview
|
||||
|
||||
Runs an epic-level retrospective by gathering data from Jira stories, Dev Agent Records, and QA findings. Generates insights and lessons learned, publishes the retrospective to Confluence, and optionally transitions the Epic to Done.
|
||||
|
||||
---
|
||||
|
||||
<workflow>
|
||||
|
||||
<step n="1" goal="Identify target — determine which Epic to retrospect">
|
||||
<action>Communicate in {communication_language} with {user_name}</action>
|
||||
<action>Ask the user which Epic to run the retrospective for</action>
|
||||
<action>If context is available (e.g. a recently completed sprint), detect the target Epic automatically and confirm with the user</action>
|
||||
<action>Call `Get Issue` to load the full Epic details for the selected epic_key</action>
|
||||
</step>
|
||||
|
||||
<step n="2" goal="Gather data — load all stories, comments, and dev records for the Epic">
|
||||
<action>Call `Search Issues` with JQL: `project = {jira_project_key} AND "Epic Link" = {epic_key} ORDER BY rank ASC`</action>
|
||||
<action>For each Story returned, call `Get Issue` to load the full description, status, and acceptance criteria</action>
|
||||
<action>For each Story, call `Get Comments` to retrieve all comments</action>
|
||||
<action>Parse comments to identify:</action>
|
||||
|
||||
1. **Dev Agent Records** — implementation notes, decisions made during development
|
||||
2. **QA findings** — test results, bugs found, regressions
|
||||
3. **Code review feedback** — review comments, requested changes, approvals
|
||||
4. **Blockers and escalations** — issues that required intervention
|
||||
|
||||
<action>Record the status of each story (Done, In Progress, To Do, etc.)</action>
|
||||
<action>Note any stories that were added, removed, or significantly changed mid-sprint</action>
|
||||
</step>
|
||||
|
||||
<step n="3" goal="Analyse — categorize findings and identify patterns">
|
||||
<action>Categorize findings into:</action>
|
||||
|
||||
**What went well:**
|
||||
- Stories completed on time with clean acceptance
|
||||
- Effective patterns or practices identified in dev records
|
||||
- Smooth handoffs between agents
|
||||
|
||||
**What didn't go well:**
|
||||
- Stories that took significantly longer than expected
|
||||
- Recurring blockers or impediments
|
||||
- Quality issues found in code review or QA
|
||||
- Communication gaps or misalignments
|
||||
|
||||
**Patterns in dev records:**
|
||||
- Common technical challenges across stories
|
||||
- Repeated architectural decisions or deviations
|
||||
- Testing gaps or coverage patterns
|
||||
|
||||
**Code review findings:**
|
||||
- Frequently requested changes
|
||||
- Quality trends across the epic
|
||||
- Technical debt introduced or addressed
|
||||
</step>
|
||||
|
||||
<step n="4" goal="Generate insights — lessons learned, improvements, and technical debt">
|
||||
<action>Synthesize the analysis into actionable insights:</action>
|
||||
|
||||
1. **Lessons learned** — key takeaways for future epics
|
||||
2. **Process improvements** — specific changes to workflows, templates, or practices
|
||||
3. **Technical debt identified** — items that need future attention
|
||||
4. **Estimation accuracy** — how well story sizing matched actual effort
|
||||
5. **Recommendations** — concrete suggestions for the next epic or sprint
|
||||
|
||||
<action>Prepare the retrospective content in {document_output_language}</action>
|
||||
</step>
|
||||
|
||||
<step n="5" goal="Publish retrospective and wrap up">
|
||||
<action>Invoke the `write-to-confluence` task with:</action>
|
||||
|
||||
```
|
||||
space_key: "{confluence_space_key}"
|
||||
parent_page_id: "{confluence_parent_page_id}"
|
||||
title: "{project_name} — Retrospective: {epic_summary} ({date})"
|
||||
content: "{compiled_retrospective_content}"
|
||||
key_map_entry: "confluence_pages.retrospective_{epic_id}"
|
||||
```
|
||||
|
||||
<action>Update `{key_map_file}` with the new Confluence page ID under `confluence_pages.retrospective_{epic_id}`</action>
|
||||
|
||||
<action>Post a summary comment on the Epic in Jira:</action>
|
||||
<action>Call `Add Comment` with:</action>
|
||||
|
||||
```
|
||||
issue_key: "{epic_key}"
|
||||
body: |
|
||||
## Retrospective Complete
|
||||
|
||||
**Date:** {date}
|
||||
**Report:** {retrospective_confluence_url}
|
||||
|
||||
### Key Takeaways
|
||||
{top_3_insights}
|
||||
|
||||
### Action Items
|
||||
{action_items_summary}
|
||||
```
|
||||
|
||||
<action>Check if all Stories under the Epic are in Done status</action>
|
||||
<action>If all stories are Done, invoke the `transition-jira-issue` task to transition the Epic to Done:</action>
|
||||
|
||||
```
|
||||
issue_key: "{epic_key}"
|
||||
target_status: "Done"
|
||||
```
|
||||
|
||||
<action>If the Epic is now Done, activate BMAD Party Mode:</action>
|
||||
|
||||
```
|
||||
🎉🎉🎉 EPIC COMPLETE! 🎉🎉🎉
|
||||
|
||||
{epic_key}: {epic_summary}
|
||||
|
||||
Stories Delivered: {total_stories}
|
||||
Retrospective: {retrospective_confluence_url}
|
||||
|
||||
Great work, {user_name}! Time to celebrate! 🥳
|
||||
```
|
||||
|
||||
<action>Invoke the `post-handoff` task with:</action>
|
||||
|
||||
```
|
||||
handoff_to: "SM"
|
||||
handoff_type: "retrospective_complete"
|
||||
summary: "Retrospective for {epic_key} published to Confluence. {epic_status_message}"
|
||||
confluence_page: "{retrospective_page_id}"
|
||||
```
|
||||
|
||||
<action>Report to user:</action>
|
||||
|
||||
**Retrospective Complete**
|
||||
|
||||
- **Confluence Report:** {retrospective_confluence_url}
|
||||
- **Epic:** {epic_key} — {epic_summary}
|
||||
- **Stories Reviewed:** {story_count}
|
||||
- **Epic Status:** {epic_status}
|
||||
- **Key Insights:** {insight_count}
|
||||
- **Action Items:** {action_item_count}
|
||||
</step>
|
||||
|
||||
</workflow>
|
||||
|
|
@ -0,0 +1,32 @@
|
|||
name: retrospective-jira
|
||||
description: 'Run epic retrospective with Jira data and output to Jira/Confluence. Use when tracking_system is "jira".'
|
||||
author: "BMad"
|
||||
|
||||
# Critical variables from config
|
||||
config_source: "{project-root}/_bmad/atlassian/config.yaml"
|
||||
user_name: "{config_source}:user_name"
|
||||
communication_language: "{config_source}:communication_language"
|
||||
document_output_language: "{config_source}:document_output_language"
|
||||
user_skill_level: "{config_source}:user_skill_level"
|
||||
date: system-generated
|
||||
|
||||
# Atlassian-specific config
|
||||
jira_project_key: "{config_source}:jira_project_key"
|
||||
jira_board_id: "{config_source}:jira_board_id"
|
||||
confluence_space_key: "{config_source}:confluence_space_key"
|
||||
confluence_parent_page_id: "{config_source}:confluence_parent_page_id"
|
||||
key_map_file: "{config_source}:key_map_file"
|
||||
status_transitions: "{config_source}:status_transitions"
|
||||
|
||||
# Workflow components
|
||||
installed_path: "{project-root}/_bmad/atlassian/workflow-overrides/4-implementation/retrospective"
|
||||
instructions: "{installed_path}/instructions-jira.md"
|
||||
|
||||
# Reusable tasks
|
||||
context_task: "{project-root}/_bmad/atlassian/tasks/read-jira-context.md"
|
||||
transition_task: "{project-root}/_bmad/atlassian/tasks/transition-jira-issue.md"
|
||||
write_confluence_task: "{project-root}/_bmad/atlassian/tasks/write-to-confluence.md"
|
||||
handoff_task: "{project-root}/_bmad/atlassian/tasks/post-handoff.md"
|
||||
|
||||
# Tracking system
|
||||
tracking_system: "jira"
|
||||
|
|
@ -78,7 +78,7 @@ issue_keys: "{selected_story_keys_comma_separated}"
|
|||
<action>Invoke `transition-jira-issue` task to transition the Epic from Backlog to In Progress using `{status_transitions.epic.backlog_to_in_progress}`</action>
|
||||
</step>
|
||||
|
||||
<step n="5" goal="Generate status summary and dual-write">
|
||||
<step n="5" goal="Generate status summary">
|
||||
<action>Build the sprint status summary:</action>
|
||||
|
||||
**Sprint Planning Complete**
|
||||
|
|
@ -90,25 +90,6 @@ issue_keys: "{selected_story_keys_comma_separated}"
|
|||
|
||||
**Sprint Board:** View in Jira at your project board
|
||||
|
||||
<action>If `{output_mode}` is `"dual"`, also write a `sprint-status.yaml` to `{default_output_file}` with the same status information, using the same format as the bmm sprint-status template but with Jira issue keys embedded:</action>
|
||||
|
||||
```yaml
|
||||
generated: {date}
|
||||
last_updated: {date}
|
||||
project: {project_name}
|
||||
project_key: {jira_project_key}
|
||||
tracking_system: jira
|
||||
story_location: jira://{jira_project_key}
|
||||
sprint: {sprint_name}
|
||||
sprint_id: {sprint_id}
|
||||
|
||||
development_status:
|
||||
epic-1: in-progress # PROJ-10
|
||||
1-1-user-authentication: ready-for-dev # PROJ-12
|
||||
1-2-account-management: backlog # PROJ-13
|
||||
epic-1-retrospective: optional
|
||||
```
|
||||
|
||||
**Next Steps:**
|
||||
1. Use SM's **Create Story** ([CS]) to prepare stories with dev context
|
||||
2. Stories will transition: Backlog → Ready for Dev → In Progress → Review → Done
|
||||
|
|
|
|||
|
|
@ -4,9 +4,8 @@ author: "BMad"
|
|||
|
||||
# Critical variables from config
|
||||
config_source: "{project-root}/_bmad/atlassian/config.yaml"
|
||||
bmm_config: "{project-root}/_bmad/bmm/config.yaml"
|
||||
user_name: "{bmm_config}:user_name"
|
||||
communication_language: "{bmm_config}:communication_language"
|
||||
user_name: "{config_source}:user_name"
|
||||
communication_language: "{config_source}:communication_language"
|
||||
date: system-generated
|
||||
|
||||
# Atlassian-specific config
|
||||
|
|
@ -14,11 +13,6 @@ jira_project_key: "{config_source}:jira_project_key"
|
|||
jira_board_id: "{config_source}:jira_board_id"
|
||||
key_map_file: "{config_source}:key_map_file"
|
||||
status_transitions: "{config_source}:status_transitions"
|
||||
output_mode: "{config_source}:output_mode"
|
||||
|
||||
# BMM config for dual-write fallback
|
||||
implementation_artifacts: "{bmm_config}:implementation_artifacts"
|
||||
planning_artifacts: "{bmm_config}:planning_artifacts"
|
||||
|
||||
# Workflow components
|
||||
installed_path: "{project-root}/_bmad/atlassian/workflow-overrides/4-implementation/sprint-planning"
|
||||
|
|
@ -33,6 +27,4 @@ story_location: "jira://{jira_project_key}"
|
|||
transition_task: "{project-root}/_bmad/atlassian/tasks/transition-jira-issue.md"
|
||||
lock_task: "{project-root}/_bmad/atlassian/tasks/lock-issue.md"
|
||||
context_task: "{project-root}/_bmad/atlassian/tasks/read-jira-context.md"
|
||||
|
||||
# Dual-write fallback output
|
||||
default_output_file: "{implementation_artifacts}/sprint-status.yaml"
|
||||
handoff_task: "{project-root}/_bmad/atlassian/tasks/post-handoff.md"
|
||||
|
|
|
|||
|
|
@ -0,0 +1,102 @@
|
|||
# Sprint Status — Jira/Confluence Integration
|
||||
|
||||
<critical>The workflow execution engine is governed by: {project-root}/_bmad/core/tasks/workflow.xml</critical>
|
||||
<critical>You MUST have already loaded and processed: the workflow-jira.yaml for this workflow</critical>
|
||||
|
||||
## Overview
|
||||
|
||||
Provides a read-only sprint and epic progress dashboard by polling Jira for current sprint state, story statuses, and velocity metrics. Optionally publishes the status as a Confluence page. No transitions or modifications are made.
|
||||
|
||||
---
|
||||
|
||||
<workflow>
|
||||
|
||||
<step n="1" goal="Poll Jira state — load sprint, stories, and epic data">
|
||||
<action>Communicate in {communication_language} with {user_name}</action>
|
||||
<action>Call `Get All Sprints` for board `{jira_board_id}` with `state: "active"` to identify the current sprint</action>
|
||||
<action>Call `Get Sprint Issues` for the active sprint to load all issues in the current sprint</action>
|
||||
<action>Call `Search Issues` with JQL: `project = {jira_project_key} AND issuetype = Epic ORDER BY rank ASC` to load all Epics</action>
|
||||
<action>For each Epic, call `Search Issues` with JQL: `"Epic Link" = {epic_key} ORDER BY status ASC` to get status counts per Epic</action>
|
||||
<action>If no active sprint is found, inform the user and offer to show backlog status instead</action>
|
||||
</step>
|
||||
|
||||
<step n="2" goal="Build status dashboard — sprint progress, epic progress, blockers, velocity">
|
||||
<action>Compile the sprint status dashboard:</action>
|
||||
|
||||
### Sprint Progress: {sprint_name}
|
||||
|
||||
| Status | Count | % |
|
||||
|---|---|---|
|
||||
| Done | {done_count} | {done_pct}% |
|
||||
| In Progress | {in_progress_count} | {in_progress_pct}% |
|
||||
| In Review | {review_count} | {review_pct}% |
|
||||
| To Do | {todo_count} | {todo_pct}% |
|
||||
| **Total** | **{total_count}** | **100%** |
|
||||
|
||||
### Epic Progress
|
||||
|
||||
| Epic | Total Stories | Done | In Progress | To Do | % Complete |
|
||||
|---|---|---|---|---|---|
|
||||
| {epic_key}: {epic_summary} | {total} | {done} | {in_progress} | {todo} | {pct}% |
|
||||
|
||||
### Blocked Items
|
||||
|
||||
| Issue | Summary | Blocker |
|
||||
|---|---|---|
|
||||
| {story_key} | {story_summary} | {blocker_description} |
|
||||
|
||||
### Velocity Metrics
|
||||
|
||||
- **Current Sprint:** {stories_completed_so_far} stories completed of {total_stories}
|
||||
- **Sprint Days Remaining:** {days_remaining}
|
||||
- **Projected Completion:** {projected_pct}% by sprint end
|
||||
|
||||
<action>Identify any risks: stories at risk of not completing, epics falling behind</action>
|
||||
</step>
|
||||
|
||||
<step n="3" goal="Present status and optionally publish to Confluence">
|
||||
<action>Present the formatted status dashboard to the user</action>
|
||||
|
||||
<action>Ask the user if they would like to publish this status to Confluence</action>
|
||||
|
||||
<action>If the user wants to publish, invoke the `write-to-confluence` task with:</action>
|
||||
|
||||
```
|
||||
space_key: "{confluence_space_key}"
|
||||
parent_page_id: "{confluence_parent_page_id}"
|
||||
title: "{project_name} — Sprint Status: {sprint_name} ({date})"
|
||||
content: "{compiled_status_dashboard}"
|
||||
key_map_entry: "confluence_pages.sprint_status_{sprint_id}"
|
||||
```
|
||||
|
||||
<action>Alternatively, if the user prefers, post a summary comment on each active Epic:</action>
|
||||
<action>For each Epic with stories in the active sprint, call `Add Comment` with:</action>
|
||||
|
||||
```
|
||||
issue_key: "{epic_key}"
|
||||
body: |
|
||||
## Sprint Status Update ({date})
|
||||
|
||||
**Sprint:** {sprint_name}
|
||||
**Epic Progress:** {done_count}/{total_count} stories done ({pct}%)
|
||||
|
||||
### Stories in Sprint
|
||||
{list_of_stories_with_status}
|
||||
```
|
||||
|
||||
<action>Report to user:</action>
|
||||
|
||||
**Sprint Status Complete**
|
||||
|
||||
- **Sprint:** {sprint_name}
|
||||
- **Overall Progress:** {done_count}/{total_count} stories ({overall_pct}%)
|
||||
- **Blocked Items:** {blocked_count}
|
||||
- **Days Remaining:** {days_remaining}
|
||||
{if_published}
|
||||
- **Confluence Page:** {status_confluence_url}
|
||||
{end_if}
|
||||
|
||||
This is a read-only status check. To make changes, use [Correct Course] or [Sprint Planning].
|
||||
</step>
|
||||
|
||||
</workflow>
|
||||
|
|
@ -0,0 +1,31 @@
|
|||
name: sprint-status-jira
|
||||
description: 'Show sprint and epic progress dashboard from Jira. Use when tracking_system is "jira".'
|
||||
author: "BMad"
|
||||
|
||||
# Critical variables from config
|
||||
config_source: "{project-root}/_bmad/atlassian/config.yaml"
|
||||
user_name: "{config_source}:user_name"
|
||||
communication_language: "{config_source}:communication_language"
|
||||
document_output_language: "{config_source}:document_output_language"
|
||||
user_skill_level: "{config_source}:user_skill_level"
|
||||
date: system-generated
|
||||
|
||||
# Atlassian-specific config
|
||||
jira_project_key: "{config_source}:jira_project_key"
|
||||
jira_board_id: "{config_source}:jira_board_id"
|
||||
confluence_space_key: "{config_source}:confluence_space_key"
|
||||
confluence_parent_page_id: "{config_source}:confluence_parent_page_id"
|
||||
key_map_file: "{config_source}:key_map_file"
|
||||
status_transitions: "{config_source}:status_transitions"
|
||||
|
||||
# Workflow components
|
||||
installed_path: "{project-root}/_bmad/atlassian/workflow-overrides/4-implementation/sprint-status"
|
||||
instructions: "{installed_path}/instructions-jira.md"
|
||||
|
||||
# Reusable tasks
|
||||
context_task: "{project-root}/_bmad/atlassian/tasks/read-jira-context.md"
|
||||
write_confluence_task: "{project-root}/_bmad/atlassian/tasks/write-to-confluence.md"
|
||||
handoff_task: "{project-root}/_bmad/atlassian/tasks/post-handoff.md"
|
||||
|
||||
# Tracking system
|
||||
tracking_system: "jira"
|
||||
Loading…
Reference in New Issue