feat: add dev auto skill

src/bmm-skills/4-implementation/bmad-dev-auto/SKILL.md

@@ -0,0 +1,125 @@
+---
+name: bmad-dev-auto
+description: 'Runs a full unattended development loop for one precise orchestrator task: resolve input, write or resume a machine-owned spec, implement, review, repair or escalate, and emit structured artifacts. Use when bmad-auto or another orchestrator launches a non-interactive development session with no human present.'
+---
+
+# Dev Auto Workflow
+
+**Goal:** Execute one orchestrator-supplied development task from input resolution through planning, implementation, review, repair, and structured completion without human interaction.
+
+**Execution posture:** Machine-first. Assume no human is present in the session.
+
+## Non-Interactive Contract
+
+- Never greet.
+- Never ask questions.
+- Never present menus.
+- Never pause for approval.
+- Never rely on conversational checkpoints.
+- Never require pasted review results or out-of-band human decisions.
+- If required information is missing, write a blocked result artifact and end cleanly.
+- If a decision would normally require a human, classify it as an escalation for the orchestrator.
+
+## Responsibility Boundary
+
+`bmad-dev-auto` owns the end-to-end development judgment loop for one task:
+
+- Resolve the orchestrator invocation into a concrete run.
+- Plan or resume from disk artifacts.
+- Write and maintain the task spec.
+- Implement the code.
+- Review the implementation.
+- Decide whether findings require code repair, spec repair, deferred work, rejection, or escalation.
+- Emit structured result artifacts.
+
+The orchestrator owns process-level concerns:
+
+- Task selection.
+- Session launching.
+- Worktree creation and cleanup.
+- Commit, push, and PR behavior.
+- Cross-run coordination.
+
+## Continuity Rule
+
+The same active session that interprets the task and writes the spec must retain final judgment through implementation, review triage, repair, and finalization. Subagents may be used for bounded exploration or independent review signals, but they do not own the development decision. This session synthesizes their output against the spec, implementation rationale, and current code state.
+
+## Invocation Shape
+
+The triggering prompt is the invocation. Prefer a structured block with these fields:
+
+- `task_id`: stable orchestrator task identifier.
+- `run_id`: stable attempt identifier. If absent, derive one from date and HEAD.
+- `intent`: precise change request.
+- `source_refs`: optional files, issue text, story text, or orchestrator notes to load.
+- `resume_from`: optional path to an existing auto run directory or spec file.
+- `constraints`: optional invariants, allowed paths, forbidden paths, compatibility requirements, or verification requirements.
+- `acceptance`: optional expected behavior in Given/When/Then or equivalent machine-readable form.
+- `verification`: optional commands the orchestrator expects to run.
+
+Minimum viable invocation: a precise `intent`. If neither `intent` nor `resume_from` can be resolved, the run must end as `blocked`.
+
+## Artifact Contract
+
+Write run artifacts under `{implementation_artifacts}/auto/{task_id}/` unless `resume_from` points to an existing run directory:
+
+- `spec.md` -- machine-owned task spec.
+- `review.md` -- final review and triage record.
+- `result.json` -- valid JSON result for the orchestrator.
+
+Append incidental pre-existing issues to `{implementation_artifacts}/deferred-work.md`.
+
+## 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)
+- CLAUDE.md / memory files (load if exist)
+- YOU MUST ALWAYS SPEAK OUTPUT in your Agent communication style with the config `{communication_language}`
+
+Do not greet after loading config.
+
+### Step 5: Execute Append Steps
+
+Execute each entry in `{workflow.activation_steps_append}` in order.
+
+Activation is complete. If `activation_steps_prepend` or `activation_steps_append` were non-empty, record their execution in the run notes. Do not wait for acknowledgement.
+
+## Workflow Architecture
+
+This uses sequential step files for deterministic execution:
+
+- Read the entire current step file before acting.
+- Execute sections in order.
+- Do not load future step files until the current step reaches its `NEXT` section.
+- Persist state to disk as artifacts, not conversation.
+- End only through a written `result.json` or a clean terminal branch explicitly defined by the current step.
+
+## First Step
+
+Read fully and follow `./steps/step-01-resolve.md`.

src/bmm-skills/4-implementation/bmad-dev-auto/customize.toml

@@ -0,0 +1,26 @@
+# DO NOT EDIT -- overwritten on every update.
+#
+# Workflow customization surface for bmad-dev-auto. Mirrors the
+# agent customization shape under the [workflow] namespace.
+
+[workflow]
+
+# --- Configurable below. Overrides merge per BMad structural rules: ---
+#   scalars: override wins • arrays (persistent_facts, activation_steps_*): append
+#   arrays-of-tables with `code`/`id`: replace matching items, append new ones.
+
+# Steps to run before standard activation. Overrides append.
+activation_steps_prepend = []
+
+# Steps to run after config load but before the workflow begins. Overrides append.
+activation_steps_append = []
+
+# Persistent facts the workflow keeps in mind for the whole run.
+# Each entry is either a literal sentence or a file reference prefixed with `file:`.
+persistent_facts = [
+  "file:{project-root}/**/project-context.md",
+]
+
+# Scalar: executed after result.json is written. Override wins.
+# Leave empty for no custom post-completion behavior.
+on_complete = ""

src/bmm-skills/4-implementation/bmad-dev-auto/result-schema.md

@@ -0,0 +1,46 @@
+# Result Schema
+
+Write `result.json` as valid JSON with this shape:
+
+```json
+{
+  "schema": "bmad.dev-auto.result.v1",
+  "task_id": "<task_id>",
+  "run_id": "<run_id>",
+  "status": "completed|blocked|failed",
+  "summary": "<one sentence>",
+  "artifacts": {
+    "run_dir": "<path>",
+    "spec": "<path>",
+    "review": "<path>",
+    "deferred_work": "<path or empty>"
+  },
+  "changes": {
+    "baseline_commit": "<sha|NO_VCS>",
+    "head_commit": "<sha|NO_VCS>",
+    "files_changed": []
+  },
+  "verification": [
+    {
+      "command": "<command>",
+      "status": "passed|failed|not_run",
+      "details": "<short details>"
+    }
+  ],
+  "review": {
+    "iterations": 0,
+    "open_findings": [],
+    "deferred_findings": []
+  },
+  "orchestrator_action": "commit|retry|manual_review|none",
+  "blocked_reason": "",
+  "notes": []
+}
+```
+
+Use `orchestrator_action` as follows:
+
+- `commit` when the run completed and the orchestrator can proceed to commit or PR handling.
+- `retry` when the run was blocked by environmental or transient conditions.
+- `manual_review` when the orchestrator must supply missing intent or resolve conflicting requirements.
+- `none` when no follow-up action is appropriate.

src/bmm-skills/4-implementation/bmad-dev-auto/spec-template.md

@@ -0,0 +1,62 @@
+---
+title: '{title}'
+task_id: '{task_id}'
+run_id: '{run_id}'
+type: 'feature'
+created: '{date}'
+status: 'draft'
+baseline_commit: ''
+review_iterations: 0
+context: []
+source_refs: []
+---
+
+<frozen-after-resolution reason="orchestrator-owned intent boundary">
+
+## Intent
+
+**Problem:** ONE_TO_TWO_SENTENCES
+
+**Approach:** ONE_TO_TWO_SENTENCES
+
+## Boundaries & Constraints
+
+**Always:** INVARIANT_RULES
+
+**Escalate If:** CONDITIONS_REQUIRING_ORCHESTRATOR_DECISION
+
+**Never:** NON_GOALS_AND_FORBIDDEN_APPROACHES
+
+## I/O & Edge-Case Matrix
+
+| Scenario | Input / State | Expected Output / Behavior | Error Handling |
+|----------|---------------|----------------------------|----------------|
+| HAPPY_PATH | INPUT | OUTCOME | N/A |
+| EDGE_CASE | INPUT | OUTCOME | ERROR_HANDLING |
+
+</frozen-after-resolution>
+
+## Code Map
+
+- `FILE` -- ROLE_OR_RELEVANCE
+
+## Tasks & Acceptance
+
+**Execution:**
+- [ ] `FILE` -- ACTION -- RATIONALE
+
+**Acceptance Criteria:**
+- Given PRECONDITION, when ACTION, then EXPECTED_RESULT
+
+## Spec Change Log
+
+Append-only. Each entry records the review finding that triggered the change, what was amended, what known-bad state the amendment avoids, and KEEP instructions for behavior that must survive re-implementation.
+
+## Design Notes
+
+DESIGN_RATIONALE_AND_EXAMPLES
+
+## Verification
+
+**Commands:**
+- `COMMAND` -- expected: SUCCESS_CRITERIA

src/bmm-skills/4-implementation/bmad-dev-auto/steps/step-01-resolve.md

@@ -0,0 +1,60 @@
+---
+task_id: ''
+run_id: ''
+run_dir: ''
+spec_file: ''
+review_file: ''
+result_file: ''
+deferred_work_file: '{implementation_artifacts}/deferred-work.md'
+mode: ''
+---
+
+# Step 1: Resolve Invocation
+
+## Rules
+
+- YOU MUST ALWAYS SPEAK OUTPUT in your Agent communication style with the config `{communication_language}`.
+- The triggering prompt is the orchestrator invocation.
+- Do not ask for missing information.
+- Do not infer broad product intent from weak hints.
+- Do not modify product code in this step.
+
+## Instructions
+
+1. Parse the invocation.
+   - Prefer explicit fields: `task_id`, `run_id`, `intent`, `source_refs`, `resume_from`, `constraints`, `acceptance`, and `verification`.
+   - If the invocation points to a file, load it and treat its contents as the invocation payload.
+   - If `resume_from` is present, resolve it to either an existing run directory or an existing `spec.md`.
+   - If no `task_id` is supplied, derive a stable kebab-case value from the intent. If the intent is absent, use `unresolved`.
+   - If no `run_id` is supplied, derive one from `{date}` and current HEAD when version control is available.
+
+2. Establish artifact paths.
+   - If resuming from a run directory, set `{run_dir}` to that directory.
+   - If resuming from a spec file, set `{run_dir}` to that file's parent directory.
+   - Otherwise, set `{run_dir}` to `{implementation_artifacts}/auto/{task_id}`. If it already exists and this is not a resume, append a deterministic numeric suffix.
+   - Set `{spec_file}` to `{run_dir}/spec.md`.
+   - Set `{review_file}` to `{run_dir}/review.md`.
+   - Set `{result_file}` to `{run_dir}/result.json`.
+   - Create `{run_dir}` if it does not exist.
+
+3. Validate minimal input.
+   - If neither a precise intent nor a readable resume spec exists, write `{result_file}` using the result schema from `../result-schema.md` with `status` = `blocked`, `blocked_reason` = `missing_intent`, and the resolved artifact paths.
+   - End cleanly after writing the blocked result. Do not continue to Step 2.
+
+4. Perform a version-control sanity check.
+   - Record current branch, HEAD, and working tree state in memory for the result.
+   - Compute the dirty file list before product-code work, excluding `{implementation_artifacts}`, `{planning_artifacts}`, `{project-root}/_bmad`, and `{project-root}/.bmad-auto` paths.
+   - If the remaining product-code dirty file list is non-empty and the invocation does not explicitly allow dirty resume, do not modify product code. Write `{result_file}` using the result schema from `../result-schema.md` with `status` = `blocked`, `blocked_reason` = `dirty_worktree`, and the dirty file list.
+   - End cleanly after writing the blocked result.
+
+5. Load source references.
+   - Load every readable file in `source_refs`.
+   - If a reference is missing, record it as an input warning. Missing optional references do not block unless the intent depends on them.
+
+6. Set `{mode}`.
+   - `resume` when `{spec_file}` already exists and is readable.
+   - `plan` otherwise.
+
+## Next
+
+Read fully and follow `./step-02-plan-or-resume.md`.

src/bmm-skills/4-implementation/bmad-dev-auto/steps/step-02-plan-or-resume.md

@@ -0,0 +1,43 @@
+---
+blocked_reason: ''
+---
+
+# Step 2: Plan or Resume
+
+## Rules
+
+- YOU MUST ALWAYS SPEAK OUTPUT in your Agent communication style with the config `{communication_language}`.
+- Do not ask for approval.
+- Do not create conversational checkpoints.
+- The `<frozen-after-resolution>` block is the orchestrator-owned intent boundary once written.
+- Review-driven spec repair may change only sections outside `<frozen-after-resolution>`.
+
+## Instructions
+
+1. Resume path.
+   - If `{mode}` = `resume`, read `{spec_file}` completely.
+   - Validate that it has frontmatter, a recognized `status`, and a `<frozen-after-resolution>` block.
+   - If the spec is malformed, write `{result_file}` using the result schema from `../result-schema.md` with `status` = `blocked`, `blocked_reason` = `invalid_resume_spec`, and the validation failures. End cleanly.
+   - Load any files listed in the `context` frontmatter.
+   - If the spec is valid, keep it as the controlling plan and continue to Step 3.
+
+2. Planning path.
+   - Investigate the codebase enough to identify affected files, existing patterns, verification commands, and risk boundaries.
+   - Use subagents only for bounded research summaries if available. Do not delegate ownership of the plan.
+   - Read `../spec-template.md` fully.
+   - Fill the template from the invocation, loaded references, persistent facts, and investigation.
+   - Remove placeholder text and any sections that do not apply.
+   - Write the completed spec to `{spec_file}`.
+
+3. Precision gate.
+   - Verify the spec has one cohesive task, explicit boundaries, concrete code map entries, actionable tasks, and testable acceptance criteria.
+   - If independent shippable goals are present, narrow to the primary goal only when a primary goal is unambiguous. Append secondary goals to `{deferred_work_file}` with a heading `## Deferred from bmad-dev-auto {task_id} ({date})`.
+   - If the primary goal is ambiguous or any acceptance-critical intent gap remains, write `{result_file}` using the result schema from `../result-schema.md` with `status` = `blocked`, `blocked_reason` = `ambiguous_intent`, and the unresolved questions as machine-readable items. End cleanly.
+
+4. Ready state.
+   - Set `{spec_file}` frontmatter `status` to `ready-for-dev`.
+   - Preserve the `<frozen-after-resolution>` block exactly after this point unless a new orchestrator invocation changes it in a later run.
+
+## Next
+
+Read fully and follow `./step-03-implement.md`.

src/bmm-skills/4-implementation/bmad-dev-auto/steps/step-03-implement.md

@@ -0,0 +1,41 @@
+---
+baseline_commit: ''
+---
+
+# Step 3: Implement
+
+## Rules
+
+- YOU MUST ALWAYS SPEAK OUTPUT in your Agent communication style with the config `{communication_language}`.
+- No push. No remote operations.
+- Do not commit.
+- Do not modify the `<frozen-after-resolution>` block.
+- Do not hand implementation ownership to a subagent.
+
+## Instructions
+
+1. Establish baseline.
+   - If version control is available, capture current HEAD as `{baseline_commit}`.
+   - If version control is unavailable, set `{baseline_commit}` to `NO_VCS`.
+   - Write `{baseline_commit}` to `{spec_file}` frontmatter unless a resume spec already has a non-empty `baseline_commit`.
+
+2. Enter implementation state.
+   - Set `{spec_file}` frontmatter `status` to `in-progress`.
+   - Load any files listed in the `context` frontmatter.
+
+3. Implement directly.
+   - Follow the tasks and acceptance criteria in `{spec_file}`.
+   - Preserve existing project architecture, naming, formatting, and test patterns.
+   - If the implementation reveals a spec problem outside the frozen block, amend the spec before continuing and append a `## Spec Change Log` entry.
+   - If the implementation reveals a missing orchestrator decision inside the frozen block, stop product-code work, revert product-code changes from this run when safe, write `{result_file}` using the result schema from `../result-schema.md` with `status` = `blocked`, `blocked_reason` = `intent_gap`, and the exact missing decision. End cleanly.
+
+4. Self-check.
+   - Verify every task in `## Tasks & Acceptance` is complete.
+   - Mark completed task checkboxes `[x]`.
+   - Run applicable verification commands from the spec and from project conventions.
+   - If verification fails because of the current change, repair and rerun.
+   - If verification cannot run because of environment limitations, record the limitation for `{result_file}` but continue only if code inspection can still establish task correctness.
+
+## Next
+
+Read fully and follow `./step-04-review-and-repair.md`.

src/bmm-skills/4-implementation/bmad-dev-auto/steps/step-04-review-and-repair.md

@@ -0,0 +1,55 @@
+---
+max_review_iterations: 5
+---
+
+# Step 4: Review and Repair
+
+## Rules
+
+- YOU MUST ALWAYS SPEAK OUTPUT in your Agent communication style with the config `{communication_language}`.
+- Review subagents receive no conversation context.
+- Review subagents provide signals only. This session owns triage and repair decisions.
+- Do not ask the user to run review prompts manually.
+- Do not leave known patch findings unresolved when the fix is unambiguous.
+
+## Instructions
+
+1. Enter review state.
+   - Set `{spec_file}` frontmatter `status` to `in-review`.
+   - Increment `review_iterations` in `{spec_file}` frontmatter.
+
+2. Construct the review payload.
+   - Read `baseline_commit` from `{spec_file}` frontmatter.
+   - Build a diff covering tracked and untracked changes since `baseline_commit`.
+   - If `baseline_commit` is missing or `NO_VCS`, construct a best-effort file-change summary from the working tree.
+   - Do not stage files.
+
+3. Run review layers.
+   - **Spec compliance:** Compare the diff to `{spec_file}`, including acceptance criteria, boundaries, context docs, and verification expectations.
+   - **Edge-case review:** Walk boundary conditions, failure paths, compatibility risks, and state transitions introduced by the diff.
+   - **Regression review:** Look for unintended behavior changes outside the spec, deleted behavior, security issues, data loss, and integration breakage.
+   - Use subagents for independent review signals when available, but perform an inline review yourself even if subagents run.
+
+4. Classify findings.
+   - `patch` -- caused by this change and unambiguously fixable in code.
+   - `bad_spec` -- caused by this change, but the non-frozen spec failed to direct the implementation clearly enough.
+   - `intent_gap` -- caused by missing or conflicting orchestrator-owned intent inside `<frozen-after-resolution>`.
+   - `defer` -- real pre-existing issue not caused by this task.
+   - `reject` -- false positive, already handled, or outside scope without actionable evidence.
+
+5. Process findings in order.
+   - If any `intent_gap` finding exists, revert product-code changes from this run when safe, preserve run artifacts, write `{result_file}` using the result schema from `../result-schema.md` with `status` = `blocked`, `blocked_reason` = `intent_gap`, and the exact orchestrator decision required. End cleanly.
+   - If any `bad_spec` finding exists, amend only the non-frozen spec sections, append a `Spec Change Log` entry with KEEP instructions, revert or repair code as needed, then read fully and follow `./step-03-implement.md`.
+   - If any `patch` finding exists, apply all unambiguous fixes, rerun relevant verification, then repeat this step from section 1.
+   - If any `defer` finding exists, append it to `{deferred_work_file}` with source task, evidence, and reason for deferral.
+   - Drop `reject` findings.
+
+6. Iteration guard.
+   - If the `review_iterations` value in `{spec_file}` frontmatter exceeds `{max_review_iterations}`, write `{result_file}` using the result schema from `../result-schema.md` with `status` = `blocked`, `blocked_reason` = `review_loop_limit`, and the unresolved findings. End cleanly.
+
+7. Write review artifact.
+   - Write `{review_file}` with review payload summary, findings by classification, actions taken, verification reruns, deferred items, and final open risks.
+
+## Next
+
+Read fully and follow `./step-05-finalize.md`.

src/bmm-skills/4-implementation/bmad-dev-auto/steps/step-05-finalize.md

@@ -0,0 +1,35 @@
+---
+---
+
+# Step 5: Finalize
+
+## Rules
+
+- YOU MUST ALWAYS SPEAK OUTPUT in your Agent communication style with the config `{communication_language}`.
+- No push. No remote operations.
+- Do not commit.
+- Final output is disk artifacts first, chat summary second.
+
+## Instructions
+
+1. Determine final status.
+   - `completed` when implementation is done, review has no unresolved `patch`, `bad_spec`, or `intent_gap` findings, and verification is passing or limitations are explicitly recorded.
+   - `blocked` when `{result_file}` already exists with a blocked status from an earlier step.
+   - `failed` only for unexpected execution errors that prevented artifact completion.
+
+2. Finalize spec.
+   - If final status is `completed`, set `{spec_file}` frontmatter `status` to `done`.
+   - Ensure completed execution tasks are checked.
+   - Ensure `Spec Change Log` entries are append-only.
+
+3. Ensure review artifact exists.
+   - If `{review_file}` does not exist, write a minimal review artifact explaining why review could not run or why an earlier blocked result ended the workflow.
+
+4. Write result JSON.
+   - Read `../result-schema.md`.
+   - Write `{result_file}` as valid JSON matching that schema.
+
+5. Completion behavior.
+   - If `{workflow.on_complete}` is non-empty, execute it after writing `{result_file}`.
+   - Emit a concise terminal summary naming `{result_file}`, final status, changed files, and verification state.
+   - Do not ask for next steps.

src/bmm-skills/module-help.csv

@@ -3,6 +3,7 @@ BMad Method,_meta,,,,,,,,,false,https://docs.bmad-method.org/llms.txt,
 BMad Method,bmad-document-project,Document Project,DP,Analyze an existing project to produce useful documentation.,,,anytime,,,false,project-knowledge,*
 BMad Method,bmad-generate-project-context,Generate Project Context,GPC,Scan existing codebase to generate a lean LLM-optimized project-context.md. Essential for brownfield projects.,,,anytime,,,false,output_folder,project context
 BMad Method,bmad-quick-dev,Quick Dev,QQ,Unified intent-in code-out workflow: clarify plan implement review and present.,,,anytime,,,false,implementation_artifacts,spec and project implementation
+BMad Method,bmad-dev-auto,Dev Auto,DA,Machine-first unattended development run for one orchestrator task: resolve input plan or resume implement review repair finalize and emit result JSON.,,,anytime,,,false,implementation_artifacts,spec review result JSON and project implementation
 BMad Method,bmad-correct-course,Correct Course,CC,Navigate significant changes. May recommend start over update PRD redo architecture sprint planning or correct epics and stories.,,,anytime,,,false,planning_artifacts,change proposal
 BMad Method,bmad-agent-tech-writer,Write Document,WD,"Describe in detail what you want, and the agent will follow documentation best practices. Multi-turn conversation with subprocess for research/review.",write,,anytime,,,false,project-knowledge,document
 BMad Method,bmad-agent-tech-writer,Update Standards,US,Update agent memory documentation-standards.md with your specific preferences if you discover missing document conventions.,update-standards,,anytime,,,false,_bmad/_memory/tech-writer-sidecar,standards