--- name: initialize-analysis description: Initialize or organize a new or existing R statistical or epidemiologic analysis project, including a latest RMD, partial scripts, project instructions, AGENTS.md, Quarto setup, references and gitignore. Use for resuming unfinished initialization too. --- If the linked plugin files cannot be opened, say so and continue from the repository's own AGENTS.md and analysis plan; do not guess their contents. Read [shared conventions](references/conventions.md). Use the [blueprint](references/REPOSITORY-BLUEPRINT.md), [analysis-plan guidance](references/analysis-plan.md), [initialization questions](references/initialization.md), [guidance templates](assets/AGENTS.md) and [personal instructions](assets/project-instructions.md). For website work read [Quarto setup](references/quarto.md); for data boundaries and ignore rules read [data handling](references/data-handling.md). The starter templates (`_quarto.yml`, `README.Rmd`, `quarto/`, `R/`, `gitignore.template`) are in [assets/starter](assets/starter/). 1. Inspect accessible project instructions, AGENTS.md (including applicable nested guidance), README and available source metadata. Establish which copy is current. Accept the user's designation of the latest RMD; do not demand a version-history investigation. Do not open possible restricted data as part of inventory. 2. If the project has no repository yet, suggest creating it before drafting anything: whoever is setting up can create it under their own account, and ownership can move later (see leaving a project in [onboarding](references/onboarding.md)). If the repository has to wait (for example, someone else will create it), keep drafts as files in the person's own LLM project for the repository, not only in the chat, and move them in once it exists. Then conduct the initialization questionnaire. Reuse supplied answers, ask one useful question at a time, and invite pertinent IRB/protocol, prior scripts, analysis plans, data documentation, papers and earlier results. Do not force uploads or repeat answered questions. File access does not imply publication permission. Adapt length and presentation through experience. 3. Establish personal assistance and authorization separately from shared project rules. A clinician can help with the protocol without installing R or Git. Read [collaborator onboarding](references/onboarding.md) when needed. Do not carry one person's working style or permissions into anyone else's instructions or the shared files. 4. Identify active, exploratory, superseded and uncertain material. Trace dependencies before moves. Extract useful rationale from mixed RMDs; preserve originals and provenance. Archive only within authorized scope; never assume old means disposable. Existing organization and theme choices survive unless change is requested. 5. Explicitly adapt the [sample .gitignore](assets/starter/gitignore.template), saving it as .gitignore in the target project. Ignore or track `figures/` and `tables/` according to the questionnaire answer on review before release. Never ignore `docs/`. The visible template is provided for hosts that hide dotfiles. Inspect tracked-path metadata and ignore behavior, including outputs and archives. Report tracked sensitive candidates without opening them. Ignore patterns do not remove history or restrict agent access. Choose narrowly scoped exceptions for approved public/synthetic data. 6. Produce a concrete concise setup plan: retained sources, proposed files/moves/archive paths, guidance gaps, data boundaries, references suggestions, output tracking and remaining decisions. Execute work already authorized; ask only for missing decisions or authorization, not repeated approval. Do not automatically install tools, publish, or make external Git writes. Include protecting the default branch, following [GitHub workflow](references/github-workflow.md), as a step for the maintainer. If the person setting up works in R, suggest the next step from [setting up from R](references/github-workflow.md#setting-up-from-r) based on `usethis::git_sitrep()`, one step at a time. When the first pull request containing `docs/` is merged, remind the person setting up that someone with admin or maintainer permission must turn on GitHub Pages (see publishing the website in [GitHub workflow](references/github-workflow.md#publishing-the-website)), or the site will not go live. 7. Draft or reconcile analysis-plan.md from the variant that fits the design, drafting a decision issue for each unresolved choice rather than choosing, and citing references.bib for sourced decisions. Create README.Rmd from the starter (badges, goal, website link, documentation links, how to run) and knit README.md, unless the person prefers a plain README.md. Where there is a README.Rmd, edit only it afterwards. Adapt AGENTS.md to shared rules and study-specific references. Its "Data sources" table lists every source the analysis uses, one row each, with the package that accesses it, that package's documentation, whether this team maintains it, and the access restriction; fill it as described in [data sources](references/data-sources.md). Do not copy facts about a source into AGENTS.md when they belong in its package documentation. Suggest that each person who works on the repository with an AI assistant creates their own LLM project for this repository, and prepare their personal project-instruction text from the template for that project's instructions, asking which working style they want as a starting point; this is an offer, not a requirement. Ask whether the project wants milestones with target dates; if so, set them up as in [GitHub workflow](references/github-workflow.md#milestones-optional) with the phases and dates the team gives. Also ask whether they want a periodic check-in, as described in [onboarding](references/onboarding.md). Do not claim those settings changed without a capable tool and verified update. Read skill references already present there and invoke relevant available skills. Help add references where absent; do not replace existing routing with a duplicated catalogue. 8. Record non-sensitive setup decisions and pending items in one agreed project setup note or existing tracker. Keep private personal permissions outside shared/public files. Resume from these records and conversation; never restart intake unnecessarily. Report exact completed work and untested capabilities.