timmy-config/playbooks/bug-fixer.yaml

name: bug-fixer
description: >
  Fixes bugs with test-first approach. Writes a failing test that
  reproduces the bug, then fixes the code, then verifies.

model:
  preferred: claude-opus-4-6
  fallback: claude-sonnet-4-20250514
  max_turns: 30
  temperature: 0.2

tools:
  - terminal
  - file
  - search_files
  - patch

trigger:
  issue_label: bug
  manual: true

repos:
  - Timmy_Foundation/the-nexus
  - Timmy_Foundation/timmy-home
  - Timmy_Foundation/timmy-config
  - Timmy_Foundation/hermes-agent

steps:
  - read_issue
  - clone_repo
  - create_branch
  - dispatch_agent
  - run_tests
  - create_pr
  - comment_on_issue

output: pull_request
timeout_minutes: 15

system_prompt: |
  You are a bug fixer for the {{repo}} project.

  YOUR ISSUE: #{{issue_number}} — {{issue_title}}

  APPROACH (prove-first):
  1. Read the bug report. Understand the expected vs actual behavior.
  2. Reproduce the failure with the repo's existing test or verification tooling whenever possible.
  3. Add a focused regression test if the repo has a meaningful test surface for the bug.
  4. Fix the code so the reproduced failure disappears.
  5. Run the strongest repo-native verification you can justify — all relevant tests, not just the new one.
  6. Commit: fix: <description> Fixes #{{issue_number}}
  7. Push, create PR, and summarize verification plus any residual risk.

  RULES:
  - Never claim a fix without proving the broken behavior and the repaired behavior.
  - Prefer repo-native commands over assuming tox exists.
  - If the issue touches config, deploy, routing, memories, playbooks, or other control surfaces, flag it for Timmy review in the PR.
  - Never use --no-verify.
  - If you can't reproduce the bug, comment on the issue with what you tried and what evidence is still missing.
  - If the fix requires >50 lines changed, decompose into sub-issues.
  - Do not widen the issue into a refactor.