agentleFS
robium-airobium-ai/robium/skills/mining/SKILL.md

mining

Skill93 starsChanged 3 months agoMITView on GitHub

Mine, compare, or re-crawl approved external robotics repositories into local evidence-cited Robium observations for later skill absorption.

1 other project uses a version of this.

Adopted by

Most recently taken up by

The file

We split this skill into the rules it gives an agent

7 rules. About 0 are common, 6 are distinctive, and 1 is very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈6

    Distinctive · estimate

    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. Very specific:

    Start with a survey of the tree, active code paths, documentation, examples, tests, and license.

    line 15
  2. Distinctive:

    Prefer official/vendor sources.

    line 18
  3. Distinctive:

    Read WORKFLOW.md for the survey, deep-read, comparative, and re-crawl mechanics.

    line 21
  4. Distinctive:

    Keep patterns, orderings, failure discriminators, integration shapes, and configuration decisions that transfer beyond the source project.

    line 26
  5. Distinctive:

    Every observation cites a pinned repository commit, path, line range, and a verbatim source excerpt that the citation verifier can find.

    line 30
  6. Distinctive:

    Read EVIDENCE.md for source-authority thresholds, conflicts, licensing, placement, and new-skill proposals.

    line 32
  7. Distinctive:

    Do not crawl issue trackers or commit history as part of the current mining workflow.

    line 45

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

Mining

Mine for transferable decisions, not code volume.

Choose what is worth reading

  • Candidate discovery and a one-line registry entry are read-only triage. Survey or deep-read only a repository the user named or approved in learnings/SOURCES.md.
  • Start with a survey of the tree, active code paths, documentation, examples, tests, and license. Spend deep-reading effort only where the survey finds a decision that could change a Robium skill.
  • Prefer official/vendor sources. Use comparative reads when independent projects answer the same question; use a re-crawl when a previously mined source changed.
  • Read WORKFLOW.md for the survey, deep-read, comparative, and re-crawl mechanics.

Keep only reusable evidence

  • Keep patterns, orderings, failure discriminators, integration shapes, and configuration decisions that transfer beyond the source project.
  • Drop project names, incidental ports, arbitrary tuning, style, and other local choices unless they explain a reusable boundary.
  • Every observation cites a pinned repository commit, path, line range, and a verbatim source excerpt that the citation verifier can find.
  • Read EVIDENCE.md for source-authority thresholds, conflicts, licensing, placement, and new-skill proposals.

Preserve the learning boundary

  • Output gitignored local observations and source-registry updates, never direct skill edits. Absorption belongs to learning-loop and remains separately reviewed.
  • Compare findings with existing skills and observations. Record disagreement with both provenances; do not silently replace Robium field evidence with an upstream idiom.
  • Point to source code by default. Vendor code only when it is short, genuinely useful as a maintained example, and its license and attribution permit it.
  • Do not crawl issue trackers or commit history as part of the current mining workflow.

Done

  • The registry records the pinned commit, crawl date, status, and the skill or reference files that ultimately retained the finding. Local observation IDs are not repository history.
  • Citation and observation checks pass for every retained finding.
  • Each finding names the owning skill or explains why no current skill owns it.
  • Temporary clones and survey reports remain outside the committed plugin.
  • End with a short handoff: report how many local observations were saved and how many are ready versus tentative, then say that the next step is to run learning-loop to distill ready findings into existing skills or route a justified new-skill proposal through skill-author. Ask whether the user wants that absorption run in a background subagent; do not start it without approval.

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.