Complexa Target

NVIDIAOfficialCreated by Ohad MosafiDistributed by NVIDIA

Skill
Tool integration
Software development
Apache-2.0
Medium risk

From the author

Add, edit, inspect, or validate Proteina-Complexa target definitions for protein binders, ligand binders, and AME motif scaffolding. Use for target registries, chain/residue selectors, hotspots, ligand fields, and incomplete motif inputs. Covers direct YAML edits and complexa target/validate target commands; running a campaign with an already registered target belongs to complexa-design.

— the description by Ohad Mosafi

AutoGineer summary

Written by AutoGineer from the skill’s own files, not by the author

The complexa-target skill provides a standardized approach to defining, editing, and validating design targets within the Proteina-Complexa framework. It covers the registration of protein binders, ligand binders, and AME enzyme scaffolding by managing specific YAML configuration files. The skill emphasizes direct file editing for configuration management, offering a reliable way to define target parameters such as chain selectors, hotspot residues, and ligand information, while providing validation steps to ensure target integrity before initiating design campaigns.

What it does

Adds or updates target definitions in YAML registries for protein and ligand binders.
Provides a structured schema for defining target inputs, hotspot residues, and ligand properties.
Supports manual configuration editing for AME enzyme scaffolding tasks.
Validates target configurations to ensure PDB paths and parameters are correctly resolved.
Offers CLI commands for listing and inspecting existing target definitions.
Generates documentation artifacts for registered design targets.

When to use it

When you need to register a new protein or ligand target for a design pipeline.
When you need to modify existing target parameters like hotspot residues or binder length ranges.
When you are preparing a new AME enzyme scaffolding task.
When you need to verify that a target PDB is correctly referenced and accessible by the pipeline.

Advantages

Direct YAML editing provides full control and avoids complex CLI flag management.
Standardized schema ensures consistency across different design pipelines.
Built-in validation steps prevent runtime errors by checking path resolution early.
Supports both simple protein surfaces and complex ligand-binding pockets.

Usage examples

“Add a new protein target named 'Target_Alpha' using PDB 'Alpha_Structure' from the 'custom_targets' source.”: The agent will append a new entry to configs/targets/targets_dict.yaml with the specified source, filename, and default binder length, then verify the configuration.
“Validate the configuration for the ligand target '41_7BKC_LIGAND'.”: The agent will run the validation command against the ligand pipeline to confirm the target exists and the PDB file is correctly resolved.

Install

Download the skill as a ZIP:
https://mp-staging.autogineer.com/agent-skills/nvidia/complexa-target/download

Unzip it into the cross-client skills folder of your project:

mkdir -p .agents/skills && unzip complexa-target.zip -d .agents/skills

Documentation by Ohad Mosafi

complexa-target

Add or edit a design target in Proteina-Complexa. Targets live in three YAML files, one per complexa design pipeline:

configs/targets/targets_dict.yaml — protein binder (default pipeline)
configs/targets/ligand_targets_dict.yaml — ligand binder
configs/design_tasks/ame_dict_v2.yaml — AME / enzyme scaffolding

The complexa target CLI only manages the first two. AME tasks use an extended schema (the same core fields as ligand targets plus contig_atoms for hand-curated per-residue motif atom selections) and are file-edit-only.

Instructions

complexa target add is a thin wrapper around "load YAML → build dict → append a block" (see src/proteinfoundation/cli/target_manager.py:add_target_cli and append_target_to_dict). For agentic use, just edit the targets dict directly — the schema is short, the existing entries are great copy templates, and you skip 14 CLI flags / SMILES shell-escaping. Use the CLI only if you explicitly want its YAML auto-quoter or its overwrite-prompt safety.

For an offline edit, work on the supplied registry or requested output copy. When a copy is requested, create its parent directory and copy into an absent destination. If the destination already exists, inspect and preserve it: reuse it when it is the intended working copy, otherwise report the path conflict. Do not delete the output tree to restart a configuration edit. An installed Complexa runtime, GPU, or target structure is not required to write the configuration. Use the field schema below, preserve unrelated entries, and read back the saved block. Coordinate validation remains pending when the structure is absent; finish the configuration task without installing a runtime. With Read/Edit tools, read the destination copy before editing it; reading the original input path does not satisfy Edit's requirement for the output path.

Use the schema below and the selected registry; the CLI reference is needed only for CLI use. Finish with the saved entry, its consumer pipeline, the downstream generation.task_name, and the validation status.

Step	Direct file edit (preferred)	CLI
Look at existing targets	Read `configs/targets/{,ligand_}targets_dict.yaml` (or `configs/design_tasks/ame_dict_v2.yaml` for AME)	`complexa target list` (protein/ligand only)
Look at one target	Read the dict and grep for the key	`complexa target show NAME`
Add a new target	Append a YAML block (Step 3a)	`complexa target add ...` (Step 3b)
Verify configuration	Parse the saved YAML and compare the changed entry and untouched keys	`complexa target show NAME --dict PATH`
Check runtime PDB-path resolution	Requires the full pipeline and environment	`complexa validate target CONFIG --target NAME`

Step 1: Decide the target type

Targets live in three different files, one per complexa design pipeline. Pick the file by working out which pipeline the user will run, then add the entry to that file. Each file is consumed by exactly one pipeline.

User intent	Pipeline	Targets dict file	This skill?
Bind a protein surface (PD-L1, IFNAR2, TNF-α, …) — default	`configs/search_binder_local_pipeline.yaml`	`configs/targets/targets_dict.yaml`	Yes — Step 2 (protein)
Bind a small-molecule pocket (FAD, SAM, OQO, …)	`configs/search_ligand_binder_local_pipeline.yaml`	`configs/targets/ligand_targets_dict.yaml`	Yes — Step 2 (ligand)
AME / enzyme scaffolding (motif + ligand, `M####_<pdb>` names)	`configs/search_ame_local_pipeline.yaml`	`configs/design_tasks/ame_dict_v2.yaml`	Partial — see "AME tasks" below

AME tasks (enzyme pipeline)

AME tasks live under motif_target_dict_cfg: with source, target_filename, ligand, contig_atoms, binder_length, and use_bonds_from_file. The contig_atoms string contains curated chain/residue/atom selections. Existing entries illustrate the field structure, not the selections for a new motif. If motif atoms, ligand selection, or structure location are missing, list the missing inputs and write a separate, explicitly incomplete template if useful. Leave the registry unchanged until those scientific inputs are supplied. A task name or PDB ID alone does not determine them. In the missing-input handoff, explain that registration will be a direct edit under motif_target_dict_cfg once the curated selections are supplied; complexa target add cannot register AME tasks. Completed entries are selected with ++generation.task_name=<NAME> and configs/search_ame_local_pipeline.yaml.

Step 2: Gather required info

Use the supplied values and ask only for missing required information. Required fields differ for protein, ligand, and AME definitions.

Protein target

Field	Question	Example	Required
name	"Target name (used as the dict key and `task_name`)?"	`02_PDL1`, `MyTarget_v1`	yes
source	"Source directory under `$DATA_PATH/target_data/`?"	`bindcraft_targets`, `custom_targets`	yes (or `target_path`)
target_filename	"PDB filename (no `.pdb` extension)?"	`PD-L1`, `IFNAR2`	yes (or `target_path`)
target_input	"Chain + residue range — see reference for grammar."	`A1-115`, `A1-50,B1-50`	yes
hotspot_residues	"Hotspot residues (interface contact residues)?"	`["A33", "A95", "A102"]`	optional, recommended
binder_length	"Binder length range `[min, max]` or single `[length]`?"	`[80, 150]`, `[100]`	optional (default `[60, 120]`)
pdb_id	"Reference PDB ID (optional, metadata only)?"	`"2lag"`	optional

Hotspot selectors encode chain + residue number, not amino-acid identity. For example, Tyr42 (Y42) on explicitly specified chain B becomes B42; already supplied chain/residue selectors stay unchanged. Preserve the user's residue numbering. Without coordinates, report that residue identities and membership in the structure are unverified.

Ligand target — protein fields above (minus `target_input`), plus:

Field	Question	Example	Required
ligand	"3-letter PDB ligand residue code?"	`FAD`, `OQO`, `SAM`	yes (presence marks target as ligand)
SMILES	"SMILES string for the ligand?"	`"O=C2C3=Nc1cc(c(...)..."`	recommended; uppercase YAML key
ligand_only	"Generate pocket around ligand only (no protein-protein interface)?"	`true` / `false`	optional (default `true`)
use_bonds_from_file	"Use bond info from the input PDB/CIF?"	`true` / `false`	optional (default `true`)
target_input	not required for ligand targets	—	no

Check whether the proposed key already exists in the selected YAML mapping. Preserve an existing entry unless the user requested that entry's update.

Copy a supplied SMILES exactly. Chain-specific ligand selection belongs to preparation of the input structure; do not invent a chain field or protein target_input to represent it in the ligand entry.

Examples

Step 3a: Append the YAML block directly (preferred)

Open configs/targets/targets_dict.yaml (or ligand_targets_dict.yaml for ligand targets), find a similar existing entry as a style template, and append the new block under target_dict_cfg:. Two-space indent, single blank line between entries.

Protein template

  02_PDL1:
    source: bindcraft_targets
    target_filename: PD-L1
    target_input: "A1-115"
    hotspot_residues: ["A37", "A39", "A49", "A98"]
    binder_length: [64, 155]
    pdb_id: "4z18"

Rules to match the existing file style (mirrors what complexa target add would emit):

Quote chain/residue ranges ("A1-115", "A33") and any SMILES — flow-style strings get tripped up by : and brackets otherwise.
Use flow-style lists (["A33", "A95"], [64, 155]) — that's what the on-disk dump produces.
target_input, source, target_filename are required for protein. target_path (absolute path) can replace source + target_filename if the PDB lives outside $DATA_PATH/target_data/.

Ligand template

  41_7BKC_LIGAND:
    source: ligand_targets
    target_filename: 7BKC_ligand_centered
    hotspot_residues: [null]
    binder_length: [100]
    pdb_id: 7BKC
    ligand: 'FAD'
    ligand_only: True
    SMILES: "O=C2C3=Nc1cc(c(cc1N(C3=NC(=O)N2)CC(O)C(O)C(O)COP(=O)(O)OP(=O)(O)OCC6OC(n5cnc4c(ncnc45)N)C(O)C6O)C)C"
    use_bonds_from_file: True

The presence of the ligand: key flips the target into ligand mode — there is no separate is_ligand flag. target_input is not required for ligands.

After saving, skip to Step 4 to verify.

Step 3b: CLI alternative (`complexa target add`)

Use the CLI when you want its automatic chain/residue quoting, the overwrite-confirm prompt, or to wire target creation into a non-Python script. Prefer non-interactive mode for agentic use (-i / --editor opens an editor and blocks).

Confirmed flags (from `src/proteinfoundation/cli/target_cli.py`)

Read target_schema.md for the flag table and worked CLI examples when this path is needed. Select the intended dictionary with --dict; --source and --target-filename should be explicit when they differ from the CLI defaults. AME registration remains a direct edit.

Step 4: Verify

First parse the saved YAML with an available YAML parser and check the selected mapping, field types, requested values, and preservation of other entries. Read back the resulting block. This verifies configuration editing only.

With a prepared Complexa installation, pipeline configs, environment, and target structure, additionally check runtime path resolution from that checkout:

# 1. Select the dictionary that was actually edited.
complexa target show 02_PDL1 --dict configs/targets/targets_dict.yaml

# 2. Resolve the PDB path and validate it exists on disk.
#    This traverses Hydra defaults to find the target dict.
complexa validate target configs/search_binder_local_pipeline.yaml --target 02_PDL1

complexa validate target (from src/proteinfoundation/cli/validate.py::validate_target) checks:

DATA_PATH is set and target_data/ exists.
The target name resolves in target_dict_cfg.
Either target_path exists, or $DATA_PATH/target_data/<source>/<target_filename>.pdb exists.
target_input, hotspot_residues, binder_length are reported back so a human can sanity-check them.

For ligand targets, use configs/targets/ligand_targets_dict.yaml for show and configs/search_ligand_binder_local_pipeline.yaml for validation; --target is the target key, not a config path. This validator does not check residue identities, ligand chemistry, or AME contig_atoms; do not describe a path check as coordinate or scientific validation.

Step 5: Emit artifact

Save the edited entry and validation status at the user's requested output location (otherwise ./target_<name>/). For an offline edit, the saved YAML block is sufficient; no CLI-generated artifact is required. On a prepared installation, a target-show record can also be saved:

mkdir -p target_02_PDL1
complexa target show 02_PDL1 > target_02_PDL1/target_show.txt

If a standalone definition is requested, save the actual entry under its registry key in target_definition.yaml. The handoff should include the saved path, target key, consumer pipeline from Step 1, and ++generation.task_name=<NAME>, together with what validation actually ran. For an incomplete AME request, report the separate template, missing inputs, and the direct registry edit needed after those inputs arrive.

Hardware requirements

None for target definition — this is a YAML edit, not a training/inference step. Disk impact is a few KB appended to the targets dict (plus an automatic .yaml.bak backup written by save_targets_dict).

For the downstream design / evaluate runs that consume the target, defer to complexa-design and references/hardware.md.

Troubleshooting

Symptom	Cause	Fix
`Target PDB file: File not found` from `validate target`	`<source>/<target_filename>.pdb` does not exist under `$DATA_PATH/target_data/`	Confirm the PDB stem and source dir. Use `--target-path /full/path.pdb` if the file lives outside `target_data/`.
"Target 'X' already exists! Overwrite? (y/N)"	Name collision in dict	Either pick a new name, or pass `-f / --force` to overwrite.
Hotspot residue not in PDB	Wrong chain or residue number	Open the PDB, re-check chain letters (case-sensitive) and residue indices. Hotspots use the format `<CHAIN><RESNUM>` — see reference.
Chain not found	`target_input` references a chain that does not exist in the PDB	Inspect the PDB with `grep "^ATOM" target.pdb \| awk '{print $5}' \| sort -u`.
Ligand code missing from PDB	The 3-letter `ligand` code does not appear as a `HETATM` residue name in the file	Open the PDB and check `HETATM` lines; you may need a `_ligand_centered` variant of the PDB.
SMILES parse failure downstream	Bad SMILES string	Validate with `rdkit.Chem.MolFromSmiles(smiles)` before adding. Quote SMILES in shell to escape brackets and parens.
Target name with leading digit breaks Hydra interpolation	YAML treats `02_PDL1` as a string fine; some override syntaxes need quoting	Use `++generation.task_name=02_PDL1`; quote if the shell strips characters.
`target_input` appears ignored for a ligand target	By design — ligand targets do not use `target_input`; pocket is defined by the ligand	Leave it unset for ligand targets.

Reference

references/target_schema.md — every field, chain-spec grammar, AME task-name grammar, three worked examples.
configs/targets/targets_dict.yaml — live protein entries (copy a known-good one as a template).
configs/targets/ligand_targets_dict.yaml — live ligand entries.
configs/design_tasks/ame_dict_v2.yaml — AME task definitions (file-edit only, not exposed via complexa target CLI).
src/proteinfoundation/cli/target_cli.py — argparse source of truth.
src/proteinfoundation/cli/target_manager.py — add_target_cli, list_targets, show_target, schema in TARGET_FIELDS.
src/proteinfoundation/cli/validate.py — validate_target implementation.

Files

ATTRIBUTION.mdAdded by AutoGineer958 B
BENCHMARK.md7.5 KiB
LICENSELicence file added by AutoGineer11.2 KiB
SKILL.md14.6 KiB
evals/evals.json9.0 KiB
evals/files/campaign_context/README-excerpts.md3.8 KiB
evals/files/campaign_context/SNAPSHOT.md622 B
evals/files/campaign_context/configs/pipeline/binder/binder_generate.yaml9.0 KiB
evals/files/campaign_context/configs/search_binder_local_pipeline.yaml1.5 KiB
evals/files/campaign_context/source_manifest.json809 B
evals/files/project/SNAPSHOT.md570 B
evals/files/project/configs/design_tasks/ame_dict_v2.yaml237 B
evals/files/project/configs/pipeline/ligand_binder/ligand_binder_generate.yaml5.6 KiB
evals/files/project/configs/search_ligand_binder_local_pipeline.yaml1.9 KiB
evals/files/project/configs/targets/ligand_targets_dict.yaml222 B
evals/files/project/configs/targets/targets_dict.yaml176 B
evals/files/project/source_manifest.json716 B
references/hardware.md4.8 KiB
references/target_schema.md12.0 KiB
skill-card.md5.0 KiB
skill.oms.sig8.2 KiB

references/target_schema.md

Target schema reference

Authoritative source: src/proteinfoundation/cli/target_manager.py::TARGET_FIELDS and the live YAML dicts under configs/targets/. This document mirrors them.

Protein target schema

Stored in configs/targets/targets_dict.yaml under target_dict_cfg.<name>. Either (source + target_filename) OR target_path is required, plus target_input.

Field	Type	Required	Default	Example	Controls
`source`	str	yes*	`custom_targets`	`bindcraft_targets`	Subdirectory of `$DATA_PATH/target_data/` where the PDB lives.
`target_filename`	str	yes*	(name of target)	`PD-L1`	PDB stem (no `.pdb` extension). Combined with `source` to build the path.
`target_path`	str	yes*	`null`	`/abs/path/target.pdb`	Full path to a PDB. If set, `source`+`target_filename` are optional.
`target_input`	str	yes	`A1-100`	`A1-115`, `A1-50,B1-50`	Chain + residue range (the "target_input" chain-spec).
`hotspot_residues`	list[str]	no	`[]`	`["A33", "A95", "A102"]`	Interface residues focused on during binder design.
`binder_length`	list[int]	no	`[60, 120]`	`[80, 150]`, `[100]`	Binder length. Two-element list = uniform `[min, max]`; one-element = fixed length.
`pdb_id`	str	no	`null`	`"2lag"`	Reference PDB ID, metadata only.

(* "yes" with the OR rule: either target_path OR (source AND target_filename).)

Ligand target schema

Stored in configs/targets/ligand_targets_dict.yaml. The presence of the ligand key is what marks an entry as a ligand target (no separate is_ligand flag). target_input is not used for ligand targets.

All protein fields above (with target_input optional / omitted), plus:

Field	Type	Required	Default	Example	Controls
`ligand`	str OR list[str]	yes	`null`	`"FAD"`, `["DHZ", "ZN"]`	Three-letter PDB residue name(s) for the ligand. Presence marks target as ligand.
`ligand_only`	bool	no	`true`	`true`	If `true`, generate the binding pocket around the ligand only (no protein-protein interface).
`SMILES`	str	no	`null`	`"O=C2C3=Nc1cc(...)C"`	SMILES string for the ligand (single-ligand targets only). Optional but recommended.
`use_bonds_from_file`	bool	no	`true`	`true`	If `true`, use bond information from the input PDB/CIF file rather than inferring from coordinates.

Note: hotspot_residues is still present for ligand entries but is typically [null] since the pocket is ligand-defined.

`target_input` chain-spec grammar

target_input selects which residues of the target PDB are exposed to the binder design model.

Form	Meaning	Example
`<CHAIN><START>-<END>`	One contiguous chain segment	`A1-115` = chain A, residues 1 through 115
`<CHAIN><START>-<END>,<CHAIN><START>-<END>`	Multiple chain segments (comma-separated)	`A1-50,B1-50` = chain A residues 1-50 plus chain B residues 1-50
`<CHAIN><START>-<END>/0 <NRES>-<NRES>`	Chain break + contigs syntax (RFdiffusion-style)	`A1-115/0 50-100` = target A1-115 plus a 50-100 residue binder placeholder

<CHAIN> is a single uppercase letter (case-sensitive — A and a are different). <START> and <END> are integer residue numbers as they appear in the PDB (not 0-indexed; respects insertion codes only if the PDB does).

When is target_input required vs optional?

Protein targets: required. Default is A1-100.
Ligand targets: not required (and not used at runtime). The pocket is defined by the ligand position, not a chain range.

Hotspot residue format

A hotspot is a single residue, identified by chain + residue number:

"A33"     # chain A, residue 33
"B17"     # chain B, residue 17

Rules:

Must be a string (always quote in YAML — the YAML dumper auto-quotes any <chain><digits> pattern).
Chain letter is case-sensitive and must match a chain in the PDB.
An amino-acid label plus an explicitly supplied chain must be translated: Tyr42 (Y42) on chain B is selector B42. Do not infer the chain from the amino-acid letter or claim the identity was checked without coordinates.
Residue number must exist in the PDB (use grep "^ATOM" target.pdb | awk '{print $5, $6}' | sort -u to enumerate).
The list may be empty ([]) — no hotspots = no special interface focus.
The list may contain only [null] for ligand targets where the pocket is ligand-defined.

CLI form: --hotspot-residues A33 A95 A102 (space-separated, no quotes needed on the command line).

`binder_length` semantics

Value	Meaning
`[60, 120]`	Sample binder length uniformly in [60, 120] inclusive.
`[100]`	Always generate length-100 binders.
`[80, 150]`	Sample uniformly in [80, 150].
`[]` or unset	Falls back to default `[60, 120]`.

CLI form: --binder-length 60 120 (two ints) or --binder-length 100 (one int).

Source directory convention

source is not a full path. It is a subdirectory name under $DATA_PATH/target_data/. The full path resolution is:

${DATA_PATH}/target_data/<source>/<target_filename>.pdb

Examples:

`source`	`target_filename`	Resolved path
`bindcraft_targets`	`PD-L1`	`${DATA_PATH}/target_data/bindcraft_targets/PD-L1.pdb`
`ligand_targets`	`7BKC_ligand_centered`	`${DATA_PATH}/target_data/ligand_targets/7BKC_ligand_centered.pdb`
`custom_targets`	`MyTarget_v1`	`${DATA_PATH}/target_data/custom_targets/MyTarget_v1.pdb`

Override the convention with --target-path /absolute/path/to/file.pdb (overrides both source and target_filename).

Common existing source directories: bindcraft_targets, alpha_proteo_targets, ligand_targets, custom_targets.

AME task names (NOT `complexa target`)

The AME pipeline uses task names, not targets-dict entries. Task names are defined in configs/design_tasks/ame_dict_v2.yaml under motif_target_dict_cfg: and are file-edit-only — they have a richer schema than protein/ligand targets and the complexa target CLI does not touch them.

Grammar

M{NNNN}_{pdb_id}

Component	Values	Meaning
`M{NNNN}`	`M0001` …	Zero-padded sequential ID assigned when the task is added.
`pdb_id`	4-char PDB code (lowercase)	Source PDB for the motif + ligand context.

Examples (drawn from configs/design_tasks/ame_dict_v2.yaml): M0024_1nzy, M0096_1chm.

AME task schema

Each entry under motif_target_dict_cfg.<name> has:

Field	Type	Example	Notes
`source`	str	`ame_targets`	Subdirectory under `$DATA_PATH/target_data/`.
`target_filename`	str	`1nzy_v2`	PDB stem (no `.pdb`).
`ligand`	str	`"FAD"`	3-letter PDB ligand code in the motif PDB.
`contig_atoms`	str	`"A64: [O, C]; A86: [CB, CA, N, C]; ..."`	Hand-curated per-residue atom selection for the motif.
`binder_length`	list[int]	`[100, 160]`	Length range for the scaffold.
`use_bonds_from_file`	bool	`true`	Use bond info from the PDB.
`pdb_id`	str	`"1nzy"`	Reference PDB ID, metadata only.

The motif atom selections and ligand identity must come from the user or a curated structure/task definition. A task name alone is insufficient. When those inputs are absent, preserve the registry and put placeholders in a separate template explicitly marked incomplete.

To run an AME task:

complexa design configs/search_ame_local_pipeline.yaml \
  ++run_name=ame_1nzy \
  ++generation.task_name=M0024_1nzy

Do not use complexa target add for AME tasks — they live in a different dict and add the contig_atoms field (and use motif_target_dict_cfg instead of target_dict_cfg) that the CLI does not know how to construct.

CLI options

For complexa target add, confirmed by src/proteinfoundation/cli/target_cli.py:

Flag	Type	Applies to	Notes
`name` (positional)	str	both	dict key
`--dict PATH`	path	both	select target dictionary explicitly
`-i, --interactive`	flag	both	opens an editor; avoid for unattended use
`-e, --editor NAME`	str	both	editor command
`--source NAME`	str	both	directory under `$DATA_PATH/target_data/`
`--target-filename NAME`	str	both	PDB stem without `.pdb`
`--target-path PATH`	str	both	full path, instead of source + filename
`--target-input SPEC`	str	protein	chain/residue range
`--hotspot-residues R [R ...]`	list	both	chain/residue selectors
`--binder-length N [N ...]`	int list	both	range or fixed length
`--pdb-id ID`	str	both	metadata only
`--ligand CODE`	str	ligand	marks ligand mode
`--ligand-only`	flag	ligand	pocket-only mode
`--smiles STR`	str	ligand	writes uppercase `SMILES`
`--use-bonds-from-file`	flag	ligand	use input bonds
`-f, --force`	flag	both	overwrite existing without prompting

--source defaults to custom_targets for protein or ligand_targets for ligand entries; --target-filename defaults to the target name. Ligand entries default to ligand_only: true and use_bonds_from_file: true. These commands do not manage AME entries.

Worked examples

1. Protein target from PDB ID + chain (new BindCraft target)

User wants to design binders against chain A, residues 1-115, of an existing PDB at ${DATA_PATH}/target_data/bindcraft_targets/PD-L1.pdb, hotspot residues A37, A39, A49, A98, binder length 64-155.

complexa target add 02_PDL1 \
  --source bindcraft_targets \
  --target-filename PD-L1 \
  --target-input A1-115 \
  --hotspot-residues A37 A39 A49 A98 \
  --binder-length 64 155 \
  --pdb-id 4z18

Resulting YAML entry (appended to configs/targets/targets_dict.yaml):

  02_PDL1:
    target_input: "A1-115"
    source: bindcraft_targets
    target_filename: "PD-L1"
    hotspot_residues: ["A37", "A39", "A49", "A98"]
    binder_length: [64, 155]
    pdb_id: 4z18

2. Ligand target with SMILES (FAD pocket)

User wants binders for the FAD-binding pocket of 7BKC, fixed length 100.

complexa target add 41_7BKC_LIGAND \
  --source ligand_targets \
  --target-filename 7BKC_ligand_centered \
  --pdb-id 7BKC \
  --ligand FAD \
  --ligand-only \
  --use-bonds-from-file \
  --smiles "O=C2C3=Nc1cc(c(cc1N(C3=NC(=O)N2)CC(O)C(O)C(O)COP(=O)(O)OP(=O)(O)OCC6OC(n5cnc4c(ncnc45)N)C(O)C6O)C)C" \
  --binder-length 100

Resulting YAML entry (appended to configs/targets/ligand_targets_dict.yaml):

  41_7BKC_LIGAND:
    source: ligand_targets
    target_filename: "7BKC_ligand_centered"
    hotspot_residues: []
    binder_length: [100]
    pdb_id: 7BKC
    ligand: FAD
    ligand_only: True
    SMILES: "O=C2C3=Nc1cc(c(cc1N(C3=NC(=O)N2)CC(O)C(O)C(O)COP(=O)(O)OP(=O)(O)OCC6OC(n5cnc4c(ncnc45)N)C(O)C6O)C)C"
    use_bonds_from_file: True

3. Ligand target with `--use-bonds-from-file` and no SMILES

User has a curated _centered PDB whose bonds are authoritative, and does not want to provide a SMILES (e.g. uncommon ligand). They want a length range 40-88.

complexa target add Cambridge_bloodsugar_A_4D71_pdb \
  --source ligand_targets \
  --target-filename Cambridge_bloodsugar_A_4D71_pdb \
  --pdb-id 4D71 \
  --ligand UNK \
  --ligand-only \
  --use-bonds-from-file \
  --binder-length 40 88

(Note: --ligand requires a value; pass a placeholder like UNK or the actual 3-letter code if available. The complexa target add parser interprets the presence of --ligand as marking the target ligand-typed.)

Resulting entry mirrors Cambridge_bloodsugar_A_4D71_pdb from configs/targets/ligand_targets_dict.yaml — SMILES: null, use_bonds_from_file: True, binder_length: [40, 88].

Cross-references

CLI: src/proteinfoundation/cli/target_cli.py
Manager + schema: src/proteinfoundation/cli/target_manager.py (see TARGET_FIELDS)
Validator: src/proteinfoundation/cli/validate.py::validate_target
Protein dict: configs/targets/targets_dict.yaml
Ligand dict: configs/targets/ligand_targets_dict.yaml
AME dict: configs/design_tasks/ame_dict_v2.yaml

Requirements and compatibility

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

Security

What our scanner noticed· Medium risk

Large base64-encoded blobs

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

Created by

Ohad Mosafi

Publisher

NVIDIA (Official)

Distributed by

NVIDIA

Source

NVIDIA/skills · skills/bionemo-complexa-target · commit fce3cca

Licence

Apache License 2.0 (redistribution allowed)

LICENSE (added by AutoGineer from LICENSE-APACHE)
ATTRIBUTION.md (written by AutoGineer)

Synced

2026-11-08

AutoGineer is not affiliated with or endorsed by Ohad Mosafi or NVIDIA.

Download ZIP

The ZIP holds the skill’s files, its licence files and an ATTRIBUTION.md. Download complexa-target.zip