agentleFS
hranesshraness/atet/.agents/skills/percolate-kb/SKILL.md

percolate-kb

Skill7 starsChanged 49 days agoMITView on GitHub

Review a hraness/wordcell Markdown vault for recurring ideas and missing structural connections, then promote evidence-backed concepts and typed relationships with the Wordcell CLI. Use after materially adding or revising notes, when organizing an accumulated vault, or when an agent needs to turn repeated tags and prose references into an explicit queryable knowledge graph.

4 other projects use a version of this, 1 of them edited.

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

15 rules. About 0 are common, 13 are distinctive, and 2 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈13

    Distinctive · estimate

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

    Keep the graph authored, local, and reviewable.

    line 10
  2. Distinctive:

    Read the applicable repository and vault instructions before editing.

    line 19
  3. Distinctive:

    Run percolation on the changed note when possible:

    line 26
  4. Distinctive:

    Run it without a note only when reviewing the whole vault:

    line 32
  5. Distinctive:

    Treat each result as a prompt to open the cited notes and read the relevant prose.

    line 38
  6. Distinctive:

    Create a concept only when the idea is likely to be reused and its definition can be stated from the source material:

    line 62
  7. Distinctive:

    Write a concise definition and cite or link the notes that establish it.

    line 76
  8. Distinctive:

    After promotion, rerun percolation on the cited non-concept notes.

    line 81
  9. Distinctive:

    Add a relationship from the note that owns the assertion:

    line 91
  10. Very specific:

    Use a specific lower-kebab-case predicate.

    line 98
  11. Distinctive:

    Never write inverse edges, generated backlinks, inferred transitive relationships, or semantic-search scores into Markdown.

    line 110
  12. Distinctive:

    Use exact structure to verify that the promoted graph says what the prose says:

    line 116
  13. Distinctive:

    Prefer the note-scoped commands first.

    line 124
  14. Distinctive:

    When working alone or integrating several lanes:

    line 130
  15. Distinctive:

    When several agents are editing different notes in a managed-catalog vault, each lane should validate authored structure and local …

    line 137

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

Percolate concepts and relationships

Keep the graph authored, local, and reviewable. wordcell percolate proposes candidates from deterministic evidence; it never changes a note. Backlinks, graph reports, and QMD results are derived views, while Markdown remains the authority.

Locate the vault

  • Resolve <vault> to the directory containing its authored or managed index.md front door.
  • Read the applicable repository and vault instructions before editing.
  • Pass the resolved path to every --root.
  • Identify the note or small neighborhood changed by the current task. Prefer a bounded review to a vault-wide cleanup during parallel work.

Inspect candidates

Run percolation on the changed note when possible:

wordcell percolate notes/example --root "$KB_ROOT" --limit 25 --json

Run it without a note only when reviewing the whole vault:

wordcell percolate --root "$KB_ROOT" --min-support 2 --limit 50 --json

Treat each result as a prompt to open the cited notes and read the relevant prose. Candidate kinds may include:

  • a recurring tag with no maintained type: concept note;
  • notes that share a concept or tag but have no explicit relationship;
  • an exact title or alias mentioned without a contextual link;
  • a self, reciprocal, malformed, broken, or ambiguous authored relationship.

For missing relationships, support counts independent shared tags or concept neighbors; the evidence array shows the participating notes. The default minimum of two therefore requires two shared signals, not merely both endpoints of one tag match. Other candidate kinds count their natural unit: supporting notes, mention occurrences, or authored hygiene evidence.

For a missing concept, use suggestedId. When collidesWith is non-null, the natural ID is already an ordinary note, so KB chooses an unoccupied *-concept ID. Read the occupied note before deciding whether to create the suggested concept or promote and improve the existing note instead.

Semantic search may help discover evidence, but similarity is never enough to author an edge.

Promote durable concepts

Create a concept only when the idea is likely to be reused and its definition can be stated from the source material:

wordcell note create notes/local-first \
  --root "$KB_ROOT" \
  --title "Local-first" \
  --type concept \
  --tag architecture \
  --body '# Local-first

A concise reviewed definition grounded in the cited notes.'

Write a concise definition and cite or link the notes that establish it. Concepts are ordinary Markdown notes, so they can carry aliases, evidence, context, and their own outbound relationships. Do not create a concept merely to mirror every tag.

After promotion, rerun percolation on the cited non-concept notes. The new concept may support relationships among its neighbors even when a run scoped to the concept itself has no candidate:

wordcell percolate notes/write-path --root "$KB_ROOT" --limit 25 --json

Author typed relationships

Add a relationship from the note that owns the assertion:

wordcell relation add notes/write-path supports notes/durable-agent-memory \
  --root "$KB_ROOT"

Use a specific lower-kebab-case predicate. Targets are exact vault-root note IDs without .md. Ground the assertion in nearby prose or evidence; the frontmatter is an indexable statement, not a substitute for explanation.

List or remove relationships without editing reciprocal notes:

wordcell relation list notes/write-path --root "$KB_ROOT" --json
wordcell relation remove notes/write-path supports notes/durable-agent-memory \
  --root "$KB_ROOT"

Never write inverse edges, generated backlinks, inferred transitive relationships, or semantic-search scores into Markdown. Those are derived views.

Query before concluding

Use exact structure to verify that the promoted graph says what the prose says:

wordcell links notes/write-path --root "$KB_ROOT" --direction both --depth 2 --json
wordcell relation list notes/write-path --root "$KB_ROOT" --json
wordcell graph --root "$KB_ROOT" --json

Prefer the note-scoped commands first. Use the whole-vault graph only when the question spans several neighborhoods, and confirm returned IDs against their Markdown notes before reporting a conclusion.

Finish under the vault's catalog mode

When working alone or integrating several lanes:

wordcell refresh --root "$KB_ROOT"
wordcell check --root "$KB_ROOT"

When several agents are editing different notes in a managed-catalog vault, each lane should validate authored structure and local attachments without rewriting the shared catalog:

wordcell check --root "$KB_ROOT" --no-catalog

The integrating agent runs one final managed refresh and normal check. In an authored-catalog vault, refresh and check leave the front door untouched, while wordcell catalog --root "$KB_ROOT" renders an exhaustive disposable inventory. Resolve same-note Git conflicts from the prose and evidence; do not accept one side's frontmatter mechanically.

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.