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
- Walsworth-Group/physkittheir own version, first seen Nov 8, 2026
- cperler/soustheir own version, first seen Nov 8, 2026
- Mark-Life/agent-skillstheir own version, first seen Nov 6, 2026
- pche-broken-artist/forge-of-thoughttheir own version, first seen Nov 6, 2026
- danielrosehill/Claude-Image-Production-Plugintheir own version, first seen Nov 5, 2026
- buildomator/buildomatortheir own version, first seen Nov 4, 2026
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.
genomewalkerSkillcheckpoint
Save a checkpoint of task status, decisions, active files, and next steps
Also in 3 projects that use this
GitHubSkillprd
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
sunnyclinches44Skillexplain
Explains code using real-world analogies and ASCII diagrams
Also in 3 projects that use this
SentrySkillspec
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
GoogleSkilldomain-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
SentrySkillreview
Fixture review skill.
Also in 5 projects that use this
- +1 more from getsentry
Other versions51 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 51
- hsantanna88/clo-author★ 262same name
- hugosantanna/clo-author★ 262same name
- buildomator/buildomator★ 102same name
- sneg55/agent-starter★ 76same name
- dtiger1889-ops/claude-harness-toolbox★ 31same name
- 5throck/ai-workspace-standards★ 25same name
- jcottam/agent-resources★ 25same name
- danielrosehill/Claude-Image-Production-Plugin★ 21same name
- pche-broken-artist/forge-of-thought★ 12same name
- ice-lfernandes/claude-spring-architect★ 11same name
41 more not listed
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository39 other files it gives its agents.
- anecdotesSkill
- backupSkill
- checkSkill
- cite-syncSkill
- dataSkill
- diariosSkill
- distill-styleSkill
- driveSkill
- dropboxSkill
- fetch-annotationsSkill
- findings-auditSkill
- findingsSkill
- gmailSkill
- handoffSkill
- howtoSkill
- hypothesisSkill
- iatSkill
- ideaSkill
- inboxSkill
- institutionsSkill
- literatureSkill
- llmkitSkill
- meetSkill
- memory-auditSkill
- new-pipelineSkill
- nextSkill
- otterSkill
- outlookSkill
- questionsSkill
- referee-panelSkill
- siteSkill
- style-checkSkill
- style-reviewSkill
- style-reviseSkill
- tactiqSkill
- theorySkill
- validate-sectionSkill
- whatsappSkill
- zoomSkill
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
- Very specific: line 39
Follow the canonical structure from $ROOT/research-kit/rules/project_docs_contract.md.
- Very specific: line 78
Follow the pattern of existing projects (see any $ROOT/projects/*/CLAUDE.md for examples):
- Very specific: line 110
Add domain-specific WebFetch permissions if the materials mention specific data sources or websites.
- Distinctive: line 152
After scaffolding, the user's original files are still in the project folder.
- Distinctive: line 154
Leave them where they are
- Distinctive: line 155
Delete them (now that their content has been absorbed into docs/)
- Very specific: line 159
Check $ROOT/research/rules/workspace.md — note the new project in the projects/ listing if the user wants to update it.
- Very specific: line 160
Check $ROOT/research/meta/research_map.md — suggest where it fits in the project clusters.
- Very specific: line 161
If the project originated from an idea in $ROOT/ideas/, update the idea's frontmatter (status: project, related_project: …
- Very specific: line 182
Do NOT create talk/ or references/ directories unless requested.
- Distinctive: line 184
Always use today's date (from system context) for created dates.
- Very specific: line 185
Check $ROOT/research/meta/variable_dictionary.md and $ROOT/research/meta/data_linkages.md before populating data.md — the dataset may …
“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.
Files
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.).
- 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 (nodocs/directory). - Read every file in the project folder. These are the user's seed materials — project descriptions, research proposals, paper drafts, notes, data documentation, etc.
- 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
- Check workspace context for connections:
$ROOT/research/meta/data_linkages.mdand$ROOT/data_catalog/for existing datasets$ROOT/research/meta/variable_dictionary.mdfor known variables$ROOT/research/meta/research_map.mdfor 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 requestsStep 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 tagsblock (🟢/🟡/🔴 Replicated/Single source/Provisional; Strong/Plausible/Speculative) verbatim fromproject_docs_contract.md§864, then leave an empty## Findings overview(with### Empirical findings/### Interpretationssubheads). Individual findings become siblingdocs/findings/<slug>.mdfiles with the required four-class Sources footer. Do NOT create a flatdocs/findings.md. - Remaining files: create with header and empty template sections per the contract formats in
project_docs_contract.mdsection 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/ordocs/notes/) - Leave them where they are
- Delete them (now that their content has been absorbed into docs/)
Step 5: Register the project
- Check
$ROOT/research/rules/workspace.md— note the new project in theprojects/listing if the user wants to update it. - Check
$ROOT/research/meta/research_map.md— suggest where it fits in the project clusters. - If the project originated from an idea in
$ROOT/ideas/, update the idea's frontmatter (status: project,related_project: $ROOT/projects/<slug>). - Suggest creating a project brief in
$ROOT/research/project_briefs/.
Step 6: Initialize git
cd $ROOT/projects/<slug> && git initCreate 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>.mdper hypothesis), never a flatdocs/hypotheses.md— folder mode is the default perproject_docs_contract.md§5 (same asdocs/findings/). - Do NOT create
talk/orreferences/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.mdand$ROOT/research/meta/data_linkages.mdbefore populating data.md — the dataset may already be documented.
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
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.

