flow

A command that runs a defined development task through planning, implementation, and review, then stops for human acceptance.

In plain words
What is it for?
Use it when a task already has a fixed scope and criteria and should pass through planning, coding, and review before someone accepts it.
Why use it?
It connects the main development stages into one unattended run while keeping final approval with a person.

Skill for Claude CodeCodex

Install

Getting it into your agent

One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.

agentmods
npx agentmods add skills/foliveira/harmonia/flow
Any agent
npx skills add foliveira/harmonia --skill flow
Clone the repo
git clone --depth 1 https://github.com/foliveira/harmonia

Made for: Claude Code, Codex.

Per session 40 Skills are progressive disclosure: only the name and description are preloaded; the body loads when the skill is used.
When invoked 1,092 The whole file, excluding the scripts and references it only reads on demand.
Security scan A 0 findings. Scan, not verified.
Origin original No closer match found in the catalogue.
Token cost

What it costs to keep this loaded

Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.

ModelPer sessionOnce invoked
Fable 5 $0.00040 $0.01092
Opus 5 $0.00020 $0.00546
Sonnet 5 $0.00008 $0.00218
Haiku 4.5 $0.00004 $0.00109

Measured 2d ago against content hash b2523616e4ff, method: parsed. Prices are Anthropic first-party input rates as of 2026-08-30, from the pricing page.

Security

Grade A, and why

flow scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 2d ago.

A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.

Nothing flagged

None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.

skills/flow/SKILL.md · 19 lines

How it starts

The opening of the file, as written. The whole thing — 19 lines — stays where its author put it; the contents beside it link to each section on GitHub.

Your working contract is the 4 rules; their digest is injected at session start - read ${CLAUDE_PLUGIN_ROOT}/core/RULES.md in full only if that digest is not in your context. Read the plan, implement, and review stages from ${CLAUDE_PLUGIN_ROOT}/core/lifecycle.yaml - their artifacts and gates are authoritative and define the transitions below; do not hardcode them. This runner is a meta-command, not a lifecycle stage: it holds no stage logic of its own and hardcodes no agent list. Each stage's own SKILL.md owns its orchestration - agents, the red-green loop, the panel, the gates - so execute those procedures and never restate them (R9).

Span: plan, then implement, then review, in one unattended session. Discuss stays manual because it is dialogic - the scoper and rubber-duck question the developer, so it cannot run unattended - and acceptance stays manual under the human-only gate. The runner chains neither.

  1. Entry gate - require a pinned scope that carries criteria: bash ${CLAUDE_PLUGIN_ROOT}/bin/workspace.sh resolve --repo . to locate the active workspace (never mint; on ambiguity or no-active-task, surface the script's message and stop). If the resolved workspace has no scope.md, refuse and point the developer to /harmonia:discuss - the runner starts from an already-pinned scope and never mints or auto-scopes. With scope.md present, gate its criteria before any work: run bash ${CLAUDE_PLUGIN_ROOT}/bin/check-criteria.sh --workspace <resolved-workspace> --repo . and halt on a non-zero exit - a criteria-less or non-machine-checkable scope is refused up front and pointed to /harmonia:discuss, the same refusal as the no-scope path (the check writes a status-validated receipts/check-criteria.json; the implement gate re-runs it, redundant but harmless). With scope and criteria confirmed, clear this run's stale prior-run output before any transition runs by calling bash ${CLAUDE_PLUGIN_ROOT}/bin/workspace.sh clear-span --repo .; the subcommand names the span out-artifacts and confines the removal to the resolved workspace, so this runner no longer restates that file list (it lives in bin/workspace.sh, exercised by tests/workspace.bats). scope.md is the pinned input and is never removed.
  2. Plan: execute the plan stage per ${CLAUDE_PLUGIN_ROOT}/skills/plan/SKILL.md. Scope is present, so the scoper consumes and refines it and never re-mints (R31). Before advancing, confirm the plan stage wrote its design.md out-artifact to the workspace; if it did not, halt and hand back.
  3. Implement: execute the implement stage per ${CLAUDE_PLUGIN_ROOT}/skills/implement/SKILL.md. Its pre-implement gate runs check-criteria. Inspect that gate's signal directly: halt when receipts/check-criteria.json records a status other than pass, or when check-criteria exits non-zero. On that signal the criteria are not machine-checkable, so implement writes no code - a stop before any work begins, unlike the review halt in step 5 which stops after the work with verdict.md and gate-report.md already on disk. Halt and hand back with the failing-criteria report and its receipt (receipts/check-criteria.json); do not advance.
  4. Advance to review - unconditional: once the implement stage has written its boundary.md and diff-summary.md out-artifacts, advance to review whether the red-green loop completed or exited incomplete at its max_rounds cap. The cap is not a gate failure; the loop records the disagreement in the workspace for the review lead to arbitrate. Do not inspect the coverage result to decide advancing.
  5. Review: execute the review stage per ${CLAUDE_PLUGIN_ROOT}/skills/review/SKILL.md. Take its verdict.md as authoritative. Halt on a failing review gate: if the verdict is not a pass because a coverage, criteria-run, or receipts gate failed, or because a test-immutability violation was recorded, stop and hand back with verdict.md and gate-report.md on disk. Never record a coverage override to keep going, and never override the lead's verdict.
  6. Stop before capture - hand back: the runner ends after review. It never writes the accepted marker and never runs bash ${CLAUDE_PLUGIN_ROOT}/bin/workspace.sh accept - acceptance is a human act. Never run accept on the developer's behalf. Hand back a summary telling the developer to exercise the built behavior, record acceptance via /harmonia:accept, then invoke /harmonia:capture as a separate manual act. The runner never enters capture.

Read the full file on GitHub · 19 lines

Changes

What this file has done since we first saw it

Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.

  1. 2d ago First seen · 19 lines · 40 tokens per session scan A b2523616e4ff

Subscribe to this mod's changes

flow is a skill published in the GitHub repository foliveira/harmonia (2 stars, last pushed 17d ago), licensed MIT. It adds 40 tokens to every session and 1,092 once invoked, about $0.0002 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-31.

Related

Other skills, from other repositories

todos

This chat has a shared, live TODO plan — your tasks for the conversation, which the user also edits. Read this skill and reach for the todo tools whenever a request takes more than a couple of steps. It covers the plan model (group = task, items = its steps; loose items are the user's lane), how to work it: propose…

JetBrains/thinkrail · 127 tokens

writing-workflow-skills

Use when adding a new workflow skill to pi-thinkrail-workflow, changing an existing workflow skill's role, trigger, handoff, or structure, or checking a workflow skill against the workflow system's rules. Not for authoring general-purpose skills outside this package.

JetBrains/thinkrail · 60 tokens

brainstorming

Use this BEFORE any creative or feature work: building a new feature, adding functionality, changing behavior, or making a nontrivial design decision. Turns the user's request into a validated design — recorded as a spec-graph task-spec — before any implementation. Do not skip this because a change looks small.

JetBrains/thinkrail · 65 tokens

shipping-a-pr

Use when finished work needs to ship as a pull request, or when the ask is about a PR — creating one, bringing it up to date, adding screenshots, watching its checks, or addressing its review comments. Not for reviewing a PR you are not shipping.

JetBrains/thinkrail · 57 tokens

writing-specs

Use when a workflow step drafts or revises a spec artifact — a goal-and-requirements, an architecture, or a module SPEC — or when a workflow skill names it at such a step. The shared quality bar for specs — not a workflow, nothing to execute.

JetBrains/thinkrail · 59 tokens

clarify

Adaptive requirements clarification with auto-depth routing. Shallow (Q&A) for simple tasks, Deep (exploration + DRAFT + PLAN) for complex ones. Escalates automatically when ambiguity persists.

mag123c/toktrack · 43 tokens