Boltz Protein Screen

by boltz-biobeafb3c16236No license5 starsListed Oct 8, 2026Updated Oct 8, 2026Repository updated 4 weeks ago

Screen existing protein binders with Boltz. Use when ranking a supplied protein, peptide, antibody, nanobody, or binder library against a target. Not for designing new proteins or screening small molecules.

AI-generated overview

Screens supplied protein, peptide, antibody or nanobody binder libraries against a target using the Boltz API and ranks hits.

What it does
Guides an agent through submitting a binder library screen to the Boltz protein:library-screen API: normalizing candidate binders, choosing a structure-template or sequence-only target, authoring the payload, estimating cost, submitting the job, and downloading results. It then ranks hits from results/index.jsonl by binding_confidence, using iptm and min_interaction_pae as tiebreakers. It also covers authentication, sandbox escalation, long-running download handling and follow-up status checks.
When to use it
Use it when the user already has candidate proteins, peptides, antibodies, nanobodies or a binder library and wants them ranked against a given target. It is not intended for designing new proteins or for screening small molecules.
Requirements
Requires the boltz-api CLI on PATH with valid authentication (device-code login) and network access to the Boltz API; a companion boltz-cli-setup skill is referenced for install, auth and sandbox guidance. It ships no scripts, only instructions plus reference documents.

Workflow

If boltz-api is missing from PATH, use boltz-cli-setup for install/update guidance before retrying. If a command reports missing or expired authentication, use boltz-cli-setup to start boltz-api auth login --device-code before retrying; do not ask permission first. If the agent host sandbox blocks boltz-api install/auth/API calls, use boltz-cli-setup to request the host sandbox bypass/escalation needed for user-wide CLI install, browser login, credential storage, temp files, or API access before retrying.

Use this skill when the user already has candidate proteins / peptides / antibodies / nanobodies.

  1. Normalize the binder library into proteins — a list of candidate complexes. For a simple sequence library each entry has one protein entity; multi-chain candidates (antibody heavy+light) are also allowed.
  2. Pick the target variant:
    • structure_template — user has a CIF/PDB file or URL; select which chains are polymer vs ligand, which residues to keep (crop_residues), and optionally epitope_residues / flexible_residues.
    • no_template — user has only sequences; pass them as target.entities plus optional epitope_residues.
  3. Don't add bonds / constraints unless the user asks for geometry constraints.
  4. Author the payload YAML or JSON, run estimate-cost, show the USD cost, wait for explicit confirmation.
  5. start to submit. Capture the ID.
  6. Launch download-results through the runtime's long-running or non-blocking command facility. Use the mechanism the runtime documents; consult boltz-cli-setup if unsure. After launching the downloader, always report the job ID, run name, and output directory. If the runtime can schedule follow-up checks, schedule a download-status check and state the cadence; otherwise include the download-status command.
  7. Rank hits from <output-root>/<run-name>/results/index.jsonl by binding_confidence descending. Use iptm and min_interaction_pae as tiebreakers. optimization_score is not emitted for this endpoint. Read references/results.md [blocked] for output layout and metric details.

Command Pattern

bash
# Replace placeholders with concrete absolute paths before running.# Use a short descriptive run name, for example: protein-screen-<target>-<library>-v1
boltz-api protein:library-screen estimate-cost \  --input @yaml:///absolute/path/payload.yaml
boltz-api protein:library-screen start \       --idempotency-key "<run-name>" \       --input @yaml:///absolute/path/payload.yaml \       --raw-output --transform id
# Copy the printed job ID into this command, then launch it through the# runtime's long-running/non-blocking command facility (consult boltz-cli-setup# if unsure). Do not detach it with shell "&" or nohup unless the runtime# documents shell backgrounding as its supported mode.boltz-api download-results \  --id "<job-id-from-start>" --name "<run-name>" \  --root-dir "/absolute/path/boltz-experiments" \  --poll-interval-seconds 30

Payload keys are proteins, target — API body field names.

Always Do This

  • For structure_template, embed CIF/PDB bytes with @data:///abs/path/target.cif inside the structure.data field. Don't use bare @path (automatic file-type detection once sent CIF as plain text into a base64 field and broke the server parser).
  • Residue indices are 0-based. epitope_residues and flexible_residues must be subsets of crop_residues.
  • Keep payload field names exactly as the API body names shown in references/api.md.
  • Use absolute paths for the output root, payload files, and embedded target files. Do not cd into the run directory for follow-up commands; pass the same --root-dir and use absolute paths so later relative paths do not drift.
  • Prefer one merged top-level payload via --input @yaml:///absolute/path/payload.yaml or @json:///absolute/path/payload.json for estimate-cost and start. Keep --idempotency-key and --workspace-id top-level; if they also appear inside --input, the top-level flags win.
  • Direct object flags still work as overrides, such as --target @yaml:///absolute/path/target.yaml or repeated --protein @json:///absolute/path/protein-1.json entries. Piped YAML / JSON on stdin also works, but it must use API body field names. Never use @file:// or @./.
  • Use the same slug as both --idempotency-key and --name.
  • In permission-gated runtimes, keep each Boltz call as a top-level command that starts with boltz-api. Prefer concrete arguments over sh -c, inline environment assignments, aliases, wrapper scripts, loops, or pipelines around the boltz-api invocation unless the user already allowed that exact command form. Use --raw-output --transform id, read the printed ID, then paste that literal ID into the next download-results command.
  • Run download-results through the runtime's long-running or non-blocking command facility, using the mechanism the runtime documents rather than tool arguments you assume exist. Do not detach it with shell & or nohup unless the runtime documents shell backgrounding as its supported mode; some tool runners reap shell-backgrounded children before .boltz-run.json is written. If unsure how this runtime handles long-running commands, consult boltz-cli-setup.
  • After the download starts, do not manually wait on it or run ad hoc polling loops. Wall-clock time scales roughly with the number of candidates in the library: under 100 often finishes in a few minutes, 100-1,000 may take several minutes to tens of minutes, and larger screens can take longer or hours depending on inputs and system load. Don't quote a fixed duration. --poll-interval-seconds 30 is a reasonable downloader default. download-results emits JSONL progress on stderr by default; add --progress-format text --verbose only when you explicitly want human-readable logs.
  • If the runtime can schedule follow-up checks (a heartbeat, scheduled task, or reminder), schedule one after launching download-results. It should run boltz-api --format json download-status --name "<run-name>" --root-dir "/absolute/path/boltz-experiments", post only material status changes or terminal completion/failure, and stop once terminal. Choose cadence by candidate count: under 100 -> every 1-2 minutes; 100-1,000 -> every 5 minutes; over 1,000 -> every 15 minutes. If the runtime cannot schedule follow-ups, do not claim an automatic next check: report the job ID, run name, output directory, and the download-status command. Poll a saved session handle only for interactive, user-requested progress checks; never run a manual poll loop in the current turn.
  • If detached download needs to be restarted, re-run boltz-api download-results with the same --name "<run-name>" and the same --root-dir.
  • Cost is tiered by total complex length (target + candidate); the combined length sets the tier. Do not state or estimate a dollar figure yourself — to say anything about cost, run estimate-cost and quote only the number it returns.

Escape Hatch

Read references/api.md [blocked] for the proteins list shape and both target variants (structure_template with chain_selection, and no_template with epitope hints). Read references/results.md [blocked] after download when ranking screened binders or explaining outputs.

Outputs

Rank from results/index.jsonl after download-results; use references/results.md [blocked] for local file layout and metric meanings.

Source and attribution

Source:boltz-bio/boltz-api-skillsinplugins/boltz/skills/boltz-protein-screenat commitbeafb3c

License: No license

Content belongs to its original authors. SourceWeft indexes it from a public repository.

Report or request removal