CI Setup

Prepare release/versioning automation after the local OpenCode adapter and tests exist.

Preconditions

• Local migration exists: opencode-plugin/, tests, and migration docs.
• User has approved CI/versioning setup. If not, present a proposal first.

Workflow

1. Inspect version sources: .claude-plugin/plugin.json, plugin/.claude-plugin/plugin.json, package.json, tags, changelog, and existing release workflows.
2. Decide the OpenCode package version source. Use the source plugin version when clear; ask on conflicts; otherwise keep 0.1.0 and document the decision.
3. Validate package metadata and tests:

python3 skills/migrate-plugin/scripts/validate_opencode_package.py <repo> --format markdown
python3 skills/migrate-plugin/scripts/validate_skills.py <repo> --format markdown

4. Propose CI before writing it. Include what each job proves: package metadata, skill drift, hook tests, MCP config shape, existing Claude tests, and optional npm publishing.
5. Only after approval, add minimal workflow files and docs.

Proposal shape:

## CI / Versioning Proposal

- Version source: <manifest/package/tag and value>
- Validation jobs: <package lint, skill drift, hook tests, MCP shape>
- Publish path: <trusted publishing, NPM_TOKEN, or not configured>
- Files to add/change: <workflow and docs>
- Approval needed: <yes/no, secrets/permissions>

CI Policy

• Prefer validation and drift checks before publish automation.
• For package-local skill copies, add a test/check that compares copied skill content with the declared source of truth.
• Prefer npm trusted publishing when the repo is ready and the maintainer has package ownership; otherwise document required NPM_TOKEN setup without inventing secrets.
• Do not change the core migration output unless CI exposes a real defect.

See versioning and release guidance for version-source rules.

Completion

Report the chosen version source, workflows or checks added, secrets/permissions the maintainer must configure, and commands to verify locally.