opentrons-integration – skill Lập trình cho agent AI
Soạn thảo, rà soát, di chuyển, mô phỏng và gỡ lỗi các giao thức Python Protocol API v2 chính thức của Opentrons cho robot Flex và OT-2. Dùng cho xử lý chất lỏng riêng theo robot, thiết lập deck và labware, pipette, module, tham số runtime, liquid class và phân tích Opentrons App. Hãy dùng pylabrobot thay thế khi một workflow
Cài skill opentrons-integration bằng một lệnh
Chọn công cụ bạn đang dùng, copy lệnh và dán vào terminal. Skill sẽ nằm trong thư mục skills của công cụ đó và sẵn sàng dùng ở phiên làm việc tiếp theo.
Claude Code
mkdir -p ~/.claude/skills && curl -fsSL https://skill.dn1nguoi.com/z/opentrons-integration-2421d.tgz | tar xz -C ~/.claude/skills
Gọi trong Claude Code: /opentrons-integration – rồi mô tả công việc bạn muốn làm.
Codex
mkdir -p ~/.codex/skills && curl -fsSL https://skill.dn1nguoi.com/z/opentrons-integration-2421d.tgz | tar xz -C ~/.codex/skills
Gọi trong Codex: $opentrons-integration – rồi mô tả công việc bạn muốn làm.
Hermes Agent
mkdir -p ~/.hermes/skills && curl -fsSL https://skill.dn1nguoi.com/z/opentrons-integration-2421d.tgz | tar xz -C ~/.hermes/skills
Gọi trong Hermes Agent: /opentrons-integration – rồi mô tả công việc bạn muốn làm.
DeepSeek
mkdir -p ~/.deepcode/skills && curl -fsSL https://skill.dn1nguoi.com/z/opentrons-integration-2421d.tgz | tar xz -C ~/.deepcode/skills
Gọi trong DeepSeek: /opentrons-integration – rồi mô tả công việc bạn muốn làm.
Nội dung SKILL.md
Nội dung SKILL.md gốc bằng tiếng Anh.
Opentrons Integration
Overview
Create production-minded Python Protocol API v2 protocols for Opentrons Flex and
OT-2. This skill covers protocol structure, hardware and deck configuration,
liquid handling, runtime customization, module control, simulation, and safe
deployment.
The verified baseline as of 2026-10-01 is:
opentrons==10.0.0for reproducible Flex simulation.opentrons==9.0.0for local OT-2 API 2.28 compatibility simulation.- Flex supports API levels 2.15 through 2.30 on current software.
- OT-2 supports API levels 2.0 through 2.28 on current software.
- API 2.29 and later are Flex-only at this baseline. Keep OT-2 at 2.28 or lower.
- Bundled Flex templates retain API 2.29 because step grouping is their newest
required feature. API 2.30 fixes start-only meniscus aspiration.
- The 10.0.0 library reports a local maximum of 2.31, ahead of the documented
robot maximum 2.30. Do not infer robot support from that constant.
Read references/sources.md for the upstream documentation used for this
snapshot. Recheck the official versioning page before targeting newer robot
software.
Safety Boundary
Opentrons protocols control physical equipment. Never treat successful Python
syntax or local simulation as permission to run on a robot.
Before live execution:
1. Simulate locally with the same pinned opentrons version used for authoring.
2. Import the protocol into the correct Opentrons App and require successful
analysis.
3. Verify robot model, software, pipettes, mounts, modules, adapters, labware
definitions, deck fixtures, tip count, source volumes, dead volumes, and
destination capacity.
4. Review the run preview and deck map with the operator.
5. Perform a slow dry run with nonhazardous liquid when geometry, custom
labware, partial tip pickup, or gripper moves are new.
6. Keep the emergency stop accessible and follow site-specific biosafety,
chemical-safety, and contamination-control procedures.
Simulation cannot verify physical calibration, liquid properties, meniscus
behavior, labware manufacturing tolerances, cap or seal removal, tubing, or all
possible collisions.
Choose the Right Interface
Use this skill for Python files imported into the Opentrons App and run through
the Protocol API.
- Use Protocol Designer for supported no-code workflows.
- Use PyLabRobot for a hardware-agnostic workflow spanning vendors.
- Treat the robot's HTTP API as a separate integration surface. If direct HTTP
control is explicitly required, use the OpenAPI document served by the target
robot and do not infer endpoints from Protocol API methods.
Required Intake
Do not write final protocol code until these facts are known:
- Robot: Flex or OT-2, plus installed robot software.
- Pipette model, volume range, channel count, and mount.
- Modules and generations; Flex Gripper or Stacker availability.
- Exact labware API load names and custom definition files, if any.
- Deck fixtures: Flex trash bin, waste chute, staging slots, or Stackers.
- Source volumes, destination volumes, dead volume, mixing needs, and liquid
characteristics.
- Tip policy: contamination boundaries, reuse policy, filters, partial pickup,
and total tips.
- Operator interventions, incubation timing, runtime parameters, and output
files.
- Acceptance criteria: tolerated volume error, required controls, and dry-run
plan.
If any physical configuration is uncertain, produce a parameterized draft and
an explicit assumptions list rather than guessing.
Install and Simulate
Flex:
uv run --no-project --isolated --python 3.12 --with "opentrons==10.0.0" opentrons_simulate protocol.pyOT-2 API 2.28:
uv run --no-project --isolated --python 3.12 --with "opentrons==9.0.0" opentrons_simulate protocol.pyThe 10.0.0 package rejects OT-2 protocols after the Flex/OT-2
release-line split. Always complete OT-2 analysis in the current OT-2 App.
For a dedicated Flex environment:
uv venv --python 3.12 .venv-opentrons
uv pip install --python .venv-opentrons/bin/python -r skills/opentrons-integration/requirements-flex.txt
.venv-opentrons/bin/opentrons_simulate protocol.pyUse requirements-ot2.txt instead for an OT-2 compatibility environment. On
Windows, invoke the executable from .venv-opentrons\Scripts\opentrons_simulate.exe.
Local simulation is for Python protocols; import Protocol Designer JSON files
into the appropriate Opentrons App instead.
Protocol Skeletons
Flex, API 2.29
For Flex, requirements is mandatory. Put apiLevel only in requirements,
not in both metadata and requirements.
from opentrons import protocol_api
metadata = {
"protocolName": "Flex transfer",
"author": "Your Name",
"description": "Transfer buffer into a plate.",
}
requirements = {"robotType": "Flex", "apiLevel": "2.29"}
def run(protocol: protocol_api.ProtocolContext) -> None:
tips = protocol.load_labware(
"opentrons_flex_96_tiprack_200ul", "D1"
)
reservoir = protocol.load_labware("nest_12_reservoir_15ml", "D2")
plate = protocol.load_labware("nest_96_wellplate_200ul_flat", "C2")
protocol.load_trash_bin("A3")
pipette = protocol.load_instrument(
"flex_1channel_1000", "left", tip_racks=[tips]
)
pipette.transfer(
100,
reservoir["A1"],
plate["A1"],
new_tip="always",
)OT-2, API 2.28
For OT-2 API 2.15 and later, a requirements block is recommended. OT-2 has a
fixed trash in slot 12; do not call load_trash_bin().
from opentrons import protocol_api
metadata = {
"protocolName": "OT-2 transfer",
"author": "Your Name",
}
requirements = {"robotType": "OT-2", "apiLevel": "2.28"}
def run(protocol: protocol_api.ProtocolContext) -> None:
tips = protocol.load_labware("opentrons_96_tiprack_300ul", "1")
reservoir = protocol.load_labware("nest_12_reservoir_15ml", "2")
plate = protocol.load_labware("nest_96_wellplate_200ul_flat", "3")
pipette = protocol.load_instrument(
"p300_single_gen2", "left", tip_racks=[tips]
)
pipette.transfer(100, reservoir["A1"], plate["A1"])Use the lowest API level that provides every required feature when a protocol
must run across a mixed software fleet. Use the current maximum only when the
workflow needs its behavior or capabilities.
Authoring Workflow
1. Select robot and API level
Check the maximum supported API in the App under the robot's advanced settings.
Map every requested feature to its minimum API level using
references/api_reference.md.
Important gates:
- 2.20: CSV runtime parameters, liquid presence detection, expanded partial
nozzle layouts.
- 2.21: Absorbance Plate Reader.
- 2.22: current labware-level liquid loading methods.
- 2.23: meniscus locations and labware lids.
- 2.24: liquid classes and liquid-class complex commands.
- 2.25: Flex Stacker and Flex 96-Channel 200 µL pipette.
- 2.27: dynamic pipetting and concurrent module actions.
- 2.28: 20 µL Flex tips, improved partial-tip return, and thermocycler ramp rate.
- 2.29: step grouping; Flex only at the verified baseline.
- 2.30: aspirating at
meniscus(target="start")without anend_location.
2. Build the deck explicitly
- Use exact load names from the official Labware Library.
- Load Flex trash bins or the waste chute explicitly.
- Account for module footprints, staging slots, Stacker shuttles, gripper paths,
and tall-labware adjacency.
- Load labware on adapters or module contexts in the documented order.
- Never substitute a similarly named labware definition; geometry and offsets
are part of the protocol's safety model.
See references/modules_and_deck.md.
3. Select pipettes and tips
Current load names are:
- Flex:
flex_1channel_50,flex_1channel_1000,
flex_8channel_50, flex_8channel_1000,
flex_96channel_200, flex_96channel_1000.
- OT-2 GEN2:
p20_single_gen2,p20_multi_gen2,
p300_single_gen2, p300_multi_gen2, p1000_single_gen2.
Check that every requested volume is within the configured pipette and tip
range. For Flex 50 µL pipettes handling 1–4.9 µL, call
configure_for_volume(volume) while empty before pickup; low-volume mode caps
the pipette at 30 µL. A 100 nL operation is not an Opentrons pipetting task.
4. Choose a liquid-handling layer
- Use
aspirate(),dispense(),mix(),air_gap(),blow_out(), and
touch_tip() for explicit control.
- Use
transfer(),distribute(), andconsolidate()for standard movements. - On Flex, consider
transfer_with_liquid_class(),
distribute_with_liquid_class(), or consolidate_with_liquid_class() for
Opentrons-verified aqueous, volatile, or viscous behavior.
- Use dynamic start/end locations or
dynamic_mix()only when API 2.27+ and the
geometry has been reviewed.
Model contamination boundaries before optimizing tips. For standard distribute()
and consolidate(), `new_tip="always"
… (nội dung đầy đủ có trong gói tải về)
Skill liên quan
- azure-security-keyvault-secrets-java – SDK Azure Key Vault Secrets cho Java để quản lý bí mật. Dùng khi lưu trữ, lấy hoặc quản…
- azure-servicebus-rust – Thư viện Azure Service Bus cho Rust. Gửi và nhận tin nhắn qua queue, topic và…
- azure-storage-blob-java – Xây dựng ứng dụng lưu trữ blob bằng SDK Azure Storage Blob cho Java.
- openapi-spec-generation – Tạo và duy trì đặc tả OpenAPI 3.1 từ mã nguồn, đặc tả thiết kế trước (design-first) và…
- parallel-debugging – Gỡ lỗi các vấn đề phức tạp bằng cách đưa ra các giả thuyết cạnh tranh, điều tra song…
- hunt-source-leak – Săn lỗ hổng rò rỉ mã nguồn và artifact build: source map JavaScript (.js.map) khôi phục…
- azure-storage-blob-rust – SDK Azure Blob Storage cho Rust. Dùng để tải lên, tải xuống và quản lý blob cùng…
- azure-storage-queue-rust – Thư viện Azure Queue Storage cho Rust. Gửi, nhận và quản lý tin nhắn hàng đợi. Kích hoạt…