agentleFS
naman10parikhnaman10parikh/wikimem/skills/wikimem-observer/SKILL.md

wikimem-observer

Skill8 starsChanged 25 days agoMITView on GitHub

Run WikiMem's self-improvement Observer — score every wiki page on quality, surface the weakest/orphan/most-referenced pages and knowledge gaps, then optionally auto-improve a budget-capped set and commit one reviewable change. Use WHEN the user says "improve / clean up / lint / tidy my wiki", "what's weak in my notes", "score my vault", "fill the gaps", or wants the nightly self-evolution loop (Automation 3). This is the open-endedness moat — the wiki gets better while you sleep. Do NOT use for ingesting new sources (use wikimem-ingest-pipeline) or querying knowledge.

The file

We split this skill into the rules it gives an agent

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

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈1

    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:

    Do not invoke to add new content (that is wikimem-ingest-pipeline) or to answer a question from saved knowledge.

    line 21
  2. Very specific:

    Use --budget and --max-improvements on the cron path.

    line 61
  3. Distinctive:

    Always report: avg score (before→after), what was changed, dollars spent vs cap, and that one commit was written (so it's reversible).

    line 74

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

WikiMem Observer — The Wiki That Improves Itself

What this skill does

The Observer is WikiMem's self-improvement loop (Automation 3 — the moat). It reads the whole vault, scores each page, finds the pages worth touching (weakest + newest + most-referenced), surfaces orphans, contradictions, and knowledge gaps, and — when allowed — auto-improves a budget-capped set of pages and writes exactly ONE git commit so the user can accept or reject the run via time-lapse restore. Budget-capped by design (default $2.00; a typical run is ~11 LLM calls ≈ $0.005–$0.01 on a tight cap).

Scoring dimensions: recency/freshness, citation quality, wikilink density, category coverage, TLDR/summary quality.

Trigger — invoke this skill when

  • "Improve / clean up / tidy / polish my wiki" · "make my notes better"
  • "What's weak / stale / orphaned in my vault?" · "score my wiki" · "find gaps"
  • "Find contradictions" · "which pages need work?"
  • "Set up the nightly self-improvement" / "run the Observer"

Do not invoke to add new content (that is wikimem-ingest-pipeline) or to answer a question from saved knowledge.

Steps

  1. Resolve the vault:
    VAULT=$(find . -name "AGENTS.md" -maxdepth 3 | head -1 | xargs dirname 2>/dev/null || echo ".")
  2. Always observe before improving (read-only, $0): get the report first so the user sees the diagnosis before any spend or change.
    wikimem observe --vault "$VAULT" --max-pages 100        # scores + orphans + gaps, no writes
    wikimem observe --vault "$VAULT" --json                  # same, machine-readable
  3. Present the diagnosis — avg score, weak pages (< 60%), orphans, knowledge gaps, top recurring issues. THEN ask before spending: "Auto-improve the N weakest pages? (uses LLM, budget-capped)".
  4. Improve, budget-first, on approval. Two equivalent entry points:
    # Observer with auto-improve, hard budget + page caps (preferred — explicit caps)
    wikimem observe --vault "$VAULT" --improve --max-improvements 5 --budget 0.50
    
    # Council-style improve against a quality threshold
    wikimem improve --vault "$VAULT" --threshold 80          # dry preview first:
    wikimem improve --vault "$VAULT" --threshold 80 --dry-run
    Each improve run writes one commit — keep it that way so it stays reviewable.
  5. Show the delta and offer to accept/reject:
    wikimem status --vault "$VAULT"     # new avg score, orphans resolved
    wikimem history --vault "$VAULT"    # the Observer's commit; revert if unwanted

Scheduling the nightly loop

# 3am daily — observe + improve up to 5 pages under a tight budget
0 3 * * * cd /path/to/wiki && wikimem observe --improve --max-improvements 5 --budget 0.50

Use --budget and --max-improvements on the cron path; an uncapped nightly run can spend.

Expected output

Observer Report — 2026-06-06
Pages reviewed: 47/47   Avg score: 6.2/10
Weak (<60%): 8    Orphans: 3    Gaps: 5    Contradictions: 1
Top issues: missing TLDR (12), no tags (8), low wikilink density (6)

[after --improve] Improved 3 pages, $0.41 spent (cap $0.50), 1 commit written.
Accept this run, or `wikimem history` → revert?

Always report: avg score (before→after), what was changed, dollars spent vs cap, and that one commit was written (so it's reversible).

Anti-patterns

  • Auto-improving without showing the read-only observe diagnosis first.
  • Running the nightly cron without --budget / --max-improvements caps.
  • Writing more than one commit per run (breaks clean accept/reject).
  • Treating Observer output as final truth — it is a reviewable suggestion, revertible via wikimem history.

Related

ResourcePath
Observer enginesrc/core/observer.ts · src/core/observer-patterns/
Improve (Council)src/cli/commands/improve.ts → src/core/improve.ts
Observe commandsrc/cli/commands/observe.ts
History / revertsrc/cli/commands/history.ts → src/core/history.ts
Slash commandtemplates/claude-commands/wikimem-improve.md

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.