メニュー
SimSci Engineering team convention for drafting a Design Document on the IHME hub. Use whenever the user asks to e.g. "draft a design doc", "write a design document", "make a design doc", or "start a PRD".
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
| name | design-doc |
| description | SimSci Engineering team convention for drafting a Design Document on the IHME hub. Use whenever the user asks to e.g. "draft a design doc", "write a design document", "make a design doc", or "start a PRD". |
Design documents live in the SSE Confluence space under the Design documents parent page. There is one canonical template — _TEMPLATE — and every doc descends from it. Do not invent a structure; pull the template and follow it.
210206856 (https://hub.ihme.washington.edu/spaces/SSE/pages/210206856/_TEMPLATE)176589711 (https://hub.ihme.washington.edu/spaces/SSE/pages/176589711/Design+documents)SSEAt the start of each invocation, fetch the template body so the section order, header table, and placeholder language are current:
mcp__plugin_mcp-hub_mcp-hub__get_page(page_id="210206856")
The returned body_storage is Confluence storage XHTML — that is what you will reuse for the new page. The placeholder prompts inside it (italic guidance, <ac:placeholder> blocks) describe what each section is for.
Work iteratively. For each section the user has content for, propose Confluence storage XHTML (the same format the template uses). Keep all section headings even when a section is short — engineers scanning the doc rely on the rhythm. Use *na* when a section truly doesn't apply (e.g. Current state for a greenfield effort). You may also add new sections if it seems relevant.
A few notes based on existing docs:
X.01 convention (1.01, 2.01, …). For guidance about the pointing convention, consult page id 176590586 (https://hub.ihme.washington.edu/spaces/SSE/pages/176590586/Point+Jira+Tickets) Do not fill in the Ticket column — that is for the user to update as they create tickets.Show the user the draft. Do not call create_page until the user explicitly approves the copy.
Once the user approves, create the page directly:
mcp__plugin_mcp-hub_mcp-hub__create_page(
space="SSE",
parent_id="176589711",
title="<doc title>",
body=<full storage-format XHTML, headings + content>,
)
For subsequent edits, use mcp__plugin_mcp-hub_mcp-hub__update_page — prefer mode="replace_section" with the heading name when revising one section, and pass expected_version from a fresh get_page to avoid clobbering concurrent edits.
This skill does not transition the page status, review the doc, or notify reviewers. Leave it in DRAFT and let the user circulate it.
Guided iteration loop for a vivarium model — take one model change from a research-spec doc through a staged artifact→component→observer build, InteractiveContext verification, review, and a PR. Use when the user asks to implement or iterate a model concept (a cause, risk, intervention, or observer) in an existing model repo from its vivarium-research documentation, or names a MIC ticket that points at one.
Use when the user asks about vivarium-suite CI — build status, Jenkins console logs, job structure, GitHub Actions runs, etc. Covers the GH Actions / Jenkins setup, the per-package Multibranch Pipeline layout, URL-to-jobFullName translation for the Jenkins MCP, and parallel matrix log interleaving.
Reference for the shared `make` targets used across vivarium repositories, centralized in `vivarium/build_utils/resources/makefiles/`. Use this when the task involves making a new conda environment, formatting code, running development checks, or type hinting. Use whenever the user asks what a `make <target>` does in a vivarium repo, mentions running `make` in this ecosystem, or whenever another skill or instruction says "run `make X`" and you need to know exactly what it does, its arguments, env vars, and side effects.
Internal building block invoked by /viv:code-reviewer (and framework-development's review phase): runs the multi-agent review fan-out + functional-correctness pass + per-finding confidence scoring + synthesis on a diff the caller has already gathered. Not a review entry point — to review a PR, use /viv:code-reviewer.
Use after a code review when some findings won't be addressed in the current PR — triages them into Jira ticket recommendations. Classifies each unaddressed finding (address-now / ticket / drop), groups ticket candidates by theme, checks the MIC backlog for duplicates via the `_duplicate_finder` sub-agent, then drafts and files tickets per team conventions, every write gated on explicit user approval. Trigger on "triage the findings", "file tickets for the rest", "turn these review comments into tickets", or when the user defers review findings after `/viv:code-reviewer`.
Propagate an adapted copy of a reference file or directory across several targets — monorepo libs and/or external repos — in parallel, then file one draft PR per repo. Use when the user wants to roll a piece of boilerplate or config out to many places at once. Not for a single-target edit (just edit it) and not when the change needs bespoke per-target design rather than adaptation of a shared reference.