OrgSmith
CLAUDE.md6 starsChanged 33 days agoApache-2.0View on GitHub
Frontier-model-powered generator of complete synthetic organizations. Read README.md for the product shape and SPEC.md for the current unit of work. - Airlock: Python in orgsmith/ never calls a model and never touches the network. Model touchpoints are exactly the CLI verb pairs --emit-context/--next-batch (writes a JSON work order) and --ingest <file> (validates and merges a deliverable). Skills are the only reader/writer of work orders. - Facts are load-bearing; prose is replaceable. All numbers, dates, ids, names, and relationships come from…
- Installs packages
In this repository4 other files it gives its agents.
- forge-authorSkill
- forge-reviewerSkill
- forge-reviewSkill
- forgeSkill
The file
We split this CLAUDE.md into the rules it gives an agent
5 rules. About 0 are common, 2 are distinctive, and 3 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈2
Distinctive · estimate
This author's own choices. Worth a look.
3
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 15
Facts are load-bearing; prose is replaceable: All numbers, dates, ids, names, and relationships come from the deterministic ledgers.
- Distinctive: line 31
Committed fixtures are frozen: Never edit or regenerate a committed org's ledgers, manifest, or authored prose.
- Very specific: line 70
Re-emission order: when a derived artifact moves: charter for every org (if a charter field was added), then report, then …
- Very specific: line 82
Always python3 -m venv .venv.
- Distinctive: line 102
Commit in small increments with tests in the same increment.
≈ “Common” is an estimate: at least 1 in 5 of the 26,980 CLAUDE.md files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
OrgSmith project conventions
What this is
Frontier-model-powered generator of complete synthetic organizations. Read README.md for the product shape and SPEC.md for the current unit of work.
Hard rules
- Airlock: Python in
orgsmith/never calls a model and never touches the network. Model touchpoints are exactly the CLI verb pairs--emit-context/--next-batch(writes a JSON work order) and--ingest <file>(validates and merges a deliverable). Skills are the only reader/writer of work orders. - Facts are load-bearing; prose is replaceable. All numbers, dates, ids,
names, and relationships come from the deterministic ledgers. The model
writes surface prose with
{{fact:...}}placeholders. Never let generated text carry a literal value that the ledger owns. - Resume state is file-derived, never conversation memory. Everything a
stage needs is a pure function of committed files plus
state.json. - Never LLM-grades-LLM in automated test tiers. Model passes happen only inside skills.
orgsmith/schemas.pyis the keystone: ALL inter-stage contracts live there as pydantic models withorgsmith/<kind>@<ver>schema ids.- Additive evolution. New capabilities are recipe knobs that default
off, schema fields that default inert on the existing schema ids, and
randomness drawn only from NEW
seeds.pystreams, so every committed fixture keeps loading, validating clean, and regenerating byte-identical structure. Prove a knob inert against the frozen fleet before any org turns it on. - Committed fixtures are frozen. Never edit or regenerate a committed
org's ledgers, manifest, or authored prose; that takes a fresh,
user-approved carve-out.
PINNED = SLUGS(tests/test_org_regen.py) is enforced fleet-wide and must be green at every commit.charter.json,evals/,acl.json,review/,baselines/,GENERATION-REPORT.md,DATA-CARD.md, and PERMISSIONS.md are derived and may always be re-emitted. Adding a new org is not a regeneration. - Grandfather by charter, never by artifact absence. A validator rule skips visibly only when its recipe knob is off; a knob that is on with its artifact missing is a failure (tamper evidence). A fixture-hosted test whose host is deleted or moves must fail or be re-hosted, never skip into a silent pass.
- Nothing that is not an oracle may gate.
orgsmith/review/structure.py, the unowned-number count, and every board or probe number are measurements: no threshold they produce enters a test tier or a validator rule. Ingest may reject only on an oracle (a ledger fact against the text). - The user-facing product name appears in code only via
PRODUCT_NAMEinorgsmith/__init__.py. The pre-rename working name must not appear anywhere in the repo (enforced intests/test_short.py).
Freeze status
No carve-out is open. The last one (M17e, approved by the user
2026-10-13) regenerated ashcombe-advisory, hollowell-ip and
meridian-actuarial once to close the mail-mention device, and closed the
same day with the fleet re-frozen. Regenerating a committed org's ledgers,
manifest, or authored prose again requires a fresh, user-approved carve-out.
History of every carve-out, and of what each turn did and did not claim, is in
docs/FREEZE-LOG.md. Known residuals are recorded on the data cards and in
BACKLOG.md, never prose-fixed.
Working on the fleet
- Serialization traps.
dump_jsonserializes every model field, so a new field onFact,Engagement, orManifestEntrywrites a key into every committed ledger and breaks the pin: avoid it (M17b put scope facts in the existingfactslist for this reason). A new field on the charter's sub-models rewrites everycharter.jsonand, throughdatacard._knob_rows, every data card; that is derived and allowed. - Re-emission order when a derived artifact moves:
charterfor every org (if a charter field was added), thenreport, thentools/checksums.py, thendata-cardfor every org (the cards quote their own checksum row).emit-schemasafter any schema change. - Experiments run on pinned code. A measurement that spans code changes
runs from a git worktree pinned at its pre-registration commit, with the
grading scripts hashed in the pre-registration (
docs/M17D-OPUS55-PROBE.md).
Environment
- This box runs Python 3.10;
.python-versionsays 3.12. Code stays 3.10-compatible (nomatchon types we ship, no 3.11+ stdlib). - Always
python3 -m venv .venv; run everything via.venv/bin/python. - LibreOffice is required on the generation box for legacy-format
rendering (
legacy_ratiorecipes convert .docx/.xlsx/.pptx to .doc/.xls/.ppt viasoffice --headlessat render time only). Install:sudo apt-get install --no-install-recommends -y libreoffice-writer libreoffice-calc libreoffice-impress, then confirmpython -m orgsmith doctorreportssoffice ok. CI deliberately has NO LibreOffice: validation of every committed fixture (including legacy files) must stay pure Python (olefile, xlrd, stdlib email, python-pptx, pypdf).
Testing
bin/test [short|unit|org](default: all tiers). Marker-based pytest, keyless and offline.orgtier validates the committed fleet undercompanies/.- Skills-in-repo deviation:
.claude/skills/is versioned here because the skills ARE the product, unlike the house norm of global skills.
Git
- Commit in small increments with tests in the same increment. Do not push or modify remote state without explicit user confirmation.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

