← ClaudeAtlas

mainlinelisted

Pin what this session is for in a file, account for every detour, and balance the ledger before closing. Use when opening a session, picking up a handoff, noticing a problem outside the current job, or being asked "what are we actually doing".
lightarktech/founder-coding-skills · ★ 0 · AI & Automation · score 70
Install: claude install-skill lightarktech/founder-coding-skills
The mainline of a session normally lives in exactly one place: the first message. Then context gets compacted, that message becomes a summary of a summary, and the session keeps working — confidently, competently — on something else. Nobody notices, because the AI never says "I have changed subject" and the founder is watching output, not direction. So the mainline moves out of the conversation and into a file the harness restates every turn. **First principle: account, don't intercept.** Detours are allowed by default. A gate that blocks teaches the model to satisfy the gate instead of doing the job, and it cannot win anyway — block `Write` and it uses a shell heredoc, block one tool and it picks another. What actually hurts is not the turn; it's the turn nobody wrote down and nobody came back from. ## Opening a session — pin the charter first Create `MISSION.md` in the repo root (one per session, git-ignored — it is a working file, not a deliverable). Template: [`templates/MISSION.template.md`](../../templates/MISSION.template.md). **Do not hand the founder a form.** When their first instruction arrives, draft the whole charter yourself from that message plus the state of the repo, then put only the one-line mainline in front of them, phrased so one word answers it: > Mainline: *<one line>*. Reply OK, or tell me in one sentence what you want instead. Where you genuinely cannot tell, write `- [ ] NEEDS FOUNDER: <the specific missing thing>` — never invent it, never se