Introducing seeds — blog post outline

Skeleton, not prose. Each section: a one-line purpose, bullet points to cover, and (where useful) a note about a hook/quote/anecdote that I think earns its keep. Reorder, cut, expand, override at will.

1. Open with the pain

Purpose: name the problem in concrete terms before naming the tool.

The plan-file workflow with AI: you converge on a plan, AI writes it, you give feedback, AI helpfully rewrites — and the alternatives and rejection-reasons are now silently gone.
The conversation that produced the plan lives outside the project (chat scrollback, transcripts) and gets deleted/compacted over time.
The lived consequence: you become afraid to give AI feedback because the feedback destroys the very reasoning you wanted to preserve.
The longer-horizon consequence: on systems you’ve worked on for years, you keep re-inventing solutions you already considered and rejected, because the why is gone.
(Optional anecdote): a specific time this happened to you, if you have one you’re willing to tell.

2. First attempt: ADRs (and why they didn’t fit)

Purpose: show that the obvious answer doesn’t solve the actual problem.

ADRs are great. You tried them. You started building ADRB.
ADRs capture decisions — the destination. The deliberation — alternatives, rejected ideas, mid-discussion tangents, dead ends that taught you something — does not fit in an ADR.
The trip matters more than the destination, especially across years.
You commissioned a small literature review on deliberation tools (IBIS, Compendium, dialogue mapping, etc.). The tools exist; nobody uses them; they’re too formal for the cocktail-napkin phase, which is where the interesting thinking happens.
You needed something cocktail-napkin-light that didn’t get thrown away with the napkin.

3. seeds, briefly (and the play on beads)

Purpose: name the tool, anchor it to beads, give a 30-second feel.

It’s a CLI; lifecycle states (captured, exploring, resolved, deferred, abandoned); questions as first-class objects; tags, parents, children, links; SQLite + git-trackable JSONL.
The name is a deliberate gardening-cousin of beads (Steve Yegge’s tool). Beads = bug database, catches implementation. Seeds catches what comes before implementation — thoughts, ideas, plans, notions, questions.
(Optional): a tiny CLI snippet — seeds jot "what if..." → seeds explore → seeds resolve. Five lines.

4. Tell-on-yourself: the AI drives the bus

Purpose: lay out the design constraint that decides everything else, and own the “I don’t read this stuff” admission up front.

You have never invoked the seeds CLI directly. Same with beads.
You have read maybe a fraction of a percent of the seeds you’ve generated. They’re a magical black box you trust without inspecting.
25 years as a solo developer made you almost allergic to reading other people’s code, docs, and AI transcripts. You’re not pretending otherwise.
The bar you set early on: if it required you to use the CLI, it wouldn’t get used at all. It had to feel like an extension of the AI’s working memory.
Therefore: the CLI is flag-based, atomic, no interactive prompts — shaped for an AI to grab onto naturally.
You have no plan to quantify whether this is working. Quantification isn’t the day job. Getting stuff done is the day job.

5. How you actually use it (the workflow rhythm)

Purpose: replace abstract claims with the concrete loop. This is the section that should feel most lived-in.

Step 0 — dump the brain. Start a project, fire up dictation, talk through stray thoughts, weird ideas, gist, considerations. Don’t try to be organized.
Step 1 — “turn this into seeds.” AI reads the dump, creates a batch of seeds (some ideas, decisions, concerns, questions, tags). Messy and partial.
Step 2 — AI interviews you. It asks for clarification on things you said. It asks about things you didn’t say but should have. It flags contradictions. Generally it’s right on. You answer or admit you don’t know.
Step 3 — triage together. You suggest deferrals; you say which things can’t be defined until other things are. The AI builds parent- child relationships, links related seeds.
Step 4 — the foundational-priority question. You ask “what’s foundational? what decisions need to be made now?” — and the AI figures it out. It knows which seeds gate the rest. You don’t know how it knows. (This moment is worth lingering on.)
Step 5 — answer or chase. Sometimes you have an answer, sometimes the AI suggests one and you sanity-check, sometimes you send it off to investigate.
Step 6 — investigations get recorded back into seeds. This is the part you love most. The AI doesn’t just answer in chat (where the answer evaporates at compaction time); the findings land in the seed body. Years later that information is still there, exactly as it was at the time the decision was made.
Step 7 — cycle until enough. No formal threshold; you just feel it.
Step 8 — handoff. “Make some beads out of these seeds.” The resolved/decided ones become bd issues with their seed-body context attached. Off to implementation.
Step 9 — feedback loop. Implementation surfaces wrong assumptions; you come back to seeds; new thoughts get jotted, resolved seeds occasionally get reopened, the deliberation feeds the next round.

6. Where this has shown up in your work (anonymized)

Purpose: ground the abstract claim in real shapes you’ve used. Anonymize all project/dataset names; describe at a high level only.

Greenfield design — web app, library, pipeline, fresh project with no context to inherit.
Software-adjacent: ETL design. ETL has a tremendous number of small decisions (which incoming tables, which columns, what transformations) and the why is what downstream users need to understand the trustworthiness of the resulting data. Seeds turned out to be a natural fit for that audit-log shape. Pull this thread if you want — the data-quality angle for downstream consumers is a strong subargument.
Decade-old codebases. You’ve experimented with backfilling seeds from the last decade of GitHub issues (closed and open) on a long-running app. Fidelity is low; the agent now has something when you ask “have we considered X.” The killer moment is when the agent says “we already considered that in 2022, here’s the bead it became, here’s why it ended where it did.”
Seeds about seeds. The project’s own deliberation lives in seeds. Self-dogfooded. Slightly recursive. Useful.

7. Relationship with beads

Purpose: be clear about the boundary, give credit, address the obvious “isn’t beads doing this now?” question.

Beads = bug database. Steve Yegge built it for: I’m coding, I notice something, I don’t want to forget, I don’t want to context-switch. After several months of heavy use, beads has fundamentally changed how you work with AI on implementation. That’s the existence proof for “structured tools for AI agents work.”
Seeds is for the verb before implementation: planning, deliberation, ideas, half-questions, things you haven’t decided are work yet — and may decide are not work at all.
Different lifecycles: beads is open→in_progress→closed (work to be done); seeds is captured→exploring→resolved/abandoned/deferred (thought that may become work).
You’ve watched beads add bd memory and bd decision and threading. That drift is fine with you.
But: planning and implementation are still discrete jobs. You don’t want your AI to face the full backlog of half-formed thoughts every time it asks “what’s ready to ship?”
Implementation can — and does — feed back into the plan. If reality disagrees with a decision, that goes back to seeds.

8. The principles, said plainly

Purpose: short and unsentimental. Don’t pad it.

Capture the journey, not just the conclusions.
An idea that isn’t ready for a todo list still deserves a place to wait.
Capture is fast; structure comes later.
The AI is a participant in the deliberation, not a stenographer of yours.
Domain-agnostic by construction (software, ETL, RPG character work, house projects — the shape is the same; the fruit differs).

9. What seeds doesn’t do (the honest part)

Purpose: credibility through limits.

It doesn’t enforce completeness. It’s a forest, not a checklist. You’ll forget to deliberate about things and seeds will not flag it.
Capturing in the moment is still hard. Resolved deliberations end up better-documented than active ones. Open problem.
Of N projects you’ve initialized seeds in, M of them have zero seeds. Just having the tool installed doesn’t grow a deliberation log. The habit has to come with it.
You can’t measure success. You can only tell that you feel safer planning in seeds than in markdown. That’s not science.
Beads might absorb this eventually. If it does, fine — your investment is in the deliberation surviving, not in seeds existing as a separate thing.

10. The investment / years-later payoff

Purpose: this is the section that argues why it’s worth the friction even though the friction is real and the payoff is delayed.

Asymmetric: cheap per capture, valuable on retrieval.
The dream moment: you come back to a project after months or years, ask the agent to create a seed for an idea, and the agent says “we already considered that, here’s the seed, here’s the discussion, here’s the resolution.” You skip a re-litigation that would have cost you an afternoon. You haven’t seen the years-later payoff many times yet — that’s honest. But the early signs are there.
(Optional): the round-trip experiment you keep meaning to run — plan → seeds → plan, see if the second plan is faithful to the first. If yes, evidence of lossless deliberation capture. If no, the losses tell you what’s missing from the model. You haven’t done it yet.

11. The frame: this is mine; hopefully it fits you too

Purpose: avoid being prescriptive. Make it clear this is one person’s report from the field.

The way you use it may not be the way someone else would use it.
The tool was written by an AI, for you, on your behalf, to fit the way you already think.
The thesis line: you’re trying to explore the deliberation space while securing your thinking to the level of detail and permanence you require in order to feel comfortable. That’s the whole project.
The design is loose enough to bend to a different brain.
(This frame can also live earlier — section 4 or 5 — if you’d rather lead with humility than land on it. Your call.)

12. Why you trust it without quantifying it

Purpose: the strong-signal argument. Short.

Tools that fundamentally change how you think about a problem tend to turn out to be good tools.
Beads did this for implementation work over four months.
Seeds is doing this for planning work.
A markdown plan file now feels sloppy and ephemeral by comparison.

13. The closer

Purpose: land the punch.

The line: “I don’t feel safe planning if I’m not planning in seeds.”
One sentence on what to do with that.

14. Try it

Purpose: link, license, expectation-set.

GitHub repo (outcomesinsights/seeds).
MIT, beta.
Drive it through your AI. The AI’s experience matters more than yours.
Tell you what your AI does with it.

Pieces you have available but I’d consider cutting

These came up in the source material but might not earn space in a tight post:

The full literature review of deliberation tools (IBIS, Compendium, decision journals). One sentence in §2 is probably enough.
The “two of nine projects never used it” stat. A great honest moment but specific; could land as one bullet in §9 or be cut.
The seeds-about-seeds dogfooding meta-loop. Useful for credibility, but easy to overplay.
The “AI friction patterns” (premature implementation, asking permission to capture). Real, but inside-baseball; could live in the companion working-with-seeds.md instead.
The completeness-checking gap and the capture-in-the-moment gap. Both genuine, both probably one bullet each in §9.

Pieces I’d push you to make sure you keep

The “evidence destruction by helpfulness” framing in §1, or any phrase as crisp.
Tell-on-yourself in §4. The post is much weaker if you bury this.
The “what’s foundational?” moment in §5. That’s the wild bit and it’s hard-earned.
The investigation-recorded-back-into-seeds beat in §5. That’s the magic.
The thesis line about securing your thinking to the level of permanence you require. Wherever it lands, it should land.
The “I don’t feel safe planning if I’m not planning in seeds” closer.

Tone notes (to your taste, not mine)

Your Jigsaw posts are direct, opinionated, willing to say “I don’t know,” fond of pointed section headings. The “ETL Is Hell” voice.
Yegge’s beads post is much more ornate (and longer). Mostly that isn’t your voice, but the structural moves are worth borrowing: open with failure, descend into the problem, reveal the solution late, let the philosophy come last.
Length target: probably 1500–2500 words. Less than Yegge, more than most of your Jigsaw posts. The post has more to do than a typical Jigsaw post (introduce a tool, sell a workflow, defend it against a sibling tool).
Don’t write it like I would. Write it like you would. The honest, dry, “I don’t know if this’ll work for you but here’s what I did” voice is the right one for this particular tool.