Binder Gauntlet

AnthropicOfficialPublished by Anthropic

Skill
Workflow
Science and research
Apache-2.0
Low risk
Has scripts

From the author

Validation and developability gauntlet for de novo designed protein binders and miniproteins against any protein target. Use this skill when designed binders are scored only by structure-predictor confidence (ipSAE, ipTM, pAE) and you must validate binding with independent re-prediction, pose agreement (DockQ) and controls, profile developability and sequence liabilities, check specificity and cross-reactivity, and write a validation dossier before you rank, filter or finalise binder designs, and at every selection round of a design campaign to steer it. Use when a user says "validate these binder designs", "run the gauntlet on these", "check developability" or "sequence liabilities", asks which designs should go to the lab, or asks for controls, a specificity panel or a validation dossier for designed binders.

— the description by Anthropic

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/download

Unzip 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-test should 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

cluster/README.md

Running the GPU steps as batch jobs on a cluster

Status: written down, not yet run on a customer's cluster. The design loop this drives has been run many times on single data-centre GPUs, which is the guide's Route A. What is untested is pushing each step through a cluster scheduler from a Claude Code session. Expect to adjust node selection, storage and the image for your site.

This is the guide's Route B. Claude Code still holds the loop; the only change from Route A is that each GPU step in steps.md becomes one batch job that the session writes, submits with kubectl or sbatch, waits for, and reads back. There is deliberately no wrapper script here: your platform team already has conventions for GPU jobs, and a session that calls kubectl and sbatch directly, under the rules below, adapts to them faster than a tool of ours would. This page is the cluster-side checklist, one example manifest per object, and those rules. Do Route A once first, so that your TOOLS.md is proven before the cluster adds its own unknowns.

What the cluster side needs

Kubernetes

Where Claude Code runs: any machine with kubectl and a kubeconfig context for the cluster. It needs no GPU itself.

One namespace, and an identity scoped to it that can create, get, list, watch and delete Jobs, Pods and PersistentVolumeClaims, read pods/log and use pods/exec — nothing cluster-wide, no node access. A Role of roughly this shape, bound to your user or service account, is enough on a default cluster; check it against your cluster's admission policies, since some sites also require quotas, priority classes or pod-security labels on the namespace:

kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata: {name: binder-design, namespace: <your-namespace>}
rules:
  - {apiGroups: ["batch"], resources: ["jobs"], verbs: ["create", "get", "list", "watch", "patch", "delete"]}
  - {apiGroups: [""], resources: ["pods", "persistentvolumeclaims"], verbs: ["create", "get", "list", "watch", "patch", "delete"]}
  - {apiGroups: [""], resources: ["pods/log"], verbs: ["get"]}
  - {apiGroups: [""], resources: ["pods/exec"], verbs: ["create", "get"]}

A container image, pullable from that namespace, with the tools from the guide's section 4 and their weights baked in, plus bash and tar. Building it is a task for whoever administers your compute: each tool's own repository is its install guide, the weights go in at build time so that no job downloads anything, and your TOOLS.md records what went in and how each tool is called inside it.
A work volume that every job mounts at /work: one PersistentVolumeClaim, on a ReadWriteMany storage class if your cluster offers one (then pods may land on any GPU node); otherwise ReadWriteOnce with every pod pinned to one GPU node by a kubernetes.io/hostname selector, which is fine for a first run. Tens of gigabytes is enough when the weights are in the image. A small utility pod that mounts the same volume and sleeps gives kubectl cp and kubectl exec somewhere to land; workspace.example.yaml is the shape of both.
The GPU resource name your device plugin advertises (nvidia.com/gpu unless your platform team says otherwise) and the node labels and taints your GPU pool carries, which become the Job's nodeSelector and tolerations; these vary by cloud and by site. If your role may read nodes, kubectl --context <ctx> get nodes --show-labels shows them; otherwise ask.
A GPU quota you know. Jobs beyond it sit Pending, and a Job's deadline counts that waiting time.

Write the context, namespace, image, GPU resource name, node selector and tolerations, storage class and a short run id into the "Where the GPU work runs" section of your TOOLS.md (the guide's TOOLS.md.example has the lines). gpu-job.example.yaml is the shape of one step: the session copies it per step, fills in the name, command and resources, applies it, waits for it with kubectl wait or by polling kubectl get job, saves kubectl logs under jobs/ in your working folder, and reads the result. Small inputs go onto the volume and small outputs come back with kubectl cp against the utility pod; short CPU commands (listing a folder, a scoring script over confidence files) run there with kubectl exec.

Slurm

Run Claude Code on a login node, from a working folder on the filesystem the compute nodes share, with the tools installed in an environment or container the compute nodes can activate. Each GPU step is a short batch script the session writes under jobs/ and submits with sbatch --wait, so the command returns when the step ends; the script names the partition, --gres=gpu:<n>, --cpus-per-task, --mem, --time and whatever account or QoS options your site requires, activates the environment on its first line, and writes its log beside itself. squeue -u $USER and sacct -j <id> --format=State,Elapsed,MaxRSS give status and the reason for a failure; inputs and outputs are already on the shared filesystem, so nothing is copied. Put the partition, the extra sbatch options and the activation line in TOOLS.md. Check the --gres spelling and the time format your site expects.

Rules the session follows on a cluster

Paste these rules into your first message.

Stay in the box. Every kubectl command carries --context <ctx> -n <namespace> explicitly, never whatever the current context happens to be; every sbatch names the partition. No cluster-scoped command, ever.
Name, label, and remove narrowly. Every object is named <run-id>-<step>-<suffix> and labelled app=binder-design,run=<run-id>. Objects are removed by exact name, after listing what carries both of this run's labels; never by one broad label on its own, never across namespaces. In a shared namespace a broad selector removes other people's work.
Bounded jobs only. Every Job has backoffLimit: 0, an activeDeadlineSeconds, CPU, memory and GPU limits, automountServiceAccountToken: false, no secrets mounted and no network use; its command tees its own output to /work/logs/ so the log survives a deadline kill. Slurm scripts carry --time and write their log to the shared folder.
One job per tool per batch of candidates, never one per candidate: loading a model costs more than scoring one more complex. Several jobs at once only up to the GPU quota you state; long steps run in the background while the session reads earlier results and keeps the report current.
On failure, change something. Read the Job's status reason (DeadlineExceeded, OOMKilled, a non-zero exit) and the log tail, say in one line what went wrong and what will be different, then resubmit. Never the same command into the same failure.
Pull back tables and selected models, not whole prediction folders; keep designs.csv and report.md current in the working folder as the guide asks. Finish with nothing running, remove this run's utility pod by name, and leave the volume until you have copied what you need; remove it, by name, only when you say so.

Security and data handling

Least privilege. A namespace-scoped identity; no node access; no service-account token in any pod; no secrets mounted, because no step needs one.
No network from jobs. With weights in the image and inputs on the volume, no step makes an outbound call. Where your network plugin enforces NetworkPolicy, a default-deny egress policy on the namespace turns that from a property of the tools into a guarantee.
What is on the volume — target files, every candidate sequence and model, the scores — is, on your own targets, the confidential material the guide's section 10 describes. Put the namespace and its storage where such material may live, and remove the volume when the campaign is archived.
What goes to the model is only what the session reads: job status, log tails, and the tables and files it opens. The bulk stays on the volume or the shared filesystem.

Troubleshooting

Symptom	Likely cause	What to do
A Job's pod sits `Pending`, then the Job ends `DeadlineExceeded`	No free GPU of the kind you selected, a node selector or toleration that matches no node, or the namespace quota is used up	While it is `Pending`: `kubectl --context <ctx> -n <ns> describe pod <pod-name>`; the Events section names the reason. Fix the selector or tolerations in `TOOLS.md`, wait for quota, or ask for fewer GPUs at once.
`OOMKilled`	The container hit its memory limit (host memory, not GPU memory)	Raise the memory limit; alignment-based and diffusion-based predictors need more. GPU out-of-memory shows in the log instead: smaller batches, or one predictor per job.
`ErrImagePull` / `ImagePullBackOff`	Wrong image name, or the namespace cannot read your registry	Check the image line in `TOOLS.md`; add `imagePullSecrets` to both manifests.
The utility pod is `Pending` with a volume event	The storage class does not support the access mode asked for, or a ReadWriteOnce volume is attached to another node	See "A work volume" above; `describe pvc` and `describe pod` say which.
Permission denied writing under `/work`	The image runs as a non-root user and the fresh volume is root-owned	Set `securityContext.fsGroup` to the image user's group in both manifests.
A tool cannot find its weights, or tries to download them	The weights path inside the image differs from what `TOOLS.md` says, or the tool defaults to fetching	Fix `TOOLS.md`; point the tool's weights or cache variable at the baked-in path.
Slurm job ends `TIMEOUT` or `OUT_OF_MEMORY` in `sacct`	`--time` or `--mem` too small for the batch	Time one small batch first and size from that; split the batch.

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

2026-11-08

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