Fill the v0.1.0 stub body. Description rewritten to document two distinct flows (was iterative-only, even though triggers already listed targeted-frames phrases): - Flow A — iterative-watch (transcript → pick anchors → frames): for "what's in this video / summary / о чём ролик / video summary / youtube transcript" - Flow B — targeted-frames (frames only, no transcript): for "посмотри 1:23 / покажи кадр на N / что показано на N" — user already named timestamps, transcript fetch would be pure waste Body sections filled (6): When/Prereq/Inputs/Steps/Failure/Side/NOT — Flow A and Flow B distinguished throughout. Failure modes table covers missing CLI, missing yt-dlp/ffmpeg (with Windows winget+PATH note), network/private/age- gated, subs-disabled. What NOT to do explicitly forbids the "always-iterative" trap that the v0.1.0 description implicitly invited. Bump version 0.1.0 → 0.2.0 (MINOR — documents new capability set). Description 744 chars (under 900-char soft budget; well below ~1024 hard limit). Installed to ~/.claude/skills/using-yt-tools/ via scripts/install.ps1 — harness skill- listing renders full description, not truncated to H1. STATUS.md: closes new [using-yt-tools-skill-body-fill] 🟢 (filed+closed in-place since this is one body-fill task, not a multi-session workstream). [using-yt-tools-review] stays 🔵 — body-fill blocker removed, but still blocked on [using-yt-tools-trigger-smoke-clean-session] (needs fresh CC session). Caveat recorded: body-fill was done by implementer instead of the 'fresh agent' the review-task originally specified — explicit user approval. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
claude-skills
Russian version: README.ru.md.
Joint workshop and storage for Claude skills.
About
A shared workspace where Claude and I author, debug, and ship skills together:
skills/— editable sources (markdown + assets), the source of truthdist/— built.skillarchives for Claude, committed to the repohermes/— Hermes-rollout config:mapping.yamland anymode: manualoverrides underhermes/skills/dist-hermes/— pre-converted Hermes-flavour skill tree, committed (regenerated byscripts/build-hermes.py)scripts/— utilities:build.sh(source →.skill),install.sh(source →~/.claude/skills/),build-hermes.py(source →dist-hermes/).wiki/,.tasks/— working notes and the task board
Quick start
Install skills on a fresh machine
Windows (PowerShell):
git clone <repo> claude-skills
cd claude-skills
bash scripts/install.sh # copies every skills/* into ~/.claude/skills/
# or only specific ones:
bash scripts/install.sh caveman wiki-maintainer
Linux / macOS (bash):
git clone <repo> claude-skills
cd claude-skills
bash scripts/install.sh # copies every skills/* into ~/.claude/skills/
# or only specific ones:
bash scripts/install.sh caveman wiki-maintainer
The install target can be overridden with CLAUDE_SKILLS_DIR=/path bash scripts/install.sh.
install.shworks on Windows under git-bash. A nativeinstall.ps1is on the task board but not yet implemented.
Using skills in projects
Once the skills are installed, the easiest way to wire them into a new
(or existing) project is the project-bootstrap
skill. Tell the agent "bootstrap" or "set everything up" from the
project's folder and it will, in one pass:
- initialize
git(if missing) and write a sane.gitignore - create a starter
README.md - lay out
.wiki/per the Karpathy LLM Wiki pattern (delegated tosetup-wiki) - lay out
.tasks/with the canonical task board (delegated tosetup-tasks) - write
CLAUDE.mdwith skill triggers (use superpowers,use project wiki,use task management system,check across all projects,we're on Windows) - record the skill versions used in
.wiki/concepts/bootstrap-manifest.mdso cross-project layout drift stays debuggable - check whether the official
superpowers@claude-plugins-officialplugin is installed and, if not, print the install command — theuse superpowerstrigger is a no-op without it
Two modes, picked automatically: init for an empty folder, upgrade
for an existing project (the skill only fills the gaps and never overwrites
without explicit confirmation). On upgrade, CLAUDE.md is merged
idempotently — only canonical trigger lines that aren't already present are
appended after explicit confirm, so re-running project-bootstrap after a
template change picks up the new triggers without duplicating the old ones.
Edit a skill
# 1. Edit skills/<name>/SKILL.md (or its assets).
# 2. Push the changes into the live skill folder:
bash scripts/install.sh <name>
# 3. Rebuild the archive (optional, but handy before a commit):
bash scripts/build.sh <name>
Build .skill archives
bash scripts/build.sh # all skills
bash scripts/build.sh caveman # one skill
build.sh uses zip when it's available (Linux/macOS) or delegates to
scripts/build.ps1 via PowerShell (Windows without zip). On Windows you
can also run powershell scripts/build.ps1 directly.
Build for Hermes
The same skills/ are rolled out to Hermes Agent (Nous Research) on factory
Linux machines. The converter reads hermes/mapping.yaml (per-skill
mode / category / replace-rules / skip-list) and writes a Hermes-formatted
skill tree to dist-hermes/, which is committed to the repo.
python scripts/build-hermes.py # regenerate dist-hermes/ from mapping
Every skill in skills/ must have an explicit entry in mapping.yaml
(auto / manual / skip / pending); the build fails on unmapped skills.
Skip and pending entries land in dist-hermes/SKIPPED.md with reasons. Full
design rationale lives in
.wiki/concepts/hermes-skills-rollout-design.md.
Layout
claude-skills/
├── skills/ ← sources (one folder per skill)
├── dist/ ← .skill archives for Claude (committed)
├── hermes/
│ ├── mapping.yaml ← per-skill Hermes-rollout config
│ └── skills/ ← `mode: manual` overrides (Hermes-flavour rewrites)
├── dist-hermes/ ← pre-converted Hermes-flavour tree (committed)
│ ├── <category>/<name>/ ← e.g. software-development/pulling-before-work/
│ └── SKIPPED.md ← skip + pending log (auto-generated)
├── scripts/
│ ├── build.sh / build.ps1
│ ├── install.sh / install.ps1
│ └── build-hermes.py
├── .wiki/ ← design docs, notes
├── .tasks/ ← STATUS.md
├── CLAUDE.md
└── README.md (this file — see README.ru.md for Russian)
For the principles and decisions behind this layout see
.wiki/concepts/repo-layout.md.