# Igem Wiki Story

> Plan, write, implement, or audit the narrative and information architecture of an iGEM wiki, especially Home, Description, Awards, navigation, page introductions, and cross-page storytelling. Use for project framing and site-level comprehension; use a domain skill for technical evidence or Human Practices content.

- Skill: `travisboston16/igem-wiki-story` (Agent Skill, multi-file: 6 files)
- Install (CLI): `npx skillmds@latest add travisboston16/igem-wiki-story`
- Raw SKILL.md: https://api.skillmd.com/api/skills/travisboston16/igem-wiki-story/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Security
- Author: TravisBoston16 (https://skillmd.com/u/travisboston16)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/travisboston16/igem-wiki-story

---


# iGEM Wiki Story

Make the project understandable before making it impressive. The opening path should tell a judge what problem exists, who experiences it, what the team built, what evidence was obtained, and where to inspect it.

For precedent research or substantial story 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.

For a new or substantially restructured page, adapt the coordinator's page-brief template before writing. Preserve the evidence status and maturity from the Claim-Evidence Register in headlines, summaries, and award pages.

## Build the narrative spine

1. Define the problem, affected users, context, and why existing approaches are insufficient.
2. State the proposed synthetic-biology system without overstating maturity.
3. Name the team's strongest measured or computed result and its condition.
4. Show how Design, Engineering, Results, Model, Human Practices, Safety, and Implementation connect.
5. Give each major claim one canonical destination page.

## Assign page roles

- **Home:** a concise orientation and evidence-aware invitation into the project.
- **Description:** the complete problem-to-solution logic, system boundary, users, mechanism, goals, and success criteria.
- **Awards or Judging:** an index mapping claims to the evidence pages; never the only location of evidence.
- **Navigation and page introductions:** explain what a reader will learn and why it matters.

Use progressive detail: one-sentence project statement, short story, system diagram, key evidence, then routes to depth. Preserve essential text when animation, video, counters, or WebGL does not load.

## Audit claims and experience

- Replace global claims with sourced, bounded statements.
- Label prototypes, proposals, simulations, and validated results accurately.
- Check that project name, users, mechanism, numbers, and readiness agree throughout the site.
- Prefer descriptive menu labels and page subtitles over clever but ambiguous names.
- Test the first screen, global navigation, no-motion or reduced-motion path, mobile layout, keyboard path, and link destinations in a real browser.

Do not copy another team's visual identity, mascots, animations, or prose. Extract information-design decisions and adapt them to the team's evidence and established design system.