skills/using-wiki-graph/SKILL.md — triggers on relational/structural wiki
questions («что связывает X и Y», path/neighbors/backlinks/orphans), routes to
mcp__wiki-graph__* instead of single-page reads (the 0%-recall failure mode).
Precondition: dense corpora only (modulair yes, sparse meta-wiki no).
hermes/mapping.yaml: registered as `pending` (intended auto/mcp, mirrors
using-vds-ops) — NOT promoted to auto; promotion gated on a
using-wiki-graph-test-trigger behavioral audit (instrument-touch).
Installed scoped via scripts/install.sh. Closes [wiki-graph-skill].
NOTE: build-hermes currently red on pre-existing unmapped skill 'meta-host-routing' (not this change).
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Don't-batch-YouTube-requests rule, filed from modulair-wiki ingest session
where ~21 rapid requests tripped HTTP 429 IP-block on both transcript-api and
yt-dlp. Captures empirical symptom + cooldown/one-at-a-time fix + en-US lang
gotcha, to land in SKILL.md as a What-NOT-to-do bullet + failure-mode row.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Second pass: filled the empty skeleton (When-to-use, Inputs, Steps, Failure
modes, Side effects, What-NOT) from the design archive
(.workshop/.archive/2026-05-29-skill-private-dev-public-publish.md). 0.1.0 -> 0.2.0.
Non-implementer subagent review found 3 findings, all fixed in this same increment:
- Step 5 dev->pub copy had no meta-exclusion -> would leak .wiki/.tasks/CLAUDE.md
into the PUBLIC fork. Added explicit meta-exclude + .gitignore backstop +
git-status check, plus a 4th failure mode for the leak.
- pub-folder origin was never established before Step 5 pushed to it -> Step 4 now
clones the GitHub fork into pub (origin=fork, upstream=canonical).
- Step 3 "same base" was unmechanized -> clone fork, add gitea remote, push base.
Closes review task: all findings filed and resolved; no follow-ups needed.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Skeleton (header + empty body) promoted from
.workshop/.brainstorm/skill-private-dev-public-publish.md. Body filled in a
second pass. No install/push/hermes — handled by baseline tasks.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
v0.2.0 wrongly said the dedicated meta-host shares the project's name. Per
meta-out-of-repo design the convention is meta-<project> (e.g.
OpeItcLoc03/meta-yt-tools), so the bare <project> name stays free for a code
mirror. Fixed resolve step, example, and bootstrap instruction.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Resolve order now prefers a dedicated same-name Gitea meta-host (e.g.
OpeItcLoc03/yt-tools) over a shared host (.common). Adds Bootstrapping a
new meta-host section incl. the git add -f gotcha (global core.excludesFile
ignores .wiki/.tasks in fresh clones). yt-tools relocated to its own host
2026-05-27.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Resolve where a project's meta lives before tasks_create/knowledge_ingest/
promotion. Github-hosted projects (or any 'not in cache' in projects-meta)
keep .tasks/.wiki in a sibling Gitea host repo (meta-out-of-repo design),
not in the github tree. Route MCP calls to the host, never guess.
Codified after an agent started writing yt-tools tasks into the github repo
instead of recalling yt-tools meta lives in .common.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
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).
Investigation finding: SRE module mismatch не воспроизводится на DESKTOP-NSEF0UK.
Three yt-dlp installs coexist:
- Python313\Scripts\yt-dlp.exe (system pip, first on PATH)
- ~\.local\bin\yt-dlp.exe (uv tool install, Python 3.14.3)
- ~\pipx\venvs\yt-tools\Scripts\yt-dlp.exe (pipx-bundled, Python 3.12.13)
All three return --version exit 0. All three interpreters import `re` cleanly.
yt-listen shims в ~/.local/bin и в pipx venv — byte-identical (SHA256 match).
Smoke-test diagnosis «uv-managed cpython-3.12 corrupt» вероятно misdiagnosis —
реальный виновник скорее всего был corrupt _sre.pyd в Python313 system install
(первый на PATH). uv с тех пор bumped 3.12 → 3.14.3, что независимо могло
залечить состояние. SKILL.md "Locating binaries" уже даёт корректный
fallback chain (PATH → ~/.local/bin → legacy venv); добавлять
\$HOME\pipx\venvs\yt-tools\Scripts приоритетным не нужно.
Closed wontfix без SKILL change.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Symmetric to install-side --prune (e871c20). Removes
dist/<name>.skill files whose <name> is not in skills/*.
Design choices match install:
- Combined flag (build + prune in one run)
- Global scan, ignores -Names / positional filter
- Default off, print-and-delete, no confirmation
Bash wrinkle: when build.sh delegates to powershell.exe -File
build.ps1 (Windows-without-zip case), --prune is NOT forwarded.
Bash runs prune itself at the end of the script against the
shared dist/. Keeps the delegation surface narrow and the prune
logic single-sourced per shell.
[skip-tdd: wrapper] — same carve-out as install-side, smoke-test
evidence: fake dist/fake-stale-{sh,ps}.skill files created in real
dist/, ran build.{sh,ps1} --prune, verified fakes removed, real
caveman.skill etc. left intact.
Wiki .wiki/concepts/install-cross-platform.md extended:
- title broadened (Install → Install / Build)
- new "Build-side --prune" section
- scope note: dist-hermes/ is separate (managed by build-hermes.py)
Closes [install-ps1-build-prune-followup].
Closes 3/3 acceptance of [install-ps1]:
- (a) install.ps1 existed
- (b) --prune flag shipped in 6cf0e98
- (c) concept page now written
.wiki/concepts/install-cross-platform.md captures:
- why two scripts (PS for native-Win, sh for Linux/Mac)
- parity contract (shared invariants, flag-naming convention)
- --prune design choices and rejected alternatives
- scope boundary (install-side only; dist/.skill prune is separate)
Index + log updated per .wiki/CLAUDE.md schema.
STATUS.md: [install-ps1] ⚪ → 🟢, new ⚪ task
[install-ps1-build-prune-followup] filed for the analogous
flag on build.{sh,ps1}.
For each <name>/ dir in $target that has no matching skills/<name>/,
remove it. Catches stale installs after skill rename/retire
(motivating case: using-synology-ops just removed but install dir
lingered until manual rm).
Design choices:
- Combined flag (install + prune in one run), not standalone mode
- Prune always scans full target — does NOT respect -Names/positional
filter, since stale-cleanup is a global concern
- Prints `pruning: <name>` per removal, no confirmation prompt
- Default off — flag must be passed explicitly
[skip-tdd: wrapper] — shell glue wrapping Remove-Item / rm -rf with
a set-difference; verified via smoke-test on disposable target dir
(fake stale dirs created, full install + prune run via env-overridden
CLAUDE_SKILLS_DIR, post-state confirmed: stale dirs removed, valid
skills installed, using-synology-ops absent as expected).
Closes 1/3 of [install-ps1] acceptance (the --prune flag). The
remaining doc .wiki/concepts/install-cross-platform.md is deferred
to a follow-up commit.
Empirical close: 1473-char description on using-vds-ops works
(7/7 smoke-test PASSED, listing shows full text, no fallback).
Memory note feedback_skill_description_length_limit.md was
paranoid — deleted from user memory (not in repo).
YAML colon-space gotcha memory kept (different concern, valid).
[using-synology-ops-disambiguation-uplift] ⚪ → 🟢
[using-synology-ops-review] ⚪ → 🟢
Reason: Synology NAS decommissioned permanently 2026-05-25.
Disambiguation between NAS and VDS for shared container names
(traefik etc.) is moot when only VDS exists. Review acceptance
criteria have no target — both the MCP endpoint and the host
fleet are gone.
Full skill retire (delete skills/using-synology-ops/, hermes
mapping entry, ~/.claude/skills/ install, MCP server registration,
dist-hermes rebuild) tracked as separate next-commit operation.
STATUS.md 1467 → 239 lines (-84%), 70 → 11 active blocks.
Archive: 21 → 57 done blocks (full snapshot, replaces prior partial).
Перемещено 36 done-блоков из STATUS.md в .archive/done-2026-05.md
(uses-yt-tools cluster, tdd-criteria rollout, bootstrap fixes,
session-handoff cluster, using-vds-ops/using-synology-ops promo,
interns-grep-audit, recommend-dont-menu, project-creation-lifecycle,
project-discipline-brainstorm-workspaces).
Один heading-emoji flip: [bootstrap-fix-tdd-recommend-template] ⚪ → 🟢
(ship-commit aac9088 2026-05-07 был авторитативным, ⚪ heading stale;
duplicate **Next action** spec block stripped at the same time).
[tasks-board-cleanup-2026-05] остаётся ⚪ в STATUS.md — по NB таски,
её закрытие идёт следующим batch'ем, не в этом же коммите.
PostToolUse hook in `~/.claude/settings.json` was using
`$env:USERPROFILE` (PowerShell syntax), but Claude Code on
Windows runs hook commands through git-bash. Bash treats `$env`
as an empty variable, leaving `":USERPROFILE\..."` as the literal
`-File` argument — PowerShell fails with "invalid filename
format" and the hook never fires.
Install snippet in hooks/README.md now uses literal absolute
path `C:\Users\<you>\.claude\...` with a "Why literal path"
section explaining why `$env:VAR` / `%VAR%` / `~` all break
through the bash-harness chain on Windows.
Retracts the v0.3.0 "live-hook e2e smoke done" closure — that
result was from synthetic replay through the PowerShell tool,
which bypassed the broken harness chain. Real e2e verification
requires this fix plus a CC restart, then a substantive commit
to observe `additionalContext` surface.
Two findings from live-hook e2e smoke 2026-05-25 on this Windows machine:
(1) README snippet was pwsh-only — PS 7 Core isn't on stock Windows. PS 5.1
(`powershell`) is always present and the hook script runs cleanly under both.
README now leads with `powershell` and notes the `pwsh` swap for PS 7+ users.
(2) Missing caveat that hooks load at Claude Code session start — mid-session
edits to ~/.claude/settings.json don't activate the hook until CC restart.
Without this note user would think the hook is broken after applying the
snippet (standalone smoke would pass but live in-session wouldn't fire).
Added explicit restart instruction + verification recipe.
Also: dist/session-handoff.skill now tracked (was missing since promotion —
inconsistent with other dist/*.skill artifacts that ship in repo).
PATCH bump 0.3.1 → 0.3.2 (docs-only, no behavioral change in hook or skill).
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
