Turning TIL into Reusable Knowledge/til-to-knowledge

Here's the problem

TILs pile up, but knowledge often doesn't.

Thinking about why: a TIL is essentially a record of "what happened that day on that project." It's tightly bound to context. So when you reread it a month later, you can't remember the situation and it's useless anywhere else.

/til-to-knowledge is a command that closes that gap. It takes a day's TIL, pulls out the CS and web concepts that hold anywhere, and writes each one up as a complete study document.

How it works

1. Input — it reads wiki/todayILearned/{date}.md from the Obsidian vault. Leave the date out and it takes the most recent TIL.
2. Extraction — it derives study topics from the TIL. The question matters here: not "I fixed this bug today," but "what's the general principle behind this bug?"
3. Dual recording — the same knowledge gets converted into two formats.
   • Vault wiki/cs/{domain}/ — one-line definition / why it matters / key concepts / diagnostic questions / prescriptions. It links back to the TIL note with a wikilink.
   • Blog content/knowledge/{category}/ — a public document that satisfies a Zod schema. The Knowledge section of this site is that output.

The two systems differ in both format and taxonomy, so this is a conversion, not a copy. Vault documents have no frontmatter at all, and blog documents carry the rule that directory name === frontmatter category.

The most important rule: strip confidential material

A TIL contains company project names, paths, and numbers verbatim. But the output of this command is meant to be public.

So the TIL is used only as input for extracting concepts, and the output gets rewritten like a textbook. Reading the result, you should not be able to tell which company or which project it came from. Project anecdotes and measurements are never quoted; where an example is needed, it becomes an anonymous one like foo or example.com.

The other rule is no stubs. "A TODO document to fill in later" never gets created. An empty shell is a broken promise in a knowledge graph. And honestly, nobody ever fills them in.

Where it sits in the pipeline

The session records and daily TILs accumulated by /agent-memory-log are this command's input, and the knowledge documents produced here become the basis for blog posts.

In [record → knowledge → writing] it's the middle stage — the place where context-bound records get promoted into knowledge that reads fine without the context.

What I took away

The bottleneck in knowledge management turned out to be conversion, not collection.

If records pile up but knowledge doesn't, the missing step is rewriting records as general concepts. And doing that conversion by hand every time never lasts — so I baked the rules (strip confidential material, no stubs, taxonomy invariants) straight into the command.