implement-patch

$npx mdskill add trailofbits/skills/implement-patch

Use after independent validation confirms one claim. Read the [record contract](../../references/records.md). Before target commands, follow its [project guidance](../../references/records.md#project-guidance).

SKILL.md

.github/skills/implement-patchView on GitHub ↗
---
name: implement-patch
description: Use when a confirmed local bug needs an invariant-level fix, variant search, tests, and one local commit.
---

# Implement Patch

## When to Use

Use after independent validation confirms one claim. Read the
[record contract](../../references/records.md).
Before target commands, follow its [project guidance](../../references/records.md#project-guidance).

## When NOT to Use

Do not use for speculative bug hunting, proof of a completed patch, or a change that
cannot be exercised by the local compiler or runtime.

## Procedure

1. Before editing, run `uv run --no-project <script> check --before-repair <run-dir>`
   with the [record validator](../../scripts/records.py). If this check fails,
   stop and return its errors for an INCONCLUSIVE report. The gate requires
   `finding.repair_scope` with a usable case plan and a consistent attempt count.
   Use the declared scope as the repair brief. Identify the broken
   invariant and search within its boundary for every instance of the
   same violation. Read the threat model only to preserve intended behavior; it is
   not a gate.
2. Run the project's existing suite and record its results. Write a regression test
   that fails on the baseline for the named bug and any fixed variant. Observe the
   failure. Fix the invariant within the repair brief with the smallest reviewable change.
3. Run the regression test and full existing suite again. Compare before and after
   failures. Fix new failures or explain a pre-existing one from receipts.
4. Record every variant as `fixed` or `not_fixed` with a reason. Produce exactly one
   local commit. Never push or open a PR. From the baseline, write `fix.patch` for
   production changes and `tests.patch` for test changes in `patch/attempt-N/`.
5. Write `patch.json` with the two commit SHAs, changed-file and line counts,
   variants, suite results, and your agent identity. If the attempt produced no commit,
   record `patch_commit: null` and return it as failed. Manifest the entire attempt
   directory, including both patch files and the record, using
   `uv run --no-project <script> manifest <patch-attempt-dir>`. Check it with the
   [record validator](../../scripts/records.py).

   [Patch record schema](../../schemas/patch.schema.json):
```json
{
  "schema_version": 1,
  "attempt": 1,
  "baseline_commit": "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa",
  "patch_commit": "bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb",
  "files_changed": 2,
  "lines_added": 3,
  "lines_removed": 1,
  "variants": [],
  "suite_before": {"command": "pytest", "passed": 9, "failed": 1, "skipped": 0},
  "suite_after": {"command": "pytest", "passed": 10, "failed": 0, "skipped": 0},
  "agent": "patcher-1"
}
```

## Rationalizations to Reject

| Shortcut | Required action |
| --- | --- |
| Only the reported line matters. | Search for the same invariant violation. |
| Minimal means the fewest lines. | Make the smallest reviewable invariant-level fix. |
| Tests pass after the patch. | Show the regression test failed before it. |

More from trailofbits/skills

SkillDescription
address-sanitizerBuilds and runs code under AddressSanitizer to catch buffer overflows, use-after-free, and other memory errors during fuzzing or tests. Covers -fsanitize=address builds, ASAN_OPTIONS, reading the crash report, LeakSanitizer, and the overhead and platform trade-offs. Use when fuzzing C/C++ or Rust that has unsafe blocks or FFI, when debugging a memory corruption crash, or when reading an ASan stack trace.
adjudicate-regressionUse when deciding whether source and live reproduction evidence establish a new regression or an exclusion.
aflppSets up and runs AFL++ for multi-core fuzzing of C/C++ projects built with afl-clang-fast or afl-gcc-fast. Covers instrumentation modes, parallel main and secondary campaigns, persistent mode, corpus minimization, and crash triage. Use when scaling fuzzing across cores, fuzzing a mature C/C++ codebase, reading the afl-fuzz status screen, or moving on after libFuzzer has plateaued.
agentic-actions-auditorAudits GitHub Actions workflows for security vulnerabilities in AI agent integrations including Claude Code Action, Gemini CLI, OpenAI Codex, and GitHub AI Inference. Detects attack vectors where attacker-controlled input reaches AI agents running in CI/CD pipelines, including env var intermediary patterns, direct expression injection, dangerous sandbox configurations, and wildcard user allowlists. Use when reviewing workflow files that invoke AI coding agents, auditing CI/CD pipeline security for prompt injection risks, or evaluating agentic action configurations.
algorand-vulnerability-scannerScans Algorand smart contracts for 11 common vulnerabilities including rekeying attacks, unchecked transaction fees, missing field validations, and access control issues. Use when auditing Algorand projects (TEAL/PyTeal).
atherisSets up and runs Atheris, the coverage-guided Python fuzzer built on libFuzzer. Covers TestOneInput harnesses, FuzzedDataProvider, instrumenting both pure Python and native C extensions, and running under AddressSanitizer. Use when fuzzing a Python package, hunting memory corruption in a Python C extension, or choosing between Atheris and Hypothesis for a Python target.
audit-augmentation>
audit-context-buildingUnderstand a codebase before looking for bugs in it - what each function assumes, what it guarantees, and what it depends on elsewhere. Use when starting an audit, threat model, or architecture review on unfamiliar code, and before any vulnerability-hunting pass.
audit-prep-assistantPrepares codebases for security review using Trail of Bits' checklist. Helps set review goals, runs static analysis tools, increases test coverage, removes dead code, ensures accessibility, and generates documentation (flowcharts, user stories, inline comments). Use when preparing your own codebase to be audited by someone else, getting a repository review-ready before an external security review, deciding what to fix before auditors start, or asking what assessors need from a project. For understanding unfamiliar code you are about to audit, use audit-context-building instead.
burpsuite-project-parserSearches and explores Burp Suite project files (.burp) from the command line. Use when searching response headers or bodies with regex patterns, extracting security audit findings, dumping proxy history or site map data, or analyzing HTTP traffic captured in a Burp project.