make-project

Save this page and point your AI at it (for example, if you use Cursor, put it under ~/.cursor/skills/make-project/SKILL.md).

What. Help set up or clean a research project folder that is safe for an AI to access, with memos for onboarding, a GitHub stub for analysis and writing, and optionally an Overleaf stub for TeX coauthoring.

When. Starting or auditing a paper/project folder. Related: analysis-skill for analysis.qmd; write-like-mac for prose; review-my-paper for manuscript review (findings can go in memos/review.md once a review exists).

Posture (read first)

This skill is mostly feedback and options, not silent scaffolding.

1. Ask questions before doing anything. Gather intent before inspecting or changing files.
2. Prefer findings → options → approval over creating or moving folders.
3. Do not jump straight into creating directories, rewriting trees, or mass moves.
4. Wait for explicit user approval before any file-system changes (mkdir, move, delete, overwrite).

Workflow

If the user already answered intent and path in the same message, do not re-ask those points—still propose before changing the filesystem unless they clearly said go ahead and create/apply.

Map of this file

Mode

Clarify make vs check up front (ask if unclear).

Project stem

The project stem is a short, filesystem-safe identifier for the project. Use it consistently in folder and .Rproj names. Project identity for analysis is the folder name; the working notebook is always analysis.qmd (no stem inside that filename).

Example: a TikTok project has stem tiktok (same as the project name in that case).

Ask for the stem early if it is not obvious from the folder name. Prefer one stem everywhere rather than mixing nicknames.

Structure

Canonical layout. Names are filesystem-safe. Human-readable titles noted where they differ.

project_name/                         # AI-accessible project root (often = stem)
├── memos/
│   ├── onboarding.md                 # get an AI up to speed
│   ├── notes_for_coauthors.md        # title: "notes for coauthors"
│   ├── to_do.md
│   └── review.md                     # after a review has been conducted
├── project_stub_gh/                  # GitHub repo: analysis + writing
│   ├── archive/
│   ├── lib/                          # papers / library PDFs as used
│   ├── code/                         # extra scripts (not the main analysis spine)
│   ├── assets/                       # stable inputs: bib.bib, images/, fixed compile inputs
│   ├── outputs/                      # tables, figures, objects produced when code is rerun
│   ├── saved/                        # intermediate saved rds or similar (optional companion to outputs/)
│   ├── overlay/                      # optional; role TBD — ask before inventing contents
│   ├── <stem>.Rproj
│   ├── paper.qmd
│   ├── analysis.qmd                  # aligned with analysis-skill
│   ├── presentation.qmd              # revealjs
│   └── README.md                     # includes path to data (outside this tree)
└── project_stub_overleaf/            # Overleaf / TeX coauthoring stub (optional)
    ├── paper.tex
    ├── appendix.tex
    ├── assets/                       # stable inputs synced from gh assets/ (e.g. bib)
    │   └── bib.bib
    └── figs_tabs/                    # figures/tables synced from gh outputs/

The GitHub stub folder may use the repo name instead of the literal project_stub_gh. The Overleaf stub may use <stem>_overleaf instead of project_stub_overleaf. Internal layout matters more than the literal folder name; keep stem-based naming consistent when you choose a variant.

Not in this tree: respondent-level data, credentials, restricted IRB materials, or other confidential files. Record their path in README.md.

File roles

Memos (memos/)

GitHub stub

Overleaf stub (project_stub_overleaf/)

Flow (do not invert):

1. Analysis writes regenerated tables/figures to gh outputs/.
2. Stable inputs live in gh assets/.
3. Sync gh outputs/ → Overleaf figs_tabs/; sync needed gh assets/ (e.g. bib) → Overleaf assets/.
4. Overleaf figs_tabs/ and assets/ are not where analysis writes; they are compile/sync destinations.

outputs/ vs assets/ in the GitHub stub (do not blur)

Same distinction as in analysis-skill. On Overleaf, regenerated products land in figs_tabs/; stable inputs in assets/.

Security and confidentiality

1. Data and sensitive material must not be available to the AI. Keep them elsewhere; put the path in README.md.
2. Do not copy microdata, identifiers, credentials, or restricted documents into the AI-accessible root or into chat.
3. If confidential material may already be in the workspace, alert the user and do not dig into those files unless explicitly authorized for a local, non-uploading task.
4. Never upload project data or manuscripts to an external model without permission.

Layout rules

• Deep rather than wide. Few files per folder; nested by job.
• Only one current copy of each key document. No paper_final.qmd beside paper.qmd.
• Archive older versions as YYYYMMDD_name.xxx under archive/.
• Live file = plain name; history only in archive/.

Archiving and paths (here::)

When moving a live file into archive/ (or relocating folders), paths must still work from the new location.

• Prefer the R here package: resolve project-root-relative paths with here::here(...) (and Quarto/R scripts that call here) so roots stay valid after moves.
• Avoid hard-coded absolute paths and fragile ../ chains that break when a file’s depth changes.
• After an archive or restructure, check that data paths in README.md, analysis housekeeping, and any TeX \input / figure paths still resolve.
• When proposing archive/cleanup options, call out path risk and favor here::-based roots in the recommended fix.

Make (propose, then wait)

After questions, propose—do not create yet—something like:

1. AI-accessible root name, project stem, and parent path; confirmation that data stay outside.
2. memos/ with the four starter files (thin placeholders only).
3. GitHub stub folders, including clear outputs/ vs assets/.
4. Thin stubs: <stem>.Rproj, paper.qmd, analysis.qmd (pointer or spine from analysis-skill), presentation.qmd, README.md with a Data path placeholder outside the tree.
5. Optional: Overleaf stub (paper.tex, appendix.tex, assets/bib.bib, figs_tabs/) and whether to include overlay/ (only if the user knows what it is for) and saved/.
6. Path convention: prefer here:: for R/Quarto roots so later archives do not break relative paths.

Present as options when more than one layout is reasonable (e.g. stub folder name, whether to add Overleaf, whether to migrate an existing mess). Create files only after the user approves an option.

Do not invent results, citations, or fake project history.

Check (report, then propose)

Inspect against the standard. Return findings and cleanup options. Restructure only after approval.

Checklist

• AI-accessible root vs data location; README records external data path
• Project stem clear and used consistently (.Rproj, stub names if stem-based); analysis file is plain analysis.qmd
• No apparent confidential/microdata/secrets in the AI tree (if suspected: alert)
• memos/ with onboarding.md, notes_for_coauthors.md, to_do.md (and review.md if a review exists)
• Stub has paper.qmd, analysis.qmd, presentation.qmd, <stem>.Rproj, README
• outputs/ used for rerun products; assets/ for stable inputs (flag swaps or dumps in the wrong place)
• If Overleaf stub present: paper.tex, appendix.tex, assets/, figs_tabs/; TeX figs/tabs from figs_tabs/; sync from gh outputs/ → figs_tabs/ and gh assets/ → Overleaf assets/; neither is the analysis write target
• Expected folders present as needed: archive/, lib/, code/, assets/, outputs/, saved/
• Deep rather than flat; one current copy of each key document; dated archives
• Paths robust under archive/move (favor here::); no broken relative roots after past moves
• analysis.qmd compatible with analysis-skill (or gaps noted)

Report format

# Project check: [path]

**Mode:** check (advice)
**Overall:** fits / mostly fits / does not fit

## Alerts
[Confidential or data-in-workspace concerns, or None.]

## Findings
- ...

## Options
1. [Minimal cleanup] …
2. [Full align to standard] …
3. [Leave as-is / defer] …

## What already looks right
- ...

Wait for the user to choose an option before applying file-system changes.

Do not

• Create, move, or delete project folders/files before the user approves
• Place or request data inside the AI-accessible project root
• Put regenerated tables/figures in gh assets/ (use gh outputs/)
• Treat Overleaf figs_tabs/ or assets/ as the analysis write target (they are sync/compile sinks)
• Create multiple live versions of the same paper or analysis file
• Invent substantive paper content when scaffolding
• Quietly ignore suspected confidential material—alert the user
• Archive or move files in ways that break relative paths without fixing roots (here::)