agentsclimarketplace

Llm wiki

Skill brantshin/super-dev/skills/llm-wiki

Evidence-driven engineering harness for autonomous coding agents

Install
npx -y skills add brantshin/super-dev --skill llm-wiki

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

2 things to look at

  • 13 days oldThe repository was created 13 days ago. New is not bad, but a brand new repository carrying a familiar-sounding name is the shape a typosquat arrives in, and there has been no time for anyone else to find a problem with it.
  • 1 stars1 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

Maintain a Git-native, LLM-curated project knowledge base that compounds across tasks. Use when initializing or restructuring a project Wiki, staging source material in an inbox, ingesting verified documents into cross-linked Markdown, querying project knowledge with source paths, promoting reusable findings from engineering work, or linting indexes, metadata, provenance, links, and stale content. Keep transient task state and private memory outside the Wiki.

SKILL.md

7.4 KB, ~1.4k tokens by cl100k_base, as published. Nobody here has run it

LLM Wiki

Build and maintain a persistent Markdown knowledge network instead of rediscovering the same project facts from raw documents in every session. Follow the pattern described by Karpathy's LLM Wiki, while letting each repository define its own schema and privacy boundary.

Preserve the knowledge boundary

  • Treat raw sources as immutable. Add a new source or correction record instead of rewriting history.
  • Treat the Wiki as synthesized project knowledge, not as a dump of chats, logs, task todos, or copied documents.
  • Treat the Wiki-local agent instruction file (AGENTS.md for Codex, CLAUDE.md for Claude Code) as its schema: topology, naming, required metadata, and maintenance rules.
  • Keep active task state in the task Spec. Promote only verified, reusable, repository-appropriate knowledge.
  • Keep credentials, private messages, user preferences, system memory, production payloads, and personal paths out of shared project knowledge.
  • Persist only repository-relative paths, sanitized logical aliases, or content hashes in Wiki pages and maintenance logs. Keep machine-local absolute paths in the uncommitted task baseline only.
  • Confirm the target repository accepts Wiki writes before modifying it. A useful finding does not by itself authorize a commit.

Read wiki-contract.md whenever deciding where information belongs or how pages must be structured.

Select one operation

OperationResult
initCreate a new Wiki schema, indexes, log, inbox, and initial sections
inboxStage material for later compilation without treating it as accepted knowledge
ingestCompile one or more sources into pages, links, indexes, provenance, and log entries
queryAnswer from the Wiki with concrete page paths and freshness caveats
lintAudit health without modifying the Wiki; finish clean or completed-with-findings
lint-fixRepair authorized findings, validate the result, and record the maintenance operation
restructureChange topology without losing links, history, or source attribution

Do not combine a broad restructure with unrelated content ingestion unless the user explicitly requests both.

Run the control loop

  1. Read the repository instructions, the Wiki-local agent instruction file, root index.md, and the smallest relevant section indexes.
  2. State the requested operation, target root, source root, read or write scope, privacy boundary, and completion evidence.
  3. For a write operation, record the repository baseline, dirty and untracked state, expected files, and initial hashes. Stop on overlapping user changes.
  4. Inspect current pages before adding content. Reuse or update existing concepts instead of creating near-duplicates.
  5. Preserve raw material and source attribution.
  6. Make the smallest coherent set of edits. Re-read a shared index, map, or log immediately before writing it and stop on baseline drift.
  7. Validate pages, links, metadata, provenance, privacy, and the exact diff before appending a completed maintenance log entry.
  8. Report what changed, which sources support it, what remains uncertain, and whether any knowledge candidate was intentionally not synced.

Read the Write baseline gate in maintenance-guide.md before any operation that changes Wiki or inbox files.

Initialize

Confirm the Wiki root and immutable source root, then read init-guide.md. Create only sections justified by the current project; avoid empty taxonomies copied from examples.

Minimum initialization evidence:

  • The Wiki-local agent instruction file defines the three layers and maintenance rules.
  • README.md, index.md, log.md, and inbox/ exist.
  • Each initial section has an index.md.
  • Links resolve and content pages satisfy the metadata contract.

Stage inbox material

Add a recognizable source note to inbox/ without rewriting it into project truth. Attach the required intake fields for capture time, origin, owner, intent, target, and status. Do not update indexes or claim ingestion until the full ingest operation completes.

Read the Inbox section of maintenance-guide.md before moving or deleting staged material.

Ingest

Compile source material into the smallest set of existing or new pages that preserves meaning and provenance. Reconcile contradictions explicitly; do not silently replace an older conclusion.

An ingest is complete only when pages, section indexes, the global index, cross-links, optional provenance maps, and log.md agree. Read maintenance-guide.md for the full quality gate.

Query

Start from index.md, follow only relevant pages and their links, and cite concrete repository paths in the answer. Name the date or freshness limit for time-sensitive facts. If the Wiki does not cover the question, say so instead of filling the gap from assumption.

Propose new synthesis as an ingest candidate. Do not mutate the Wiki during a read-only query unless the request also authorizes maintenance.

Lint, repair, or restructure

Treat lint as report-only by default. Read maintenance-guide.md, run the checks that fit the repository, and finish as clean, completed-with-findings, or blocked. Do not repair files or append log.md unless the user or repository also authorizes maintenance writes.

For lint-fix or restructure, apply the write baseline gate, change only the authorized files, validate first, and append a completed log entry last. Preserve redirects or update all inbound links when moving pages. Unresolved findings may remain after a completed audit; they block a repair operation only when its Done Contract requires them to be fixed.

Stop conditions

Stop and report the exact gap when:

  • the Wiki root, source root, schema, or write authority is unclear;
  • source material contains secrets, private identities, production data, or content unsuitable for the target repository;
  • a proposed page conflicts with verified knowledge and the contradiction cannot be resolved from available sources;
  • an expected write target already contains overlapping dirty changes or changes after its baseline hash was recorded;
  • moving or deleting an inbox or raw-source file could lose the only copy;
  • a restructure would break inbound links that cannot be enumerated;
  • validation cannot distinguish the new Wiki state from stale or unrelated content.

Reference map

  • wiki-contract.md: knowledge layers, information boundaries, topology, naming, metadata, links, and provenance.
  • init-guide.md: initialization sequence, minimum directory shape, and schema template.
  • maintenance-guide.md: inbox, ingest, query, lint, validation commands, and common failure modes.

Gives 0 of the 12 instructions most memory context skills give in ~1.4k tokens

Counted across 674 of the 847 authors here whose files we hold, read 2026-08-06

  • inform the user when setup is completein 21 of 674, across 6 files
  • confirm the draft with the user before writingin 21 of 674, across 6 files
  • update the agent skills block in place if it existsin 21 of 674, across 6 files
  • present findings to the userin 20 of 674, across 5 files
  • write the three docs files from seed templatesin 20 of 674, across 5 files
  • ask the user about each decision one at a timein 19 of 674, across 4 files
  • edit CLAUDE.md if it existsin 18 of 674, across 3 files
  • explore current repo statein 18 of 674, across 3 files
  • do not overwrite user edits to surrounding sectionsin 18 of 674, across 3 files
  • back up the original file before overwritingin 16 of 674, across 8 files
  • keep the memory index under 200 linesin 15 of 674
  • Provide actionable steps and verificationin 13 of 674, across 2 files

Said here and by no other author read

  • Treat raw sources as immutable
  • Keep active task state out of the Wiki
  • Keep credentials and private data out
  • Persist only repository-relative paths
  • Confirm repository accepts Wiki writes before modifying
  • Record repository baseline before writing

Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.

Keep looking

Skills are one crate of 328,083. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.