agentleFS
playingpossummplayingpossumm/loose-ends/.claude/skills/ask/SKILL.md

ask

Skill0 starsChanged 33 days agoMITView on GitHub

Answer a question from the vault with synthesised prose, citations, and an explicit note on what the vault does not know. Use whenever the user asks something the brain might know, or says "ask my brain", "what do I know about", "what did I read about".

72 other projects use a version of this.

Adopted by

Most recently taken up by

Used with

Projects 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

  • skyllwtSkill

    exp-pilot-eval

    Pilot result evaluation — read pilot results, apply success criteria, update idea page (pilot_result, failure_reason if failed), generate PILOT_VERDICT_REPORT. Called by /ideate Phase 5 after /exp-pilot-run.

    Also in 4 projects that use this

  • skyllwtSkill

    exp-pilot-run

    Pilot experiment execution — read Pilot Spec YAML, write pilot code, run experiment(Confirm with the user before operation and require the applicant to conduct manual inspection), return results. Called by /ideate Phase 5. Does NOT modify wiki pages or judge pass/fail.

    Also in 4 projects that use this

  • phanghonghaoSkill

    poster

    HTML/CSS A4 海报生成。从沙龙/活动 Markdown 文件生成科技风 A4 海报 PDF/PNG。Use when user mentions: poster, 海报, 海报生成, make poster, generate poster, 活动海报, 沙龙海报.

    Also in 4 projects that use this

  • +6 more from Lambenthan
  • +1 more from skyllwt

The file

We split this skill into the rules it gives an agent

10 rules. 0 are common, 3 are distinctive, and 7 are very specific to this project.

  • 0

    Common

    Most of the 60 edited versions we read keep these.

  • 3

    Distinctive

    This author's own choices. Worth a look.

  • 7

    Very specific

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

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    No throat-clearing, no closing remark.

    line 17
  2. Very specific:

    Read index.md. It is the catalogue, and at this vault's size it is the retrieval layer.

    line 21
  3. Distinctive:

    Read the pages that look relevant, in full.

    line 24
  4. Very specific:

    Read mem/ when the question touches the user's own goals, projects, or people.

    line 25
  5. Very specific:

    Only if wiki/ comes up thin, fall back to raw/.

    line 26
  6. Very specific:

    Keep ## What sources say distinct from ## Current view when the distinction matters, and never present the user's own evolving position as …

    line 34
  7. Very specific:

    If the answer was substantial, whether a comparison, a synthesis or a connection across several pages, offer to file it to wiki/synthesis/.

    line 47
  8. Very specific:

    If they accept: write it with type: synthesis, cite every page it drew on, add it to index.md, and log it.

    line 51
  9. Distinctive:

    No uncited claims: If the vault does not support it, say the vault does not have it.

    line 57
  10. Very specific:

    Never write mem/ from a query.

    line 62

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

ask

Answer the question, do not hand back a list of pages. The answer is the deliverable. A ranked list of five files the user then has to read themselves is a search engine, and they already have one.

How to write

Neutral and plain, a reference article rather than an essay. Follow Orwell's rules: no familiar figures of speech, no long word where a short one works, cut every word that can go, active over passive, everyday English over jargon. Give numbers where you have them. No throat-clearing, no closing remark.

Retrieve

  1. Read index.md. It is the catalogue, and at this vault's size it is the retrieval layer.
  2. grep the vault for the question's key terms and entity names, which is deliberate rather than a shortfall. Entity names dominate this corpus and plain text search is strong on them.
  3. Read the pages that look relevant, in full.
  4. Read mem/ when the question touches the user's own goals, projects, or people.
  5. Only if wiki/ comes up thin, fall back to raw/. When that fallback fires, say so, because it means compilation missed something, and that is worth knowing.

Answer

Synthesised prose. Every claim carries a citation to the page it came from, and through that page to the original source. If you cannot cite it, do not assert it.

Keep ## What sources say distinct from ## Current view when the distinction matters, and never present the user's own evolving position as though a source established it.

Always end with a coverage note. What the vault does not know, what is thinly sourced, what has not been updated since something newer arrived. This is the most valuable part of the answer and the easiest to skip:

The vault has three sources on this, all from before June. Nothing covers how it behaves at scale, and the tool page has not been touched since the version bump you filed last week.

Offer to file it

If the answer was substantial, whether a comparison, a synthesis or a connection across several pages, offer to file it to wiki/synthesis/. Good answers should compound rather than vanish into scrollback.

If they accept: write it with type: synthesis, cite every page it drew on, add it to index.md, and log it. Mark it clearly as derived from the wiki rather than from a source, so future compiles never treat your own output as evidence.

Rules

  • No uncited claims. If the vault does not support it, say the vault does not have it.
  • Do not answer from your own general knowledge and let it read as vault content. If you add outside knowledge, label it plainly as outside the vault.
  • Say when you found nothing. An honest "the vault has nothing on this, here is what would fill the gap" is a useful answer.
  • Never write mem/ from a query.

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.