← ClaudeAtlas

triagelisted

Decide what a request for software work gets: done here in the conversation, a spec sent to the dark factory, or a planning session in the light factory. Use at the start of every request for work, before reading code for it.
rexchao1/not-so-simple-software-factory · ★ 3 · AI & Automation · score 77
Install: claude install-skill rexchao1/not-so-simple-software-factory
# triage Three outcomes. Pick one before doing anything else, and say which. | Outcome | Means | |---|---| | **here** | You do it now, in the real checkout, with your normal tools. | | **dark** | You write a spec and send it through `/dark-factory`. A worker builds it and opens a pull request. | | **light** | It is bigger than one spec. `/light-factory` plans it with the human before anything is built. | Treating every request the same is how a factory becomes slower than a terminal. The factory is for work that benefits from running without you, not for everything. ## The rule Start from the five tests. A request passes a test or it does not; no partial credit. 1. **One file.** The change is confined to a single source file, plus that file's existing test file. 2. **No new public interface.** No new exported function, type, endpoint, flag, config key, schema column, migration, or event. Changing the body of an existing one is fine. 3. **No unresolved choice.** Nothing in the request leaves a choice open that would change behavior, interfaces, data, security, scale, performance, compatibility, operations, cost, or proof. 4. **An existing check proves it.** The repository's test command already covers the changed behavior, or the request names the command that will. 5. **An end state, not a goal.** "Rename X to Y" is an end state. "Make login less confusing" is a goal. Then: - **All five pass, and the human is here with you:** `here`. Do it, run the check, show the dif