First run of the setup skill, on the whole company

Situation. This morning’s note ended with a plan: install the pack on one product repository and re-run last week’s review. The pack was built around a simple picture: one repository, one deploy command, one health URL. The first real run ignored the plan and pointed the setup skill at the hardest thing we have instead: the company monorepo, twenty-one repositories stitched together, fifteen of them deployable.

What happened. The setup skill’s job is to work out how a company ships and write it down where every future review can read it. It explored the monorepo, came back with one screen (eight backend services, seven web frontends, the guard hooks each deploy script runs, the health checks, the migration tooling) and asked its one hard question: which command is the only one that should ever deploy to production? The answer it recorded is the rule the team already lived by but had never written into the repository: each product’s own guarded script, never the bare platform tool that skips the checks. Then it asked a second question its own rules forced on it, since it will not create a new instructions file without permission, because it had discovered the monorepo root had no instructions file at all. Everything it was documenting had lived in one place until now: the founder’s private notes. Two files later, the release discipline and eleven hard-won gotchas are in the repository, each one born from a real past incident: a deploy that shipped the wrong working tree, a tool flag that silently created an unconfigured service, a migration path that bypasses its own ledger. On the record, readable by any teammate, human or otherwise.

The part worth keeping: the skill found nothing new. Every fact it wrote down was already known. What changed is who can know it. A rule that lives in one person’s head protects nothing when someone else, or something else, does the deploying.

Next. Run the threat-model skill against the same estate; the written security model already exists as an architecture document, so the test is whether the skill treats it as input rather than starting from a blank page. Then the original plan: re-run last week’s review through the public pack and file every gap as the pack’s first issues.