Skip to main content
Spec 1.0: This example uses the current stable portable core release.
Use this when production behavior is wrong and you need a safe, repeatable fix.

​
Goal

Fix the bug and make the intended behavior explicit enough that the same regression is harder to reintroduce.
  1. Reproduce the bug with a failing test or another clear failing check.
  2. Implement the smallest safe fix.
  3. Keep the regression test.
  4. If you are entering an existing repo or branch, get context first. In specled_ex, that is mix spec.prime --base HEAD.
  5. Run the guided reconcile step. In specled_ex, that is mix spec.next --bugfix.
  6. If the current subject already states the intended behavior, keep the test and tighten a scenario only when the wording is ambiguous.
  7. If the intended behavior is missing, update the requirement or scenario before merge.
  8. Update docs if the behavior is user-facing.
  9. Run the strict check before merge. In specled_ex, that is mix spec.check --base HEAD.

​
Prompt you can give an agent

Fix this bug through the full Spec Led Development loop.

If you are entering an existing repo or branch, start with the session-start context command for that stack.
First add or keep the regression proof.
Then make the smallest safe code change.
Run the guided reconcile step for this repo.
If the current subject already states the intended behavior, keep the test and tighten a scenario only if needed.
If the intended behavior is missing, update the requirement or scenario before you finish.
If the behavior is user-facing, check whether docs should move too.
Run the strict check before you finish.

​
Why this works

A bug fix is one of the best times to use Spec Led Development because the intended effect is usually very clear:
  • this behavior was wrong
  • this behavior should now stay true
  • this test or command proves it
That makes the spec update small and useful.

​
What to keep small

  • one requirement or one scenario update
  • one regression path
  • one bounded code change
A good bug-fix spec update is usually only a few lines, but sometimes the right outcome is to keep the new regression test and leave the requirement unchanged because the current truth was already clear.

​
Avoid

  • bundling cleanup and refactors into the same change
  • fixing adjacent issues without updating the spec boundary
  • merging a bug fix that only changes code but not the stated contract

​
Good outcome

The bug-fix loop is complete when:
  • the failing behavior is now described clearly
  • the regression is covered by a test or command
  • the verification loop passes
  • the team can point to one place in the repo that states the intended effect