# New Research Project > Scaffold a new genealogical research project inside an Obsidian vault that uses Charted Roots (CR). Creates a Research Project index note plus a seeded Individual Research Note, both flat in the vault's shared Research folder (no per-project subfolder), using CR's cr_type frontmatter so the project shows up in existing Bases views immediately. Use this whenever the user wants to "start a new research project," "research a new ancestor," "open a case file on" someone, or names a specific ancestor plus an open question (parentage, origin, identity, a conflicting record, immigration, etc.) with no existing project for them yet. Also use it for "help me dig into who X's parents were" when no project for X exists. Do not use for editing an existing project, creating a plain Person/Source/Event note (those have their own CR templates), or vaults that don't use Charted Roots. - Skill: `emaynard/new-research-project` (Agent Skill, multi-file: 4 files) - Install (CLI): `npx skillmds@latest add emaynard/new-research-project` - Raw SKILL.md: https://api.skillmd.com/api/skills/emaynard/new-research-project/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Research & Search - License: CC-BY-NC-SA-4.0 - Author: emaynard (https://skillmd.com/u/emaynard) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/emaynard/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/ - 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/ - 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.