Workbench is a mono-repo template that engineers clone for a consistent, structured development environment. It wires together multiple project repos as git submodules and provides a standard set of slash commands for orchestrating AI coding agents through a defined development workflow.

In multi-repo team environments, development configuration — editor settings, linter rules, CI pipelines, git hooks, and sub-agent configuration — drifts out of sync across team members. Each engineer maintains their own ad-hoc setup, leading to inconsistent tooling, broken pipelines, and onboarding friction. Workbench solves this by centralizing all configuration in a single mono-repo template. Engineers clone it and get a complete, consistent environment: .opencode/ commands and skills, .workbench/ settings, and standardized tooling are all pre-configured.

AI coding agents lose context between sessions. Without a structured workspace, each new session requires re-explaining the project structure, conventions, and active work — wasting time and producing inconsistent results. Workbench gives AI agents a persistent home. Git submodules keep projects organized, issue tracking integration and slash commands maintain workflow state across sessions, and the .workbench/ and .opencode/ directories store project-specific configuration that agents reference automatically.

Without standardized workflows, each team member interacts with AI coding agents differently — different prompts, different quality gates, different review processes. This leads to uneven code quality and unpredictable delivery. Workbench provides a structured Agentic Software Development Life Cycle (ASDLC) — a pipeline of slash commands (/ticket, /research, /plan, /execute, /review, /commit) that guide every issue through consistent stages, each powered by a dedicated sub-agent with a specific responsibility. The human runs the slash commands; the agents execute the structured workflows.

• Bun installed
• gh CLI installed and authenticated (gh auth login)

Choose to install the CLI from the package manager or the source code.

Install the package from or .

For example:

npm install -g @workbench-codes/workbench

If you have cloned the repo and you don't want to install the package from npm (or other sources) then this is how you install the package.

cd packages/workbench-cli
bun install
bun link

See packages/workbench-cli/README.md for full CLI documentation.

workbench --init

This launches an interactive flow to fork, clone, and wire up your repositories.

Once your workbench is set up, work on issues using the built-in slash commands in either OpenCode or Claude Code. Both implement the same structured flow from issue analysis through to review.

• OpenCode or Claude Code installed
• A configured project management tool (see Project Management below)

/implement

/implement is the end-to-end orchestrator. It resumes from the issue's current status label and runs the remaining commands automatically. Each /implement run also creates a PM document with an implementation report.

Manual flow remains available:

/ticket → /research → /plan → /execute → /review → /commit

Each command takes an issue ID as its argument and is best run in a fresh OpenCode session:

Under the hood, each slash command is powered by a dedicated sub-agent:

• ticketer — powered by /ticket. Handles interactive Q&A, scope boundary exploration, and ticket writing.
• researcher — powered by /research. Runs a multi-phase pipeline to locate, pattern-match, and analyze relevant code in the codebase.
• planner — powered by /plan. Interacts on design decisions and writes detailed phased implementation plans.
• executer — powered by /execute. Implements phases sequentially, tracks deviations from the plan, and writes execution notes.
• reviewer — powered by /review. Validates the implementation against plan specifications and writes review reports.
• committer — powered by /commit. Creates atomic git commits with conventional messages and issue trailers.

/implement orchestrates these sub-agents automatically, advancing through the workflow based on the issue's current status label.

# Manual flow
/ticket PAP-1234
/research PAP-1234
/plan PAP-1234
/execute PAP-1234
/review PAP-1234
/commit

# Orchestrated flow
/implement PAP-1234

# ONLY for GitHub Issues we also need to pass the {owner}/{repo}
# Thisis needed because GitHub issues are unique in scope of a repository
/implement 54 workbench-codes/workbench
# or up to a stage
/implement 54 plan workbench-codes/workbench

# Orchestrated flow with optional stop-step bound
/implement PAP-1234 research

/implement accepts an optional stop-step (ticket|research|plan|execute|review|commit). Input is case-insensitive, normalized to lowercase, and must not be earlier than the issue's current status progression.

The commands are defined in .opencode/command/ and can be customised for your own workflow.

The workbench supports multiple project management backends. The active backend is configured in .workbench/settings.yml via the project_management field:

project_management: github-issues

Supported PM tools are:

• Linear (linear)
• GitHub Issues (github-issues)

Authentication and setup instructions vary by backend — refer to the relevant PM tool's documentation for authentication steps.

The setup wizard optionally indexes your repositories with ck — a hybrid code search tool by BeaconBay that fuses lexical (BM25/grep) precision with embedding-based recall, so you can find the right code even when the exact keywords aren't there.

The workbench is periodically updated with improvements to slash commands, skills, schemas, and documentation. To fetch the latest managed files from the source repository, run workbench --sync from your workbench root:

workbench --sync

Sync clones the source, applies the configured file paths (.opencode/, .workbench/schemas/, README.md), and auto-commits changes with a chore message. An interactive confirmation prompt lets you review and abort before any files are overwritten.

Sync requires an initialized workbench (created via workbench --init) and a clean working tree. Run periodically to stay updated.

See packages/workbench-cli/README.md for full flag documentation and troubleshooting.

To set up the workbench CLI for local development:

cd packages/workbench-cli
bun install
bun tsc --noEmit

This installs dependencies and runs the TypeScript type checker. See CONTRIBUTING.md for the full development workflow, build commands, and PR submission guide.

workbench is inspired by Cluster444/agentic, which pioneered the idea of a structured agentic development workflow using slash commands.

Contributions are welcome. See CONTRIBUTING.md for setup instructions, the development workflow, and how to submit a PR.

Please read our Code of Conduct before participating.

MIT — see LICENSE.