agentleFS
WenyuChiouWenyuChiou/research-hub/skills/research-project-orienter/SKILL.md

research-project-orienter

Skill67 starsChanged 7 months agoMITView on GitHub

Read the .research/ manifest files at a project root and produce a single orientation memo (research question, datasets, current stage, key entrypoints, evidence artifacts, open questions). Use when the user asks to "orient me in this project", "what is this repo about", or "build a context map for this paper" — and the project already has .research/ manifests (or trigger research-context-compressor first).

The file

We split this skill into the rules it gives an agent

8 rules. About 0 are common, 3 are distinctive, and 5 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.

  • 5

    Very specific

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

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Read in this order:

    line 37
  2. Distinctive:

    Do not read source code, data files, or PDFs unless the manifest points you at a specific path AND the user's question requires it.

    line 46
  3. Very specific:

    Don't auto-fall-back — ask first.

    line 58
  4. Very specific:

    Don't summarize the manuscript — paper-memory-builder does that.

    line 115
  5. Very specific:

    Don't compare papers — literature-triage-matrix does that.

    line 116
  6. Distinctive:

    Don't propose code changes — that's a separate task.

    line 117
  7. Very specific:

    Don't invent missing fields.

    line 118
  8. Very specific:

    Don't read PDFs in data/ or outputs/ unless directly asked.

    line 121

≈ “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.

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

research-project-orienter

Quickly orient an AI assistant inside a research workspace without scanning the whole repository. Reads the .research/ manifest files written by research-context-compressor and produces a single in-conversation orientation memo.

Part of the research-hub skill pack; works alongside Zotero, Obsidian, and NotebookLM workflows but does not require any of them.

This skill is fast and read-only. If .research/ doesn't exist yet, defer to research-context-compressor first.

When to use

Trigger phrases:

  • "Understand this research project before helping me."
  • "Summarize this repo's research question, data, experiments, and outputs."
  • "Build a context map for this paper/project."
  • "Orient me in this codebase."
  • "What is this repo about?"

Not for:

  • Detailed code review — that's a code task.
  • Generating new manifests — use research-context-compressor first.
  • Literature review — use literature-triage-matrix.

Inputs

Read in this order:

  1. .research/project_manifest.yml — top-level orientation. Required.
  2. .research/experiment_matrix.yml — experiment status. Read if present.
  3. .research/data_dictionary.yml — datasets. Read if present.
  4. .research/decisions.md — recent ADRs. Read last 5 if present.
  5. .research/open_questions.md — known unknowns. Read all.
  6. .research/run_log.md — last 3 entries for context.

Do not read source code, data files, or PDFs unless the manifest points you at a specific path AND the user's question requires it.

What if .research/ doesn't exist?

Tell the user:

This project doesn't have a .research/ manifest yet. I can create one first (loads research-context-compressor skill, takes ~30 seconds and writes 3 small YAML files), or I can fall back to scanning the repo directly (slower, more tokens). Which?

Don't auto-fall-back — ask first. If they pick "scan", read README.md + docs/ + the top-level entrypoint, and produce the memo from that, but caveat: "this orientation came from a one-shot scan; for more reliable future sessions, run research-context-compressor once."

Output: orientation memo

Single message in this exact structure:

## Project orientation: <project_name>

**Research question**: <one sentence from manifest>

**Stage**: <current_stage>  ·  **Last updated**: <last_updated>

**Datasets** (<count>):
- `<name|id>`: <purpose|description; "(no description)" if both absent>
- ...

**Experiments** (<count>, by status):
- <status>: <id> — <hypothesis or method, one line; "(no hypothesis)" if both absent>
- ...

**Entrypoints**:
- `<path>` — <one-line purpose>  # if list form (`main_entrypoints`)
- `<key>: <path>`                # if object form (`entrypoints` map)
- ...

**Recent decisions** (<count>):
- <date>: <decision title>

**Open questions** (<count>):
- <question text>
- ...

**Evidence artifacts**:
- `<path>` — supports claim/figure
- ...

**Suggested next action**: <based on current_stage>

Length budget: ~200-400 tokens for typical project. Don't pad.

Token-saving behavior

  • The whole point of this skill is to save tokens. If you find yourself reading > 5 files outside .research/, stop and tell the user the manifest is incomplete — they should refresh with research-context-compressor.
  • Cache-friendly: the orientation memo is identical between sessions if the manifests don't change. Future sessions can paste it back as context.

What NOT to do

  • Don't summarize the manuscript — paper-memory-builder does that.
  • Don't compare papers — literature-triage-matrix does that.
  • Don't propose code changes — that's a separate task.
  • Don't invent missing fields. If research_question is empty in the manifest, say "no research question recorded; please add one to .research/project_manifest.yml" rather than guessing.
  • Don't read PDFs in data/ or outputs/ unless directly asked.

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.