Stub claimed the plugin's SessionStart hook runs `pipx install yt-tools` (PyPI install). v1 retargeted to plugin-only distribution 2026-05-26 — the hook actually runs `pipx install --force "$CLAUDE_PLUGIN_ROOT[full]"` from the plugin's local clone (PyPI release deferred post-v1). Aligned 3 doc locations:
- frontmatter description (line 4) — describes local-clone install with [full]-default + core fallback.
- "Why the move" § (lines 17-20) — same alignment.
- "How to install the replacement" § (lines 31-35) — same alignment.
- "Source pointers" PyPI link (line 54) — qualifier "(deferred post-v1; not yet published)".
Frontmatter version bumped 0.4.0 → 0.4.1 (PATCH — docs-only, no behavior change). Stub still declares no trigger phrases — remains inert under invoke-by-name to avoid double-activation with the plugin's skill.
Closes part of yt-tools-distrib-docs-sync-pypi-deferred (R4 location 4-of-4).
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
This skill is no longer maintained in claude-skills. The canonical source
is now skills/using-yt-tools/SKILL.md inside the OpeItcLoc03/yt-tools
plugin repository, distributed via the OpeItcLoc03/claude-plugins
marketplace.
Replaces the v0.3.2 fully-Russian SKILL body (~250 lines, 3 flows incl.
Locating binaries probe chain + Invoke pattern + Failure modes table) with
a short English deprecation stub.
Frontmatter changes:
- version: 0.3.2 → 0.4.0 (breaking — content reduced to stub, source
location moved; pre-1.0 convention: minor bumps cover breaking moves)
- description: full English deprecation notice with install command for the
plugin replacement; intentionally drops all trigger phrases so this stub
cannot double-activate alongside the plugin's bundled skill once the user
has installed the plugin.
Body: brief pointer prose — why the move, how to install the plugin
replacement, what to do with this directory after the plugin install
succeeds (delete it), and source pointers to the new repos and design doc.
The plugin distribution is the new source-of-truth: bug fixes, new flows,
trigger updates ship there. This stub will be removed once enough downstream
users have migrated (no fixed timeline; tracked in the yt-tools-distribution
review umbrella).
Bug surfaced in field: agent in another session probed only legacy venv
location, found empty (post-pipx-migration), then took install-hint
verbatim and started recreating the venv we just deleted — destructive
cleanup paradox.
Three fixes:
- Add `~/.local/bin/yt-frames.exe` as known location #2 in probe chain
(between PATH and legacy venv). pipx is now recommended install per
yt-tools README; shim lives there.
- Rewrite install-hint to pipx-first (pip install --user pipx; pipx
ensurepath; pipx install --editable ~/projects/.common/lib/yt-tools).
- Add explicit 'NOT to do' rule: do NOT recreate deleted venv if
pipx-shim exists. Empty .venv/ + present pipx-shim means PATH issue
(run pipx ensurepath + restart shell), not missing package.
Failure-modes table updated to reflect three-step probe chain and the
recreate-venv anti-pattern.
Skill no longer aborts on bare `Get-Command yt-frames` miss — binaries
installed in project-local venv or winget cache (Gyan.FFmpeg_*) are
valid install sites, just not on PATH for fresh shells.
New Step 0 in both flows: probe PATH first, then known install
locations (venv Scripts/bin, winget Gyan.FFmpeg_*/ffmpeg-*-full_build/bin);
abort only if both empty. PATH-prepend pattern documented (full-path
to yt-frames.exe is insufficient — child yt-dlp/ffmpeg need prepend
too).
Failure modes table updated: removed 'restart CC session' advice —
agent can't restart itself, and resolve-fallback makes it unnecessary.
MINOR bump per project-discipline (behaviour change in resolve logic).
Prerequisites: explicit table with two options (activate venv vs full-path).
Steps: added step 0 (venv activation) to both Flow A and Flow B.
Acceptance: agent can now invoke CLI without "command not found" error.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Closes finding [using-yt-tools-frames-multiline-stdout]: the previous
"Last line каждого CLI's stdout — absolute path артефакта" wording matched
yt-transcript / yt-watch reality but quietly misled callers about yt-frames,
which emits one ``Wrote: <abs path>`` line per extracted frame (designed
that way per ``yt_tools/frames.py`` docstring so streaming consumers don't
have to parse a trailing summary; ``tests/test_cli_smoke.py:81`` enforces
the prefix).
Chose spec-fix over code-fix: changing yt-frames to bare paths would break
the existing piping/scraping contract — bigger surface than the docs typo
this finding actually is. SKILL.md now spells out per-CLI stdout shape and
notes warnings/errors go to stderr.
PATCH (wording clarification, no behavior change).
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
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>
