labarchive-integration
This skill provides programmatic access to LabArchives electronic lab notebooks via REST API, enabling automation of notebook creation, entry management, attachment handling, and integration with external research tools like Protocols.io and REDCap. Use it when you need to automate lab documentation workflows, backup notebook data, manage user permissions, or connect LabArchives with third-party research platforms within a scientific agent environment.
git clone --depth 1 https://github.com/K-Dense-AI/scientific-agent-skills /tmp/labarchive-integration && cp -r /tmp/labarchive-integration/skills/labarchive-integration ~/.claude/skills/labarchive-integrationSKILL.md
# LabArchives Integration Use LabArchives APIs only from current, official method pages. The public documentation is a shared notebook, not a versioned SDK reference, so verify the specific page immediately before implementing a remote operation. ## Choose the Correct Surface Do not combine these interfaces: - **Legacy ELN API:** notebook trees, entries, attachments, users, searches, exports, and site-license functions. It uses regional `*api.labarchives.com` hosts, `/api/<class>/<method>` paths, XML for many responses, and signed query parameters. - **Inventory API v1:** inventory, item types, orders, storage locations, and vendors. It documents relative `/public/v1/...` paths, JSON schemas, and signed `X-LabArchives-*` request headers. - **Product integrations:** Jupyter, REDCap, Protocols.io, GraphPad Prism, SnapGene, Geneious, and others are product-specific UI or file workflows. They are not evidence of a general LabArchives OAuth 2.0 API. Read [`references/api_reference.md`](references/api_reference.md) before writing API code and [`references/integrations.md`](references/integrations.md) before automating an advertised integration. ## Access and Credentials LabArchives ELN developer API access is an Enterprise capability. The current Inventory FAQ limits Inventory API access to Enterprise and Enterprise Plus licensees and requires an Inventory account with API permission. Contact the institution's LabArchives team or LabArchives support for access and the development documentation supplied with it. The environment names below are conventions of this skill, not vendor-defined standards: - `LABARCHIVES_ELN_API_URL` — one exact regional ELN API URL ending in `/api` - `LABARCHIVES_ACCESS_KEY_ID` — LabArchives-issued Access Key ID (`akid`) - `LABARCHIVES_ACCESS_PASSWORD` — HMAC signing secret - `LABARCHIVES_USER_ID` — optional persistent UID bound to that Access Key ID - `LABARCHIVES_INVENTORY_LAB_ID` — required for Inventory requests Keep secrets in the process environment or an approved secret manager. Do not put them in YAML, source code, command-line arguments, prompts, logs, notebooks, or committed `.env` files. The bundled tools never search for `.env` files. From this skill directory: ```bash uv run scripts/setup_config.py regions uv run scripts/setup_config.py check --require-user-id ``` `setup_config.py` validates only endpoint structure and named-variable presence; it does not authenticate, persist, or print credentials. See [`references/authentication_guide.md`](references/authentication_guide.md). ## Regional Endpoints Browser login hosts and API hosts are different. The official ELN API overview currently lists US/rest of world, Australia/New Zealand, UK, Europe outside the UK, and Canada API hosts. The help center separately lists the five regional browser login hosts. Use `setup_config.py regions` for the current allowlist and the complete table in the authentication guide. Never build an API URL from a browser login URL. The public Inventory v1 pages retrieved for this refresh document relative paths, but not a complete regional absolute base-URL table. Obtain that base URL from the institution/vendor documentation rather than guessing from an Inventory login host. ## Authentication Model ### ELN requests The official algorithm is fully documented: 1. Set `expires` to the current Unix epoch time in milliseconds, adjusted for server clock difference if necessary. Despite its name, it is not a future expiry time. 2. Concatenate, with no separators: `<Access Key ID><API method name><expires>`. 3. Compute HMAC-SHA-512 using the Access Password as the key. 4. Base64-encode the digest. 5. URI-encode that signature and send `akid`, `expires`, and `sig` as the documented query parameters. For ordinary ELN calls, the signature input is the method name only, not the API class. User authorization is a documented special case: signing the `api_user_login` redirect uses the unencoded redirect URI in place of a method name. ### Inventory API v1 requests Inventory shares the HMAC algorithm but signs the exact relative route, including resolved path parameters and excluding the query string. Its authentication page documents these headers: - `X-LabArchives-UId` - `X-LabArchives-AKId` - `X-LabArchives-LabId` - `X-LabArchives-Signature` - `X-LabArchives-Expires` Create a fresh signature for every request. Do not move ELN query authentication into Inventory headers or Inventory headers into ELN calls. ## Local Request Planning `scripts/entry_operations.py` is deliberately network-free. It implements the documented signature primitive and emits redacted JSON plans, never a live request or reusable signature: ```bash uv run scripts/entry_operations.py self-test uv run scripts/entry_operations.py eln-plan \ --api-class entries --api-method entry_info uv run scripts/entry_operations.py inventory-plan \ --path /public/v1/users/me ``` Import its `create_signature`, `build_eln_auth_params`, or `build_inventory_headers` functions into institution-reviewed code when needed. Pass returned authentication material directly to the HTTP client; never print or persist it. Before any remote write: 1. Open the exact official method page and verify verb, path, parameters, body, and response schema. 2. Produce a dry-run plan with identifiers and sensitive values redacted. 3. Confirm the target region, notebook/lab, and user-visible effect. 4. Require explicit approval before sending. 5. Re-read and verify the resulting object; do not infer success from HTTP 200 alone when the method documents a response body. The bundled scripts perform no remote writes. ## Local LA Container Inspection An **LA container** is a ZIP file with `lamanifest.xml`, an application file, and optional preview/index files. It is not synonymous with a notebook backup. Inspect one without extracting it: ```bash uv run scripts/notebook_operations.py inspect example
How to use the Adaptyv Bio Foundry API and Python SDK for protein experiment design, submission, and results retrieval. Use this skill whenever the user mentions Adaptyv, Foundry API, protein binding assays, protein screening experiments, BLI/SPR assays, thermostability assays, or wants to submit protein sequences for experimental characterization. Also trigger when code imports `adaptyv`, `adaptyv_sdk`, or `FoundryClient`, or references `foundry-api-public.adaptyvbio.com`.
This skill should be used for time series machine learning tasks including classification, regression, clustering, forecasting, anomaly detection, segmentation, and similarity search. Use when working with temporal data, sequential patterns, or time-indexed observations requiring specialized algorithms beyond standard ML approaches. Particularly suited for univariate and multivariate time series analysis with scikit-learn compatible APIs.
Plan, execute, and document validation, verification, and transfer of analytical procedures under the governing framework - ICH Q2(R2) and Q14, USP <1220>/<1225>/<1226>, ICH M10 bioanalytical, CLSI EP, or ISO/IEC 17025. Use for HPLC, LC-MS/MS, GC, CE, ICP-MS, dissolution, qNMR, qPCR, NIR, and ligand binding or cell-based assays whenever the question is whether a procedure is fit for its intended purpose. Triggers include "method validation", "analytical method validation", "AMV", "validation protocol", "acceptance criteria", "linearity", "reportable range", "accuracy and precision", "repeatability", "intermediate precision", "recovery", "LOD", "LOQ", "detection limit", "quantitation limit", "specificity", "robustness", "method transfer", "method comparison", "Deming", "Passing-Bablok", "Bland-Altman", "equivalence testing", "OOS investigation", "ICH Q2", "Q2(R2)", "Q14", "USP 1225", "ICH M10", "incurred sample reanalysis", "ISR", "CLSI EP", and any request to show that an assay works.
Data structure for annotated matrices in single-cell analysis. Use when working with .h5ad files or integrating with the scverse ecosystem. This is the data format skill—for analysis workflows use scanpy; for probabilistic models use scvi-tools; for population-scale queries use cellxgene-census.
Autonomously improve a real artifact (code, training recipe, agent harness, data pipeline, prompt) against an objective and an evaluator, using Hypothesis Tree Refinement (HTR) from the Arbor paper. Use this whenever someone wants to iteratively optimize something over many experiments without overfitting — e.g. "get my model's eval score up", "improve this agent/harness", "tune this pipeline", "beat the baseline on this benchmark", "run a search over approaches and keep the best", "do an MLE-bench / Kaggle-style optimization", or any long-horizon "make this artifact better and don't just memorize the dev set" task. Trigger it even when the user doesn't say "Arbor" or "hypothesis tree" but describes repeated experiment-and-evaluate loops, branching exploration of competing ideas, or worries about a dev/test gap. Runs Claude itself as the coordinator with subagent executors in isolated git worktrees; for the standalone `arbor` CLI tool see references/arbor-upstream.md.
Infer gene regulatory networks (GRNs) from gene expression data using scalable algorithms (GRNBoost2, GENIE3). Use when analyzing transcriptomics data (bulk RNA-seq, single-cell RNA-seq) to identify transcription factor-target gene relationships and regulatory interactions. Supports distributed computation for large-scale datasets.
Core Python library for astronomy and astrophysics workflows that need Astropy APIs, including units/quantities, coordinates, FITS I/O, tables, time systems, WCS, and cosmology. Use when implementing or debugging astronomical data analysis code with Astropy.
Observe the user's screen via screenpipe, detect repeated research workflows, match them against existing scientific-agent-skills, and draft new skills (or composition recipes that chain existing ones) for the patterns not yet covered. Use when the user asks to analyze their recent work and propose skills based on what they actually do. Requires the screenpipe daemon (https://github.com/screenpipe/screenpipe) running locally on port 3030 — the skill has no other data source and will refuse to run if screenpipe is unreachable. All detection runs locally; only redacted cluster summaries reach the LLM.