Skill detail
medical-imaging-review
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…
Why we recommend it: Medical imaging AI review methodology, adjacent to clinical research synthesis.
Inspect before use
Read the source instructions and check the requirements before you install this skill.
SKILL.md
The saved excerpt is a snapshot from when this skill was listed. The external source remains the complete and most current version.
---
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; route those requests to a specialized evidence-synthesis methods workflow.
---
# 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 prepare a handoff to a specialized methods workflow. Do not approximate those methods with prose or simple averaging.
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
Read the full source on GitHub (opens external page)