I stumbled upon this by accident when I was describing to Claude something I did in another session. Claude opened it up and read for itself. Kind of cool.

@Mira Bradshaw I like the guidance for "low stakes". We do have risk impact, so those identified as low could be candidates for full delegation. I agree on model change. Claude changed to Opus 5 for me (I didn't change it myself). It was like I was talking to someone new that did not act the way I was expecting. I switched back to Opus 4.8 and my old friend returned. 😃

@Janez Gec I agree, I'm not completely a fan of the entire rubric. The risk of fully autonomous is removing the check that says "hey, I'm about to do this in production. It will affect your customers, are you sure my plan looks good?". Even just stopping at a PR review keeps the score at a 2.

To be honest, I have Claude design all my ICM workflows. I just tell Claude to read Jake's paper and what I'm trying to accomplish. Then start using it and iterate until I'm happy.

I found that it's a lot easier to convince a customer by showing them you can solve their problem. For my current client, I never mentioned ICM before they hired me. I told them I could speed up their development process by using AI assisted workflows with human approval at every step. I explained the problems I used to run into with vibe coding and that I finally figured out how to get consistent results. They still don't understand what ICM is, but they are excited for me to continue to implement it in other parts of the company.

🔗 https://github.com/craig-atr/folder-cartographer 🗺️ FOLDER-CARTOGRAPHER — a drop-in Claude folder that walks a body of work someone will change and leaves behind a map a cold reader can wander: a catalog.md (the front door) plus one card per noun. You point it at a repo, a vendor portal, a delivery folder; it inventories the nouns, marks each live / leftover / ghost, and writes cards that say what the thing is, what else moves if you touch it, and the one neighbour everyone wrongly assumes it touches — citing file:line instead of copying the source. Its whole discipline is catalog → one card → stop: it hands you the shelf, it does not photocopy the library. It is not a tour, an audit, or a diagnostician — it marks a ghost, it does not scold it or explain a failure. 🔁 IT WORKS ON ANY FOLDER — PROVEN ON EIGHT REAL CODEBASES — from an Android app to public frameworks, no per-repo tuning. Four are territories I own, with nothing in common: vendor-lilly (a multi-tenancy spine whose payoff is "not every request goes through tenant middleware — these four routes don't"); atomic-tattoo-removal, where the map's reason to exist is that three backends live in one repo and never touch each other (Express booking, Firestore-from-the-browser admin, external CRM); astanza-crm, a big, messy CRM where most of the repo is not the app — a tiny 7-noun spine that marks a superseded server.original.js and the drawer of one-off scripts as leftover and an empty index config as a ghost; and arnold, a Kotlin/Android app, where the map shows interface-vs-impl wired once in MainActivity, quarantines the old Node app as a leftover, and flags a first-launch migrator that is green in tests but called by no production path as a ghost. A reader who assumes "the backend" is one thing, or that every file that runs is live, ships the wrong change; the map is what stops them. And it isn't only proven on repos I own: the same folder maps three public frameworks a judge can clone and re-check — Express (a routing spine), Commander (a CLI parser), Fastify (a plugin system) — plus linkstash, a small self-contained territory shipped inside the receipt so the citation and live-wiring gates run green with no clone at all. Same rules, eight real codebases.

@Jodi Paige-Lee Teamwork 💪🤖