Exécutez n'importe quel Skill dans Manus
en un clic

Exécutez n'importe quel Skill dans Manus en un clic

harness-bugfix

Étoiles1

Forks0

Mis à jour28 mai 2026 à 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

Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.

Exécuter dans Manus

Source

alexherrero

alexherrero/dev-setup

Ouvrir le dépôt GitHub Voir les dépôts du créateur

Téléchargement

Exécuter dans Manus

Métiers associésSOC

Basé sur la classification professionnelle SOC

Développeurs de logicielsProfessions informatiques et mathématiques·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.

Plus depuis ce dépôt

même dépôt

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.