opencode-workflow-playbook

An OpenCode-first, native-first vibecoding playbook for turning AI-assisted development into a repeatable, evidence-driven workflow.

简体中文 · Foundations · OpenCode implementation · Workflow chain · Evolution

Built around a simple idea: AI coding gets much better when ownership is clear, planning becomes explicit, tests anchor execution, and verification relies on evidence instead of confidence.

---

Why this exists

Most AI-assisted development workflows fail in one of two ways:

• they become fast but chaotic, with too many agents and no clear ownership
• or they become structured but brittle, with duplicated process spread across multiple systems

This repository documents a practical middle path.

The current public baseline is the native-first stack adopted in April 2026: OpenCode agents, commands, plugins, optional skills, and Sentry MCP, with planning and TDD anchored by PLAN.md and command workflows instead of a permanently layered five-tool stack.

It is a playbook for people who want to keep AI speed without losing:

• task ownership
• workflow explainability
• reusable conventions
• verification discipline

Who this is for

• solo builders using AI heavily in daily development
• engineers designing repeatable AI-assisted delivery workflows
• technical leads who need a way to explain how humans and agents should collaborate

What you will get

• transferable vibecoding principles
• anti-patterns that commonly break AI workflows
• verification guidance for docs, code, and runtime-sensitive work
• a native-first OpenCode implementation of the playbook
• shareable agent, command, plugin, and instruction templates
• a /plan -> /spec -> /implement workflow with acceptance criteria and test anchors
• model-routing guidance for mixing fast and deep modes
• evolution notes that explain how the stack changed and why

Two reading paths

Learn the playbook

Start here if you want the transferable methodology first:

• What is vibecoding?
• Core principles
• Common anti-patterns
• Verification discipline
• Case study: making a workflow public

Adopt the stack

Start here if you want the concrete OpenCode-first implementation:

• Architecture
• Setup
• Config overview
• Workflow: plan -> spec -> implement
• Workflow: model routing
• Glossary
• Decision records
• Evolution timeline

Quick start

1. Read the foundations docs to understand the workflow model.
2. Choose a minimal or full native-first OpenCode setup.
3. Copy and adapt the templates in config/.
4. Use /plan to write PLAN.md, /spec to create test anchors, then /implement to execute against the plan.
5. Use the examples in examples/ as workflow patterns, not as commands to paste blindly.

Core operating model

The implementation documented here follows one explicit rule:

one primary owner per task, optional overlays only when they add a distinct kind of value.

That rule is what keeps the stack composable instead of turning it into a pile of overlapping automation.

Repository map

.
├── README.md
├── README.zh-CN.md
├── LICENSE
├── CHANGELOG.md
├── CONTRIBUTING.md
├── CODE_OF_CONDUCT.md
├── SECURITY.md
├── ROADMAP.md
├── config/
│   ├── AGENTS.template.md
│   ├── ROUTING_POLICY.template.md
│   ├── ENV_SELF_CHECK_POLICY.template.md
│   ├── agents/
│   ├── commands/
│   └── plugins/
├── docs/
│   ├── evolution/
│   ├── foundations/
│   ├── opencode/
│   │   ├── decisions/
│   │   └── workflows/
│   ├── superpowers/   # historical 2026-03 planning artifacts
│   └── zh-CN/
├── examples/
└── .github/

Open source signals

• Contributing
• Code of Conduct
• Security policy
• Roadmap
• License