/flow-next
Manage .flow/ tasks and specs. Triggers: 'show me my tasks', 'list specs', 'what tasks are there', 'add a task', 'create task', 'what's ready', 'task status', 'show fn-1-add-oauth'. NOT for /flow-next:plan or /flow-next:work.
Claude Code
$ npx -y skills add gmickel/flow-next --skill flow-next --agent claude-code
Codex
$ npx skills add gmickel/flow-next --skill flow-next -a codex -y
Cursor
$ npx skills add gmickel/flow-next --skill flow-next -a cursor -y
Gemini CLI
$ npx skills add gmickel/flow-next --skill flow-next -a gemini-cli -y
GitHub Copilot
$ npx skills add gmickel/flow-next --skill flow-next -a github-copilot -y
OpenCode
$ npx skills add gmickel/flow-next --skill flow-next -a opencode -y
Windsurf
$ npx skills add gmickel/flow-next --skill flow-next -a windsurf -y
SKILL.md
flow-next.SKILL.mdname: flow-next
description: "Manage .flow/ tasks and specs. Triggers: 'show me my tasks', 'list specs', 'what tasks are there', 'add a task', 'create task', 'what's ready', 'task status', 'show fn-1-add-oauth'. NOT for /flow-next:plan or /flow-next:work."
Flow-Next Task Management
Quick task operations in `.flow/`. To build or plan a feature use `/flow-next:flow`; it picks the route.
Preamble
**CRITICAL: flowctl is BUNDLED — NOT installed globally.** `which flowctl` will fail (expected). Define once; subsequent blocks use `$FLOWCTL`:
FLOWCTL="${DROID_PLUGIN_ROOT:-${CLAUDE_PLUGIN_ROOT}}/scripts/flowctl"
[ -x "$FLOWCTL" ] || FLOWCTL="<plugin-root>/scripts/flowctl" # <plugin-root> = the directory two levels above this skill's SKILL.md file (the harness gave you that file's absolute path when the skill loaded); substitute it literally
[ -x "$FLOWCTL" ] || FLOWCTL=".flow/bin/flowctl"**Discover all commands/options:**
$FLOWCTL --help
$FLOWCTL <command> --help # e.g., $FLOWCTL task --help
Quick Reference
# Check if .flow exists
$FLOWCTL detect --json
# Initialize (if needed)
$FLOWCTL init --json
# List everything (specs + tasks grouped)
$FLOWCTL list --json
# List all specs
$FLOWCTL specs --json
# List all tasks (or filter by spec/status)
$FLOWCTL tasks --json
$FLOWCTL tasks --spec fn-1-add-oauth --json
$FLOWCTL tasks --status todo --json
# View spec with all tasks
$FLOWCTL show fn-1-add-oauth --json
$FLOWCTL cat fn-1-add-oauth # Spec markdown
# View single task
$FLOWCTL show fn-1-add-oauth.2 --json
$FLOWCTL cat fn-1-add-oauth.2 # Task spec
# What's ready to work on?
$FLOWCTL ready --spec fn-1-add-oauth --json
# Create task under existing spec
$FLOWCTL task create --spec fn-1-add-oauth --title "Fix bug X" --json
# Set task description and acceptance (combined, fewer writes; unique per-task temp paths)
$FLOWCTL task set-spec fn-1-add-oauth.2 --description "${TMPDIR:-/tmp}/flow-desc-fn-1-add-oauth.2.md" --acceptance "${TMPDIR:-/tmp}/flow-accept-fn-1-add-oauth.2.md" --json
# Or use stdin with heredoc (no temp file):
$FLOWCTL task set-description fn-1-add-oauth.2 --file - --json <<'EOF'
Description here
EOF
# Start working on task
$FLOWCTL start fn-1-add-oauth.2 --json
# Mark task done (unique per-task temp paths)
echo "What was done" > "${TMPDIR:-/tmp}/flow-summary-fn-1-add-oauth.2.md"
echo '{"commits":["abc123"],"tests":["npm test"],"prs":[]}' > "${TMPDIR:-/tmp}/flow-evidence-fn-1-add-oauth.2.json"
$FLOWCTL done fn-1-add-oauth.2 --summary-file "${TMPDIR:-/tmp}/flow-summary-fn-1-add-oauth.2.md" --evidence-json "${TMPDIR:-/tmp}/flow-evidence-fn-1-add-oauth.2.json" --json
# Validate structure (one spec; repo-wide through a counts-and-errors projection)
$FLOWCTL validate --spec fn-1-add-oauth --json
$FLOWCTL validate --all --json | jq '{valid, total_specs, total_tasks, total_errors, total_warnings, root_errors, failing: [.specs[] | select(.errors | length > 0) | {spec, errors}]}'Common Patterns
"Add a task for X"
1. Find relevant spec:
# List all specs
$FLOWCTL specs --json
# Or show a specific spec to check its scope
$FLOWCTL show fn-1 --json
2. Create task:
$FLOWCTL task create --spec fn-N --title "Short title" --json
3. Add description + acceptance (combined):
# Unique per-task temp paths — written + consumed in this one block
cat > "${TMPDIR:-/tmp}/flow-desc-fn-N.M.md" << 'EOF'
**Bug/Feature:** Brief description
**Details:**
- Point 1
- Point 2
EOF
cat > "${TMPDIR:-/tmp}/flow-accept-fn-N.M.md" << 'EOF'
- [ ] Criterion 1
- [ ] Criterion 2
EOF
$FLOWCTL task set-spec fn-N.M --description "${TMPDIR:-/tmp}/flow-desc-fn-N.M.md" --acceptance "${TMPDIR:-/tmp}/flow-accept-fn-N.M.md" --json"What tasks are there?"
# All tasks, projected (add --spec fn-1-add-oauth for one spec)
$FLOWCTL tasks --json | jq -c '[.tasks[] | {id, title, status, spec}]'
# Ready tasks for a spec
$FLOWCTL ready --spec fn-1-add-oauth --json"What's next?"
$FLOWCTL brief
`brief` is orientation only: it omits blocked and dependency-waiting tasks, so never answer a task listing from it.
"Show me task X"
$FLOWCTL show fn-1-add-oauth.2 --json # Metadata
$FLOWCTL cat fn-1-add-oauth.2 # Full spec
(Legacy `fn-1.2` / `fn-1-xxx.2` still works.)
Create new spec (rare - usually via /flow-next:flow or /flow-next:capture)
$FLOWCTL spec create --title "Spec title" --json
# Returns: {"success": true, "id": "fn-N-spec-title", ...}Close a spec as won't-do
$FLOWCTL spec close fn-1-add-oauth --retire superseded --by fn-2-sso --json
Pick the reason that is true: `superseded` (another spec replaced it), `delivered-elsewhere` (it shipped under another spec or pull request) or `moot` (it is no longer needed, including a decision not to build it). Name each successor with `--by`. Its never-run tasks read `retired`, not `done`.
Before closing any spec: read [references/declined.md](references/declined.md); it decides whether the close earns a `.flow/memory/declined/` file.
ID Format
- Spec: `fn-N-slug` where slug is derived from title (e.g., `fn-1-add-oauth`, `fn-2-fix-login-bug`)
- Task: `fn-N-slug.M` (e.g., `fn-1-add-oauth.1`, `fn-2-fix-login-bug.2`)
Legacy formats `fn-N` and `fn-N-xxx` (random 3-char suffix) are still supported.
Notes
- Run `$FLOWCTL --help` to discover all commands and options
- **Every write goes through a flowctl subcommand**, except the `.flow/memory/declined/*.md` file above, which has no flowctl verb. A session that edits `.flow/` JSON or task markdown by hand has broken this.
- **Every read comes from `.flow/` state**, via `--json` (`detect`, `list`, `specs`, `tasks`, `show`, `ready`) or `cat` for markdown. An answer assembled from files skimmed by hand has broken this.
- **A task marked complete
Read more
name: flow-next description: "Manage .flow/ tasks and specs. Triggers: 'show me my tasks', 'list specs', 'what tasks are there', 'add a task', 'create task', 'what's ready', 'task status', 'show fn-1-add-oauth'. NOT for /flow-next:plan or /flow-next:work."
Flow-Next Task Management
Quick task operations in `.flow/`. To build or plan a feature use `/flow-next:flow`; it picks the route.
Preamble
**CRITICAL: flowctl is BUNDLED — NOT installed globally.** `which flowctl` will fail (expected). Define once; subsequent blocks use `$FLOWCTL`:
FLOWCTL="${DROID_PLUGIN_ROOT:-${CLAUDE_PLUGIN_ROOT}}/scripts/flowctl"
[ -x "$FLOWCTL" ] || FLOWCTL="<plugin-root>/scripts/flowctl" # <plugin-root> = the directory two levels above this skill's SKILL.md file (the harness gave you that file's absolute path when the skill loaded); substitute it literally
[ -x "$FLOWCTL" ] || FLOWCTL=".flow/bin/flowctl"**Discover all commands/options:**
$FLOWCTL --help $FLOWCTL <command> --help # e.g., $FLOWCTL task --help
Quick Reference
# Check if .flow exists
$FLOWCTL detect --json
# Initialize (if needed)
$FLOWCTL init --json
# List everything (specs + tasks grouped)
$FLOWCTL list --json
# List all specs
$FLOWCTL specs --json
# List all tasks (or filter by spec/status)
$FLOWCTL tasks --json
$FLOWCTL tasks --spec fn-1-add-oauth --json
$FLOWCTL tasks --status todo --json
# View spec with all tasks
$FLOWCTL show fn-1-add-oauth --json
$FLOWCTL cat fn-1-add-oauth # Spec markdown
# View single task
$FLOWCTL show fn-1-add-oauth.2 --json
$FLOWCTL cat fn-1-add-oauth.2 # Task spec
# What's ready to work on?
$FLOWCTL ready --spec fn-1-add-oauth --json
# Create task under existing spec
$FLOWCTL task create --spec fn-1-add-oauth --title "Fix bug X" --json
# Set task description and acceptance (combined, fewer writes; unique per-task temp paths)
$FLOWCTL task set-spec fn-1-add-oauth.2 --description "${TMPDIR:-/tmp}/flow-desc-fn-1-add-oauth.2.md" --acceptance "${TMPDIR:-/tmp}/flow-accept-fn-1-add-oauth.2.md" --json
# Or use stdin with heredoc (no temp file):
$FLOWCTL task set-description fn-1-add-oauth.2 --file - --json <<'EOF'
Description here
EOF
# Start working on task
$FLOWCTL start fn-1-add-oauth.2 --json
# Mark task done (unique per-task temp paths)
echo "What was done" > "${TMPDIR:-/tmp}/flow-summary-fn-1-add-oauth.2.md"
echo '{"commits":["abc123"],"tests":["npm test"],"prs":[]}' > "${TMPDIR:-/tmp}/flow-evidence-fn-1-add-oauth.2.json"
$FLOWCTL done fn-1-add-oauth.2 --summary-file "${TMPDIR:-/tmp}/flow-summary-fn-1-add-oauth.2.md" --evidence-json "${TMPDIR:-/tmp}/flow-evidence-fn-1-add-oauth.2.json" --json
# Validate structure (one spec; repo-wide through a counts-and-errors projection)
$FLOWCTL validate --spec fn-1-add-oauth --json
$FLOWCTL validate --all --json | jq '{valid, total_specs, total_tasks, total_errors, total_warnings, root_errors, failing: [.specs[] | select(.errors | length > 0) | {spec, errors}]}'Common Patterns
"Add a task for X"
1. Find relevant spec:
# List all specs $FLOWCTL specs --json # Or show a specific spec to check its scope $FLOWCTL show fn-1 --json
2. Create task:
$FLOWCTL task create --spec fn-N --title "Short title" --json
3. Add description + acceptance (combined):
# Unique per-task temp paths — written + consumed in this one block
cat > "${TMPDIR:-/tmp}/flow-desc-fn-N.M.md" << 'EOF'
**Bug/Feature:** Brief description
**Details:**
- Point 1
- Point 2
EOF
cat > "${TMPDIR:-/tmp}/flow-accept-fn-N.M.md" << 'EOF'
- [ ] Criterion 1
- [ ] Criterion 2
EOF
$FLOWCTL task set-spec fn-N.M --description "${TMPDIR:-/tmp}/flow-desc-fn-N.M.md" --acceptance "${TMPDIR:-/tmp}/flow-accept-fn-N.M.md" --json"What tasks are there?"
# All tasks, projected (add --spec fn-1-add-oauth for one spec)
$FLOWCTL tasks --json | jq -c '[.tasks[] | {id, title, status, spec}]'
# Ready tasks for a spec
$FLOWCTL ready --spec fn-1-add-oauth --json"What's next?"
$FLOWCTL brief
`brief` is orientation only: it omits blocked and dependency-waiting tasks, so never answer a task listing from it.
"Show me task X"
$FLOWCTL show fn-1-add-oauth.2 --json # Metadata $FLOWCTL cat fn-1-add-oauth.2 # Full spec
(Legacy `fn-1.2` / `fn-1-xxx.2` still works.)
Create new spec (rare - usually via /flow-next:flow or /flow-next:capture)
$FLOWCTL spec create --title "Spec title" --json
# Returns: {"success": true, "id": "fn-N-spec-title", ...}Close a spec as won't-do
$FLOWCTL spec close fn-1-add-oauth --retire superseded --by fn-2-sso --json
Pick the reason that is true: `superseded` (another spec replaced it), `delivered-elsewhere` (it shipped under another spec or pull request) or `moot` (it is no longer needed, including a decision not to build it). Name each successor with `--by`. Its never-run tasks read `retired`, not `done`.
Before closing any spec: read [references/declined.md](references/declined.md); it decides whether the close earns a `.flow/memory/declined/` file.
ID Format
- Spec: `fn-N-slug` where slug is derived from title (e.g., `fn-1-add-oauth`, `fn-2-fix-login-bug`)
- Task: `fn-N-slug.M` (e.g., `fn-1-add-oauth.1`, `fn-2-fix-login-bug.2`)
Legacy formats `fn-N` and `fn-N-xxx` (random 3-char suffix) are still supported.
Notes
- Run `$FLOWCTL --help` to discover all commands and options
- **Every write goes through a flowctl subcommand**, except the `.flow/memory/declined/*.md` file above, which has no flowctl verb. A session that edits `.flow/` JSON or task markdown by hand has broken this.
- **Every read comes from `.flow/` state**, via `--json` (`detect`, `list`, `specs`, `tasks`, `show`, `ready`) or `cat` for markdown. An answer assembled from files skimmed by hand has broken this.
- **A task marked complete
Faster than your agent alone. And better. A workflow plugin that takes a bug, idea or ticket to a verified pull request: specs, cross-model review by risk, live QA, receipts in your repo. Claude Code · Codex · Cursor · Droid · Grok Build · OpenCode · Muse Code.
Other skills on flow-next.
More skills from other plugins.
brainstorming
You MUST use this before any creative work - creating features, building components, adding functionality, modifying behavior, or…
ask-matt
Ask which skill or flow fits your situation. A router over the skills in this repo.
Questions about flow-next.
- Which coding agents can use flow-next?
- flow-next installs in Claude Code, Codex, Cursor, Gemini CLI, GitHub Copilot, OpenCode and Windsurf with the skills CLI, using each agent's flag shown on this page. Flowy's auto-invocation, which fires a skill when your prompt matches, runs in Claude Code only.

