The deep dive · chapter 6 · 7 steps

Ideas that don't evaporate

Capturing a suggestion in one move, the six lines that make it decidable, and the design choice that stops the list rotting.

1. 1. The problem — the good idea from Tuesday

   Somebody said something genuinely useful in a conversation on Tuesday. By Thursday nobody can reconstruct it, including them.

   Every team knows the fix is "write it down somewhere", and every team has a somewhere that nobody reads. Idea lists fail for two specific reasons, and they're worth naming because the design here is aimed at both.

   Capture costs too much. If recording an idea means opening a tool, choosing a category, estimating effort and picking a priority, you won't do it while you're in the middle of something else — which is exactly when the idea arrives.

   The list only grows. A list of ninety items with no decisions attached is the same as no list, except it also makes you feel bad.

2. 2. Five folders, and that's the design

   A folder is the status

   aidlc — zsh

   $ ls .aidlc/roadmap/
   
   inbox/         somebody suggested it
   backlog/       we agreed to do it
   in-progress/   work has started
   done/          shipped
   hold/          not now

   the whole design

   There is no "status:" field
   anywhere in an idea file.
   
   Two places recording one fact
   eventually disagree, and a
   wrong status looks exactly like
   a right one.

   ← backstep 1 of 3next →

   Read the first frame again, because it's the whole thing: the folder an idea sits in tells you its status. There is no status: field in an idea file, and adding one is explicitly forbidden.

   That sounds like a stylistic preference. It isn't. Two records of one fact eventually disagree, and when they do, a wrong status looks exactly like a right one — nothing reports it, and you find out when somebody works from the stale one. Moving the file makes disagreement impossible rather than merely unlikely.

   The five folders are inbox (somebody suggested it), backlog (we agreed to do it), in-progress (work has started), done (shipped), and hold (not now, or no).

   hold deliberately holds both "parked" and "declined". Separating them would mean a judgement at the moment of dropping, which is the moment you have least information; the git history and the item's own history list tell you which it was, if anyone ever asks.

3. 3. The six lines

   Every idea opens with a summary of exactly six labelled lines: what it is, who benefits, what they can do afterwards, whether it makes money, rough cost and the main risk, and a recommendation.

   Six, and no more. The purpose is that a decision can be made from the top of the file. An idea whose value cannot be stated in six lines is one nobody can decide about, so it sits there while everyone waits for somebody else to read the whole thing.

   Two of the rules attached to it are more interesting than they look.

   "None" is a real answer for revenue, and often the right one. Writing "indirect" for everything makes the field useless — and worse than blank, because it reads as answered. It's also the cheapest available honesty check: an idea that has to write revenue — none and value — it observes the process rather than serving a user has just declared itself.

   Write it last. A summary drafted before the detail is a guess wearing a summary's clothes.

4. 4. Your turn

   your turn · Agree to do something

   An idea has been sitting in the inbox and you have decided you want it. How do you change its status to "agreed"?

   $ the command that changes the status
   
   $ ls .aidlc/roadmap/backlog/
   20260902-price-alerts.md

   Which line goes in the blank?

   • aidlc roadmap promote 20260902-price-alerts
   • git mv .aidlc/roadmap/inbox/20260902-price-alerts.md .aidlc/roadmap/backlog/
   • Edit the file and set status: backlog

   This exercise needs JavaScript. The transcript above is complete apart from the blank.

5. 5. Turning an idea into work

   Promotion is where the list meets everything in the earlier chapters: pick a workflow, pick how far back to start, create the work, and let the idea seed it. For a full start the idea becomes raw material that the ideation step refines; for a standard start it's the input to requirements.

   Then the idea file records the name of the work it became, and moves to in-progress. When that work finishes, it moves to done on its own — the completion event does it, which is the only reason it reliably happens.

6. 6. The cap, and why it's uncomfortable

   The rule this project ended up needing: cap the list at around a dozen raw ideas. At the cap, promote something or drop something before capturing anything new.

   That's unpleasant, and it's the point. An idea list that only grows is a list nobody triages. Forcing a decision at capture time means the decisions actually get made, and the ones you drop were mostly going to be dropped in eighteen months anyway, having taken up room the whole time.

   There's a related discipline about follow-ups. Every finished piece of work generates suggestions for next time, and the default for those is dropped — keeping one requires a stated reason. Finishing work reliably generates more work than it retires, and if you keep every follow-up the list becomes a machine for creating work about work.

   The one exception is worth knowing, because this project paid for it: if a fix is understood well enough to write down in prose, capture it as an idea in the same breath. A follow-up described in a completion note here was rediscovered from scratch three days later, re-analysed, and re-scoped as new work. Prose is not a work item.

7. 7. What you can do now

   You can capture an idea mid-task in one file with no ceremony, decide on somebody else's idea by reading six lines, and change its status by moving it. And you know why there's no status field to edit.

   Next: what actually breaks when two people work in the same folder at the same time. It isn't what you'd expect.