Backlog

Every open item in Flow, in one place. An open item lives here and nowhere else: the files under lab/context/ keep the reasoning behind them, and none of those files is a work list. Each submodule keeps its own: lab/domain-skills/backlog.md, lab/util/backlog.md and lab/toolbox/backlog.md. An item about how Flow uses one of them stays here.

One line per item: what it is, then where the argument lives. Never the argument itself.
A pointer names a file in lab/context/ unless the line gives a path.
A finished item is deleted, never checked off. Git holds what was done, lab/context/ holds why.
## V1 blocks the first release. Its ### The spine runs in the order written, and the final sweep is last. Every other V1 section is filed by area and gets built wherever it fits before that sweep.
## After V1 holds what cannot be built yet, one subsection per area, the lowest priority last.
A marker on the line says what else holds an item back. talk first needs its own conversation before anything gets built. parked waits for a real case. half done marks a started item.

V1

Everything here has to be true before Flow installs on a machine and gets used.

V1 went from 7 items to 39 on 2026-09-16, when the user ruled that everything minor and obvious belongs here. What stayed behind needs a case only live use produces, is a drawing engine Flow works without, or targets another harness or model.

The spine

The management skill, in build order

Routed out of lab/context/management.md on 2026-09-17, the last phase of the groundwork method. This list runs in the order written. Nothing here is designed further: each line has a dated section in that map holding the argument, and the map stays as the design record every line points back to. The 4 skills come last, because each one calls code that does not exist yet.

~/.flow/history.jsonl: one line per change Flow makes to the machine, ignored by ~/.flow/'s git. Built 2026-09-23 for clones, pulls, switches, installs and sources changes. Setups, migrations and restores add theirs when those skills are built. Clones, pulls that changed something, switches, installs, setups, migrations and restores. management.md → ### Every change Flow makes to the machine is one line in ~/.flow/history.jsonl
skills/tools/setup-machine/SKILL.md: put Flow on a machine that never had it, or that has somebody else's setup on it. install.sh, the one pasted line, is built, and bash lab/scripts/try.sh --case before-flow tests the skill against this computer as it was before Flow. The survey reads all 4 routes a skill arrives by and looks for Flow's own leftovers first. Where a harness keeps its own files is ~/.flow/references/harnesses/, one file each, read before the survey starts. The competitor test asks whether a thing instructs behavior on ground Flow already rules on, with a third outcome beside keep and delete for the account-synced tree that comes back on the next sync. The harvest sorts every line into 3 buckets and drops one only where the migration names the Flow rule replacing it. It asks no question. ## The user and ## Preferences are optional fields in migration.md holding what the harvest found, and both fill during work through ## Capture. ## Preferences keeps a harvested line only where the user would still want it had Flow been there from the start. It opens no project's memory files, which wait for /flow:setup-project, and treats whatever it finds as context of any type rather than a rule file. settings.json splits 3 ways, with every key the form names under its red or green section, and every other key left exactly as it is. The form's whole shape, the second check included, is management.md → ### The whole form, as approved. Outside skills the form can take over get their own section: an npx skills install becomes a source, and a folder copied in by hand moves into ~/.flow/private-skills/. Then the rule file is written: ~/.agents/AGENTS.md and the import line in ~/.claude/CLAUDE.md. flow install starts this skill itself, as claude --safe-mode with the rule template and the skill joined into one --append-system-prompt-file, and skips it on a machine where ~/.flow/version exists. Step 0 of this skill, of /flow:setup-project and of /flow:migrate is flow doctor --prereq, and a failure stops the run. flow install writes none of those 3 and no longer merges settings.json, so this skill owns all 4. Its last act is closing the machine's original, the window flow install opened: originals.close(at) in scripts/flow/lib/originals.js, which apply-migration.js already calls for a migration whose type is setup-machine. One migration, one yes, then to the end. Setup asks no question, ruled by the user 2026-09-21. management.md → ## Setup asks no question, ruled 2026-09-21, ## The interview is one open question, locked 2026-09-21, ## Setup and migration are two flows, ## The competitor test, ## Harvesting an existing setup, ## What setup does to settings.json and to a project, ## The 2 personalised files
skills/tools/setup-project/SKILL.md: bring one project into Flow, the first time the user opens it. It reads the whole project before it writes anything: CLAUDE.md, AGENTS.md, .claude/, .agents/, .codex/, docs/ and the project's memory folder under ~/.claude/projects/. ~/.flow/references/harnesses/ is where that path list comes from, one file per harness. From that it writes one migration for the project's context files and state, and that migration is also what fills the project's original. The window opens and closes inside this one run, so a later migration copies nothing. Real project work it finds, such as Delapse's 182 files under docs/, becomes tickets, since a migration does only what one yes covers. An empty new project gets project-template/ and nothing more, since nothing copies the template into a project today. Delapse is the test case. What it reads, and in what order, is its own design pass, inside this build. management.md → ## What setup does to settings.json and to a project
skills/tools/migrate/SKILL.md: 6 fixed steps, each naming the file it reads or writes. Open the run's folder; read ~/.flow/version, every newer changelog entry, and the upgrades/<number>.md guide each one names; diff the 3 things Flow owns, against the harness paths in ~/.flow/references/harnesses/; write migration.md, one line per file rather than one per entry, and every new file whole under files/; run ~/.flow/scripts/apply-migration.js, which changes only the paths the migration names and records nothing, the machine's original having closed at setup; prove with flow doctor and one claude --print session read back through flow audit, then stamp the version. The session that applied it holds rules that are gone, because rules load when a session launches, which is why the proof runs in a second process. management.md → ## The 6 steps of a migration, ## A whole-workflow replacement, ## Proof
skills/tools/help/SKILL.md: answer a question about Flow in one line plus an address, such as docs/manual/settings.md → ## Hooks, found through ~/.flow/docs/manual/README.md. "What do I do now" is state rather than documentation: read ~/.flow/run.json, then the board, then .flow/handoff.md, and name /flow:start instead of rebuilding what it renders. management.md → ## The answer job
flow up: the whole update in one word. Fetch, see what is newer, update the submodules, run the migration, run flow doctor. Inside a project it does the same against .flow/version. flow doctor already names it in every version note, so the command is on screen before it exists. management.md → ## How Flow ships
Then it runs here, which is both the acceptance test and the first real install. The 9 outside skills and plugins on this machine have been kept untouched since 2026-09-15 to be the test material, and ## Settled by the user puts install, verify and re-install across the user's 2 machines in v1. never-install holds until the user says the day has come. management.md → ## Faults found by the attack, 2026-09-17 records the machine as it stands

The skill system

Plugins are a fourth install state Flow does not control: off by default. extraKnownMarketplaces in the committed settings, enabledPlugins in .claude/settings.local.json, and a flip takes effect next session. skillOverrides is not an off switch: it leaves the commands and the hooks running

Individual skills

Build the research redesign: Context7 through a script, one folder per outside tool under ~/.flow/wiki/, and capture sending tool findings there. Designed and agreed 2026-09-19, built once the management skills are finished. knowledge-base.md → ## The build plan
/grill: a skill fired at a finished artifact, disable-model-invocation: true, never model-invoked. Decided and undesigned. One form hands the stripped mechanism to subagents that never saw the conversation, so none of them can defend it. talk first
The skill-creation trigger: when a recurring pattern becomes a new skill, and who writes it. talk first
Auditing current work against a skill's accumulated practice: scope it to what the work touched, or the reads are unbounded. talk first

`flow`, the tool

A study case says fixed the moment a rule changes, and nothing checks that the rule worked. open and fixed are the only 2 statuses, so writing the fix and declaring it good are one act. All 3 cases written 2026-09-06 say fix: home/CLAUDE.md, and ## The turn has never run in a session. Wanted: addressed in the middle, meaning the file changed and the change is unproven. Changes CASE_STATUSES in lib/cases.js, the --status values on flow cases ls and edit, and references/study-cases.md → ## Closing. What blocks it is who promotes a case to fixed: nothing watches a session today, so addressed becomes the terminal state and the third status buys nothing. talk first. rules.md
Working on more than one machine, past the simplest version. Raised by the user 2026-09-09, widened 2026-09-19, and cut down to the smallest thing that works on 2026-09-20. What was built that day: ~/.flow/ is one private git repository, flow sync brings the other machine's work down and sends this one up by hand, and scripts/flow/lib/flow-repo.js holds it. What stays on one machine is version, run.json, originals/, settings.local.json, the scripts and references links, and each wiki tool's downloads/. The parts still open, each parked until a real case turns up:
- The rule file moves into ~/.flow/. ~/.agents/AGENTS.md becomes a link to ~/.flow/AGENTS.md, so the profile in ## The user and ## Preferences travels with everything else. Agreed 2026-09-20 and unbuilt: /flow:setup-machine writes that file, so it lands in that skill's build. One state path across harnesses, below, covers the rest of the moving.
- Nothing syncs by itself. SessionEnd fires only on exit, /clear, /resume and /logout, never on /compact. Its hooks share a 1.5-second budget, too short for a push, and a session left open on one machine never ends. Proposed 2026-09-19: a background commit and push from Stop after every answer that changed ~/.flow/, and a background fast-forward pull from SessionStart and from UserPromptSubmit once the last pull is 5 minutes old. parked
- What Flow does not carry at all: ~/.claude/settings.json, the plugins a machine has enabled, and its MCP servers. Each is Claude Code's own file, outside ~/.flow/, and a copy of one would carry the other machine's paths and keys. parked
- A Flow update reaching one machine before the other. The 2 clones sit at different commits, so ~/.flow/version differs and a migration that ran on one has not run on the other. parked
- The transcripts and the audit index stay put. ~/.claude/projects/ is 351 MB on this machine and audit/audit.db is derived from it, so neither travels and flow audit answers about one machine. parked
- Nothing tells Claude what arrived. A note written on the other machine is on disk after a sync, and no session mentions it. parked
- Whether migrations/ should travel. It does today, since nothing ignores it. It is history rather than state, and its paths are the other machine's. parked
- A project travels through its own repository. Its .flow/, tickets included, is committed with it, so only uncommitted work stays behind, and util git uncommitted send carries that on the rare day it is left. Flow leaves projects alone, ruled 2026-09-20.
- Each machine holds projects, clones and plugins the other never had. Raised by the user 2026-09-20. The ~/.flow/ that arrives then describes a machine that is not this one. Open: whether /flow:setup-machine runs a second time, on request, to harvest what the new machine already carries. parked
flow sync is never proved against a real remote. scripts/tests/sync.test.js covers what needs no git: the ignore list, the .gitignore written from it, and the refusal on a ~/.flow/ that is not a repository. Sending, bringing down and the refusal on a pull that will not fast-forward are all untested, and testing them means a bare repository in tmp/ and real git runs. Found 2026-09-20 while building it.
An overlay reaches a SKILL.md and nothing else. The mechanism is a shell line at the bottom of a skill body, !`flow overlays <name>` , and 10 skills carry one. A references/ page under a skill has no place to run a command, and neither does a file in rules/, so a project cannot extend either one. Raised by the user 2026-09-11, designing the management skill. talk first

Rules and always-loaded files

The audit

Scoring a session against Flow's rules, conduct rules included. The machinery landed 2026-09-07 and holds no checks, so nothing is scored yet. A check is a function where a function can decide, and a model call only where it cannot. rules.md assumes one PreToolUse hook on Edit|Write and leaves conduct rules to a reminder, but 3 documented hooks reach further. MessageDisplay streams Claude's prose with a turn_id. PreToolUse carries the prompt_id of the user prompt in progress. Stop carries last_assistant_message and can block, up to 8 times in a row. Text against edits inside one turn is readable, so the-turn and the-reply become enforceable and not only measurable. Raised by the user 2026-09-07. talk first, a design pass. rules.md → ## Locked decisions: the enforcement bridge, docs/dev/claude-code.md → ## What a hook can see of the conversation
A run is not wired to anything: run and run_session are built and empty, every query treats them as optional, and nothing writes a row. A SessionStart hook has session_id and cwd, and statuses.js says which ticket is in flight. It also fires on compact, so a naive hook counts one session 4 times. talk first
A linter is a rule check Flow does not have to write. Raised by the user 2026-09-10. ESLint, ruff and shellcheck already decide most of the shape questions scripts/rule-checks/ would otherwise implement by hand, they run over a whole file rather than one edit's added text, and their rules are argued over by more people than Flow will ever have. Two ways in: a check that shells out to the linter and files its findings under a Flow rule id, or Flow generating linter config from its own rules so the two cannot disagree. Open: which rules belong in linter config rather than in JS, what a project with no linter gets, and what happens when a project's existing config contradicts a Flow rule. never-install binds here: Flow can read a config a project already has, and adding a linter is the user's call. talk first
flow audit prune: cleanupPeriodDays is 365, so nothing bounds ~/.claude/projects/ for a year, and the index is 44 MB against 241 MB of transcripts as of 2026-09-02. Prune by run rather than by age, delete only what the index has fully read, and never sweep what a study case pins
A subagent's transcript is indexed and unreachable: each one becomes its own session row carrying agent_of, and no query joins on it. A subagent's tool calls do not appear in its parent's totals
~/.flow/workflow-notes.md and study cases cite the audit: both become readers of it. A case still extracts and commits what it cites, because the index is machine-local and the transcripts are swept. references/study-cases.md justifies writing one immediately because the conversation is the only copy, and retention weakens that premise. talk first

Subagents and dispatch

Output contract, tool allowlist and model, per agent: nothing fixes what a dispatched agent returns, so it comes back as free prose the parent has to re-read. The model for fixing a format exactly is repos/caveman/agents/cavecrew-*.md, 3 tight subagent definitions each with a tool allowlist and model: haiku. talk first

Docs for whoever reads Flow

A manual page on what Claude Code already does: /run spent months doing a worse version of shell mode, a built-in feature nobody knew was there, and was deleted the day it surfaced. The page lists the built-ins worth knowing and the Flow-shaped mistake each one prevents: shell mode against building a command skill, permissions.deny being additive against any switch layered over it, the documented hook payload against guessing what a hook receives. It grows every time a feature turns out to have been there all along. talk first on where it sits: its own page, or a section of one that exists
docs/context/ and docs/spec/decisions.md overlap and nothing routes between them. "We use Postgres" is a durable verified fact and a locked decision at once. The user asked whether the two folders merge. Recommended instead: delete docs/spec/decisions.md and split it 3 ways, since the overlap is one file wide and not one folder wide. Decisions that constrain implementation go to tech.md, which references/workflow.md already gives that job. Product decisions go to product.md. Refused options, bets and open questions stay in the groundwork map that produced them. Merging loses more: a folder named spec holding a verified command breaks name-for-content, and decisions.md against subject files stays an overlap after the merge. Walk 3 real Delapse examples first, which makes it groundwork. A delete needs its own confirmation. talk first

Install and migration

Tune guard.js's deny and ask lists against real use: they were written from the rules, never against an observed false positive
domain-skills is cloned over SSH while every other submodule is not. .gitmodules names git@github.com:Adrian333Dev/domain-skills.git, and lab/util and lab/toolbox both use https://. All 3 repositories are public on GitHub, checked 2026-09-17, so https needs no key, no agent and no setup at all to clone or pull, and gh already covers pushing. Setting the SSH remote up cost the user an afternoon of local errors, and would cost anyone else the same. Changes one url in .gitmodules, after which the submodule's own copy of that url has to be re-synced. Raised by the user 2026-09-17.

Context and session boundaries

Wrap up when the context gets large: a hook that reads the running token count, then tells the agent to stop at the next checkpoint, write the handoff and report in full. The transcript at ~/.claude/projects/<project>/<session-id>.jsonl carries a usage block on every assistant message, so the count is readable without asking Claude Code for it. PostToolUse, never UserPromptSubmit: a long execution run makes no user turns for the second one to fire on. Threshold around 120k against a working ceiling of 150k. What counts as a checkpoint has to be defined per phase, because the reminder must never cut a ticket in half. Designing it is also what makes "go means finish everything" safe to put into home/AGENTS.md, so the two are one job. A working start was deleted 2026-09-15: context-pulse, a hook printing context usage read from the transcript, restored by git show cf63643:lab/framework-build/hooks/context-pulse/index.mjs. talk first. rules.md
Nothing loads on a bare /flow:start with no ticket and no path: a handoff.md sits beside whichever thing is being worked, so there can be several and no id points at one. Left out of the 2026-08-24 build
A dropped file path costs a whole extra turn: dragging a file from the editor into the terminal pastes its absolute path in single quotes, and dragging is the only easy way to name a file the @ list will not offer, a git-ignored one above all. The agent then spends one turn seeing the path and a second reading the file. Wanted: the drop inserts @path, which the user set on 2026-09-21 as the only acceptable outcome. Researched the same day, and it is 2 faults in 2 different places.
- The drop itself is not Flow's to fix, ruled 2026-09-21. A hook that reads the dropped file and prints its content is rejected outright. A UserPromptSubmit hook cannot insert the @ either: it only adds context beside the prompt, capped at 10,000 characters and 30 seconds.
- What was measured, in a scratch session with every reading tool disallowed so only expansion could reach the file: @ delivers a git-ignored file, so only the suggestion list filters by git. An @path printed by a hook is never expanded, proved against a control where the same hook returned the file's content and the answer came back. A quoted @'path' never expands, 3 runs each on the relative and absolute forms, so typing @ before dropping is not a workaround. @src/ expands to a listing of the folder.
- Filed rather than built: 3 [FEATURE] issues on 2026-09-21, the file drop #95761, the folder drop #95762, and a hook being able to replace a prompt #95763. claude-code.md → ### Three more on 2026-09-21, written from the dropped-path research holds all 3, and ### The feature form, field by field beside it holds what the form asks for.
- If the hook is ever revisited, 2 things are already settled: it cannot tell a dropped path from one merely mentioned, so delete /home/me/old.log would load old.log, and a large file is printed as its path, its line count and its size with no instruction attached, because the numbers already say it.
- lab/research/claude-code-docs/hooks.md, settings.md → ### File suggestion settings
Context engineering: keep what loads as small as possible, and stop cache invalidation when a skill loads mid-session. talk first
A workflow note is written and never read again. ~/.flow/workflow-notes.md is the cheap half of the capture pair: one dated line for friction with nothing to preserve. Nothing drains it, and nothing promotes a line that has now appeared 3 times into the study case it has become. Decide what reads the file back and when. /flow:file-findings already drains .flow/inbox.md, and the notes file is global where the inbox is per project. talk first. references/study-cases.md → ## Note or case

Drawing

Turn the glyph probe into a script: lab/research/ascii-glyph-probe.md is evidence today. scripts/glyph-probe.js would make "show it to the user first" something the agent can carry out, and it has to render into a file as well as a terminal. drawing.md

Other people, other models

Build Flow for a stranger. home/AGENTS.md carries a personal profile, the install has never run on a second machine, and no page explains Flow to somebody who has never seen it. A setup script is fine, and a one-command npm install is not required. Split out of the other-harness item on 2026-09-16, because none of it needs another harness or another model. manual.md

After V1

The skill system

Flow keeps Claude Code's skills and adds 3 things: a group folder, one shell line per skill for overlays, and a rule that a skill invoked over and over stays short. skills.md carries every argument.

How a design plugin gets used: what fires it, whether design work is its own phase, what happens when 2 of them disagree, the boundary with /flow:visualize, what comes back into Flow afterwards. Decided after the first real run in a project, never before. Not essential; Flow works without one. talk first
paths: in skill frontmatter, which Flow uses nowhere. With it, Claude Code loads a skill only while working with files matching the patterns, and every Flow skill loads from its description alone today. Rejected 2026-08-26 for the standards/ group, since dissolved. Still open for domain skills, where a skill maps to a file type and costs nothing until it matches. No richer condition than a glob exists: no hook loads a skill or a rule file, asked and closed 2026-09-07. parked until 1 project installs 5 or more domain skills. docs/dev/claude-code.md

Individual skills

Whether a child map may write an open branch into its parent's map.md. Built 2026-09-08 as /flow:groundwork Phase 2's rule for a decision that binds more than 1 child, because 2 children answering the same question answer it differently. Unproven: no product has been split into child maps yet, and the rule assumes one session at a time, which holds for a solo developer and not in general. Reverse it and the alternative is walking the shared decision in whichever child hits it first, then having the sibling read it. talk first

`flow`, the tool

flow history, filtering ~/.flow/history.jsonl by type, name and date, once grepping it gets tedious. management.md → ## Skills, sources and the machine's clones, ruled 2026-09-23
flow contribute sends study cases to Flow's repository, the way it sends a skill to domain-skills. Everyone gets /flow:review, so every machine writes cases nobody reads yet.
One state path across harnesses. Raised by the user 2026-09-09. Flow writes to ~/.claude/ today, and a second harness means ~/.codex/ or ~/.agents/ beside it, each with its own layout. What the user wants is one place holding whatever must survive a machine change, with ~/.flow/ as the candidate, and explicitly not the whole of ~/.claude/ moved under it. Open: which files actually need to travel, whether they are linked or copied, and how a harness that only reads its own path gets them. Depends on Working on more than one machine, since travelling means committed. talk first

Rules and always-loaded files

Project-level rule checks at .flow/checks/<id>.js, with the scorecard loading both folders. Designed and deliberately skipped in the 2026-09-07 build: no project needs one, and a mechanism built ahead of its first case gets built wrong. The global half at scripts/rule-checks/ is done. parked

The audit

Built 2026-09-02, over the transcripts Claude Code already writes. flow audit indexes them into a SQLite file, answers queries against it, and opens a bounded turn range of the original conversation when the counts are not enough. docs/dev/audit.md describes the index.

The rule-text injection path has never run live. When a check fires against a rule whose file never loaded this session, rule-check.js injects the rule's whole text instead of its id. checks.ruleText is unit-tested and has never been exercised by Claude Code. It stays unproven until a warn check exists. Moves to ## V1 if a major rule gets a check before release
A full sweep over the tree against every rule, ending in one report. Raised by the user 2026-09-10. PreToolUse sees one edit at a time and only the text that edit added, so nothing today can say how the project as a whole stands against the rules. A sweep walks every file, runs every check whose applies matches, and writes one report detailed enough for an agent to work through: fix these, report those, ignore the rest. Distinct from flow scorecard, which counts what sessions did rather than what the tree holds. The design problem is needs: 'added'. Every check is written to judge new text, and handing one a whole file that predates the rule turns a clean tree into thousands of findings. So a sweep either runs a different set of checks or every check declares what it does when handed history. talk first
The daily sweep is a second mode: analysing every session since yesterday is batch, and batch wants parallel dispatch. Parallel readers need no worktree and no change record, so nothing blocks it since 2026-09-15. The deterministic half runs at zero token cost over every new session and escalates only what it flags

Subagents and dispatch

Work on several branches at once: Flow supports one branch at a time to start with, ruled by the user 2026-09-13. Across parallel branches .flow/inbox.md, .flow/handoff.md and new ticket ids collide, and a new worktree lacks the ignored skill symlinks. Ideas raised, none decided: the branch recorded on a ticket, and the sessions that worked it recorded by id, doubted because work moves between machines. talk first. skills.md → ## Branches
2 change-record paths never ran live: a subagent resumed by typing into its row, whose record should arrive with the parent's next tool call, and a record left with nobody waiting for it. Both are unit-tested. Watch for them in the first real session that resumes a subagent. docs/dev/agents.md
A worker that starts its own subagent: that subagent's changes carry its own id, and whether the delivery reaches the top parent is unverified. Watch for it the first time a dispatched worker dispatches. docs/dev/agents.md
2 snapshots per command a worker runs, which is slow on a very large repository. Nothing has measured the cost. docs/dev/agents.md

Install and migration

Flow on native Windows. Today it runs on Linux, macOS and WSL: every hook is a $HOME shell line, every skill carries a bash line, and the install writes symlinks into ~/.local/bin. Native Windows runs hooks in PowerShell. Raised by the user 2026-09-16. management.md → ## Which operating systems
Migrate Delapse, with its project-local skills converted: the real test of the workflow, and where its conventions route into the project CLAUDE.md and docs/context/. Its skills are not Flow's. Each is copied into <project>/.claude/skills/<name>/ and committed with Delapse, or vendored into Flow's tree under a group once a second project wants it, reversed 2026-08-26. parked until the workflow is finished. skills.md

Context and session boundaries

Strip filler out of a dictated prompt before the model reads it: "umm", "you know", a stray "like". Low priority. Unbuildable as first designed: UserPromptSubmit cannot replace the prompt, only add text beside it, and a compressed copy beside the original makes the context bigger. Kept in case a workaround turns up, and the platform request that would unblock it is the one named in claude-code.md → ## Worth filing, decided 2026-09-21. Whatever strips must touch filler only, because hedges, questions and the order of a message are what instruction-or-thinking reads. parked

Drawing

The ASCII engine: hand it JSON, get back the drawing. You have read drawing.md and mostly disagree with its recommendation; state your direction before anything in there gets argued. talk first
An SVG engine: later than the ASCII one. It reopens the SVG ban, decided on a measured ~10 minutes and ~80k tokens per diagram in the main context, which a subagent changes. talk first

Other people, other models

Flow on another harness and on another model. Researched 2026-09-06 and 2026-09-07, and nothing is locked. Codex waits until Flow has shipped on Claude Code, ruled by the user 2026-09-18, reversing a ruling from the same morning that put the port before the management skill. Each harness may get its own mechanisms rather than one bent to fit both. The flow: prefix and the one real copy of each file in ~/.agents/ were built before the reversal and stay, since any harness needs them. Building it for a stranger split off into ## V1 on 2026-09-16. talk first. models.md. The parts:
- The Codex hooks, in ~/.codex/hooks.json. Walked hook by hook on 2026-09-18, with a design for each. The git switch takes 3 pieces there, because a Codex hook cannot answer "ask". models.md → ### The hooks on Codex, walked 2026-09-18
- Codex writes only inside the project, /tmp and writable_roots. Add ~/.flow to writable_roots under [sandbox_workspace_write] in ~/.codex/config.toml, so Flow's own files can be written from a Codex session. apply-migration.js also writes into ~/.claude/, ~/.codex/ and ~/.agents/, so from Codex it runs outside the sandbox, as a command asking for sandbox_permissions: require_escalated. SandboxWorkspaceWrite in repos/codex/codex-rs/config/src/types.rs
- Codex's memory stays off, as it is by default: [features] memories, in repos/codex/codex-rs/features/src/lib.rs. Claude Code keeps memory per project and Flow turns it off in home/settings.json. Codex's, when on, is one pile in ~/.codex/memories/, which would split what the 2 harnesses know again
- The Codex subagents, as TOML files in ~/.codex/agents/. Read import_subagents in repos/codex/codex-rs/external-agent-migration/src/source/cla.rs first
- A skill linked onto the whole machine never reaches Codex. flow skills on <name> --machine or --global links into ~/.claude/skills/. Codex reads ~/.agents/skills/ alone, so both would move there, with a link back for Claude Code the way Flow's own plugin folder has one
- flow audit reads Codex's session logs, ~/.codex/sessions/YYYY/MM/DD/rollout-<id>.jsonl, through a new scanner beside scan.js. Until it exists, work done in Codex is invisible to every audit query
- No rule is measured per model. Sonnet 4.6 puts the report before the edits. Opus 5 fails plain explanation with the reply rules loaded. A base rule set plus a per-model overlay is the shape, earned by the scorecard split rather than assumed
- Buy one coding plan and run Flow on it. GLM at $18, or Qwen at about ¥200, which bundles Kimi, GLM and MiniMax. It answers whether a non-Claude model holds Flow's rules, whether the quota survives Flow's token profile, and whether auto mode's classifier runs on the gateway model
- Replace WebSearch and WebFetch off Anthropic. WebSearch is a server-side Anthropic tool and stops. WebFetch preflights to api.anthropic.com and reportedly fails behind third-party providers. An MCP search server is the replacement, and CLAUDE.md's read-the-docs rule depends on both
- The audit's cost_usd and cache columns go wrong from the first non-Anthropic session: a flat plan has no per-request dollar figure
- Survey the remaining harnesses, deepseek-harness first

Research still to read

Read agent-toolkit/skills/game-changing-features and adhd for /flow:groundwork's idea generation. Both produce ideas rather than shape one, which is the half /flow:groundwork does least: game-changing-features forces the what would make this 10x more valuable question, and adhd is a divergent-ideation engine. adhd was already read once, on 2026-08-29, for its writing rules only: this is a different question and the earlier verdict does not carry. bash lab/scripts/repos.sh restores both
Read claude-task-master for initialization, the ticket system and the workflow shape. An AI task-management system that drops into Cursor, Windsurf, Roo and others, 28k stars, JavaScript, last pushed 2026-04-28. It is the closest thing to a direct competitor Flow has: it solves the same ticket problem for many editors where Flow solves it for one, so its onboarding and its task model are the 2 things to read. github.com/eyaltoledano/claude-task-master
Read deepseek-harness for ideas: a plugin-based agent harness where everything is a plugin, cloned at repos/deepseek-harness/. Ranked last here. github.com/deepseek-ai/deepseek-harness

FilesExpand file tree

backlog.md

Latest commit

History

backlog.md

File metadata and controls

Backlog

V1

The spine

The management skill, in build order

The skill system

Individual skills

flow, the tool

Rules and always-loaded files

The audit

Subagents and dispatch

Docs for whoever reads Flow

Install and migration

Context and session boundaries

Drawing

Other people, other models

After V1

The skill system

Individual skills

flow, the tool

Rules and always-loaded files

The audit

Subagents and dispatch

Install and migration

Context and session boundaries

Drawing

Other people, other models

Research still to read

`flow`, the tool

`flow`, the tool