[FEATURE]: Add .claude/commands/ compatibility (like .claude/skills/)

[SeanZoR]

Summary

OpenCode supports Claude Code's .claude/skills/ paths for skill discovery, but doesn't support .claude/commands/ paths for command discovery. This creates an inconsistent migration experience for users coming from Claude Code.

Current Behavior

Skills - OpenCode searches these paths (per docs):

• .opencode/skill/<name>/SKILL.md (project)
• ~/.config/opencode/skill/<name>/SKILL.md (global)
• .claude/skills/<name>/SKILL.md (project, Claude-compatible)
• ~/.claude/skills/<name>/SKILL.md (global, Claude-compatible)

Commands - OpenCode only searches (per docs):

• .opencode/command/ (project)
• ~/.config/opencode/command/ (global)

No .claude/commands/ compatibility.

Proposed Behavior

Add Claude-compatible command paths to match the skills behavior:

• .claude/commands/<name>.md (project)
• ~/.claude/commands/<name>.md (global)

Use Case

Users migrating from Claude Code who have existing commands at ~/.claude/commands/ currently need to either:

1. Copy/move files to ~/.config/opencode/command/
2. Create symlinks manually

This is friction that doesn't exist for skills.

Related Issues

• Does opencode actually support finding skills at .claude/skills? #6266 - .claude/skills/ compatibility discussion
• Skill discovery doesn't match Claude Code's skills/ directory structure #6177 - Skill discovery paths
• feat: add support for .claude/skills directory #6252 - PR that added project-level .claude/skills/ support

[github-actions]

This issue might be a duplicate of existing issues. Please check:

• Does opencode actually support finding skills at .claude/skills? #6266: Does opencode actually support finding skills at .claude/skills? - Related to Claude Code path compatibility
• [feat] custom slash commands #299: [feat] custom slash commands - Related feature for custom command management
• [FEATURE]: Plugin Hook for Registering Additional Config Directories #6347: [FEATURE]: Plugin Hook for Registering Additional Config Directories - Related to configurable discovery paths for commands and skills

Feel free to ignore if none of these address your specific case.

[mamoreau-devolutions]

I just tried doing basic compatibility by copying .claude/commands to .opencode/command, but it looks like there are incompatibilities with the frontmatter for things like the argument-hint: https://code.claude.com/docs/en/slash-commands#frontmatter

I wouldn't mind having to duplicate certain frontmatter parameters for Claude Code and OpenCode, but this particular incompatibility prevents OpenCode from loading it. Therefore, I can't just use a git symlink for compatibility like I do for GitHub Copilot.

[zerobell-lee]

It even interprets instructions wrongly. I tried running slash commands on both environment; ~/.config/opencode/commands and ~/.claude/commands, they were recognized successfully, but one in ~/.claude/commands never worked. It just adds custom command instruction onto the prompt and make user request empty.

[pablontiv]

Additional Context: Frontmatter Incompatibility

Building on @mamoreau-devolutions' comment about frontmatter incompatibilities, here's the full mapping needed for Claude Code → OpenCode command compatibility:

Claude Code Frontmatter

name: my-command
description: Does something
argument-hint: <topic>
allowed-tools: [Read, Write, Bash]
model: claude-sonnet-4-20250514

OpenCode Command Frontmatter

description: Does something
agent: build
model: anthropic/claude-sonnet-4-20250514
subtask: false

Key Differences

Claude Code	OpenCode	Notes
name	filename	OpenCode derives name from file
argument-hint	-	No equivalent (causes parse error)
allowed-tools	-	No equivalent
model	model	Different format (provider/model)
-	agent	OpenCode-specific
-	subtask	OpenCode-specific

Suggested Solution

When loading from .claude/commands/, OpenCode could:

1. Ignore unknown frontmatter fields instead of erroring
2. Map argument-hint to hints array
3. Auto-prefix model with provider if missing

This would allow the same command file to work in both tools.

---

Alternatively, issue #10262 (plugin dynamic commands) would let a compatibility plugin handle this translation layer without core changes.

[github-actions]

To stay organized issues are automatically closed after 90 days of no activity. If the issue is still relevant please open a new one.