Flywheel

Plugin fw in mopeyjellyfish/flywheel. Commands read from the repo's manifest — 1 month ago.

Skills (32)

• architecture-strategy

  Assess repo-grounded architecture choices and improvements. Use for boundaries, service splits, dependency direction, or distributed posture.

• brainstorm

  Explore requirements and approaches. Use for a fuzzy idea, open scope, or one direction that needs sharper behavior before planning.

• browser-test

  Run browser acceptance checks with playwright-cli. Use when browser-visible behavior needs fresh proof before review or commit.

• commit-message

  Draft Conventional Commit messages. Use when choosing a commit header, body, footer, or breaking-change marker.

• commit

  Finish a branch cleanly. Use to verify readiness, make logical commits, push, and create or refresh a PR with evidence.

• debug

  Investigate hard bugs, regressions, stack traces, or broken behavior with evidence, a repro loop, causal proof, and a fix path.

• decision

  Grill and capture durable decisions. Use for ADRs, terminology conflicts, tradeoffs, or spec decision review.

• deepen

  Grill and strengthen an existing plan. Use to align source docs, decisions, vertical slices, tests, and rollout before work.

• docs

  Write or refresh Diataxis project docs. Use when setup, APIs, CLI flows, config, workflows, or behavior changed.

• document-review

  Review requirements or plan docs. Use to surface severity, confidence, and a ranked fix queue before planning or work.

• ideate

  Generate and filter grounded next bets. Use when the work is not chosen and the user wants ranked ideas before brainstorming.

• incident

  Handle runtime incidents from live evidence. Use to bound blast radius and choose mitigation, rollback, or patch.

• logging

  Design or review structured logging. Use when runtime behavior needs useful events, stable fields, or correlation IDs.

• maintainability

  Assess future edit cost. Use when wrappers, helpers, naming, cohesion, or ownership may make changes harder.

• observability

  Design or review runtime observability. Use for logs, metrics, traces, dashboards, validation, and supportability.

• optimize

  Run measured optimization loops. Use for latency, throughput, resource, cost, build, or query improvements that need proof.

• pattern-recognition

  Assess pattern fit from repo truth. Use when deciding whether DTOs, repositories, ports, builders, DDD, or similar patterns fit.

• plan

  Create read-only implementation plans. Use for requirements, bug reports, feature ideas, or rough tasks before execution.

• polish

  Run an interactive browser polish loop. Use to tighten browser-visible work with live feedback before review or commit.

• research

  Research a topic with repo and current-source evidence. Use when findings should sharpen shaping, review, or planning.

• review

  Run structured code review. Use before PRs or merges to find bugs, regressions, missing tests, and readiness gaps.

• rollout

  Plan release posture for runtime-risky changes. Use for validation, sequencing, rollout, rollback, and blast radius.

• run

  Optionally orchestrate remaining Flywheel stages. Use only when one coordinated pass is better than manual stage handoffs.

• setup

  Diagnose and bootstrap repo-local setup. Use for onboarding, workflow readiness, host posture, or missing tool checks.

• shape

  Shape work before implementation. Use to choose ideation, brainstorming, planning, or plan-deepening before work.

• simplify

  Reduce accidental complexity in recent code. Use when wrappers, abstractions, or orchestration no longer earn their keep.

• spin

  Capture durable lessons in docs/solutions. Use after completed work, verified fixes, or repeated repo-specific patterns.

• start

  Route project work through Flywheel. Use to pick the earliest useful stage from shape, work, review, spin, or commit.

• tdd

  Enforce red-green-refactor for feature work, bug fixes, refactors, and behavior changes.

• verify

  Verify completion claims with fresh evidence. Use before claiming tests, lint, builds, fixes, or requirements are done.

• work

  Execute ready implementation work. Use for plans, specs, todos, or clear requests that need tracked changes and validation.

• worktree

  Manage isolated git worktrees. Use for branch work, isolated review targets, parallel checkouts, or cleanup.

Hooks (2)

• PreToolUse

  node "${CLAUDE_PLUGIN_ROOT}/hooks/flywheel-hook-policy.js" pre-tool claude

• Stop

  node "${CLAUDE_PLUGIN_ROOT}/hooks/flywheel-hook-policy.js" stop claude

Similar plugins