New Research Project

New Research Project

Scaffold a new genealogy research project as a set of Charted Roots (CR) notes, not as a duplicated folder of standalone files. This exists because Steve Little's original Genealogy AI Starter Workspace expects each project to carry its own copy of AGENTS.md, a source register, research logs, and templates. In a Charted Roots vault, almost all of that is already handled by shared, vault-wide structure — duplicating it per project would just create drift between projects and make vault-wide search (Bases views) incomplete. This skill creates only what's genuinely new per project: the project's own identity and its links into the shared system.

Before creating anything

Read Templates/GRA/README.md in the vault if it exists — it documents the exact design this skill implements (why there's no per-project AGENTS.md, where sources live, how project tagging works). If that file is missing, this vault may not be set up for this workflow yet; tell the user and offer to set up Templates/GRA/ first (research-project templates, a shared Research/ folder, and a projects property on the Source templates) before scaffolding a project into it.

Step 1: Get the research question and subject

Never scaffold a project without a specific, focused research question. A project titled after a person with no question ("research John Smith") is not useful — GPS-aligned research answers one thing at a time (identity, relationship, event, place, or activity). If the user hasn't given a specific question yet, ask for it before proceeding: "What's the one specific thing you want to find out about ?"

Also check whether a People/ note for the subject already exists in the vault (search by name). If it does, read its frontmatter — it's often a GEDCOM import with useful (but uncited) facts worth carrying into the new project's identity profile. If multiple people share the name and a similar birth year, flag this explicitly rather than guessing which one the user means — same-name disambiguation is a real methodological hazard here, not a minor detail. Present the candidates and ask, or if the user's phrasing already disambiguates (e.g. "b. 1760" vs. another with a different date), proceed but still note the other candidate(s) as a related, unresolved question inside the new project note rather than silently ignoring them.

Step 2: Create the project's index note

Create Research/<Descriptive Name> - Research Project.md — flat, in the shared Research/ folder, the same way Sources/, Places/, Events/, and People/ are all flat with no per-item subfolder. There is no Projects/ folder in this design; don't create one. Use a disambiguating name if more than one person shares the subject's name in the vault (e.g. John Patterson (b. 1760) rather than bare John Patterson).

Base the note on Templates/GRA/Research Project.md, but don't just copy the Templater placeholders verbatim — fill them in for real:

• subject: wikilink to the People/ note if one exists, otherwise leave as a plain name pending a Person note.
• status: open for a brand-new project.
• research_level: 1 if nothing is known yet, 2 if the vault already has some uncited facts (typical for GEDCOM-imported people), higher only if real sourced research already exists.
• related: wikilinks to any same-name candidates flagged in Step 1.
• Fill in Research question, Known facts (pulled from the existing People/ note if any, each row noting it's uncited if it is), Scope and search plan (suggest record types sized to the question's complexity — see the gra skill's GPS application guidance for how to size "simple" vs. "moderate" vs. "complex" research), and Answer standard.
• Leave the embedded ![[Charted Roots/Bases/research.base#By Project]] and ![[Charted Roots/Bases/sources.base#By Project]] embeds in place — they're how this project's linked research and sources surface without copying any of those notes onto the index note itself.

Step 3: Seed an Individual Research Note

Create Research/<Subject> - Identity Profile.md from Templates/GRA/ Individual Research Note.md, with project: linking back to the new project note. Populate the identity profile table from the existing People/ note's frontmatter if one exists (names, dates, places, relationships) — mark every row as needing a citation unless one already exists in Sources/. Note any same-name disambiguation issue from Step 1 here too, in its own section, so it isn't lost.

Do not populate the "Name and place variants" or "FAN cluster" tables with invented entries just to fill space — a couple of well-reasoned starting variants (period spelling conventions, common abbreviations) are useful; a table padded with guesses is not.

Step 4: Do not fabricate research activity

This is the most important rule in this skill. Steps 1-3 create the scaffolding for a project — they do not perform research. Do not create a Research Log Entry or Research Journal note describing a search that didn't happen. It's fine (and honest) to create a Research Journal entry documenting the scaffolding session itself ("today we set up the project and identified an open disambiguation question"), because that genuinely happened. It is not fine to invent a plausible-sounding search log entry to make the project look further along than it is.

Step 5: Report back

Tell the user what was created (paths), summarize the research question and any disambiguation issue found, and suggest the first concrete next step (usually: the first record type worth searching, per the scope and search plan). Offer to open the gra or family-history-planning skill if the user wants to move directly into analysis or a research plan.

Reference

For the full rationale behind this project structure (why sources aren't duplicated, why there's no per-project AGENTS.md, how CR's cr_type entity types map to the original Genealogy AI Starter Workspace's files), see Templates/GRA/README.md in the vault.