Complexa Evaluate Pdbs
NVIDIAOfficialPublished by NVIDIA
- Skill
- Workflow
- Science and research
- Apache-2.0
- Medium risk
- Has scripts
AutoGineer summary
Written by AutoGineer from the skill’s own files, not by the author
The complexa-evaluate-pdbs skill provides a structured workflow to evaluate directories of pre-existing PDB files. It utilizes the Proteina-Complexa CLI to perform refolding and metric computation, including interface pAE, i_pLDDT, scRMSD, and designability scores. The skill supports various design types such as protein binders, ligand binders, and AME (motif-ligand) designs, allowing users to assess outputs from third-party tools like BindCraft, AlphaProteo, or RFdiffusion. It handles the full evaluation pipeline from pre-flight environment checks to final manifest generation.
What it does
- Refolds PDB files using backends like AF2, RF3, ESMFold, or Boltz2.
- Computes interface metrics including i_pAE, i_pTM, pLDDT, and scRMSD.
- Assesses monomer and codesignability through ProteinMPNN-based redesign.
- Calculates motif-specific metrics such as motif RMSD and sequence recovery.
- Aggregates results into CSV summaries with pass-rate analysis based on defined thresholds.
- Generates a run manifest to track configurations, git SHAs, and output paths for reproducibility.
When to use it
- When you need to evaluate a directory of pre-existing PDB designs.
- When assessing the quality of third-party protein binder or ligand binder outputs.
- When performing motif-aware evaluation for enzyme or AME designs.
- When you need to generate standardized pass-rate reports for a set of protein structures.
Advantages
- Automates the complex evaluation-to-analysis pipeline for protein designs.
- Supports multiple folding backends and design types within a unified configuration framework.
- Provides standardized metrics and success thresholds for consistent result interpretation.
- Includes pre-flight checks to ensure hardware and environment readiness before execution.
Usage examples
- “Evaluate my protein binder PDBs in /data/designs using AF2.”
- The agent runs the pre-flight check, then executes the complexa analysis command with the protein_binder configuration and colabdesign backend.
- “Score these ligand binder designs in /data/ligands.”
- The agent identifies the ligand_binder type, configures the RF3 folding backend, and runs the evaluation and analysis steps.
Install
Download the skill as a ZIP:
https://mp-staging.autogineer.com/agent-skills/nvidia/complexa-evaluate-pdbs/downloadUnzip it into the cross-client skills folder of your project:
mkdir -p .agents/skills && unzip complexa-evaluate-pdbs.zip -d .agents/skills
Documentation by NVIDIA
Complexa Evaluate-PDBs Skill
Score a directory of pre-existing PDB files against the same metrics Proteina-Complexa uses internally. Wraps complexa analysis <evaluate_config> ++sample_storage_path=<dir>: the CLI runs the evaluate step (refold + interface metrics + monomer metrics) and then the analyze step (success thresholds, diversity, pass-rate CSVs). Do not run complexa generate here — the inputs already exist.
What this skill enables
Re-fold a directory of designed PDBs with AF2 (
colabdesign), RF3 (rf3_latest), ESMFold (esmfold), or Boltz2 (boltz2_default).Compute binder interface metrics:
i_pAE,min_ipAE,i_pTM,pLDDT, binder/complex scRMSD.Compute monomer designability (ProteinMPNN-redesigned scRMSD) and codesignability (original sequence refold scRMSD).
For motif inputs: motif RMSD (CA + all-atom), motif-region designability/codesignability, sequence recovery.
Aggregate into per-PDB CSVs plus pass-rate summaries using the default thresholds for the
result_type.
Step 1: Pre-flight
Always check GPU / disk / tool binaries before launching a refold job. RF3 and ColabDesign-AF2 are large.
bash scripts/preflight.shSurface from preflight.json:
gpu.availableandgpu.vram_gb— colabdesign/RF3 need ≥40 GB; ESMFold tolerates ≥24 GB.env.missing_required— must include the keys for the chosen folding backend:colabdesign→AF2_DIRrf3_latest→RF3_CKPT_PATH,RF3_EXEC_PATHesmfold→ ESMFold weights resolvable
tools.{foldseek,mmseqs}— required byaggregation.compute_diversity/compute_mmseqs_diversity(both defaulttrue).
If any required key is missing, route the user to the complexa-setup skill.
Step 2: Identify the design type
Like complexa design, evaluation has one default flow (protein binder) and two extensions (ligand binder, AME). The evaluate config you pass to complexa analysis decides everything else (which metrics, which refolder defaults, which thresholds the analyze step applies).
Default — protein binder
complexa analysis configs/evaluate_from_pdb_dir.yaml \
++sample_storage_path=/abs/path/to/pdbs \
++dataset.task_name=02_PDL1 \
++result_type=protein_binder \
++metric.binder_folding_method=colabdesign \
++metric.inverse_folding_model=soluble_mpnn \
++run_name=eval_pdl1_af2Use this when the user's PDBs are protein-binder designs (multi-chain, binder is the last chain) or third-party outputs from BindCraft / AlphaProteo / RFdiffusion. Pulls thresholds for protein_binder (i_pAE * 31 ≤ 7.0, pLDDT ≥ 0.9, scRMSD_ca < 1.5 Å).
Extensions — pick the matching config
| Design type | Use the protein-binder default? | Evaluate config | Analyze config | result_type | Default backend |
|---|---|---|---|---|---|
| Protein binder | Yes (default) | configs/evaluate_from_pdb_dir.yaml | configs/analyze.yaml | protein_binder | colabdesign (AF2) |
| Ligand binder (binder + small-molecule) | Same evaluate config, swap 3 overrides | configs/evaluate_from_pdb_dir.yaml | configs/analyze.yaml | ligand_binder | rf3_latest |
| AME / motif + ligand (enzyme outputs) | No — needs motif-aware config | configs/evaluate_ame_from_pdb_dir.yaml | configs/analyze_motif_binder.yaml | motif_ligand_binder | rf3_latest |
| Motif protein binder (standalone) | No — no _from_pdb_dir variant | configs/evaluate_motif_binder.yaml + ++input_mode=pdb_dir | configs/analyze_motif_binder.yaml | motif_protein_binder | colabdesign / rf3_latest |
Extending to ligand binder (same evaluate config as default, three override swaps):
complexa analysis configs/evaluate_from_pdb_dir.yaml \
++sample_storage_path=/abs/path/to/pdbs \
++dataset.task_name=39_7V11_LIGAND \
++result_type=ligand_binder \
++metric.binder_folding_method=rf3_latest \
++metric.inverse_folding_model=ligand_mpnn \
++run_name=eval_v11_rf3Extending to AME (different config; ligand auto-completion gotcha — see Step 4):
complexa analysis configs/evaluate_ame_from_pdb_dir.yaml \
++sample_storage_path=/abs/path/to/pdbs \
++dataset.task_name=M0096_1chm \
++run_name=eval_ame_chmSee references/eval_configs.md for the full matrix (every result_type, every threshold default, every supported folding backend, motif-protein-binder variant).
Step 3: Gather inputs (AskUserQuestion)
Ask in one batched AskUserQuestion:
pdb_dir— absolute path to the directory of PDBs to evaluate.Design type — protein binder / ligand binder / AME (motif + ligand).
Folding backend —
colabdesign(AF2, protein binders),rf3_latest(ligand / AME),boltz2_default(alternative).Target / task name — must match a key in
configs/targets/targets_dict.yaml,configs/targets/ligand_targets_dict.yaml, orconfigs/design_tasks/ame_dict_v2.yaml. Required for binder + AME evaluation (needed to identify the target reference and, for AME, the motif contigs).AME-only: confirm ligand residue name is already renamed to
L:0in every PDB (see Troubleshooting). If not, do that rename first.
Step 4: Run evaluate → analyze
Prefer complexa analysis (the evaluate→analyze chain) — it reuses the same config for both steps and writes a single log dir.
# Protein binder PDB dir, AF2 refold
complexa analysis configs/evaluate_from_pdb_dir.yaml \
++sample_storage_path=/abs/path/to/pdbs \
++dataset.task_name=02_PDL1 \
++metric.binder_folding_method=colabdesign \
++metric.inverse_folding_model=soluble_mpnn \
++result_type=protein_binder \
++run_name=eval_pdl1_af2For ligand binders flip binder_folding_method=rf3_latest, inverse_folding_model=ligand_mpnn, result_type=ligand_binder. For AME use configs/evaluate_ame_from_pdb_dir.yaml — see references/eval_configs.md for full worked examples.
If you need to inspect output between stages, run them separately. The configs above are shared between evaluate and analyze:
complexa evaluate configs/evaluate_from_pdb_dir.yaml ++sample_storage_path=/abs/path/to/pdbs ++run_name=eval_pdl1_af2
complexa analyze configs/evaluate_from_pdb_dir.yaml ++run_name=eval_pdl1_af2Dry-run first if the user is unsure (no GPU work happens; the planned file walk + invocation prints):
complexa analysis configs/evaluate_from_pdb_dir.yaml ++sample_storage_path=/abs/path/to/pdbs ++dryrun=trueDirect module invocation (debug fallback)
complexa evaluate / analyze are subprocess wrappers around the Hydra
modules with logging + parallel job splitting bolted on. To attach a debugger
or run under a profiler, invoke the module directly:
python -m proteinfoundation.evaluate \
--config-path "$(realpath configs)" \
--config-name evaluate_from_pdb_dir \
++sample_storage_path=/abs/path/to/pdbs \
++dataset.task_name=02_PDL1 \
++metric.binder_folding_method=colabdesign \
++run_name=eval_debugFor normal one-shot runs prefer complexa analysis — you get the shared log
dir and a single replayable invocation, instead of having to thread the same
overrides through two python -m calls.
Step 5: Parse results
Output lands under ./evaluation_results/${run_name}/:
Per-PDB metrics CSV —
*_results_*.csv(one row per input PDB ×sequence_types).Pass-rate summaries — written by the
analyzestep (e.g.res_designability.csv,res_filter_ligand_pass_*.csv,success_criteria_*.json).Diversity output — FoldSeek/MMseqs2 cluster files when
aggregation.compute_diversity=true(default).
Summarize to the user:
Per-PDB row count and number of successful designs vs total.
Default-threshold pass rate by
result_type(e.g. forprotein_binder:i_pAE*31 <= 7.0 AND pLDDT >= 0.9 AND scRMSD_ca < 1.5).Top 5 designs by primary metric (
i_pAEfor protein,min_ipAEfor ligand,motif_rmsd_pred_allfor motif binders).
Step 6: Emit manifest
Capture the resolved invocation + outputs for replay.
python3 scripts/write_manifest.py \
--output-dir ./evaluation_results/${run_name} \
--command "complexa analysis configs/evaluate_from_pdb_dir.yaml ++sample_storage_path=<dir> ++dataset.task_name=<task> ++metric.binder_folding_method=<backend> ++run_name=<run>" \
--skill complexa-evaluate-pdbs \
--out ./eval_manifest.jsonThe manifest pins: resolved config, git SHA, ckpt SHA-256s, the result CSV paths, and the user-stated result_type for replay.
Most common overrides
| Override | Effect |
|---|---|
++sample_storage_path=<dir> | The directory of PDBs to evaluate (required). |
++dataset.task_name=<name> | Target / AME task name (binders, AME). Resolves target PDB + contigs. |
++metric.binder_folding_method=<backend> | colabdesign / rf3_latest / boltz2_default. |
++metric.inverse_folding_model=<model> | protein_mpnn / soluble_mpnn / ligand_mpnn. |
++metric.sequence_types=[self,mpnn,mpnn_fixed] | Which sequence flavors to refold. |
++metric.num_redesign_seqs=N | ProteinMPNN/LigandMPNN redesign count. |
++metric.compute_pre_refolding_metrics=true | Add bioinformatics/TMOL/HBPLUS metrics on the input structures. |
++metric.keep_folding_outputs=true | Save the refolded PDBs (large, but useful for inspection). |
++result_type=<type> | Override default thresholds: protein_binder / ligand_binder / motif_protein_binder / motif_ligand_binder. |
++aggregation.success_thresholds.<…> | Tighten or loosen specific thresholds (see references/eval_configs.md). |
++eval_njobs=N | Parallel GPUs for the evaluate step. |
++dryrun=true | Plan without running any folding. |
++file_limit=N | Cap input PDBs (handy for first-pass smoke tests). |
Hardware
GPU: ≥1 CUDA GPU. AF2 (
colabdesign) and RF3 (rf3_latest) need ≥40 GB VRAM (A100/H100/L40S). ESMFold runs on ≥24 GB. Multi-GPU via++eval_njobs=N.CPU/disk: 24 CPUs default (
ncpus_: 24). Each refolded PDB + intermediate output is ~1–5 MB;keep_folding_outputs=truecan balloon to tens of GB for thousands of inputs.See
references/hardware.mdfor per-backend wall-clock and VRAM tables.
Troubleshooting
Error: Config file not found— paths are relative to the repo root;cdto the repo before invokingcomplexa analysis.compute_motif_binder_metrics=Truebutresult_type=protein_binder—result_typeand the underlyingcompute_*_metricsmust agree. Useconfigs/evaluate_ame_from_pdb_dir.yamlfor AME inputs rather than mutatingevaluate_from_pdb_dir.yaml.RF3 shape errors on AME PDBs — RF3 tries to auto-complete the ligand atoms from CCD. Rename the ligand residue to
L:0in every input PDB before evaluation; see the snippet inREADME.md(atom_array.res_name[ligand_mask] = "L:0").Diversity step fails (
foldseek not found) —FOLDSEEK_EXECnot onPATH. Either fix.env(preferred) or disable:++aggregation.compute_diversity=false ++aggregation.compute_mmseqs_diversity=false.All pass-rates are 0% — check the
binder_folding_methodmatches the target type (RF3 for ligand, AF2 for protein) and that++dataset.task_nameresolves to the correct reference PDB (complexa target show <name>to verify).
Reference
Full evaluate/analyze config matrix, every supported result_type, per-threshold defaults, and three worked examples (protein binder / ligand binder / AME): see references/eval_configs.md.
Files
- ATTRIBUTION.mdAdded by AutoGineer885 B
- BENCHMARK.md7.7 KiB
- LICENSELicence file added by AutoGineer11.2 KiB
- SKILL.md12.7 KiB
- config/skillspector-baseline.yml1.2 KiB
- evals/evals.json5.0 KiB
- evals/trigger_evals.json1.4 KiB
- references/CONFIGURATION_GUIDE.md34.7 KiB
- references/EVALUATION_METRICS.md55.9 KiB
- references/INFERENCE.md14.9 KiB
- references/SEARCH_METADATA.md7.7 KiB
- references/SWEEP.md10.6 KiB
- references/eval_configs.md12.4 KiB
- references/hardware.md4.8 KiB
- scripts/preflight.shScript8.4 KiB
- scripts/write_manifest.pyScript9.6 KiB
- skill-card.md5.3 KiB
- skill.oms.sig7.0 KiB
references/SWEEP.md
Sweep System
How to run parameter sweeps and override experiment settings without modifying source code.
Documentation Map
Running a design? See Inference Guide.
Tuning YAML configs? See Configuration Guide.
Understanding metrics? See Evaluation Guide.
Search metadata? See Search Metadata.
Overview
The sweep system has two mechanisms that work together:
--sweeper FILEloads a YAML file defining one or more parameter axes. All combinations are generated as a cartesian product.--override KEY=VAL [KEY=VAL ...]pins individual parameters to scalar values, applied to every generated config.
Both can be used independently or combined. When a key appears in both the sweeper file and the CLI overrides, the override wins and that axis is collapsed to a single value.
Quick Start
# 1. Single experiment with a specific target (no sweep)
./slurm_utils/launch_protein_binder_search_from_local_docker.sh \
--override generation.task_name=22_DerF21
# 2. Sweep beam widths for a single target
./slurm_utils/launch_protein_binder_search_from_local_docker.sh \
--sweeper configs/sweeps/beam_width.yaml \
--override generation.task_name=22_DerF21
# 3. Sweep beam widths with nsteps pinned to 400
./slurm_utils/launch_protein_binder_search_from_local_docker.sh \
--sweeper configs/sweeps/beam_width.yaml \
--override generation.task_name=22_DerF21 generation.args.nsteps=400
# 4. Dry run to preview config generation
python script_utils/generate_inference_configs.py \
--config_name search_binder_pipeline \
--sweeper configs/sweeps/beam_width.yaml \
--override generation.task_name=22_DerF21 \
--dryrunSweep YAML Format
Sweep files live in configs/sweeps/. Each key is a dot-notation config path
and each value is a list of values to sweep over:
# configs/sweeps/beam_width.yaml
generation.search.beam_search.beam_width:
- 1
- 2
- 4
- 8Multiple axes produce a cartesian product:
# 3 beam widths x 2 nsteps = 6 configs
generation.search.beam_search.beam_width:
- 2
- 4
- 8
generation.args.nsteps:
- 200
- 400Long values (e.g., checkpoint paths) benefit from YAML block-list style:
ckpt_path:
- /path/to/checkpoints/model_v1/epoch_100.ckpt
- /path/to/checkpoints/model_v2/epoch_200.ckpt
- /path/to/checkpoints/model_v3/epoch_50.ckptA scalar value (not a list) is automatically wrapped in a single-element list, so it pins that parameter without adding a sweep dimension:
generation.args.self_cond: true--override Format
Override arguments are KEY=VALUE strings where:
The key uses dot notation (e.g.,
generation.args.nsteps)The value is auto-typed: integers, floats, booleans (
true/false), null (null/none), or strings
--override generation.task_name=22_DerF21 generation.args.nsteps=400 generation.args.self_cond=trueMultiple overrides are space-separated after a single --override flag.
How It Works
Config Generation Pipeline
+-----------------+
| Sweeper YAML | (optional)
+-----------------+
|
v
+-----------+ +------------------+ +-------------------+
| Pipeline | ---> | generate_infer- | ---> | N inf_*.yaml + |
| Config | | ence_configs.py | | N eval_*.yaml |
+-----------+ +------------------+ +-------------------+
^
|
+-----------------+
| --override | (optional)
| KEY=VAL ... |
+-----------------+The base pipeline config (e.g.,
search_binder_pipeline.yaml) is loaded via Hydra.If a
--sweeperfile is provided, its axes are combined into a cartesian product.For each combination, the sweep values are merged into the base config.
--overridevalues are applied on top of every config (overriding sweep values if they conflict).Each config gets a unique
root_pathand is saved as a pair:inf_{idx}_{run}.yamlandeval_{idx}_{run}.yaml.
Config Naming
Generated config filenames follow the pattern:
inf_{index}_{run_name}.yaml
eval_{index}_{run_name}.yamlThe index is sequential (0, 1, 2, ...) and the run name comes from the
--run_name argument. Task name is intentionally NOT in the filename -- it
lives inside the config content. This keeps filenames predictable so the bash
launcher can construct Hydra --config-name paths without parsing YAML.
Directory Structure
On the remote cluster (and on-cluster direct launches), configs always live at the canonical paths:
configs/
inference_configs/
inf_0_my_run.yaml
inf_1_my_run.yaml
eval_configs/
eval_0_my_run.yaml
eval_1_my_run.yamlLocal-to-remote flow (with rsync)
When launching from a local machine, configs are first generated into a unique
temporary directory (configs/_gen_XXXXXX/) so that concurrent launches never
collide. Inside the rsync lock, the temp directory contents are staged
(moved) into the canonical configs/inference_configs/ and
configs/eval_configs/ paths, rsync'd to the cluster, and then cleaned up
locally.
generate_configs() → configs/_gen_abc123/{inference_configs,eval_configs}/
stage_configs_for_sync() → configs/{inference_configs,eval_configs}/ (inside lock)
rsync → $RUN_DIR/configs/{inference_configs,eval_configs}/
cleanup_staged_configs() → local canonical dirs removed (inside lock)Direct on-cluster flow (no rsync)
When running directly on the cluster, no temp directory is needed. Configs are generated straight into the canonical paths and used in-place by the SLURM array jobs.
Integration with SLURM Scripts
All three launcher scripts accept --sweeper and --override:
./slurm_utils/launch_protein_binder_search_from_local_docker.sh \
--sweeper configs/sweeps/beam_width.yaml \
--override generation.task_name=22_DerF21The on-cluster script works identically (no rsync needed):
./slurm_utils/launch_protein_binder_search_conda.sh \
--sweeper configs/sweeps/beam_width.yaml \
--override generation.task_name=22_DerF21The multi-target loop wrapper also passes these through:
./slurm_utils/launch_protein_binder_search_target_loop_conda.sh \
--sweeper configs/sweeps/beam_width.yaml \
./my_targets.txtLegacy Positional Arguments
The TARGET_TASK positional argument is still supported for backward
compatibility. Internally it is converted to
--override generation.task_name=$TARGET_TASK.
Running Concurrent Experiments
The system is designed for safe concurrent launches:
Local config isolation: Each launch generates configs in a unique
mktemp -d configs/_gen_XXXXXXdirectory. Before rsync (inside the lock), configs are staged to the canonicalconfigs/inference_configs/andconfigs/eval_configs/paths, rsync'd, then cleaned up. This means the generation phase is fully parallel, and the staging+rsync phase is serialised by the lock.Remote directory uniqueness: The run name on the cluster includes the sweeper file basename (e.g.,
my_run-search-beam_width-22_DerF21), making collisions nearly impossible for different sweeps.Lock file for rsync: The
.lockfile prevents simultaneous rsync operations from corrupting the code copy.
Example: launching two experiments in parallel from different terminals:
# Terminal 1: sweep beam widths for target A
./slurm_utils/launch_protein_binder_search_from_local_docker.sh \
--sweeper configs/sweeps/beam_width.yaml \
--override generation.task_name=22_DerF21
# Terminal 2: sweep replicas for target B (safe to run simultaneously)
./slurm_utils/launch_protein_binder_search_from_local_docker.sh \
--sweeper configs/sweeps/search_replicas.yaml \
--override generation.task_name=02_PDL1Running Individual Pipeline Stages
The core Python modules (generate, filter, evaluate, analyze) can
still be run independently with Hydra ++key=value overrides:
# Run just evaluation on existing inference outputs
python -m proteinfoundation.evaluate \
--config-path /path/to/eval_configs \
--config-name eval_0_22_DerF21_my_run \
++eval_njobs=4The sweep system only affects config generation and the bash pipeline orchestration. It does not change how individual modules consume configs.
Migration from Old System
| Old | New |
|---|---|
Edit sweeper = {...} dict in Python | Create a YAML file in configs/sweeps/ |
--target_task_override 22_DerF21 | --override generation.task_name=22_DerF21 |
--unified flag | Removed (always unified pipeline mode) |
--eval_config_name evaluate | Removed (eval derived from pipeline config) |
--infer_config_name search_binder | --config_name search_binder_pipeline |
generate_binder_inference_configs.py | generate_inference_configs.py |
Hardcoded ALPHA_PROTEO_TARGETS list | Removed (use sweep or override) |
| Manually delete generated configuration files | Automatic: temp dir + staging (concurrent-safe) |
Tests
The sweep system is covered by tests/test_sweep.py (92 tests):
pytest tests/test_sweep.py -vTest categories:
TestParseScalar/TestParseOverride: Value parsing and type inferenceTestLoadSweeperFile: YAML loading and validationTestBuildSweeper: Merge logic and conflict resolutionTestDotKeyDictToNestedDict: Dot-notation conversionTestGetTaskNameFromConfig/TestCreateEvalConfig: Config helpersTestApplySweeperAndSaveConfigs: End-to-end cartesian product, value propagation, unique paths, filename conventionsTestConcurrentSafety: Parallel generation without collisionsTestBuildParser: CLI argument parser validationTestCreateEvalConfigNjobs: eval_njobs priority regression testsTestCreateEvalConfigPaths: Path derivation edge casesTestEmptySweepAxis: Zero-config guard regression testsTestConfigFilenameContract: Filename contract between Python and bashTestEvalPathEdgeCases: Eval path derivation with adversarial inputs
Requirements and compatibility
Written for: Claude Code
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: Declares allowed tools, Names Claude Code tools, Needs Python
The author says: complexa CLI installed (pip install -e .); CUDA GPU; AF2_DIR (colabdesign) or RF3_CKPT_PATH+RF3_EXEC_PATH (rf3_latest); ESMFold weights for monomer paths
Security
What our scanner noticed· Medium risk
- Large base64-encoded blobs
- Instructions that use the network
- 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
- NVIDIA
- Publisher
- NVIDIA (Official)
- Source
- NVIDIA/skills · skills/bionemo-complexa-evaluate-pdbs · commit fce3cca
- Licence
- Apache License 2.0 (redistribution allowed)
- LICENSE (added by AutoGineer from LICENSE-APACHE)
- ATTRIBUTION.md (written by AutoGineer)
- Synced
AutoGineer is not affiliated with or endorsed by NVIDIA.
Download ZIP
The ZIP holds the skill’s files, its licence files and an ATTRIBUTION.md. Download complexa-evaluate-pdbs.zip