sepehr
5bd180b5b8
Some checks failed
CI / check (push) Has been cancelled
Capture uncommitted solver robustness work (regularization, domain errors, linear solver lifecycle, tube DP/MSH), web workbench updates, and synced BMAD skills across IDE agent folders before starting BPHX pressure-drop. Co-authored-by: Cursor <cursoragent@cursor.com>
103 lines
4.8 KiB
Markdown
103 lines
4.8 KiB
Markdown
---
|
|
name: bmad-dev-auto
|
|
description: 'One iteration of an unattended development loop. Use when invoked by name.'
|
|
---
|
|
|
|
# Dev Auto Workflow
|
|
|
|
**Goal:** Turn intent into a hardened, reviewable artifact, without human interaction.
|
|
|
|
**CRITICAL:** If a step says "read fully and follow step-XX", you read and follow step-XX. No exceptions.
|
|
|
|
## HALT
|
|
|
|
To HALT with a final status and optional blocking condition:
|
|
|
|
1. If `{spec_file}` is known and exists, update `status` in frontmatter and append missing result details under `## Auto Run Result`.
|
|
2. If `{spec_file}` is unknown or missing, create `{implementation_artifacts}/bmad-dev-auto-result-<slug-or-timestamp>.md` with:
|
|
```markdown
|
|
---
|
|
status: <final status>
|
|
---
|
|
|
|
# BMad Dev Auto Result
|
|
|
|
Status: <final status>
|
|
Blocking condition: <blocking condition, if any>
|
|
```
|
|
3. Run: `python3 {project-root}/_bmad/scripts/resolve_customization.py --skill {skill-root} --key workflow.on_complete`
|
|
4. If the resolved `workflow.on_complete` is non-empty, follow it as the final instruction before exiting.
|
|
5. Stop the workflow.
|
|
|
|
## Subagents
|
|
|
|
Using subagents when instructed is mandatory. If you cannot, HALT with status `blocked` and blocking condition `no subagents`.
|
|
|
|
Invoke every subagent **synchronously**: launch it, wait for it to return within the same turn, then continue with its result. When a step says to run subagents "in parallel" (e.g. the reviewers), that means several **blocking** calls awaited together in one turn — not detached execution. Never run a subagent in the background / detached / async (e.g. `run_in_background: true`), and never end your turn to "await a completion notification." This workflow runs unattended: there is no event loop to resume a yielded turn, so a backgrounded subagent never hands control back and the run stalls. The only sanctioned way to end a turn is the HALT protocol above with an explicit terminal `status`.
|
|
|
|
## READY FOR DEVELOPMENT STANDARD
|
|
|
|
A specification is "Ready for Development" when:
|
|
|
|
- **Actionable**: Every task has a file path and specific action.
|
|
- **Logical**: Tasks ordered by dependency.
|
|
- **Testable**: All ACs use Given/When/Then.
|
|
- **Complete**: No placeholders or TBDs.
|
|
- **Sufficient**: No known requirement, acceptance, dependency, or implementation gaps remain unresolved.
|
|
- **Coherent**: No unresolved ambiguities or internal contradictions.
|
|
|
|
## Conventions
|
|
|
|
- Bare paths (e.g. `step-01-clarify-and-route.md`) resolve from the skill root.
|
|
- `{skill-root}` resolves to this skill's installed directory (where `customize.toml` lives).
|
|
- `{project-root}`-prefixed paths resolve from the project working directory.
|
|
- `{skill-name}` resolves to the skill directory's basename.
|
|
|
|
## On Activation
|
|
|
|
### Step 1: Resolve the Workflow Block
|
|
|
|
Run: `python3 {project-root}/_bmad/scripts/resolve_customization.py --skill {skill-root} --key workflow`
|
|
|
|
**If the script fails**, resolve the `workflow` block yourself by reading these three files in base → team → user order and applying the same structural merge rules as the resolver:
|
|
|
|
1. `{skill-root}/customize.toml` — defaults
|
|
2. `{project-root}/_bmad/custom/{skill-name}.toml` — team overrides
|
|
3. `{project-root}/_bmad/custom/{skill-name}.user.toml` — personal overrides
|
|
|
|
Any missing file is skipped. Scalars override, tables deep-merge, arrays of tables keyed by `code` or `id` replace matching entries and append new entries, and all other arrays append.
|
|
|
|
### Step 2: Execute Prepend Steps
|
|
|
|
Execute each entry in `{workflow.activation_steps_prepend}` in order before proceeding.
|
|
|
|
### Step 3: Load Persistent Facts
|
|
|
|
Treat every entry in `{workflow.persistent_facts}` as foundational context you carry for the rest of the workflow run. Entries prefixed `file:` are paths or globs under `{project-root}` -- load the referenced contents as facts. All other entries are facts verbatim.
|
|
|
|
### Step 4: Load Config
|
|
|
|
Load config from `{project-root}/_bmad/bmm/config.yaml` and resolve:
|
|
|
|
- `project_name`, `planning_artifacts`, `implementation_artifacts`, `user_name`
|
|
- `communication_language`, `document_output_language`, `user_skill_level`
|
|
- `date` as system-generated current datetime
|
|
- `project_context` = `**/project-context.md` (load if exists)
|
|
- YOU MUST ALWAYS SPEAK OUTPUT in your Agent communication style with the config `{communication_language}`
|
|
- Language MUST be tailored to `{user_skill_level}`
|
|
- Generate all documents in `{document_output_language}`
|
|
|
|
### Step 5: Execute Append Steps
|
|
|
|
Execute each entry in `{workflow.activation_steps_append}` in order.
|
|
|
|
Activation is complete after all activation steps have run.
|
|
|
|
## Workflow Execution
|
|
|
|
Follow the step files in order. Read one step fully, execute it, then load the next step only when directed. Do not skip, reorder, or pre-load steps.
|
|
|
|
## First workflow step
|
|
|
|
Read fully and follow: `./step-01-clarify-and-route.md` to begin the workflow.
|