Docs

Write concise maintainer-facing docs for completed or in-progress OpenCode migration work.

Inputs To Inspect

• OPENCODE_SUPPORT.md, README, package docs, and generated opencode-plugin/ files.
• Migration evidence: source URL/commit or fixture path, surface inventory, hook parity, MCP decisions, tests, and caveats.
• Shared snippets in maintainer explanations.

Workflow

1. Inspect existing docs and generated adapter files.
2. Draft or update the maintainer docs.
3. Verify the docs cover: source/version, files added, safety for Claude users, verification commands, MCP separation, caveats, and next steps.
4. Summarize the documentation changes.

Output Rules

• Explain what changed, why it is safe, how to verify it, and what is intentionally not automated.
• Keep MCP setup separate from package install instructions.
• Say “after package publication” for public opencode plugin <package> installs unless publication already exists.
• Include CI/versioning as a next step and offer ci-setup when publishing, trusted publishing, or skill-copy sync is relevant.
• Do not add .github/workflows/*, npm publishing config, or release automation.

Use this compact section shape when creating OPENCODE_SUPPORT.md:

## OpenCode Support

- Source: <repo>@<commit or fixture path>
- Generated files: <opencode-plugin files and config snippets>
- Compatibility: <what remains shared, what is OpenCode-specific>
- Verification: <commands/tests run>
- Caveats: <untested parity or manual setup>
- Next step: consider `ci-setup` for versioning/publishing checks.

Completion

Finish with updated docs plus a short summary of maintainer-facing changes and any remaining decisions.