opencode-power-pack: 54 Portable Agent Skills and an Opt-In Sandbox Runner
54 rigorous skills for Codex, OpenCode, and Pi: code review, security audit, feature development, frontend design, MCP tools, Hugging Face ML/training, and more.
At a glance
- What is it?
- A collection of 54 skills that plug into Claude Code, Codex, OpenCode, and Pi, plus a v0.5.0 sandbox CLI that wraps commands in Seatbelt or Bubblewrap profiles. The value is portability across four agents; the cost is that the sandbox guarantee is deliberately narrow.
- Who is it for?
- Adopt it if you already run two or more of Claude Code, Codex, OpenCode, and Pi and want one skill set instead of four divergent prompt libraries, or if you need per-command containment for review and audit work. Skip it if you only use one agent and already have local prompts, or if you need whole-agent isolation: the README states the current guarantee is only that a command and its descendants are shell-contained.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 2 days ago.
- What is it written in?
- Mainly Python, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The problem: four coding agents, four disconnected prompt libraries
If a team uses Claude Code on one machine, Codex on another, and Pi or OpenCode for a third workflow, the same review checklist gets written three times and drifts. opencode-power-pack addresses that by shipping 54 skills that all four agents can discover, with namespacing so explicit invocations do not collide. In Claude Code the README shows skills mounted under a plugin namespace, so a call looks like /opencode-power-pack:code-review rather than a bare /code-review. Codex uses a dollar prefix, for example $code-review and $security-review. Pi discovers the skills straight from the package declaration and reports them through pi list. The intended audience is engineers who want the same review, audit, and feature-development procedures available regardless of which agent is open in the terminal, and who would rather install a versioned package than copy prompt files between dotfolders by hand.
How the pack is structured: skills as files, one shared install location
The mechanism is file placement plus per-agent discovery. The npm installer copies skills into a shared .agents/skills location that the README says Codex, OpenCode, and Pi all recognize, which is why a single install command can serve three of the four agents. Claude Code and Codex instead go through their own plugin marketplaces, and Pi installs directly from the Git repository. That means there are three distinct delivery paths for the same content: plugin marketplace, npm copy, and git install. The consequence is that version pinning behaves differently depending on the path. The README's sandbox example pins an exact version with npm install --global @waybarrios/opencode-power-pack@0.5.0, while the update example uses @latest with --force to overwrite previously copied skills. If you mix paths on one machine, you can end up with skills from two different releases in the same session, and nothing in the material suggests a reconciliation step for that.
The v0.5.0 sandbox: profiles, fail-closed behaviour, and a narrow guarantee
The sandbox runner is the most concrete engineering claim in the repository. It uses native isolation rather than containers: Seatbelt on macOS and Bubblewrap on Linux, with no image, daemon, or persistent sandbox to manage. Skills are assigned one of four least-privilege profiles (observe, develop, network-read, publish), and escalation beyond the assigned profile requires an explicit check. The failure mode is defined as fail-closed: if isolation is unavailable, an escalation is undeclared, a confirmation is missing, or the backend fails, the README states that execution stops rather than retrying outside the sandbox. That is the right default for a tool that runs agent-generated commands, but read the scope carefully. The README is explicit that the guarantee is limited to shell-contained execution for the command and its descendants, and that automatic host routing and whole-agent isolation are not claimed yet. Treat this as per-command containment, not as a jail around the agent itself.
Getting it running: four install paths and the sandbox CLI
For Claude Code, the README gives /plugin marketplace add waybarrios/opencode-power-pack followed by /plugin install opencode-power-pack@opencode-power-pack, and notes that /reload-plugins may be required. For Codex, the commands are codex plugin marketplace add waybarrios/opencode-power-pack --ref main and codex plugin add opencode-power-pack@opencode-power-pack, after which /plugins confirms the installation. Pi uses pi install git:github.com/waybarrios/opencode-power-pack, with -l added for a project-local install recorded in .pi/settings.json. The npm route is the most granular: npx @waybarrios/opencode-power-pack list enumerates profiles and skills, install --profile recommended writes the balanced profile for the current user, install code-review security-review selects individual skills, --project scopes the install to the repository, and --dry-run previews without writing. The sandbox itself is exercised through three commands shown in the release notes: npm install --global @waybarrios/opencode-power-pack@0.5.0, then opencode-power-pack sandbox doctor --json to verify the boundary, then opencode-power-pack sandbox exec --skill code-review -- git status --short to run a command under the skill's trusted profile.
Where it is the wrong tool
The sandbox profile model assumes a skill knows what it needs. A skill assigned observe cannot reach the network without an escalation check, which is correct for a review pass but awkward for a task that legitimately fetches dependencies mid-run. The fail-closed default means those runs stop rather than degrade, and the README does not describe a per-invocation override that keeps containment while widening the profile, so the practical workaround is likely to run the command outside sandbox exec entirely. That is a real trade-off, not a defect: the design optimizes for predictable refusal. The second limitation is the four-agent pitch itself. If you use exactly one agent and are happy with its built-in commands, installing a 54-skill pack adds surface area for no portability gain, and the selective installer exists precisely because the full set is more than most projects need. The third is the version skew noted earlier: the README's own update example uses @latest with --force, which overwrites copied skills in place.
Alternative: agent-native commands and hand-written prompt files
The obvious alternative is not another skill pack but the built-in slash commands each agent already ships, supplemented by a repository-local prompt directory. The difference in approach is ownership and scope. Agent-native commands are maintained by the vendor, updated with the agent, and cannot fall behind a separate release cadence, but they are not portable and they cannot be assigned a sandbox profile. A local prompt directory is fully under your control and reviewable in your own pull requests, but nothing enforces what a prompt is allowed to execute. opencode-power-pack sits between those: it accepts a third-party release cadence and a dependency on the npm registry in exchange for one skill definition shared across four agents and a capability contract that a prompt file alone cannot express. If your team already has prompt files that work and you do not need the sandbox profiles, the pack's main selling point does not apply to you.
Maintenance, licensing, and what to check before adopting
The release history shows v0.3.0 in early August 2026, v0.4.0 on 13 August, and v0.5.0 on 17 August, with the last push to main on 7 September. That is a fast cadence, which cuts both ways: fixes arrive quickly, and the surface you install can shift between minor versions. The repository is MIT licensed, but the README's badge and THIRD_PARTY_NOTICES.md indicate a mixed MIT and Apache-2.0 position, so the per-file terms are worth checking rather than assuming a single licence covers all 54 skills. Nothing here is legal advice. On upgrade cost, the npm path is the cheapest to reason about: npm update --global @waybarrios/opencode-power-pack for a global install, or the @latest install --force pattern to refresh copied skills, with --dry-run available to preview a selection first. The plugin marketplace paths for Claude Code and Codex are managed by the agents themselves, and the material does not describe how to pin a specific release there, so verify that before standardizing on it across a team.
Editorial conclusion
Adopt it if you already run two or more of Claude Code, Codex, OpenCode, and Pi and want one skill set instead of four divergent prompt libraries, or if you need per-command containment for review and audit work. Skip it if you only use one agent and already have local prompts, or if you need whole-agent isolation: the README states the current guarantee is only that a command and its descendants are shell-contained. Before installing, run opencode-power-pack sandbox doctor --json and confirm which backend (Seatbelt on macOS, Bubblewrap on Linux) is actually available, then read docs/sandbox-compatibility.md and THIRD_PARTY_NOTICES.md to see which of the 54 skills fall under Apache-2.0 rather than MIT.
Community notes