research-context-compressor
Skill67 starsChanged 7 months agoMITView on GitHub
Inspect a research repository and write a compact `.research/` workspace manifest (project_manifest.yml, experiment_matrix.yml, data_dictionary.yml) so future AI sessions can orient themselves without rescanning the whole repo. Use when the user asks to "compress this project context", "create a research manifest", or "save the project context for future agents".
In this repository14 other files it gives its agents.
- AGENTS.mdAGENTS.md
- CLAUDE.mdCLAUDE.md
- research-hubSkill
- gap-to-topicSkill
- literature-triage-matrixSkill
- notebooklm-brief-verifierSkill
- paper-memory-builderSkill
- paper-summarizeSkill
- research-design-helperSkill
- research-hub-multi-aiSkill
- research-hubSkill
- research-project-orienterSkill
- research-workflow-orchestratorSkill
- zotero-library-curatorSkill
The file
Show its rules and text
We split this skill into the rules it gives an agent
13 rules. About 0 are common, 3 are distinctive, and 10 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈3
Distinctive · estimate
This author's own choices. Worth a look.
10
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 80
Write these to <project-root>/.research/:
- Very specific: line 90
Stage 2 → 3a provenance (v0.3.13+): If .research/design_brief.md exists AND its frontmatter sets source: topic_dossier.gaps.yml#<gap-id>, …
- Very specific: line 106
If no design_brief.md exists or its frontmatter source field is empty, omit the provenance: block entirely — do NOT write provenance: {} or …
- Distinctive: line 112
If a file already exists, update don't replace: keep human-edited fields, fill in only the empty ones unless the user said "regenerate from …
- Very specific: line 132
If you don't know a field, leave it empty ("" or []).
- Distinctive: line 137
Read manifest files first if they exist.
- Very specific: line 141
After running, tell the user: "Wrote .research/project_manifest.yml (and N other files).
- Distinctive: line 147
After writing the files, print a 5-line summary:
- Very specific: line 160
Don't write to .paper/ — that's paper-memory-builder's job.
- Very specific: line 161
Don't write .research/literature_matrix.md — that's literature-triage-matrix's job.
- Very specific: line 163
Don't write to .research_hub/ — that's research-hub's internal cache, managed by the CLI.
- Very specific: line 165
Don't invent fields not in the schema.
- Very specific: line 167
Don't overclaim: if the project has no clear research question yet, leave research_question empty and add a question to open_questions.md.
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
research-context-compressor
Build a compact, machine-readable workspace memory at the project root
under .research/. Other research-hub skills (project-orienter,
literature-triage-matrix, paper-memory-builder) read these files instead of
rescanning the repo every session, which is where the token savings come from.
This is the foundation skill. Run it once per project and refresh when the project's research question, datasets, or experiment set changes.
When to use
Trigger phrases:
- "Compress this project context for future agents."
- "Create a research manifest so future sessions don't reread everything."
- "Save the key project context before we continue."
- "Build a
.research/folder for this repo."
Not for:
- Compressing source code or generating doc strings — that's a code task.
- Running experiments or analyzing results — those write to
outputs/, not.research/. - Writing the manuscript itself.
Inputs you should read (whichever exist — priority order)
The compressor reads whatever your project has. None of these are required. If a file is missing, that field of the manifest stays empty (see "What NOT to do"). Skim, do not deep-read.
For any project:
README.mdat the repo root — project overview. Single most useful input..research/design_brief.mdif it exists — Stage 3a handoff fromresearch-design-helper(plugin v0.3.12+). Read the frontmatter (project,source,gap_verdict) plus section 1 (Research question) only — informs theproject_manifest.ymlresearch_questionfield. The brief is the authority on the sharpened RQ; the manifest mirrors it. Don't deep-read; skim. If frontmattersource: topic_dossier.gaps.yml#<id>is set, copy that gap-id into the manifest'sprovenance.from_gapfield (forward-compat with the Stage 2 → 3a wire).
For code-based research projects (Python / JS / R / Julia / etc.):
pyproject.toml/package.json/requirements.txt/renv.lock/Project.toml— primary tools.scripts/andnotebooks/— main entrypoints.data/andoutputs/— datasets and artifacts.
For qualitative / archival / interpretive projects:
notes/,drafts/,sources/— manuscript-track work..obsidian/— Obsidian vault settings, if present.- Any plain-text bibliography file (
bibliography.md,sources.bib,references.json).
For both:
docs/— long-form descriptions..git/HEADandgit log --oneline -20— current branch + recent activity, if a git repo..research/(if it already exists) — for refresh, not first-time create.
An empty manifest field is better than an invented one.
For a worked humanities-project example with minimal scaffold (README + notes/ only, no code, no data/), see references/example-humanities-project.md. It illustrates the "empty fields are honest" rule.
Outputs you must produce
Write these to <project-root>/.research/:
project_manifest.yml— top-level orientation. Required.experiment_matrix.yml— per-experiment status. Required ifscripts/ornotebooks/exist.data_dictionary.yml— datasets and schemas. Required ifdata/exists.run_log.md— append a single entry recording this run.decisions.md— leave empty if no ADRs yet; do not invent decisions.open_questions.md— list any obvious unknowns you spotted (e.g. undocumented dataset, missing license, ambiguous entrypoint).
Stage 2 → 3a provenance (v0.3.13+). If .research/design_brief.md
exists AND its frontmatter sets source: topic_dossier.gaps.yml#<gap-id>,
copy that pointer into the project_manifest.yml provenance.from_gap
field as part of every write:
# project_manifest.yml — minimal example showing the v0.3.13 provenance wire
project_name: "..."
research_question: |
... # mirrored from design_brief.md §1 (sharpened RQ)
current_stage: "design"
last_updated: "YYYY-MM-DD"
provenance:
from_gap: "topic_dossier.gaps.yml#G2" # exact copy of design_brief frontmatter `source`If no design_brief.md exists or its frontmatter source field is
empty, omit the provenance: block entirely — do NOT write
provenance: {} or provenance: null. The schema doc
(docs/research-workspace-manifest.md) records the field as optional;
absent is the honest state when the upstream chain isn't connected.
If a file already exists, update don't replace: keep human-edited
fields, fill in only the empty ones unless the user said "regenerate from
scratch". This rule also applies to provenance.from_gap — if a
manifest already has provenance.from_gap and the current
design_brief.md source differs, ask the user before overwriting
(matches the v0.3.12 provenance-protection logic in
research-design-helper).
Schema reference
Full schema lives in
docs/research-workspace-manifest.md.
Quick reminder of project_manifest.yml required fields:
project_nameresearch_arearesearch_questioncurrent_stage(one ofdiscovery / exploration / experiments / writing / rebuttal / submission)last_updated(today's date in ISO format)
If you don't know a field, leave it empty ("" or []). Do not guess
research questions, hypotheses, or claims.
Token-saving behavior
- Read manifest files first if they exist; only inspect code/data when the manifest doesn't already cover what you need.
- For large directories, list contents and pick representative entrypoints rather than reading every file.
- After running, tell the user: "Wrote
.research/project_manifest.yml(and N other files). Future agents loading theresearch-project-orienterskill can now orient themselves without re-reading the whole repo."
Output format for the user
After writing the files, print a 5-line summary:
[research-context-compressor]
Wrote: .research/project_manifest.yml (3 datasets, 2 entrypoints)
Wrote: .research/experiment_matrix.yml (2 experiments)
Wrote: .research/data_dictionary.yml (3 datasets)
Open questions surfaced: 2 — see .research/open_questions.md
Refresh later: ask "compress this project context" again.What NOT to do
- Don't write to
.paper/— that'spaper-memory-builder's job. - Don't write
.research/literature_matrix.md— that'sliterature-triage-matrix's job. - Don't write to
.research_hub/— that's research-hub's internal cache, managed by the CLI. - Don't invent fields not in the schema. Add a line to
.research/open_questions.mdinstead. - Don't overclaim: if the project has no clear research question yet, leave
research_questionempty and add a question toopen_questions.md.
See also
references/example-humanities-project.md— worked example for a non-code research project (minimal scaffold)
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.

