Fully autonomous bug hunting pipeline — discover bugs in a scoped area using parallel subagents, independently triage each finding, fix confirmed issues with subagents, then audit all fixes against repo constraints and target platforms. Runs end-to-end without user interaction.
Standardmäßig ist der Prompt ausgewählt, der zuerst die Quelle prüft. Sie können zu einem direkten Befehl wechseln oder eine lokale Kopie herunterladen.
Quelldateien prüfen
Lesen Sie SKILL.md und alle von SkillsMP angezeigten Begleitdateien, bevor Sie sich für eine Installation entscheiden.
Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.
Ein direkter Befehl überspringt den Prüf-Prompt. Prüfen Sie die Quelle, bevor Sie ihn ausführen.
Fully autonomous bug hunting pipeline — discover bugs in a scoped area using parallel subagents, independently triage each finding, fix confirmed issues with subagents, then audit all fixes against repo constraints and target platforms. Runs end-to-end without user interaction.
Bughunt
Fully autonomous pipeline: find, triage, fix, and audit bugs in a scoped area of a codebase. Five phases, each using subagents to parallelize work and provide independent assessments.
This skill runs end-to-end without asking the user any questions. Do not pause for confirmation, approval, or input between phases. Make autonomous decisions at every step — section splits, severity judgments, fix strategies, conflict resolution. Log progress to the report so the user can review the final output, but never block on user input.
Parameters
Parameter
Default
Example override
Scope
(required)
the install script, src/auth/, the CLI argument parser
Sections
auto-split from scope
split by platform, one per module
Platforms
inferred from repo
Linux, macOS, WSL
Output
/tmp/bughunt-output/<project>/
Output directory: ./qa/
<project> is the basename of the repo root (e.g. /tmp/bughunt-output/harbor/). The output directory — and therefore prior-run memory — is always per-project; never read or write another project's reports.
Workflow
1. Orient Read the target code, identify natural section boundaries
2. Discover Parallel bugbash subagents, one per section
3. Triage Independent subagent per finding — confirm, dispute, or adjust severity
4. Fix Subagent per confirmed issue — investigate, implement, self-review
5. Audit Verify all fixes against repo constraints and target platforms
Phase 1 — Orient
Read the target files yourself. Identify section boundaries for parallel discovery. Do not delegate this phase — you need the full picture to write good subagent prompts in later phases.
Good splits follow the code's own structure:
Per platform/backend — if the code branches by OS, distro, or provider
Per module — one subagent per file or logical unit
Write the section list and file ranges, then proceed immediately to Discovery. Each section needs enough context in isolation for a subagent to reason about it.
Create the output directory and initialize the report:
mkdir -p {OUTPUT_DIR}/evidence
Prior-run memory
Before launching discovery, check the output directory for reports from previous runs (report.md, report-*.md). Prior-run memory is per-project: only reports under this project's output directory count. If using the default location, also check the legacy global /tmp/bughunt-output/ root for reports whose stated scope matches this repo, and migrate them into the project subdirectory. If any exist:
Read them. Extract every previously fixed finding and every previously disputed finding with its rejection reason.
Preserve the old report (rename to report-<n>.md) — never overwrite it.
Pass relevant prior findings into the discovery prompts ("these were already found and fixed/rejected: ... do not re-report them") and dedupe new findings against them before triage. A finding that matches a previously disputed one inherits its DISPUTED verdict unless new evidence contradicts the old reasoning.
Note the severity trend across runs in the new report. If this run's findings are all lower-severity than the last run's, say so explicitly — that is the expected convergence, not a shortfall.
Phase 2 — Discover
Launch one subagent per section using the Agent tool, all in parallel (send all Agent calls in a single message). Each subagent:
Reads the code for its section
Looks for real bugs — not style nits, not hypotheticals
Returns structured findings
Subagent prompt template
You are bugbashing [project]. Your section is [section name] in [file path].
Read the file and focus on [specific areas and line ranges].
For each real bug, provide:
Issue ID (e.g., SEC-001)
Severity (Critical/High/Medium/Low)
Description
File:Line
Repro scenario
Evidence (code snippet)
Expected vs Actual
Only report bugs a real user could hit — no style nits or hypotheticals.
After all discovery agents return
Compile findings into the report. Deduplicate issues reported by multiple sections. Assign each a canonical ID. Update summary counts. Proceed immediately to Triage — do not wait for user input.
Phase 3 — Triage
Launch one subagent per finding using the Agent tool, all in parallel (send all Agent calls in a single message). Each triage agent:
Reads the relevant code fresh (no access to the discovery agent's reasoning)
Independently assesses whether the bug is real
Checks preconditions — are they realistic or contrived?
Evaluates severity — does it match the claimed impact?
Returns a short verdict
Triage subagent prompt template
You are an independent triage reviewer. Read the code, assess whether the bug is real.
Finding [ID] (claimed [severity]): [one-paragraph description with file:line]
Read [file] lines [range]. Answer:
Is this a real bug? Can a user actually hit it?
What preconditions are required? How likely are they?
Is [severity] the right severity?
Are there mitigating factors the original report missed?
Return a short verdict: CONFIRMED / DISPUTED / DOWNGRADE with reasoning (under 200 words).
Verdicts
CONFIRMED — bug is real at (or near) the stated severity. Proceeds to fix.
DOWNGRADE — bug is real but severity is wrong. Adjust the severity. Fix it only if the post-downgrade severity is Medium or higher; otherwise record it in the report as a known low-severity issue and do not fix. Cheapness of the fix is not a reason to apply it — "downgraded but it's a one-liner" is how a run inflates its fix count.
DISPUTED — bug is not real, requires impossible preconditions, or has zero practical impact. Keep it in the report's rejection table (with the refuting reason) — future runs dedupe against it — but never fix it.
The fix bar does not flex to fill the run. A run that confirms zero fixable bugs is a successful run — report "no findings above the fix bar" and the full rejection table, and stop. Do not lower the threshold because the report would otherwise look thin. The rejection table is a first-class deliverable: a well-refuted false positive is worth as much as a fix.
Update the report with triage results. Proceed immediately to Fix — do not wait for user input.
Phase 4 — Fix
Launch one subagent per confirmed issue using the Agent tool, all in parallel (send all Agent calls in a single message). Each fix agent:
Reads the relevant code and surrounding context
Investigates the root cause (not just the symptom)
Implements the minimal correct fix
Self-reviews the fix against specific criteria
Returns the exact edit (old_string / new_string) — does NOT apply it
Fix subagent prompt template
You are fixing a confirmed [severity] bug in [file].
Bug [ID]: [description]
Read [file] lines [range].
Fix requirements:
[specific behavioral requirements for this fix]
Keep the fix minimal — don't restructure surrounding code
Return: the exact old_string and new_string for an Edit tool call. Include enough surrounding context to make the match unique.
Self-review: after writing the fix, re-read it and check:
[fix-specific verification questions]
Does the fix handle the error/edge case that triggered the bug?
Does it introduce any new failure modes?
Why agents return edits instead of applying them
Multiple agents may edit the same file. Applying edits in parallel causes conflicts. Instead, collect all proposed edits, review them for overlap, then apply sequentially.
After all fix agents return
Check for overlapping edits in the same file — resolve conflicts autonomously (prefer the fix for the higher-severity issue; if equal, keep the more minimal edit)
Apply edits sequentially, one file at a time
Run syntax/parse checks on every modified file (bash -n, python -m py_compile, tsc --noEmit, etc.)
Proceed immediately to Audit — do not wait for user input
Phase 5 — Audit
Verify every fix against repo-level constraints. This is where platform-specific bugs, lint violations, and convention breaks get caught.
5a. Discover constraints
Before auditing, identify what constraints exist in the repo:
Lint rules — project linters, custom rules, CI checks
Target platforms — which OS/arch/runtime must the code support?
Portability rules — POSIX vs GNU, shell compatibility, min language versions
Lint — run the project's linter on modified files. If it has custom rules, check those specifically.
Platform portability — trace every command, flag, and function call in the fix. Verify availability on all target platforms. Common traps:
GNU-only flags (head -c, readlink -f, grep -P, sed -i without backup suffix)
macOS BSD vs GNU coreutils differences
bash-isms in code that runs under /bin/sh
Commands missing in minimal/container environments (timeout, getent, sudo)
Convention match — does the fix follow the patterns used in surrounding code?
Interaction — do any fixes conflict with each other when applied together?
5c. Fix audit failures
If a fix fails the audit:
Identify the exact constraint violation
Determine the portable/correct alternative
Apply the correction directly (no subagent needed for mechanical replacements)
Re-run the relevant check to confirm
Guidance
Fully autonomous. Run all five phases without stopping for user input. Make every decision yourself — section splits, severity calls, fix strategies, conflict resolution, audit judgments. The user reviews the final report, not intermediate checkpoints.
Subagents are your primary tool. Use the Agent tool aggressively. Every phase after Orient must use parallel subagents. Launch all subagents for a phase in a single message to maximize parallelism. Do not do sequentially what subagents can do in parallel.
Subagents are independent. Each subagent sees only its prompt and the code it reads. It has no memory of other phases or other agents. Write prompts that are fully self-contained.
Discovery is broad, triage is adversarial. Discovery agents should cast a wide net. Triage agents should be skeptical — their job is to kill false positives, not confirm findings.
Fixes are minimal. A fix agent should change the fewest lines possible to resolve the confirmed bug. No cleanup, no refactoring, no "while I'm here" improvements.
The audit catches what agents miss. Agents don't have cross-platform knowledge baked in. The audit phase exists specifically to catch platform-specific mistakes, lint violations, and convention breaks that individual fix agents can't know about.
Null results are valid. Repeated runs over the same scope must converge toward zero fixes. If they don't, the fix bar is floating — tighten it, don't celebrate the yield. Judge a run by the quality of its rejections and the severity of what it confirms, never by fix count.
Report incrementally. Update the report after each phase completes. If the session is interrupted, the work so far is preserved.
Log, don't ask. Write findings, triage verdicts, fix summaries, and audit results into the report as you go. The user reads the final report — they do not participate during execution.
