fadamakis/workbench
Plan, build and review your next PR with the Workbench board and workflow skills.
Run the Workbench delivery stages continuously for an explicitly requested task. Use for /workbench:autopilot or an explicit request for Workbench autopilot mode. Reuse the existing stage skills, fix confirmed findings and resume from current evidence. Publish a draft PR and address feedback available during the active run. Stop when waiting for CI or reviews; never schedule future work automatically. End with a read-only improvement retrospective that cannot edit skills without a separate, explicit approval.
Maintain an existing Workbench PR by triaging review comments, diagnosing CI failures and resolving conflicts. Use for /workbench:greenlight or an explicit Workbench PR-maintenance request. Make authorized local fixes and refresh evidence; push, reply and resolve discussions only when those actions are authorized.
Explain Workbench commands and when to use each stage. Use for /workbench:help, "how does Workbench work?", "show me the Workbench steps", or "which Workbench command should I use?" Give a brief guide and one next-step suggestion. Do not start the workflow, inspect the repository or change task state for a help request.
Implement a Workbench slice optimized for code reviewability. Use for /workbench:implement or the active implementation stage. Choose the smallest clear design before editing, keep state ownership and control flow easy to trace, reuse established code and copy, and simplify the actual diff before verification. Do not publish or start a competing feature workflow.
Review a completed Workbench run for one reusable workflow improvement and apply it only after the user explicitly approves that exact proposal. Use for /workbench:improve or an explicit approval of a named Workbench improvement. Never infer approval from the delivery task, autopilot, silence or task notes.
Turn a ticket and designs into a small, evidence-based Workbench implementation plan. Use for /workbench:plan or the active Workbench planning stage. Reconcile acceptance criteria, existing code, API contracts, copy and dependent PRs. Do not replace a directly requested OpenSpec, ticket-refinement or PR-plan workflow.
Inspect and prepare the host-selected checkout for a Workbench task. Use for /workbench:prepare or when the active Workbench coordinator selects preparation. Inspect dirty Git state, target ownership, base and local runtime before changing anything. Do not trigger for unrelated Git questions or overwrite an existing checkout.
Commit and push the identified Workbench task and create or update its draft PR when the user invokes /workbench:publish or explicitly requests publication. Verify target ownership, remote head and tested content first. This stage never merges, deploys, marks a PR ready or grants permission to force-push.
Review a Workbench diff through one independent, read-only reviewer subagent. Use for /workbench:review or the active Workbench review stage. Check concrete defects and reviewer effort; the main agent validates findings and owns authorized fixes. Do not trigger for all PR reviews or post comments automatically.
Launch the app or Storybook from the intended Workbench checkout. Use for /workbench:run, /workbench:run app, /workbench:run storybook, or a request to preview the active Workbench change. Discover repository commands, check process ownership and ports, and return a working URL with stop instructions. This is an optional utility, not full feature verification.
Start or resume the Workbench delivery workflow when the user explicitly says "use Workbench", "resume Workbench", or invokes /workbench:start. Identify the current stage and load just that skill. Do not take over ordinary implementation, Jira, debugging or review requests outside an active Workbench task. Route requests to explain Workbench commands to help instead of starting work.
Explicit-only translation coordination for /workbench:translations with a PR, issue, or feature. Discover the repository's localization workflow, reuse an existing request, verify the requested languages, and track its actual result. Never invoke automatically because a PR changes copy.
Verify a Workbench change against acceptance criteria, CI configuration and the real runtime. Use for /workbench:verify or the active Workbench verification stage. Check UI behavior beyond Storybook where applicable and report passed, failed and blocked checks separately. Verification alone never authorizes a push.