plugins/flow-next/skills/flow-next-sync/SKILL.md
Manually trigger plan-sync to update downstream task specs after implementation drift. Use when code changes outpace specs.
npx skillsauth add gmickel/gmickel-claude-marketplace flow-next-syncInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
Manually trigger plan-sync to update downstream task specs.
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"
Arguments: $ARGUMENTS
Format: <id> [--dry-run]
<id> - task ID fn-N-slug.M (or legacy fn-N.M, fn-N-xxx.M) or spec ID fn-N-slug (or legacy fn-N, fn-N-xxx), or a resolvable tracker handle (wor-17 / wor-17.M) that flowctl show maps to the linked spec/task (fn-52.10, R16)--dry-run - show changes without writingREPO_ROOT="$(git rev-parse --show-toplevel 2>/dev/null || pwd)"
Parse $ARGUMENTS for:
ID--dry-run flag = DRY_RUN (true/false)Validate ID first (handle-recognition rule, R16):
fn-" check. 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. So /flow-next:sync wor-17 resolves the linked spec.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):
. (e.g., fn-1.2, fn-1-add-oauth.2, wor-17.2) -> task ID. (e.g., fn-1, fn-1-add-oauth, wor-17) -> spec IDtest -d .flow || { echo "No .flow/ found. Run flowctl init first."; exit 1; }
If .flow/ missing, output error and stop.
$FLOWCTL show <ID> --json
If command fails:
flowctl list to see available."flowctl specs to see available."Stop on failure.
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):
status: donestatus: in_progressThen filter remaining tasks to status: todo or status: blocked (these are downstream).
If no downstream tasks:
No downstream tasks to sync (all done or none exist).
Stop here (success, nothing to do).
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 == 0 OR STRATEGY_CONTENT == {} (no STRATEGY.md or husk — verify with flowctl 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.
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>
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.
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.
| 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)." |
planSync.enabled setting is for auto-trigger only; manual always runstodo and blocked taskstesting
Live-app real-user QA pass derived from the spec. Drives the running app via flow-next-drive, derives scenarios from the spec's AC / R-IDs / boundaries, files structured P0/P1/P2 findings with evidence, and ends with a YES/NO ship verdict receipt. Triggers on /flow-next:qa with a spec id. FORBIDDEN from marking PASS by reading source — the verdict rests on captured evidence from the live app, never on agent narration.
testing
Live-app real-user QA pass derived from the spec. Drives the running app via flow-next-drive, derives scenarios from the spec's AC / R-IDs / boundaries, files structured P0/P1/P2 findings with evidence, and ends with a YES/NO ship verdict receipt. Triggers on /flow-next:qa with a spec id. FORBIDDEN from marking PASS by reading source — the verdict rests on captured evidence from the live app, never on agent narration.
testing
Project a flow-next spec to a tracker issue (Linear first, GitHub next) and reconcile body/status/comments two-way — projection, not coordination. The spec stays the source of truth; the tracker is a co-editable mirror. Use to configure the bridge (discovery ceremony), link a spec to an issue (flow-first push or tracker-first "grab issue X and spec it"), push/pull/reconcile, or unlink. Triggers on /flow-next:tracker-sync, "sync to linear", "push this spec to the tracker", "grab issue X and spec it", "link this spec to the issue", "reconcile with the tracker". NOT /flow-next:sync (that is plan-sync, a different skill).
development
Drive any UI surface like a real user - a web app, a Chromium-backed desktop app (Electron / WebView2, reached over CDP), or a genuinely native app (macOS AppKit/SwiftUI, or a non-CDP webview) reached via Computer Use. Detects the surface, picks the best available driver, degrades gracefully. Use to navigate sites, verify deployed UI, test web or desktop apps, capture baseline screenshots, drive a sign-in flow, scrape data, fill forms, run an e2e check, or inspect current page state. Triggers on "check the page", "verify UI", "test the site", "test this app", "drive the app", "automate this desktop app", "read docs at", "look up API", "visit URL", "browse", "screenshot", "scrape", "e2e test", "login flow", "capture baseline", "see how it looks", "inspect current", "before redesign", "Electron app", "native app".