Skip to content

feat: OpenCode skill parity — generate the tree from canonical Claude skills #158

Description

@omergk28

Summary

The OpenCode integration ships 10 hand-written skills while Claude has 53
and Copilot CLI has 49. Notably absent is the entire planning arc documented
in Design Before Coding
/ctx-brainstorm, /ctx-spec, /ctx-task-out, /ctx-implement — so OpenCode
users cannot follow the project's own recommended design workflow.

Rather than hand-porting again, this proposes aligning OpenCode with the
Copilot CLI model: generate the tree from the canonical Claude skills at
build time.

Current state

Tree Skills Maintenance
Claude 53 canonical source of truth
Copilot CLI 49 35 auto-synced by hack/sync-copilot-skills.sh, 14 legacy-named and unsynced
OpenCode 10 fully hand-written

hack/sync-copilot-skills.sh already solves this for Copilot: it derives each
skill from internal/assets/claude/skills/<name>/SKILL.md with a one-line
sed stripping the Claude-specific allowed-tools: frontmatter key. It is
opt-in by directory presence (a skill with no Claude counterpart is left
untouched), wired into make build, and gated in CI by
make check-copilot-skills.

OpenCode has no equivalent. Its 10 skills are hand-written terse variants at
roughly 30% the length of their Claude counterparts — and diffing them shows
the terseness is truncated reference material (dropped flag tables, output
descriptions), not OpenCode-specific adaptation.

Why this is low-cost

The OpenCode skill path is already fully generic — no Go changes needed:

  • internal/assets/embed.go:22 embeds by glob: integrations/opencode/skills/*/SKILL.md
  • agent.OpenCodeSkills() (internal/assets/read/agent/agent.go:135) walks directory entries
  • deploySkills() (internal/cli/setup/core/opencode/skill.go:34) iterates whatever it finds
  • TestSkillFrontmatter enforces only name + description

Adding a skill is mkdir + a SKILL.md. Nothing registers or enumerates.

The planning arc is the easiest possible port: ctx-brainstorm, ctx-spec,
ctx-task-out, ctx-implement, and ctx-plan carry no allowed-tools key
at all
, so the sync transform is a byte-identical copy. Their cross-skill
references are closed within that set. The only Claude-specific line across all
five is a parenthetical at ctx-brainstorm/SKILL.md:200.

Proposed solution

  1. Add hack/sync-opencode-skills.sh as a sibling of the Copilot script — same
    opt-in-by-directory model, same allowed-tools: strip.
  2. Wire sync-opencode-skills into make build and add a
    check-opencode-skills CI gate mirroring check-copilot-skills.
  3. Enroll the planning arc (ctx-brainstorm, ctx-spec, ctx-task-out,
    ctx-implement, ctx-plan) plus the capture skills its bodies reference
    (ctx-task-add, ctx-decision-add) so no reference dangles.
  4. Enroll the existing 10 hand-written skills so the tree becomes uniform,
    replacing the truncated bodies with the canonical ones.
  5. Use canonical Claude skill names throughout. The 14 unsynced Copilot skills
    are unsynced precisely because they were renamed (ctx-add-task vs
    ctx-task-add); OpenCode already uses canonical names and should keep them.

Open question: terse variants

If lean skill bodies are wanted for OpenCode's context budget, the honest fix
is a terse transform in the sync script rather than two conventions coexisting
in one tree. Otherwise the truncation is unintentional divergence and should go.

Acceptance criteria

  • hack/sync-opencode-skills.sh exists and mirrors the Copilot script's contract
  • make build syncs OpenCode skills; make check-opencode-skills fails on staleness
  • The Design Before Coding arc is available in OpenCode
  • Enrolled OpenCode skills are byte-identical to their Claude source minus allowed-tools:
  • Skill names align 1:1 with the Claude tree
  • Build, lint, and compliance tests pass

Related

  • feat: Copilot CLI skill parity with Claude integration #61 — Copilot CLI skill parity with Claude integration (the precedent, closed)
  • Phase KB-followup in .context/TASKS.md — "adversarial design review of parallel
    skill trees" — this issue picks the canonical + build-time transform shape
    that Copilot already proves in production.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions