Publish a harness-agnostic ytstudio agent skill (SKILL.md)

[jdwit]

Context

Our README positions ytstudio as "designed for humans and AI agents", but today we ship only a PyPI CLI. Agent skills are now a portable, harness-agnostic way to teach any agent how to drive a tool: a skill is just a folder with a SKILL.md (YAML frontmatter plus instructions), optionally bundling reference files and helper scripts. Registries like skills.sh distribute these like npm packages across many agent runtimes, and publishing is low-friction (a public GitHub repo with a SKILL.md is already a published skill).

This issue is intentionally scoped to one vendor-neutral deliverable: author and publish a ytstudio SKILL.md. No MCP server, nothing tied to a specific harness or platform.

Goal

Author a model- and harness-agnostic SKILL.md that teaches an agent to operate a YouTube channel through the existing ytstudio CLI, following the open SKILL standard so it works across the agents that skills.sh tracks.

Proposed structure

A skills/ytstudio/ folder (location TBD: this repo or a dedicated repo):

• SKILL.md with frontmatter:
  • name: ytstudio
  • description: one line stating when to use it (managing/automating a YouTube channel from the terminal: bulk video edits and uploads, analytics, comments, livestreams, playlists), so an agent can judge relevance.
• Instructions body, concise and using progressive disclosure:
  • Prerequisites: install ytstudio (uv/pipx/pip), one-time ytstudio init + ytstudio login, and the profile model for multi-channel.
  • Core usage patterns per command group, stressing the two things an agent must know: pass -o json for parseable output, and mutations are dry-run by default so preview first, then re-run with --execute.
  • Pointers rather than a full dump: bundle the auto-generated command reference as a reference file the agent reads on demand.
• Optional bundled resources: a trimmed command reference kept in sync with the generated reference.md, and example YAML upload sidecars.

Publishing

• Put it in a public GitHub repo with the SKILL.md at the documented path; that alone makes it installable.
• List it on skills.sh and link it from our README/docs.
• Follow the open spec (agentskills/agentskills); avoid anything harness- or vendor-specific.

Acceptance criteria

• A valid SKILL.md (correct frontmatter, concise instructions) that an agent can follow to install, authenticate, and run read plus dry-run-gated write commands.
• No MCP and no harness/platform-specific content.
• Published in a public repo and discoverable on skills.sh.
• Documented and linked from the project README/docs.
• A note on keeping the bundled reference in sync with the generated command reference.

Notes

• The CLI already emits JSON everywhere and defaults mutations to dry-run, so the skill is mostly instructions over an existing, safe surface; minimal or no changes to the CLI itself.

[jdwit]

Scope narrowed per discussion: dropped the MCP server and any OpenClaw-specific packaging. This is now a single, model- and harness-agnostic SKILL.md targeting the open SKILL standard (publishable on skills.sh).

[jdwit]

On the open question of location ("this repo or a dedicated repo"): keep it in this repo. No separate public repo is needed.

The skill spec treats "a public GitHub repo containing a SKILL.md" as already published. ytstudio-cli is already public, so a skills/ytstudio/SKILL.md folder here satisfies the publishing requirement on its own.

Reasons to keep it in-repo rather than spin up a dedicated repo:

• Reference stays in sync for free. The "keep the bundled reference in sync with the generated command reference" acceptance criterion becomes trivial when the skill and the CLI share a commit/PR. We can regenerate skills/ytstudio/reference.md from the same source in the same change (a make skill-reference target or a CI check), instead of coordinating across two repos.
• Single source of truth, less overhead. No second repo with its own issues/CI/release cadence to maintain, and the skill versions naturally track the CLI it documents.
• Discoverability is unaffected. Monorepo skills in a subfolder are supported by the open spec (a skill is just "a folder with a SKILL.md", multiple per repo are allowed). When listing on skills.sh we point at the subpath (skills/ytstudio/) rather than the repo root.

Proposed resolution: set the location to this repo at skills/ytstudio/, and update the "Proposed structure" / "Publishing" sections accordingly (drop "dedicated repo").