agentleFS
hsigstadhsigstad/research-kit/skills/new-project/SKILL.md

new-project

Skill0 starsChanged 4 months agoMITView on GitHub

Scaffold a new research project from materials the user has placed in a folder under projects/. Reads existing files to extract context instead of asking questions. Use when the user wants to create a new research project.

51 other projects use a version of this.

Adopted by

Most recently taken up by

Used with

Projects with it also use checkpoint, prd and 9 more.

Other files people use alongside this one.

Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
  • genomewalkerSkill

    checkpoint

    Save a checkpoint of task status, decisions, active files, and next steps

    Also in 3 projects that use this

  • GitHubSkill

    prd

    Generate high-quality Product Requirements Documents (PRDs) for software systems and AI-powered features. Includes executive summaries, user stories, technical specifications, and risk analysis.

    Also in 3 projects that use this

  • sunnyclinches44Skill

    explain

    Explains code using real-world analogies and ASCII diagrams

    Also in 3 projects that use this

  • SentrySkill

    spec

    Produce a verified spec — problem, desired outcome, and acceptance criteria — before building. Use when given a GitHub/Linear issue link, when starting from a fuzzy in-conversation idea, or asked to "figure out what to do" / "scope this" / "what should I build" — whenever the *what* isn't yet pinned down. Grills the ambiguities, checks the premise against the code, and produces acceptance criteria you sign off on — then hands to design-first.

    Also in 3 projects that use this

  • GoogleSkill

    domain-modeling

    Build and sharpen a project's domain model. Use when the user wants to pin down domain terminology or a ubiquitous language, record an architectural decision, or when another skill needs to maintain the domain model.

    Also in 4 projects that use this

  • SentrySkill

    review

    Fixture review skill.

    Also in 5 projects that use this

  • +1 more from getsentry

The file

We split this skill into the rules it gives an agent

12 rules. 0 are common, 4 are distinctive, and 8 are very specific to this project.

  • 0

    Common

    Most of the 48 edited versions we read keep these.

  • 4

    Distinctive

    This author's own choices. Worth a look.

  • 8

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Very specific:

    Follow the canonical structure from $ROOT/research-kit/rules/project_docs_contract.md.

    line 39
  2. Very specific:

    Follow the pattern of existing projects (see any $ROOT/projects/*/CLAUDE.md for examples):

    line 78
  3. Very specific:

    Add domain-specific WebFetch permissions if the materials mention specific data sources or websites.

    line 110
  4. Distinctive:

    After scaffolding, the user's original files are still in the project folder.

    line 152
  5. Distinctive:

    Leave them where they are

    line 154
  6. Distinctive:

    Delete them (now that their content has been absorbed into docs/)

    line 155
  7. Very specific:

    Check $ROOT/research/rules/workspace.md — note the new project in the projects/ listing if the user wants to update it.

    line 159
  8. Very specific:

    Check $ROOT/research/meta/research_map.md — suggest where it fits in the project clusters.

    line 160
  9. Very specific:

    If the project originated from an idea in $ROOT/ideas/, update the idea's frontmatter (status: project, related_project: …

    line 161
  10. Very specific:

    Do NOT create talk/ or references/ directories unless requested.

    line 182
  11. Distinctive:

    Always use today's date (from system context) for created dates.

    line 184
  12. Very specific:

    Check $ROOT/research/meta/variable_dictionary.md and $ROOT/research/meta/data_linkages.md before populating data.md — the dataset may …

    line 185

“Common” is measured: kept by at least 6 in 10 of the 48 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Scaffold a new research project

You are creating a new research project repository under projects/.

Finding the workspace root

The workspace root contains CLAUDE.md alongside projects/, pipelines/, $ROOT/data_catalog/, research/. If the current directory is inside a project or pipeline, search upward to find the root. Use $ROOT for all paths below.

Step 1: Identify the project folder and read existing materials

The user has already created a folder under projects/<slug>/ and may have placed materials in it (PDFs, notes, descriptions, data files, drafts, etc.).

  1. Infer the slug from the folder name. If the skill was invoked with an argument, use that as the slug. Otherwise, look for recently created folders under projects/ that lack the canonical structure (no docs/ directory).
  2. Read every file in the project folder. These are the user's seed materials — project descriptions, research proposals, paper drafts, notes, data documentation, etc.
  3. Extract context from these materials:
    • Research question and motivation
    • Current focus / what to work on first
    • Methods and identification strategy
    • Data sources
    • Relevant literature
    • Institutional background
    • Any other information that maps to the docs/ files
  4. Check workspace context for connections:
    • $ROOT/research/meta/data_linkages.md and $ROOT/data_catalog/ for existing datasets
    • $ROOT/research/meta/variable_dictionary.md for known variables
    • $ROOT/research/meta/research_map.md for related projects
    • $ROOT/ideas/ for an idea entry that originated this project

Only ask questions if critical information cannot be inferred from the materials and workspace context. If you do need to ask, ask at most one or two targeted questions — not a full interview.

Step 2: Create the directory structure

Follow the canonical structure from $ROOT/research-kit/rules/project_docs_contract.md. Do not overwrite any files the user already placed in the folder. Create only what is missing.

$ROOT/projects/<slug>/
  README.md
  CLAUDE.md
  .claude/
    settings.local.json
  docs/
    summary.md
    thinking.md
    todo.md
    done.md
    meetings.md
    feedback.md
    literature.md
    institutions.md
    data.md
    methods.md
    decisions.md
    findings/
      index.md     # folder-mode findings — the default per project_docs_contract.md §864
  source/
  build/
    .gitkeep
  paper/
    tables/
    figures/
    references.bib
  talk/          # create only if user requests
  references/    # create only if user requests

Step 3: Populate files

Populate docs/ files using context extracted from the user's materials. The more the user provided, the richer the initial documentation should be. Files for which no relevant information was found get their header and empty template sections only.

CLAUDE.md

Follow the pattern of existing projects (see any $ROOT/projects/*/CLAUDE.md for examples):

# <slug>

Read `docs/summary.md` and `docs/todo.md` (if available) before making changes.

**Current focus:** <inferred from materials>

**Identification:** <inferred from materials, or omit if unknown>

**Shared code:** Use `diarios` for court parsing and cleaning. Do not modify `diarios` without asking.

**Data policy:** Never read raw data files. Dataset metadata is in `../../data_catalog/`.

Adapt sections based on what the materials actually contain. Don't include sections that have no content.

.claude/settings.local.json

{
  "permissions": {
    "allow": [
      "Bash(python3:*)",
      "Bash(git add:*)",
      "Bash(git commit:*)"
    ]
  }
}

Add domain-specific WebFetch permissions if the materials mention specific data sources or websites.

docs/summary.md

Populate with research question, motivation, and conceptual framework extracted from the user's materials. Use the format from project_docs_contract.md.

docs/todo.md

# TODOs

## Setup
- [ ] Initial data exploration
  - created: <today's date>

## <topic from current focus>
- [ ] <first task inferred from materials>
  - created: <today's date>

Other docs/ files

  • data.md — populate if the materials describe datasets
  • methods.md — populate if the materials describe identification strategy or methods
  • literature.md — populate if the materials cite papers
  • institutions.md — populate if the materials describe institutional context
  • thinking.md — place any speculative or exploratory content from the materials here
  • findings/index.md — seed the folder-mode findings page even for a new project, so the first finding lands compliant instead of drifting into an ad-hoc flat file. Copy the ## How to read the confidence tags block (🟢/🟡/🔴 Replicated/Single source/Provisional; Strong/Plausible/Speculative) verbatim from project_docs_contract.md §864, then leave an empty ## Findings overview (with ### Empirical findings / ### Interpretations subheads). Individual findings become sibling docs/findings/<slug>.md files with the required four-class Sources footer. Do NOT create a flat docs/findings.md.
  • Remaining files: create with header and empty template sections per the contract formats in project_docs_contract.md section 6.

README.md

# <Project Title>

<One-line research question>

See `docs/summary.md` for details.

Step 4: Handle the user's seed materials

After scaffolding, the user's original files are still in the project folder. Ask the user whether to:

  • Move them to a subfolder (e.g., references/ or docs/notes/)
  • Leave them where they are
  • Delete them (now that their content has been absorbed into docs/)

Step 5: Register the project

  1. Check $ROOT/research/rules/workspace.md — note the new project in the projects/ listing if the user wants to update it.
  2. Check $ROOT/research/meta/research_map.md — suggest where it fits in the project clusters.
  3. If the project originated from an idea in $ROOT/ideas/, update the idea's frontmatter (status: project, related_project: $ROOT/projects/<slug>).
  4. Suggest creating a project brief in $ROOT/research/project_briefs/.

Step 6: Initialize git

cd $ROOT/projects/<slug> && git init

Create a .gitignore:

build/
*.pyc
__pycache__/
.ipynb_checkpoints/

Gotchas

  • Never overwrite files the user placed in the folder. The user's materials are the source of truth.
  • Do NOT create optional docs files (theory.md, hypotheses, results.md, etc.) unless the user asks or the materials clearly warrant them. When hypotheses are warranted, create folder mode (docs/hypotheses/index.md + one <slug>.md per hypothesis), never a flat docs/hypotheses.md — folder mode is the default per project_docs_contract.md §5 (same as docs/findings/).
  • Do NOT create talk/ or references/ directories unless requested.
  • Pipeline repos are different — they have fewer docs files and no paper/. If the user actually wants a pipeline, tell them and use the pipeline structure from the contract.
  • Always use today's date (from system context) for created dates.
  • Check $ROOT/research/meta/variable_dictionary.md and $ROOT/research/meta/data_linkages.md before populating data.md — the dataset may already be documented.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.