use case · development # End-to-end development: from the owner's idea to accepted code This is how we do development. The owner throws in an idea — and from there it gets drawn out, formalized, planned, broken down into a task tree and built in waves of agents, while agents on different engines critique and review every step. Every step is a task in SKEIN with everything attached: decisions, research, critique rounds, files. You can trace the whole path from idea to accepted code. Merging and deploying stay with a human. **“I want it to…”** an idea, sometimes a single sentence **Answers questions** 3–5 per turn, each with options and a recommendation problem statement **Fleshing out the task** zask **Recon** code, UI, permissions, similar features **Draft statement** assumptions highlighted **Structured interview** goal, behavior, edge cases, UI down to the icon, permissions *batch 1* **zask-ready** or zask-gaps, with the gaps listed zask doesn't make technical decisions. It writes “up to the developers”. 1. *comment* `[original wording]` snapshot before the edit 2. *task* `[zask] Payment retry` rewritten in place 3. *labels* `zask` `zask-gaps` 4. *description* answers as `Q → A` after each batch 5. *label* `zask-ready` 6. *links* `related`, duplicates closed **Answers in batches** and sets the config: who writes, who critiques stage 1 **Interview and context gathering** zdox **Lead** Claude, Codex or Grok **Repository recon** fresh clones, real code **Recap of understanding** in auto mode, decides whether a spec and plan are needed ⟦zdox-config⟧ critics.spec = grok, codex, fable · stage3.author = grok · stage4.author = codex · critics.review = grok, codex 1. *claim* head task `sk-412` · in_progress 2. *label* `zdox` and a “taken by run” comment 3. *description* recap and list of source tasks 4. *epic* “Planning” **Settles the forks** critics mark them `[USER-DECISION]`; they arrive in one batch **STOP questions** a new dependency, a new service, a breaking contract change stages 2–4 **Spec, plan, test plan** zdox spec **written by the lead** what, why, contracts *round 1* grok codex fable READY-FOR-PLANNING plan **written by grok** streams and groups *round 1* grok codex PLAN-READY test plan **written by codex** coverage matrix *round 1* grok codex TESTS-READY Critics work in parallel. The lead checks every finding against the source. An engine that brought no findings of its own is dropped from the next round. 1. *task* “Stage 2 · Spec” 2. *tasks* “Critique round N” → one per engine 3. *attachment* `spec-r1-grok.md` log of each critic 4. *comment* “codex#3 rejected because…” 5. *attachment* `spec.md` 6. *attachment* `plan.md` and round logs 7. *attachment* `tests.md` and round logs 8. *commit* one critique round = one commit stage 5 **Task tree** zdox **created by grok** task body: spec excerpt, acceptance, tests *round 1* **completeness critic codex** requirement → task → test, no holes 1. *epic* “Implementation”, groups G0…G3 2. *tasks* each with spec, acceptance and tests in the body 3. *links* `blocks`: the dependency graph 4. *attachment* `tasks-analyze.md` and the critic's log 5. *epic* “Code review” **Decides when review doesn't converge** two rounds without improvement, or criticals after the third **Can look into any session** `tmux attach` stage 6 **Development waves** zdox · zagents · zcoderev One executor per repository. It's a live agent session in tmux that runs every wave of its stream. G0 · shared contract: the others wait **skein-api** [falcon] · tmux wave 1 review fix ⟲ wave 2 review stream done **skein-web** [raven] · tmux wave 1 review wave 2 review fix ⟲ stream done **skein-frontend** [lynx] · tmux wave 1 review fix ⟲ review wave 2 stream done **Task → commit** claimed, done, one commit, closed. Tests at the end of the wave **Wave review · zcoderev** reviewers matched to the stack: go, typescript, html-css… codex grok *round 1* **Triage and fix** more than two criticals: another round on the fixes **falcon** Is the field required or not? Waiting for an answer. **lead** Required, see INV-3 in the spec. 1. *comment* roster: `falcon · skein-api` 2. *claim* `[falcon]` in the task title 3. *commit* one task = one commit 4. *closed* `[agent falcon · wave 412/api/1]` 5. *comment* wave summary, “Wave 1” in the group title 6. *tasks* `[coderev]` one per engine, report attached 7. *closed* findings table: critical / warning / info 8. *comment* `[review round] wave 412/api/1 · round 2` 9. *comment* `[retro]` the executor logs friction right away 10. *comment* `[suite] skein-api · wave 2` wave tests **Decides when red won't go away** after three rounds stage 7 **Final tests and acceptance** zdox **Contract reconciliation** between streams **All integration and e2e** red is fixed by that stream's executor **Mutation run** surviving mutants one by one **Acceptance** the owner's source tasks 1. *comment* `[contract check]` items, rounds 2. *comment* `[mutation]` survivors, gaps, fixes 3. *closed* source tasks, with commits 4. *closed* tree bottom-up, head task last **Accepts skill edits** the retro only proposes **Merge and deploy** zdox doesn't touch branches stage 8 **Retrospective** zdox **Friction log** `[retro]` entries from every stage **Run numbers** waves, rounds, critique convergence **Proposed edits** file, section, text 1. *task* retro in the retrospectives epic, linked to the head task 1. **The idea.** The owner writes what they want. Sometimes in a single sentence. 2. **Recon.** zask first reads the code and the UI, so it doesn't ask about things already visible there. Then it writes a draft statement. 3. **Interview.** Questions come in batches of 3–5, each with options and a recommendation. After every batch the answers go into the task description. 4. **Verdict.** No blocking gaps, so it gets the zask-ready label. Technical decisions are left to the developers. 5. **zdox takes the task.** It claims it, reads the run config, looks through the repositories and asks the owner its own questions. The recap goes into the description. 6. **Spec.** The lead writes it itself: what we're building, why, contracts and invariants. Load-bearing decisions get checked with a spike. 7. **Spec critique.** Critics on three engines read the spec in parallel. The lead checks findings against the source, edits and starts a new round. Product forks go to the owner. 8. **Plan.** A different engine writes the plan. It cuts the work into per-repository streams and task groups. The plan is critiqued in rounds too. 9. **Test plan.** Every requirement gets its own test and a moment to run it: in a wave or at the end. And again, rounds of critique. 10. **Task tree.** The plan moves into SKEIN as tasks with dependencies. A completeness critic checks that no requirement got lost. 11. **Executors.** Each repository gets one agent session in tmux. Repositories run in parallel; within a repository, strictly in order. 12. **A wave.** The executor takes whole groups of tasks: claimed, done, one commit, closed. At the end of the wave it runs the tests. 13. **Review.** zcoderev checks the wave: Codex and Grok in parallel, with reviewers matched to the stack. Each engine writes its report into its own task. 14. **Fixes.** The same executor fixes confirmed findings. More than two criticals means another review round. If review doesn't converge, the owner decides. 15. **A question instead of a guess.** When the executor hits something unclear, it asks the lead and waits. A human can open any session and watch. 16. **Next waves.** A new wave starts after the previous one's review. Streams don't wait for each other, except for tasks with a shared contract. 17. **Final.** Contract reconciliation between streams, all integration and e2e tests, a mutation run. Red is fixed by the executor of that stream. 18. **Acceptance.** The owner's source tasks are closed with commits. The tree is closed bottom-up, the head task last. 19. **Retro.** Friction was logged along the way. The retro collects it and proposes skill edits, but a human accepts them. Merging and deploying are theirs too. 20. **All in SKEIN.** From the owner's first sentence to the last commit: tasks, critique rounds, review reports, decisions and questions. Any step can be found and opened. ## There are a lot of tasks. And that's fine. One task set by the owner grows into a tree in SKEIN with more tasks than you could read in an evening. That's not a problem — it's normal when work goes through agents: agents break work down in detail because that's how they find it easier to do and to check. the tree of one owner task: tasks · epics · closed It doesn't bury the human: tasks an agent broke down on its own don't turn into a stream of notifications. You get only what's yours — and the tree waits until you ask “Hey agent, how's it going?”. ### What you can see after the fact - Every task has an origin: a human, an agent on assignment, or an agent on its own. - Every action is tied to an agent session: from a line in the audit log you can get to its chat. - Decisions, research and critique rounds are attached to tasks, not scattered across chats. - Commits are tied to tasks; the close outcome is honest: done, won't do, duplicate, superseded. This is how we build SKEIN with SKEIN — and everything else too. ← All use cases Use case: support →