medical-imaging-review

What the source does

• FilesystemDeclared1 observation
• NetworkNone observedNo outbound calls in the source
• ShellNone observedNo commands run in the source
• DependenciesPinnedNothing floats
• SecretsNone foundNo keys in source

Five audit layers

Gates applied: no behavioural pass.

Audit 0.4.1 · source sha d77a3a8c44da · 20 Oct 2026Report an issue or request a re-scan

• Publisherluwill GitHub userOwner of the repository this skill is read from
• Source folderluwill/research-skills/medical-imaging-reviewThe exact folder we audited
• LicenceNot declaredAs the repository states it
• Commit pinned for this verdictd77a3a8c44daA new audit runs when the source changes
• Repository statusNot archivedLast push 10 days ago
• Sandboxed runNot runSkills are read, not executed; layer L4 is skipped

Its description: Use when the user asks to plan, conduct, document, synthesize, or draft a medical imaging AI narrative review or method survey, scoping review, or systematic review with qualitative synthesis, including protocol design,…

---
name: medical-imaging-review
description: Use when the user asks to plan, conduct, document, synthesize, or draft a medical imaging AI narrative review or method survey, scoping review, or systematic review with qualitative synthesis, including protocol design, literature search, screening, extraction, risk-of-bias appraisal, or evidence synthesis. Do not use this skill to perform a meta-analysis or umbrella review; stop and tell the user these need a specialized evidence-synthesis workflow this environment does not provide.
---

# Medical Imaging AI Review

Build traceable review artifacts whose claims can be audited back to first sources. Report the actual project state and unresolved human gates. Do not promise editorial outcomes or describe an incomplete project as a completed review.

## Scope and hard boundary

Support exactly four route tokens across three methodological families:

| User intent | Route token | Route |
|---|---|---|
| Interpret a field | narrative | Narrative review |
| Compare method families | method-survey | Method survey |
| Map available evidence and research gaps | scoping | Scoping review |
| Answer a focused question without statistical pooling | systematic | Systematic review with qualitative synthesis |

Do not perform a meta-analysis, network meta-analysis, individual-participant-data meta-analysis, or umbrella review with this skill. If the request requires pooled estimates, heterogeneity statistics, forest or funnel plots, review-overlap analysis, or review-level appraisal, stop and tell the user plainly that these need a specialized evidence-synthesis methods workflow which this environment does not provide — do not name a workflow you cannot see, and do not approximate those methods with prose or simple averaging. Do not approximate those methods with prose or simple averaging.

**Corpus hand-off with lit-search.** The retrieval half of any route (exhaustive,
recall-evidenced searching) belongs to the **lit-search** skill: run it first, then consume
its `dois.md` / `references.md` (and `references.bib` with `--bibtex`) as the candidate
pool. Copy the imported records into this project's `search/exports/` as an immutable
export (never edit in place), record the lit-search run id and its PRISMA counts in
`search/search_log.md`, and let this skill's human screening gates take over from that
pool — this skill plans and writes the review; it does not re-run the retrieval.

Read [references/REVIEW_TYPES.md](references/REVIEW_TYPES.md) before collecting literature or drafting. Use only narrative, method-survey, scoping, or systematic as route tokens; systematic always means qualitative synthesis in this skill. Before evidence collection begins, a corrected route may be recorded with an explicit decision note. After collection begins, the project route is immutable: freeze the old project and initialize a new project for a different route, carrying forward only logged, provenance-preserving artifacts.

## Intake gate

Before starting a multi-step review, confirm and record:

1. Review route and research question.
2. Population, modality, anatomy, task, setting, and outcomes or concepts in scope.
3. Target journal or audience and any binding instructions.
4. Search date range, language limits, databases, grey-literature policy, and evidence cutoff.
5. Expected deliverable and current project stage.
6. Named human roles for screening, extraction or charting, adjudication, risk-of-bias assessment, and certainty assessment when applicable.
7. Planned AI assistance and disclosure.

For scoping and systematic routes, read [references/REPORTING_STANDARDS.md](references/REPORTING_STANDARDS.md) before protocol or search design. If a required decision is missing, continue only with clearly labeled planning options; do not silently choose a consequential protocol rule.

## Project contract

Initialize every new multi-step project with the bundled script:

    python3 <skill_dir>/scripts/init_review_project.py --parent <workspace-root> --name <topic-slug> --route <narrative|method-survey|scoping|systematic>

Use a lowercase kebab-case topic slug. The initializer prints the newly created project path:

    review_project/<topic-slug>-<YYYYMMDD-HHMMSS>-<8hex>/

Treat that printed path as <project_dir> for the rest of the workflow. The initializer refuses an existing target and never writes into another project directory. Do not pre-create, reuse, rename, or flatten the generated child. When resuming work, select the exact existing <project_dir> instead of running initialization again.

Core generated artifacts include:

    <project_dir>/
    ├── review_config.yaml
    ├── REVIEW_CONTEXT.md
    ├── IMPLEMENTATION_PLAN.md
    ├── PARADIGM.md
    ├── manuscript.md
    ├── references.bib
    ├── claim_ledger.csv
    ├── AI_USE_DISCLOSURE.md
    └── route-specific subdirectories

Use REVIEW_CONTEXT.md as the portable project brief and review_config.yaml as the source of truth for route, scope, standards, human roles, AI use, evidence cutoff, and status. Re-read both at the start of each work session. Do not depend on a tool-specific instruction filename.

Before changing an artifact, inspect <project_dir>. Never overwrite, truncate, reset, or replace existing content. Preserve unrelated content and apply a narrow patch or merge. Ask before resolving a material conflict. A bounded advisory answer can remain inline; do not initialize a project unless the task needs persistent artifacts.

When a first-stage plan requires persistent artifacts, the response must explicitly show the initializer command that was run, the collision-safe <project_dir> printed by the initializer, and the current project status; do not imply that a project exists before the initializer succeeds.

## Stable citations and claim ledger

Use stable citekeys during research and drafting, for example [@smith2024model]. Keep `references.bib` as the project bibliography used for drafting and rendering. Pre

Excerpt, first 6,000 characters of SKILL.md, verbatim from the audited commit. It is text from someone else’s repository, quoted so you can judge it before your agent reads it.

1. 2026-10-20
   ✓SAFE B 89 / 100

   first audit · source d77a3a8c44da

Questions about medical-imaging-review

• github.com/luwill/research-skills/tree/main/medical-imaging-revi — the audited source at commit d77a3a8c44da and every finding aboveObserved · 20 Oct 2026

Spotted something wrong? Report a correction · Methodology