Skip to content

fix(opencode): accept documented string forms for skill compatibility and top-level permission#2096

Merged
dyoshikawa merged 1 commit into
mainfrom
resolve-issue-2066-opencode-schema-unions
Jun 30, 2026
Merged

fix(opencode): accept documented string forms for skill compatibility and top-level permission#2096
dyoshikawa merged 1 commit into
mainfrom
resolve-issue-2066-opencode-schema-unions

Conversation

@dyoshikawa

Copy link
Copy Markdown
Owner

Summary

Follow-up for OpenCode upstream (#2066). Two schema-widening bug fixes so rulesync accepts the documented string forms instead of throwing or rejecting valid config.

Part 1 — skills compatibility string|object

OpenCode SKILL.md documents compatibility: opencode (a bare string), but the schema was object-only, so importing such a skill threw. Widened OpenCodeSkillFrontmatterSchema.compatibility to a string|looseObject union and propagated it through fromRulesyncSkill/toRulesyncSkill and the opencode section of rulesync-skill.ts.

Part 2 — permissions top-level uniform string

OpenCode documents a bare top-level string applying to all tools (permission: allow), but the top-level field was object-only. Widened to enum(allow,ask,deny) | record; a top-level string maps to the canonical model as { "": { "": value } }, mirroring OpenCode own "*"-as-all-tools convention (no meaningful lossiness; round-trips to the equivalent verbose object form).

Backward compatibility with the existing object forms is preserved.

Tests

  • opencode-skill.test.ts: string compatibility in to/fromRulesyncSkill + a fromDir import of compatibility: opencode.
  • opencode-permissions.test.ts: top-level permission: allow import maps to canonical { "": { "": "allow" } }.

Verification

pnpm cicheck fully green: 298 test files, 6622 tests; lint/typecheck, cspell, secretlint, supported-tools, gitignore all pass.

References

Closes #2066

… and top-level permission (#2066)

OpenCode documents SKILL.md `compatibility` as a free-form string (e.g. `compatibility: opencode`), but the schema modeled it as object-only, so importing the documented form threw `Invalid frontmatter`. Widen OpenCodeSkillFrontmatterSchema and the rulesync opencode-section schema to a string|object union and propagate it through toRulesyncSkill/fromRulesyncSkill.

OpenCode also documents the top-level `permission` config as accepting a bare uniform string (`"permission": "allow"`) applying to all tools, but the schema typed it as object-only. Widen OpencodePermissionsConfigSchema to a string|record union and map the uniform string into the canonical model as the wildcard tool/glob `{ "*": { "*": value } }`, matching OpenCode's own `*` all-tools convention. The object forms remain fully backward compatible.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
@dyoshikawa
dyoshikawa merged commit 0074575 into main Jun 30, 2026
9 checks passed
@dyoshikawa
dyoshikawa deleted the resolve-issue-2066-opencode-schema-unions branch June 30, 2026 23:02
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Follow up OpenCode upstream updates: skill compatibility frontmatter accepts a string, not object-only

2 participants