opencode-qa
QA opencode itself, per case: verify the CLI/terminal (opencode run, db, serve, export), prove a specific plugin hook/action/event fired via the SSE event stream, smoke-test the TUI under tmux, and investigate sessions in opencode's SQLite DB by id, title/name, or message text. Ships tested helper scripts (each with a --self-test) plus per-domain references. Use whenever someone wants to QA, smoke-test, verify, or debug opencode's CLI, HTTP server, plugin hooks/events, or TUI, or to find/inspect opencode sessions in the database. Triggers: opencode qa, qa opencode, test opencode, verify openco
Profile →npx skills add code-yeongyu/oh-my-openagent --skill opencode-qa --agent claude-code
Same command for any agent — swap --agent for codex, cursor, copilot.
Weekly change comes from our own snapshots, not the repository page — it measures attention, not adoption.
# opencode QA QA the opencode coding agent itself. This skill maps each QA need to a tested helper script and a deep reference. Every script ships a `--self-test` that asserts its scenario against the live machine, so the scripts are both the QA tools and their own regression checks. Verified against opencode v1.17.7 (bun 1.3.12, macOS). Confirm the installed version with `opencode --version`; the surface is stable but always sanity check a flag with `opencode <cmd> --help`. ## Golden rules (read before running anything) - READS of the live DB are safe and intended. Investigating sessions (Case D) only reads `~/.local/share/opencode/opencode.db`. - Anything that SPAWNS opencode (serve, run, the TUI) must use an isolated XDG sandbox so QA never writes junk sessions into the real DB. The bundled scripts already do this; if you run opencode by hand for QA, set `XDG_DATA_HOME` / `XDG_CONFIG_HOME` / `XDG_STATE_HOME` / `XDG_CACHE_HOME` to temp dirs first. - Global text search over the `part` table is a multi-GB scan. Always scope it (`--session`, `--recent`, or `--since`). The text script refuses an unbounded scan on purpose. - The opencode source repo (`packages/opencode`) tests itself
- Golden rules (read before running anything)
- Setup
- Router: pick your case
- Case A: CLI / terminal works
- Case B: a specific hook, action, or event
- Case C: the TUI
- Case D: investigate sessions in the DB
- Scripts index
- Risks and caveats
- References
cd <this-skill-dir> # .agents/skills/opencode-qa bash scripts/lib/common.sh --self-check # confirm the harness + deps stream structured events (types: text, tool_use, step_start, step_finish, reasoning, error) opencode run "list files in src" --format json run a slash command opencode run --command commit resume the last session opencode run -c "continue" target an already-running server instead of booting one opencode run "explain auth" --attach http://127.0.0.1:4096 -p "$OPENCODE_SERVER_PASSWORD"
What does the opencode-qa skill do?
QA opencode itself, per case: verify the CLI/terminal (opencode run, db, serve, export), prove a specific plugin hook/action/event fired via the SSE event stream, smoke-test the TUI under tmux, and investigate sessions in opencode's SQLite DB by id, title/name, or message text. Ships tested helper scripts (each with a --self-test) plus per-domain references. Use whenever someone wants to QA, smoke-test, verify, or debug opencode's CLI, HTTP server, plugin hooks/events, or TUI, or to find/inspect opencode sessions in the database. Triggers: opencode qa, qa opencode, test opencode, verify openco
How do I install it?
Run `npx skills add code-yeongyu/oh-my-openagent --skill opencode-qa --agent claude-code` — it drops the skill into your project so the agent can pick it up. Swap the --agent value for codex, cursor or copilot if you use one of those.
Where does this skill come from?
From code-yeongyu/oh-my-openagent, a repository with 67,209 stars. We read it straight from the repository tree rather than a submitted listing, so what you see here is what is actually published.
Is a popular skill a good skill?
Not necessarily. Stars measure attention, not adoption — a repository can trend for a week and be abandoned. That is why we show the weekly change from our own snapshots next to the total, instead of a single flattering number.