Artifact-led development workflow v4.0.0

MyFlow

Five stages, each ending in a written artifact. The artifact — not the conversation — is what carries the work forward, so a fresh session can pick up where the last one stopped without being told what happened.

One skill tree
The same twenty skills serve every agent. There is no per-agent copy to keep in step.
No dependencies
Every script imports only Node builtins and its own siblings. Nothing to install, nothing to resolve.
Evidence, not assertion
Close reads linked passing review evidence and its provenance rather than trusting a verdict line.
Proportionate
A trivial change can stay in conversation. Depth is a decision Scope makes, not a fixed toll.

The chain

Each stage reads the artifact above it and writes the one below. Read the writes column downward and you have the whole handoff: that column is the workflow's actual interface.

00

Onboard

onboard when needed

Discover the repository's own instructions, policies, locations and local capabilities — and name what is still unknown. Runs before a workstream exists, because its findings serve many later ones.

Reads
The repository, and whatever it already documents about itself
Writes
repository-map.md · onboarding/runs/ · onboarding/evaluations/
Repository policy wins. The map points at authoritative sources rather than copying them, and those sources win on conflict. A missing result is explicit — never an invitation to invent policy.
01

Scope

scope

Establish the intended outcome, acceptance criteria and risk, collaboratively and code-light. Scope decides how much workflow the work deserves, selects only the specialists it needs, and offers an isolated branch or worktree where repository policy permits.

Reads
A rough idea, and the resolved repository map
Writes
<workstream-id>/scope/ — the alignment artifact
Also establishes
The workstream ID, before any durable artifact is written
Depth is chosen here. Truly trivial and uninterrupted work may stay in conversation — but if it expands or pauses, a lightweight plan is written before it continues.
02

Plan

plan design

Turn acceptance criteria into executable authority, including the verification map that Verify will later execute. Every plan records a design disposition: locked into existing architecture, localized design, or structural design required. Only the last one earns a standalone design artifact.

Reads
scope/, plus research/ and design/ when used
Writes
<workstream-id>/plan/ — phases and a verification map
Outcomes before implementation details. The plan is authority for Implement, not a description of it — so it is accepted before code is written, and stays immutable once it is.
03

Implement

implement commit

Execute the accepted plan phase by phase, autonomously. Each phase whose automated success criteria are green gets its own commit, and a checkpoint records where the work stands.

Reads
plan/ — the accepted plan and its phases
Writes
Green-phase commits, and an implementation checkpoint
Verify is not a separate errand. After the final green phase, Implement reads the installed verify skill and runs it immediately, in the same parent session. Invoking Verify by hand is recovery guidance, not a gate a person operates.
04

Verify

verify code-review

Execute the plan's verification map, then run code review over the exact implementation scope — a commit range or commit list, never an approximation. Three lanes read the change in fresh context: Correctness and Risk, Standards and Maintainability, Spec Fidelity. Confirmed P0 and P1 findings block; P2 does not.

Reads
plan/ and the exact implementation scope
Writes
<workstream-id>/verify/ — report, review evidence, manual brief
A finding is verified before it blocks. P0 and P1 candidates get independent verification, so review pressure lands on real defects rather than on volume.
05

Close

close technical-writing

Make proportionate closeout decisions with the developer: what documentation the change actually earned, what was learned, and how it is delivered. Close is collaborative by design — it is the stage where the work rejoins the team.

Reads
Linked passing review evidence, and its plan and scope provenance
Writes
<workstream-id>/close/ — delivery and continuity record
The gate is the evidence, not the verdict. Close inspects the linked review evidence and where it came from, instead of trusting a report's top-level pass line.

What a workstream looks like on disk

A workstream is one bounded piece of work from Scope through Close. Everything it produces lives in one directory, so its progress is visible without mixing it into older work.

<workstream-root>/
└── <workstream-id>/
    ├── workstream.md      index + current state
    ├── lifecycle/
    │   └── events.jsonl   authoritative journal
    ├── feedback/
    │   └── events.jsonl   private, never synced upward
    ├── scope/           alignment
    ├── research/        when a specialist was used
    ├── design/          only when structural
    ├── plan/            implementation authority
    ├── verify/          validation + review evidence
    ├── close/           delivery record
    └── handoffs/        temporary bookmark

Artifacts are not product source

They are evidence about the work, so by default they live outside the repository, under ~/.myflow, optionally pushed to a private Git remote you own. Sandboxed agents fall back to .myflow/workstreams/ in the checkout and say so; myflow artifacts import moves them home later.

workstream.md is an index, not a second spec

It names the ID, the current stage, the authoritative current artifact and the related ones. It is a projection of the journal — the stage artifacts remain authoritative for decisions.

Handoffs are the exception

A fresh session normally resumes at a stage boundary from the manifest and the current artifact. handoff exists only for an interruption inside a stage, and points back at the authoritative artifact rather than replacing it.

Only allowlisted paths sync

Maps, onboarding records and workstreams travel. Configuration, credentials and raw observations stay on the machine — enforced by both the store's .gitignore and the sync command.

One seam for every stage edge

No skill assembles journal events or invents an idempotency key. Every boundary goes through stage-boundary.mjs, which validates the transition, digests the artifact, links the previous event, takes an append lock and returns a receipt.

Four verbs

Each stage runs the same edge commands, so the journal reads the same way whichever stage wrote it.

enter accept exit return

How an attempt ends

An attempt opens at stage.entered and closes exactly once. Overlapping open attempts are illegal.

advanced superseded abandoned workstream-closed

Hiccups have context

Sometimes something unexpected surfaces in a later stage and the work has to return to an earlier one to adjust. This is expected, and it often points to an opportunity for improvement. So the owner, the stages involved, the fix and the evidence are captured for learning.

History is immutable

Accepted artifacts and completed attempts stay as they were, even when later evidence forces a return. A retry that would change history fails; an idempotent retry returns the original receipt.

Feedback is private

Each boundary asks one optional question about how the stage went. The answer lands in the workstream's feedback/ folder. Only its coverage status ever reaches the journal, and a declined answer never blocks the work.

Host-neutral by construction

Lifecycle writes depend on no host and no external service. Where a skill would rather ask a structured question, it uses the host's facility if there is one and plain text if there is not — the wording and the choices never change with the host.

The twenty skills

Five stage orchestrators, a navigator, and the specialists Scope draws on only when the work needs them. Selection is a decision, not a default.

Stage orchestrators

6
onboard
Introduce MyFlow to a repository, refresh its workflow knowledge, or recover a missing path or convention.
scope
Begin a workstream with right-sized, code-light scoping; establish the ID; select specialists; offer worktree or trunk.
plan
Produce the accepted, executable plan from an alignment artifact or a standalone design.
implement
Execute an accepted plan phase by phase in a fresh or resumed session.
verify
Verify the plan, collect review evidence, and produce a workstream-aware report.
close
Make proportionate closeout decisions, preserve continuity, and decide delivery with the developer.

Navigation and continuity

2
myflow
The workflow map and navigation layer — where to start, and which stage the work is actually in. Not a competing stage.
handoff
Write or resume a lightweight handoff for a mid-stage pause. A backup for interruptions, not the primary mechanism.

Specialists Scope may select

5
discover
Extract intent and requirements in grill-me rounds when Scope cannot yet state the outcome clearly, then return to Scope.
research
Investigate one codebase or external question, record the evidence, and return with a recommendation.
prototype
Build something throwaway to answer a design question — does this state model or this UI feel right?
design
Resolve material architectural decisions, and write a standalone design artifact only when structure demands it.
domain-modeling
Pin down domain terminology and boundaries when the language is unclear or still moving.

Cross-cutting techniques

7
grill-me
Stress-test a plan, decision or idea relentlessly. The stage-agnostic entry point for collaborative decisions.
tdd
Shape testable seams during design and planning; run a test-first cycle during implementation when one is needed.
codebase-design
Shared deep-module vocabulary — interfaces, seams, and where the depth should go. Not a stage.
diagnosing-bugs
Evidence-first debugging for behavior that is broken, flaky or unexpectedly slow — before a durable fix is proposed.
code-review
Review a branch, range, PR or work in progress against its specification and the repository's standards.
commit
Create structured atomic commits, on request or at each green plan phase.
technical-writing
Diátaxis structure, Google developer style, STE instruction rules, Global English syntax — used by Close.