Flow planning
Context-Driven Development toolkit for AI agents — spec-first planning, TDD workflow, and Beads integration.
npx -y skills add cofin/flow --skill flow-planningAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 14 stars14 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
Use when drafting PRDs, researching, planning, refining, revising, or creating .agents/specs/<flow_id>/spec.md worksheets for Flow.
SKILL.md
3.4 KB, 705 tokens by cl100k_base, as published. Nobody here has run it
Flow Planning
Use this lifecycle skill for PRDs, research, single-flow planning, refinement, revisions, and task creation.
Workflow
- Read project context, patterns, knowledge chapters, and relevant existing specs before asking questions.
- Research code paths and external APIs before locking implementation decisions.
- Create PRDs as roadmap epics and single-flow specs as implementation worksheets.
- Refine until tasks include concrete files, behavior, tests, commands, and acceptance criteria.
- Create Beads epics/tasks and sync markdown views according to policy.
Interrogate Before Finalizing (Grill)
Before locking a PRD, spec, or refined worksheet, interrogate the plan until every decision branch is resolved. This is how Flow meets the Zero-Ambiguity Standard and the Stateless Executor Test — apply it in flow-prd, flow-plan, and especially flow-refine.
- Ask one question at a time and wait for the answer before the next. Walk the decision tree top-down, resolving dependencies between decisions in order.
- For every question, give your recommended answer and the trade-off, so the user confirms rather than composes from scratch.
- If a question is answerable from the repo, explore the codebase /
patterns.md/knowledge//tech-stack.mdinstead of asking. Only ask product or trade-off questions a human must decide. - Challenge the plan against the project's domain language: reuse the terminology already in
patterns.mdandknowledge/chapters, and flag/resolve term conflicts before finalizing. - Record decisions that are hard to reverse, surprising, and a real trade-off into
knowledge/(orlearnings.md); skip low-value notes. - Stop only when no open branch remains and a zero-context executor could implement from the artifact alone.
- The finished spec/worksheet doubles as a handoff: reference existing artifacts (PRD, patterns, knowledge, affected files) rather than duplicating them, and name the next skill to invoke. (If the harness exposes
grill-me/grill-with-docs/handoffskills, you may invoke them to drive these steps; otherwise apply the discipline directly.)
Guardrails
- Planning must be decision-complete; do not defer obvious research to implementation.
- Ask only product or tradeoff questions that cannot be answered from the repo.
- Store plans under
.agents/specs/<flow_id>/, not ad hoc docs paths. - Do not modify production code during planning.
Validation
- Confirm every requirement maps to an implementation task and test scenario.
- Confirm tasks are small enough for a low-context executor to complete without guessing.
- Run spec review or code-reviewer validation before presenting final planning artifacts when available.
References Index
Example
User: "Plan skill trigger optimization."
Action: inspect current skills and validators, ask unresolved product tradeoffs, create a Flow spec with Beads tasks, and refine until the implementation path is explicit.
What ships with it: 1 file
140 B alongside SKILL.md
agents/
- openai.yaml140 B
Gives 1 of the 12 instructions most plan spec skills give in 705 tokens
Counted across 1,099 of the 1,860 authors here whose files we hold, read 2026-08-07
- Ask one question at a timehere, and in 51 of 1099
- Break plans into vertical slicesin 29 of 1099, across 11 files
- Publish issues in dependency orderin 27 of 1099, across 9 files
- Iterate until user approves the breakdownin 25 of 1099, across 7 files
- Explore the repository to understand the codebase statein 24 of 1099, across 7 files
- Use domain glossary vocabularyin 23 of 1099, across 5 files
- Apply correct triage labels to published issuesin 23 of 1099, across 5 files
- Prefer AFK slices over HITLin 22 of 1099, across 7 files
- Write a specification before writing any codein 22 of 1099, across 14 files
- Write failing tests before implementation codein 22 of 1099, across 20 files
- Ask clarifying questions until requirements are concretein 21 of 1099, across 13 files
- Respect existing architecture decision recordsin 20 of 1099, across 5 files
Said here and by no other author read
- Research code paths before locking decisions
- Create PRDs as epics and specs as worksheets
- Refine tasks until concrete and unambiguous
- Provide recommended answers with trade-offs
- Record significant decisions in knowledge files
- Store plans under the designated specs path
Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.