Flo:next

flo:next

Work through an epic one bead at a time with full chain awareness. Additive to beads session protocol — this skill adds epic-scoped chain tracing and downstream plan integrity checking.

When to Use

• Continuing a multi-session epic (1-3 concurrent agents)
• Starting a new session on an existing epic
• Told to "pick up the next bead" or "continue the epic"

Not for: Single-bead standalone tasks (no epic parent), exploratory work not tracked in beads.

Requirements

• bd CLI (beads plugin active)
• jq (used by context.sh)
• Git repo with an active beads epic (auto-detected via .flo/state.yml — bootstraps on first use)
• Override with --epic <id> if auto-detection picks the wrong epic

Quick Reference

Key bd Commands

CRITICAL — Downstream Plan Integrity

This is the core value of flo:next. When closing a bead whose resolution differs from its original body — because human-in-the-loop changed scope, because you discovered a constraint, because the work naturally evolved — you MUST check downstream beads for cascading implications.

The rule:

1. Compare your close reason against the bead's original body
2. If they diverge: run bd dep tree <id> --direction=up --status open to get all downstream beads that depend on this one
3. For each downstream bead, assess: does this change affect its body, acceptance criteria, or feasibility?
4. If you are confident the downstream impact is clear and mechanical (e.g., a rename, a symbol that moved): propose the updates and apply them after user confirmation
5. If you are NOT confident — if there is ANY ambiguity about how the change cascades — you MUST:
   • Report every downstream bead you think is affected
   • Describe the specific concern for each
   • Suggest fixes if you have them
   • STOP and wait for user input
   • NEVER silently ignore a potential downstream misalignment
   • NEVER force-fit the situation into apparent alignment

Why this is non-negotiable: Late-stage discovery that an epic has gone off the rails wastes all prior work. Short-circuit at the first sign of plan drift. If the user pushes back on stopping, remind them: this is the only sane way to develop with agents on non-trivial epics at scale.

Entry Protocol

Hot next (same session, next bead)

If you just completed a bead and are taking the next one without clearing context, use the lighter hot path. Epic fields and design docs are already in your window.

bd dolt pull 2>/dev/null
bash $CLAUDE_PLUGIN_ROOT/scripts/context.sh --hot

Always refresh before hot next. Other agents may have closed beads, added comments, or changed dependencies since you started working. bd dolt pull pulls the latest shared bead state so the context dump reflects current data.

The hot output includes: recently closed beads (with timestamps), dependency graph, ready list, claimed list, and blocked list — all fetched fresh from bd. Then jump to step 4 (choose bead).

You may skip steps 2 and 3 (epic fields and design docs are already in your window). Do NOT skip step 5 (trace chain) — if another agent closed a bead while you were working, there is a new predecessor you haven't seen. Check the RECENTLY CLOSED section for any beads closed since your session started. If you see new ones, read their close reasons before choosing your next bead.

1. Load context (cold entry)

bash $CLAUDE_PLUGIN_ROOT/scripts/context.sh

Outputs: epic metadata + all fields, epic comments, completed chain with close reasons, latest predecessor details (comments/design/notes), dependency graph, ready/blocked/in-progress children.

Epic resolution is handled by .flo/state.yml (auto-bootstraps on first use). To override: bash $CLAUDE_PLUGIN_ROOT/scripts/context.sh --epic <id>

2. Read epic fields (MANDATORY every session)

These fields carry cross-session context. Read all of them:

• design → if it points to a design doc or issue directory, follow it (feeds step 3)
• notes → constraints and conventions set by the epic author
• comments → session learnings from all prior agents (already in context dump)

3. Read design docs (if available)

Follow the epic's DESIGN pointer if it exists:

1. If it points to an issue directory (.issues/<key>/): read the dir's README.md, then files it calls out as prerequisites (e.g., terminology.md)
2. If it points to a design doc directly (e.g., docs/plans/...): read that doc
3. If the epic has no design field: skip this step — the epic description and bead descriptions carry the context
4. (Task-specific design doc read happens after choosing a bead in step 5)

4. Choose bead (interactive)

Present the epic state to the user:

1. Show the dependency graph from the context dump (bd graph output) — this gives the user a visual map of the epic's structure and progress
2. Show the ready, claimed, and blocked sections from the context dump
3. Use AskUserQuestion with ONLY ready beads as options (up to 4, priority-sorted). The READY section of the context dump (sourced from bd ready --unassigned --parent) is the sole authority for what appears as a selectable option.
4. If a ready bead has the flo/interactive label, still show it as a selectable option but annotate it: "⚡ Interactive — this bead requires human-in-the-loop and should not be delegated to a background agent." Don't block selection — just inform.
5. If no ready beads: report to user — either all are blocked (show blockers), all are claimed (show who claimed them), or the epic is complete

NEVER offer claimed, blocked, or in-progress beads as AskUserQuestion options. They are shown for situational awareness only:

• Claimed beads have an assignee and are being worked on by another agent session
• Blocked beads have unsatisfied dependencies — they cannot be worked on yet

If the user explicitly asks to override (e.g., work on a claimed or blocked bead anyway), that's their call — but the default presentation must only offer unclaimed, unblocked work.

5. Trace the chain

For the chosen bead's most recent closed predecessor:

1. Read its close reason (already in context dump) — what was actually built
2. Read its comments, design, notes (bd show <id> + bd comments <id>) for implementation decisions the close reason may not capture
3. If the close reason references specific files or patterns, read those — they establish the contract your task builds on

The context dump pre-fetches the most recently closed child as the optimistic predecessor. If your chosen bead has a different predecessor (e.g., it depends on a specific sibling, not the latest), fetch that one instead.

You don't need to trace the entire chain — the immediate predecessor is usually sufficient. Go deeper only if the predecessor's close reason references decisions made in earlier beads, or if its close reason is sparse and its comments/design/notes don't fill the gap.

6. Read your bead + claim it

bd show <id>            # Full body, acceptance, design, notes
bd update <id> --claim --actor "<user>/<session-prefix>"
bd comments add <id> "claimed by session <full-session-id>"

Claim identity: Your session ID is the UUID from the session start message (the --resume value, e.g. e65f21da-49c5-4bf9-8a2f-dc723444d3af).

• Assignee (short, current holder): --actor "<git user.name>/<first 8 chars>" — e.g. "Jason Kuhrt/e65f21da"
• Comment (full audit trail): log the complete session UUID so any future session can trace back or resume

Multiple sessions may touch the same bead (hand-offs, retries). Each adds a comment — the history accumulates naturally.

Use --claim, NOT --status in_progress. The --claim flag atomically sets assignee + in_progress and fails if already claimed. If the claim fails, go back to step 4 and pick a different bead.

Cross-reference the bead body against the terminology/design docs. If the bead uses stale terms (written before a terminology audit, for example), use the design docs as the authority.

Now read the task-specific design doc (deferred from step 3).

7. Read the code contract

Read the stub or interface your task replaces. Read the most recent predecessor's implementation for established patterns (imports, component structure, mutation flow).

Exit Protocol

1. Close with actual result

Apply the beads close discipline rules (see beads-close-discipline rule file):

• Describe what was actually achieved
• If it diverged from the bead body, state the delta and why
• Name key artifacts (files, symbols, patterns)

2. Check downstream integrity

This is the CRITICAL section above. Do it now, before moving on.

Compare your close reason against the original bead body:

• No divergence? Proceed to step 3.
• Divergence detected? Scan downstream beads. Report findings. Wait for user if uncertain.

3. Update epic context (if session produced learnings)

If this session produced decisions, discoveries, or convention changes that future sessions should know:

bd comments add <epic-id> "Session: <what was learned or decided>"

4. Standard close

git add <files> && git commit -m "..."
bd close <id> --reason "..." --session <full-session-id> --suggest-next
bd dolt push
git push

• --session records which Claude Code session closed this bead (first-class field, separate from comments)
• --suggest-next shows newly unblocked beads after closing — feeds directly into hot path if continuing

Common Mistakes

Compaction Recovery

A SessionStart hook (compact-recovery.sh) automatically fires after context compaction. It:

1. Detects that the session was compacted (source=compact)
2. Resolves the epic from the git branch
3. Pulls latest shared bead state (bd dolt pull)
4. Finds the in_progress bead claimed by this session (matches session prefix in assignee)
5. Outputs the bead body and recovery instructions as a system message

What the agent receives post-compaction: CC's compaction summary (what you were doing) + the hook's recovery context (epic progress, active bead body, instructions to run context.sh --hot).

What the agent should do: Follow the recovery instructions — run the hot path, re-read the bead body, and resume implementation. The compaction summary tells you where you left off; the hook output tells you what you're building.

If no active bead is found: The hook exits silently (no output). This means the session was not doing flo:next work — it hadn't claimed a bead — so the hook does not inject recovery context that would hijack the session's actual task. This also covers: bead closed before compaction, bead claimed with --status in_progress instead of --claim (no assignee to match).

Notes

• This skill layers on top of the beads session protocol. It does not replace bd ready or the session close checklist — it adds chain tracing and plan integrity checking.
• Git commit/push permissions come from the beads session protocol, not this skill's allowed-tools.
• The context script is zero-token when the agent reads the stdout. The script source is never loaded.
• For parallel agent sessions (1-3 concurrent), each agent runs its own flo:next entry. The --claim --actor flag is the concurrency primitive — it atomically sets assignee + status and fails if another agent already claimed the bead. Each agent uses its session ID (from the conversation start message) to form a unique actor identity: <git user.name>/<session-id-first-8-chars>.