A generic development workbench for setting up and maintaining multiple projects from a single repository. Built and used internally by PAP — a no-code mobile building platform — and open for community use.
The repository acts as a hub: engineers fork it, configure their code and resource repositories as submodules, and get a consistent environment across the team.
| Folder | Purpose |
|---|---|
packages/workbench-cli/ |
The workbench CLI tool (TypeScript, Bun) |
projects/ |
Git submodules for code repositories |
resources/ |
Git submodules for documentation/resource repositories |
scripts/ |
Helper scripts for managing the codebase |
thoughts/ |
Planning notes, research, and ticket documentation (Not checked in) |
Linear is used for project management. To authenticate the Linear MCP (defined in .opencode/opencode.json), run:
opencode mcp auth linearThe workbench CLI provides a terminal UI for initializing a workbench repository — forking, cloning, and wiring up submodules interactively or non-interactively.
cd packages/workbench-cli
bun install
bun linkInteractive init — fork, clone, and set up in one flow:
workbench --initNon-interactive init:
workbench --init --no-tui --name my-projectInit + setup combined:
workbench --init --no-tui --name my-project --org myorg --code-repository https://github.com/myorg/apiAlready have a workbench repo cloned?
workbench --tuiSee packages/workbench-cli/README.md for the full flag reference and examples.
Once your workbench is set up, the primary way to work on issues is through OpenCode using the built-in slash commands. These commands implement a structured flow from issue analysis through to review.
- OpenCode installed
- Linear MCP authenticated (see MCP — Linear above)
/implement
/implement is the end-to-end orchestrator. It resumes from the issue's
current status-ticket label and runs the remaining commands automatically.
Each /implement run also creates a new Linear document artifact titled
Implementation Report: <ISSUE_ID> - YYYY-MM-DDTHH-MM-SSZ.
Manual flow remains available:
/ticket → /research → /plan → /execute → /review → /commit
Each command takes a Linear issue ID as its argument and is best run in a fresh OpenCode session:
| Command | What it does |
|---|---|
/ticket {issue-id} |
Analyses the Linear issue and structures it for development |
/research {issue-id} |
Researches the codebase in context of the issue |
/plan {issue-id} |
Creates a detailed implementation plan |
/execute {issue-id} |
Implements the plan |
/implement {issue-id} [ticket|research|plan|execute|review|commit] |
Orchestrates all remaining workflow steps, optionally bounded to a stop-step |
/commit |
Commits the changes in atomic commits, ready for review |
/review {issue-id} |
Reviews the execution against the plan |
# Manual flow
/ticket PAP-1234
/research PAP-1234
/plan PAP-1234
/execute PAP-1234
/review PAP-1234
/commit
# Orchestrated flow
/implement PAP-1234
# 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 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.
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.