Add automated bugfix pipeline for unattended execution

bugfix/SKILL.md

@@ -63,6 +63,7 @@ Systematic bug resolution through these phases:
 6. **Review** (`/review`) — *(Optional)* Critically evaluate fix and tests
 7. **Document** (`/document`) — Release notes and documentation
 8. **PR** (`/pr`) — Submit a pull request
+9. **Feedback** (`/feedback`) — Address PR review comments
 
 ## Phase Transitions
 
@@ -75,10 +76,17 @@ Each phase must meet its exit criteria before the next phase begins. If a later
 - `/test` → proceed when all new and existing tests pass; if tests fail, return to `/fix`
 - `/review` → if the fix is inadequate or edge cases are missed, return to `/diagnose` or `/fix`
 
+## Automated Mode
+
+For unattended execution (CI/CD bots, automated systems), use
+`skills/automated.md` instead of the interactive controller. It chains
+diagnose → fix → test → review with self-correction loops and runs to
+completion without human input. See `/automated` or read the skill directly.
+
 ## File Layout
 
-The workflow controller lives at `skills/controller.md`.
-It defines how to execute phases, recommend next steps, and handle transitions.
+The workflow controller lives at `skills/controller.md` (interactive) or
+`skills/automated.md` (unattended).
 Phase skills are at `skills/{name}.md`.
 
 For principles, hard limits, safety, quality, and escalation rules, see `guidelines.md`.

bugfix/commands/automated.md

@@ -0,0 +1,7 @@
+# /automated
+
+Read `../skills/automated.md` and follow it.
+
+Run the full unattended bugfix pipeline. Context:
+
+$ARGUMENTS

bugfix/commands/feedback.md

@@ -0,0 +1,7 @@
+# /feedback
+
+Read `../skills/feedback.md` and follow it.
+
+Address PR review feedback. Context:
+
+$ARGUMENTS

bugfix/guidelines.md

@@ -10,11 +10,13 @@ Systematic bug resolution through these phases:
 6. **Review** (`/review`) — *(Optional)* Critically evaluate fix and tests
 7. **Document** (`/document`) — Release notes and documentation
 8. **PR** (`/pr`) — Submit a pull request
+9. **Feedback** (`/feedback`) — Address PR review comments
 
-The workflow controller lives at `skills/controller.md`.
-It defines how to execute phases, recommend next steps, and handle transitions.
+The workflow controller lives at `skills/controller.md` (interactive) or
+`skills/automated.md` (unattended).
 Phase skills are at `skills/{name}.md`.
-Artifacts go in `.artifacts/{number}/bugfix/{issue}`.
+Artifacts go in `.artifacts/{number}/bugfix/{issue}` (interactive) or a
+caller-configured directory (automated).
 
 ## Principles
 
@@ -56,6 +58,10 @@ Stop and request human guidance when:
 - A security or compliance concern arises
 - Confidence on the proposed solution is below 80%
 
+In **automated mode** (`skills/automated.md`), "stop and request human
+guidance" means writing an escalation report to the artifact directory
+and terminating. See the Escalation section in `skills/automated.md`.
+
 ## Working With the Project
 
 This workflow gets deployed into different projects. Respect the target project:

bugfix/skills/automated.md

@@ -0,0 +1,260 @@
+---
+name: automated
+description: Unattended bugfix pipeline that chains diagnose, fix, test, and review with self-correction loops. Designed for CI/CD bots and automated systems.
+---
+
+# Automated Bugfix Pipeline
+
+You are an automated bugfix agent running without human interaction. Your job
+is to diagnose a bug, implement a fix with tests, verify it, and self-review
+the result — all in a single unattended session.
+
+This pipeline reuses the individual phase skills (`diagnose.md`, `fix.md`,
+`test.md`, `review.md`) but orchestrates them sequentially with
+self-correction loops instead of waiting for human input between phases.
+
+**This file replaces `controller.md` for automated runs.** When a skill says
+"re-read the controller for next-step guidance," ignore that directive and
+return here to continue with the next phase.
+
+## When to Use This
+
+- A bug report has already been prepared and placed in a known location
+- A working branch has already been created
+- No human will be available to guide phase transitions
+- The calling system handles branch management, commits, and PR creation
+
+For interactive sessions with a human, use `controller.md` instead.
+
+## Configuration
+
+Before starting, determine these values from your context (task file,
+calling system instructions, or environment). Use the defaults if not
+specified.
+
+| Setting | Default | Description |
+|---------|---------|-------------|
+| `TASK_FILE` | `.ai-bot/task.md` | Bug report or task description |
+| `ARTIFACT_DIR` | `.ai-bot/` | Directory for intermediate artifacts |
+| `PR_OUTPUT` | `.ai-bot/pr.md` | Where to write the PR title and body |
+| `LINT_COMMAND` | *(auto-detect)* | Lint and format command (e.g., `make fmt && make lint`) |
+| `MAX_FIX_ATTEMPTS` | `5` | Max fix → test iterations before escalating |
+| `MAX_REVIEW_ROUNDS` | `3` | Max review → fix → test iterations before proceeding |
+
+**Artifact path mapping**: Individual skills reference
+`.artifacts/{number}/bugfix/...` paths. Redirect ALL artifact writes to
+`ARTIFACT_DIR` instead. Each phase below specifies the exact output
+filename to use.
+
+## Ground Rules
+
+- **Do not stop for human input.** Run all phases to completion.
+- **Do not create or switch branches.** Stay on the current branch.
+- **Do not push code or create PRs.** Write `PR_OUTPUT` and stop.
+- **Do not write files outside `ARTIFACT_DIR` and the project source tree.**
+  Scratch files, logs, notes, and test scripts go in `ARTIFACT_DIR`.
+  Only production source code and test file changes go outside it.
+- **Follow `guidelines.md`** for principles, hard limits, and quality
+  standards. Where guidelines say "stop and request human guidance,"
+  write an escalation report (see Escalation below) and terminate.
+- **Read and follow the project's `AGENTS.md`** if one exists. The
+  project's conventions take precedence over generic defaults.
+
+## Pipeline
+
+Execute these phases in order. For each phase, read the referenced skill
+file and execute its steps — but apply the ground rules and configuration
+above, and return here between phases instead of following the controller.
+
+### Phase 1 — Diagnose
+
+Read and execute `diagnose.md`.
+
+**Input**: Bug report at `TASK_FILE`.
+**Output**: Root cause analysis at `ARTIFACT_DIR/diagnosis.md`.
+
+**Overrides**:
+- If no reproduction report exists, skip the "Review Reproduction" step
+  and work directly from the bug report.
+- If diagnosis confidence is below 80%, document your caveats and
+  proceed. In unattended mode, a best-effort diagnosis is better than
+  stopping.
+
+### Phase 2 — Fix
+
+**⚠ Before proceeding, re-read the Overrides below carefully. They contain
+mandatory requirements that are easy to overlook after deep diagnosis work.**
+
+Read and execute `fix.md`.
+
+**Input**: Root cause analysis from Phase 1.
+**Output**:
+- Code changes and test changes in the working tree.
+- `ARTIFACT_DIR/implementation-notes.md` — see below.
+
+**Overrides**:
+- **Skip Step 2** (Create Feature Branch) — the branch already exists.
+- **Confidence threshold**: If you proceeded past a low-confidence
+  diagnosis in Phase 1, the 80% escalation threshold from
+  `guidelines.md` does not apply to the fix phase. Attempt the fix
+  based on your best-effort diagnosis. The self-review in Phase 4
+  will catch inadequate fixes.
+- **Unit tests are mandatory.** You MUST modify or create at least one
+  test file (e.g., `*_test.go`, `test_*.py`, `*.test.js`, `*.spec.ts`).
+  Add tests that cover the changed
+  behavior — both the happy path and the specific bug scenario. The fix
+  is not complete until tests exercise the new or changed code paths.
+  Do not defer tests to a later step. Phase 3 will verify that test
+  files were actually modified; if they weren't, you will be sent back
+  here.
+- **Write implementation notes** to `ARTIFACT_DIR/implementation-notes.md`.
+  A future AI session may need to address PR review comments without
+  any memory of this session. Record the context it will need:
+  - Files modified and why (with `file:line` references)
+  - Design choices made and alternatives considered or rejected
+  - Test strategy: what scenarios are covered, what was intentionally
+    excluded and why
+
+### Phase 3 — Test
+
+Read and execute `test.md`.
+
+**Input**: Changes from Phase 2.
+**Output**: Test verification at `ARTIFACT_DIR/test-verification.md`.
+
+**Gate check**: Before running tests, verify that you actually added or
+modified at least one test file (e.g., `*_test.go`, `test_*.py`,
+`*.test.js`, `*.spec.ts`). If no test files were modified, **stop and
+return to Phase 2** — do not proceed.
+
+Run the project's full test suite. If tests fail:
+
+1. Analyze the failure — is it a test issue or a fix issue?
+2. Return to **Phase 2** to revise the fix.
+3. Re-run **Phase 3**.
+4. Track the attempt count. After `MAX_FIX_ATTEMPTS` failures, escalate.
+
+### Phase 4 — Review
+
+Read and execute `review.md`.
+
+**Input**: All changes from Phases 2–3.
+**Output**: Review findings at `ARTIFACT_DIR/review.md`.
+
+Self-review the fix and tests with a critical eye. If the verdict is
+"Fix is inadequate" or finds CRITICAL or HIGH severity issues:
+
+1. Return to **Phase 2** to address the findings.
+2. Re-run **Phase 3** (test) and **Phase 4** (review).
+3. Track the round count. After `MAX_REVIEW_ROUNDS`, note the
+   unresolved issues in the review report and proceed — the human
+   reviewer will catch remaining problems.
+
+### Phase 5 — Lint
+
+Run the project's lint and format checks.
+
+**If `LINT_COMMAND` is configured**: Run it, fix all issues, repeat until
+it exits cleanly.
+
+**If `LINT_COMMAND` is not configured**, detect it using this priority
+order:
+
+1. Check the project's `AGENTS.md` for a lint command.
+2. Check the `Makefile` for `lint` or `fmt` targets.
+3. Check `package.json` scripts for a `lint` script.
+4. Fall back to language-specific defaults based on file extensions
+   present in the project:
+   - Go: `gofmt -w . && golangci-lint run ./...`
+   - Python: `ruff check --fix .` or `black . && flake8`
+   - JS/TS: `npx eslint --fix .`
+
+Fix all reported issues before proceeding.
+
+### Phase 6 — PR Description
+
+Write the PR title and description to `PR_OUTPUT`.
+
+**Format**:
+- **Line 1**: PR title. Write a clear, concise summary of the fix.
+- **Line 2**: Blank.
+- **Lines 3+**: PR body in markdown containing:
+  - **Root Cause** — summary from `ARTIFACT_DIR/diagnosis.md`
+  - **Fix** — what was changed and why
+  - **Tests Added** — list the specific test functions you wrote or
+    modified to verify this fix, with file paths
+  - **Known Issues** — if `MAX_REVIEW_ROUNDS` was exhausted with
+    unresolved findings, list them here so the human reviewer knows
+    to look more carefully. Omit this section if the self-review
+    was clean.
+
+### Phase 7 — Session Context
+
+Write a session context manifest to `ARTIFACT_DIR/session-context.md`.
+
+This file is the entry point for any future AI session that works on this
+PR without memory of the current session (e.g., addressing PR review
+feedback). Keep it concise — its purpose is to let a future session
+quickly recover the "why" behind your decisions.
+
+**Contents** (use this structure):
+
+```markdown
+# Session Context
+
+## Summary
+[1-2 sentence description of what was done and why]
+
+## Key Design Decisions
+[Summarize the most important choices from your implementation:
+what approach was taken, what alternatives were rejected, and why.
+Include file:line references for the core changes.]
+
+## Test Strategy
+[What scenarios are covered by tests, what was intentionally
+excluded and why]
+
+## Known Concerns
+[Any risks, caveats, or unresolved issues from the self-review.
+If the review was clean, say so.]
+
+## Artifacts
+The following files in this directory contain detailed context:
+- `diagnosis.md` — Root cause analysis
+- `implementation-notes.md` — Detailed file changes and rationale
+- `test-verification.md` — Test results and coverage
+- `review.md` — Self-review findings
+```
+
+**Why this matters**: A future session using `feedback.md` to address PR
+review comments has no memory of this session. Without this file, the AI
+must re-derive your reasoning from the code diff alone, which leads to
+worse responses to reviewer challenges and a higher risk of accidentally
+reverting intentional decisions.
+
+## Escalation
+
+When a phase fails beyond its retry limit, or when `guidelines.md`
+escalation criteria are met, write `ARTIFACT_DIR/escalation.md` with:
+
+- Which phase failed
+- What was attempted (include attempt count)
+- Why it could not be resolved automatically
+- Suggested next steps for a human
+
+Then **stop**. Do not continue past the failed phase.
+
+## Output
+
+When the pipeline completes successfully, the working tree contains:
+
+| Artifact | Description |
+|----------|-------------|
+| Source code changes | Production fix in the working tree |
+| Test changes | New or updated tests in the working tree |
+| `ARTIFACT_DIR/diagnosis.md` | Root cause analysis |
+| `ARTIFACT_DIR/implementation-notes.md` | Design decisions, alternatives, test rationale |
+| `ARTIFACT_DIR/test-verification.md` | Test results summary |
+| `ARTIFACT_DIR/review.md` | Self-review findings |
+| `ARTIFACT_DIR/session-context.md` | Summary manifest for future sessions |
+| `PR_OUTPUT` | PR title and description |

bugfix/skills/controller.md

@@ -37,6 +37,9 @@ executing phases and handling transitions between them.
 8. **PR** (`/pr`) — `pr.md`
    Push the branch to a fork and create a draft pull request.
 
+9. **Feedback** (`/feedback`) — `feedback.md`
+   Address PR review comments.
+
 Phases can be skipped or reordered at the user's discretion.
 
 ## How to Execute a Phase
@@ -75,6 +78,7 @@ After presenting results, consider what just happened, then offer options that m
 - The bug is a test coverage gap, not a runtime issue → skip `/reproduce`
   and `/diagnose`
 - Review says everything is solid → offer `/pr` directly
+- PR has been submitted and reviewers have commented → offer `/feedback`
 
 **Going back** — sometimes earlier work needs revision: