Corp-OS

What it is

Corp-OS is a Claude plugin: 23 skills that operate on a folder of markdown files on your own disk. The folder is the knowledge base. The skills are what put things into it, turn them into statements you can cite, get them back out with their provenance attached, and take things out again when they stop being true.

There's no database, no server, and no account. If every part of this disappeared tomorrow you'd still have a folder of markdown you could read with cat in ten years.

The problem it's built around

Most personal knowledge systems are organized by subject: a folder per topic, a note per person. They only ever grow. Nothing in them expires. After a few months nobody trusts them enough to look.

The notes aren't wrong, exactly. You just can't tell which ones are. A pricing note from March reads exactly like a pricing note from last week, and the system has no opinion about which one you should believe. So you stop believing any of it, and the thing you built to save time becomes a place you visit to confirm what you already remembered.

Corp-OS is built to know when it's out of date and say so.

Five things that aren't configurable

Almost everything about Corp-OS is declared in a config file. Layer names, label vocabularies, how long things stay fresh, how strict the review step is, even the organizing idea itself. Every skill reads that file before it does anything, and all of it is meant to be changed.

Five properties aren't configurable, because everything else rests on them.

A day with it

Something gets said in a meeting. It goes into the raw layer, either pulled from a registered source or handed over directly, as it was said, not summarized. Later you work the queue. Each candidate becomes a proposal with its kind, its confidence, and a verbatim citation attached, and you confirm, decline, defer, or modify. Declines are kept. The record of what you chose not to know turns out to be useful surprisingly often.

Then you get things back out. A question gets an answer with citations. A recurring brief says what moved, what needs a decision, and what went stale. A dashboard is a page you come back to, built by a script that counts what's on disk, not by a model writing numbers into markup.

Once a month or so, you sweep. Claims past their window, claims never verified, contradictions, and assumptions that got promoted to facts when nobody was looking.

What building it taught me

Past a certain point, more instruction stops buying reliability

The redaction skill is supposed to write two files: the cleaned copy and a private log of exactly what was removed. Across five test runs it produced that log under four different names, and once not at all. The instruction to write it was there, it was concrete, it was explained, and I'd already strengthened it twice.

The retention-delete sequence was the same story. It held at 67% after two instruction passes, the second of which said never edit the original into a tombstone in as many words, and one run in three still did exactly that.

So the step stopped being something to remember. A script now writes both files together and refuses to write one without the other. Another does the delete sequence in the right order. With the script, 67% became 8 out of 8.

The rule I took from it: a step that has to happen every time, that nothing else will catch if it's skipped, belongs in code, not in an instruction. Eleven scripts exist for that reason. None of them exercises judgment. That stays with the person.

The audit has to be able to say no

Corp-OS organizes work around jobs to be done. That's its best idea, and it's wrong for some people. It pays off when the same questions get re-asked and the same evidence re-gathered. It costs more than it returns when the work is mostly reference accumulation.

So the audit skill runs a test before recommending it: cluster the existing material into candidate jobs without looking at the subject taxonomy, then compare. If the clusters just reproduce the taxonomy that already exists, the material is subject-shaped, and the audit says to leave the jobs layer off.

What the tests found

There are three harnesses at three different costs. A loop you can run in a minute is one you stay inside. A thirty-minute one is a loop you leave.

The first real conformance run found the intake skill doing four of its five required outputs, four runs out of four, with the fifth missing every time. It found a four-release-old contradiction where the spec said raw files are never edited while three skills told the model to edit them. Nobody had noticed, because you read whichever one you arrive at first.

Then it found something worse about itself. Every conformance figure before v0.11.0 was void. The harness auto-approved file edits and nothing else, so not one shipped script had ever run inside a test. The file-level results were real, but what produced them was never measured, because a model told to run a script and blocked from doing so writes the result by hand. I spent six runs and three instruction passes chasing a failure that was the instrument the whole time.

The best one came last. A test written to check something else entirely found that the skill whose whole job is removing stale knowledge had never had a review gate, in any release, going back to the first. Three of four runs rewrote the derived layer with no proposal behind it, one of them across fourteen files. I'd read that skill a dozen times and never caught it. One run of a test did.

What still fails

Every skill now has a conformance case, and the suite figure is 203 of 208 checks across 28 cases, one run each. The five that failed are on the record. One was the harness asserting the wrong thing (it read the OS's own capture rule as a fabricated source), and that assertion was replaced. Four are real, in two skills. The guide skill opens a decision itself instead of handing it to the decision skill, a hand-off that passed two releases ago and has regressed since, and I haven't diagnosed why. And recall dropped a load-bearing sensitive fact, which has scored one in four, then seven of seven, then this. That's the highest-stakes check in the suite, so it stays at the top of the backlog.

A wording pass meant to improve a hand-off once measured 0 out of 2 and got reverted.

When an assertion turned out to be wrong about the skill, and not the other way around, it got corrected on the record with the evidence attached. That happened eight times.

Measure what a run costs, too

The same instinct applied to the bill. In a real session breakdown, 54% of tokens went to the per-turn prefix (the system prompt and every loaded tool schema, re-sent on every turn), and reading files was under 9%. So the expensive things are turn count and what's loaded, not what a skill reads. Filing forty items moved from forty turns of arithmetic into one script. Measured against a real 852-claim OS instead of the fixture, the per-run pre-flight floor went from 9,508 to 5,501 tokens, and one generated index went from 14,943 to 244. The things that didn't save money are written down next to the ones that did.

Confidence was three questions in one field

Confidence started as a single value, and it was answering three unrelated questions at once: how faithful is the recording, how many independent sources exist, and is this contested.

Measured in a real corpus: 599 of 836 entries sat one rung below the top because they were single-source summaries. Their full transcripts were still fetchable through the same connector that produced the summaries. One call. Zero had taken it, because a ceiling you could lift looked exactly like one you couldn't.

Splitting the medium out into its own field turned that into a sortable list of entries that are one call away from being stronger.

Sensitivity is two questions too

There's what must not leave, and there's whether the system can reason correctly without it. Collapsing those into a single flag meant quarantining everything sensitive, which sounds safe. It isn't. When sensitive material is load-bearing, removing it from the working set doesn't produce a gap. It produces a confidently wrong answer with nothing in it to signal the omission.

Load-bearing sensitive material now stays where the system can see it, marked, and gets stripped at the boundary where things leave. That boundary is the only place confidentiality was ever enforced anyway.

Hand-written counts go stale

This project has caught that same defect five times: a file saying "both shipped scripts" three releases after there were four, a hard-coded version string that went stale within one release, a version recorded in six files with six different values, a layer counted wrong for five releases, and two README files stating a skill count that was four short.

So the reference page listing every skill is generated from the plugin at build time, and the build fails if it's drifted. The counts in the prose are checked against the directories on disk. The only thing declared by hand is the judgment a machine can't derive, and the generator refuses to run until a person has supplied it.

Who it's wrong for

If your work is mostly reference accumulation, or is organized around long-lived subject areas that don't change, this will cost more than it returns, and the audit will tell you so.

It assumes one operator. Sharing is an export: there's a step that produces a cleaned copy along with a private log of exactly what came out. That's deliberate, but it means this isn't a team wiki and doesn't want to become one.

And the setup interview takes fifteen to twenty minutes. That's the deliverable as much as the folder is. A scaffold built without it is a generic notebook that gets abandoned in a month.

Try it

Install it as a Claude plugin:

/plugin marketplace add brentgann/corp-os
/plugin install corp-os@brentgann

Then ask for Corp-OS setup, or run /corp-os.

Updating has two halves. /plugin marketplace update brentgann replaces the skills. Asking for corp-os-upgrade brings your own folder in line with them, because every Corp-OS carries its own copies of the shipped scripts so it keeps working when the plugin isn't loaded.

The source, the architecture record with every decision and its reasoning, and the eval results are all on GitHub. MIT licensed. The diagrams are also available as PDFs:architecture andskill map.

Corp-OS v0.27.0: 23 skills, 8 slash commands,18 scripts, 14 reference specs, 5 invariants. Routing accuracy 100% across 77 queries at 3 repeats. Conformance 203 of 208 checks across28 cases and 23 of 23 skills, one run each on 2026-09-10, so a baseline, not yet a rate. Current as of September 2026.