measured-workflows

Plugin measured-workflows from marketplace measured-skills in JovaniPink/measured-skills. Commands read from the repo's manifest — 6 days ago.

Skills (32)

• address-review

  Evaluates reviewer comments when asked to address feedback or decide whether a requested fix is valid; checks current code and tests before accepting, rejecting, or deferring it. Loads before file inspection when the request matches.

• align-on-decisions

  Clarifies an underspecified request when the desired result, constraints, or success criteria are unclear; asks only material questions and does not reopen settled decisions.

• assess-change-impact

  Traces a change's blast radius when asked what might break, which callers depend on it, or what else needs updating; separates traced dependencies from hypotheses. Loads before file inspection when the request matches.

• assess-worktree-isolation

  Assesses checkout isolation when concurrent edits or dirty files may collide with a new task; reuses safe worktrees and preserves unrelated work rather than creating or deleting blindly.

• author-skill

  Authors portable skills when asked to create or revise SKILL.md workflows and client distributions; preserves routing, provenance, and invocation controls rather than treating ordinary docs as skills.

• build-spike

  Runs an isolated technical experiment when explicitly asked to test feasibility or answer an implementation uncertainty; disposable evidence does not authorize production adoption.

• choose-workflow

  Suggests a workflow when a user asks which skill to use, where to start, or how to finish existing work. Returns a route, context needs, and a copyable prompt without executing it. Loads before file inspection when the request matches.

• coordinate-agents

  Coordinates delegated work when explicitly asked for independent workers or a bounded reviewer; defines ownership, evidence, and budgets without duplicating edits or delegating irreversible decisions.

• design-module-interface

  Designs module boundaries when asked to untangle coupling, simplify an API, or clarify ownership; makes caller contracts concrete before implementation.

• design-web-motion

  Designs web motion when asked to animate a design, plan an interaction, or create a product showcase. Specifies choreography, state, responsive behavior, and static alternatives; does not implement or publish.

• diagnose-failure

  Diagnoses failures when asked \"why is the build failing\", \"why did this regress\", or \"what caused this error\"; reproduces and tests hypotheses before proposing a fix. Loads before file inspection when the request matches.

• edit-technical-writing

  Edits technical writing when asked to tighten a status update, clarify documentation, or remove vague and repetitive prose; preserves evidence, uncertainty, and the author's meaning.

• execute-plan

  Executes an identified implementation plan when explicitly authorized to implement it; tracks checkpoints, tests, deviations, and unfinished work without expanding scope.

• explain-codebase

  Explains existing code when asked how a request flows, where behavior lives, or what a module does; grounds the explanation in current files rather than inferred historical intent.

• finish-branch

  Assesses next steps for a finished branch when explicitly asked to wrap up development; presents PR, retention, or cleanup options without assuming merge or deletion authority.

• frame-problem

  Frames a feature or problem when asked what to build, which outcome matters, or whether a proposed fix addresses the need; establishes users, constraints, and success before implementation.

• guide-configuration

  Guides account or device setup when explicitly asked to help with a protected configuration step; verifies visible results without requesting secrets or claiming unseen completion.

• handoff-work

  Prepares a continuation record when explicitly asked to hand off or resume work elsewhere; records exact state, unfinished work, evidence, and existing authority without transferring new permissions.

• implement-test-first

  Implements a bounded behavior change when explicitly asked to use test-driven development; establishes a meaningful failing test, makes it pass, and refactors within authorized scope.

• investigate-design-rationale

  Investigates why a design exists when asked why code was written that way or which constraint drove it; distinguishes historical evidence from plausible explanations.

• model-domain-vocabulary

  Clarifies domain terms when teams use the same word differently or code and documents disagree; proposes definitions and examples without declaring owner approval.

• plan-change

  Plans a change when asked for implementation steps, acceptance criteria, or a handoff-ready design; resolves interfaces and dependencies before execution without treating the plan as authorization. Loads before file inspection when the request matches.

• plan-tests

  Plans tests when asked what to test, which checks matter, or how to cover a risky change; selects proportionate unit, integration, contract, and journey evidence. Loads before file inspection when the request matches.

• publish-change

  Commits, pushes, or opens a PR only when explicitly requested; verifies identity, destination, diff, and checks while keeping merge, deployment, and release separately authorized.

• request-review

  Prepares a review packet when explicitly asked to request review of a change; states scope, tests, and risks, and sends it only when the destination and action are authorized.

• research-sources

  Researches a question when asked to look up, compare, or verify current facts; uses primary sources and preserves dates, links, and uncertainty without turning claims into findings.

• resolve-merge-conflicts

  Resolves a named Git conflict when explicitly asked to reconcile a merge, rebase, or cherry-pick; preserves both intents and keeps continuation, commit, and push authority separate.

• review-engineering-prompt

  Reviews a request for an engineering assistant when asked to check a prompt, clarify coding instructions, or improve a repair request. Checks outcome, context, scope, permissions, and completion evidence; returns feedback without executing the quoted task.

• review-workflow

  Reviews a completed workflow when explicitly asked what caused friction or what to improve next; uses observed task evidence without diagnosing people or claiming unmeasured benefit.

• run-research-workflow

  Coordinates a research lifecycle when explicitly asked to maintain traceable knowledge, evaluation, and corrections; excludes one-off search and never implies automatic publication.

• trace-decisions

  Maintains a decision log when explicitly asked to record choices, evidence, and unresolved work across a task; excludes hidden reasoning, raw transcripts, and unrelated private context.

• track-acceptance

  Creates a completion ledger when explicitly asked to track acceptance criteria and current evidence; preserves blocked and abandoned requirements.

Similar plugins