القائمة
Fold new material — inbox captures and named raw sources — into the karpathy-style wiki as atomic, cross-linked pages. Use when draining the inbox or adding a source.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
Drive a set of issues or a spec to done as an orchestrator: scout context, delegate each unit's implementation to a subagent, review, and commit per unit.
Converge a repo's convention docs to this workflow's — the counterpart to `setup-matt-pocock-skills`. Docs only; run once per repo after the skills are installed.
Review documentation for document discipline — docstrings, comments, and prose (markdown, ADRs, README) — in a subagent. Use when the user wants to review the docs of a change (a diff), or to audit the docs of named files or the whole repo out of band. Separate from code review, so it runs on its own.
Audit the karpathy-style wiki for decay — orphans, dead links, contradictions, staleness. Use for an on-demand health check of the vault.
Consult the karpathy-style wiki for knowledge it has already curated — read-only. Reach for it mid-task when you need a concept, convention, tool reference, or past decision the wiki would hold; prefer it over re-deriving. Not for general knowledge, live code state, or facts read straight from the repo.
Present the open issues in dependency order and reason about what to implement next — which are ready, which are blocked, which are underspecified. Use when the user or an orchestrator asks what to work on next, what's blocked, or wants the dependency-ordered backlog before picking work.
| name | wiki-ingest |
| description | Fold new material — inbox captures and named raw sources — into the karpathy-style wiki as atomic, cross-linked pages. Use when draining the inbox or adding a source. |
Turn raw material into atomic, interlinked wiki pages without duplicating what's already there. This is the heavy operation; it owns all writes to the wiki layer.
Load the rules first: vault_read "_schema.md" — layers, page types, frontmatter, controlled
tags, provenance, and autonomy. Every vault touch goes through the obsidian MCP server (its
vault_* / search_* tools), which reaches the live vault by paths relative to its root — never a
filesystem path. The README covers connecting it.
vault_list "inbox/", then vault_read each item.For external material, vault_write "sources/<slug>.md" with the content (or a faithful excerpt +
URL) and never edit it again; add a source-type stub. A personal idea from the inbox needs no source
file — record its origin in provenance instead.
Break the material into atomic, evergreen ideas. For each idea:
search_simple (and search_query for tag/field, or inbound links via
{"in": ["<path>", {"var": "links"}]}) to find an existing page first.vault_patch (surgical — target one heading, block, or frontmatter
field) or vault_append, not a whole-file rewrite. If the new info contradicts the page, stop
and flag — do not overwrite (approval-gated per the schema).vault_write "<type-dir>/<slug>.md" — one atomic page of the correct type, full
frontmatter, status: seed, linked to its source._schema.md (extracted default, ^[inferred], ^[ambiguous]).New pages accrete into themes. When a cluster has grown enough that home no longer routes to it
well, extend the theme's map — add the new page to the relevant MOC, or split a crowded cluster
into its own (the mint trigger lives in _schema.md). Minting a map is bottom-up and autonomous —
it's a new page; don't design a hierarchy ahead of the pages.
Once an inbox item is fully folded in, vault_delete "inbox/<item>" — git is the trail. This is the
one autonomous deletion; it never touches sources/ or wiki pages.
Done when every idea in the material is reflected in a page and linked to its source, and every processed inbox item is removed.