Run any Skill in Manus with one click

harness-bugfix

Stars1

Forks0

UpdatedMay 28, 2026 at 16:12

Bug triage pipeline — Report → Analyze → Fix → Verify. Use instead of harness-plan+harness-work for bugs. Prefixed harness- for consistency with the other phase skills.

Installation

Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.

Run Skill in Manus

Source

alexherrero

alexherrero/dev-setup

View GitHub Repository View Creator Repositories

Download

Run Skill in Manus

Related occupationsSOC

Based on SOC occupation classification

Software DevelopersComputer and Mathematical Occupations·SOC 15-1252

SKILL.md

readonly

name	harness-bugfix
description	Bug triage pipeline — Report → Analyze → Fix → Verify. Use instead of harness-plan+harness-work for bugs. Prefixed harness- for consistency with the other phase skills.

harness-bugfix skill

Run the bugfix pipeline of agentm. Full spec: harness/pipelines/bugfix.md. Read it and follow it.

Bug report: provide the bug report, issue link, or reproduction steps when invoking this skill.

Four phases, in order

Report — capture the bug verbatim in .harness/PLAN.md under ## Report. Do not paraphrase. Interview if the report is unclear. Then propose a GitHub Issue (gh issue create --label bug) with title + body preview; on confirmation, record #N in PLAN.md as **Tracking:** #N. Skip gracefully if gh unavailable or origin not on GitHub.
Analyze — reproduce locally, find the root cause (ask "why" at least three times), not just the first suspicious line. Write findings under ## Analysis. If root cause is actually a design flaw, stop and escalate to harness-plan. Post the Analysis to the tracking issue as a comment (preview-and-ask).
Fix — write a regression test that FAILS against current code and WILL pass after the fix. Then fix it. Minimal scope — no "while I'm in here" changes. Post the Fix summary (commit SHA, regression test path, files changed, gate results) to the tracking issue as a comment.
Verify — run the harness-review skill (non-negotiable for bugs). Confirm the regression test actually exercises the root cause, not just the symptom. Confirm the original report's reproduction steps no longer reproduce. Then dispatch the documenter subagent with the bug report + fix diff — it updates Known-Issues.md or adds an ADR only if the fix reveals a gotcha worth persisting. Most bugfixes get NO CHANGES from docsub and that's correct. Post the Verify summary to the tracking issue, then close it with gh issue close --reason completed.

Non-negotiables

Regression test is mandatory. No test, no fix.
Root cause before fix. Jumping to a patch is how bugs come back.
harness-review on every bugfix. Bugs are evidence of code you got wrong once — fresh eyes matter more, not less.
Docsub's bugfix pass is lightweight. Don't force a wiki update on a run-of-the-mill fix — over-documentation is drift too.
Every gh issue * call is preview-and-ask per harness/documentation.md. No silent automation. The issue serves as the bug's posterity record — Report → Analysis → Fix → Verify, one comment per phase, closed on completion.

Start with the Report phase.

More from this repository

same repository

dependabot-fixer

alexherrero/dev-setup

Fix breakage on a Dependabot PR. Trigger when (a) the current branch matches `dependabot/*` and CI is red, (b) the user asks to "fix the dependabot PR" / "make this dependency update pass", or (c) the user invokes `/dependabot-fix [pr-number]`. Reads failing CI logs and upstream CHANGELOG, applies a bounded fix loop, pushes commits to the Dependabot branch, comments residual risks on the PR. Never merges. Aborts honestly when the fix needs human judgment.

2026-05-281

ship-release

alexherrero/dev-setup

Cut a tagged GitHub release from the default branch. Trigger when the user says "ship a release", "cut a release", "tag a release", or invokes the skill explicitly. Auto-sizes the semver bump from conventional-commit prefixes in the commit range since the last tag — patch / minor / major — and respects an explicit size hint (`patch|minor|major`) or exact version (`vX.Y.Z`). Writes CHANGELOG.md, tags, pushes, creates the GitHub release. Aborts if the tree is dirty, the default branch isn't pushed, or the tag already exists.

2026-05-281

dependabot-fixer

alexherrero/dev-setup

Fix breakage on a Dependabot PR. Trigger when (a) the current branch matches `dependabot/*` and CI is red, (b) the user asks to "fix the dependabot PR" / "make this dependency update pass". Reads failing CI logs and upstream CHANGELOG, applies a bounded fix loop, pushes commits to the Dependabot branch, comments residual risks on the PR. Never merges. Aborts honestly when the fix needs human judgment.

2026-05-281

harness-plan

alexherrero/dev-setup

Turn a brief into .harness/PLAN.md with per-task verification criteria. No code written — implementation is the harness-work skill. Prefixed harness- to avoid collision with Codex's built-in /plan (which has different semantics).

2026-05-281

harness-release

alexherrero/dev-setup

Pre-merge gate — verify plan done, gates green, CI passing, docs swept. Does NOT push/merge/tag without explicit user approval. Prefixed harness- for consistency with the other phase skills.

2026-05-281

harness-review

alexherrero/dev-setup

Adversarial review — assume the code has bugs, find them. Executable artifact required. No fixes applied. Prefixed harness- to avoid collision with Codex's built-in /review (which has different semantics).

2026-05-281

harness-bugfix skill

Run the bugfix pipeline of agentm. Full spec: harness/pipelines/bugfix.md. Read it and follow it.

Bug report: provide the bug report, issue link, or reproduction steps when invoking this skill.

Four phases, in order

Report — capture the bug verbatim in .harness/PLAN.md under ## Report. Do not paraphrase. Interview if the report is unclear. Then propose a GitHub Issue (gh issue create --label bug) with title + body preview; on confirmation, record #N in PLAN.md as **Tracking:** #N. Skip gracefully if gh unavailable or origin not on GitHub.

Analyze — reproduce locally, find the root cause (ask "why" at least three times), not just the first suspicious line. Write findings under ## Analysis. If root cause is actually a design flaw, stop and escalate to harness-plan. Post the Analysis to the tracking issue as a comment (preview-and-ask).

Fix — write a regression test that FAILS against current code and WILL pass after the fix. Then fix it. Minimal scope — no "while I'm in here" changes. Post the Fix summary (commit SHA, regression test path, files changed, gate results) to the tracking issue as a comment.

Verify — run the harness-review skill (non-negotiable for bugs). Confirm the regression test actually exercises the root cause, not just the symptom. Confirm the original report's reproduction steps no longer reproduce. Then dispatch the documenter subagent with the bug report + fix diff — it updates Known-Issues.md or adds an ADR only if the fix reveals a gotcha worth persisting. Most bugfixes get NO CHANGES from docsub and that's correct. Post the Verify summary to the tracking issue, then close it with gh issue close --reason completed.

Non-negotiables

Regression test is mandatory. No test, no fix.

Root cause before fix. Jumping to a patch is how bugs come back.

harness-review on every bugfix. Bugs are evidence of code you got wrong once — fresh eyes matter more, not less.

Docsub's bugfix pass is lightweight. Don't force a wiki update on a run-of-the-mill fix — over-documentation is drift too.

Every gh issue * call is preview-and-ask per harness/documentation.md. No silent automation. The issue serves as the bug's posterity record — Report → Analysis → Fix → Verify, one comment per phase, closed on completion.

Start with the Report phase.