How do I install the Routine Logic Bugfixer skill?

Run npx skillmds@latest add bex-co/routine-logic-bugfixer-2 in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

Is Routine Logic Bugfixer safe to use?

This skill has not completed SkillMD's automated safety review yet. Independent scanners report: SkillSpector: PASS, Skill Scanner: PASS. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with Routine Logic Bugfixer?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is Routine Logic Bugfixer free to use?

Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.

Who published Routine Logic Bugfixer?

bex-co (@bex-co) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Routine Logic Bugfixer by bex-co — Agent Skill

Name: Routine Logic Bugfixer
Author: bex-co

Routine Logic Bugfixer

Autonomous maintenance routine that picks one tricky logic unit in a monorepo package — state machines, date/period math, sign conventions, dedup windows, pagination — models its states and edge cases exhaustively, proves any divergence from documented intent with a failing test, lands the minimal root-cause fix plus regression test, and ships via /ship. Use only when the user explicitly invokes /routine-logic-bugfixer or asks to hunt for logic bugs. SKIP for test-infrastructure failures and intermittent tests (routine-flaky-test-fixer) and for merely convoluted-but-correct code (routine-logic-simplifier). The core trigger is "model this tricky logic and fix what's provably wrong".

bex-co Updated Sep 22, 2026

File contents

Task: Model tricky logic to find and fix provable bugs

Usage: /routine-logic-bugfixer [package-or-path]

Pick one unit of genuinely tricky logic, enumerate its states and edges, derive inputs that should break it, prove each bug with a failing test against documented intent, fix the root cause, and ship via /ship.

Contract

Read .agents/skills/routine-shared/contract.md first — preconditions, scope resolution, verify gates, ship protocol, budget, universal STOPs. Floor even without it: never ship red; one finding per ship; anything in a DO_NOT_DO.md is a hard STOP.

Workflow

1. Scope

Resolve scope per the contract.

2. Discover

Pick one tricky unit — the kinds this repo actually has: auth/session state machines, date and period arithmetic, amount sign conventions, dedup/fuzzy-match windows, pagination cursors, cache invalidation, balance computation. Then model it explicitly: list every state, transition, and edge (empty input, boundary dates, negative amounts, timezone/DST edges, off-by-one windows, concurrent transitions). From the model, derive candidate-breaking inputs.

3. Prove it

A bug exists only when you have both:

A failing test against current code for a derived input, and
Documented intent the behavior diverges from — code comments, docs, CLAUDE.md guidance, beancount semantics, ADRs, or the git history of the unit.

Reproducible crashes found while modeling count as provable bugs (crashing is never the documented intent). If the intent is genuinely ambiguous — the test pins a choice nobody has made — STOP for that finding and report the ambiguity instead of shipping an opinion.

4. Fix

The minimal root-cause fix, plus the failing test as a permanent regression test. No drive-by refactoring; if the unit also deserves simplification, defer to routine-logic-simplifier in the summary.

5. Verify

New regression test green, full owning-package gate green, and a quick sweep of callers for anyone depending on the old wrong behavior (if someone does, that is an intent ambiguity — STOP and report).

6. Ship

Compose /ship for this one bug. Loop within budget.

What NOT to do

Never ship a "fix" whose only justification is that the new behavior seems more reasonable — no documented intent, no bug.
Never weaken or delete an existing test to make a fix pass; a conflicting test means conflicting intent — STOP and report.
Intermittent failures are not logic bugs — defer to routine-flaky-test-fixer.
Don't model units that are trivial or already exhaustively tested; spend the budget where trickiness lives.

Arguments

$ARGUMENTS

---name: routine-logic-bugfixer-2description: Autonomous maintenance routine that picks one tricky logic unit in a monorepo package — state machines, date/period math, sign conventions, dedup windows, pagination — models its states and edge cases exhaustively, proves any divergence from documented intent with a failing test, lands the minimal root-cause fix plus regression test, and ships via /ship. Use only when the user explicitly invokes /routine-logic-bugfixer or asks to hunt for logic bugs. SKIP for test-infrastructure failures and intermittent tests (routine-flaky-test-fixer) and for merely convoluted-but-correct code (routine-logic-simplifier). The core trigger is "model this tricky logic and fix what's provably wrong".---# Task: Model tricky logic to find and fix provable bugsUsage: `/routine-logic-bugfixer [package-or-path]`Pick one unit of genuinely tricky logic, enumerate its states and edges, deriveinputs that should break it, prove each bug with a failing test againstdocumented intent, fix the root cause, and ship via `/ship`.## ContractRead `.agents/skills/routine-shared/contract.md` first — preconditions,scope resolution, verify gates, ship protocol, budget, universal STOPs. Flooreven without it: never ship red; one finding per ship; anything in a`DO_NOT_DO.md` is a hard STOP.## Workflow### 1. ScopeResolve scope per the contract.### 2. DiscoverPick **one** tricky unit — the kinds this repo actually has: auth/session statemachines, date and period arithmetic, amount sign conventions,dedup/fuzzy-match windows, pagination cursors, cache invalidation, balancecomputation. Then model it explicitly: list every state, transition, and edge(empty input, boundary dates, negative amounts, timezone/DST edges, off-by-onewindows, concurrent transitions). From the model, derive candidate-breakinginputs.### 3. Prove itA bug exists only when you have **both**:1. A failing test against current code for a derived input, and2. **Documented intent** the behavior diverges from — code comments, docs, `CLAUDE.md` guidance, beancount semantics, ADRs, or the git history of the unit.Reproducible crashes found while modeling count as provable bugs (crashing isnever the documented intent). If the intent is genuinely ambiguous — the testpins a choice nobody has made — **STOP for that finding** and report theambiguity instead of shipping an opinion.### 4. FixThe minimal root-cause fix, plus the failing test as a permanent regressiontest. No drive-by refactoring; if the unit also deserves simplification, deferto `routine-logic-simplifier` in the summary.### 5. VerifyNew regression test green, full owning-package gate green, and a quick sweep ofcallers for anyone depending on the old wrong behavior (if someone does, thatis an intent ambiguity — STOP and report).### 6. ShipCompose `/ship` for this one bug. Loop within budget.## What NOT to do- Never ship a "fix" whose only justification is that the new behavior seems more reasonable — no documented intent, no bug.- Never weaken or delete an existing test to make a fix pass; a conflicting test means conflicting intent — STOP and report.- Intermittent failures are not logic bugs — defer to `routine-flaky-test-fixer`.- Don't model units that are trivial or already exhaustively tested; spend the budget where trickiness lives.## Arguments$ARGUMENTS

Frequently asked questions