plugins/flow/skills/run-state-management/SKILL.md
Manage FlowRun state at `.flow/runs/<ISO-timestamp-id>/run.yaml` — create runs at command entry, write activity records via `bin/flow-record-activity.sh` at phase boundaries, transition `state.status` (active → completed | blocked | cancelled), and persist resumable next-action hints to `events.jsonl`. Use when a flow command begins (creates the run), when a phase boundary completes (writes an activity), or when SessionEnd needs to mark a resumable next action. This skill MUST be consulted because runs without recorded activities cannot be resumed — `/flow:resume` reads `state.completed_activities[]` to identify the next safe action; an empty array forces the user to start over.
npx skillsauth add synaptiai/synapti-marketplace run-state-managementInstall 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.
You own FlowRun durability. Every long-running flow command (start, debug, address, review, pr, merge, release) writes a .flow/runs/<id>/run.yaml at entry, appends an activity record at every phase boundary, and updates state.status on completion. Without this skill, runs are session-scoped and die when the conversation ends — defeating the resumability promise of the v3 runtime layer.
No phase transitions without an activity write. state.completed_activities[] is the source of truth for /flow:resume — a missing activity means the resume command will skip ahead and the user loses work.
This skill wraps autonomous-workflow (which encodes the phase structure of /flow:start and friends). It adds:
.flow/runs/<id>/events.jsonlIf autonomous-workflow says "next phase is VERIFY," this skill writes the corresponding activity YAML and updates state.current_phase.
The invoking command MUST pass:
start-issue | debug | address-pr | review-pr | merge-pr | release (matches the workflow YAML filenames under plugins/flow/workflows/).<ISO-8601-compact-timestamp>-<target-slug> (e.g., 2026-05-20T143000Z-issue-42).preflight, explore, plan, code, verify)..flow/runs/<id>/run.yaml — FlowRun document conforming to schemas/v1/run.schema.json..flow/runs/<id>/activities/<NNN>-<name>.yaml — activity records written per phase boundary..flow/runs/<id>/events.jsonl — line-per-event ledger.workflow-run artifact appended to linked decision journal.When the command begins:
# Compose the FlowRun YAML
cat > /tmp/run.yaml <<EOF
apiVersion: flow.synapti.ai/v1
kind: FlowRun
metadata:
id: ${RUN_ID}
workflow: ${WORKFLOW_ID}
workflow_version: 1
goal: ${GOAL_ID:-null}
created_at: ${NOW}
context:
repo: ${REPO}
branch: ${BRANCH}
issue: ${ISSUE:-null}
pr: ${PR:-null}
journal: ${JOURNAL}
state:
status: active
current_phase: ${INITIAL_PHASE}
current_activity: null
completed_activities: []
blocked_reason: null
limits:
max_iterations: 10
max_runtime_minutes: null
events:
- at: ${NOW}
type: run_started
EOF
Write to .flow/runs/<id>/run.yaml via direct file write (no atomic helper needed for the initial creation — race-free because the directory doesn't yet exist).
Append workflow-run artifact to the linked journal:
bin/journal-record.sh --issue ${N} --type workflow-run \
--metadata workflow=${WORKFLOW_ID} \
--metadata run_id=${RUN_ID} \
--metadata status=active
At the end of each phase (or significant sub-step within a phase), compose a FlowActivity YAML and invoke bin/flow-record-activity.sh:
ACT_FILE=$(mktemp)
cat > "${ACT_FILE}" <<EOF
apiVersion: flow.synapti.ai/v1
kind: FlowActivity
metadata:
id: ${ACTIVITY_NAME}
run_id: ${RUN_ID}
workflow: ${WORKFLOW_ID}
phase: ${PHASE}
activity:
type: ${TYPE} # bash | skill | agent | task | gate | evaluation
name: '${HUMAN_NAME}'
status: passed # or running | failed | skipped | blocked
started_at: ${START_TIME}
completed_at: ${NOW}
outputs:
evidence_refs: [${EVIDENCE_REF_LIST}]
files_changed: [${FILES_LIST}]
command_exit_code: ${EXIT_CODE}
result:
summary: '${SUMMARY}'
confidence: ${high|medium|low}
EOF
bin/flow-record-activity.sh --run-id ${RUN_ID} --activity-file "${ACT_FILE}"
rm "${ACT_FILE}"
The helper:
001-, 002-, ...)schemas/v1/activity.schema.jsonevents.jsonlAfter each activity write, update run.yaml to reflect the new phase/activity:
state:
status: active
current_phase: ${NEW_PHASE} # advance if at phase boundary
current_activity: ${NEXT_ACTIVITY_ID}
completed_activities:
- ${PRIOR_ACTIVITY_IDS}
- ${JUST_RECORDED_ACTIVITY_ID} # append the one we just wrote
This update is atomic via the same helper pattern: direct read-merge-write through Python with _journal_atomic.py.acquire_lock(run.yaml.lock).
When the command completes (success, failure, or cancellation):
state:
status: completed # or failed, cancelled, blocked
current_phase: <last>
current_activity: <last>
completed_activities: [...]
blocked_reason: null # set when status is blocked
Update the workflow-run journal artifact with the final status (via a second journal-record.sh call with the updated metadata).
When SessionEnd fires (separate hook: session-end-state.sh), if an active FlowRun exists:
{type: session_end, at: <now>}state.blocked_reason: "session ended" if no terminal transition happenedActive FlowRun <id> persisted; use /flow:resume to continue| Workflow | Phase order |
|---|---|
| start-issue | preflight → explore → plan → code → verify |
| debug | preflight → reproduce → diagnose → fix → verify |
| address-pr | preflight → categorize → resolve → verify |
| review-pr | preflight → fan-out → consolidate → report |
| merge-pr | preflight → verify → confirm → merge |
| release | preflight → bump → confirm → tag |
The machine-readable equivalents live at plugins/flow/workflows/<id>.workflow.yaml.
run.yaml outside the helper or direct create — concurrent updates need flock.state.current_phase without writing an activity — phases without activities can't be resumed.state.status: completed while completed_activities[] is empty — implausible; the run did nothing.events.jsonl and trusting partial lines — readers MUST skip un-parseable trailing lines (atomicity at write time, tolerance at read time).blocked run without checking why it was blocked — surface the blocker first.plugins/flow/skills/autonomous-workflow/SKILL.md — phase structure source of truth.plugins/flow/bin/flow-record-activity.sh — atomic activity writer.plugins/flow/bin/_journal_atomic.py — exposed acquire_lock, _atomic_write for run.yaml updates.plugins/flow/schemas/v1/run.schema.json — run document schema.plugins/flow/schemas/v1/activity.schema.json — activity document schema.plugins/flow/references/decision-journal-schema.md — workflow-run and activity-completed artifact-type rows.tools
Validate a FlowWorkflow YAML at `plugins/flow/workflows/<id>.workflow.yaml` against `schemas/v1/workflow.schema.json` AND cross-reference the referenced skills/agents exist + every Tier 3 action is confirm-gated + no native /goal or /loop dependency is declared. Use when /flow:workflow validate is invoked, when CI runs the workflow schema gates, or when a new workflow is being authored. This skill MUST be consulted because schema validation alone catches shape errors; cross-reference validation catches the silent-correctness failures (typo'd skill name, Tier 3 escape, /goal dependency) that would otherwise ship to users.
tools
Verify UI-facing changes by running a screenshot-analyze-verify loop across configured viewports, with a browser-tool priority cascade (Playwright MCP → Chrome DevTools MCP → CLI fallback → external skill fallback) and bounded iteration. Use after build/runtime verification passes and the diff includes `.tsx`/`.jsx`/`.vue`/`.html`/`.css`/`.scss`/`.svelte` files OR the acceptance criteria mention UI/page/render/display/visual. This skill MUST be consulted because UI changes that pass build and unit tests can still ship blank pages, render-blocking console errors, or broken responsive layouts that no other verification phase catches.
data-ai
Coordinate agent teams for adversarial review (paired skeptic/verifier per facet, challenge round with disposition vocabulary, consolidated findings with confidence) or parallel implementation (task sizing 5-6 per teammate, non-overlapping files). Enforces independent analysis before shared conclusions. Reference only (`disable-model-invocation: true`); loaded only when `agentTeams: true` in settings.
development
Conduct two-stage code review: Stage 1 verifies spec compliance (criterion-to-code mapping), Stage 2 evaluates security, correctness, performance, and maintainability across 6 parallel facets with P1/P2/P3 synthesis and deduplication by file:line. Use when reviewing code changes or pull requests. This skill MUST be consulted because reviewing quality on broken logic is wasted effort, and unmet acceptance criteria must block merge.