Agent skill

Flow Next Deps

by gmickel in gmickel/flow-next

Show spec dependency graph and execution order. An agent skill from gmickel/flow-next.

MITAuto-check passed

Install Flow Next Deps

skills CLI
$ npx skills add gmickel/flow-next --skill flow-next-deps -a claude-code

Project install by default; add -g for ~/.claude/skills/.

GitHub CLI
$ gh skill install gmickel/flow-next flow-next-deps --agent claude-code

Project scope by default; add --scope user for a personal install. Needs GitHub CLI 2.90.0 or later (public preview).

Manual copy
$ git clone --depth 1 https://github.com/gmickel/flow-next.git skills-src && mkdir -p .claude/skills && cp -r skills-src/plugins/flow-next/skills/flow-next-deps .claude/skills/flow-next-deps && rm -rf skills-src

Use ~/.claude/skills/ instead of .claude/skills for a personal install. The folder must contain SKILL.md.

Claude Code skills documentation · loads skills from .claude/skills/

Facts

Skill name
flow-next-deps
GitHub stars
709
Token cost
~1.9k tokens
SKILL.md length
340 words
Files
1
Skills in repo
43
Repo updated
First seen
Licence
MIT

At a glance

Show spec dependency graph and execution order. An agent skill from gmickel/flow-next.

  • Works in 3 steps: Gather Spec Data → Identify Blocking Chains → Compute Execution Phases
  • Asking whats blocking what
  • SKILL.md covers Preamble, Setup, Step 1: Gather Spec Data and Step 2: Identify Blocking Chains, plus 4 more sections
  • Calls jq

What it does

Flow Next Deps is an agent skill from gmickel/flow-next. Show spec dependency graph and execution order. Use when asking 'what's blocking what', 'execution order', 'dependency graph', 'what order should specs run', 'critical path', 'which specs can run in parallel'.

Its SKILL.md is about 1.9k tokens, which your agent loads only when the skill is triggered. It is a single SKILL.md file with no bundled scripts.

The repository describes itself as: 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… The licence is MIT.

When your agent uses it

  • Asking whats blocking what
  • Execution order
  • Dependency graph
  • What order should specs run

Example prompts

  • “s blocking what”
  • “execution order”
  • “dependency graph”
  • “/flow-next-deps”

Workflow steps

3 steps, taken from the step headings in SKILL.md.

  1. Gather Spec Data
  2. Identify Blocking Chains
  3. Compute Execution Phases

What it can do on your machine

Read from SKILL.md and the folder at commit c1ce203. It shows what the files ask for, not the result of running them.

  • Tool permissions

    Pre-approves nothing: there is no allowed-tools line, so your agent's usual permission prompts apply.

    From allowed-tools in the SKILL.md frontmatter.

  • Runs code

    Shell commands in SKILL.md call:

    • jq

    From the folder's file list and the shell code blocks in SKILL.md.

  • Network

    No URLs in SKILL.md.

    From URLs in SKILL.md, links to its own repository left out.

  • Credentials

    Names no API keys, tokens, secrets or passwords.

    From names ending in _API_KEY, _TOKEN, _SECRET, _KEY or _PASSWORD in SKILL.md.

Context cost

Flow Next Deps loads about 1.9k tokens when it runs. Until then it costs about 56 tokens; SKILL.md has 340 words of instructions outside code blocks.

Always · name and description, kept in context so the agent knows when to use it
~56
When it runs · the whole SKILL.md, loaded when a task matches
~1.9k

Estimates: characters ÷ 4, the usual rule of thumb; real counts depend on the model's tokenizer. Scripts and assets cost tokens only if the agent reads them.

Safety

Auto-check passed

The automated check found no risky patterns in SKILL.md.

Automated static check — not a guarantee. Review scripts before installing. It scans the text of SKILL.md for risky patterns (piping downloads into a shell, reading credential files, hidden Unicode, destructive commands); files beside SKILL.md are not scanned.

SKILL.md

The full file from gmickel/flow-next at commit c1ce203, republished under its MIT licence (© gmickel). 340 words, ~1,878 tokens.

Download SKILL.mdSave it as .claude/skills/flow-next-deps/SKILL.md (or your agent's skills folder).
name
flow-next-deps
description
Show spec dependency graph and execution order. Use when asking 'what's blocking what', 'execution order', 'dependency graph', 'what order should specs run', 'critical path', 'which specs can run in parallel'.

Flow-Next Dependency Graph

Visualize spec dependencies, blocking chains, and execution phases.

Preamble

flowctl is bundled with the plugin (not on PATH). Define once; subsequent blocks use $FLOWCTL:

bash
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"

Setup

bash
$FLOWCTL detect --json | jq -e '.exists' >/dev/null && echo "OK: .flow/ exists" || echo "ERROR: run $FLOWCTL init"
command -v jq >/dev/null 2>&1 && echo "OK: jq installed" || echo "ERROR: brew install jq"

Step 1: Gather Spec Data

Build a consolidated view of all specs with their dependencies — a single heavy per-spec loop for the whole skill. Steps 2 and 3 reuse the cached file (bash vars do not survive across tool calls, so the cache is a file at a literal agent-composed path — compose <suffix> once, e.g. 4 random chars, and reuse the same literal path in every later block):

bash
# ONE gather — Steps 2 and 3 read this file; never re-run the per-spec loop
SPECS_FILE="${TMPDIR:-/tmp}/flow-deps-specs-<suffix>.json"
$FLOWCTL specs --json | jq -r '.specs[].id' | while read id; do
  $FLOWCTL show "$id" --json | jq -c '{
    id: .id,
    title: .title,
    status: .status,
    plan_review: .plan_review_status,
    deps: (.depends_on_epics // [])
  }'
done | jq -s '.' > "$SPECS_FILE"
cat "$SPECS_FILE"
Done when
  • $SPECS_FILE exists at the composed literal path and parses as a JSON array with one object per spec returned by flowctl specs --json.
  • The per-spec flowctl show loop has run exactly once for this invocation. Steps 2 and 3 read that file. A second run of the gather loop has broken this.

Step 2: Identify Blocking Chains

Determine which specs are ready vs blocked (pure jq, works on any shell):

bash
# Reuse the Step 1 gather — same literal path, NO re-fetch (one heavy loop total)
SPECS_FILE="${TMPDIR:-/tmp}/flow-deps-specs-<suffix>.json"

# Compute blocking status
jq -r '
  # Build status lookup
  (map({(.id): .status}) | add // {}) as $status |

  # Check each non-done spec
  .[] | select(.status != "done") |
  .id as $id | .title as $title |

  # Find deps that are not done
  ([.deps[] | select($status[.] != "done")] | join(", ")) as $blocked_by |

  if ($blocked_by | length) == 0 then
    "READY: \($id) - \($title)"
  else
    "BLOCKED: \($id) - \($title) (by: \($blocked_by))"
  end
' "$SPECS_FILE"
Done when
  • Every non-done spec in $SPECS_FILE emitted exactly one READY: or BLOCKED: line, and each BLOCKED: line names the specific deps holding it.
  • The jq ran against the cached file, not a fresh flowctl show sweep.

Step 3: Compute Execution Phases

Group specs into parallel execution phases:

bash
# Reuse the Step 1 gather — same literal path, NO re-fetch (one heavy loop total)
SPECS_FILE="${TMPDIR:-/tmp}/flow-deps-specs-<suffix>.json"

# Phase assignment algorithm (run in jq for reliability)
jq '
  # Build status lookup
  (map({(.id): .status}) | add // {}) as $status |

  # Filter to non-done specs
  [.[] | select(.status != "done")] as $open |

  # Assign phases iteratively
  reduce range(10) as $phase (
    {assigned: [], result: [], open: $open};

    .assigned as $assigned |
    .open as $remaining |

    # Find specs not yet assigned whose deps are all done or in earlier phases
    ([.open[] | select(
      ([.id] | inside($assigned) | not) and
      ((.deps // []) | all(. as $d | $status[$d] == "done" or ($assigned | index($d))))
    )] | map(.id)) as $ready |

    if ($ready | length) > 0 then
      .result += [{phase: ($phase + 1), specs: [.open[] | select(.id | IN($ready[]))]}] |
      .assigned += $ready
    else . end
  ) |
  # Emit the phases AND the residue: any open spec never assigned is UNRESOLVABLE — a
  # dependency cycle (A→B→A), a dep on a missing/closed spec, or a chain deeper than 10.
  # Dropping it silently is the one way /deps gives a WRONG answer (the graph it exists to
  # expose hides the deadlock). Surface it, with the offending deps for diagnosis.
  .assigned as $asg |
  { phases: .result,
    deadlocked: [ $open[] | select(.id as $i | ($asg | index($i)) | not)
                  | { id, status,
                      unresolved_deps: [ (.deps // [])[] | select(. as $d | ($asg | index($d)) or ($status[$d] == "done") | not) ] } ] }
' "$SPECS_FILE"
Done when
  • The jq result carries both .phases and .deadlocked, and every open spec appears in exactly one of them.
  • The report is rendered from .phases and .deadlocked. Phases narrated from a reading of the spec titles have broken this.

Output Format

Present results as:

markdown
## Spec Dependency Graph

### Status Overview

| Spec | Title | Status | Dependencies | Blocked By |
|------|-------|--------|--------------|------------|
| **fn-1-add-auth** | Add Authentication | **READY** | - | - |
| fn-2-add-oauth | Add OAuth Login | blocked | fn-1-add-auth | fn-1-add-auth |
| fn-3-user-profile | User Profile Page | blocked | fn-1-add-auth, fn-2-add-oauth | fn-2-add-oauth |

### Execution Phases

Render from the jq result's `.phases`:

| Phase | Specs | Can Start |
|-------|-------|-----------|
| **1** | fn-1-add-auth | **NOW** |
| 2 | fn-2-add-oauth | After Phase 1 |
| 3 | fn-3-user-profile | After Phase 2 |

### ⚠️ Deadlocked / Unresolvable

**This section renders exactly when `.deadlocked` is non-empty** — and when it does, it is the
most important part of the report. Each entry is an open spec that could not be placed in
any phase: a dependency **cycle**, a dep on a **missing/closed** spec, or a chain deeper
than 10. These are invisible to `ready`/`flow --auto` (they just never become ready) — this is the
one place the graph surfaces them.

| Spec | Status | Unresolved deps | Likely cause |
|------|--------|-----------------|--------------|
| fn-7-x | blocked | fn-9-y | fn-9-y not found / closed, or a cycle fn-7↔fn-9 |

For each, state the likely cause: if two deadlocked specs list each other → **cycle** (fix
with `flowctl spec rm-dep`); if an unresolved dep isn't among the open specs → **missing or
closed dependency**. **Every entry of `.deadlocked` reaches the report.** A report that lists phases while silently dropping an open spec has broken this.

### Critical Path

fn-1-add-auth → fn-2-add-oauth → fn-3-user-profile (3 phases)

This skill is read-only inspection. Edge changes are reported as commands for the operator to run — flowctl spec add-dep <spec> <dep> / rm-dep <spec> <dep>. A run that executes either command itself, or edits a spec file, has broken this.

Quick One-Liner

For a fast dependency check:

bash
$FLOWCTL specs --json | jq -r '.specs[] | select(.status != "done") | "\(.id): \(.title) [\(.status)]"'

When to Use

  • "What's the execution order for specs?"
  • "What's blocking progress?"
  • "Show me the dependency graph"
  • "What's the critical path?"
  • "Which specs can run in parallel?"
  • "What should I work on next?"

© gmickel, MIT. Rendered from Markdown: HTML in the file is shown as text, images as links, and headings moved down two levels. Raw file

Files

Just SKILL.md in plugins/flow-next/skills/flow-next-deps of gmickel/flow-next.

Open the folder on GitHubat commit c1ce203

Compare with similar skills

Flow Next Deps next to the 5 skills that share the most tags, products or categories with it. Stars are the repository's; “used in” counts other GitHub owners with a copy.

Flow Next Deps compared with similar skills
SkillStarsUsed inTokensAuto-checkLicenceRepo updated
Flow Next Deps this skillgmickel/flow-next709—~1.9kAutomated safety check: PassMIT
Dependency Scanningsickn33/agentic-awesome-skills47k1 repos~2.4kAutomated safety check: PassMIT
Depsickn33/agentic-awesome-skills47k1 repos~1.8kAutomated safety check: PassMIT
Dependency Checkruvnet/ruflo74k—~258Automated safety check: PassMIT
Logseq Dependency Upgradelogseq/logseq45k—~1.1kAutomated safety check: PassAGPL-3.0
Askagenticnotetaking/arscontexta3.5k—~5.7kAutomated safety check: PassMIT

Similar skills

  • Dependency Scanning

    sickn33/agentic-awesome-skills

    Scan package dependencies for known vulnerabilities using Snyk, Dependabot, and OWASP Dependency-Check.

    47k GitHub starsUsed in 1 repo~2.4k tokens
    SecurityAuto-check passed
  • Dep

    sickn33/agentic-awesome-skills

    Handles containerization, CI/CD pipelines, and deployment setup.

    47k GitHub starsUsed in 1 repo~1.8k tokens
    DevOps & CloudAuto-check passed
  • Dependency Check

    ruvnet/ruflo

    Scan project dependencies for known vulnerabilities and CVEs.

    74k GitHub stars~258 tokensUpdated today
    SecurityAuto-check passed
  • Audit, plan, and refresh dependency upgrades for the Logseq repository by scanning every non-gitignored package.json, deps.edn, bb.edn and nbb.edn manifest, checking latest upstream versions…

    45k GitHub stars~1.1k tokensUpdated today
    Knowledge ManagementAuto-check passed
  • Ask

    agenticnotetaking/arscontexta

    Query the bundled research knowledge graph for methodology guidance.

    3.5k GitHub stars~5.7k tokensUpdated 7 mo ago
    Knowledge ManagementAuto-check passed
  • Graph

    agenticnotetaking/arscontexta

    Interactive knowledge graph analysis. An agent skill from agenticnotetaking/arscontexta.

    3.5k GitHub stars~4.9k tokensUpdated 7 mo ago
    Knowledge ManagementAuto-check: notes

More from gmickel/flow-next

All 43 skills in this repo
  • Flow Next Resolve PR

    gmickel/flow-next

    Resolve PR review feedback. An agent skill from gmickel/flow-next.

    709 GitHub stars~1.1k tokensUpdated today
    Auto-check passed
  • Flow Next Resolve PR

    gmickel/flow-next

    Resolve PR review feedback — fetch unresolved threads, triage, dispatch per-thread resolver agents, validate, commit, reply + resolve via GraphQL.

    709 GitHub stars~1.1k tokensUpdated today
    Auto-check passed
  • Flow Next

    gmickel/flow-next

    Manage .flow/ tasks and specs. An agent skill from gmickel/flow-next.

    709 GitHub stars~1.6k tokensUpdated today
    Auto-check passed
  • Flow Next Audit

    gmickel/flow-next

    Audit .flow/memory/ entries against the current codebase and decide Keep / Update / Consolidate / Replace / Delete / Harden per entry.

    709 GitHub stars~3.1k tokensUpdated today
    Auto-check: notes
  • Flow Next Capture

    gmickel/flow-next

    Save the current conversation as a source-tagged flow-next spec, then offer review or editing.

    709 GitHub stars~1.9k tokensUpdated today
    Auto-check: notes
  • Flow Next Chart

    gmickel/flow-next

    Decision-map discovery for one oversized unclear idea before capture.

    709 GitHub stars~2.7k tokensUpdated today
    Auto-check: notes

Questions about Flow Next Deps

What does Flow Next Deps do?

Show spec dependency graph and execution order. An agent skill from gmickel/flow-next. Flow Next Deps is an agent skill from gmickel/flow-next. Show spec dependency graph and execution order.

When should I use Flow Next Deps?

Flow Next Deps fits situations like: asking whats blocking what; execution order; dependency graph; what order should specs run.

How do I install Flow Next Deps in Claude Code?

Run `npx skills add gmickel/flow-next --skill flow-next-deps -a claude-code`. Or copy the skill folder (plugins/flow-next/skills/flow-next-deps in gmickel/flow-next) into .claude/skills/flow-next-deps in your project. Claude Code loads it when a task matches its description.

How do I install Flow Next Deps in Codex?

Run `npx skills add gmickel/flow-next --skill flow-next-deps -a codex`. Or copy the skill folder (plugins/flow-next/skills/flow-next-deps in gmickel/flow-next) into .agents/skills/flow-next-deps in your project. Codex loads it when a task matches its description.

Can I use Flow Next Deps in Cursor, Gemini CLI or GitHub Copilot?

Cursor, Gemini CLI, GitHub Copilot and OpenCode also load SKILL.md folders. With the skills CLI, run `npx skills add gmickel/flow-next --skill flow-next-deps -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/flow-next-deps, .gemini/skills/flow-next-deps, .github/skills/flow-next-deps and .opencode/skills/flow-next-deps in your project.

What does Flow Next Deps need to run?

Going by SKILL.md and its folder, Flow Next Deps needs the command-line tools its instructions call (jq).

Does Flow Next Deps access the network?

SKILL.md contains no URLs. Any network use would come from the scripts or tools the agent runs. This is read from the text; nothing was executed.

Is Flow Next Deps safe to install?

Our automated static check of SKILL.md found no risky patterns, such as piping downloads into a shell, reading credential files or hidden Unicode. It is not a guarantee. Review the folder before installing.

What licence does Flow Next Deps use?

Flow Next Deps is published under the MIT licence (the repository's licence). It allows redistribution, so the full SKILL.md is shown on this page.

How many tokens does Flow Next Deps use?

About 1.9k tokens (SKILL.md is roughly 7.5k characters). Agents keep only the skill's name and description in context until a task matches; then they load SKILL.md in full.

What are the alternatives to Flow Next Deps?

Skills that share tags, products or a category with Flow Next Deps: Dependency Scanning (sickn33/agentic-awesome-skills, 47k stars), Dep (sickn33/agentic-awesome-skills, 47k stars), Dependency Check (ruvnet/ruflo, 74k stars) and Logseq Dependency Upgrade (logseq/logseq, 45k stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.

Who maintains Flow Next Deps?

gmickel (a GitHub user) maintains it in gmickel/flow-next, which has 709 GitHub stars. The repository holds 43 skills in this directory. The repository was last updated on October 10, 2026.

Source: gmickel/flow-next on GitHub. Facts on this page come from the repository at the commit we read; the author's words are quoted as theirs.