How do I install the Igem Wetlab Wiki skill?

Run npx skillmds@latest add travisboston16/igem-wetlab-wiki in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

Is Igem Wetlab Wiki safe to use?

This skill has not completed SkillMD's automated safety review yet. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with Igem Wetlab Wiki?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is Igem Wetlab Wiki free to use?

Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.

Who published Igem Wetlab Wiki?

TravisBoston16 (@travisboston16) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Igem Wetlab Wiki by travisboston16 — Agent Skill

Name: Igem Wetlab Wiki
Author: TravisBoston16

Igem Wetlab Wiki

Plan, write, implement, or audit iGEM wet-lab documentation, including Design, Experiments, Engineering, Results, Measurement, Parts, Protocols, and Notebook pages. Use for experimental evidence, DBTL cycles, measurement validity, figure standards, or wet-lab reproducibility; do not use for purely computational Model work.

File contents

iGEM Wet-Lab Wiki

Turn laboratory work into an auditable chain of design, test, learning, and revision. Preserve failures and uncertainty when they explain the next decision.

For precedent research or substantial wet-lab work, read the curated findings in references/benchmark-corpus.md and the compact reviewed-page index. Read the full official award ledger only when verifying or listing winners and nominees. Verify consequential details live.

When documenting Engineering Success or a consequential iteration, adapt assets/templates/dbtl-cycle.md. Use the whole-wiki figure evidence card when a figure carries a headline claim.

Inventory the evidence

For each experiment, record the question, construct or sample, protocol version, conditions, controls, biological and technical replicates, raw data, analysis, result, uncertainty, failure modes, and decision it informed. Verify the actual notebook, figures, code, and Registry entries before drafting.

Separate page functions

Design: rationale, mechanism, construct architecture, alternatives, and expected behavior.
Experiments or Protocols: reproducible procedures and material conditions.
Engineering: chronological or dependency-based Design-Build-Test-Learn cycles.
Results: the clearest integrated experimental conclusions, with links to method and iteration.
Measurement: validity, calibration, standards, dynamic range, controls, error, comparability, and interpretation.
Parts: design and characterization linked to Registry records.
Notebook: dated trace of work, not a replacement for synthesized conclusions.

Write each result as a traceable unit

Include purpose, method summary, controls and replicates, figure or table, quantitative interpretation, uncertainty, limitations, and the next decision. Captions should state what is shown, conditions, sample size, uncertainty display, and supported conclusion.

Do not treat a single representative image, technical replicate, fitted curve, or qualitative observation as broader proof than it is. Report values below detection or quantification limits conservatively. Keep axis units, normalization, exclusions, statistical tests, and transformations visible.

For a current iGEM season, verify the required Engineering Standard URL and any Registry requirements through the coordinator's season reference. A wiki Parts page does not replace complete Registry documentation. Treat the Registry as the canonical part artifact: verify identifiers, sequence and design, provenance, experience or characterization, and links back to supporting wiki evidence. For an Improved Part, compare against the original part as a control and cross-reference both entries. For a Part Collection, document the collection-level rationale and reuse path as well as each individual Registry entry.

Verify

Confirm that protocols match figures, Results match raw or processed data, Engineering cycles match chronology, part identifiers resolve, and duplicated numbers agree. Render tables, gels, microscopy, plots, equations, and long protocols at desktop and mobile widths.

---name: igem-wetlab-wikidescription: Plan, write, implement, or audit iGEM wet-lab documentation, including Design, Experiments, Engineering, Results, Measurement, Parts, Protocols, and Notebook pages. Use for experimental evidence, DBTL cycles, measurement validity, figure standards, or wet-lab reproducibility; do not use for purely computational Model work.---# iGEM Wet-Lab WikiTurn laboratory work into an auditable chain of design, test, learning, and revision. Preserve failures and uncertainty when they explain the next decision.For precedent research or substantial wet-lab work, read the curated findings in [references/benchmark-corpus.md](references/benchmark-corpus.md) and the compact [reviewed-page index](references/generated/reviewed-pages.md). Read the full [official award ledger](references/generated/award-ledger.md) only when verifying or listing winners and nominees. Verify consequential details live.When documenting Engineering Success or a consequential iteration, adapt [assets/templates/dbtl-cycle.md](assets/templates/dbtl-cycle.md). Use the whole-wiki figure evidence card when a figure carries a headline claim.## Inventory the evidenceFor each experiment, record the question, construct or sample, protocol version, conditions, controls, biological and technical replicates, raw data, analysis, result, uncertainty, failure modes, and decision it informed. Verify the actual notebook, figures, code, and Registry entries before drafting.## Separate page functions- **Design:** rationale, mechanism, construct architecture, alternatives, and expected behavior.- **Experiments or Protocols:** reproducible procedures and material conditions.- **Engineering:** chronological or dependency-based Design-Build-Test-Learn cycles.- **Results:** the clearest integrated experimental conclusions, with links to method and iteration.- **Measurement:** validity, calibration, standards, dynamic range, controls, error, comparability, and interpretation.- **Parts:** design and characterization linked to Registry records.- **Notebook:** dated trace of work, not a replacement for synthesized conclusions.## Write each result as a traceable unitInclude purpose, method summary, controls and replicates, figure or table, quantitative interpretation, uncertainty, limitations, and the next decision. Captions should state what is shown, conditions, sample size, uncertainty display, and supported conclusion.Do not treat a single representative image, technical replicate, fitted curve, or qualitative observation as broader proof than it is. Report values below detection or quantification limits conservatively. Keep axis units, normalization, exclusions, statistical tests, and transformations visible.For a current iGEM season, verify the required Engineering Standard URL and any Registry requirements through the coordinator's season reference. A wiki Parts page does not replace complete Registry documentation. Treat the Registry as the canonical part artifact: verify identifiers, sequence and design, provenance, experience or characterization, and links back to supporting wiki evidence. For an Improved Part, compare against the original part as a control and cross-reference both entries. For a Part Collection, document the collection-level rationale and reuse path as well as each individual Registry entry.## VerifyConfirm that protocols match figures, Results match raw or processed data, Engineering cycles match chronology, part identifiers resolve, and duplicated numbers agree. Render tables, gels, microscopy, plots, equations, and long protocols at desktop and mobile widths.

Frequently asked questions