release: add spotify placeholder and align python toolchains

Why:
Add the new spotify plugin placeholder in socket, make Python maintainer guidance explicitly require repo-local dev dependencies, and bump the changed shipped surfaces by a patch.

Verification:
uv run scripts/validate_socket_metadata.py
cd plugins/agent-plugin-skills && uv run pytest && uv run ruff check . && uv run mypy .
cd plugins/python-skills && uv run pytest && uv run ruff check . && uv run mypy .

Author: gaelic-ghost

.agents/plugins/marketplace.json

@@ -112,6 +112,18 @@
       },
       "category": "Productivity"
     },
+    {
+      "name": "spotify",
+      "source": {
+        "source": "local",
+        "path": "./plugins/spotify"
+      },
+      "policy": {
+        "installation": "AVAILABLE",
+        "authentication": "ON_INSTALL"
+      },
+      "category": "Productivity"
+    },
     {
       "name": "web-dev-skills",
       "source": {

AGENTS.md

@@ -49,7 +49,9 @@ Use this file for durable repo-local guidance that Codex should follow before ch
 - Keep the same names for the same concepts across `SKILL.md`, `agents/openai.yaml`, docs, automation prompts, scripts, and marketplace metadata.
 - If docs and scripts disagree, fix the script or narrow the documented contract so they match.
 - When shipped behavior, active skill inventory, packaging roots, or validation commands change, update the relevant docs and `ROADMAP.md` in the same pass unless Gale explicitly says not to.
-- For Python-backed skill repositories, prefer `uv sync --dev`, `uv run pytest`, and uv-managed maintainer tools such as `ruff` and `mypy`.
+- For Python-backed repositories in `socket`, use `uv` as the maintainer baseline and declare repo-local dev dependencies in `pyproject.toml` instead of relying on globally installed tools.
+- Prefer a root or package-local dev group that explicitly includes the Python maintainer tools the repo expects to run, including `pytest`, `ruff`, and `mypy` when those checks are part of the workflow.
+- Prefer `uv sync --dev`, `uv run pytest`, `uv run ruff check .`, and `uv run mypy .` for repos that actually ship those Python-backed validation surfaces.
 - When OpenAI or Claude product behavior matters, prefer official docs first. When describing Codex plugin boundaries, say plainly that repo-visible plugins come from the documented marketplace model and that OpenAI does not currently document a richer repo-private scoping model.
 - Use these terms consistently:
   - `skill`: reusable workflow-authoring unit

CONTRIBUTING.md

@@ -58,6 +58,8 @@ The root superproject uses a small `uv` environment for maintainer tooling:
 uv sync --dev
 ```
 
+If a root or child-repo workflow depends on Python quality tooling, declare that tooling in the relevant repo's `pyproject.toml` dev dependencies rather than assuming a machine-global install. Treat `pytest`, `ruff`, and `mypy` as the normal Python maintainer baseline when the repo's shipped validation surface uses them.
+
 The root validation path does not require application secrets. If your change involves subtree sync or GitHub operations, make sure your git remotes and GitHub authentication are already configured on your machine before you start those steps.
 
 ### Runtime Behavior
@@ -106,6 +108,8 @@ uv sync --dev
 uv run scripts/validate_socket_metadata.py
 ```
 
+If the changed surface also introduces or expands Python-backed repo checks, add the required tools to the repo-local `uv` dev group and document the corresponding `uv run pytest`, `uv run ruff check .`, and `uv run mypy .` commands where that repo's contributors will actually look.
+
 When editing docs, also review the rendered Markdown structure and cross-links for the files you changed.
 
 ## Pull Request Expectations

README.md

@@ -69,6 +69,8 @@ Sync the root maintainer environment with:
 uv sync --dev
 ```
 
+For Python-backed maintainer tooling in this superproject or its child repositories, keep the repo-local baseline explicit in `pyproject.toml` instead of assuming machine-global tools. When a repo expects Python validation, declare the needed dev dependencies there, including `pytest`, `ruff`, and `mypy` when those checks are part of the shipped workflow.
+
 Only `apple-dev-skills`, `python-skills`, and `SpeakSwiftlyServer` still use subtree sync workflows. `socket` itself does not ship a root plugin; the marketplace is the root packaged surface here.
 
 ### Workflow
@@ -95,6 +97,8 @@ Run the root validator locally with:
 uv run scripts/validate_socket_metadata.py
 ```
 
+When a child repository or helper surface grows Python-backed validation beyond this root metadata check, add those checks as repo-local `uv` dev dependencies and document the exact `uv run ...` commands in that child repo instead of assuming a globally provisioned toolchain.
+
 ## Repo Structure
 
 ```text
@@ -139,7 +143,7 @@ The root superproject docs are:
 
 Treat `socket` as the canonical home for the monorepo-owned child directories and as the subtree host for the remaining imported child repos.
 
-- `agent-plugin-skills`, `cardhop-app`, `dotnet-skills`, `productivity-skills`, `rust-skills`, `things-app`, and `web-dev-skills` are monorepo-owned here.
+- `agent-plugin-skills`, `cardhop-app`, `dotnet-skills`, `productivity-skills`, `rust-skills`, `spotify`, `things-app`, and `web-dev-skills` are monorepo-owned here.
 - `apple-dev-skills`, `python-skills`, and `SpeakSwiftlyServer` preserve explicit subtree sync paths.
 - Child repos may expose plugin packaging from their own repo roots whether they are monorepo-owned here or still preserve subtree sync.
 - `things-app` packages from its child-repo root at `./plugins/things-app`, and its bundled MCP server lives directly under that child repo's top-level `mcp/` directory.
@@ -159,6 +163,7 @@ That marketplace points at the actual packaged surface each child repository tre
 - `./plugins/SpeakSwiftlyServer`
 - `./plugins/python-skills`
 - `./plugins/rust-skills`
+- `./plugins/spotify`
 - `./plugins/things-app`
 - `./plugins/web-dev-skills`
 

ROADMAP.md

@@ -71,6 +71,7 @@ Planned
 
 ## History
 
+- Added the placeholder `plugins/spotify` child repository, wired it into the root marketplace, and kept the superproject docs honest about that new monorepo-owned plugin surface.
 - Converted the former standalone `cardhop-mcp` checkout into the monorepo-owned `plugins/cardhop-app` child, added first-pass Codex plugin metadata plus a bundled MCP config, and recorded the new child as a normal `socket` marketplace entry.
 - Retired the remaining `things-app` subtree-era wording from the root maintainer docs, removed the now-redundant local `things-app` and `things-app-mcp` sibling checkouts after verification, and prepared the `v0.11.1` plus `things-app v0.1.3` patch bump.
 - Synced the `SpeakSwiftlyServer` subtree through the newer `v4.2.x` plugin and embedded live-speech updates, confirmed the root marketplace path still stayed valid, and kept the superproject release trail explicit with the `v0.11.0` bump.

plugins/agent-plugin-skills/.codex-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "agent-plugin-skills",
-  "version": "1.3.0",
+  "version": "1.3.1",
   "description": "Installable maintainer skills for skills-export repositories.",
   "author": {
     "name": "Gale",

plugins/agent-plugin-skills/AGENTS.md

@@ -29,6 +29,8 @@ Use this file for durable repo-local guidance that Codex should follow before ch
 - Treat maintainer docs under [`docs/maintainers/`](./docs/maintainers/) as the durable explanation layer for repo policy and packaging boundaries.
 - Keep Codex plugin guidance aligned with the current OpenAI docs: only `plugin.json` belongs in `.codex-plugin/`, while `skills/` stays at the plugin root.
 - Keep Codex plugin-boundary wording factual and explicit: repo-visible plugins come from the documented marketplace model, and OpenAI does not document a richer repo-private scoping model beyond that.
+- For Python-backed maintainer repositories, require `uv` plus repo-local dev dependencies in `pyproject.toml` for the tools the repo expects to run.
+- Do not teach or rely on machine-global `uv tool install` as the primary baseline for repo validation when the repo can declare `pytest`, `ruff`, and `mypy` directly in its dev dependency group.
 
 ### Communication and Escalation
 
@@ -56,6 +58,8 @@ uv sync --dev
 
 ```bash
 uv run pytest
+uv run ruff check .
+uv run mypy .
 ```
 
 ### Optional Project Commands

plugins/agent-plugin-skills/CONTRIBUTING.md

@@ -52,6 +52,8 @@ This repository uses `uv` for local Python tooling. Sync the dev environment bef
 uv sync --dev
 ```
 
+Keep the maintainer toolchain declared in the repository itself. If the repo expects linting, type-checking, or tests, add those tools to the repo-local dev dependency group in `pyproject.toml` instead of relying on `uv tool install` or other machine-global setup. Treat `pytest`, `ruff`, and `mypy` as the default Python maintainer trio when the shipped workflow uses them.
+
 This repo does not require dedicated local services or repo-specific secret configuration for normal docs and test work.
 
 ### Runtime Behavior
@@ -62,6 +64,8 @@ Run the normal validation flow with:
 
 ```bash
 uv run pytest
+uv run ruff check .
+uv run mypy .
 ```
 
 ## Development Expectations
@@ -89,6 +93,8 @@ Prefer the grounded repo checks:
 ```bash
 uv sync --dev
 uv run pytest
+uv run ruff check .
+uv run mypy .
 ```
 
 If you changed only prose, still sanity-check the nearby docs for split clarity and internal consistency before handing the work off.

plugins/agent-plugin-skills/README.md

@@ -62,6 +62,8 @@ Sync the local maintainer environment before changing the Python-backed audit to
 uv sync --dev
 ```
 
+Keep the Python maintainer baseline repo-local. When this repo or a target repo expects Python checks, declare the required dev dependencies in `pyproject.toml` instead of assuming contributors already installed standalone tools globally. The normal baseline is `pytest`, `ruff`, and `mypy` when those checks are part of the shipped workflow.
+
 ### Workflow
 
 Keep root [`skills/`](./skills/) canonical, keep maintainer docs under [`docs/maintainers/`](./docs/maintainers/), and keep plugin metadata in [`.codex-plugin/plugin.json`](./.codex-plugin/plugin.json).
@@ -77,6 +79,8 @@ Run the repo-local tests before landing changes that touch skill behavior, docs-
 ```bash
 uv sync --dev
 uv run pytest
+uv run ruff check .
+uv run mypy .
 ```
 
 ## Repo Structure

plugins/agent-plugin-skills/docs/maintainers/reality-audit.md

@@ -28,7 +28,7 @@ For the durable map of Codex plugin catalogs, staged payloads, installed cache p
 - `.agents/skills` and `.claude/skills` are POSIX symlink mirrors to `../skills`.
 - README and AGENTS say plainly that this repo exports installable skills and that OpenAI documents marketplace-based plugin discovery rather than a richer repo-private plugin scope.
 - ROADMAP matches the live exported skill set.
-- Maintainer tooling guidance includes `uv sync --dev`, `uv tool install ruff`, `uv tool install mypy`, and `uv run --group dev pytest`.
+- Maintainer tooling guidance includes `uv sync --dev`, repo-local `pyproject.toml` dev dependencies for `pytest`, `ruff`, and `mypy`, plus the corresponding `uv run pytest`, `uv run ruff check .`, and `uv run mypy .` commands when those checks are part of the shipped workflow.
 - No tracked file reintroduces nested staged plugin directories, repo-marketplace guidance for this repo, installer workflows, or install-validation workflows.
 
 ## Specialist Owners