About this skill

Problem

When building OpenCode skills or agents, core rules, permission descriptions, description constraints, and test boundaries often blur together. This can cause mode confusion, false positives, permission gaps, or leaked sensitive information. This skill separates creation and design review, and requires review to be delegated to the skill-review subagent instead of relying on the main model to self-review.

How It Works

It starts by printing a declaration line that confirms the mode, target, and review depth.
Creation mode uses references/patterns.md and references/agent-format.md.
Review mode delegates to the skill-review agent and runs references/red-team-testing.md.
Temporary files go to .opencode/.tmp/, tracking folders can use .opencode/notepads/, and scripts/validate-skill.mjs provides automated validation.
Common pitfalls include too many core rules, important constraints buried in descriptions, not restarting after changing agents, doing runtime testing during design review, and treating ## When to Use as a plain comment.

Boundaries and Notes

This skill focuses on design quality, structure, permissions, and security checks. It does not replace runtime functional testing; behavioral verification belongs to skill-tester. It acts more like a pre-commit structure checker, useful after changing permissions, descriptions, or core rules, rather than running full business use cases. For packaging, installation, or command-file management, use opencode-skill-packager, opencode-skill-installer, or opencode-command-manager instead.

Screenshots

Use Cases

Before adding an OpenCode skill, check core rules, description constraints, and permission config for clarity and overload.
After changing agent permissions or core logic, delegate design review to skill-review and run red-team tests.
When auditing existing skill docs, use checklists and common traps to catch mixed modes, buried rules, and test-boundary risks.
Before publishing a skill package, run validate-skill.mjs and follow temp-directory rules to keep test files out of real paths.

Best For

Engineers maintaining an OpenCode skill library: confirm structure, permissions, and security checklists before merging a new skill.
Developers building agent workflows: decide when to re-review and restart after changing agent markdown or permissions.
Tech leads owning AI tooling delivery: require every new agent to have a reviewable design review and red-team test record.
Application developers handling sensitive prompts: scan examples for leaked usernames, paths, or API keys before release.