--- name: intake-project description: > Intake and normalize a new radiology research project. Classifies project type, summarizes current state, identifies missing inputs, recommends next steps, and scaffolds lightweight project memory files. triggers: new project, intake project, project intake, classify project, organize project, what is this project tools: Read, Write, Edit, Bash, Grep, Glob model: inherit --- # Intake-Project Skill ## Purpose This skill is the front door for a new or messy project. It converts a folder, document bundle, or mixed set of notes into a structured project state that other skills can use safely. Use this skill when: - a new paper or proposal folder has been created - an older folder exists but is poorly organized - the user asks "what is this project and what should I do next?" - another skill needs a reliable project summary before proceeding --- ## Communication Rules - Communicate with the user in their preferred language. - Keep project labels and file names in the language already used by the workspace. - Use English for manuscript section names, study design names, and medical/statistical terminology. --- ## Inputs Accept any of the following: - a project folder - a manuscript draft - an abstract or proposal - tables/figures plus notes - a mixed folder with PDFs, drafts, and analyses If information is incomplete, infer cautiously from file names and contents, then label uncertain items clearly. --- ## Core Tasks ### 1. Project classification Determine: - project type: `original | review | meta-analysis | case report | technical note | grant | peer review | challenge | career-doc` - primary domain: `radiology | medical AI | multimodal LLM | intervention | survival/prognostic | diagnostic accuracy | workflow` - target output: `paper | abstract | grant | review | rebuttal | CV` - likely target journal or venue, if recoverable ### 2. State reconstruction Identify: - what already exists - what is missing - current phase - blocking dependencies ### 3. Project memory scaffold If missing, propose or create lightweight anchor files: - `PROJECT.md` - `STATUS.md` - `CLAIMS.md` - `DATA_DICTIONARY.md` - `ANALYSIS_PLAN.md` - `REVIEW_LOG.md` Create only files that are justified by the project type. ### 4. Action plan Produce the next 3-5 actions in dependency order. --- ## Canonical Manuscript Folder Structure For any manuscript project (cohort, MA, RCT, case series), enforce this structure when scaffolding or reorganizing. Map every new artifact into one of these slots — do not invent ad-hoc folders. ``` {project_root}/ ├── HANDOFF.md # session handoff entry point ├── README.md # project overview ├── data/ # raw data (NEVER edit; read-only) ├── analysis/ # reproducible scripts (00_* → 04_*) ├── output/ # analysis outputs: CSVs, PNGs, intermediates ├── irb/ # IRB/ethics docs ├── proposal/ # original protocol / approved proposal ├── reviews/ # external correspondence ├── manuscript/ # SOURCE manuscript + drafting │ ├── manuscript_v{N}.{md,docx,pdf} # current canonical working version (top level) │ ├── build_unified_docx.py # or pandoc wrapper │ ├── archive/ # ALL prior versions v1 .. v{N-1} │ ├── reviews/ # QC: self_review, peer_review, STROBE/PRISMA, critic │ ├── figures/ # figure scripts + rendered PNG/PDF │ └── tables/ # table scripts + rendered docx └── submission/ # per-journal packages └── {journal-slug}/ # e.g., chest/, kjr/ ├── CHECKLIST.md ├── cover_letter.{md,docx,pdf} ├── title_page.docx # separated for double-anonymized ├── manuscript_anonymized.{docx,pdf} ├── supplement.{docx,pdf} ├── strobe_checklist.md # or PRISMA / CONSORT ├── circulation_email.md └── figures/ # submission-ready DPI copies ``` ### Rules - **`manuscript/` = source; `submission/{journal}/` = derived artifacts.** Regenerate submission files from `manuscript/manuscript_v{N}.md`; never edit anonymized/title-page directly. - **One canonical working version** at `manuscript/manuscript_v{N}.{md,docx,pdf}`. Older versions move to `manuscript/archive/` immediately on version bump. - **No loose files at project root.** Only `HANDOFF.md`, `README.md`, folder entries. - **QC artifacts** (self_review, peer_review, STROBE, critic reports) live in `manuscript/reviews/`, not at manuscript top level. - **On rejection/retarget:** `cp -r submission/{old} submission/{new}`, then rewrite cover letter and reformat. - **Double-anonymized journals** (Chest, AJRCCM): title page and anonymized manuscript MUST be separate files under `submission/{journal}/`. ### When to apply - At project intake: scaffold empty structure. - At first submission prep: create `submission/{journal}/` and populate. - Mid-project cleanup: when `manuscript/` has >3 versioned files or QC docs at top level, reorganize. - Before session handoff: reorganize if structure is drifting. **Precedent:** CK-5 Emphysema → Mortality (2026-04-20) reorganized v1–v6 + QC docs from manuscript/ top level so reject-retarget path to KJR requires only `cp -r submission/chest submission/kjr`. --- ## Workflow ### Phase 1: Discover context 1. Read top-level folder names and key files. 2. Detect manuscript-like files, tables, figures, protocols, and analysis outputs. 3. Extract: - project title or working title - study question - dataset or cohort hints - collaborators or institutions - venue/journal hints ### Phase 2: Classify project stage Assign one current stage: - `idea` - `data assembly` - `analysis planning` - `analysis in progress` - `drafting` - `revision` - `submission prep` - `archived/unclear` **Gate:** Present the classification (project type, stage, target output) to the user. Confirm before creating any files — misclassification leads to wrong scaffold and wrong skill routing. ### Phase 3: Surface missing inputs Check for common gaps: - no explicit study question - no target journal - no analysis plan - no variable dictionary - no claims-to-results map - no review log for revised manuscripts ### Phase 4: Produce normalized summary Output this structure: ```text ## Project Intake Summary Project: ... Type: ... Current stage: ... Likely target: ... ### What exists - ... ### What is missing - ... ### Risks / ambiguities - ... ### Recommended next actions 1. ... 2. ... 3. ... ``` --- ## Optional File Templates ### `PROJECT.md` ```md # PROJECT - Title: - Type: - Primary question: - Target journal/venue: - Lead folder: - Collaborators: - Last updated: ``` ### `STATUS.md` ```md # STATUS - Current stage: - Current blocker: - Next actions: 1. 2. 3. - Last updated: ``` --- ## Guardrails - Do not invent data values, outcomes, or collaborator roles. - Do not assume a target journal unless evidence exists in the files. - Do not create a large folder scaffold when the user only wants a quick assessment. - If a project appears to mix multiple studies, say so explicitly rather than collapsing them into one. --- ## Handoff Rules After intake: - route to `search-lit` if the literature basis is weak - route to `design-study` if the research question exists but design logic is unclear - route to `manage-project` if the folder should be scaffolded - route to `write-paper` only after the project phase is clearly `drafting` --- ## What This Skill Does NOT Do - It does not write full manuscript sections - It does not perform statistical analysis - It does not verify citations deeply - It does not replace study design review ## Anti-Hallucination - **Never fabricate file paths, URLs, DOIs, or package names.** Verify existence before recommending. - **Never invent journal metadata, impact factors, or submission policies** without verification at the journal's website. - If a tool, package, or resource does not exist or you are unsure, say so explicitly rather than guessing.