agentsclimarketplace

Mikeross

Skill thicc-patty/mikeross

your documents to a second brain that cites every claim or admits it doesn't know. a Claude Code skill for grounded Obsidian knowledge bases.

Install
npx -y skills add thicc-patty/mikeross

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

One thing to look at

  • 0 stars0 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

Turn documents — especially big OCR'd PDFs — into a grounded, hallucination-proof, beautifully-visualized Obsidian knowledge base. Four modes: `pdf` (slice a long PDF into meaningfully-named chunks filed into folders), `build` (author an interlinked Obsidian KB with per-note source citations so nothing is invented), `ask` (answer questions only from the vault, citing the page or honestly saying "not in the KB"), and `paint` (style the Obsidian graph view to look like a brain / galaxy). Use mikeross whenever the user wants to organize a PDF or pile of documents, build a second brain / knowledge base / wiki / vault from sources, set up grounded notes that cite their sources, do Q&A over their notes without hallucinating, or make their Obsidian graph look good — even if they don't say "mikeross". Named after Mike Ross (Suits): total recall, everything cited.

The file declares its own license as MIT. That is the author’s claim about this one file, and it is not the same thing as the license GitHub reports for the repository, which is listed with the other numbers below.

SKILL.md

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

mikeross — grounded knowledge bases from documents

mikeross turns source documents into an Obsidian vault where every claim is traceable to a page, then makes that vault a pleasure to read and to look at. It is self-contained (Python + pypdf); graphify and an OCR tool are optional accelerators, never required.

Run a single mode, or all for the end-to-end pipeline. The modes share one project: a vault folder. Scripts live in scripts/; the detailed rules live in references/ — read them when a mode needs them.

The two rules that run through everything

  1. Grounding (strict by default). Notes cite their source; answers cite a page or say "not in the KB"; broken source becomes an honest review task, never a guess. Full contract: references/grounding-contract.md — read it before build or ask. --light opts out.
  2. When in doubt, ask. Folder placement, chunk names, an ambiguous figure, strict-vs-light — if the right call depends on the user's knowledge, ask one prepared question instead of assuming. A wrong guess propagates silently; a question costs one turn.

Mode: pdf <file> — slice & organize an OCR'd PDF

Goal: a long PDF becomes a set of meaningfully-named chunks (PDF + Markdown) in sensible folders — the raw material a grounded KB is built from.

  1. Map it (cheap): python scripts/pagemap.py --pdf "<file>" --out pagemap.json. If has_text_layer is false it's an un-OCR'd scan — tell the user to OCR first (ocrmypdf in.pdf out.pdf, optional dependency) and stop.
  2. Plan the cuts (you decide, from the map): read pagemap.json — the per-page headings, keywords, and the outline. Choose semantic boundaries, a clear name per chunk, and a target subfolder. Don't read every full page; the map is enough. Confirm the plan with the user when boundaries/names are non-obvious (when-in-doubt-ask).
  3. Write the plan as plan.json (schema in scripts/split_pdf.py's docstring: source, out_dir, and chunks of {name, start, end, folder}, 1-based inclusive).
  4. Cut it: python scripts/split_pdf.py --plan plan.json. Each chunk yields a split PDF (human-verifiable source) and a .md extract (KB input) with provenance frontmatter.

Mode: build <vault> — author the grounded KB

Read references/kb-structure.md and references/grounding-contract.md first.

  • Cold start: from the chunked sources, author the structure — MOC home + master-file hub (synthesis + ![[ ]] transclusions) + atomic notes (one per real entity, not per page) + glossary + source map + a portable export. Put source_doc/source_pages/confidence frontmatter on every note; tag noisy figures ⚠️ verify against source.
  • Incremental: a doc in _Intake/ → classify with the user (what / where) → build/update notes → log problem zones to _Review Queue.md → present a short verification brief, then stop.
  • --light drops the provenance machinery for casual vaults (say so when you use it).

Mode: ask <question> — grounded Q&A over the vault

  • Retrieve from the vault notes (and a graphify graph if one exists). Answer only from them, citing [[Note]] (p. NNN). Not found → "not in the KB". Noisy figure → flag it.
  • Can't answer / hit a problem zone → say why, pinpoint it, append a - [ ] task to _Review Queue.md, surface inline. Never invent. (Contract §3.)
  • Save each answer as a dated, cited note in Answers/ so it re-enters the KB.

Mode: paint <vault> — style the Obsidian graph

Writes <vault>/.obsidian/graph.json: colour Groups = lobes, a Forces preset = shape.

python scripts/paint_graph.py --vault "<vault>" --preset galaxy   # big vault: multicolour star-field
python scripts/paint_graph.py --vault "<vault>"                   # default: bounded "brain" + gold stem
  • Presets: brain (bounded, gold "stem" = the master/MOC hub) and galaxy (big vaults; many hubs, no single stem). Lobes auto-derive from top-level folders; for a flat vault pass --lobe "file:Keyword=#HEX" repeatedly. Every force/style value is overridable (--repel, --center, --linkdist, --node, --line, --fade, --no-stem). --help lists all.
  • Timing (important): Obsidian overwrites graph.json when the Graph view closes. Write while the Graph view is closed (or Obsidian quit), then open the Graph view. Tell the user.

Mode: all <pdf-or-folder> — the pipeline

pdf → build → paint, pausing at the confirm checkpoints between stages (plan, intake classification, verification brief). The happy path for "here's a document, make me a second brain."

Dependencies

  • Required: Python 3.9+ and pypdf (pip install pypdf). Nothing else for the core flow.
  • Optional: ocrmypdf (only to OCR a scan that has no text layer); graphify (if installed, ask and paint can use its community detection for richer "lobes" — but folder-based lobes work fine without it).

A note on honesty

mikeross's value is that it won't make things up. Lean into that: when the source is thin or garbled, an honest "not in the KB — flagged for review" is the correct, valuable answer. The review queue turns those gaps into the next round of work instead of hiding them.

Gives 0 of the 12 instructions most note taking skills give in ~1.4k tokens

Counted across 686 of the 876 authors here whose files we hold, read 2026-08-07

  • include a visual element on every slidein 44 of 686, across 13 files
  • use wikilinks for internal vault linksin 36 of 686, across 12 files
  • commit to a single visual motif across every slidein 34 of 686, across 9 files
  • use subagents to visually inspect rendered slidesin 31 of 686, across 7 files
  • read pptxgenjs guide before creating presentations from scratchin 30 of 686, across 6 files
  • keep 0.5 inch minimum marginsin 30 of 686, across 7 files
  • re-verify affected slides after every fixin 27 of 686, across 5 files
  • run content QA checks before declaring successin 26 of 686, across 3 files
  • Use Markdown links for external URLs onlyin 26 of 686, across 11 files
  • pick a bold topic specific color palettein 24 of 686, across 2 files
  • read editing guide before editing existing presentationsin 23 of 686, across 1 file
  • use one dominant color across all slidesin 23 of 686, across 1 file

Said here and by no other author read

  • ask one prepared question when uncertain
  • read reference contract before build or ask modes
  • map the pdf before planning cuts
  • confirm non-obvious chunk boundaries with user
  • write plan as plan.json
  • put provenance frontmatter on every note

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.