flow

Plugin flow from marketplace synapti-marketplace in synaptiai/synapti-marketplace. Commands read from the repo's manifest — today.

Skills (33)

• architecture-patterns

  Document system design decisions with mapped user flows, coupling analysis, failure modes, and explicit non-goals, proving the architecture can survive under unexpected conditions. Use when designing systems, evaluating structural changes, or reviewing architecture decisions. Proactively suggest whe

• autonomous-workflow

  Execute development workflows through Explore-Plan-Code-Verify phases with task-driven tracking, Tier 1/2/3 action classification, decision journaling, and bounded debug loops. Use when executing any development workflow autonomously or orchestrating multi-step implementation tasks. This skill MUST

• brainstorming

  Generate 2-4 distinct approaches with trade-off analysis across simplicity, flexibility, performance, effort, and risk, driving collaborative decision-making before implementation. Use when evaluating alternatives before committing to an implementation strategy. Proactively suggest when the team def

• branch-and-task-management

  Create feature branches with naming conventions, load full issue context and impact analysis, and decompose acceptance criteria into atomic parallel tasks with dependencies. Use when starting work on a GitHub issue. This skill MUST be consulted because starting code without context causes misaligned

• capability-discovery

  Discover available agents, skills, quality commands (lint, test, typecheck), tech stack, verification capabilities, and LSP code intelligence features via parallel environment scanning. Use when starting implementation, creating PRs, reviewing PRs, or addressing feedback. This skill MUST be consulte

• change-classification

  Classify code changes as in-context, uncertain, or out-of-context using primary signals (branch diff, issue keywords, active tasks), secondary signals (directory proximity, test naming), and red-flag patterns (secrets, large binaries). Use when preparing commits or reviewing staged changes. This ski

• code-quality-principles

  Enforce code quality through the Boy Scout Rule (leave code better than found), secret-free commits, production-ready code (no TODOs, console.log, mocks, or commented code), and self-review against an atomic-commits checklist. Use when writing, modifying, or reviewing code. This skill MUST be consul

• code-review-methodology

  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. For the Tests facet the reviewer derives expected be

• convention-enforcement

  Validate git conventions (commit messages, branch naming, PR format, issue linkage) by detecting project-specific rules from CLAUDE.md and settings, inferring patterns from recent history. Use when creating commits, preparing PRs, or reviewing for convention compliance. This skill MUST be consulted

• criterion-verification-map

  Transform acceptance criteria into plan-time runnable verification commands (behavioral, API, UI, error, performance, config, data, contract types) with expected evidence shapes and risk areas, then execute at verify time and assemble the evidence bundle with its mandatory completeness subsections,

• debugging-patterns

  Isolate root causes through structured evidence gathering, pattern analysis, hypothesis testing (max 3 at a time, highest confidence first), and fix validation with a reproducing test before implementation. Use when any verification step fails, tests break, or debugging a reported bug. This skill MU

• evidence-based-development

  Enforce evidence-based claims through file:line citations, P1/P2/P3 prioritization proportional to evidence, and the ASSERTION/EVIDENCE/VERIFIED pattern for behavioral claims before any recommendation. Use when gathering evidence, presenting findings, or making development decisions. This skill MUST

• feedback-resolution

  Address PR review feedback through surgical fixes traceable to specific comments, apply the Boy Scout Rule only to already-modified files (separate `improve:` commits), recover context by code snippet rather than line number, and enforce pushback only when factually incorrect, test-breaking, or CLAU

• goal-contract-capture

  Capture a FlowGoal contract as `<runtime dir>/goals/<id>.goal.yaml` — outcome, acceptance criteria with verification commands, specification (non-goals, failure modes, interface contracts, risk map), constraints, evaluator binding, continuation policy, lifecycle. Use when /flow:start passes the Spec

• goal-evaluator

  Evaluate a FlowGoal against its evidence ledger: run every deterministic verification command first, dispatch the goal-evaluator-judge only for fuzzy criteria, then return a structured verdict and write non-terminal lifecycle updates. Use when /flow:goal evaluate runs, or when /flow:debug converts A

• goal-evidence-ledger

  Maintain the append-only evidence ledger: `<runtime dir>/runs/<run-id>/evidence/*.evidence.yaml` sidecars plus matching `.txt` raw captures, written only via `bin/flow-record-evidence.sh`. Use when goal-evaluator runs a verification command, when /flow:address captures verification evidence on a Flo

• goal-lifecycle

  Enforce the FlowGoal state machine: every `lifecycle.status` transition (draft → active → {waiting_for_user, waiting_for_ci, blocked, achieved, failed, cancelled}) writes the new lifecycle block through `bin/flow-goal-record.sh` AND a `goal-created` or `goal-evaluation` artifact to the decision jour

• holdout-validation

  Cross-reference agent self-review claims and evidence-bundle entries against actual file state using hidden holdout scenarios, producing P1/P2/P3 findings mapped to visible acceptance criteria only. Checks that every expected value in the tests has the source the bundle claims and that every risk-ma

• issue-crafting

  Craft well-structured GitHub issues with solution-agnostic outcomes, duplicate detection (open and closed), dynamically-discovered labels, and acceptance criteria describing observable behavior without implementation details. Use when creating new GitHub issues. Proactively suggest when an issue pre

• a-check-that-can-only-confirm

  [flow-learned] Design guards, tests, lint rules and verification scripts so they are capable of failing: every check gets a mutant that must make it fire, a mutant that must leave it silent, a mutant that removes its input, and an asserted non-zero count of what it examined. Use this whenever writin

• llm-operator-principles

  Frame Claude's identity as an LLM operator that does not tire, treats convergence as no counted P1 or P2 left (not zero findings, not exhausted budget), prohibits calendar-time estimates (weeks/days/hours/sprints/ETAs), and defaults to in-PR fixes for all findings (P1/P2/P3). Use when starting any /

• merge-and-release

  Reference document describing merge prerequisites (approval, CI checks, mergeable, conversations resolved, stale approval), release versioning (semantic semver), and changelog generation. Explains why Tier 3 confirmation is structural: merge and release cost is borne by downstream people. Reference

• merge-conflict-resolution

  Detect, classify (porcelain status; complexity: trivial, semantic, structural, delete-modify), and resolve git merge conflicts through per-file strategy selection (accept-ours, accept-theirs, manual-merge, ask-user), manual conflict hunk parsing, and post-resolution verification (orphaned markers, b

• pr-lifecycle

  Reference document describing PR lifecycle: pre-flight gates (4 conditions), verification gate (5 conditions), body structure (from templates/pr-body.md), reviewer-suggestion algorithm (CODEOWNERS → file expertise → recent activity → workload balance), and finding-ledger merge prerequisite. Referenc

• preflight-checks

  Reference document describing six pre-flight checks (clean git state, not detached HEAD, gh auth, issue exists and OPEN, remote reachable, duplicate-branch warning) as pure bash exit codes with no LLM calls. Reference only (policy document; consumed by `/flow:start` Phase 0).

• run-state-management

  Manage FlowRun state at `<runtime dir>/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 `eve

• runtime-verification

  Verify code works at runtime through build verification (mandatory), LSP diagnostics, ad-hoc verification for projects without frameworks, E2E and smoke tests, and visual verification (screenshot-analyze-verify for UI changes). Skip whitelist strictly enforced (markdown-only, config-only, dependency

• specification-capture

  Capture the four specification elements (non-goals, failure modes, interface contracts, risk map) for an issue and persist them to the decision journal under a ## Specification heading. Use when starting work on an issue (Phase 1 of /flow:start), entering a design discussion (/flow:design), or start

• tdd-patterns

  Guide test-driven development through the mandatory Red-Green-Refactor cycle: a test is RED only when it fails for the intended reason, its expected value has a stated source (spec, reference implementation, hand computation, fixture, or standard — never the implementation's own output), and its inp

• team-coordination

  Coordinate agent teams for adversarial review (paired skeptic/verifier per facet, disposition-only challenge round, mechanical consolidation with confidence) or parallel implementation (5-6 non-overlapping tasks per teammate). Enforces independent analysis before shared conclusions. Reference only (

• trigger-policy

  Enforce FlowTrigger safety rules — no autonomous merge, no recursive trigger creation, max active triggers, allowed_actions / forbidden_actions ACLs. Validates trigger YAMLs at `<runtime dir>/triggers/*.trigger.yaml` against `schemas/v1/trigger.schema.json` AND cross-checks policy.forbidden_actions

• visual-verification

  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 inclu

• workflow-validation

  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 i

Slash commands (23)

• /flow:address

  Address PR review feedback systematically. Categorizes feedback, implements surgical fixes, verifies changes, and re-requests review.

• /flow:brainstorm

  Explore approaches before committing to implementation. Generates options, analyzes trade-offs, and helps select the best approach collaboratively.

• /flow:commit

  Classify changes and create atomic commits with conventional messages. Flags out-of-context modifications and red-flag patterns before committing.

• /flow:debug

  Debug an issue with structured root cause analysis. Guides evidence gathering, hypothesis testing, and fix validation.

• /flow:design

  Design or review architecture for a feature or system. Analyzes existing patterns, evaluates coupling, and produces design decisions.

• /flow:explain

  Answer questions about architecture decisions, implementation rationale, and trade-offs by loading the decision journal and diff context for the current branch or issue. Use when seeking to understand what was built and why.

• /flow:flow

  Universal workflow entry point. Use /flow <verb> <target> for skill-driven GitHub development. Verbs: start, commit, pr, review, address, merge, resolve, release, status, learn, setup, explain, debug, design, brainstorm, issue, goal, resume, run, trigger, watch, workflow.

• /flow:goal

  Manage FlowGoal completion contracts — create, inspect, evaluate, pause/resume/clear, history. Use when starting a goal-driven task, when checking active-goal state, or when finalizing the verdict after evidence is collected. Captures acceptance criteria with verification commands, runs deterministi

• /flow:issue

  Create a well-crafted GitHub issue. Guides solution-agnostic requirements gathering, duplicate detection, label discovery, and verifiable acceptance criteria.

• /flow:learn

  Analyze the decision journal and session transcripts for learnable patterns and generate skill or enforcement proposals from repeated user corrections and common patterns. Use when reviewing session activity to extract reusable knowledge.

• /flow:merge

  Merge an approved pull request. Verifies prerequisites (approval, checks, conversations), displays assessment, and requires explicit human confirmation. Tier 3 — never autonomous.

• /flow:pr

  Create a pull request with full code review, quality gates, comprehension report, and reviewer suggestions. Runs parallel agent review before PR creation.

• /flow:release

  Create a release in two runs: open a release pull request that bumps the version files and changelog, then, once it is merged, tag the merge commit and publish the GitHub release. Requires explicit human confirmation. Tier 3 — never autonomous.

• /flow:resolve

  Resolve merge conflicts on the current branch or for a pull request. Detects conflict types, analyzes both sides, applies per-file resolution strategies, and verifies the result compiles and passes tests.

• /flow:resume

  Read interrupted FlowRun state and propose the next safe action. Use /flow:resume (no args) for the most-recent active run, or /flow:resume <run-id> for a specific run. Informational only — never auto-executes the next phase. The user decides whether to continue.

• /flow:review

  Review a pull request with multi-faceted analysis. Supports both single-session parallel review and agent team adversarial review.

• /flow:run

  Execute a FlowTrigger target ONCE. Subcommands: trigger <id>. Does NOT schedule future execution.

• /flow:setup

  Initialize flow for a repository. Detects tech stack, generates settings, configures LSP servers, warns about plugin coexistence, offers GitHub rulesets for the default branch and tags, and optionally adds CLAUDE.md sections.

• /flow:start

  Start work on a GitHub issue. Assigns issue, creates branch, decomposes tasks from acceptance criteria, and guides implementation with autonomous execution.

• /flow:status

  Display a read-only overview of workflow state including assigned issues, open PRs, pending reviews, branch state, and decision journal health. Use when checking current development status.

• /flow:trigger

  Manage FlowTrigger artifacts in the runtime directory's triggers/ (.flow/triggers/ by default). Subcommands: list, inspect <id>, enable <id>, disable <id>, run <id>, delete <id>. Triggers describe wake-up intent; they do NOT guarantee background execution.

• /flow:watch

  Create a FlowTrigger from a template and, for pr, issue and branch, a /loop prompt file the user invokes manually. Subcommands: pr <N>, ci, issue <N>, branch. Flow CANNOT invoke /loop from plugin code; this command prepares the prompt and tells the user how to start the loop themselves. ci creates a

• /flow:workflow

  Inspect and validate FlowWorkflow YAMLs in the plugin's workflows/ directory and the runtime directory's workflows/ (.flow/workflows/ by default). Subcommands: list, inspect <id>, validate <id>, graph <id>.

Subagents (10)

• code-reviewer

  Review code changes for quality, logic correctness, edge cases, security, and error handling. Use when reviewing a branch diff before PR creation or during /flow:review. Do not use for a security-only or error-handling-only pass; dispatch security-reviewer or error-handler-inspector for those. Retur

• convention-checker

  Validate Git conventions including commit messages, branch naming, PR format, and code patterns. Use when preparing a commit or PR, or when auditing branch history for convention compliance. Do not use for code-quality review. Report convention violations with severity.

• error-handler-inspector

  Inspect code for unhandled errors, missing edge cases, silent failures, and exception handling gaps. Use when dispatching the error-handling facet of a parallel review. Do not use for a full-scope code review. Return P1/P2/P3 findings with file:line citations.

• finding-critic

  Try to refute a consolidated review finding from the code itself, answering in a three-verdict grammar: AGREE, DISAGREE_EVIDENCE with a file:line citation, or DISAGREE_CONCERN. Use when the grounding pass of a review fan-out audits P1/P2 findings before they are posted. Never re-prioritizes, re-cate

• goal-evaluator-judge

  Specialized loop-time verdict judge for the FlowGoal evaluator. Judges goal satisfaction by evaluating the embedded goal contract, the deterministic check report, and the evidence ledger (all delivered inline in the prompt under <<<UNTRUSTED_*>>> fences) — then returns a structured verdict of {achie

• implementation-planner

  Parse acceptance criteria from issues and create atomic task breakdowns (implementation + test + evidence) with dependencies, parallel execution opportunities, and one discriminating test per risk-map row. Use when decomposing an issue into trackable implementation tasks.

• integration-verifier

  Verify end-to-end functionality beyond unit tests. Start dev servers, run E2E suites, perform smoke tests, and validate acceptance criteria at runtime. Use after unit-level quality checks pass, when a change has runtime surface. Do not use for markdown-, config-, or dependency-only changes.

• security-reviewer

  Review code for security vulnerabilities including OWASP top 10, secrets detection, auth/authz verification, input validation, and dependency vulnerabilities. Use when performing security-focused code review or agent team adversarial review.

• test-runner

  Discover and run project-specific lint, test, and type-check commands, reporting structured results with pass/fail status. Execute quality commands in parallel when possible. Use when running quality gates or verifying code changes.

• verdict-judge

  Judge implementation completeness by receiving acceptance criteria and an evidence bundle, then returning per-criterion verdicts of PASS, FAIL, or NEEDS-HUMAN-REVIEW. Run by bin/flow-judge.sh --judge verdict (/flow:start Phase 4 step 6) through the claude CLI with no tools; never dispatched as a sub

Hooks (19)

• PreToolUse

  ${CLAUDE_PLUGIN_ROOT}/hooks/scripts/block-force-push.sh

• PreToolUse

  ${CLAUDE_PLUGIN_ROOT}/hooks/scripts/block-destructive.sh

• PreToolUse

  ${CLAUDE_PLUGIN_ROOT}/hooks/scripts/block-unchecked-merge.sh

• PreToolUse

  ${CLAUDE_PLUGIN_ROOT}/hooks/scripts/block-secrets.sh

• PreToolUse

  ${CLAUDE_PLUGIN_ROOT}/hooks/scripts/ask-issue-create.sh

• PreToolUse

  ${CLAUDE_PLUGIN_ROOT}/hooks/scripts/tier-gate.sh

• PreToolUse

  ${CLAUDE_PLUGIN_ROOT}/hooks/scripts/ask-policy.sh

• PostToolUse

  ${CLAUDE_PLUGIN_ROOT}/hooks/scripts/log-file-changes.sh

• PostToolUse

  ${CLAUDE_PLUGIN_ROOT}/hooks/scripts/log-commits.sh

• PostToolUse

  ${CLAUDE_PLUGIN_ROOT}/hooks/scripts/record-quality-run.sh

• PostToolUse

  ${CLAUDE_PLUGIN_ROOT}/hooks/scripts/s1-screen-text.sh

• PostToolUseFailure

  ${CLAUDE_PLUGIN_ROOT}/hooks/scripts/record-quality-run.sh

• TaskCompleted

  ${CLAUDE_PLUGIN_ROOT}/hooks/scripts/verify-task-completion.sh

• TeammateIdle

  ${CLAUDE_PLUGIN_ROOT}/hooks/scripts/nudge-idle-teammate.sh

• SessionEnd

  ${CLAUDE_PLUGIN_ROOT}/hooks/scripts/session-end-learn.sh

• SessionEnd

  ${CLAUDE_PLUGIN_ROOT}/hooks/scripts/session-end-state.sh

• Stop

  ${CLAUDE_PLUGIN_ROOT}/hooks/scripts/flow-goal-stop.sh

• Stop

  ${CLAUDE_PLUGIN_ROOT}/hooks/scripts/reply-style-check.sh

• SessionStart

  ${CLAUDE_PLUGIN_ROOT}/hooks/scripts/tier-session-start.sh

Similar plugins