add spotify skill#94
Conversation
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request adds a new rule to AGENTS.md regarding PR descriptions and introduces a new Spotify skill documentation (SKILL.md) in two locations to control Spotify playback via the spotify_player CLI. The review feedback correctly identifies several incorrect CLI commands and options in the documentation—such as invalid subcommands for playing, searching, queuing, transferring playback, and managing playlists—and provides accurate code suggestions to align the documentation with the actual CLI syntax.
Important
The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 1e5be0f77f
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| spotify_player playback play --name "track or album name" | ||
| spotify_player playback start --uri spotify:track:TRACKID |
There was a problem hiding this comment.
For requests to play a named track or URI, these examples parse incorrectly: upstream commands.rs defines play as resume-only with no arguments, and start requires a track/context/liked/radio subcommand plus --id or --name rather than --uri (the project README’s scripting example uses playback start track --id ...). Agents following this skill to start a specific song will get an argument error instead of playback.
Useful? React with 👍 / 👎.
| spotify_player search --query "bohemian rhapsody" --type track | ||
| spotify_player search --query "miles davis" --type artist | ||
| spotify_player search --query "chill vibes" --type playlist |
There was a problem hiding this comment.
When using the search section, every example fails argument parsing because upstream init_search_command only defines a required positional query; there are no --query or --type options. This blocks the main discovery workflow the skill advertises, so these should be positional-query examples such as spotify_player search "..." with any type filtering done on the returned data.
Useful? React with 👍 / 👎.
| ### Queue | ||
|
|
||
| ```bash | ||
| spotify_player queue --uri spotify:track:TRACKID |
There was a problem hiding this comment.
The CLI has no top-level queue subcommand: upstream command initialization lists get, playback, connect, like, authenticate, playlist, generate, and search, while queue is only exposed as a get key queue value. When a user asks to queue a track, this documented command will fail with an unrecognized subcommand, so either remove the queue-management claim or document a supported flow if one exists.
Useful? React with 👍 / 👎.
|
|
||
| ```bash | ||
| spotify_player get key devices | ||
| spotify_player playback transfer --device "device name" |
There was a problem hiding this comment.
For device selection, upstream commands.rs exposes a connect subcommand with required --id or --name; playback has no transfer subcommand. This example will fail whenever a user asks to switch playback devices, so it should use the supported connect syntax.
Useful? React with 👍 / 👎.
| spotify_player get key playlists | ||
| spotify_player playlist create --name "My Playlist" | ||
| spotify_player playlist delete --id PLAYLISTID |
There was a problem hiding this comment.
This playlist block uses names the CLI does not accept: the key enum exposes user-playlists, not playlists, creation is playlist new <name> rather than playlist create --name, and deletion takes a positional id rather than --id. Playlist listing, creation, and deletion requests will therefore fail from the skill as written.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 365f69b47e
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
|
|
||
| ## Core Rules | ||
|
|
||
| - Use `--json` or pipe through `jq` when output will be consumed by another tool or agent. |
There was a problem hiding this comment.
For any agent following this core rule by adding --json, the CLI will reject the command: checked upstream init_cli, which registers only theme/config/cache/config-override/daemon globals, and the README’s scripting example pipes spotify_player search "$query" | jq ... with no JSON flag. Keep the jq advice, but remove --json or agents will turn otherwise valid playback/search/get requests into argument errors.
Useful? React with 👍 / 👎.
1 participant
Summary
skills/spotify/SKILL.mdwrappingspotify_playerCLI (6.9k stars, Rust, actively maintained)Test plan
dotagents renderregenerates plugin copy correctly/spotifyspotify_playercommands work after auth setup