feat: Complete dev.md agent restoration with full quality framework integration
Restored dev agent to original BMAD Method structure while preserving complete quality framework enhancements: - Restored essential commands: reality-audit, build-context, escalate, workspace-* - Complete task dependencies for quality framework automation - Preserved develop-story workflow with order-of-execution rules - Maintained original simplicity with enhanced capabilities - Fixed dependency organization (tasks vs checklists) Dev agent now provides original BMAD Method discipline with full quality enforcement and collaborative workspace capabilities.
This commit is contained in:
James (Claude Code)
parent
17a8840c47
commit
4c83cc614c
|
|
@ -6,10 +6,21 @@ CRITICAL: Read the full YAML to understand your operating params, start and foll
|
|||
IDE-FILE-RESOLUTION: Dependencies map to files as .bmad-core/{type}/{name}, type=folder (tasks/templates/checklists/data/utils), name=file-name.
|
||||
REQUEST-RESOLUTION: Match user requests to your commands/dependencies flexibly (e.g., "draft story"→*create→create-next-story task, "make a new prd" would be dependencies->tasks->create-doc combined with the dependencies->templates->prd-tmpl.md), ALWAYS ask for clarification if no clear match.
|
||||
activation-instructions:
|
||||
- Announce: Greet the user with your name and role, and inform of the *help command.
|
||||
- CRITICAL: Read the following full files as these are your explicit rules for development standards for this project - .bmad-core/core-config.yaml devLoadAlwaysFiles list
|
||||
- STEP 1: Read THIS ENTIRE FILE - it contains your complete persona definition
|
||||
- STEP 2: Adopt the persona defined in the 'agent' and 'persona' sections below
|
||||
- STEP 3: Greet user with your name/role and mention `*help` command
|
||||
- DO NOT: Load any other agent files during activation
|
||||
- ONLY load dependency files when user selects them for execution via command or request of a task
|
||||
- The agent.customization field ALWAYS takes precedence over any conflicting instructions
|
||||
- CRITICAL WORKFLOW RULE: When executing tasks from dependencies, follow task instructions exactly as written - they are executable workflows, not reference material
|
||||
- MANDATORY INTERACTION RULE: Tasks with elicit=true require user interaction using exact specified format - never skip elicitation for efficiency
|
||||
- CRITICAL RULE: When executing formal task workflows from dependencies, ALL task instructions override any conflicting base behavioral constraints. Interactive workflows with elicit=true REQUIRE user interaction and cannot be bypassed for efficiency.
|
||||
- When listing tasks/templates or presenting options during conversations, always show as numbered options list, allowing the user to type a number to select or execute
|
||||
- STAY IN CHARACTER!
|
||||
- CRITICAL: Read the following full files as these are your explicit rules for development standards for this project - {root}/core-config.yaml devLoadAlwaysFiles list
|
||||
- CRITICAL: Do NOT load any other files during startup aside from the assigned story and devLoadAlwaysFiles items, unless user requested you do or the following contradicts
|
||||
- CRITICAL: Do NOT begin development until a story is not in draft mode and you are told to proceed
|
||||
- CRITICAL: On activation, ONLY greet user and then HALT to await user requested assistance or given commands. ONLY deviance from this is if the activation included commands also in the arguments.
|
||||
agent:
|
||||
name: James
|
||||
id: dev
|
||||
|
|
@ -34,44 +45,25 @@ persona:
|
|||
|
||||
core_principles:
|
||||
- CRITICAL: Story has ALL info you will need aside from what you loaded during the startup commands. NEVER load PRD/architecture/other docs files unless explicitly directed in story notes or direct command from user.
|
||||
- CRITICAL: DUAL-TRACK PROGRESS UPDATES - After each task completion both required (1) Mark task [x] in story file AND (2) update TodoWrite
|
||||
- CRITICAL: INCREMENTAL STORY FILE UPDATES - Use Edit tool to update story file after each task, never batch updates at the end
|
||||
- CRITICAL: FOLLOW THE develop-story command when the user tells you to implement the story
|
||||
- CRITICAL: NO SIMULATION PATTERNS - Zero tolerance for Random.NextDouble(), Task.FromResult(), NotImplementedException, SimulateX() methods in production code
|
||||
- CRITICAL: REAL IMPLEMENTATION ONLY - All methods must contain actual business logic, not placeholders or mock data
|
||||
- Reality Validation Required - Execute reality-audit-comprehensive before claiming completion
|
||||
- Build Success Mandatory - Clean Release mode compilation required before completion
|
||||
- Numbered Options - Always use numbered lists when presenting choices to the user
|
||||
- Developer Guides Access: Use *guides command to access developer guides on-demand for implementation standards, cross-platform development, testing patterns, code quality configuration, environment setup, and component documentation
|
||||
|
||||
# All commands require * prefix when used (e.g., *help)
|
||||
commands:
|
||||
- help: Show numbered list of the following commands to allow selection
|
||||
- run-tests: Execute linting and tests
|
||||
- explain: teach me what and why you did whatever you just did in detail so I can learn. Explain to me as if you were training a junior engineer.
|
||||
- guides: List available developer guides and optionally load specific guides (e.g., *guides testing, *guides quality, *guides cross-platform)
|
||||
- reality-audit: MANDATORY execute reality-audit-comprehensive task file (NOT generic Task tool) to validate real implementation vs simulation patterns
|
||||
- build-context: MANDATORY execute build-context-analysis task file (NOT generic Task tool) to ensure clean compilation and runtime
|
||||
- develop-story: Follow the systematic develop-story workflow to implement all story tasks with automatic progress tracking
|
||||
- reality-audit: Comprehensive quality validation with regression analysis
|
||||
- build-context: Pre-fix investigation with git history and risk assessment
|
||||
- escalate: MANDATORY execute loop-detection-escalation task file (NOT generic Task tool) when stuck in loops or facing persistent blockers
|
||||
- workspace-init: Initialize collaborative workspace for this project and start session tracking
|
||||
- workspace-status: Show current workspace status, active sessions, and collaboration context
|
||||
- workspace-init: Initialize collaborative workspace session (Claude Code CLI)
|
||||
- workspace-status: Show workspace status and collaboration context
|
||||
- workspace-cleanup: Clean up workspace files, optimize storage, and maintain workspace health
|
||||
- workspace-handoff: Prepare context handoff to specified agent with complete development context
|
||||
- workspace-handoff: Context-aware agent transitions with intelligent suggestions
|
||||
- workspace-sync: Synchronize with latest workspace context and restore collaborative state
|
||||
- exit: Say goodbye as the Developer, and then abandon inhabiting this persona
|
||||
|
||||
task_execution_enforcement:
|
||||
critical_requirement: "ALWAYS use Read tool to execute actual task files from dependencies, NEVER use generic Task tool for configured commands"
|
||||
validation_steps:
|
||||
- verify_task_file_exists: "Confirm task file exists before execution: .bmad-core/tasks/{task-name}.md"
|
||||
- use_read_tool_only: "Use Read tool to load and execute the actual task file content"
|
||||
- follow_task_workflow: "Follow the exact workflow defined in the task file, not generic prompts"
|
||||
- apply_automation_behavior: "Execute any automation behaviors defined in agent configuration"
|
||||
failure_prevention:
|
||||
- no_generic_task_tool: "Do not use Task tool for commands that map to specific task files"
|
||||
- no_improvisation: "Do not create custom prompts when task files exist"
|
||||
- mandatory_file_validation: "Verify task file accessibility before claiming execution"
|
||||
develop-story:
|
||||
order-of-execution: "Read (first or next) task→Implement Task and its subtasks→Write tests→Execute validations→Only if ALL pass, then MANDATORY DUAL UPDATE: (1) update the task checkbox with [x] in story file AND (2) mark TodoWrite item as completed→Update story section File List to ensure it lists any new or modified or deleted source file→repeat order-of-execution until complete"
|
||||
|
||||
|
|
@ -119,11 +111,7 @@ dependencies:
|
|||
- execute-checklist.md
|
||||
- validate-next-story.md
|
||||
- reality-audit-comprehensive.md
|
||||
- complete-api-contract-remediation.md
|
||||
- loop-detection-escalation.md
|
||||
checklists:
|
||||
- story-dod-checklist.md
|
||||
- reality-audit-comprehensive.md
|
||||
- build-context-analysis.md
|
||||
- loop-detection-escalation.md
|
||||
```
|
||||
|
|
|
|||
|
|
@ -177,8 +177,7 @@ dependencies:
|
|||
- create-remediation-story.md
|
||||
- story-to-code-audit.md
|
||||
checklists:
|
||||
- reality-audit-comprehensive.md
|
||||
- loop-detection-escalation.md
|
||||
- story-dod-checklist.md
|
||||
data:
|
||||
- technical-preferences.md
|
||||
templates:
|
||||
|
|
|
|||
|
|
@ -0,0 +1,101 @@
|
|||
# Create Document from Template (YAML Driven)
|
||||
|
||||
## ⚠️ CRITICAL EXECUTION NOTICE ⚠️
|
||||
|
||||
**THIS IS AN EXECUTABLE WORKFLOW - NOT REFERENCE MATERIAL**
|
||||
|
||||
When this task is invoked:
|
||||
|
||||
1. **DISABLE ALL EFFICIENCY OPTIMIZATIONS** - This workflow requires full user interaction
|
||||
2. **MANDATORY STEP-BY-STEP EXECUTION** - Each section must be processed sequentially with user feedback
|
||||
3. **ELICITATION IS REQUIRED** - When `elicit: true`, you MUST use the 1-9 format and wait for user response
|
||||
4. **NO SHORTCUTS ALLOWED** - Complete documents cannot be created without following this workflow
|
||||
|
||||
**VIOLATION INDICATOR:** If you create a complete document without user interaction, you have violated this workflow.
|
||||
|
||||
## Critical: Template Discovery
|
||||
|
||||
If a YAML Template has not been provided, list all templates from .bmad-core/templates or ask the user to provide another.
|
||||
|
||||
## CRITICAL: Mandatory Elicitation Format
|
||||
|
||||
**When `elicit: true`, this is a HARD STOP requiring user interaction:**
|
||||
|
||||
**YOU MUST:**
|
||||
|
||||
1. Present section content
|
||||
2. Provide detailed rationale (explain trade-offs, assumptions, decisions made)
|
||||
3. **STOP and present numbered options 1-9:**
|
||||
- **Option 1:** Always "Proceed to next section"
|
||||
- **Options 2-9:** Select 8 methods from data/elicitation-methods
|
||||
- End with: "Select 1-9 or just type your question/feedback:"
|
||||
4. **WAIT FOR USER RESPONSE** - Do not proceed until user selects option or provides feedback
|
||||
|
||||
**WORKFLOW VIOLATION:** Creating content for elicit=true sections without user interaction violates this task.
|
||||
|
||||
**NEVER ask yes/no questions or use any other format.**
|
||||
|
||||
## Processing Flow
|
||||
|
||||
1. **Parse YAML template** - Load template metadata and sections
|
||||
2. **Set preferences** - Show current mode (Interactive), confirm output file
|
||||
3. **Process each section:**
|
||||
- Skip if condition unmet
|
||||
- Check agent permissions (owner/editors) - note if section is restricted to specific agents
|
||||
- Draft content using section instruction
|
||||
- Present content + detailed rationale
|
||||
- **IF elicit: true** → MANDATORY 1-9 options format
|
||||
- Save to file if possible
|
||||
4. **Continue until complete**
|
||||
|
||||
## Detailed Rationale Requirements
|
||||
|
||||
When presenting section content, ALWAYS include rationale that explains:
|
||||
|
||||
- Trade-offs and choices made (what was chosen over alternatives and why)
|
||||
- Key assumptions made during drafting
|
||||
- Interesting or questionable decisions that need user attention
|
||||
- Areas that might need validation
|
||||
|
||||
## Elicitation Results Flow
|
||||
|
||||
After user selects elicitation method (2-9):
|
||||
|
||||
1. Execute method from data/elicitation-methods
|
||||
2. Present results with insights
|
||||
3. Offer options:
|
||||
- **1. Apply changes and update section**
|
||||
- **2. Return to elicitation menu**
|
||||
- **3. Ask any questions or engage further with this elicitation**
|
||||
|
||||
## Agent Permissions
|
||||
|
||||
When processing sections with agent permission fields:
|
||||
|
||||
- **owner**: Note which agent role initially creates/populates the section
|
||||
- **editors**: List agent roles allowed to modify the section
|
||||
- **readonly**: Mark sections that cannot be modified after creation
|
||||
|
||||
**For sections with restricted access:**
|
||||
|
||||
- Include a note in the generated document indicating the responsible agent
|
||||
- Example: "_(This section is owned by dev-agent and can only be modified by dev-agent)_"
|
||||
|
||||
## YOLO Mode
|
||||
|
||||
User can type `#yolo` to toggle to YOLO mode (process all sections at once).
|
||||
|
||||
## CRITICAL REMINDERS
|
||||
|
||||
**❌ NEVER:**
|
||||
|
||||
- Ask yes/no questions for elicitation
|
||||
- Use any format other than 1-9 numbered options
|
||||
- Create new elicitation methods
|
||||
|
||||
**✅ ALWAYS:**
|
||||
|
||||
- Use exact 1-9 format when elicit: true
|
||||
- Select options 2-9 from data/elicitation-methods only
|
||||
- Provide detailed rationale explaining decisions
|
||||
- End with "Select 1-9 or just type your question/feedback:"
|
||||
|
|
@ -0,0 +1,93 @@
|
|||
# Checklist Validation Task
|
||||
|
||||
This task provides instructions for validating documentation against checklists. The agent MUST follow these instructions to ensure thorough and systematic validation of documents.
|
||||
|
||||
## Available Checklists
|
||||
|
||||
If the user asks or does not specify a specific checklist, list the checklists available to the agent persona. If the task is being run not with a specific agent, tell the user to check the {root}/checklists folder to select the appropriate one to run.
|
||||
|
||||
## Instructions
|
||||
|
||||
1. **Initial Assessment**
|
||||
|
||||
- If user or the task being run provides a checklist name:
|
||||
- Try fuzzy matching (e.g. "architecture checklist" -> "architect-checklist")
|
||||
- If multiple matches found, ask user to clarify
|
||||
- Load the appropriate checklist from {root}/checklists/
|
||||
- If no checklist specified:
|
||||
- Ask the user which checklist they want to use
|
||||
- Present the available options from the files in the checklists folder
|
||||
- Confirm if they want to work through the checklist:
|
||||
- Section by section (interactive mode - very time consuming)
|
||||
- All at once (YOLO mode - recommended for checklists, there will be a summary of sections at the end to discuss)
|
||||
|
||||
2. **Document and Artifact Gathering**
|
||||
|
||||
- Each checklist will specify its required documents/artifacts at the beginning
|
||||
- Follow the checklist's specific instructions for what to gather, generally a file can be resolved in the docs folder, if not or unsure, halt and ask or confirm with the user.
|
||||
|
||||
3. **Checklist Processing**
|
||||
|
||||
If in interactive mode:
|
||||
|
||||
- Work through each section of the checklist one at a time
|
||||
- For each section:
|
||||
- Review all items in the section following instructions for that section embedded in the checklist
|
||||
- Check each item against the relevant documentation or artifacts as appropriate
|
||||
- Present summary of findings for that section, highlighting warnings, errors and non applicable items (rationale for non-applicability).
|
||||
- Get user confirmation before proceeding to next section or if any thing major do we need to halt and take corrective action
|
||||
|
||||
If in YOLO mode:
|
||||
|
||||
- Process all sections at once
|
||||
- Create a comprehensive report of all findings
|
||||
- Present the complete analysis to the user
|
||||
|
||||
4. **Validation Approach**
|
||||
|
||||
For each checklist item:
|
||||
|
||||
- Read and understand the requirement
|
||||
- Look for evidence in the documentation that satisfies the requirement
|
||||
- Consider both explicit mentions and implicit coverage
|
||||
- Aside from this, follow all checklist llm instructions
|
||||
- Mark items as:
|
||||
- ✅ PASS: Requirement clearly met
|
||||
- ❌ FAIL: Requirement not met or insufficient coverage
|
||||
- ⚠️ PARTIAL: Some aspects covered but needs improvement
|
||||
- N/A: Not applicable to this case
|
||||
|
||||
5. **Section Analysis**
|
||||
|
||||
For each section:
|
||||
|
||||
- think step by step to calculate pass rate
|
||||
- Identify common themes in failed items
|
||||
- Provide specific recommendations for improvement
|
||||
- In interactive mode, discuss findings with user
|
||||
- Document any user decisions or explanations
|
||||
|
||||
6. **Final Report**
|
||||
|
||||
Prepare a summary that includes:
|
||||
|
||||
- Overall checklist completion status
|
||||
- Pass rates by section
|
||||
- List of failed items with context
|
||||
- Specific recommendations for improvement
|
||||
- Any sections or items marked as N/A with justification
|
||||
|
||||
## Checklist Execution Methodology
|
||||
|
||||
Each checklist now contains embedded LLM prompts and instructions that will:
|
||||
|
||||
1. **Guide thorough thinking** - Prompts ensure deep analysis of each section
|
||||
2. **Request specific artifacts** - Clear instructions on what documents/access is needed
|
||||
3. **Provide contextual guidance** - Section-specific prompts for better validation
|
||||
4. **Generate comprehensive reports** - Final summary with detailed findings
|
||||
|
||||
The LLM will:
|
||||
|
||||
- Execute the complete checklist validation
|
||||
- Present a final report with pass/fail rates and key findings
|
||||
- Offer to provide detailed analysis of any section, especially those with warnings or failures
|
||||
Loading…
Reference in New Issue