[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6CVRAK8SNRVYV5Q6FPMSK06":3,"skill-same:01M6CVRAK8SNRVYV5Q6FPMSK06":91},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":18,"publishedAt":38,"linkOnly":39,"markdownContent":40,"markdownBody":41,"frontMatter":42,"refName":43,"commitSha":44,"skillDirectory":45,"forksCount":46,"repositoryHtmlUrl":47,"repositoryHomepageUrl":6,"ownerHtmlUrl":48,"ownerBlogUrl":49,"ownerDescription":6,"updatedAt":50,"install":51,"resources":64},"01M6CVRAK8SNRVYV5Q6FPMSK06","review",null,"Review or audit analytical code and scientific changes in statistics, ML, bioinformatics, or data pipelines. Use for PRs, commits, diffs, sanity checks, correctness questions, pre-merge review, tripwire testing, or conversational grill mode. Consult the bundled statistical, leakage, bioinformatics, documentation, LLM-failure, and code-quality checklists; synthesize prioritized findings. Do not use for writing new analysis, reports, brainstorming, project initialization, or pure software review with no analytical component.","arjunrajlaboratory\u002Fmycelium","arjunrajlaboratory","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F59969125?v=4","01M6CVPTM66Z3J8E20GYXJ1RQJ","Arjun Raj's systems biology lab","01M6CVPTRFA9TWRGGB81YN4AP0",72,"MIT","https:\u002F\u002Fgithub.com\u002Farjunrajlaboratory\u002Fmycelium\u002Fblob\u002Fmain\u002Fskills\u002Freview\u002FSKILL.md",[],[5,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37],"tripwire","synthesize","do","grill","reports","use","code-quality","consult","commits","analysis","testing","audit","code","ml","brainstorming","documentation","component","diffs","writing","2026-11-10 10:12:30",false,"---\nname: review\ndescription: >\n  Review or audit analytical code and scientific changes in statistics, ML,\n  bioinformatics, or data pipelines. Use for PRs, commits, diffs, sanity checks,\n  correctness questions, pre-merge review, tripwire testing, or conversational\n  grill mode. Consult the bundled statistical, leakage, bioinformatics,\n  documentation, LLM-failure, and code-quality checklists; synthesize prioritized\n  findings. Do not use for writing new analysis, reports, brainstorming, project\n  initialization, or pure software review with no analytical component.\n---\n\n# Mycelium — Review\n\nResolve bundled `skills\u002F` paths relative to the Mycelium plugin root (two\ndirectories above this `SKILL.md`). Resolve repository and `.living\u002F` paths\nrelative to the user's working repository.\n\nReview code, analysis, or documentation changes for the kinds of mistakes that\nmatter in scientific data work. Two modes plus one opt-in follow-up:\n\n- **Default**: dispatch six specialized sub-agents, parallelized up to the\n  host capacity and run in waves when necessary, then synthesize a single\n  prioritized report.\n- **`grill`**: walk the user through every consequential analytical decision\n  conversationally, one question at a time.\n- **Tripwires (opt-in, offered after default)**: perturb inputs and verify\n  the pipeline actually fails at named scientific boundaries. Three\n  categories — fault-injection, metamorphic, and known-answer tests.\n  Three modes — **audit** (default: write a behavioral spec describing\n  which tripwires would apply, no code runs), **scaffold** (propose\n  project-specific patches that add the instrumentation hooks),\n  **run** (execute against existing instrumentation). Scaffold and\n  run are agent-improvised per analysis rather than template-stamped.\n  See `skills\u002Fcore\u002Freferences\u002Freview\u002Fdeep-tripwires.md`.\n\nThe point of progressive disclosure is that the main skill stays under your\ncontext budget and only loads the per-domain checklists into the sub-agents\nthat need them. Don't read the per-agent checklists yourself unless you are\ndebugging the skill — pass the file paths to the sub-agents.\n\n## Why this skill exists\n\nLLM coding agents tend to make the same kinds of mistakes when generating\nanalysis code, and many are silent: code that runs cleanly and produces a\nconfidently wrong number. This skill encodes the catalog of those failure\nmodes, partitions them across six specialists so each can hold a tight prompt,\nand aggressively prunes false positives in synthesis. Severity calibration\nmatters more than raw recall — a list of fifty nits buries the one critical\nfinding.\n\n## What gets reviewed\n\nThe skill works on any of the following review scopes. If the user did not\nspecify, ask once which scope they want.\n\n| Scope | How to obtain the diff |\n|-------|------------------------|\n| **PR** (`\u002Fmycelium:review \u003CPR#>` or PR URL) | `gh pr diff \u003Cnum>` plus `gh pr view \u003Cnum> --json files,body,title` for context |\n| **Commit \u002F commit range** (`\u002Fmycelium:review \u003Csha>` or `\u003Csha1>..\u003Csha2>`) | `git show \u003Csha>` or `git diff \u003Csha1>..\u003Csha2>` |\n| **Working tree** (default if no scope given on a dirty repo) | `git diff HEAD` plus `git status` |\n| **Branch vs main** | `git diff main...HEAD` |\n| **Pasted diff** (user dumped a diff into chat) | Use the diff verbatim |\n| **Whole analysis directory** (`\u002Fmycelium:review analysis\u002F\u003Cname>`) | Read the directory; treat all files as \"added\" |\n\nFor all scopes: also collect the relevant context — the analysis's\n`UPPER_SNAKE_CASE.md` documentation file, `specification.md` if present,\n`.living\u002Fdecisions.md`, and any installed convention packs in\n`.living\u002Fconventions\u002F` — and pass these into each sub-agent so it can ground\nfindings in the project's stated intent rather than inferring from code alone.\n\n## Default mode protocol\n\n### Step 1 — Establish review scope\n\nDetermine the scope from the user's invocation. If unclear, ask one short\nquestion (\"review the working tree, last commit, or a specific PR?\") rather\nthan guessing. For PRs, fetch with `gh`. For commits\u002Fworking tree, use `git`.\n\nCapture the diff, the list of touched files, and any relevant context files\ninto local variables (or a scratch file in `\u002Ftmp\u002F`) so the sub-agents share a\ncommon substrate.\n\n### Step 2 — Dispatch six sub-agents in parallel (or run their checklists in-line)\n\nIf the `Agent` tool is available to you, schedule all six specialists while\nrespecting the host capacity (subagent_type `general-purpose` is fine; for very\nlarge diffs prefer `Explore`). Run as many concurrently as the host permits,\nwait for that wave to finish, and dispatch the remaining specialists in later\nwaves. Do not assume that six slots are available. If dispatch reports\n`agent thread limit reached`, wait for an active specialist to finish and retry\nthe undispatched specialist once; if capacity remains unavailable, run that\nchecklist in-line. If the `Agent` tool is *not* available (common when this\nskill runs from inside a sub-agent context that doesn't expose it), execute\neach specialist's checklist in-line: read each checklist file in turn, apply it\nto the diff, collect findings, then proceed to synthesis. Either way the output\ncontract and the synthesis steps are the same, and every applicable checklist\nmust run exactly once.\n\nEach sub-agent (or in-line pass) gets:\n\n1. The diff (or path to it if large)\n2. The list of context files to read\n3. The path to its checklist reference: `skills\u002Fcore\u002Freferences\u002Freview\u002F\u003Cagent>.md`\n4. A clear instruction to follow the output contract in\n   `skills\u002Fcore\u002Freferences\u002Freview\u002FREADME.md` exactly. The required\n   fields per finding are `severity` (`major | minor`), `file`, `line`\n   (or range), `category`, `summary`, `evidence` (a 1–5 line verbatim\n   code snippet — the synthesis pass renders this directly under each\n   finding), `why_it_matters` (one or two sentences specific to this\n   analysis), `suggested_fix`, and `confidence` (`high | medium |\n   low`). Anything the agent considered and decided not to flag goes\n   in a separate `not_flagged` list with `file`, `line`, `considered`,\n   and `reason` — synthesis uses this to dedupe across agents.\n   Sub-agents should also return a `decisions` list of consequential\n   analytical choices in their scope (per the README contract); these\n   roll up into the report's \"Key decisions in this analysis\" section.\n5. The standing instruction to err on the side of NOT flagging when the\n   evidence is weak — false positives are more costly than false negatives at\n   this stage because synthesis can ask follow-up questions but cannot\n   reconstruct missing certainty.\n\nThe six sub-agents and their checklist files:\n\n| # | Sub-agent | Checklist file | Focus |\n|---|-----------|----------------|-------|\n| 1 | **stats-causal** | `skills\u002Fcore\u002Freferences\u002Freview\u002Fstats-causal.md` | Test selection, multiple comparisons, p-hacking, causal claims, effect-size reporting, study design |\n| 2 | **data-pipeline-leakage** | `skills\u002Fcore\u002Freferences\u002Freview\u002Fdata-pipeline-leakage.md` | Train\u002Ftest contamination, time-series look-ahead, joins, missing values, dedup, units, batch effects, ML evaluation |\n| 3 | **bioinformatics** | `skills\u002Fcore\u002Freferences\u002Freview\u002Fbioinformatics.md` | Gene names, reference genome, scRNA-seq pipeline, RNA-seq DE, double dipping, pseudoreplication |\n| 4 | **llm-failure-modes** | `skills\u002Fcore\u002Freferences\u002Freview\u002Fllm-failure-modes.md` | Try\u002Fexcept antipatterns, hallucinated APIs, default-parameter smuggling, sycophancy\u002Fforking-paths drift, fabricated tool output |\n| 5 | **doc-schema-fidelity** | `skills\u002Fcore\u002Freferences\u002Freview\u002Fdoc-schema-fidelity.md` | Docstrings\u002Fspecs\u002Fschemas\u002FREADMEs vs reality, definition drift, comment freshness, undocumented behavior |\n| 6 | **code-quality** | `skills\u002Fcore\u002Freferences\u002Freview\u002Fcode-quality.md` | Duplicate sources of truth, boolean flag pairs, misleading names, premature abstractions, secrets, import hacks, BC cruft, file organization, logging consistency |\n\nThe bioinformatics agent should self-skip with a one-line \"no biology here\" if\nthe diff doesn't touch genomic data — don't spawn it if the project clearly\nisn't biology, but err on the side of running it for any project that has ever\ntouched a sequence file, gene table, or single-cell object.\n\n### Step 3 — Synthesize\n\nRead `skills\u002Fcore\u002Freferences\u002Freview\u002Fsynthesis.md` and follow it. The short\nform:\n\n1. Aggregate findings across sub-agents and dedupe. Two sub-agents\n   flagging the same line with different framings is the common case —\n   keep the more actionable framing and add a one-line \"see also\" if the\n   other framing adds value.\n   One root cause gets one finding ID even when it has several consequences,\n   affected files, or remediation steps. Nest those details under that finding;\n   do not inflate the total by splitting one defect into multiple framings.\n2. Recalibrate severity to two levels: **Major** (fix this — result\n   invalid, misleading, or insecure) and **Minor** (consider improving —\n   doesn't change the conclusion). Drop pure stylistic nits a linter\n   would catch.\n3. Identify the **key analytical decisions** in the work — the\n   consequential choices that, if changed, would meaningfully change the\n   result (estimand, sample-filtering thresholds, normalization, model \u002F\n   test choice, multiple-comparison handling, train\u002Ftest strategy,\n   reference choice, etc.). List them whether or not each has an\n   associated finding.\n4. Draft 3–5 **questions for the analyst** — meta-level questions whose\n   answers change which findings matter most (e.g., \"is this for\n   wet-lab validation or paper figure?\", \"are donors technical or\n   biological replicates?\", \"is the deployment seeing the same\n   customers or new ones?\"). The diff can't answer these.\n5. For each finding, include: file:line, a 1–5 line code snippet\n   verbatim from the source so the user sees the issue without opening\n   the file, why it matters *for this analysis specifically*, and a\n   one-sentence fix.\n6. Group findings by category (the six sub-agent areas), and within each\n   category list Major findings first, then Minor.\n7. Number findings F1, F2, F3 ... globally so the Key decisions and\n   Questions sections can link to them where useful.\n8. Derive every reported count from the final `##### F\u003Cn>.` headings. Add the\n   required Finding tally table, then run the deterministic validator before\n   reporting or writing a handoff:\n   `python3 \"$(cat .mycelium\u002Fplugin-root)\u002Fskills\u002Fcore\u002Fscripts\u002Fvalidate_review_report.py\" \u003Creport>`.\n   If it fails, repair IDs, severities, or tallies and rerun it. Never copy an\n   earlier draft's hand-count into chat or `.mycelium\u002Flast-session.md`.\n\n### Step 4 — Render the report\n\nWrite the report to a file under `.living\u002Foutputs\u002Freviews\u002F` named\n`YYYY-MM-DD-\u003Cscope-slug>.md` (e.g., `2026-04-24-pr-127.md`,\n`2026-04-24-working-tree.md`). The structure:\n\n```markdown\n# Review — \u003Cscope> — YYYY-MM-DD\n\n**Scope**: \u003CPR \u002F commit range \u002F working tree \u002F pasted diff>\n**Files reviewed**: N\n**Sub-agents run**: 6 (or list which were skipped and why)\n\n## Key decisions in this analysis\n\n- **\u003CDecision>** — \u003Cone-line description>. \u003Csee F2 if linked, or no\n  link if informational>\n- ...\n\n## Questions for the analyst\n\nThree to five open-ended questions whose answers would change which\nfindings matter most (analysis goal, replicate type, downstream use,\nacceptable false-positive rate, registration status, deployment\ncontext). The diff can't answer these — only the analyst can.\n\n- \u003CQuestion>\n- ...\n\n## Findings\n\n### Statistics & causal inference\n#### Major\n##### F1. \u003Cshort description>\n`\u003Cfile>:\u003Cline>`\n```python\n\u003C1-5 lines verbatim>\n```\n**Why it matters here**: ...\n**Fix**: ...\n\n#### Minor\n##### F2. ...\n\n### Data pipeline & leakage\n... (Major \u002F Minor under each category)\n\n### Bioinformatics\n...\n\n### LLM coding antipatterns\n...\n\n### Documentation & schema fidelity\n...\n\n### Code quality\n...\n\n## What was checked but is fine\n- **Statistics & causal inference**: \u003Cone sentence>\n- ...\n\n## Finding tally\n\n| Category | Major | Minor | Total |\n| --- | ---: | ---: | ---: |\n| Statistics & causal inference | N | N | N |\n| Data pipeline & leakage | N | N | N |\n| Bioinformatics | N | N | N |\n| LLM coding antipatterns | N | N | N |\n| Documentation & schema fidelity | N | N | N |\n| Code quality | N | N | N |\n| **Total** | **N** | **N** | **N** |\n\n## Notes\n- Cross-cutting observations: compound findings sharing one remediation\n  path, \"did this code ever run\" questions, etc.\n```\n\nPrint the path of the written file at the end. The chat reply should\nsurface the validator-confirmed count of Major findings per category and the\n\"Key decisions\" list so the user sees the shape of the report without opening\nthe file.\n\n### Step 5 — Offer tripwires (opt-in behavioral follow-up)\n\nRead `skills\u002Fcore\u002Freferences\u002Freview\u002Fdeep-tripwires.md` and follow it.\nThe short form (two terms before the steps: an **audit** is the\n*default artifact* — a written document that walks the analysis, names\neach tripwire that would apply, names the perturbation and expected\noutcome, links each to a static finding, and surfaces what's missing\nif you wanted to execute. No code runs. **Instrumentation** is the\nfour observability hooks the pipeline needs for tripwires to actually\nexecute: checkpoint emission, `--stop-after`, `analysis_labels.yml`,\nand a drop ledger. Definitions and the full mode table are in\n`deep-tripwires.md` \"Three operating modes\"):\n\n1. Scan the static findings for `suggested_tripwire` tags emitted by\n   the sub-agents (see the output contract in `review\u002FREADME.md`).\n2. Detect whether the repo has any of the four instrumentation hooks\n   (checkpoint logging anywhere in the analysis scripts, a\n   `--stop-after` \u002F `STOP_AFTER_CHECKPOINT` mechanism, an\n   `analysis_labels.yml` or equivalent at the analysis root, a drop\n   ledger of any name\u002Fshape, an existing tripwire runner under\n   `tools\u002F`). Names and formats are illustrative — accept what the\n   project uses. This picks the default mode: `audit` if zero or\n   only some hooks are present, `scaffold` if the user asks to add\n   them, `run` if all four are present.\n3. Use `AskUserQuestion` to offer a menu. **Lead every user-facing\n   surface with plain English; keep internal IDs in parentheses or\n   in artifacts.** See `deep-tripwires.md` \"Talking to the user\" for\n   the gloss table. Examples of well-phrased options: \"Describe what\n   we'd test (no code runs)\" rather than \"audit mode\"; \"Propose\n   project-specific patches that would let us actually run the\n   tests\" rather than \"scaffold mode\". Always include \"skip\" and the\n   audit option. Include \"scaffold\" if the hooks are partial or\n   absent. Include \"run selected tripwires\" if all four hooks are\n   present. The list of named tripwires on the menu is shaped by\n   which `suggested_tripwire` tags appeared in the static findings,\n   plus the starter four (missing counts, missing metadata sample,\n   label permutation, toy contrast direction) which are always\n   available. When naming individual tripwires in the menu, use the\n   plain-English glosses (\"the report-numbers-still-match check\")\n   not the internal IDs.\n4. Execute the chosen mode per `deep-tripwires.md`. Scaffold-mode\n   and run-mode are **agent-improvised per analysis** — the skill\n   ships principles + examples, and the agent reads the project's\n   language \u002F layout \u002F existing helpers and adapts. Do not stamp\n   templates blindly; if the project already has a logging or\n   filter helper, build on it. Output paths:\n   - audit → `.living\u002Foutputs\u002Freviews\u002FYYYY-MM-DD-\u003Cscope-slug>-tripwires.md`\n   - scaffold → `…-tripwires-scaffold.md` (proposal, not auto-applied)\n   - run → `…-tripwires-run.md` (pass\u002Ffail per tripwire)\n\nPrint the written path(s) at the end.\n\n**Reporting rule (applies to every mode).** When summarizing the\nresult back to the user in chat, lead with one English sentence\n(\"Three places in your docs cite p-values that don't match the\nsource CSV\"), then show the table \u002F artifact as evidence. Don't\nopen with `Instrumentation detected: 0\u002F4` or raw checkmark\u002FX\noutput. The user wants to know what failed and why before they\nneed the test IDs.\n\nSkip Step 5 entirely if the diff is a pure refactor with no data-flow\nchange AND no documentation change, or if the user invoked the skill\nwith a flag asking to suppress tripwires (e.g., `\u002Fmycelium:review\n--no-tripwires`).\n\n**Documentation-only diffs are NOT a skip case.** When report text or\nanalysis docs change without the pipeline changing, that's exactly\nwhen the report-values-freshness tripwire is most useful — it catches\n\"someone edited the report number without regenerating the source\nCSV\" silently. For doc-only diffs, restrict the offered menu to the\nfreshness and known-answer categories (the fault-injection and\nmetamorphic tripwires don't apply when the pipeline wasn't touched)\nrather than skipping Step 5.\n\n### Step 6 — Post-action hook\n\nTreat a review as a significant action: log a short entry to\n`.living\u002Flearnings.md` if the review surfaced a recurring pattern (e.g., \"the\nanalyze script is using `t-test` on count data — this is the third time this\npattern has come up, consider a convention\"). Derive `mitigation_type` by the rule in `skills\u002Fcore\u002Ftemplates\u002Flearning-entry.md`: `structural` if a shipped test, assertion, type constraint, frozenset, or schema validation enforces it; otherwise `convention` if a `.living\u002Fconventions.md` entry covers it; otherwise `ambient-awareness`. Otherwise no logging is needed.\n\n## Grill mode protocol\n\nTriggered by the user invoking with `grill` in their request, e.g.,\n`\u002Fmycelium:review grill` or \"grill me on this analysis\".\n\nRead `skills\u002Fcore\u002Freferences\u002Freview\u002Fgrill-mode.md` and follow it. The short\nform:\n\n1. Identify the consequential decisions in the analysis. These are anything\n   that, if changed, would meaningfully change the result: choice of\n   statistical test, multiple-comparison correction, sample-filtering\n   thresholds, normalization steps, clustering parameters, train\u002Ftest split\n   strategy, choice of estimand, choice of reference (genome, baseline,\n   comparator), exclusion criteria, etc. Read `.living\u002Fdecisions.md` and the\n   analysis script(s) to extract these.\n2. **One question per turn**, conversationally phrased. Do not dump a\n   numbered list. The point is to feel like a thoughtful colleague over coffee,\n   not a checklist. Acknowledge the answer, then move to the next.\n3. Track answers internally. After ~5–8 exchanges (or when the user signals\n   they want to wrap up), produce a short summary: which decisions had clear\n   justifications, which the user wasn't sure about, which deserve a\n   follow-up. Offer to file the unsure ones as `todo\u002F` items.\n4. If the user gives a justification that itself reveals a problem (e.g.,\n   \"we used t-test because that's what the tutorial used\"), don't lecture —\n   ask the next question that exposes the implication (\"got it — and the\n   data here is counts, right? do we expect the t-test assumptions to hold\n   on counts?\"). Trust theory of mind.\n\nThe aim of grill mode is to help the user converge on what they actually\nbelieve about each choice without exhausting them. If at any point they say\n\"enough\" or \"let's stop,\" stop and write the partial summary.\n\n## What this skill is NOT for\n\n- Running the analysis (`\u002Fmycelium:analyze`)\n- Generating a report or paper section (`\u002Fmycelium:report`)\n- Repo-wide refactoring without an analysis context — use a generic code\n  reviewer for that\n- Stylistic \u002F linting work — let the linter handle it\n- Validating raw data ingestion — `\u002Fmycelium:ingest` covers that with its\n  own checks\n\n## Cross-references inside this skill\n\n- `skills\u002Fcore\u002Freferences\u002Freview\u002Fsynthesis.md` — synthesis & severity\n  calibration\n- `skills\u002Fcore\u002Freferences\u002Freview\u002Fgrill-mode.md` — grill protocol detail\n- `skills\u002Fcore\u002Freferences\u002Freview\u002Fdeep-tripwires.md` — behavioral\n  follow-up (Step 5)\n- Per-agent checklists under `skills\u002Fcore\u002Freferences\u002Freview\u002F` (six files;\n  loaded by sub-agents, not by you)\n- The mycelium core `Post-Action Hook Protocol` from `..\u002Fcore\u002FSKILL.md`\n  governs what to log to `.living\u002F` when a review surfaces a recurring\n  pattern\n","# Mycelium — Review\n\nResolve bundled `skills\u002F` paths relative to the Mycelium plugin root (two\ndirectories above this `SKILL.md`). Resolve repository and `.living\u002F` paths\nrelative to the user's working repository.\n\nReview code, analysis, or documentation changes for the kinds of mistakes that\nmatter in scientific data work. Two modes plus one opt-in follow-up:\n\n- **Default**: dispatch six specialized sub-agents, parallelized up to the\n  host capacity and run in waves when necessary, then synthesize a single\n  prioritized report.\n- **`grill`**: walk the user through every consequential analytical decision\n  conversationally, one question at a time.\n- **Tripwires (opt-in, offered after default)**: perturb inputs and verify\n  the pipeline actually fails at named scientific boundaries. Three\n  categories — fault-injection, metamorphic, and known-answer tests.\n  Three modes — **audit** (default: write a behavioral spec describing\n  which tripwires would apply, no code runs), **scaffold** (propose\n  project-specific patches that add the instrumentation hooks),\n  **run** (execute against existing instrumentation). Scaffold and\n  run are agent-improvised per analysis rather than template-stamped.\n  See `skills\u002Fcore\u002Freferences\u002Freview\u002Fdeep-tripwires.md`.\n\nThe point of progressive disclosure is that the main skill stays under your\ncontext budget and only loads the per-domain checklists into the sub-agents\nthat need them. Don't read the per-agent checklists yourself unless you are\ndebugging the skill — pass the file paths to the sub-agents.\n\n## Why this skill exists\n\nLLM coding agents tend to make the same kinds of mistakes when generating\nanalysis code, and many are silent: code that runs cleanly and produces a\nconfidently wrong number. This skill encodes the catalog of those failure\nmodes, partitions them across six specialists so each can hold a tight prompt,\nand aggressively prunes false positives in synthesis. Severity calibration\nmatters more than raw recall — a list of fifty nits buries the one critical\nfinding.\n\n## What gets reviewed\n\nThe skill works on any of the following review scopes. If the user did not\nspecify, ask once which scope they want.\n\n| Scope | How to obtain the diff |\n|-------|------------------------|\n| **PR** (`\u002Fmycelium:review \u003CPR#>` or PR URL) | `gh pr diff \u003Cnum>` plus `gh pr view \u003Cnum> --json files,body,title` for context |\n| **Commit \u002F commit range** (`\u002Fmycelium:review \u003Csha>` or `\u003Csha1>..\u003Csha2>`) | `git show \u003Csha>` or `git diff \u003Csha1>..\u003Csha2>` |\n| **Working tree** (default if no scope given on a dirty repo) | `git diff HEAD` plus `git status` |\n| **Branch vs main** | `git diff main...HEAD` |\n| **Pasted diff** (user dumped a diff into chat) | Use the diff verbatim |\n| **Whole analysis directory** (`\u002Fmycelium:review analysis\u002F\u003Cname>`) | Read the directory; treat all files as \"added\" |\n\nFor all scopes: also collect the relevant context — the analysis's\n`UPPER_SNAKE_CASE.md` documentation file, `specification.md` if present,\n`.living\u002Fdecisions.md`, and any installed convention packs in\n`.living\u002Fconventions\u002F` — and pass these into each sub-agent so it can ground\nfindings in the project's stated intent rather than inferring from code alone.\n\n## Default mode protocol\n\n### Step 1 — Establish review scope\n\nDetermine the scope from the user's invocation. If unclear, ask one short\nquestion (\"review the working tree, last commit, or a specific PR?\") rather\nthan guessing. For PRs, fetch with `gh`. For commits\u002Fworking tree, use `git`.\n\nCapture the diff, the list of touched files, and any relevant context files\ninto local variables (or a scratch file in `\u002Ftmp\u002F`) so the sub-agents share a\ncommon substrate.\n\n### Step 2 — Dispatch six sub-agents in parallel (or run their checklists in-line)\n\nIf the `Agent` tool is available to you, schedule all six specialists while\nrespecting the host capacity (subagent_type `general-purpose` is fine; for very\nlarge diffs prefer `Explore`). Run as many concurrently as the host permits,\nwait for that wave to finish, and dispatch the remaining specialists in later\nwaves. Do not assume that six slots are available. If dispatch reports\n`agent thread limit reached`, wait for an active specialist to finish and retry\nthe undispatched specialist once; if capacity remains unavailable, run that\nchecklist in-line. If the `Agent` tool is *not* available (common when this\nskill runs from inside a sub-agent context that doesn't expose it), execute\neach specialist's checklist in-line: read each checklist file in turn, apply it\nto the diff, collect findings, then proceed to synthesis. Either way the output\ncontract and the synthesis steps are the same, and every applicable checklist\nmust run exactly once.\n\nEach sub-agent (or in-line pass) gets:\n\n1. The diff (or path to it if large)\n2. The list of context files to read\n3. The path to its checklist reference: `skills\u002Fcore\u002Freferences\u002Freview\u002F\u003Cagent>.md`\n4. A clear instruction to follow the output contract in\n   `skills\u002Fcore\u002Freferences\u002Freview\u002FREADME.md` exactly. The required\n   fields per finding are `severity` (`major | minor`), `file`, `line`\n   (or range), `category`, `summary`, `evidence` (a 1–5 line verbatim\n   code snippet — the synthesis pass renders this directly under each\n   finding), `why_it_matters` (one or two sentences specific to this\n   analysis), `suggested_fix`, and `confidence` (`high | medium |\n   low`). Anything the agent considered and decided not to flag goes\n   in a separate `not_flagged` list with `file`, `line`, `considered`,\n   and `reason` — synthesis uses this to dedupe across agents.\n   Sub-agents should also return a `decisions` list of consequential\n   analytical choices in their scope (per the README contract); these\n   roll up into the report's \"Key decisions in this analysis\" section.\n5. The standing instruction to err on the side of NOT flagging when the\n   evidence is weak — false positives are more costly than false negatives at\n   this stage because synthesis can ask follow-up questions but cannot\n   reconstruct missing certainty.\n\nThe six sub-agents and their checklist files:\n\n| # | Sub-agent | Checklist file | Focus |\n|---|-----------|----------------|-------|\n| 1 | **stats-causal** | `skills\u002Fcore\u002Freferences\u002Freview\u002Fstats-causal.md` | Test selection, multiple comparisons, p-hacking, causal claims, effect-size reporting, study design |\n| 2 | **data-pipeline-leakage** | `skills\u002Fcore\u002Freferences\u002Freview\u002Fdata-pipeline-leakage.md` | Train\u002Ftest contamination, time-series look-ahead, joins, missing values, dedup, units, batch effects, ML evaluation |\n| 3 | **bioinformatics** | `skills\u002Fcore\u002Freferences\u002Freview\u002Fbioinformatics.md` | Gene names, reference genome, scRNA-seq pipeline, RNA-seq DE, double dipping, pseudoreplication |\n| 4 | **llm-failure-modes** | `skills\u002Fcore\u002Freferences\u002Freview\u002Fllm-failure-modes.md` | Try\u002Fexcept antipatterns, hallucinated APIs, default-parameter smuggling, sycophancy\u002Fforking-paths drift, fabricated tool output |\n| 5 | **doc-schema-fidelity** | `skills\u002Fcore\u002Freferences\u002Freview\u002Fdoc-schema-fidelity.md` | Docstrings\u002Fspecs\u002Fschemas\u002FREADMEs vs reality, definition drift, comment freshness, undocumented behavior |\n| 6 | **code-quality** | `skills\u002Fcore\u002Freferences\u002Freview\u002Fcode-quality.md` | Duplicate sources of truth, boolean flag pairs, misleading names, premature abstractions, secrets, import hacks, BC cruft, file organization, logging consistency |\n\nThe bioinformatics agent should self-skip with a one-line \"no biology here\" if\nthe diff doesn't touch genomic data — don't spawn it if the project clearly\nisn't biology, but err on the side of running it for any project that has ever\ntouched a sequence file, gene table, or single-cell object.\n\n### Step 3 — Synthesize\n\nRead `skills\u002Fcore\u002Freferences\u002Freview\u002Fsynthesis.md` and follow it. The short\nform:\n\n1. Aggregate findings across sub-agents and dedupe. Two sub-agents\n   flagging the same line with different framings is the common case —\n   keep the more actionable framing and add a one-line \"see also\" if the\n   other framing adds value.\n   One root cause gets one finding ID even when it has several consequences,\n   affected files, or remediation steps. Nest those details under that finding;\n   do not inflate the total by splitting one defect into multiple framings.\n2. Recalibrate severity to two levels: **Major** (fix this — result\n   invalid, misleading, or insecure) and **Minor** (consider improving —\n   doesn't change the conclusion). Drop pure stylistic nits a linter\n   would catch.\n3. Identify the **key analytical decisions** in the work — the\n   consequential choices that, if changed, would meaningfully change the\n   result (estimand, sample-filtering thresholds, normalization, model \u002F\n   test choice, multiple-comparison handling, train\u002Ftest strategy,\n   reference choice, etc.). List them whether or not each has an\n   associated finding.\n4. Draft 3–5 **questions for the analyst** — meta-level questions whose\n   answers change which findings matter most (e.g., \"is this for\n   wet-lab validation or paper figure?\", \"are donors technical or\n   biological replicates?\", \"is the deployment seeing the same\n   customers or new ones?\"). The diff can't answer these.\n5. For each finding, include: file:line, a 1–5 line code snippet\n   verbatim from the source so the user sees the issue without opening\n   the file, why it matters *for this analysis specifically*, and a\n   one-sentence fix.\n6. Group findings by category (the six sub-agent areas), and within each\n   category list Major findings first, then Minor.\n7. Number findings F1, F2, F3 ... globally so the Key decisions and\n   Questions sections can link to them where useful.\n8. Derive every reported count from the final `##### F\u003Cn>.` headings. Add the\n   required Finding tally table, then run the deterministic validator before\n   reporting or writing a handoff:\n   `python3 \"$(cat .mycelium\u002Fplugin-root)\u002Fskills\u002Fcore\u002Fscripts\u002Fvalidate_review_report.py\" \u003Creport>`.\n   If it fails, repair IDs, severities, or tallies and rerun it. Never copy an\n   earlier draft's hand-count into chat or `.mycelium\u002Flast-session.md`.\n\n### Step 4 — Render the report\n\nWrite the report to a file under `.living\u002Foutputs\u002Freviews\u002F` named\n`YYYY-MM-DD-\u003Cscope-slug>.md` (e.g., `2026-04-24-pr-127.md`,\n`2026-04-24-working-tree.md`). The structure:\n\n```markdown\n# Review — \u003Cscope> — YYYY-MM-DD\n\n**Scope**: \u003CPR \u002F commit range \u002F working tree \u002F pasted diff>\n**Files reviewed**: N\n**Sub-agents run**: 6 (or list which were skipped and why)\n\n## Key decisions in this analysis\n\n- **\u003CDecision>** — \u003Cone-line description>. \u003Csee F2 if linked, or no\n  link if informational>\n- ...\n\n## Questions for the analyst\n\nThree to five open-ended questions whose answers would change which\nfindings matter most (analysis goal, replicate type, downstream use,\nacceptable false-positive rate, registration status, deployment\ncontext). The diff can't answer these — only the analyst can.\n\n- \u003CQuestion>\n- ...\n\n## Findings\n\n### Statistics & causal inference\n#### Major\n##### F1. \u003Cshort description>\n`\u003Cfile>:\u003Cline>`\n```python\n\u003C1-5 lines verbatim>\n```\n**Why it matters here**: ...\n**Fix**: ...\n\n#### Minor\n##### F2. ...\n\n### Data pipeline & leakage\n... (Major \u002F Minor under each category)\n\n### Bioinformatics\n...\n\n### LLM coding antipatterns\n...\n\n### Documentation & schema fidelity\n...\n\n### Code quality\n...\n\n## What was checked but is fine\n- **Statistics & causal inference**: \u003Cone sentence>\n- ...\n\n## Finding tally\n\n| Category | Major | Minor | Total |\n| --- | ---: | ---: | ---: |\n| Statistics & causal inference | N | N | N |\n| Data pipeline & leakage | N | N | N |\n| Bioinformatics | N | N | N |\n| LLM coding antipatterns | N | N | N |\n| Documentation & schema fidelity | N | N | N |\n| Code quality | N | N | N |\n| **Total** | **N** | **N** | **N** |\n\n## Notes\n- Cross-cutting observations: compound findings sharing one remediation\n  path, \"did this code ever run\" questions, etc.\n```\n\nPrint the path of the written file at the end. The chat reply should\nsurface the validator-confirmed count of Major findings per category and the\n\"Key decisions\" list so the user sees the shape of the report without opening\nthe file.\n\n### Step 5 — Offer tripwires (opt-in behavioral follow-up)\n\nRead `skills\u002Fcore\u002Freferences\u002Freview\u002Fdeep-tripwires.md` and follow it.\nThe short form (two terms before the steps: an **audit** is the\n*default artifact* — a written document that walks the analysis, names\neach tripwire that would apply, names the perturbation and expected\noutcome, links each to a static finding, and surfaces what's missing\nif you wanted to execute. No code runs. **Instrumentation** is the\nfour observability hooks the pipeline needs for tripwires to actually\nexecute: checkpoint emission, `--stop-after`, `analysis_labels.yml`,\nand a drop ledger. Definitions and the full mode table are in\n`deep-tripwires.md` \"Three operating modes\"):\n\n1. Scan the static findings for `suggested_tripwire` tags emitted by\n   the sub-agents (see the output contract in `review\u002FREADME.md`).\n2. Detect whether the repo has any of the four instrumentation hooks\n   (checkpoint logging anywhere in the analysis scripts, a\n   `--stop-after` \u002F `STOP_AFTER_CHECKPOINT` mechanism, an\n   `analysis_labels.yml` or equivalent at the analysis root, a drop\n   ledger of any name\u002Fshape, an existing tripwire runner under\n   `tools\u002F`). Names and formats are illustrative — accept what the\n   project uses. This picks the default mode: `audit` if zero or\n   only some hooks are present, `scaffold` if the user asks to add\n   them, `run` if all four are present.\n3. Use `AskUserQuestion` to offer a menu. **Lead every user-facing\n   surface with plain English; keep internal IDs in parentheses or\n   in artifacts.** See `deep-tripwires.md` \"Talking to the user\" for\n   the gloss table. Examples of well-phrased options: \"Describe what\n   we'd test (no code runs)\" rather than \"audit mode\"; \"Propose\n   project-specific patches that would let us actually run the\n   tests\" rather than \"scaffold mode\". Always include \"skip\" and the\n   audit option. Include \"scaffold\" if the hooks are partial or\n   absent. Include \"run selected tripwires\" if all four hooks are\n   present. The list of named tripwires on the menu is shaped by\n   which `suggested_tripwire` tags appeared in the static findings,\n   plus the starter four (missing counts, missing metadata sample,\n   label permutation, toy contrast direction) which are always\n   available. When naming individual tripwires in the menu, use the\n   plain-English glosses (\"the report-numbers-still-match check\")\n   not the internal IDs.\n4. Execute the chosen mode per `deep-tripwires.md`. Scaffold-mode\n   and run-mode are **agent-improvised per analysis** — the skill\n   ships principles + examples, and the agent reads the project's\n   language \u002F layout \u002F existing helpers and adapts. Do not stamp\n   templates blindly; if the project already has a logging or\n   filter helper, build on it. Output paths:\n   - audit → `.living\u002Foutputs\u002Freviews\u002FYYYY-MM-DD-\u003Cscope-slug>-tripwires.md`\n   - scaffold → `…-tripwires-scaffold.md` (proposal, not auto-applied)\n   - run → `…-tripwires-run.md` (pass\u002Ffail per tripwire)\n\nPrint the written path(s) at the end.\n\n**Reporting rule (applies to every mode).** When summarizing the\nresult back to the user in chat, lead with one English sentence\n(\"Three places in your docs cite p-values that don't match the\nsource CSV\"), then show the table \u002F artifact as evidence. Don't\nopen with `Instrumentation detected: 0\u002F4` or raw checkmark\u002FX\noutput. The user wants to know what failed and why before they\nneed the test IDs.\n\nSkip Step 5 entirely if the diff is a pure refactor with no data-flow\nchange AND no documentation change, or if the user invoked the skill\nwith a flag asking to suppress tripwires (e.g., `\u002Fmycelium:review\n--no-tripwires`).\n\n**Documentation-only diffs are NOT a skip case.** When report text or\nanalysis docs change without the pipeline changing, that's exactly\nwhen the report-values-freshness tripwire is most useful — it catches\n\"someone edited the report number without regenerating the source\nCSV\" silently. For doc-only diffs, restrict the offered menu to the\nfreshness and known-answer categories (the fault-injection and\nmetamorphic tripwires don't apply when the pipeline wasn't touched)\nrather than skipping Step 5.\n\n### Step 6 — Post-action hook\n\nTreat a review as a significant action: log a short entry to\n`.living\u002Flearnings.md` if the review surfaced a recurring pattern (e.g., \"the\nanalyze script is using `t-test` on count data — this is the third time this\npattern has come up, consider a convention\"). Derive `mitigation_type` by the rule in `skills\u002Fcore\u002Ftemplates\u002Flearning-entry.md`: `structural` if a shipped test, assertion, type constraint, frozenset, or schema validation enforces it; otherwise `convention` if a `.living\u002Fconventions.md` entry covers it; otherwise `ambient-awareness`. Otherwise no logging is needed.\n\n## Grill mode protocol\n\nTriggered by the user invoking with `grill` in their request, e.g.,\n`\u002Fmycelium:review grill` or \"grill me on this analysis\".\n\nRead `skills\u002Fcore\u002Freferences\u002Freview\u002Fgrill-mode.md` and follow it. The short\nform:\n\n1. Identify the consequential decisions in the analysis. These are anything\n   that, if changed, would meaningfully change the result: choice of\n   statistical test, multiple-comparison correction, sample-filtering\n   thresholds, normalization steps, clustering parameters, train\u002Ftest split\n   strategy, choice of estimand, choice of reference (genome, baseline,\n   comparator), exclusion criteria, etc. Read `.living\u002Fdecisions.md` and the\n   analysis script(s) to extract these.\n2. **One question per turn**, conversationally phrased. Do not dump a\n   numbered list. The point is to feel like a thoughtful colleague over coffee,\n   not a checklist. Acknowledge the answer, then move to the next.\n3. Track answers internally. After ~5–8 exchanges (or when the user signals\n   they want to wrap up), produce a short summary: which decisions had clear\n   justifications, which the user wasn't sure about, which deserve a\n   follow-up. Offer to file the unsure ones as `todo\u002F` items.\n4. If the user gives a justification that itself reveals a problem (e.g.,\n   \"we used t-test because that's what the tutorial used\"), don't lecture —\n   ask the next question that exposes the implication (\"got it — and the\n   data here is counts, right? do we expect the t-test assumptions to hold\n   on counts?\"). Trust theory of mind.\n\nThe aim of grill mode is to help the user converge on what they actually\nbelieve about each choice without exhausting them. If at any point they say\n\"enough\" or \"let's stop,\" stop and write the partial summary.\n\n## What this skill is NOT for\n\n- Running the analysis (`\u002Fmycelium:analyze`)\n- Generating a report or paper section (`\u002Fmycelium:report`)\n- Repo-wide refactoring without an analysis context — use a generic code\n  reviewer for that\n- Stylistic \u002F linting work — let the linter handle it\n- Validating raw data ingestion — `\u002Fmycelium:ingest` covers that with its\n  own checks\n\n## Cross-references inside this skill\n\n- `skills\u002Fcore\u002Freferences\u002Freview\u002Fsynthesis.md` — synthesis & severity\n  calibration\n- `skills\u002Fcore\u002Freferences\u002Freview\u002Fgrill-mode.md` — grill protocol detail\n- `skills\u002Fcore\u002Freferences\u002Freview\u002Fdeep-tripwires.md` — behavioral\n  follow-up (Step 5)\n- Per-agent checklists under `skills\u002Fcore\u002Freferences\u002Freview\u002F` (six files;\n  loaded by sub-agents, not by you)\n- The mycelium core `Post-Action Hook Protocol` from `..\u002Fcore\u002FSKILL.md`\n  governs what to log to `.living\u002F` when a review surfaces a recurring\n  pattern\n",{"name":5,"description":7},"main","2c9d7a461b75b93020c274bff2a508697dc05caa","skills\u002Freview",2,"https:\u002F\u002Fgithub.com\u002Farjunrajlaboratory\u002Fmycelium","https:\u002F\u002Fgithub.com\u002Farjunrajlaboratory","https:\u002F\u002Frajlab.seas.upenn.edu\u002F","2026-11-13 02:21:06",{"source":8,"skillName":5,"commands":52,"prompt":62,"zipAvailable":63},[53,56,59],{"tool":54,"command":55},"npx","npx skills add arjunrajlaboratory\u002Fmycelium --skill review",{"tool":57,"command":58},"bunx","bunx skills add arjunrajlaboratory\u002Fmycelium --skill review",{"tool":60,"command":61},"pnpm","pnpm dlx skills add arjunrajlaboratory\u002Fmycelium --skill review","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Farjunrajlaboratory\u002Fmycelium\u002Fblob\u002Fmain\u002Fskills\u002Freview\u002FSKILL.md",true,[65,71,75,79,83,87],{"path":66,"resourceType":67,"resourceTypeDesc":68,"sizeBytes":69,"sourceHtmlUrl":70},"agents\u002Fopenai.yaml","REFERENCE","参考文档",215,"https:\u002F\u002Fgithub.com\u002Farjunrajlaboratory\u002Fmycelium\u002Fblob\u002Fmain\u002Fskills\u002Freview\u002Fagents\u002Fopenai.yaml",{"path":72,"resourceType":67,"resourceTypeDesc":68,"sizeBytes":73,"sourceHtmlUrl":74},"references\u002Fadvanced.md",11628,"https:\u002F\u002Fgithub.com\u002Fendman100\u002Fskill-router-nexus\u002Fblob\u002Fmain\u002FScience\u002Fphysics-quantum-and-simulation\u002Fqutip\u002Freferences\u002Fadvanced.md",{"path":76,"resourceType":67,"resourceTypeDesc":68,"sizeBytes":77,"sourceHtmlUrl":78},"references\u002Fanalysis.md",9387,"https:\u002F\u002Fgithub.com\u002Fendman100\u002Fskill-router-nexus\u002Fblob\u002Fmain\u002FScience\u002Fphysics-quantum-and-simulation\u002Fqutip\u002Freferences\u002Fanalysis.md",{"path":80,"resourceType":67,"resourceTypeDesc":68,"sizeBytes":81,"sourceHtmlUrl":82},"references\u002Fcore_concepts.md",5595,"https:\u002F\u002Fgithub.com\u002Fendman100\u002Fskill-router-nexus\u002Fblob\u002Fmain\u002FScience\u002Fphysics-quantum-and-simulation\u002Fqutip\u002Freferences\u002Fcore_concepts.md",{"path":84,"resourceType":67,"resourceTypeDesc":68,"sizeBytes":85,"sourceHtmlUrl":86},"references\u002Ftime_evolution.md",7866,"https:\u002F\u002Fgithub.com\u002Fendman100\u002Fskill-router-nexus\u002Fblob\u002Fmain\u002FScience\u002Fphysics-quantum-and-simulation\u002Fqutip\u002Freferences\u002Ftime_evolution.md",{"path":88,"resourceType":67,"resourceTypeDesc":68,"sizeBytes":89,"sourceHtmlUrl":90},"references\u002Fvisualization.md",8288,"https:\u002F\u002Fgithub.com\u002Fendman100\u002Fskill-router-nexus\u002Fblob\u002Fmain\u002FScience\u002Fphysics-quantum-and-simulation\u002Fqutip\u002Freferences\u002Fvisualization.md",[92,108,140,162,184,204],{"skillNo":93,"name":94,"nameZh":6,"description":95,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":96,"categories":97,"keywords":98,"publishedAt":38},"01M6CVRE72Z220BXQCRXZT2481","transfer","Cross-pollinate learnings across Science subprojects by scanning recent .living\u002Flearnings.md entries and identifying actionable knowledge transfers. Use when user says \"transfer knowledge\", \"cross-pollinate\", \"sync learnings\", or \"knowledge transfer\".","https:\u002F\u002Fgithub.com\u002Farjunrajlaboratory\u002Fmycelium\u002Fblob\u002Fmain\u002Fskills\u002Ftransfer\u002FSKILL.md",[],[94,99,100,101,102,24,103,104,105,106,107],"sync","science","knowledge","user","scanning","knowledge transfer","learnings","across","entries",{"skillNo":109,"name":110,"nameZh":6,"description":111,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":112,"categories":113,"keywords":124,"publishedAt":38},"01M6CVR761ZN49KWQXV3NG5AGA","report","Create a shareable report — a PDF, or a self-contained HTML report with a companion slide deck — a manuscript section, or a structured writeup from completed Mycelium analyses. Load the project's report templates, provenance, section guidance, and QC checklist. Use when the user wants a document artifact for collaborators or publication. Do not use for conversational explanation, standalone figures, performing analysis, ingestion, setup, or brainstorming.","https:\u002F\u002Fgithub.com\u002Farjunrajlaboratory\u002Fmycelium\u002Fblob\u002Fmain\u002Fskills\u002Freport\u002FSKILL.md",[114,119],{"categoryNo":115,"categoryName":116,"taxonomyType":117,"taxonomyTypeDesc":118},"01JBSEEDCAT000000000000002","文档处理","SCENARIO","使用场景",{"categoryNo":120,"categoryName":121,"taxonomyType":122,"taxonomyTypeDesc":123},"01JBSEEDCAT000000000000034","行政与办公人员","PROFESSION","适用职业",[110,125,126,33,127,128,129,130,28,131,24,132,133,134,135,136,21,137,138,139],"PDF","setup","create","templates","report templates","provenance","html report","deck","ingestion","guidance","checklist","document","artifact","self","mycelium",{"skillNo":141,"name":142,"nameZh":6,"description":143,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":144,"categories":145,"keywords":146,"publishedAt":38},"01M6CVR3VBVQ7GCR6C2WD1BEZS","lifecycle-audit","Run a black-box Mycelium lifecycle smoke test through a real Claude Code or Codex CLI task. Use after plugin installation, hook, SessionStart, PostToolUse, Stop, activity tracking, handoff, or data-lineage changes; when automatic hooks appear not to fire; or before merging cross-host lifecycle work. Verify installed-build identity, natural dispatch, state transitions, positive and negative probes, and scientific-tree isolation. Do not use as a substitute for unit tests or for ordinary scientific analysis.","https:\u002F\u002Fgithub.com\u002Farjunrajlaboratory\u002Fmycelium\u002Fblob\u002Fmain\u002Fskills\u002Flifecycle-audit\u002FSKILL.md",[],[30,147,148,149,150,151,152,153,154,31,155,156,28,157,24,158,159,160,21,161],"lifecycle","lifecycle audit","cli","codex","test","unit tests","codex cli","plugin","state","lineage","work","smoke","hooks","smoke test","task",{"skillNo":163,"name":164,"nameZh":6,"description":165,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":166,"categories":167,"keywords":171,"publishedAt":38},"01M6CVR0XNRWMMXX1N32741VE8","ingest","Add or import files and datasets into a Mycelium project with metadata, provenance, validation, and DATA_MANIFEST updates. Use for collaborator or facility outputs and formats such as CSV, FASTQ, XLSX, TIFF, JSON, FCS, TSV, or images. Do not use for analyzing existing data, listing datasets, deleting data, downloading URLs, or editing code.","https:\u002F\u002Fgithub.com\u002Farjunrajlaboratory\u002Fmycelium\u002Fblob\u002Fmain\u002Fskills\u002Fingest\u002FSKILL.md",[168],{"categoryNo":169,"categoryName":170,"taxonomyType":117,"taxonomyTypeDesc":118},"01JBSEEDCAT000000000000004","电子表格",[164,172,31,173,174,175,176,177,178,130,179,180,24,181,182,183,21,139],"xlsx","validation","metadata","csv","analyzing","data","manifest","json","editing","images","files","datasets",{"skillNo":185,"name":186,"nameZh":6,"description":187,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":188,"categories":189,"keywords":190,"publishedAt":38},"01M6CVQY7YVDS8PW82J1C67XJ3","ideas","Brainstorm research ideas using installed persona and ideation conventions. Use for fresh perspectives, creative angles, new analysis directions, expert viewpoints, \"what are we missing?\", or other open-ended exploration. Do not use for a defined analysis, code fix, project setup, or data ingestion task.","https:\u002F\u002Fgithub.com\u002Farjunrajlaboratory\u002Fmycelium\u002Fblob\u002Fmain\u002Fskills\u002Fideas\u002FSKILL.md",[],[186,191,126,192,177,28,193,194,195,196,197,24,133,198,199,200,201,21,202,203],"research","data ingestion","open","persona","brainstorm","perspectives","fix","ideation","creative","project setup","expert","exploration","conventions",{"skillNo":205,"name":206,"nameZh":6,"description":207,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":208,"categories":209,"keywords":210,"publishedAt":38},"01M6CVQTC883K58NHRMTS3DRF8","harden","Ship one learning's structural_mitigation_candidate as a real test, then mark the learning's mitigation_type structural. Picks a learning in .living\u002Flearnings.md that is still ambient-awareness but names a concrete check, writes the test in the repository's own test setup, proves it fails when the learning's problem is present and passes on the current code, and updates only that entry after the user confirms. Use when the user asks to harden, enforce, or turn a learning, gotcha, or lesson into a test or structural mitigation. Do not use for recording a new learning, promoting learnings to conventions, adding checks inside analysis code, or changing Mycelium itself.","https:\u002F\u002Fgithub.com\u002Farjunrajlaboratory\u002Fmycelium\u002Fblob\u002Fmain\u002Fskills\u002Fharden\u002FSKILL.md",[],[206,151,126,31,211,212,28,213,214,102,24,215,216,21,105,217,218,219,203,139],"repository","awareness","ship","learning","only","test setup","but","lesson","enforce"]