release-smoke-test

Validates packed oh-my-opencode-slim release candidates in isolated OpenCode environments before npm publish.

Updated Aug 16, 2026
One-click install
npx skills add https://github.com/Aveer/skills --skill release-smoke-test-aveer
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: release-smoke-test
Source: https://github.com/Aveer/skills/tree/main/skills/release-smoke-test
Command: npx skills add https://github.com/Aveer/skills --skill release-smoke-test-aveer

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Publishing an OpenCode plugin release without testing the actual packed artifact risks shipping crashes, plugin resolution failures, or model-specific regressions that only appear outside the source tree. ## Core Features & Use Cases - Artifact-Based Validation: Packs the release candidate with npm pack and installs the tarball into a throwaway app, ensuring you test exactly what users will receive. - Isolated OpenCode Config: Creates a sanitized environment (env -i, temp HOME and XDG_CONFIG_HOME) so plugin_origins contains only the intended plugin, with a labeled host-provider fallback when isolation breaks provider aliases. - Crash Signature Detection: Runs opencode run with DEBUG logging and searches logs for known regression signatures such as the OpenCode 1.17.11 malformed-message crash. - Use Case: Before publishing a bugfix for a message transform regression, pack the candidate, install it in a temp app, run an isolated smoke against a free model, confirm no TypeError appears in logs, and record results on the release PR using the reporting template. ## Quick Start Ask the agent to smoke test the current release candidate by packing it, installing the tarball into an isolated throwaway app, and running an OpenCode smoke prompt with DEBUG logs.

Frequently Asked Questions about release-smoke-test

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I smoke test an OpenCode plugin before publishing to npm?▼

Pack the candidate with npm pack, install the tarball into a throwaway app, point an isolated OpenCode config at the installed dist/index.js, and run opencode run with --print-logs --log-level DEBUG. Verify plugin_origins contains only your plugin and search logs for crash signatures.

How to create an isolated OpenCode config for plugin testing?▼

Write a minimal opencode.json in a temp XDG_CONFIG_HOME directory referencing the plugin via a file:// URL, then run with env -i, a temp HOME, and stripped host variables. Use opencode debug config to confirm exactly one plugin origin loaded.

Why should I test the packed tarball instead of the source tree?▼

The packed artifact is what users actually install from npm, so it catches packaging errors, missing dist files, and build issues that the source tree hides. Testing @latest or local source can pass while the published package is broken.

Does this release smoke test workflow work on Windows?▼

Yes, the POSIX commands are illustrations only. On Windows use a unique directory under $env:TEMP, PowerShell or Python to write files, quoted paths, and a Windows-compatible timeout while preserving the same pack-install-isolate-run contract.

What if the isolated environment cannot resolve OpenAI provider aliases?▼

Run a second host-provider smoke using OPENCODE_CONFIG_DIR pointed at a temp config while keeping the plugin path on the tarball install. Label it as weaker isolation and use opencode debug config to disclose what else merged in.