Binder Gauntlet
AnthropicOfficialPublished by Anthropic
- Skill
- Workflow
- Science and research
- Apache-2.0
- Low risk
- Has scripts
AutoGineer summary
Written by AutoGineer from the skill’s own files, not by the author
Binder-gauntlet provides a structured computational protocol to validate de novo designed protein binders and miniproteins. It moves beyond initial structure-predictor confidence scores by implementing independent re-prediction, pose agreement checks, developability profiling, and specificity testing. The skill is designed to be used iteratively throughout a design campaign to steer selection, filter candidates, and generate a final validation dossier for laboratory transition.
What it does
- Validates binding claims using independent structure predictors and pose agreement metrics.
- Profiles chemical and physical developability, including aggregation risks and surface charge.
- Checks for specificity and cross-reactivity against paralogs and orthologs.
- Assesses native context, including glycosylation sites and domain architecture.
- Generates a structured validation dossier and per-design data table.
- Provides a sequence-level profiling script for identifying liability motifs.
When to use it
- When you need to validate binder designs beyond initial structure-predictor confidence.
- At each selection round of a design campaign to filter and steer development.
- When preparing a validation dossier for leads before laboratory synthesis.
- When you need to check for sequence liabilities, specificity, or developability flags.
Advantages
- Promotes objective decision-making by using independent predictors and controls.
- Enables early identification of design liabilities to save time and resources.
- Provides a standardized reporting format for design campaigns.
- Target-agnostic and tool-agnostic, allowing integration with existing local predictors.
Usage examples
- “Validate these binder designs.”
- The agent runs the gauntlet protocol, including independent re-prediction, pose agreement checks, and developability profiling, resulting in a validation dossier.
- “Check developability and sequence liabilities for this set of binders.”
- The agent uses the sequence profiling script to identify motifs, charge patches, and aggregation-prone stretches, reporting them in a structured table.
- “Which of these designs should go to the lab?”
- The agent evaluates the designs against the consensus rule and developability criteria, providing a ranked list with justifications for those kept and those set aside.
- “Create a validation dossier for my top binder leads.”
- The agent compiles the results from the binding validation, specificity panel, and developability checks into a markdown dossier based on the provided template.
Install
Download the skill as a ZIP:
https://mp-staging.autogineer.com/agent-skills/anthropics/binder-gauntlet/downloadUnzip it into the cross-client skills folder of your project:
mkdir -p .agents/skills && unzip binder-gauntlet.zip -d .agents/skills
Documentation by Anthropic
Binder gauntlet: validate and profile designed binders before anyone orders DNA
A structure predictor's interface confidence is the field's standard first filter, and it is only that. This skill is the rest of the computational diligence a protein-engineering or pharma team expects to see next to a table of designed binders: (A) evidence the binding claim survives checks the design loop did not optimise against, with controls; (B) a developability profile of each design; (C) an honest dossier that says what was not checked. It is target-agnostic and tool-agnostic — use whatever predictors and utilities are installed — but names common open tools and literature thresholds (see references/thresholds.md). Budget it explicitly: time one complex prediction per predictor and multiply — A1 for 30 designs × 2 predictors × 3 seeds is ≈180 complex predictions plus the monomer refolds and controls; A6–A9 on 10 leads roughly doubles that; part B is CPU-minutes.
Before you start
Script:
${CLAUDE_SKILL_DIR}/scripts/sequence_profile.py(standard library only) turns one or many sequences (a FASTA file, or--seq) into Part B's sequence-level table: size, pI and net charge, GRAVY, A280 measurability, cysteines, liability motifs with their positions, hydrophobic and charged windows, candidate protease sites; one row per design, CSV or--json. Run it on the shortlist every round instead of re-deriving the motif rules. First use in a new environment:python3 "${CLAUDE_SKILL_DIR}/scripts/sequence_profile.py" --self-testshould end "self-test passed".Where to write: a working folder in the user's directory, for example
gauntlet/<target>/with one sub-folder per round. Never write into the skill's folder.References:
references/thresholds.md(where every pass mark comes from),references/developability-checks.md(how to compute each Part B item),references/dossier-template.md(Part C),references/honest-limits.md(the sentences to use).On a cluster: where GPU work is dispatched as Kubernetes or Slurm jobs rather than run in the session, every structure-prediction run in Part A (complex re-predictions, monomer refolds, co-folds, the controls included) goes out as a batch job the way the session submits its other GPU work; Part B, the superpositions and the write-up stay in the session.
Principles
Independence. A check only adds evidence if the design loop did not optimise against it. Prefer predictors, seeds and physics terms outside your objective; say which checks are and are not independent.
Same pipeline for controls and designs. Every validation protocol is first run on positive and negative controls; report their numbers beside the designs'. A pipeline that cannot separate a known binder from a scrambled sequence is not evidence.
Not run ≠ passed. Anything you did not check is listed as not checked, with the reason.
Pass/fail only where the literature gives a threshold; otherwise report values against references. There is no validated computational developability gauntlet for miniproteins (antibody rules such as TAP do not transfer); show descriptors, compare to reference proteins if available, do not invent cut-offs.
Reject in the open. Candidates dropped on this evidence are part of the deliverable, with the reason.
Run it in the loop, not only at the end
These checks are for steering design, not just for documenting it. At every selection or refinement round, run the cheap ones on the current shortlist and use the results to decide what to keep, drop, mutate or redesign: sequence liabilities (above all labile motifs inside the interface), A280 measurability, pI and charge patches, hydrophobic patch on the free (non-interface) face, low-complexity or poly-residue runs, a self-association co-fold, designability/sequence recovery (A8, B1–B4, B7, B8 — minutes per round), plus an out-of-objective re-prediction with pose agreement, a monomer refold and the partner-superposition blocker test on the current top N (A1, A2, A5 — N × predictors × seeds complex predictions; time it as in the budget note above). Reserve the expensive checks — the full paralog/ortholog/decoy panel (A6), binding-dead mutants (A7), full-length-target refolds (A9), any MD (A10) — for leads before the final pick. Run the controls (A3) early, and again through each protocol the first time you use it, so every later number has a reference. Keep a running "set aside, and why" log from the first round; it becomes dossier topic 8. A liability found in a final candidate costs a redesign or a caveat; the same liability found at round one costs nothing. The dossier is the record of this steering, not the goal. One trade-off to manage (Principle 1): a predictor you select on joins your objective, so state the A4 rule before the first round, hold at least one predictor or protocol back for the final pass, and say in dossier topic 1 which checks steered selection and which stayed independent.
Part A — Binding-validation gauntlet (per design unless noted)
A1. Out-of-objective re-prediction and pose agreement. Re-predict each binder–target complex from sequence with at least one predictor not used in design or scoring — two if you have them — (e.g. AF2-multimer with target template ± initial guess, Boltz, Chai, Protenix/AF3-class, or single-sequence predictors where they support complexes), several seeds each. Record interface confidence (ipTM, interface pAE, ipSAE) and agreement with YOUR designed pose (DockQ, interface RMSD, binder RMSD after target superposition). Literature pass marks: interface pAE < 10; DockQ ≥ 0.49 "medium", ≥ 0.23 "acceptable"; binder Cα RMSD to design ≲ 2 Å (the pAE < 10 mark is calibrated for AF2 initial-guess; for other predictors report the value beside the controls' values rather than applying 10 as a pass line). A confident prediction in a different pose is a failure, not a pass. If only one independent predictor is available, run it with more seeds and label section 1 "single-predictor"; if none is, say so and report A2/A3/A5/A9 with the design-time predictor, marked not independent. A2. Monomer refold. Fold the binder alone (no target); require high pLDDT (> 80) and RMSD to the designed monomer ≲ 1–2 Å (≤ 3.5 Å bound-vs-unbound is BindCraft's filter). Flag fold-on-binding designs explicitly. A3. Controls through the identical protocol. Positives: a natural partner or known binder of the target extracted from a deposited complex if one exists (and an engineered high-affinity variant if public). Negatives: composition-preserving scrambles of several designs; a well-folded unrelated protein of similar size; and a decoy target (fold designs against an unrelated protein of the same fold class as the target). Report the score distributions and where each design falls; a design that scores with the negatives fails this check. A4. Consensus rule. State a rule before looking (e.g. "every independent predictor you ran — at least one, held back from selection — reproduces the designed pose at DockQ ≥ 0.49 and its interface confidence is in the range of the positive controls") and apply it uniformly; note that once used for selection it is no longer an independent check. A5. Function/epitope test by superposition. Superpose the natural partner's complex onto each predicted design complex; report steric clash with the partner and fraction of the partner's footprint covered → "predicted blocker: yes/no". Footprint overlap alone is weaker than clash. A6. Specificity and cross-reactivity panel (when sequences are available or can be staged): co-fold each design against the target's closest human paralogs and same-family domains and 1–2 unrelated same-fold decoys (want low confidence), and against mouse/cynomolgus orthologs (cross-reactivity is usually WANTED for animal models — report it as such). Co-folding confidence discriminates on/off-target only roughly; say so. A7. Binding-dead control mutants. For the top designs, propose 2–3-residue hotspot knockouts or charge reversals at the designed interface and re-predict; expect confidence/pose to collapse. Single-Ala changes rarely move co-folding scores — do not present this as a ΔΔG scan (that needs Rosetta/FoldX). Output: a named binding-dead mutant per lead for the lab. A8. Self-association. Co-fold two copies of each binder; a confident homodimer, especially one burying the binding face, is a flag (designed binders have turned out dimeric by SEC-MALS). A9. Native-context checks. From the target's UniProt entry: N-glycosylation sequons and annotated glycosites, disulfides, natural variants and isoform boundaries near the footprint — a design made against a bare, truncated crystal construct can target a surface that is glycan-covered or absent on the cell. Re-predict leads against the full extracellular region (or full domain architecture), not just the truncated construct you designed against, and check approach direction relative to the membrane/other domains. A10. Pose persistence. Across seeds, predictors and (optionally) short MD, report interface-contact persistence and pose RMSD spread; treat MD as a red-flag screen only — there is no published evidence we know of that it raises hit rates beyond A1-type filters. A11. Physics-lite interface metrics (label uncalibrated if no Rosetta/FoldX): buried SASA, shape complementarity, interface H-bonds/salt bridges, buried unsatisfied polar atoms, interface hydrophobic fraction.
Part B — Developability profile (CPU; per design)
See references/developability-checks.md for motif lists and how to compute each item with biopython/freesasa/DSSP. B1. Chemical liabilities with solvent exposure and interface membership: deamidation (NG ≫ NS > NT/NN), Asp isomerisation (DG, DS), Asp-Pro, exposed Met/Trp (oxidation), N-X-S/T sequons, free Cys, N-terminal Gln. B2. Charge: pI, net charge at pH 7.4, largest positive and negative surface patches; interface His count (pH sensitivity). B3. Hydrophobic surface: largest hydrophobic patch and a SAP-like score, reported separately for the binding face and the rest of the surface (the interface may be hydrophobic; the free surface should not be). B4. Aggregation-prone stretches (sliding-window hydrophobicity/β-propensity heuristic; a dedicated predictor such as Aggrescan3D/CamSol/TANGO if installed and licensed where required) and low-complexity/poly-ion runs. B5. Protease exposure: canonical trypsin/chymotrypsin/Asp-N sites that sit in loops with high SASA. B6. Stability proxies: monomer pLDDT, design-vs-refold RMSD, inverse-folding/LM log-likelihood, helix capping/buried polar sanity; note de novo miniproteins are typically hyperstable (Tm > 70–90 °C) so this is a sanity check, not a ranking. B7. Designability: sequence recovery of the designed backbone by an inverse-folding model and how many alternative sequences refold to it. B8. Format and manufacturability: which terminus is solvent-exposed and ≥ 15–20 Å from the interface (tag / Fc / albumin-binder attachment); expression host implied (Cys-free, no glycosylation → E. coli); A280 measurability (Trp/Tyr present?); gene-synthesis complexity of a codon-optimised gene (GC%, repeats, homopolymers); intended therapeutic/imaging format and its PK implication — an unmodified protein < 30–50 kDa is renally filtered (half-life of order minutes–hours); half-life comes from format (Fc, albumin binding, PEG/polypeptide fusion), not sequence. Do not report a "predicted PK" beyond this. B9. Immunogenicity: if an HLA-II epitope predictor is available, report predicted epitope density vs reference proteins; otherwise list it under "not checked". "Humanness" is undefined for de novo sequences; aggregation and epitope content are the computable levers; the real assessment is in vitro. B10. What must go to the lab regardless: expression/solubility/SEC, affinity and kinetics, specificity panel, Tm, protease/serum stability, structure of the complex, in-vitro immunogenicity, any PK.
Part C — Reporting
Write a markdown dossier covering these nine topics (template: references/dossier-template.md): (1) binding evidence beyond the objective + controls + consensus call; (2) function/blocker; (3) specificity and species cross-reactivity; (4) robustness (pose persistence, self-association, refold-alone; binding-dead mutants for leads); (5) native context; (6) developability per design; (7) interface metrics (uncalibrated); (8) candidates set aside and why; (9) not checked and why. Plus one per-design CSV keyed by the binder sequence, so rows can be joined to whatever table lists the designs. Use the limits language in references/honest-limits.md verbatim or close to it: co-folding models share training data, so agreement is correlated evidence; controls show the pipeline is not trivially fooled, not that designs bind; confidence filters raise lab hit rates but do not predict affinity; developability descriptors are shown against references, not as pass/fail.
Order of work when time is short
Controls first (A3), and through each new protocol as it is introduced → at each design round: B1–B4, B7, B8 and A8 on the shortlist (minutes) plus A1/A2/A5 on the current top N, dropping or redesigning on the results → before the final pick: complete A1/A2 on everything still kept (including the predictor held back from selection) and apply the A4 rule, then A9 and A6/A7 on the leads → the remaining items (A10, A11, B5, B6, B9) → write up, always leaving time for topic (9). If you only discover this skill at the end, run it in the listed order on the final set and say in the dossier that it was applied post hoc.
Files
- ATTRIBUTION.mdAdded by AutoGineer874 B
- DECLARED-USE-CASE.md5.4 KiB
- LICENSE.txt10.0 KiB
- README.md35.9 KiB
- SKILL.md14.6 KiB
- TOOLS.md.example3.5 KiB
- backtests.md26.9 KiB
- cluster/README.md9.8 KiB
- cluster/gpu-job.example.yaml3.1 KiB
- cluster/workspace.example.yaml2.2 KiB
- references/developability-checks.md6.9 KiB
- references/dossier-template.md3.7 KiB
- references/honest-limits.md1.9 KiB
- references/thresholds.md6.9 KiB
- rubric.md15.3 KiB
- sample/README.md7.5 KiB
- sample/fetch-sample.shScript2.9 KiB
- sample/ground-truth.yaml7.2 KiB
- scripts/sequence_profile.pyScript12.8 KiB
- steps.md6.3 KiB
steps.md
Step catalogue — what runs, in what shape
The design-and-screen loop in the guide breaks into the steps below. On a GPU machine (Route A) each GPU step is one tool run in the working folder; on a cluster (Route B) it is one batch job as cluster/README.md describes; the CPU steps run wherever Claude Code runs. Commands are written generically on purpose: the exact invocation of each tool on your machine or in your image is what your TOOLS.md records (start from TOOLS.md.example); nothing here is a real flag of any tool. Paths are relative to the working folder (/work inside a cluster job). Keep every script you write for a step under jobs/, with its log beside it.
Times are orders of magnitude for a first run — about thirty designs chosen from a few hundred candidates of 50–120 residues against a single domain, on one data-centre GPU with 40 GB of memory or more — and depend on the tool, the build, the GPU and the lengths. Time your own first small batch and plan from that, not from this page.
Batching rule. One tool run (or job) per tool per batch, never one per candidate: loading a model takes longer than scoring one more complex, and on a cluster every job also pays scheduling and image start-up. Batches of 50–200 candidates are a good unit. Two light steps that always follow each other (backbone generation then sequence design) can share one run as step-one && step-two.
0. Target preparation — CPU
Inputs: the target FASTA, the public structures, the alignment if you built one (guide section 6). Claude Code trims the construct, picks the site and writes target/README.md with the residues chosen and why. On a cluster, target/ and TOOLS.md are then copied onto the work volume. Output: target/.
1. Backbone generation — GPU
Inputs: target/, the site residues, a length range. Command shape: the generator's own command line as TOOLS.md gives it, writing into backbones/<batch>/. Use at least two different generators across the campaign (for example RFdiffusion or a successor, BindCraft, PXDesign, BoltzGen, Proteina-Complexa, the ESM cookbook's gradient-guided design through ESMFold2 or another open generator you have installed; some of these design the sequence as well, in which case step 2 is a redesign or is skipped for that batch). A generator that optimises each design against a structure predictor makes that predictor part of your objective: for example, BindCraft does this with AlphaFold2-multimer, the ESM cookbook recipe with ESMFold2 and mosaic with Boltz-2. Do not count that predictor as an independent check on that generator's designs, and hold back a different one for step 6. Output: one model per candidate backbone in complex with the target. Typical: minutes to tens of minutes per batch of 50–200; memory well inside a 40 GB card at these sizes.
2. Sequence design — GPU, light
Inputs: backbones/<batch>/. Command shape: ProteinMPNN or SolubleMPNN (both from the LigandMPNN code base) over the whole batch folder, target chain fixed, a few sequences per backbone, writing sequences/<batch>.fasta plus a table mapping sequence id to backbone. Typical: seconds to a few minutes per batch. Cheap enough to share a run with step 1.
3. Complex re-prediction — GPU, the bulk of the time
Inputs: sequences/<batch>.fasta, the target sequence (and its alignment for predictors that use one). Command shape: one predictor over one batch, each candidate as a two-chain complex with the target, N seeds, writing models and confidence files under predictions/<predictor>/<batch>/. Run two or three predictors that see the problem differently — whichever of ESMFold2, Protenix, AlphaFold2-multimer (through ColabFold), Boltz-2 and Chai-1 you have installed — and keep one more back for step 6. One run per predictor per batch. Typical: of the order of 10–60 seconds per complex per seed, so this step dominates; screen cheaply first (one fast predictor, one seed, the whole batch), then spend seeds and the slower predictors only on what survives. Memory: the alignment-based and diffusion-based predictors are the ones that need the larger cards and more host memory.
4. Scoring, pose agreement and clustering — CPU
Inputs: predictions/, backbones/. Command shape: an ipSAE script over each prediction's aligned-error output (the interface score of Dunbrack, 2025), ipTM and interface pLDDT from the predictors' own confidence files, DockQ or an interface RMSD between the design model and each refold (pose agreement), and TM-align or US-align all-against-all on the binders for structural clusters. On a cluster this runs in the utility pod or as a CPU-only job, or locally after copying the confidence files back. Output: scores/<batch>.csv, one row per candidate per predictor, merged into designs.csv. Typical: minutes.
5. In-loop checks from the binder-gauntlet skill — CPU, plus more of step 3
The binder-gauntlet skill's cheap checks (sequence composition, similarity to the target and its known partners, liabilities, and the like) run where Claude Code runs, on designs.csv, every selection round, and cost no GPU time. The structural controls it asks for — the binder folded alone, a shuffled-sequence control, the natural partner as a positive reference — are further step-3 runs over small FASTA files; batch them together rather than one run each.
6. Final pass with the held-out predictor — GPU
Inputs: the thirty or so selected designs as one FASTA. Command shape: the predictor you did not use in steps 3–5, more seeds than the screen used, writing predictions/final/; then step 4 once more over that folder. One run. Typical: well under an hour at this size. Its numbers go into the report next to the screening numbers, with the disagreement stated, as the guide's section 9 asks.
Parallelism
On one GPU, run one GPU step at a time and do CPU work (reading earlier results, the skill's checks, the report) while it runs. On a machine with several GPUs, or on a cluster, steps are independent: start several in the background — different batches, or different predictors over the same batch — up to the number of GPUs you have or your quota allows. On a cluster, more than that only queues jobs as Pending while their deadlines tick.
Requirements and compatibility
Written for: Claude Code, Claude apps
Works with: Claude Code, Claude apps, OpenAI Codex, GitHub Copilot, Cursor, Gemini CLI, Kiro, OpenCode, Goose, Amp, Roo Code, JetBrains Junie, Factory Droid, Devin (ex-Windsurf), Mistral Vibe, OpenHands, Letta
“Works with” means the tool reads the open Agent Skills format; a skill written for one tool may use features others lack.
Needs: Needs Python
The author says: Method-only skill. Part B's sequence checks run with the bundled script (python3, standard library only). Structure-based checks use whatever structure predictors and python structure libraries (biopython, freesasa, DSSP) the session has. No network access and no model calls.
Security
What our scanner noticed· Low risk
- Scripts that your agent may run
This skill includes scripts that your agent may run. Read them before you use it.
A static scan is not a guarantee. Skills are third-party content: review a skill before you let an agent use it.
Attribution and licence
- Published by
- Anthropic
- Publisher
- Anthropic (Official)
- Source
- anthropics/life-sciences · binder-gauntlet · commit 0d38fe5
- Licence
- Apache License 2.0 (redistribution allowed)
- ATTRIBUTION.md (written by AutoGineer)
- Synced
AutoGineer is not affiliated with or endorsed by Anthropic.
Download ZIP
The ZIP holds the skill’s files, its licence files and an ATTRIBUTION.md. Download binder-gauntlet.zip