AIS-OS: a Claude Code and Codex starter kit built around the Three Ms and Four Cs

The problem AIS-OS addresses, and who it is actually for

Most people who use Claude Code or Codex end up with the same mess. The agent can read files, but it has no idea which files matter, what the business does, or where the answer to a question lives. You paste context in by hand, session after session, and nothing accumulates. AIS-OS is a repository of Markdown manuals, skill packages, and scripts that gives the agent a fixed place to look.

The README names the audience directly: solopreneurs, small business operators, managers, creators, and AI consultants who are building automations. It also states that the kit mirrors how members of the AI Automation Society run their businesses, while insisting the structure is universal. Those two claims sit in tension. The folder names and the onboarding interview are generic, but several conventions (the trademarked Three Ms and Four Cs, the AIS abbreviation itself) come from one community's vocabulary. If you are outside that community, expect to spend the onboarding interview translating your own work into someone else's categories.

The litmus test the README sets is unusually concrete for a starter kit: while you are away from your desk, the system observes one real-world event and produces an output faster and more accurate than you would produce yourself. That is a high bar, and it is the right one to judge the kit against, because everything in the repository is scaffolding for it rather than the thing itself.

How the Four Cs map onto files and skills

The architecture is described as four layers, and the repository layout reflects them. Context lives in context/, decisions/, and archives/, plus the shared CLAUDE.md and AGENTS.md manuals at the top level. Connections are recorded in connections.md, which is the file /link writes to when you add a project, folder, or source. Capabilities are the skill packages under .claude/ and .agents/. Cadence is the part that runs without you, and the README is explicit that it comes last, with the warning not to automate workflows that do not already work manually.

The dependency graph is the sharpest design decision in the kit. Context is described as non-skippable, Connections and Capabilities can be built in parallel, and Cadence is terminal. That ordering is a real constraint rather than a suggestion, because the audit rubric rewards evidence: the README says missing or unverified layers cap the total score, and that installed skills cannot compensate for absent connections or execution history. In other words, you cannot buy your way to a good audit by adding more skills.

The second framework, the Three Ms, is about how you think rather than what you build: Mindset, Method, Machine. The README defines Method as a sequence (find the constraint, eliminate or automate or delegate, map the process, pick an autonomy level, tie it to a KPI) and Machine as a set of heuristics including the Lego Principle, the Validation Chain, and the Kill Switch. The /level-up skill walks through all three weekly. Whether the framing helps is a personal question; the mechanism it drives is one shipped artifact per run, which is at least measurable.

Installing AIS-OS and running a first real audit

The README does not give a clone command, a package name, or an install script. There is no published package and no release archive in the repository metadata. What the README does specify is the entry point: run /onboard on day one, immediately after clone. The repository is a set of files you place where Claude Code or Codex can read them, and the skills are invoked as slash commands.

A minimal sequence, following the README's own ordering, looks like this:

git clone https://github.com/nateherkai/AIS-OS.git
cd AIS-OS

After cloning, the README says to run the onboarding skill first. It is a seven-question interview that generates the Day-1 file set and fills the shared CLAUDE.md and AGENTS.md manuals.

/onboard

Once onboarding finishes, the next step the README recommends is verification rather than more building. The audit skill checks routing, freshness, and Claude/Codex compatibility, then saves a dated report.

/audit

What you should see after /audit is a Markdown file in audits/ with a date in its name, containing five retrieval probes, stale-cache and source-authority checks, a comparison against prior reports, and up to three prioritized improvements. The README states that findings keep their IDs across runs and are tracked as new, still open, resolved, reopened, not rechecked, or no longer applicable, and that resolution requires fresh evidence. If your report shows probes that do not resolve, that is the system telling you your Context layer is thin, not that the audit is broken.

The audit rubric is the most opinionated part, and the most fragile

Rubric v2 awards points for evidence rather than folder counts, API keys, or skills with names like "daily." That is a deliberate rejection of the vanity metrics most starter kits ship with, and it is the reason the audit report is worth reading at all. The score is described as a measure of verified operational reliability, not overall usefulness, which is an honest scoping of what a script can actually check.

Two limitations follow from that. First, the README warns that old rubric scores need a new baseline, meaning any score you recorded before the rubric change is not comparable to one you get now. If you have been tracking a number, that number moved for reasons unrelated to your system. Second, the success indicators the README describes are explicitly not KPIs: a teammate asking your system a question, fewer new tabs, and no longer rehearsing business facts from memory. None of those are observable by an audit script. So the kit has a quantitative check that measures retrieval reliability and a qualitative set of felt indicators that measures whether the thing is changing your work, and the two can disagree. A high audit score with none of the three indicators showing up means you built the folder structure and not the habit.

The audit also distinguishes confirmed defects from verification gaps, intentional runtime differences, and optional improvements. That taxonomy is useful precisely because it stops the report from treating every unverified item as a failure, but it also means you have to read the categories rather than the total.

Where AIS-OS is the wrong tool

The kit assumes you already have Claude Code or Codex installed and are comfortable working in a terminal or an agent session. There is no web interface, no hosted service, and no homepage. If your team works in a browser and expects to share a knowledge base with permissions and roles, this is not that. The README's own scaling story is that each operator runs a personal AI OS and the company becomes AI-ready as a side effect, which is a bottom-up model, not a replacement for a shared documentation platform.

A second boundary is the Cadence layer. It is the layer that runs while your laptop is closed, and the README places it last and warns against automating workflows that do not work manually. Nothing in the repository description suggests a scheduler, a queue, or a daemon. If your goal is unattended automation that fires on a real-world event, the kit gives you the context and the capability, and you supply the trigger yourself.

There is also a maintenance question worth stating plainly. The last push to the default branch was on 2026-09-07, which is recent, and the repository is not archived. That tells you the project is being touched, not that it has a stable interface. The README already documents a rubric change that invalidated prior scores, so treat the skill contracts as moving.

Alternatives and the difference in approach

The obvious alternative is a plain CLAUDE.md or AGENTS.md file that you write by hand and keep updated. That is genuinely lighter: one file, no skills, no audit history, no rubric. The difference is that a hand-written manual has no verification step, so it drifts silently as your business changes, and you find out it is stale when the agent gives you a wrong answer. AIS-OS adds the audit loop and the dated report trail specifically to make drift visible. If you have never had a problem with a stale manual, you do not need the loop.

A second alternative is a hosted retrieval product that indexes your documents and answers questions over them. That approach puts the retrieval machinery outside your repository, which means less to maintain and more to trust. AIS-OS keeps everything as files in your own project, so the routing decisions are inspectable and versionable, and you can read exactly why the agent looked where it looked. The trade is that you own the upkeep of connections.md and the context files.

The kit also ships /3d-brain, which builds a local 3D globe from selected files with search, note reading, Cinema, and a branching growth replay. That is a visualization over your saved knowledge rather than a retrieval mechanism, and it is the one component whose contribution to the litmus test is not obvious from the documentation.

Licence, upgrade cost, and what to check before adopting

The README describes the kit as free and MIT-licensed, but the repository metadata reports the licence as NOASSERTION, and the top-level entries include a file named LICENSE. Those two signals do not agree. Read the LICENSE file before you build anything commercial on top of it, and note that the README separately marks the Three Ms of AI and the Four Cs of an AI OS as trademarks of Nate Herk with a 2026 copyright notice. A permissive licence on the code and a trademark claim on the framework names are different things, and the README does not explain how they interact. This is not legal advice; it is a reason to read the file rather than the summary.

Upgrade cost is the more practical concern. Because the audit rubric changed once already, and because the README says old scores need a new baseline, you should expect to re-run /audit and re-read your history after any update rather than comparing totals across versions. The report format is designed for that: findings keep their IDs and carry a status, so a re-run tells you what changed. Budget the time to read the diff, not just the number.

The first thing to verify is whether the five retrieval probes in your first /audit report resolve. That single check tells you whether your Context and Connections layers are real, and it is the prerequisite for everything the kit promises after it.

Editorial conclusion

Adopt AIS-OS if you already run Claude Code or Codex daily and want a repeatable way to make your own business context retrievable, with /audit as the check that keeps it honest. Skip it if you want a hosted knowledge base, a team product, or anything that works without a coding agent installed. Before you commit, run /onboard, then run /audit and read the dated report in audits/ to see whether the five retrieval probes actually resolve against your files. The licence file is named LICENSE but the repository metadata reports NOASSERTION, so read the file itself rather than trusting the README's MIT claim.

Frequently asked questions

Official sources

1. Issues
2. nateherkai/AIS-OS on GitHub
3. README