I'm running a startup incubator in Suriname and for a young "AI for geology & mining" startup I'm trying to get ICM in the mix: Workflows - for the business aspects design - design, coding and maintenance of the software (front end/back-end) - The actual AI engine running the service, setup, training, optimization, uptime etc. - Monitoring users, errors, UX - Monitoring business progress/KPI's/CAP tables for Stock Splits Anybody knows how best to structure all of this? Best practices? Oh and I manage currently 4 active startups

Have been fiddling with ICM, Hermes, GSD, BMAD, taskMaster etc. They all sound perfect and logical on their own but feel "out of control" somehow so put it inside of ICM. I tried to make sense of them all and cook up an ICM here: .icm/ ├── CLAUDE.md # Upgrade safety gates, rollback hooks, and CLI routines ├── .icm.env # NEW: Central environment vars feeding variables to scripts │ ├── 00-gsd-wave-governor/ # CONTEXT & SPREAD CONTROL │ ├── contract.md # Rules: Blast-radius mitigation, branch naming, strict file locks │ └── active_wave.md # Tracks the current migration delta and target files │ ├── 01-discovery-and-party/ # LEGACY ANALYSES & DEBATE │ ├── contract.md # Rules: Analysis must document side-effects before code editing │ ├── codebase_discovery.md # Static analysis logs, dependency graphs, and tech debt maps │ ├── 00-party-room/ # BMAD Party Mode: "Refactor vs. Wrap" architectural battles │ │ ├── system_prompt.md # Personas (Winston/Arch, John/PM, Safety-QA Specialist) │ │ └── migration_consensus.md # Binding agreement on the upgrade strategy & fallback path │ └── 01-feedback-loops/ # Regression and breaking change post-mortems │ ├── 02-taskmaster-decomp/ # MIGRATION STEP DECOMPOSITION │ └── todo/ # Micro-tasks focused on localized refactoring steps │ └── 03-bmad-assembly-line/ # IMPLEMENTATION & REGRESSION TESTING │ ├── 01-architect-spec/ # BMAD Role: Designing code deltas & backward compatibility │ ├── 02-dev-workspace/ # BMAD Role: Executing precise, isolated modifications │ └── 03-qa-sandbox/ # BMAD Role: Core regression suite, smoke tests, validation

Everyone gets something wrong the first time. Vote below, then drop your mistake in the comments so others can learn from it.

A question for those using ICM to provide software or consulting services: When you work with multiple customers, does one ICM system support all of them, with separate customer configurations, requirements, data, and outputs? Or do you create and maintain a separate ICM structure for each customer or software product? I’ve been thinking about this through the way I create my own products. I reuse many of the same standards, checks, scripts, and production methods, but different product types may still need different schemas and workflows. A devotional is not built exactly like a prayer card set, even though they share part of the same underlying system. I’m curious whether software providers (or consultants) approach this similarly. Do you maintain a common core and adapt it for each customer, keep every customer implementation completely separate, or use some combination of the two? I’m still learning how others structure this, so I would genuinely appreciate hearing what has worked for you—and where separation becomes important.

Two days ago Jake dropped ICM Architect. I've been running my own folder-first setup for months, so instead of just installing it I audited my system against his, point by point, and let the loser lose on each point. Thank you Jake. The tool won in places I didn't expect, and my setup is better this week than last week. The honest before and after: Before: my runs were verified hard, but the catalogue layer (the indexes and registries that route everything) was checked by nothing but good intentions. Auditing against his invariants surfaced four live drifts I didn't know I had, two of them actively routing to a skill that no longer exists. After: that layer now has its own frozen referee, armed against the real messes it caught, before they were fixed. Before: counts and values copied into routing files. My registry said 21 folders, the disk had 22. One next-step note froze a superseded number for six weeks. After: one home per fact. Routing files point at the thing that owns the number; nothing computable gets hand-written twice. Before: "the operator reviews it" as a gate. After: every human gate is a named act: compare this line to that official document. If the act can't be named, the gate isn't real. Before: two shapes in my toolbox, both pipelines. A record that accumulates had no name, so one workspace stayed flat for two months. After: the intake now asks his question, what is the repeating unit of work, with the five forms as a menu. Plus the ladder: chat, then a saved prompt, then a folder. Climb on repetition, not on excitement. One thing travelled the other way: the reverse walk test (who points INTO your folder from outside, before you move anything). PR as promised: github.com/RinDig/icm-architect/pull/4 And the audit only worked because every step got checked by something that wasn't me. The tool that finds your rot is worth more than the tool that agrees with you.