Enhancement: help users get deterministic skill resolution when sibling wizards are installed (ship a bin/oc wrapper or .envrc)

[BaseInfinity]

Follow-up to #26 (skill-name collision / non-deterministic resolution).

Problem recap

When opencode-sdlc-wizard is installed alongside claude-/codex- siblings, OpenCode reads .opencode/skills + .claude/skills + .agents/skills, and same-named skills resolve non-deterministically per session (verified in #26). The installer already detects siblings (both can coexist), but coexistence is only true on disk — at runtime the wizard's own .opencode skills can lose a coin-flip to the Claude/Codex copies.

Verified fix

Launching OpenCode with OPENCODE_DISABLE_CLAUDE_CODE_SKILLS=1 + OPENCODE_DISABLE_EXTERNAL_SKILLS=1 makes it read only .opencode/skills/ — deterministic across runs, zero external leakage. (There is no opencode.json key for this; .env is NOT honored — both tested.)

Requested enhancement

When the installer detects sibling wizards, offer to drop in one of these (opt-in), and document the trade-off (the Claude-only meta-skills won't show in OpenCode):

1. A repo wrapper bin/oc (zero-dependency):

#!/usr/bin/env bash
export OPENCODE_DISABLE_CLAUDE_CODE_SKILLS=1
export OPENCODE_DISABLE_EXTERNAL_SKILLS=1
exec opencode "$@"

2. Or a .envrc (direnv) so bare opencode auto-isolates per-repo:

export OPENCODE_DISABLE_CLAUDE_CODE_SKILLS=1
export OPENCODE_DISABLE_EXTERNAL_SKILLS=1

Plus a post-install opencode debug skill check that warns if any wizard-installed .opencode/skills/* is being shadowed.

Real-world validation

Applied this in a consumer repo (3 lanes: Claude Code + Codex + OpenCode). Result: deterministic .opencode-only resolution, OpenCode-native sdlc/gdlc/rdlc load reliably, end-to-end smoke test passes (build agent routes to claude-sonnet-4-6, skills resolve correctly).

Environment: OpenCode 1.16.2, opencode-sdlc-wizard 0.13.4, macOS 15.1 arm64.