SKEIN
ENRU
Home / Use cases / Development
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 questions3–5 per turn, each with options and a recommendation
problem statementFleshing out the taskzask
Reconcode, UI, permissions, similar features
Draft statementassumptions highlighted
Structured interviewgoal, behavior, edge cases, UI down to the icon, permissionsbatch 1
zask-readyor 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. labelszask zask-gaps
  4. descriptionanswers as Q → A after each batch
  5. labelzask-ready
  6. linksrelated, duplicates closed
Answers in batchesand sets the config: who writes, who critiques
stage 1Interview and context gatheringzdox
LeadClaude, Codex or Grok
Repository reconfresh clones, real code
Recap of understandingin 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. claimhead task sk-412 · in_progress
  2. labelzdox and a “taken by run” comment
  3. descriptionrecap and list of source tasks
  4. epic“Planning”
Settles the forkscritics mark them [USER-DECISION]; they arrive in one batch
STOP questionsa new dependency, a new service, a breaking contract change
stages 2–4Spec, plan, test planzdox
spec
written by the leadwhat, why, contracts
round 1
grokcodexfable
READY-FOR-PLANNING
plan
written by grokstreams and groups
round 1
grokcodex
PLAN-READY
test plan
written by codexcoverage matrix
round 1
grokcodex
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. attachmentspec-r1-grok.md log of each critic
  4. comment“codex#3 rejected because…”
  5. attachmentspec.md
  6. attachmentplan.md and round logs
  7. attachmenttests.md and round logs
  8. commitone critique round = one commit
stage 5Task treezdox
created by groktask body: spec excerpt, acceptance, tests
round 1
completeness critic codexrequirement → task → test, no holes
  1. epic“Implementation”, groups G0…G3
  2. taskseach with spec, acceptance and tests in the body
  3. linksblocks: the dependency graph
  4. attachmenttasks-analyze.md and the critic's log
  5. epic“Code review”
Decides when review doesn't convergetwo rounds without improvement, or criticals after the third
Can look into any sessiontmux attach
stage 6Development waveszdox · 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 1reviewfix ⟲wave 2reviewstream done
skein-web[raven] · tmux
wave 1reviewwave 2reviewfix ⟲stream done
skein-frontend[lynx] · tmux
wave 1reviewfix ⟲reviewwave 2stream done
Task → commitclaimed, done, one commit, closed. Tests at the end of the wave
Wave review · zcoderevreviewers matched to the stack: go, typescript, html-css…
codexgrok
round 1
Triage and fixmore 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. commentroster: falcon · skein-api
  2. claim[falcon] in the task title
  3. commitone task = one commit
  4. closed[agent falcon · wave 412/api/1]
  5. commentwave summary, “Wave 1” in the group title
  6. tasks[coderev] one per engine, report attached
  7. closedfindings 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 awayafter three rounds
stage 7Final tests and acceptancezdox
Contract reconciliationbetween streams
All integration and e2ered is fixed by that stream's executor
Mutation runsurviving mutants one by one
Acceptancethe owner's source tasks
  1. comment[contract check] items, rounds
  2. comment[mutation] survivors, gaps, fixes
  3. closedsource tasks, with commits
  4. closedtree bottom-up, head task last
Accepts skill editsthe retro only proposes
Merge and deployzdox doesn't touch branches
stage 8Retrospectivezdox
Friction log[retro] entries from every stage
Run numberswaves, rounds, critique convergence
Proposed editsfile, section, text
  1. taskretro in the retrospectives epic, linked to the head task
whole scheme
  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 →