flow-next-sync
Updates project specs to match actual implementation when code drifts from the original plan.
Install
mkdir -p .claude/skills/flow-next-sync && curl -L -o skill.zip "https://agentskills.codes/api/skills/download/3595" && unzip -o skill.zip -d .claude/skills/flow-next-sync && rm skill.zipInstalls to .claude/skills/flow-next-sync
Activation
This is the description your AI agent reads to decide when to run this skill — the better it matches your request, the more reliably it fires.
Manually trigger plan-sync to update downstream task specs after implementation drift. Use when code changes outpace specs.Key capabilities
- →Manually trigger plan-sync for task specifications
- →Validate local setup version against plugin version
- →Resolve task and spec IDs from tracker handles
- →Identify downstream tasks for synchronization
- →Perform dry-run analysis of drift
How it works
It triggers a manual plan-sync to align task specifications with current code by identifying drift and updating downstream tasks.
Inputs & outputs
When to use flow-next-sync
- →Updating specs after refactoring
- →Fixing spec drift
- →Synchronizing task tracking with code progress
About this skill
Manual Plan-Sync
Manually trigger plan-sync to update downstream task specs.
Preamble
CRITICAL: flowctl is BUNDLED - NOT installed globally. Define once; subsequent blocks use $FLOWCTL:
FLOWCTL="${DROID_PLUGIN_ROOT:-${CLAUDE_PLUGIN_ROOT}}/scripts/flowctl"
[ -x "$FLOWCTL" ] || FLOWCTL=".flow/bin/flowctl"
Input
Arguments: $ARGUMENTS
Format: <id> [--dry-run]
<id>- task IDfn-N-slug.M(or legacyfn-N.M,fn-N-xxx.M) or spec IDfn-N-slug(or legacyfn-N,fn-N-xxx), or a resolvable tracker handle (wor-17/wor-17.M) thatflowctl showmaps to the linked spec/task (fn-52.10, R16)--dry-run- show changes without writing
Workflow
Step 1: Parse Arguments
REPO_ROOT="$(git rev-parse --show-toplevel 2>/dev/null || pwd)"
Parse $ARGUMENTS for:
- First positional arg =
ID --dry-runflag =DRY_RUN(true/false)
Validate ID first (handle-recognition rule, R16):
- The id is resolved by
flowctl show, not by a prefix check. A session that rejects a resolvable tracker handle as an unknown id — because it gated on "must start withfn-" — has broken this. Route the arg through$FLOWCTL show <ID> --json(Step 3); flowctl's widened resolver (fn-52.10) maps a tracker key (wor-17/wor-17.M) to its linked spec/task, so a resolvable handle is the existing spec/task, never a new id./flow-next:sync wor-17therefore resolves the linked spec. - If no ID provided: "Usage: /flow-next:sync <id> [--dry-run]"
- If the arg does not resolve via
flowctl show(Step 3): "Unknown ID. Use fn-N-slug (spec) / fn-N-slug.M (task), a tracker handle (wor-17), or legacy fn-N, fn-N-xxx."
Detect ID type (use the canonical id from flowctl show):
- Contains
.(e.g., fn-1.2, fn-1-add-oauth.2, wor-17.2) -> task ID - No
.(e.g., fn-1, fn-1-add-oauth, wor-17) -> spec ID
Step 2: Validate Environment
test -d .flow || { echo "No .flow/ found. Run flowctl init first."; exit 1; }
If .flow/ missing, output error and stop.
Step 3: Validate ID Exists
$FLOWCTL show <ID> --json
If command fails:
- For task ID: "Task <id> not found. Run
flowctl listto see available." - For spec ID: "Spec <id> not found. Run
flowctl specsto see available."
Stop on failure.
Step 4: Find Downstream Tasks
For task ID input:
# Extract spec from task ID (remove .N suffix)
SPEC=$(echo "<task-id>" | sed 's/\.[0-9]*$//')
# Get all tasks in spec
$FLOWCTL tasks --spec "$SPEC" --json
Filter to status: todo or status: blocked. Exclude the source task itself.
For spec ID input:
$FLOWCTL tasks --spec "<spec-id>" --json
-
First, find a source task to anchor drift detection (agent requires
COMPLETED_TASK_ID):- Prefer most recently updated task with
status: done - Else: most recently updated task with
status: in_progress - Else: error "No completed or in-progress tasks to sync from. Complete a task first."
- Prefer most recently updated task with
-
Then filter remaining tasks to
status: todoorstatus: blocked(these are downstream).
If no downstream tasks:
No downstream tasks to sync (all done or none exist).
Stop here (success, nothing to do).
Done when
- A source task is anchored — the input task in task mode, or the most recently updated
done(elsein_progress) task in spec mode — or the run stopped with the documented refusal because neither exists. DOWNSTREAM_TASK_IDSholds the spec'stodoandblockedtasks with the source task excluded. An empty downstream set stops the run here. A session that spawns the agent with nothing downstream has broken this.
Step 5: Gather glossary + decisions + strategy context
Three extra context types help the agent catch drift the spec text alone can't reveal: project-glossary terms (renames where the old spec used a term whose _Avoid_ alias now appears in code), active decision constraints (current code may touch files mentioned in a decision's Consequences section), and strategic-intent drift (completed task contradicts an active STRATEGY.md track or approach).
GLOSSARY_JSON="$("$FLOWCTL" glossary list --json 2>/dev/null \
|| echo '{"groups":[],"file_count":0,"total_terms":0}')"
DECISIONS_JSON="$("$FLOWCTL" memory list --track knowledge --category decisions --json 2>/dev/null \
|| echo '{"entries":[],"legacy":[],"count":0,"status":"active"}')"
STRATEGY_CONTENT="$("$FLOWCTL" strategy read --json 2>/dev/null || echo '{}')"
All three calls are best-effort — empty defaults keep the agent prompt valid when flowctl returns nothing or fails.
Husk short-circuit — when all three of the following hold, skip the extra context entirely (pass the empty defaults; the agent's husk short-circuit at the top of Phase 3b will skip the whole section):
GLOSSARY_JSON.total_terms == 0(glossary missing or husk)DECISIONS_JSON.count == 0(no decision entries)STRATEGY_CONTENT.sections_filled == 0ORSTRATEGY_CONTENT == {}(no STRATEGY.md or husk — verify withflowctl strategy status --json | jq '.sections_filled // 0')
When any of the three has signal, pass through all three (untouched) and let the agent run the matching subsection (3b.1 / 3b.2 / 3b.3) and skip the empty ones.
When GLOSSARY_JSON.total_terms == 0 but file_count > 0, every group is a husk. Husks carry no signal for drift detection — pass the JSON through untouched and let the agent skip them.
Done when
- All three variables are populated — with the documented empty default preserved on failure, never dropped. A prompt built with a missing
GLOSSARY_JSON/DECISIONS_JSON/STRATEGY_CONTENTkey has broken this. - The husk short-circuit passes the empty defaults through when all three carry no signal, and passes all three untouched when any one has signal.
Step 6: Spawn Plan-Sync Agent
Read the cross-spec flag first — the same single config-leaf read /flow-next:work performs, so a repo that opted into cross-spec propagation (planSync.crossSpec=true) gets the same behavior from a manual /flow-next:sync as from the work-loop auto-trigger. Without this, CROSS_SPEC is unset and plan-sync skips the cross-spec phase entirely — the tool you reach for after big drift silently checks only same-spec tasks:
CROSS_SPEC=$($FLOWCTL config get planSync.crossSpec --json | jq -r '.value')
Build context and spawn via Task tool:
Sync task specs from <source> to downstream tasks.
COMPLETED_TASK_ID: <source task id - the input task, or selected source for spec mode>
FLOWCTL: ${DROID_PLUGIN_ROOT:-${CLAUDE_PLUGIN_ROOT}}/scripts/flowctl
SPEC_ID: <spec id>
DOWNSTREAM_TASK_IDS: <comma-separated list from step 4>
DRY_RUN: <true|false>
CROSS_SPEC: <the $CROSS_SPEC value read below — literal "true" or "false", NOT "true|false">
GLOSSARY_JSON: <output of `flowctl glossary list --json` from step 5>
DECISIONS_JSON: <output of `flowctl memory list --track knowledge --category decisions --json` from step 5>
STRATEGY_CONTENT: <output of `flowctl strategy read --json` from step 5>
<if DRY_RUN is true>
DRY RUN MODE: Report what would change but do NOT use Edit tool. Only analyze and report drift.
</if>
Use Task tool with subagent_type: flow-next:plan-sync (sync-codex.sh rewrites Task to spawn_agent for the Codex mirror).
Note: COMPLETED_TASK_ID is always provided - for task-mode it's the input task, for spec-mode it's the source task selected in Step 4.
Done when
CROSS_SPECwas read fromplanSync.crossSpecand passed to the agent as the literal stringtrueorfalse.- The downstream task-spec edits are made by the spawned
flow-next:plan-syncagent. A session that edits downstream task specs directly has broken this. - Under
--dry-runthe agent is told to report drift without using Edit, and Step 7 closes with "No files modified."
Step 7: Report Results
After agent returns, format output:
Normal mode:
Plan-sync: <source> -> downstream tasks
Scanned: N tasks (<list>)
<agent summary>
Dry-run mode:
Plan-sync: <source> -> downstream tasks (DRY RUN)
<agent summary>
No files modified.
Error Messages
| Case | Message |
|---|---|
| No ID provided | "Usage: /flow-next:sync <id> [--dry-run]" |
No .flow/ | "No .flow/ found. Run flowctl init first." |
| Unknown ID (does not resolve) | "Unknown ID. Use fn-N-slug (spec) / fn-N-slug.M (task), a tracker handle (wor-17), or legacy fn-N, fn-N-xxx." |
| Task not found | "Task <id> not found. Run flowctl list to see available." |
| Spec not found | "Spec <id> not found. Run flowctl list to see available." |
| No source (spec mode) | "No completed or in-progress tasks to sync from. Complete a task first." |
| No downstream | "No downstream tasks to sync (all done or none exist)." |
Rules
- Ignores config -
planSync.enabledsetting is for auto-trigger only; manual always runs - Any source status - source task can be todo, in_progress, done, or blocked
- Includes blocked - downstream set includes both
todoandblockedtasks - Reuses agent - spawns existing plan-sync agent, no duplication
When not to use it
- →When the .flow directory is missing
Prerequisites
Limitations
- →Requires a completed or in-progress source task for spec-mode sync
- →Cannot resolve unknown IDs not mapped by flowctl
How it compares
It allows manual intervention to fix spec drift immediately, whereas auto-triggers only run based on configuration.
Compared to similar skills
flow-next-sync side by side with the closest alternatives in the catalog.
| Skill | Installs | Updated | Safety | Difficulty |
|---|---|---|---|---|
| flow-next-sync (this skill) | 1 | 2mo | Review | Advanced |
| pmbok-project-management | 38 | 9mo | No flags | Intermediate |
| project-planner | 32 | 9mo | Review | Intermediate |
| spec-kit-workflow | 11 | 8mo | No flags | Intermediate |
Try saying
Example prompts that trigger this skill in your AI assistant.
More by gmickel
View all by gmickel →You might also like
pmbok-project-management
jgtolentino
Comprehensive PMP/PMBOK project management methodologies and best practices. Use this skill when users need guidance on project management processes, templates, knowledge areas, process groups, tools, techniques, or certification preparation. Covers all 10 PMBOK Knowledge Areas and 5 Process Groups with practical templates, frameworks, and industry-standard approaches. Includes risk management, stakeholder engagement, schedule management, cost control, quality assurance, and resource planning.
project-planner
adrianpuiu
Comprehensive project planning and documentation generator for software projects. Creates structured requirements documents, system design documents, and task breakdown plans with implementation tracking. Use when starting a new project, defining specifications, creating technical designs, or breaking down complex systems into implementable tasks. Supports user story format, acceptance criteria, component design, API specifications, and hierarchical task decomposition with requirement traceability.
spec-kit-workflow
jmanhype
Guides specification-driven development workflow. Automatically invoked when discussing new features, specifications, technical planning, or implementation tasks. Ensures proper workflow phases (specify → clarify → plan → checklist → tasks → analyze → implement).
product-manager-toolkit
davila7
Comprehensive toolkit for product managers including RICE prioritization, customer interview analysis, PRD templates, discovery frameworks, and go-to-market strategies. Use for feature prioritization, user research synthesis, requirement documentation, and product strategy development.
planning-agent
parcadei
Planning agent that creates implementation plans and handoffs from conversation context
pdd
mikeyobrien
Transforms a rough idea into a detailed design document with implementation plan. Follows Prompt-Driven Development — iterative requirements clarification, research, design, and planning.