agentleFS
SethGammonSethGammon/Armory/research/SKILL.md

research

Skill19 starsChanged 7 months agoMITView on GitHub

Focused research investigations. Converts questions into structured findings with confidence levels and source citations. Does not make decisions — produces information that informs the next step.

We split this skill into the rules it gives an agent

7 rules. 0 are common, 5 are distinctive, and 2 are very specific to this project.

  • 0

    Common

    Most of the 165 edited versions we read keep these.

  • 5

    Distinctive

    This author's own choices. Worth a look.

  • 2

    Very specific

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

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Use WebSearch for discovery, WebFetch for reading actual pages

    line 44
  2. Distinctive:

    Stop at 3-6 credible sources (not exhaustive — focused)

    line 46
  3. Distinctive:

    If a source contradicts another, note the disagreement

    line 47
  4. Very specific:

    Write findings to .planning/research/{topic-slug}.md:

    line 60
  5. Distinctive:

    Search exhaustively (2-4 queries, 3-6 sources, done)

    line 96
  6. Very specific:

    .planning/research/ does not exist: Create it before writing the findings document.

    line 104
  7. Distinctive:

    Every finding must have a source URL

    line 110

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

Identity

/research is for focused research investigations. It converts questions into structured findings with confidence levels. It does NOT make decisions or modify code — it produces information that informs the next step.

When to Use

  • Evaluating whether a dependency has a newer version or has been superseded
  • Finding community best practices for a specific technical problem
  • Reading official documentation for an API or library
  • Investigating how other projects solve a similar problem
  • Checking if a pattern used in the codebase has known issues
  • Any time you need external information before making a decision

Protocol

Step 1: FORMULATE

Convert the research question into 2-4 specific search queries:

  • Official docs query (e.g., "express.js middleware error handling docs")
  • Community/GitHub query (e.g., "express error middleware best practices site:github.com")
  • Technical blog/comparison query (e.g., "express vs fastify error handling 2025")
  • Release notes query if version-specific (e.g., "express 5.x changelog breaking changes")

State the question clearly in one sentence before searching.

Step 2: SEARCH

Execute searches and read actual content (not just snippets):

  • Use WebSearch for discovery, WebFetch for reading actual pages
  • Evaluate source credibility: official docs > GitHub repos with stars > recent blog posts > forum answers
  • Stop at 3-6 credible sources (not exhaustive — focused)
  • If a source contradicts another, note the disagreement

Step 3: EXTRACT

For each finding, record:

  • What: The specific fact, recommendation, or pattern discovered
  • Source: URL or reference
  • Relevance: How this applies to the original question (one sentence)
  • Confidence: high (official docs, verified), medium (community consensus), low (single source, opinion)
  • Action: What the codebase should do with this information (or "informational only")

Step 4: WRITE

Write findings to .planning/research/{topic-slug}.md:

# Research: {Topic}

> Question: {The original question}
> Date: {ISO date}
> Confidence: {overall: high/medium/low}

## Findings

### 1. {Finding title}
**What:** {description}
**Source:** {URL}
**Confidence:** {high/medium/low}
**Action:** {recommendation or "informational"}

### 2. {Finding title}
...

## Summary
{2-3 sentences: what was learned, what the recommendation is}

## Open Questions
{Anything that couldn't be resolved — needs human judgment or deeper investigation}

Step 5: RETURN

Return the summary and recommendation to the caller (user, Marshal, or Archon). The research document persists for future reference.

What /research Does NOT Do

  • Make architectural decisions (that's the caller's job)
  • Install packages or modify code
  • Search exhaustively (2-4 queries, 3-6 sources, done)
  • Evaluate subjective opinions as facts
  • Recommend without evidence

Fringe Cases

  • No web access available: Fall back to local-only research. Search the codebase, read docs files, check package.json, and produce findings from local sources. Note the limitation in the research document's confidence level.
  • Search returns nothing relevant: Broaden the query (remove version-specific terms, try synonyms), try one more angle. If still empty, report uncertainty explicitly: "No strong evidence found. Recommend human review."
  • .planning/research/ does not exist: Create it before writing the findings document. Never error on a missing output directory.
  • Conflicting sources: Surface the conflict explicitly in the findings rather than silently picking one. Both sides belong in the document.
  • Question is too broad for 3-6 sources: Narrow to the single most important sub-question, answer it well, and note what was scoped out. Suggest /research-fleet for multi-angle questions.

Quality Gates

  • Every finding must have a source URL
  • Confidence levels must be justified (not guessed)
  • Summary must answer the original question or state why it can't be answered
  • Research document must be written before returning findings

Exit Protocol

Output findings summary, then:

---HANDOFF---
- Research: {topic}
- Findings: {count} sources analyzed
- Recommendation: {one-line summary}
- Document: .planning/research/{slug}.md
---

Download now (ZIP)

  • Other versions186 projects use a version of this.

    Word for word · 1

    1. allysgrandiose674/Armory★ 1100% same

    Edited · 2

    1. SethGammon/Citadel★ 92728% same
    2. mayankjain1815-commits/CITADEL★ 428% same

    Wrote their own version · 183

    1. mattpocock/skills★ 303ksame name
    2. Yeachan-Heo/oh-my-claudecode★ 40ksame name
    3. Yeachan-Heo/oh-my-claude-sisyphus★ 40ksame name
    4. QuivrHQ/quivr★ 40ksame name
    5. udecode/plate★ 17ksame name
    6. openai/plugins★ 7.4ksame name
    7. ArcReel/ArcReel★ 5.5ksame name
    8. vinvcn/mattpocock-skills-zh-CN★ 5.3ksame name
    9. withcoral/coral★ 4.9ksame name
    10. docker/docs★ 4.7ksame name

    173 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.

  • Used alongsideProjects with it also use daily-arxiv, exp-eval and 10 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.
    • LambenthanSkill

      daily-arxiv

      每日从 arXiv 拉取新论文,过滤相关性,auto-ingest 高优先级论文,检测 SOTA 更新

      Also in 5 projects that use this

    • LambenthanSkill

      exp-eval

      实验判决门:Review LLM 独立评判实验结果 → 4 种判决路径 → 自动更新 claims confidence、ideas status、graph edges

      Also in 5 projects that use this

    • truongtv22Skill

      Problem-Solving Techniques

      Apply systematic problem-solving techniques for complexity spirals (simplification cascades), innovation blocks (collision-zone thinking), recurring patterns (meta-pattern recognition), assumption constraints (inversion exercise), scale uncertainty (scale game), and dispatch when stuck. Techniques derived from Microsoft Amplifier project patterns adapted for immediate application.

      Also in 5 projects that use this

    • liufeng1976Skill

      setup-ts-deep-modules

      Wire dependency-cruiser into a TypeScript repo so each package is a deep module — implementation hidden in subfolders, reachable only through its entry-point files. User-invoked.

      Also in 33 projects that use this

    • parcadeiSkill

      ast-grep-find

      AST-based code search and refactoring via ast-grep MCP

      Also in 4 projects that use this

    • parcadeiSkill

      debug-hooks

      Systematic hook debugging workflow. Use when hooks aren't firing, producing wrong output, or behaving unexpectedly.

      Also in 4 projects that use this

    • +5 more from Lambenthan
  • In this repository13 other files it gives its agents.

Does it work?

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

Reviews can't be read right now.

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.