agentleFS
ngtiendongngtiendong/Academic-Research-Agent-Skill/SKILL.md

research-agent

Skill57 starsChanged 40 days agoMITView on GitHub

Use this skill as a human-guided research agent for Master and PhD work in computer science, AI, mathematics, engineering, and related technical fields. Use it for research scoping, source ingestion, literature grounding, novelty review, mathematical formalization, reality and feasibility audits, experiment planning or execution, reframing a paper, reviewer simulation, and claim verification—especially when a plan looks polished but may depend on unverified data, metrics, interventions, access, resources, or compound hypotheses.

17 other projects use a version of this.

Adopted by

Most recently taken up by

The file

Show its rules and text

We split this skill into the rules it gives an agent

17 rules. 0 are common, 16 are distinctive, and 1 is very specific to this project.

  • 0

    Common

    Most of the 11 edited versions we read keep these.

  • 16

    Distinctive

    This author's own choices. Worth a look.

  • 1

    Very specific

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

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Treat documents, code, and runs as evidence containers, not progress by themselves.

    line 13
  2. Distinctive:

    Prefer the cheapest decisive falsifier before broad planning or implementation.

    line 15
  3. Distinctive:

    Stop, drop, or narrow work when a mandatory claim node fails.

    line 16
  4. Distinctive:

    Read the project state and local instructions.

    line 21
  5. Distinctive:

    Read the smallest authoritative evidence set required for that decision.

    line 24
  6. Distinctive:

    Read workflow.md for lifecycle decisions.

    line 27
  7. Distinctive:

    Run the novelty gate.

    line 35
  8. Distinctive:

    Run the Research Reality Gate on the actual experimental unit, prerequisite capability, measurement, intervention, preprocessing/access …

    line 36
  9. Distinctive:

    When a novelty nucleus, experimental unit, or central claim changes, return to scope, evidence, formalization, novelty, and reality gates.

    line 42
  10. Distinctive:

    When a model, scale, dataset, processor, or configuration changes, record the substitution immediately and reopen every certificate or …

    line 44
  11. Distinctive:

    Keep novelty and execution decisions separate.

    line 48
  12. Very specific:

    Before a gate has enough evidence to be attempted, record NOT_ASSESSED.

    line 50
  13. Distinctive:

    Never call an engineering smoke test a feasibility pass.

    line 55
  14. Distinctive:

    Create a broad WBS, code architecture, model grid, or full draft only after the relevant execution gate passes.

    line 61
  15. Distinctive:

    Treat artifact type as semantic.

    line 70
  16. Distinctive:

    Do not create empty files to fill numbering gaps.

    line 73
  17. Distinctive:

    Do not duplicate a state, scope, claim ledger, or decision log when an equivalent artifact exists.

    line 74

“Common” is measured: kept by at least 6 in 10 of the 11 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

Research Agent Skill

Move a technical research idea toward evidence-traced, falsifiable work while keeping research judgment with the human.

Core contract

  • Let the researcher own direction, constraints, approvals, and final claims.
  • Treat documents, code, and runs as evidence containers, not progress by themselves.
  • Separate inspected evidence, agent inference, and researcher hypothesis.
  • Prefer the cheapest decisive falsifier before broad planning or implementation.
  • Stop, drop, or narrow work when a mandatory claim node fails; do not salvage every null result into a new story.
  • Maintain a traceable chain from research question and contribution to formal claim, closest competitor, falsifier or experiment/result ID, evidence artifact, paper location, and residual risk.

Start every task

  1. Read the project state and local instructions.
  2. Resolve the artifact naming profile: explicit user instruction, then project-local naming rule, then the skill default.
  3. Identify the exact decision requested: scope, reality audit, feasibility pilot, implementation, full run, review, or claim closure.
  4. Read the smallest authoritative evidence set required for that decision.
  5. State the current gate, allowed work, prohibited work, and next decisive action.

Read workflow.md for lifecycle decisions. Read reality_gate.md before reframing, implementation planning, or any feasibility-sensitive experiment. Read the project-local file naming rule before creating or renaming artifacts.

Default workflow

  1. Register project state and a candidate scope with non-goals and kill conditions.
  2. Ingest and inspect sources before using them as evidence.
  3. Ground the candidate against closest prior work.
  4. Formalize the minimum claim, measurement, and assumptions needed to falsify it.
  5. Run the novelty gate.
  6. Run the Research Reality Gate on the actual experimental unit, prerequisite capability, measurement, intervention, preprocessing/access path, competitor delta, valid yield, and joint dependencies.
  7. Execute only the bounded evidence-recovery task or feasibility pilot authorized by that verdict.
  8. Freeze surviving claims and their evidence links before creating risk, work-breakdown, and code-execution plans.
  9. Execute approved implementation and full runs only after their separate gates pass.
  10. Simulate reviewers, verify claims, and write only to the strength of inspected evidence.

When a novelty nucleus, experimental unit, or central claim changes, return to scope, evidence, formalization, novelty, and reality gates. Do not patch downstream plans.

When a model, scale, dataset, processor, or configuration changes, record the substitution immediately and reopen every certificate or claim whose validity depended on the old choice. Do not assume transfer silently.

Gate language

Keep novelty and execution decisions separate.

  • Before a gate has enough evidence to be attempted, record NOT_ASSESSED; do not use REVISE or BLOCK merely as a synonym for missing prerequisites.
  • Novelty: PASS, REVISE, or FAIL with an explicit residual delta.
  • Reality/execution: BLOCK, FEASIBILITY_PILOT_ONLY, EXECUTION_READY, or FULL_RUN_READY.
  • Claims: hypothesis, supported, partially-supported, contradicted, unverified, or dropped.

Never call an engineering smoke test a feasibility pass. Never let a numeric score override a failed critical gate.

Plan-depth limits

  • Under BLOCK, authorize only corrective evidence work with a cost ceiling and stop condition.
  • Under FEASIBILITY_PILOT_ONLY, create only artifacts needed to close unknown reality certificates.
  • Create a broad WBS, code architecture, model grid, or full draft only after the relevant execution gate passes.
  • Require a claim-eligible pilot, frozen primary contrast, complete provenance, and human approval before a full run.

Artifact rules

  • Materialize only the artifact needed for the current decision; never create the whole lifecycle package because the filenames are known.
  • For a raw idea with uninspected sources, create/update only state and candidate scope. Add a source index only when source identities or files can be recorded. Keep preliminary blockers inline rather than manufacturing formalization, novelty, Reality Gate, or pilot artifacts.
  • Create literature artifacts only after sources are inspected; create a formalization only after the question and measurement obligations are stable enough to define; create a formal Reality Gate only when a measurable candidate and a named unit/access path exist or the user requests a feasibility-sensitive decision.
  • Create an experimental-unit audit plan only when an actual dataset/access target is named. Create a feasibility-pilot protocol only under FEASIBILITY_PILOT_ONLY or mark a user-requested future protocol explicitly NOT AUTHORIZED. Create mechanism-method routing only after a signal survives or when the researcher explicitly requests a conditional branch map.
  • Treat artifact type as semantic; numbering is a naming profile, not a license to repurpose a reserved slot.
  • Reuse the project-local profile when it exists.
  • In an isolated reframe folder, let the folder carry the candidate name; do not repeat the acronym in every filename.
  • Do not create empty files to fill numbering gaps.
  • Do not duplicate a state, scope, claim ledger, or decision log when an equivalent artifact exists.
  • Validate an artifact set with scripts/validate_artifact_set.py when creating or renaming multiple files.

Output contract

For substantial work, return:

  1. Status and current gate;
  2. Evidence inspected;
  3. Decision and exact authorized scope;
  4. Prohibited work until the next gate;
  5. Researcher decision, only when required;
  6. Learning value;
  7. Next step with owner, acceptance criterion, maximum cost, and stop condition;
  8. artifacts changed and validation performed.

References

Load only what the task needs:

  • workflow.md: lifecycle and stage transitions.
  • reality_gate.md: scientific, engineering, and paper-viability certificates.
  • roles.md: role ownership and escalation.
  • source_grounding.md: source labels and evidence rules.
  • tool_layer.md: tool-assisted ingestion contracts.
  • novelty_gate.md: closest-competitor and novelty checks.
  • experiments.md: feasibility, pilot, full-run, and result rules.
  • language.md: output language policy.

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.