Add command/prompt sync presets for Claude Code, Cursor, and Codex

[hhh2210]

Summary

Add first-class support or presets for syncing reusable slash-command prompt files across tools that already support this workflow:

• Cursor: Markdown commands under .cursor/commands/ (and commonly user-level ~/.cursor/commands/) become /command-name entries.
• Claude Code: existing .claude/commands/*.md and ~/.claude/commands/*.md files still work; current Claude Code docs say custom commands have been merged into skills, and commands keep working with the same frontmatter. Skills are the preferred richer format, but command files remain a compatibility target.
• Codex CLI / IDE extension: custom prompts are deprecated in favor of skills, but still supported as Markdown prompt files under ~/.codex/prompts/, invoked as /prompts:<name>. Codex scans top-level Markdown files in that folder.

Today this is technically possible with extras, but users have to know every target path and each tool's exact behavior. A built-in command/prompt preset would make this much less error-prone.

Why this matters

A common workflow is a small command such as commit-smart.md:

• inspect recent commit style
• inspect staged diff (or unstaged diff if nothing is staged)
• generate a commit message
• run git commit with that message

This is exactly the kind of lightweight workflow that users want available as /commit-smart in Cursor and Claude Code, and as /prompts:commit-smart in Codex. It is too small to require a full skill directory in every tool, but valuable enough to sync across machines and agents.

Current skillshare behavior

extras already supports arbitrary resources, for example:

extras:
  - name: commands
    targets:
      - path: ~/.claude/commands
      - path: ~/.cursor/commands
      - path: ~/.codex/prompts

This works as a low-level escape hatch, but it has several rough edges:

1. Users must manually know that Codex calls this prompts, not commands, and invokes it as /prompts:<name>.
2. Users must know that Codex custom prompts are deprecated and global-only, while Codex skills are preferred for shared/repo workflows.
3. Users must know that Claude Code command files still work, but skills are now the recommended richer path.
4. Future tool-specific conversion problems are easy to miss. Issue Convert command extras to TOML when syncing to Gemini CLI target #136 already shows this for Gemini, where Markdown command extras need to become TOML.

Proposal

Add one of these product surfaces:

Option A: first-class commands resource

Support commands similarly to skills/agents, with target-aware paths and documentation:

skillshare commands init --targets claude,cursor,codex
skillshare commands sync
skillshare commands collect --from cursor
skillshare commands list --json

Target mapping could start conservative:

• claude: ~/.claude/commands globally, .claude/commands in project mode
• cursor: .cursor/commands in project mode, and optionally ~/.cursor/commands globally if the project wants to support the user-level path
• codex: ~/.codex/prompts globally; document that Codex invokes these as /prompts:<name> and that skills are preferred for repo-shared workflows

Option B: extras presets / target aliases

Keep extras as the implementation, but let users specify tool targets instead of raw paths:

skillshare extras init commands --target claude --target cursor --target codex

This would expand to the right target paths and attach target-specific notes/warnings. Later, the same mechanism could support format: toml or similar for Gemini command conversion (#136).

Acceptance criteria

• A user can sync one Markdown command source to Claude Code, Cursor, and Codex without manually remembering all three path conventions.
• Docs explain the invocation differences:
  • Cursor/Claude: /command-name
  • Codex: /prompts:command-name
• Docs explain Codex's current deprecation status: custom prompts still work, but skills are recommended for reusable instructions that should be shared through a repo or invoked implicitly.
• Project vs global behavior is explicit, especially because Codex prompts are currently local Codex-home files rather than project-discovered files.
• The implementation does not break existing extras configs.

Related issues

• support slash command sync #134 asked for slash command sync, but it was closed after assuming Codex intended to remove all slash command functionality. Current docs show the more precise state: Codex custom prompts are deprecated in favor of skills, but still supported and invokable as /prompts:<name>.
• Convert command extras to TOML when syncing to Gemini CLI target #136 covers a target-specific format conversion problem for Gemini commands, which would fit naturally into the same command/prompt preset story.

[hhh2210]

@runkids Hi! I noticed that a few other users are also interested in this feature. Given our smooth collaboration on #145, I was wondering if we could continue discussing the feasibility of this issue.

I’d be happy to provide more context or help validate the approach if that would be useful. Thank you!

[TIR44]

I did a current-main pass after the recent extras extension work, and I think Option B is now the smallest first step.

Current flow as I read it:

• cmd/skillshare/extras_init.go treats every --target value as a raw path and stores it directly in config.ExtraTargetConfig{Path: ...} for both global and project config.
• sync extras already has the right lower-level surface for tool-specific output: ExtraTargetConfig.Extension is resolved during sync, transform targets use copy semantics, sync --all --json follows the same path, and extras collect already treats extension-managed targets as one-way.
• extras list already reports extension-backed target status using the extension output_ext, so a commands preset should not need a new sync model.
• The TUI currently suggests generic rules paths, including ~/.codex/rules, which is probably misleading for this specific workflow because Codex command-style prompts live under ~/.codex/prompts.

A narrow first PR could keep extras as the implementation and add only preset expansion for command/prompt extras:

• add a small resolver for command target presets, covered by unit tests;
• wire it into extras init commands ... for CLI first, leaving existing raw path configs untouched;
• map global presets conservatively:
  • claude -> ~/.claude/commands
  • cursor -> ~/.cursor/commands
  • codex -> ~/.codex/prompts
• map project presets only where the target is project-local:
  • claude -> .claude/commands
  • cursor -> .cursor/commands
  • keep Codex project mode explicit, either by rejecting codex with a clear message or requiring the user to pass ~/.codex/prompts manually, since Codex prompts are currently Codex-home files rather than project-discovered files;
• update extras init help/TUI placeholders so command examples mention Codex prompts and the invocation difference.

I would avoid adding skillshare commands ... in the first PR. It looks like the existing extras model is already capable enough; the missing piece is the target convention knowledge at init time plus clear docs/help text. If this direction matches the intended product shape, the implementation can stay small and should not affect existing extras configs or sync behavior.