{"id":"40423b74-c150-4a98-8de9-03718009653f","entityType":"agent","slug":"clawhub-tenequm-update-skill","name":"update-skill","canonicalUrl":"https://www.xpersona.co/agent/clawhub-tenequm-update-skill","canonicalPath":"/agent/clawhub-tenequm-update-skill","generatedAt":"2026-10-10T21:43:22.575Z","source":"CLAWHUB","claimStatus":"UNCLAIMED","verificationTier":"NONE","summary":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"medium","updatedAt":"2026-10-10T17:34:51.303Z","emptyReason":null},"description":"Thorough on-demand refresh of one skill in a skills repo - researches usage, upstream, and docs in parallel, gates twice for approval, bumps version, updates CHANGELOG, validates, commits, watches CI. Use to check a skill's freshness.","descriptionLabel":"Source description","evidenceSummary":"Capability contract not published. No trust telemetry is available yet. 1.3K downloads reported by the source. Last updated 10/10/2026.","installCommand":"clawhub skill install s17bp3v1hm1dnkzey0c9tfh02183j0y5:update-skill","sourceUrl":"https://clawhub.ai/tenequm/update-skill","homepage":"https://clawhub.ai/tenequm/skills/update-skill","primaryLinks":[{"label":"View on ClawHub","url":"https://clawhub.ai/tenequm/update-skill","kind":"source"},{"label":"Homepage","url":"https://clawhub.ai/tenequm/skills/update-skill","kind":"homepage"}],"safetyScore":84,"overallRank":62,"popularityScore":62,"trustScore":null,"claimedByName":null,"isOwner":false,"seoDescription":"update-skill technical dossier on Xpersona with agent coverage, OPENCLEW support, and live trust metadata."},"coverage":{"evidence":{"source":"public-profile","verified":false,"confidence":"medium","updatedAt":"2026-10-10T17:34:51.303Z","emptyReason":null},"protocols":[{"protocol":"OPENCLEW","label":"OpenClaw","status":"self-declared","notes":"Declared in the public agent profile."}],"capabilities":[],"verifiedCount":0,"selfDeclaredCount":1,"capabilityMatrix":{"rows":[{"key":"OPENCLEW","type":"protocol","support":"unknown","confidenceSource":"profile","notes":"Listed on profile"}],"flattenedTokens":"protocol:OPENCLEW|unknown|profile"}},"adoption":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"medium","updatedAt":"2026-10-10T17:34:51.303Z","emptyReason":null},"stars":null,"forks":null,"downloads":1315,"packageName":null,"latestVersion":"0.8.3","tractionLabel":"1.3K downloads"},"release":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"medium","updatedAt":"2026-10-10T17:34:51.287Z","emptyReason":null},"lastUpdatedAt":"2026-10-10T17:34:51.303Z","lastCrawledAt":"2026-10-10T17:34:51.287Z","lastIndexedAt":null,"nextCrawlAt":"2026-10-11T17:34:51.287Z","lastVerifiedAt":null,"highlights":[{"version":"0.8.3","createdAt":"2026-09-09T10:14:05.664Z","changelog":"Updated update-skill from 0.8.2 to 0.8.3. Changes: - modified `CHANGELOG.md` - modified `SKILL.md`","fileCount":5,"zipByteSize":16693},{"version":"0.8.2","createdAt":"2026-08-21T12:22:53.819Z","changelog":"Updated update-skill from 0.8.1 to 0.8.2. Changes: - modified `CHANGELOG.md` - modified `SKILL.md` - deleted `skill-card.md`","fileCount":5,"zipByteSize":16780},{"version":"0.8.1","createdAt":"2026-07-22T18:48:33.963Z","changelog":"Updated update-skill from 0.8.0 to 0.8.1. Changes: - modified `CHANGELOG.md` - modified `SKILL.md` - added `skill-card.md`","fileCount":5,"zipByteSize":16554},{"version":"0.8.0","createdAt":"2026-07-10T13:51:38.647Z","changelog":"Updated update-skill from 0.7.0 to 0.8.0. Changes: - modified `CHANGELOG.md` - modified `SKILL.md`","fileCount":5,"zipByteSize":16602},{"version":"0.7.0","createdAt":"2026-06-16T10:30:14.268Z","changelog":"Add Phase 0 worktree opt-in: the run asks once whether to operate in a dedicated git worktree (chore/update-), enabling parallel updates of multiple skills without README/index/diff contention. All phases operate against a new variable; the Phase 7 branch guard handles the feature-branch PR flow, and the worktree is removed after the run.","fileCount":5,"zipByteSize":13701},{"version":"0.6.0","createdAt":"2026-06-05T11:41:57.921Z","changelog":"Updated update-skill from 0.5.0 to 0.6.0. Changes: - modified `CHANGELOG.md` - modified `SKILL.md`","fileCount":5,"zipByteSize":12878},{"version":"0.5.0","createdAt":"2026-06-05T11:25:11.079Z","changelog":"Initial publish of update-skill 0.5.0. Changes: - added `CHANGELOG.md` - added `LICENSE.txt` - added `SKILL.md`","fileCount":5,"zipByteSize":12426}]},"execution":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"low","updatedAt":null,"emptyReason":"No published capability contract is available yet."},"installCommand":"clawhub skill install s17bp3v1hm1dnkzey0c9tfh02183j0y5:update-skill","setupComplexity":"low","setupSteps":["Install using `clawhub skill install s17bp3v1hm1dnkzey0c9tfh02183j0y5:update-skill` in an isolated environment before connecting it to live workloads.","No published capability contract is available yet, so validate auth and request/response behavior manually.","Review the upstream CLAWHUB listing at https://clawhub.ai/tenequm/update-skill before using production credentials."],"contract":{"contractStatus":"missing","authModes":[],"requires":[],"forbidden":[],"supportsMcp":false,"supportsA2a":false,"supportsStreaming":false,"inputSchemaRef":null,"outputSchemaRef":null,"dataRegion":null,"contractUpdatedAt":null,"sourceUpdatedAt":null,"freshnessSeconds":null},"invocationGuide":{"preferredApi":{"snapshotUrl":"https://www.xpersona.co/api/v1/agents/clawhub-tenequm-update-skill/snapshot","contractUrl":"https://www.xpersona.co/api/v1/agents/clawhub-tenequm-update-skill/contract","trustUrl":"https://www.xpersona.co/api/v1/agents/clawhub-tenequm-update-skill/trust"},"curlExamples":["curl -s \"https://www.xpersona.co/api/v1/agents/clawhub-tenequm-update-skill/snapshot\"","curl -s \"https://www.xpersona.co/api/v1/agents/clawhub-tenequm-update-skill/contract\"","curl -s \"https://www.xpersona.co/api/v1/agents/clawhub-tenequm-update-skill/trust\""],"jsonRequestTemplate":{"query":"summarize this repo","constraints":{"maxLatencyMs":2000,"protocolPreference":["OPENCLEW"]}},"jsonResponseTemplate":{"ok":true,"result":{"summary":"...","confidence":0.9},"meta":{"source":"CLAWHUB","generatedAt":"2026-10-10T21:43:22.570Z"}},"retryPolicy":{"maxAttempts":3,"backoffMs":[500,1500,3500],"retryableConditions":["HTTP_429","HTTP_503","NETWORK_TIMEOUT"]}},"endpoints":{"dossierUrl":"https://www.xpersona.co/api/v1/agents/clawhub-tenequm-update-skill/dossier","snapshotUrl":"https://www.xpersona.co/api/v1/agents/clawhub-tenequm-update-skill/snapshot","contractUrl":"https://www.xpersona.co/api/v1/agents/clawhub-tenequm-update-skill/contract","trustUrl":"https://www.xpersona.co/api/v1/agents/clawhub-tenequm-update-skill/trust"}},"reliability":{"evidence":{"source":"runtime-metrics","verified":false,"confidence":"low","updatedAt":null,"emptyReason":"No trust, reliability, or runtime telemetry is available."},"trust":{"status":"unavailable","handshakeStatus":"UNKNOWN","verificationFreshnessHours":null,"reputationScore":null,"p95LatencyMs":null,"successRate30d":null,"fallbackRate":null,"attempts30d":null,"trustUpdatedAt":null,"trustConfidence":"unknown","sourceUpdatedAt":null,"freshnessSeconds":null},"decisionGuardrails":{"doNotUseIf":["Contract metadata is missing or unavailable for deterministic execution."],"safeUseWhen":[],"riskFlags":["missing_or_unavailable_contract","trust_data_unavailable","schema_references_missing"],"operationalConfidence":"low"},"executionMetrics":{"observedLatencyMsP50":null,"observedLatencyMsP95":null,"estimatedCostUsd":null,"uptime30d":null,"rateLimitRpm":null,"rateLimitBurst":null,"lastVerifiedAt":null,"verificationSource":null},"runtimeMetrics":{"successRate":null,"avgLatencyMs":null,"avgCostUsd":null,"hallucinationRate":null,"retryRate":null,"disputeRate":null,"p50Latency":null,"p95Latency":null,"lastUpdated":null}},"benchmarks":{"evidence":{"source":"no-benchmark-data","verified":false,"confidence":"low","updatedAt":null,"emptyReason":"No benchmark suites or observed failure patterns are available."},"suites":[],"failurePatterns":[]},"artifacts":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"medium","updatedAt":"2026-10-10T17:34:51.303Z","emptyReason":null},"readme":"Skill: update-skill\n\nOwner: tenequm\n\nSummary: Thorough on-demand refresh of one skill in a skills repo - researches usage, upstream, and docs in parallel, gates twice for approval, bumps version, updates CHANGELOG, validates, commits, watches CI. Use to check a skill's freshness.\n\nTags: latest:0.8.3\n\nVersion history:\n\nv0.8.3 | 2026-09-09T10:14:05.664Z | user\n\nUpdated update-skill from 0.8.2 to 0.8.3.\nChanges:\n- modified `CHANGELOG.md`\n- modified `SKILL.md`\n\nv0.8.2 | 2026-08-21T12:22:53.819Z | user\n\nUpdated update-skill from 0.8.1 to 0.8.2.\nChanges:\n- modified `CHANGELOG.md`\n- modified `SKILL.md`\n- deleted `skill-card.md`\n\nv0.8.1 | 2026-07-22T18:48:33.963Z | user\n\nUpdated update-skill from 0.8.0 to 0.8.1.\nChanges:\n- modified `CHANGELOG.md`\n- modified `SKILL.md`\n- added `skill-card.md`\n\nv0.8.0 | 2026-07-10T13:51:38.647Z | user\n\nUpdated update-skill from 0.7.0 to 0.8.0.\nChanges:\n- modified `CHANGELOG.md`\n- modified `SKILL.md`\n\nv0.7.0 | 2026-06-16T10:30:14.268Z | user\n\nAdd Phase 0 worktree opt-in: the run asks once whether to operate in a dedicated git worktree (chore/update-), enabling parallel updates of multiple skills without README/index/diff contention. All phases operate against a new variable; the Phase 7 branch guard handles the feature-branch PR flow, and the worktree is removed after the run.\n\nv0.6.0 | 2026-06-05T11:41:57.921Z | user\n\nUpdated update-skill from 0.5.0 to 0.6.0.\nChanges:\n- modified `CHANGELOG.md`\n- modified `SKILL.md`\n\nv0.5.0 | 2026-06-05T11:25:11.079Z | user\n\nInitial publish of update-skill 0.5.0.\nChanges:\n- added `CHANGELOG.md`\n- added `LICENSE.txt`\n- added `SKILL.md`\n\nArchive index:\n\nArchive v0.8.3: 5 files, 16693 bytes\n\nFiles: CHANGELOG.md (5466b), LICENSE.txt (9157b), skill-card.md (2139b), SKILL.md (20242b), _meta.json (131b)\n\nFile v0.8.3:SKILL.md\n\n---\nname: update-skill\ndescription: Thorough on-demand refresh of one skill in a skills repo - researches usage, upstream, and docs in parallel, gates twice for approval, bumps version, updates CHANGELOG, validates, commits, watches CI. Use to check a skill's freshness.\nargument-hint: \"[skill-name]\"\ndisable-model-invocation: true\nmetadata:\n version: \"0.8.3\"\n categories: \"agents, automation\"\n topics: \"skill-maintenance, versioning, changelog, research, agent-skills\"\n openclaw:\n homepage: https://github.com/tenequm/skills/tree/main/skills/update-skill\n emoji: \"🔄\"\n upstream: \"keep-a-changelog@2.0.0\"\n---\n\n# Update Skill\n\nRun a thorough on-demand refresh of one skill in a skills repository. Two hard human-approval gates ensure no edits or commits happen without explicit confirmation.\n\nThe target skill is: $ARGUMENTS\n\nIf no argument was provided, run `ls ${CLAUDE_PROJECT_DIR}/skills/` and ask the user which to update. Stop until confirmed. Then verify `${CLAUDE_PROJECT_DIR}/skills/$ARGUMENTS/SKILL.md` exists; if not, list skills and ask again. Throughout this run, `` refers to the resolved skill name.\n\n## Operating rules\n\nThese rules apply across all phases:\n\n- **GATE 1 stops before any edit.** Do NOT call Edit or Write until the user replies affirmatively to the GATE 1 banner.\n- **GATE 2 stops before any commit or push.** Do NOT run `git commit` or `git push` until the user replies affirmatively to the GATE 2 banner.\n- **Privacy scan is a hard blocker.** Skills in a public repo can publish on merge, so the run does not reach a commit while a Phase 6 leak finding is unresolved.\n- **Sticky posture.** Once GATE 1 has been emitted, \"report findings first\" persists across follow-up rounds in the same session. If the user replies `changes` or asks for revisions, re-emit the gate after revising; never silently apply.\n- **Non-resume.** If the session is interrupted between GATE 1 and GATE 2, re-run `/update-skill ` from scratch. There is no checkpoint or resume mechanism.\n- **Duplicate triggers.** If a scheduled task or a repeated invocation fires while a run is holding at a gate, hold at the emitted gate and answer from the existing report - never redo research or re-apply edits.\n- **No `--no-verify`, no `--amend`, no force-push** unless the user explicitly authorizes it for this run. Per the repo's CLAUDE.md or AGENTS.md.\n- **Working directory.** Every path, every `just check`, and every working git command (`status`/`diff`/`add`/`commit`/`push`) in the phases below runs against `` - the worktree created in Phase 0 if the user opted in, otherwise `${CLAUDE_PROJECT_DIR}`. Use absolute paths under ``; do not mix in the main checkout once a worktree is chosen. The exception is Phase 0's own `git worktree add`/`remove`, which must run against `${CLAUDE_PROJECT_DIR}` (the main checkout).\n\n## Phase 0 - Worktree choice (ask first)\n\nAfter resolving ``, ask exactly once: \"Run this update in a dedicated git worktree, so you can update other skills in parallel? (yes / no)\". Wait for the reply.\n\n- **no** (default) -> set `` = `${CLAUDE_PROJECT_DIR}` and proceed to Phase 1 in the current checkout.\n- **yes** -> create an isolated worktree on a fresh branch and use it as `` for the entire run:\n ```bash\n git -C \"${CLAUDE_PROJECT_DIR}\" worktree add \"${CLAUDE_PROJECT_DIR}/../skills-\" -b chore/update-\n ```\n Set `` = `${CLAUDE_PROJECT_DIR}/../skills-`. If that path or branch already exists, add the same numeric suffix (`-2`, `-3`, ...) to both the worktree path and the branch name until both are free, and carry that suffix into ``. Every later phase - reads, edits, `just check`, diff review, commit, push - operates inside ``. The Phase 7 branch guard will see `chore/update-` and route to the push + PR flow automatically. Keep the worktree until the PR is **merged** - follow-up review rounds reuse it instead of recreating it. Then clean up in order: `git -C \"${CLAUDE_PROJECT_DIR}\" worktree remove \"\"` first, then delete the branch (`git branch -d chore/update-`) - a branch delete fails while a worktree still holds the branch. `git worktree remove` refuses if there are uncommitted changes (leave it in place and tell the user if so); `git worktree prune` clears stale entries left by interrupted runs. If a generated file (e.g. `README.md`) conflicts when the PR falls behind the default branch, rebase and re-run the generator - never hand-merge generated output. If the user aborts before a PR exists, remove the worktree and delete the branch the same way.\n\n## Phase 1 - Pre-flight read\n\nRead every file in `skills//` end-to-end, in parallel:\n- `skills//SKILL.md`\n- All files under `skills//references/` (use Glob first to enumerate)\n- `skills//CHANGELOG.md` (if present)\n\nCapture state for the rest of the run:\n- `metadata.version` (current)\n- `metadata.upstream` (current; parse to `{name: version}` map; empty if absent)\n- Topmost CHANGELOG entry date (if `CHANGELOG.md` exists; this is the \"last verified\" signal)\n- `git log -1 --format=%cs -- skills//` date (last touch)\n- `LICENSE.txt` (or the repo's equivalent) present and non-empty - publish pipelines and repo linters commonly hard-fail without it; if missing, queue a fix row in the Phase 3 report\n- `bootstrap_needed` flag = true if `metadata.upstream` is missing OR `CHANGELOG.md` is missing - **unless the skill is upstreamless by nature** (it wraps no package, spec, or living doc - e.g. a workflow or writing skill like `polish`). For those, omitting `metadata.upstream` is correct, not a gap: derive `bootstrap_needed` from the missing `CHANGELOG.md` alone and skip the upstream-candidate proposal.\n\n## Phase 2 - Parallel research\n\nDispatch three research subagents in a single message, one per angle. Subagents run in the background by default (Claude Code v2.1.198+): collect every agent's completion before starting Phase 3. If the user supplied a seed finding (a bug they hit, a release they know about), pass it verbatim to the relevant agent - specific leads converge fastest. **Adapt each angle to the skill**: a skill wrapping a package researches that package's releases and source; a skill tracking living docs or a spec researches those docs and their source repos; a skill with no upstream at all still gets the usage angle.\n\n- **Usage** (pond - optional): if the pond MCP (`mcp__pond__pond_search`) is available, mine it with NO `project` filter for footguns, scenario-specific breakage, inefficiencies, gaps, and recurring misunderstandings the skill could absorb. Keep the query semantic (concepts, not project names); scope with filters. These are **advisory leads, not facts** - never verified, ground-checked in Phase 3. **If pond is not installed, skip this angle entirely** - dispatch only the upstream and docs agents, and note \"Usage angle skipped: pond MCP not available (https://pond.cascade.fyi/)\" in the Phase 3 report.\n- **Upstream**: releases, commits, and merged PRs since the last-verified date. Read real source - clone to a local scratch dir (e.g. `~/pjv//`, lowercase) or use the GitHub MCP pinned to a concrete tag/SHA. For skills wrapping a CLI, also ground-truth against the live installed binary (` --help`, real invocations) - docs and clones lag shipped behavior.\n- **Docs**: the current canonical docs, read from source (raw `.md` or cloned repo), not model-summarized. Two distinct jobs, **both required**:\n - **(a) Drift check** - compare the docs against the skill's current `SKILL.md` and `references/`, flagging API changes, deprecated or removed symbols, and patterns the skill should adopt. This is anchored to what the skill already says.\n - **(b) Coverage sweep** - enumerate upstream's *current* feature/concept surface from the docs nav / table of contents, the API index, and the \"what's new\" / changelog. List every major capability, primitive, or concept the skill has **zero mention of**. Do NOT anchor this to existing skill content - the whole point is to find net-new surface the skill is silent about (`ADD` findings). This is the step a \"verify what's there\" pass structurally misses.\n\nEvery finding is one bulleted line: `[KIND]` (`ADD`/`CHANGE`/`DEPRECATE`/`REMOVE`/`FIX`/`SECURITY`), a one-line summary, an exact quote from the source (no paraphrase), and a citation. pond findings also carry `status: advisory`. Merge all returns into one list, deduped by `(KIND, citation)`.\n\n## Phase 3 - Verify, report, GATE 1\n\n### Ground-truth verification (before the report)\n\nNo row ships unverified. Before a finding becomes a row, confirm it against primary source read **today**:\n\n- Verify the finding's claim **and the existing skill text it touches** - links, enumerated lists, pinned versions, version-coupled examples. Spot-check the skill's other upstream-coupled claims even where no finding landed; silent staleness is the common miss.\n- A row asserting upstream state (a bug, API shape, version, behavior) cites the primary source checked - cloned `repo@SHA file:line`, a release, or a docs URL; a pond citation alone is insufficient, so re-ground it or drop it. A row that is purely experiential enrichment (a recurring gap or confusion) may keep its pond citation, but verify the wording you write is technically correct.\n- Drop a pond-reported bug already fixed upstream; correct any finding whose pond framing the source contradicts.\n- **Coverage-gap rows** (net-new concepts from the Phase 2(b) sweep) are verified two ways: confirm the concept exists in today's source (cite it), **and** confirm the skill genuinely omits it - grep the skill for the concept and any synonyms before claiming it's absent, so a renamed-but-present feature isn't reported as missing.\n- Scope-check every usage-derived row: a learning about private infrastructure (internal hosts, personal tooling, machine-specific setups) belongs in the user's own CLAUDE.md or memory, not a public skill. Route it there and drop the row - the Phase 6 leak scan cannot make this judgment call.\n\n### Report\n\nPrint a structured report, sections in order:\n\n1. **Tracked packages diff** - `package | pinned | latest | delta`, or \"no upstream packages tracked.\"\n2. **Proposed `metadata.upstream`** - the new flat string. No floating tags (`@latest`/`@next`/`@beta`/`@canary`); pin to a concrete tag or SHA.\n3. **Proposed CHANGELOG entry** - a Keep a Changelog block ready to commit.\n4. **Proposed edits** - one row per smallest atomic change, each with a stable ID (`A1`/`C1`/`D1`/`R1`/`F1`/`S1`...): ` | target file | one-line summary | citation`. Batch trivially-related changes into one row; past ~20 rows, consider whether the skill needs a rewrite rather than a patch. When ADD rows are numerous, include the projected post-apply `SKILL.md` line count; if it would cross the repo's size cap (500 lines in this repo), plan the `references/` split as part of the proposal, not as a surprise after apply.\n5. **New-concept coverage** (**always present, never omitted**) - the result of the Phase 2(b) coverage sweep. Either a table of net-new upstream concepts the skill omits (each becoming an `ADD` row above), or the explicit statement that there are none. End this section with the verbatim attestation below. Coverage need not be complete to pass - but any gap in what you could enumerate (JS-gated docs, rate limits, unreachable pages) must be named here, not silently dropped:\n ```\n Coverage sweep: enumerated upstream's current surface from . Net-new concepts the skill omits: / none since . Not reachable this run: .\n ```\n6. **Bootstrap proposal** (only when `bootstrap_needed`): candidate upstream packages greppable from the skill's content, each as ` (mentioned x, first cite: :)` for the user to confirm or prune; plus a seed `CHANGELOG.md`. Propose only upstreams whose releases would invalidate the skill's content - the package, spec, or living doc the skill teaches. A tool mentioned incidentally (a validator run once, a CLI in one example) is not an upstream candidate. If the skill is **upstreamless by nature**, say so explicitly, propose no candidates, and leave `metadata.upstream` omitted - only seed the `CHANGELOG.md`.\n\n### No-op short-circuit\n\nIf sections 1-4 yield zero rows AND the Phase 2(b) coverage sweep found no omitted concepts (section 5 attestation says \"none\") AND `bootstrap_needed` is false, print this verbatim and exit cleanly - no file changes, no commit. Never short-circuit without the section 5 attestation present:\n\n```\nAll current as of . Last verified per CHANGELOG.md on against .\n```\n\n### CHANGELOG format\n\n[Keep a Changelog](https://keepachangelog.com/en/2.0.0/) format. The dated entry uses only the sections it has content for (Added / Changed / Deprecated / Removed / Fixed / Security), plus a `Verified against: ` trailer **only if** a tracked package version actually changed this run. Mark breaking changes inside Changed/Removed with a leading `**Breaking:**` marker, and pin the KaC link in preambles to the version followed (both per KaC 2.0.0).\n\nWhen `bootstrap_needed`, create the full file with this header:\n\n```markdown\n# Changelog\n\nAll notable changes to this skill will be documented in this file.\n\nThe format is based on [Keep a Changelog](https://keepachangelog.com/en/2.0.0/),\nand this skill adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).\n\n## [Unreleased]\n\n## [] - \n- Initial CHANGELOG; tracking established.\n```\n\n### GATE 1 banner (verbatim)\n\n```\nGATE 1 - APPROVE TO EDIT? (yes / yes / drop / changes / no)\n```\n\nReply parsing:\n- `yes` / `yes all` -> apply every row\n- `yes A1-A4 C1` -> apply only those rows (and the listed package version updates, if any)\n- `drop D1,R2` -> apply everything except those\n- `changes ` -> revise the report and re-emit GATE 1\n- `no` -> abort, no changes\n\nDo NOT call Edit or Write until you receive an affirmative. Every revision round re-emits GATE 1; never silently apply.\n\n## Phase 4 - Apply\n\nApply each approved row with Edit/Write; batch independent edits in parallel. Then, in order:\n\n1. Update `metadata.upstream` to the new comma-separated `@` list. Reject floating tags - stop with an error if one appears. Skip entirely if the skill is upstreamless by nature - leave `metadata.upstream` omitted.\n2. Bump `metadata.version` (semver per the repo's CLAUDE.md or AGENTS.md: patch for fixes, minor for new content/sections, major for breaking removal).\n3. Append the new dated entry to `CHANGELOG.md` directly under `[Unreleased]`, above the previous entry. Add the `Verified against:` trailer only if a tracked version changed this run.\n4. If `bootstrap_needed`, write the full `CHANGELOG.md` from the bootstrap header plus the approved seed entry.\n5. When pasting upstream doc examples into a `SKILL.md` body, never let a `!` at line start or after whitespace directly touch a backticked command - Claude Code executes it at skill load, even inside code fences, and repo linters may reject it. Keep such examples in `references/` or break the adjacency.\n6. Check the post-apply `SKILL.md` line count against the repo's cap (500 here); if crossed, execute the `references/` split planned in Phase 3.\n\n## Phase 5 - Repo validation gate\n\nIf the repo defines a validation command - check its CLAUDE.md/AGENTS.md or `Justfile`/`package.json` (e.g. `just check`, `npm run lint`, `make check`) - run it from `` (the repo root, or the Phase 0 worktree). In this repo that is `just check`, which also regenerates `README.md` (the most common CI failure cause). On failure, surface the error verbatim, fix the root cause, and re-run until clean. If the failure looks unrelated to this run's edits, attribute before debugging: stash the changes (`git stash -u`) and re-run the gate on a clean tree. Failing identically means the breakage is pre-existing (an environment flake or repo issue) - unstash, report it to the user, and don't sink this run into debugging it. No `--no-verify`, no `--amend`, no hook-skipping. If the repo has no validation gate, skip this phase and note it.\n\n## Phase 6 - Privacy scan + diff review + GATE 2\n\n### Privacy / leak scan (hard blocker)\n\nSkills in a public repo can publish on merge, and any research source can leak into the diff - especially pond, which draws on private cross-project conversations. This scan runs every time, whether or not pond was used. Before showing the diff, dispatch a dedicated agent (separate from the Phase 2 research agents) to scan the added/changed lines **and every new untracked file** under `skills//` and `README.md` (if the repo generates one). `git diff` alone misses brand-new files (e.g. a fresh `references/` doc) - enumerate them with `git status --porcelain` and give the agent their full content.\n\nIt flags anything unsafe for a public skill: secrets (keys, tokens, passwords, `.env` values, connection strings), personal data (real names, emails, handles), and the easy-to-miss ones - non-public project or repo names, internal hostnames or endpoints, ticket IDs, local machine paths, pond session IDs. Intentional public references are fine (the public repo owner, official upstream repos and docs, published package names, spec URLs). The agent returns `[LEAK] : - - suggested redaction: ` per issue, or exactly `NO LEAKS FOUND`.\n\nAn unresolved `[LEAK]` is a hard blocker: redact each finding, re-run the scan, and repeat until clean before GATE 2. Hold the commit message to the same public-safe standard.\n\n### Diff review\n\nPrint `git status`, `git diff --stat`, and per-file diffs for `SKILL.md`, every changed `references/` file, `CHANGELOG.md`, and `README.md`. Then print this recovery hint verbatim, immediately above the gate banner:\n\n```\nTo discard everything: git restore . && git clean -fd skills//\n```\n\n```\nGATE 2 - APPROVE COMMIT + PUSH? (yes / no)\n```\n\nWait for explicit confirmation. Do not commit on ambiguous responses.\n\n## Phase 7 - Commit, push, watch\n\n**Branch guard first.** Run `git rev-parse --abbrev-ref HEAD`. If the result is not the repo's default branch, ask the user: push to the current branch and open a PR (recommended), push directly to the default branch (only on explicit instruction - if the repo auto-publishes on merge, this skips PR review and ships straight to the registry), or cancel.\n\nCommit with a conventional-commit message (type per content, per the repo's CLAUDE.md or AGENTS.md) using the HEREDOC pattern:\n\n```bash\ngit commit -m \"$(cat <<'EOF'\n(): \n\n\nEOF\n)\"\n```\n\n- **On the default branch**: `git push`, then, if the repo has CI, `gh run watch` the triggered run. On CI failure, surface logs verbatim; do not auto-retry.\n- **On a feature branch**: `git push -u origin `, then `gh pr create` with a body summarizing the Phase 3 report. Skip `gh run watch` at this point - PR CI is typically non-publishing, and some publish-on-merge repos run no PR CI at all. The run is not done at PR creation: once the PR merges, watch the default-branch publish run (`gh run watch`), confirm the publish landed, then do the Phase 0 cleanup (worktree first, then branch).\n\nUpdating several skills in one session? Land them together: batch into one push, or merge the PRs back-to-back and watch only the final publish run - each push to the default branch typically triggers a full republish.\n\nIf the repo auto-publishes on merge (e.g. to a registry via CI), confirm the publish landed once CI is green. The published slug and release/tag naming follow the repo's own pipeline - check its CLAUDE.md/AGENTS.md (the published slug can differ from the folder name).\n\n## Done\n\nReport a one-line summary to the user: skill name, version delta, tracked packages updated, CI status. If the repo's skills are consumed through an installer (e.g. `npx skills`), remind the user to refresh installed copies (`npx skills update `) once the publish lands.\n\nFile v0.8.3:_meta.json\n\n{\n \"ownerId\": \"kn76gpsgjw5chv0xvzbzcb8cxn81x46r\",\n \"slug\": \"update-skill\",\n \"version\": \"0.8.3\",\n \"publishedAt\": 1788948845664\n}\n\nFile v0.8.3:CHANGELOG.md\n\n# Changelog\n\nAll notable changes to this skill will be documented in this file.\n\nThe format is based on [Keep a Changelog](https://keepachangelog.com/en/2.0.0/),\nand this skill adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).\n\n## [Unreleased]\n\n## [0.8.3] - 2026-09-09\n\n### Changed\n- Description condensed to fit the repo's 250-character limit.\n\n## [0.8.2] - 2026-08-21\n\n### Changed\n\n- Declared ClawHub browse categories (`agents, automation`) and topics in `metadata`, so the release pipeline publishes them instead of leaving the skill in the `other` category.\n\n### Removed\n\n- `skill-card.md`. The ClawHub CLI strips a root `skill-card.md` from every publish and the registry generates its own card, so the authored file never reached ClawHub.\n\n## [0.8.1] - 2026-07-22\n\n### Added\n\n- skill-card.md release record following NVIDIA's skill-card format\n- metadata.openclaw block (emoji, homepage) for ClawHub display\n\n## [0.8.0] - 2026-07-10\n\n### Added\n- Worktree lifecycle hardening from real runs: keep the worktree until the PR merges (follow-up rounds reuse it), remove the worktree before deleting its branch, `git worktree prune` for stale entries, and regenerate (never hand-merge) generated-file conflicts like README.md on rebase.\n- Phase 3 line-budget planning: report the projected SKILL.md size when additive rows land and plan a references/ split when it would exceed the repo's cap.\n- Phase 5 failure-attribution step: when the validation gate fails in a way unrelated to the edits, stash and re-run on a clean tree before debugging.\n- Phase 3 public-vs-private scope call on usage-derived findings: private-infra learnings go to user memory/CLAUDE.md, never the public skill.\n- Phase 2 research inputs: ground-truth CLI-wrapping skills against the live installed CLI, and accept user-supplied seed findings as explicit leads.\n- Operating rule for duplicate/scheduled triggers firing mid-run: hold at the emitted gate, never redo research.\n- Phase 4 authoring caution: never let a `!` at line start or after whitespace directly touch a backticked command in SKILL.md bodies (Claude Code executes it at load, even in code fences).\n- Phase 1 pre-flight now verifies LICENSE.txt presence; Done phase reminds to propagate published updates to installed copies; Phase 7 batches multi-skill updates into one push when CI republishes per push.\n- `metadata.upstream` now tracks `keep-a-changelog@2.0.0` - the spec the skill embeds a template of, whose releases invalidate content (proven this run).\n\n### Changed\n- Keep a Changelog citations and the bootstrap header template moved from 1.1.0 to 2.0.0 (six change types and dates unchanged; adds the `**Breaking:**` marker convention and version-pinned format links).\n- Phase 2 notes subagents run in the background by default (Claude Code v2.1.198+): collect all completions before Phase 3.\n- Phase 7 feature-branch flow now follows through merge: watch the default-branch publish CI after the PR merges (some repos have no PR CI at all), then clean up branch and worktree.\n\n### Fixed\n- Bootstrap upstream proposal no longer promotes incidentally-mentioned tools: candidates must be things whose releases would invalidate the skill's content.\n- Phase 6 leak scan explicitly covers untracked new files, which `git diff` misses.\n\nVerified against: keep-a-changelog@2.0.0\n\n## [0.7.0] - 2026-06-16\n\n### Added\n- Phase 0 worktree choice: the run now asks once whether to operate in a dedicated git worktree (`git worktree add ... -b chore/update-`), enabling parallel updates of multiple skills without README/index/diff contention. All phases operate against a new `` variable (the worktree if chosen, else `${CLAUDE_PROJECT_DIR}`); the existing Phase 7 branch guard handles the resulting feature-branch PR flow, and the worktree is removed after the run.\n\n## [0.6.0] - 2026-06-05\n\n### Added\n- Restored the `argument-hint: \"[skill-name]\"` frontmatter field removed in 0.5.0. It is a valid, functional Claude Code field for user-invoked skills (used in Anthropic's own `skills//SKILL.md` examples) and is documented in this repo's `skills-best-practices`; it is simply outside the open Agent Skills spec, which ignores unknown fields.\n\n### Fixed\n- Aligned the repo linter (`scripts/check_skills.py`) with the optional Claude Code skill/command fields documented in `skills-best-practices` (`argument-hint`, `when_to_use`, `arguments`, `model`, `effort`, `context`, `agent`, `hooks`). The previous allowlist rejected fields the repo's own guidance endorses.\n\n## [0.5.0] - 2026-06-05\n\n### Added\n- Apache-2.0 `LICENSE.txt` (required for publishing).\n- Upstreamless-by-nature escape hatch: skills that wrap no package/spec/doc (workflow or writing skills) cleanly omit `metadata.upstream` and skip the bootstrap upstream-candidate proposal instead of being nagged.\n\n### Changed\n- Generalized for use in any skills repository. The pond usage angle is now optional with an explicit skip-and-fallback when the pond MCP is absent (https://pond.cascade.fyi/). Phase 5 reframed as a repo-agnostic validation gate, and Phase 7 defers publish/slug/release-tag specifics to the repo's own pipeline (CLAUDE.md/AGENTS.md) instead of hardcoding this repo's ClawHub scripts and release-tag naming.\n\n### Removed\n- `argument-hint` frontmatter field to pass the repo's lint allowlist (restored in 0.6.0 once the allowlist was corrected; the body already handles the no-argument case regardless).\n\nFile v0.8.3:skill-card.md\n\n## Description:\n\nThorough on-demand refresh of one skill in a skills repo - researches usage, upstream, and docs in parallel, gates twice for approval, bumps version, updates CHANGELOG, validates, commits, watches CI. Use to check a skill's freshness.\n\nThis skill is ready for commercial/non-commercial use.\n\n## Publisher:\n\n[tenequm](https://clawhub.ai/user/tenequm)\n\n### License/Terms of Use:\n\nMIT-0\n\n## Use Case:\n\nDevelopers and maintainers use this skill to refresh a selected skill in a skills repository, review proposed updates, apply approved changes, update release notes, validate the repository, and prepare publication after explicit approval.\n\n### Deployment Geography for Use:\n\nGlobal\n\n## Known Risks and Mitigations:\n\nRisk: The skill gives an agent broad authority to edit, validate, commit, push, and potentially publish changes after approval prompts.\n\nMitigation: Install only in trusted skill repositories, use trusted skill names, and review proposed edits and diffs before approving GATE 1 or GATE 2.\n\nRisk: The skill can query cross-project conversation data through Pond without a project boundary.\n\nMitigation: Avoid or disable Pond research unless that search is explicitly intended, and keep public-scope and leak-scan review active before publication.\n\n## Reference(s):\n\n- [ClawHub skill page](https://clawhub.ai/tenequm/skills/update-skill)\n- [Project homepage](https://github.com/tenequm/skills/tree/main/skills/update-skill)\n\n## Skill Output:\n\n**Output Type(s):** [text, markdown, code, shell commands, configuration, guidance]\n\n**Output Format:** [Markdown reports, repository file edits, and shell command sequences]\n\n**Output Parameters:** [1D]\n\n**Other Properties Related to Output:** [Requires explicit human approval before edits and before commit or push.]\n\n## Skill Version(s):\n\n0.8.3 (source: frontmatter and server release evidence)\n\n## Ethical Considerations:\n\nUsers should evaluate whether this skill is appropriate for their environment, review any generated or modified files before relying on them, and apply their organization's safety, security, and compliance requirements before deployment.\n\nFile v0.8.3:LICENSE.txt\n\nApache License\nVersion 2.0, January 2004\nhttps://www.apache.org/licenses/\n\nTERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION\n\n1. Definitions.\n\n\"License\" shall mean the terms and conditions for use, reproduction, and\ndistribution as defined by Sections 1 through 9 of this document.\n\n\"Licensor\" shall mean the copyright owner or entity authorized by the\ncopyright owner that is granting the License.\n\n\"Legal Entity\" shall mean the union of the acting entity and all other\nentities that control, are controlled by, or are under common control with\nthat entity. For the purposes of this definition, \"control\" means (i) the\npower, direct or indirect, to cause the direction or management of such\nentity, whether by contract or otherwise, or (ii) ownership of fifty percent\n(50%) or more of the outstanding shares, or (iii) beneficial ownership of\nsuch entity.\n\n\"You\" (or \"Your\") shall mean an individual or Legal Entity exercising\npermissions granted by this License.\n\n\"Source\" form shall mean the preferred form for making modifications,\nincluding but not limited to software source code, documentation source, and\nconfiguration files.\n\n\"Object\" form shall mean any form resulting from mechanical transformation or\ntranslation of a Source form, including but not limited to compiled object\ncode, generated documentation, and conversions to other media types.\n\n\"Work\" shall mean the work of authorship, whether in Source or Object form,\nmade available under the License, as indicated by a copyright notice that is\nincluded in or attached to the work (an example is provided in the Appendix\nbelow).\n\n\"Derivative Works\" shall mean any work, whether in Source or Object form,\nthat is based on (or derived from) the Work and for which the editorial\nrevisions, annotations, elaborations, or other modifications represent, as a\nwhole, an original work of authorship. For the purposes of this License,\nDerivative Works shall not include works that remain separable from, or\nmerely link (or bind by name) to the interfaces of, the Work and Derivative\nWorks thereof.\n\n\"Contribution\" shall mean any work of authorship, including the original\nversion of the Work and any modifications or additions to that Work or\nDerivative Works thereof, that is intentionally submitted to Licensor for\ninclusion in the Work by the copyright owner or by an individual or Legal\nEntity authorized to submit on behalf of the copyright owner. For the\npurposes of this definition, \"submitted\" means any form of electronic, verbal,\nor written communication sent to the Licensor or its representatives,\nincluding but not limited to communication on electronic mailing lists, source\ncode control systems, and issue tracking systems that are managed by, or on\nbehalf of, the Licensor for the purpose of discussing and improving the Work,\nbut excluding communication that is conspicuously marked or otherwise\ndesignated in writing by the copyright owner as \"Not a Contribution.\"\n\n\"Contributor\" shall mean Licensor and any individual or Legal Entity on\nbehalf of whom a Contribution has been received by Licensor and subsequently\nincorporated within the Work.\n\n2. Grant of Copyright License. Subject to the terms and conditions of this\nLicense, each Contributor hereby grants to You a perpetual, worldwide,\nnon-exclusive, no-charge, royalty-free, irrevocable copyright license to\nreproduce, prepare Derivative Works of, publicly display, publicly perform,\nsublicense, and distribute the Work and such Derivative Works in Source or\nObject form.\n\n3. Grant of Patent License. Subject to the terms and conditions of this\nLicense, each Contributor hereby grants to You a perpetual, worldwide,\nnon-exclusive, no-charge, royalty-free, irrevocable (except as stated in this\nsection) patent license to make, have made, use, offer to sell, sell, import,\nand otherwise transfer the Work, where such license applies only to those\npatent claims licensable by such Contributor that are necessarily infringed by\ntheir Contribution(s) alone or by combination of their Contribution(s) with\nthe Work to which such Contribution(s) was submitted. If You institute patent\nlitigation against any entity (including a cross-claim or counterclaim in a\nlawsuit) alleging that the Work or a Contribution incorporated within the Work\nconstitutes direct or contributory patent infringement, then any patent\nlicenses granted to You under this License for that Work shall terminate as of\nthe date such litigation is filed.\n\n4. Redistribution. You may reproduce and distribute copies of the Work or\nDerivative Works thereof in any medium, with or without modifications, and in\nSource or Object form, provided that You meet the following conditions:\n\n(a) You must give any other recipients of the Work or Derivative Works a copy\nof this License; and\n\n(b) You must cause any modified files to carry prominent notices stating that\nYou changed the files; and\n\n(c) You must retain, in the Source form of any Derivative Works that You\ndistribute, all copyright, patent, trademark, and attribution notices from\nthe Source form of the Work, excluding those notices that do not pertain to\nany part of the Derivative Works; and\n\n(d) If the Work includes a \"NOTICE\" text file as part of its distribution,\nthen any Derivative Works that You distribute must include a readable copy of\nthe attribution notices contained within such NOTICE file, excluding those\nnotices that do not pertain to any part of the Derivative Works, in at least\none of the following places: within a NOTICE text file distributed as part of\nthe Derivative Works; within the Source form or documentation, if provided\nalong with the Derivative Works; or, within a display generated by the\nDerivative Works, if and wherever such third-party notices normally appear.\nThe contents of the NOTICE file are for informational purposes only and do not\nmodify the License. You may add Your own attribution notices within Derivative\nWorks that You distribute, alongside or as an addendum to the NOTICE text from\nthe Work, provided that such additional attribution notices cannot be\nconstrued as modifying the License.\n\nYou may add Your own copyright statement to Your modifications and may provide\nadditional or different license terms and conditions for use, reproduction, or\ndistribution of Your modifications, or for any such Derivative Works as a\nwhole, provided Your use, reproduction, and distribution of the Work otherwise\ncomplies with the conditions stated in this License.\n\n5. Submission of Contributions. Unless You explicitly state otherwise, any\nContribution intentionally submitted for inclusion in the Work by You to the\nLicensor shall be under the terms and conditions of this License, without any\nadditional terms or conditions. Notwithstanding the above, nothing herein\nshall supersede or modify the terms of any separate license agreement you may\nhave executed with Licensor regarding such Contributions.\n\n6. Trademarks. This License does not grant permission to use the trade names,\ntrademarks, service marks, or product names of the Licensor, except as\nrequired for reasonable and customary use in describing the origin of the Work\nand reproducing the content of the NOTICE file.\n\n7. Disclaimer of Warranty. Unless required by applicable law or agreed to in\nwriting, Licensor provides the Work (and each Contributor provides its\nContributions) on an \"AS IS\" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY\nKIND, either express or implied, including, without limitation, any warranties\nor conditions of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A\nPARTICULAR PURPOSE. You are solely responsible for determining the\nappropriateness of using or redistributing the Work and assume any risks\nassociated with Your exercise of permissions under this License.\n\n8. Limitation of Liability. In no event and under no legal theory, whether in\ntort (including negligence), contract, or otherwise, unless required by\napplicable law (such as deliberate and grossly negligent acts) or agreed to in\nwriting, shall any Contributor be liable to You for damages, including any\ndirect, indirect, special, incidental, or consequential damages of any\ncharacter arising as a result of this License or out of the use or inability to\nuse the Work (including but not limited to damages for loss of goodwill, work\nstoppage, computer failure or malfunction, or any and all other commercial\ndamages or losses), even if such Contributor has been advised of the\npossibility of such damages.\n\n9. Accepting Warranty or Additional Liability. While redistributing the Work\nor Derivative Works thereof, You may choose to offer, and charge a fee for,\nacceptance of support, warranty, indemnity, or other liability obligations\nand/or rights consistent with this License. However, in accepting such\nobligations, You may act only on Your own behalf and on Your sole\nresponsibility, not on behalf of any other Contributor, and only if You agree\nto indemnify, defend, and hold each Contributor harmless for any liability\nincurred by, or claims asserted against, such Contributor by reason of your\naccepting any such warranty or additional liability.\n\nEND OF TERMS AND CONDITIONS\n\nArchive v0.8.2: 5 files, 16780 bytes\n\nFiles: CHANGELOG.md (5365b), LICENSE.txt (9157b), skill-card.md (2415b), SKILL.md (20420b), _meta.json (131b)\n\nFile v0.8.2:SKILL.md\n\n---\nname: update-skill\ndescription: \"Thorough on-demand refresh of one skill in a skills repository: researches usage/upstream/docs in parallel, gates twice for approval, bumps version, updates CHANGELOG, runs the repo's validation, then commits and watches CI. Install the pond MCP (https://pond.cascade.fyi/) for the prior-session usage angle; without it that angle is skipped. Use to update, refresh, or check the freshness of a specific skill.\"\nargument-hint: \"[skill-name]\"\ndisable-model-invocation: true\nmetadata:\n version: \"0.8.2\"\n categories: \"agents, automation\"\n topics: \"skill-maintenance, versioning, changelog, research, agent-skills\"\n openclaw:\n homepage: https://github.com/tenequm/skills/tree/main/skills/update-skill\n emoji: \"🔄\"\n upstream: \"keep-a-changelog@2.0.0\"\n---\n\n# Update Skill\n\nRun a thorough on-demand refresh of one skill in a skills repository. Two hard human-approval gates ensure no edits or commits happen without explicit confirmation.\n\nThe target skill is: $ARGUMENTS\n\nIf no argument was provided, run `ls ${CLAUDE_PROJECT_DIR}/skills/` and ask the user which to update. Stop until confirmed. Then verify `${CLAUDE_PROJECT_DIR}/skills/$ARGUMENTS/SKILL.md` exists; if not, list skills and ask again. Throughout this run, `` refers to the resolved skill name.\n\n## Operating rules\n\nThese rules apply across all phases:\n\n- **GATE 1 stops before any edit.** Do NOT call Edit or Write until the user replies affirmatively to the GATE 1 banner.\n- **GATE 2 stops before any commit or push.** Do NOT run `git commit` or `git push` until the user replies affirmatively to the GATE 2 banner.\n- **Privacy scan is a hard blocker.** Skills in a public repo can publish on merge, so the run does not reach a commit while a Phase 6 leak finding is unresolved.\n- **Sticky posture.** Once GATE 1 has been emitted, \"report findings first\" persists across follow-up rounds in the same session. If the user replies `changes` or asks for revisions, re-emit the gate after revising; never silently apply.\n- **Non-resume.** If the session is interrupted between GATE 1 and GATE 2, re-run `/update-skill ` from scratch. There is no checkpoint or resume mechanism.\n- **Duplicate triggers.** If a scheduled task or a repeated invocation fires while a run is holding at a gate, hold at the emitted gate and answer from the existing report - never redo research or re-apply edits.\n- **No `--no-verify`, no `--amend`, no force-push** unless the user explicitly authorizes it for this run. Per the repo's CLAUDE.md or AGENTS.md.\n- **Working directory.** Every path, every `just check`, and every working git command (`status`/`diff`/`add`/`commit`/`push`) in the phases below runs against `` - the worktree created in Phase 0 if the user opted in, otherwise `${CLAUDE_PROJECT_DIR}`. Use absolute paths under ``; do not mix in the main checkout once a worktree is chosen. The exception is Phase 0's own `git worktree add`/`remove`, which must run against `${CLAUDE_PROJECT_DIR}` (the main checkout).\n\n## Phase 0 - Worktree choice (ask first)\n\nAfter resolving ``, ask exactly once: \"Run this update in a dedicated git worktree, so you can update other skills in parallel? (yes / no)\". Wait for the reply.\n\n- **no** (default) -> set `` = `${CLAUDE_PROJECT_DIR}` and proceed to Phase 1 in the current checkout.\n- **yes** -> create an isolated worktree on a fresh branch and use it as `` for the entire run:\n ```bash\n git -C \"${CLAUDE_PROJECT_DIR}\" worktree add \"${CLAUDE_PROJECT_DIR}/../skills-\" -b chore/update-\n ```\n Set `` = `${CLAUDE_PROJECT_DIR}/../skills-`. If that path or branch already exists, add the same numeric suffix (`-2`, `-3`, ...) to both the worktree path and the branch name until both are free, and carry that suffix into ``. Every later phase - reads, edits, `just check`, diff review, commit, push - operates inside ``. The Phase 7 branch guard will see `chore/update-` and route to the push + PR flow automatically. Keep the worktree until the PR is **merged** - follow-up review rounds reuse it instead of recreating it. Then clean up in order: `git -C \"${CLAUDE_PROJECT_DIR}\" worktree remove \"\"` first, then delete the branch (`git branch -d chore/update-`) - a branch delete fails while a worktree still holds the branch. `git worktree remove` refuses if there are uncommitted changes (leave it in place and tell the user if so); `git worktree prune` clears stale entries left by interrupted runs. If a generated file (e.g. `README.md`) conflicts when the PR falls behind the default branch, rebase and re-run the generator - never hand-merge generated output. If the user aborts before a PR exists, remove the worktree and delete the branch the same way.\n\n## Phase 1 - Pre-flight read\n\nRead every file in `skills//` end-to-end, in parallel:\n- `skills//SKILL.md`\n- All files under `skills//references/` (use Glob first to enumerate)\n- `skills//CHANGELOG.md` (if present)\n\nCapture state for the rest of the run:\n- `metadata.version` (current)\n- `metadata.upstream` (current; parse to `{name: version}` map; empty if absent)\n- Topmost CHANGELOG entry date (if `CHANGELOG.md` exists; this is the \"last verified\" signal)\n- `git log -1 --format=%cs -- skills//` date (last touch)\n- `LICENSE.txt` (or the repo's equivalent) present and non-empty - publish pipelines and repo linters commonly hard-fail without it; if missing, queue a fix row in the Phase 3 report\n- `bootstrap_needed` flag = true if `metadata.upstream` is missing OR `CHANGELOG.md` is missing - **unless the skill is upstreamless by nature** (it wraps no package, spec, or living doc - e.g. a workflow or writing skill like `polish`). For those, omitting `metadata.upstream` is correct, not a gap: derive `bootstrap_needed` from the missing `CHANGELOG.md` alone and skip the upstream-candidate proposal.\n\n## Phase 2 - Parallel research\n\nDispatch three research subagents in a single message, one per angle. Subagents run in the background by default (Claude Code v2.1.198+): collect every agent's completion before starting Phase 3. If the user supplied a seed finding (a bug they hit, a release they know about), pass it verbatim to the relevant agent - specific leads converge fastest. **Adapt each angle to the skill**: a skill wrapping a package researches that package's releases and source; a skill tracking living docs or a spec researches those docs and their source repos; a skill with no upstream at all still gets the usage angle.\n\n- **Usage** (pond - optional): if the pond MCP (`mcp__pond__pond_search`) is available, mine it with NO `project` filter for footguns, scenario-specific breakage, inefficiencies, gaps, and recurring misunderstandings the skill could absorb. Keep the query semantic (concepts, not project names); scope with filters. These are **advisory leads, not facts** - never verified, ground-checked in Phase 3. **If pond is not installed, skip this angle entirely** - dispatch only the upstream and docs agents, and note \"Usage angle skipped: pond MCP not available (https://pond.cascade.fyi/)\" in the Phase 3 report.\n- **Upstream**: releases, commits, and merged PRs since the last-verified date. Read real source - clone to a local scratch dir (e.g. `~/pjv//`, lowercase) or use the GitHub MCP pinned to a concrete tag/SHA. For skills wrapping a CLI, also ground-truth against the live installed binary (` --help`, real invocations) - docs and clones lag shipped behavior.\n- **Docs**: the current canonical docs, read from source (raw `.md` or cloned repo), not model-summarized. Two distinct jobs, **both required**:\n - **(a) Drift check** - compare the docs against the skill's current `SKILL.md` and `references/`, flagging API changes, deprecated or removed symbols, and patterns the skill should adopt. This is anchored to what the skill already says.\n - **(b) Coverage sweep** - enumerate upstream's *current* feature/concept surface from the docs nav / table of contents, the API index, and the \"what's new\" / changelog. List every major capability, primitive, or concept the skill has **zero mention of**. Do NOT anchor this to existing skill content - the whole point is to find net-new surface the skill is silent about (`ADD` findings). This is the step a \"verify what's there\" pass structurally misses.\n\nEvery finding is one bulleted line: `[KIND]` (`ADD`/`CHANGE`/`DEPRECATE`/`REMOVE`/`FIX`/`SECURITY`), a one-line summary, an exact quote from the source (no paraphrase), and a citation. pond findings also carry `status: advisory`. Merge all returns into one list, deduped by `(KIND, citation)`.\n\n## Phase 3 - Verify, report, GATE 1\n\n### Ground-truth verification (before the report)\n\nNo row ships unverified. Before a finding becomes a row, confirm it against primary source read **today**:\n\n- Verify the finding's claim **and the existing skill text it touches** - links, enumerated lists, pinned versions, version-coupled examples. Spot-check the skill's other upstream-coupled claims even where no finding landed; silent staleness is the common miss.\n- A row asserting upstream state (a bug, API shape, version, behavior) cites the primary source checked - cloned `repo@SHA file:line`, a release, or a docs URL; a pond citation alone is insufficient, so re-ground it or drop it. A row that is purely experiential enrichment (a recurring gap or confusion) may keep its pond citation, but verify the wording you write is technically correct.\n- Drop a pond-reported bug already fixed upstream; correct any finding whose pond framing the source contradicts.\n- **Coverage-gap rows** (net-new concepts from the Phase 2(b) sweep) are verified two ways: confirm the concept exists in today's source (cite it), **and** confirm the skill genuinely omits it - grep the skill for the concept and any synonyms before claiming it's absent, so a renamed-but-present feature isn't reported as missing.\n- Scope-check every usage-derived row: a learning about private infrastructure (internal hosts, personal tooling, machine-specific setups) belongs in the user's own CLAUDE.md or memory, not a public skill. Route it there and drop the row - the Phase 6 leak scan cannot make this judgment call.\n\n### Report\n\nPrint a structured report, sections in order:\n\n1. **Tracked packages diff** - `package | pinned | latest | delta`, or \"no upstream packages tracked.\"\n2. **Proposed `metadata.upstream`** - the new flat string. No floating tags (`@latest`/`@next`/`@beta`/`@canary`); pin to a concrete tag or SHA.\n3. **Proposed CHANGELOG entry** - a Keep a Changelog block ready to commit.\n4. **Proposed edits** - one row per smallest atomic change, each with a stable ID (`A1`/`C1`/`D1`/`R1`/`F1`/`S1`...): ` | target file | one-line summary | citation`. Batch trivially-related changes into one row; past ~20 rows, consider whether the skill needs a rewrite rather than a patch. When ADD rows are numerous, include the projected post-apply `SKILL.md` line count; if it would cross the repo's size cap (500 lines in this repo), plan the `references/` split as part of the proposal, not as a surprise after apply.\n5. **New-concept coverage** (**always present, never omitted**) - the result of the Phase 2(b) coverage sweep. Either a table of net-new upstream concepts the skill omits (each becoming an `ADD` row above), or the explicit statement that there are none. End this section with the verbatim attestation below. Coverage need not be complete to pass - but any gap in what you could enumerate (JS-gated docs, rate limits, unreachable pages) must be named here, not silently dropped:\n ```\n Coverage sweep: enumerated upstream's current surface from . Net-new concepts the skill omits: / none since . Not reachable this run: .\n ```\n6. **Bootstrap proposal** (only when `bootstrap_needed`): candidate upstream packages greppable from the skill's content, each as ` (mentioned x, first cite: :)` for the user to confirm or prune; plus a seed `CHANGELOG.md`. Propose only upstreams whose releases would invalidate the skill's content - the package, spec, or living doc the skill teaches. A tool mentioned incidentally (a validator run once, a CLI in one example) is not an upstream candidate. If the skill is **upstreamless by nature**, say so explicitly, propose no candidates, and leave `metadata.upstream` omitted - only seed the `CHANGELOG.md`.\n\n### No-op short-circuit\n\nIf sections 1-4 yield zero rows AND the Phase 2(b) coverage sweep found no omitted concepts (section 5 attestation says \"none\") AND `bootstrap_needed` is false, print this verbatim and exit cleanly - no file changes, no commit. Never short-circuit without the section 5 attestation present:\n\n```\nAll current as of . Last verified per CHANGELOG.md on against .\n```\n\n### CHANGELOG format\n\n[Keep a Changelog](https://keepachangelog.com/en/2.0.0/) format. The dated entry uses only the sections it has content for (Added / Changed / Deprecated / Removed / Fixed / Security), plus a `Verified against: ` trailer **only if** a tracked package version actually changed this run. Mark breaking changes inside Changed/Removed with a leading `**Breaking:**` marker, and pin the KaC link in preambles to the version followed (both per KaC 2.0.0).\n\nWhen `bootstrap_needed`, create the full file with this header:\n\n```markdown\n# Changelog\n\nAll notable changes to this skill will be documented in this file.\n\nThe format is based on [Keep a Changelog](https://keepachangelog.com/en/2.0.0/),\nand this skill adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).\n\n## [Unreleased]\n\n## [] - \n- Initial CHANGELOG; tracking established.\n```\n\n### GATE 1 banner (verbatim)\n\n```\nGATE 1 - APPROVE TO EDIT? (yes / yes / drop / changes / no)\n```\n\nReply parsing:\n- `yes` / `yes all` -> apply every row\n- `yes A1-A4 C1` -> apply only those rows (and the listed package version updates, if any)\n- `drop D1,R2` -> apply everything except those\n- `changes ` -> revise the report and re-emit GATE 1\n- `no` -> abort, no changes\n\nDo NOT call Edit or Write until you receive an affirmative. Every revision round re-emits GATE 1; never silently apply.\n\n## Phase 4 - Apply\n\nApply each approved row with Edit/Write; batch independent edits in parallel. Then, in order:\n\n1. Update `metadata.upstream` to the new comma-separated `@` list. Reject floating tags - stop with an error if one appears. Skip entirely if the skill is upstreamless by nature - leave `metadata.upstream` omitted.\n2. Bump `metadata.version` (semver per the repo's CLAUDE.md or AGENTS.md: patch for fixes, minor for new content/sections, major for breaking removal).\n3. Append the new dated entry to `CHANGELOG.md` directly under `[Unreleased]`, above the previous entry. Add the `Verified against:` trailer only if a tracked version changed this run.\n4. If `bootstrap_needed`, write the full `CHANGELOG.md` from the bootstrap header plus the approved seed entry.\n5. When pasting upstream doc examples into a `SKILL.md` body, never let a `!` at line start or after whitespace directly touch a backticked command - Claude Code executes it at skill load, even inside code fences, and repo linters may reject it. Keep such examples in `references/` or break the adjacency.\n6. Check the post-apply `SKILL.md` line count against the repo's cap (500 here); if crossed, execute the `references/` split planned in Phase 3.\n\n## Phase 5 - Repo validation gate\n\nIf the repo defines a validation command - check its CLAUDE.md/AGENTS.md or `Justfile`/`package.json` (e.g. `just check`, `npm run lint`, `make check`) - run it from `` (the repo root, or the Phase 0 worktree). In this repo that is `just check`, which also regenerates `README.md` (the most common CI failure cause). On failure, surface the error verbatim, fix the root cause, and re-run until clean. If the failure looks unrelated to this run's edits, attribute before debugging: stash the changes (`git stash -u`) and re-run the gate on a clean tree. Failing identically means the breakage is pre-existing (an environment flake or repo issue) - unstash, report it to the user, and don't sink this run into debugging it. No `--no-verify`, no `--amend`, no hook-skipping. If the repo has no validation gate, skip this phase and note it.\n\n## Phase 6 - Privacy scan + diff review + GATE 2\n\n### Privacy / leak scan (hard blocker)\n\nSkills in a public repo can publish on merge, and any research source can leak into the diff - especially pond, which draws on private cross-project conversations. This scan runs every time, whether or not pond was used. Before showing the diff, dispatch a dedicated agent (separate from the Phase 2 research agents) to scan the added/changed lines **and every new untracked file** under `skills//` and `README.md` (if the repo generates one). `git diff` alone misses brand-new files (e.g. a fresh `references/` doc) - enumerate them with `git status --porcelain` and give the agent their full content.\n\nIt flags anything unsafe for a public skill: secrets (keys, tokens, passwords, `.env` values, connection strings), personal data (real names, emails, handles), and the easy-to-miss ones - non-public project or repo names, internal hostnames or endpoints, ticket IDs, local machine paths, pond session IDs. Intentional public references are fine (the public repo owner, official upstream repos and docs, published package names, spec URLs). The agent returns `[LEAK] : - - suggested redaction: ` per issue, or exactly `NO LEAKS FOUND`.\n\nAn unresolved `[LEAK]` is a hard blocker: redact each finding, re-run the scan, and repeat until clean before GATE 2. Hold the commit message to the same public-safe standard.\n\n### Diff review\n\nPrint `git status`, `git diff --stat`, and per-file diffs for `SKILL.md`, every changed `references/` file, `CHANGELOG.md`, and `README.md`. Then print this recovery hint verbatim, immediately above the gate banner:\n\n```\nTo discard everything: git restore . && git clean -fd skills//\n```\n\n```\nGATE 2 - APPROVE COMMIT + PUSH? (yes / no)\n```\n\nWait for explicit confirmation. Do not commit on ambiguous responses.\n\n## Phase 7 - Commit, push, watch\n\n**Branch guard first.** Run `git rev-parse --abbrev-ref HEAD`. If the result is not the repo's default branch, ask the user: push to the current branch and open a PR (recommended), push directly to the default branch (only on explicit instruction - if the repo auto-publishes on merge, this skips PR review and ships straight to the registry), or cancel.\n\nCommit with a conventional-commit message (type per content, per the repo's CLAUDE.md or AGENTS.md) using the HEREDOC pattern:\n\n```bash\ngit commit -m \"$(cat <<'EOF'\n(): \n\n\nEOF\n)\"\n```\n\n- **On the default branch**: `git push`, then, if the repo has CI, `gh run watch` the triggered run. On CI failure, surface logs verbatim; do not auto-retry.\n- **On a feature branch**: `git push -u origin `, then `gh pr create` with a body summarizing the Phase 3 report. Skip `gh run watch` at this point - PR CI is typically non-publishing, and some publish-on-merge repos run no PR CI at all. The run is not done at PR creation: once the PR merges, watch the default-branch publish run (`gh run watch`), confirm the publish landed, then do the Phase 0 cleanup (worktree first, then branch).\n\nUpdating several skills in one session? Land them together: batch into one push, or merge the PRs back-to-back and watch only the final publish run - each push to the default branch typically triggers a full republish.\n\nIf the repo auto-publishes on merge (e.g. to a registry via CI), confirm the publish landed once CI is green. The published slug and release/tag naming follow the repo's own pipeline - check its CLAUDE.md/AGENTS.md (the published slug can differ from the folder name).\n\n## Done\n\nReport a one-line summary to the user: skill name, version delta, tracked packages updated, CI status. If the repo's skills are consumed through an installer (e.g. `npx skills`), remind the user to refresh installed copies (`npx skills update `) once the publish lands.\n\nFile v0.8.2:_meta.json\n\n{\n \"ownerId\": \"kn76gpsgjw5chv0xvzbzcb8cxn81x46r\",\n \"slug\": \"update-skill\",\n \"version\": \"0.8.2\",\n \"publishedAt\": 1787314973819\n}\n\nFile v0.8.2:CHANGELOG.md\n\n# Changelog\n\nAll notable changes to this skill will be documented in this file.\n\nThe format is based on [Keep a Changelog](https://keepachangelog.com/en/2.0.0/),\nand this skill adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).\n\n## [Unreleased]\n\n## [0.8.2] - 2026-08-21\n\n### Changed\n\n- Declared ClawHub browse categories (`agents, automation`) and topics in `metadata`, so the release pipeline publishes them instead of leaving the skill in the `other` category.\n\n### Removed\n\n- `skill-card.md`. The ClawHub CLI strips a root `skill-card.md` from every publish and the registry generates its own card, so the authored file never reached ClawHub.\n\n## [0.8.1] - 2026-07-22\n\n### Added\n\n- skill-card.md release record following NVIDIA's skill-card format\n- metadata.openclaw block (emoji, homepage) for ClawHub display\n\n## [0.8.0] - 2026-07-10\n\n### Added\n- Worktree lifecycle hardening from real runs: keep the worktree until the PR merges (follow-up rounds reuse it), remove the worktree before deleting its branch, `git worktree prune` for stale entries, and regenerate (never hand-merge) generated-file conflicts like README.md on rebase.\n- Phase 3 line-budget planning: report the projected SKILL.md size when additive rows land and plan a references/ split when it would exceed the repo's cap.\n- Phase 5 failure-attribution step: when the validation gate fails in a way unrelated to the edits, stash and re-run on a clean tree before debugging.\n- Phase 3 public-vs-private scope call on usage-derived findings: private-infra learnings go to user memory/CLAUDE.md, never the public skill.\n- Phase 2 research inputs: ground-truth CLI-wrapping skills against the live installed CLI, and accept user-supplied seed findings as explicit leads.\n- Operating rule for duplicate/scheduled triggers firing mid-run: hold at the emitted gate, never redo research.\n- Phase 4 authoring caution: never let a `!` at line start or after whitespace directly touch a backticked command in SKILL.md bodies (Claude Code executes it at load, even in code fences).\n- Phase 1 pre-flight now verifies LICENSE.txt presence; Done phase reminds to propagate published updates to installed copies; Phase 7 batches multi-skill updates into one push when CI republishes per push.\n- `metadata.upstream` now tracks `keep-a-changelog@2.0.0` - the spec the skill embeds a template of, whose releases invalidate content (proven this run).\n\n### Changed\n- Keep a Changelog citations and the bootstrap header template moved from 1.1.0 to 2.0.0 (six change types and dates unchanged; adds the `**Breaking:**` marker convention and version-pinned format links).\n- Phase 2 notes subagents run in the background by default (Claude Code v2.1.198+): collect all completions before Phase 3.\n- Phase 7 feature-branch flow now follows through merge: watch the default-branch publish CI after the PR merges (some repos have no PR CI at all), then clean up branch and worktree.\n\n### Fixed\n- Bootstrap upstream proposal no longer promotes incidentally-mentioned tools: candidates must be things whose releases would invalidate the skill's content.\n- Phase 6 leak scan explicitly covers untracked new files, which `git diff` misses.\n\nVerified against: keep-a-changelog@2.0.0\n\n## [0.7.0] - 2026-06-16\n\n### Added\n- Phase 0 worktree choice: the run now asks once whether to operate in a dedicated git worktree (`git worktree add ... -b chore/update-`), enabling parallel updates of multiple skills without README/index/diff contention. All phases operate against a new `` variable (the worktree if chosen, else `${CLAUDE_PROJECT_DIR}`); the existing Phase 7 branch guard handles the resulting feature-branch PR flow, and the worktree is removed after the run.\n\n## [0.6.0] - 2026-06-05\n\n### Added\n- Restored the `argument-hint: \"[skill-name]\"` frontmatter field removed in 0.5.0. It is a valid, functional Claude Code field for user-invoked skills (used in Anthropic's own `skills//SKILL.md` examples) and is documented in this repo's `skills-best-practices`; it is simply outside the open Agent Skills spec, which ignores unknown fields.\n\n### Fixed\n- Aligned the repo linter (`scripts/check_skills.py`) with the optional Claude Code skill/command fields documented in `skills-best-practices` (`argument-hint`, `when_to_use`, `arguments`, `model`, `effort`, `context`, `agent`, `hooks`). The previous allowlist rejected fields the repo's own guidance endorses.\n\n## [0.5.0] - 2026-06-05\n\n### Added\n- Apache-2.0 `LICENSE.txt` (required for publishing).\n- Upstreamless-by-nature escape hatch: skills that wrap no package/spec/doc (workflow or writing skills) cleanly omit `metadata.upstream` and skip the bootstrap upstream-candidate proposal instead of being nagged.\n\n### Changed\n- Generalized for use in any skills repository. The pond usage angle is now optional with an explicit skip-and-fallback when the pond MCP is absent (https://pond.cascade.fyi/). Phase 5 reframed as a repo-agnostic validation gate, and Phase 7 defers publish/slug/release-tag specifics to the repo's own pipeline (CLAUDE.md/AGENTS.md) instead of hardcoding this repo's ClawHub scripts and release-tag naming.\n\n### Removed\n- `argument-hint` frontmatter field to pass the repo's lint allowlist (restored in 0.6.0 once the allowlist was corrected; the body already handles the no-argument case regardless).\n\nFile v0.8.2:skill-card.md\n\n## Description:\n\nUpdate Skill helps developers refresh one skill in a skills repository by researching usage, upstream changes, and documentation, proposing gated edits, updating versioning and changelogs, validating changes, and preparing commit and publish steps.\n\nThis skill is ready for commercial/non-commercial use.\n\n## Publisher:\n\n[tenequm](https://clawhub.ai/user/tenequm)\n\n### License/Terms of Use:\n\nApache 2.0\n\n## Use Case:\n\nDevelopers and skill maintainers use this skill to perform an agent-assisted refresh of a specific repository skill, including research, gated edits, changelog and version updates, validation, privacy scanning, and commit or publish review.\n\n### Deployment Geography for Use:\n\nGlobal\n\n## Known Risks and Mitigations:\n\nRisk: The workflow can modify repository skills and prepare commits or pushes.\n\nMitigation: Review the Phase 3 proposal before approving edits and review the Phase 6 diff before approving commit or push steps.\n\nRisk: Research or usage findings could introduce private details into a public skill update.\n\nMitigation: Use the required privacy scan and drop private-scope findings before commit review.\n\nRisk: Agent-proposed changes could introduce incorrect or misleading skill guidance.\n\nMitigation: Ground findings against primary sources, run the repository validation gate, and review generated changes before deployment.\n\n## Reference(s):\n\n- [Update Skill homepage](https://github.com/tenequm/skills/tree/main/skills/update-skill)\n- [Pond MCP](https://pond.cascade.fyi/)\n- [Keep a Changelog 2.0.0](https://keepachangelog.com/en/2.0.0/)\n- [Semantic Versioning 2.0.0](https://semver.org/spec/v2.0.0.html)\n\n## Skill Output:\n\n**Output Type(s):** [Guidance, Markdown, Code, Shell commands, Configuration instructions]\n\n**Output Format:** [Markdown reports with command snippets, proposed file edits, validation results, diffs, and git or CI status summaries]\n\n**Output Parameters:** [1D]\n\n**Other Properties Related to Output:** [Requires explicit user approval before edits and before commit or push steps.]\n\n## Skill Version(s):\n\n0.8.2 (source: frontmatter, changelog, server release metadata)\n\n## Ethical Considerations:\n\nUsers should evaluate whether this skill is appropriate for their environment, review any generated or modified files before relying on them, and apply their organization's safety, security, and compliance requirements before deployment.\n\nFile v0.8.2:LICENSE.txt\n\nApache License\nVersion 2.0, January 2004\nhttps://www.apache.org/licenses/\n\nTERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION\n\n1. Definitions.\n\n\"License\" shall mean the terms and conditions for use, reproduction, and\ndistribution as defined by Sections 1 through 9 of this document.\n\n\"Licensor\" shall mean the copyright owner or entity authorized by the\ncopyright owner that is granting the License.\n\n\"Legal Entity\" shall mean the union of the acting entity and all other\nentities that control, are controlled by, or are under common control with\nthat entity. For the purposes of this definition, \"control\" means (i) the\npower, direct or indirect, to cause the direction or management of such\nentity, whether by contract or otherwise, or (ii) ownership of fifty percent\n(50%) or more of the outstanding shares, or (iii) beneficial ownership of\nsuch entity.\n\n\"You\" (or \"Your\") shall mean an individual or Legal Entity exercising\npermissions granted by this License.\n\n\"Source\" form shall mean the preferred form for making modifications,\nincluding but not limited to software source code, documentation source, and\nconfiguration files.\n\n\"Object\" form shall mean any form resulting from mechanical transformation or\ntranslation of a Source form, including but not limited to compiled object\ncode, generated documentation, and conversions to other media types.\n\n\"Work\" shall mean the work of authorship, whether in Source or Object form,\nmade available under the License, as indicated by a copyright notice that is\nincluded in or attached to the work (an example is provided in the Appendix\nbelow).\n\n\"Derivative Works\" shall mean any work, whether in Source or Object form,\nthat is based on (or derived from) the Work and for which the editorial\nrevisions, annotations, elaborations, or other modifications represent, as a\nwhole, an original work of authorship. For the purposes of this License,\nDerivative Works shall not include works that remain separable from, or\nmerely link (or bind by name) to the interfaces of, the Work and Derivative\nWorks thereof.\n\n\"Contribution\" shall mean any work of authorship, including the original\nversion of the Work and any modifications or additions to that Work or\nDerivative Works thereof, that is intentionally submitted to Licensor for\ninclusion in the Work by the copyright owner or by an individual or Legal\nEntity authorized to submit on behalf of the copyright owner. For the\npurposes of this definition, \"submitted\" means any form of electronic, verbal,\nor written communication sent to the Licensor or its representatives,\nincluding but not limited to communication on electronic mailing lists, source\ncode control systems, and issue tracking systems that are managed by, or on\nbehalf of, the Licensor for the purpose of discussing and improving the Work,\nbut excluding communication that is conspicuously marked or otherwise\ndesignated in writing by the copyright owner as \"Not a Contribution.\"\n\n\"Contributor\" shall mean Licensor and any individual or Legal Entity on\nbehalf of whom a Contribution has been received by Licensor and subsequently\nincorporated within the Work.\n\n2. Grant of Copyright License. Subject to the terms and conditions of this\nLicense, each Contributor hereby grants to You a perpetual, worldwide,\nnon-exclusive, no-charge, royalty-free, irrevocable copyright license to\nreproduce, prepare Derivative Works of, publicly display, publicly perform,\nsublicense, and distribute the Work and such Derivative Works in Source or\nObject form.\n\n3. Grant of Patent License. Subject to the terms and conditions of this\nLicense, each Contributor hereby grants to You a perpetual, worldwide,\nnon-exclusive, no-charge, royalty-free, irrevocable (except as stated in this\nsection) patent license to make, have made, use, offer to sell, sell, import,\nand otherwise transfer the Work, where such license applies only to those\npatent claims licensable by such Contributor that are necessarily infringed by\ntheir Contribution(s) alone or by combination of their Contribution(s) with\nthe Work to which such Contribution(s) was submitted. If You institute patent\nlitigation against any entity (including a cross-claim or counterclaim in a\nlawsuit) alleging that the Work or a Contribution incorporated within the Work\nconstitutes direct or contributory patent infringement, then any patent\nlicenses granted to You under this License for that Work shall terminate as of\nthe date such litigation is filed.\n\n4. Redistribution. You may reproduce and distribute copies of the Work or\nDerivative Works thereof in any medium, with or without modifications, and in\nSource or Object form, provided that You meet the following conditions:\n\n(a) You must give any other recipients of the Work or Derivative Works a copy\nof this License; and\n\n(b) You must cause any modified files to carry prominent notices stating that\nYou changed the files; and\n\n(c) You must retain, in the Source form of any Derivative Works that You\ndistribute, all copyright, patent, trademark, and attribution notices from\nthe Source form of the Work, excluding those notices that do not pertain to\nany part of the Derivative Works; and\n\n(d) If the Work includes a \"NOTICE\" text file as part of its distribution,\nthen any Derivative Works that You distribute must include a readable copy of\nthe attribution notices contained within such NOTICE file, excluding those\nnotices that do not pertain to any part of the Derivative Works, in at least\none of the following places: within a NOTICE text file distributed as part of\nthe Derivative Works; within the Source form or documentation, if provided\nalong with the Derivative Works; or, within a display generated by the\nDerivative Works, if and wherever such third-party notices normally appear.\nThe contents of the NOTICE file are for informational purposes only and do not\nmodify the License. You may add Your own attribution notices within Derivative\nWorks that You distribute, alongside or as an addendum to the NOTICE text from\nthe Work, provided that such additional attribution notices cannot be\nconstrued as modifying the License.\n\nYou may add Your own copyright statement to Your modifications and may provide\nadditional or different license terms and conditions for use, reproduction, or\ndistribution of Your modifications, or for any such Derivative Works as a\nwhole, provided Your use, reproduction, and distribution of the Work otherwise\ncomplies with the conditions stated in this License.\n\n5. Submission of Contributions. Unless You explicitly state otherwise, any\nContribution intentionally submitted for inclusion in the Work by You to the\nLicensor shall be under the terms and conditions of this License, without any\nadditional terms or conditions. Notwithstanding the above, nothing herein\nshall supersede or modify the terms of any separate license agreement you may\nhave executed with Licensor regarding such Contributions.\n\n6. Trademarks. This License does not grant permission to use the trade names,\ntrademarks, service marks, or product names of the Licensor, except as\nrequired for reasonable and customary use in describing the origin of the Work\nand reproducing the content of the NOTICE file.\n\n7. Disclaimer of Warranty. Unless required by applicable law or agreed to in\nwriting, Licensor provides the Work (and each Contributor provides its\nContributions) on an \"AS IS\" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY\nKIND, either express or implied, including, without limitation, any warranties\nor conditions of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A\nPARTICULAR PURPOSE. You are solely responsible for determining the\nappropriateness of using or redistributing the Work and assume any risks\nassociated with Your exercise of permissions under this License.\n\n8. Limitation of Liability. In no event and under no legal theory, whether in\ntort (including negligence), contract, or otherwise, unless required by\napplicable law (such as deliberate and grossly negligent acts) or agreed to in\nwriting, shall any Contributor be liable to You for damages, including any\ndirect, indirect, special, incidental, or consequential damages of any\ncharacter arising as a result of this License or out of the use or inability to\nuse the Work (including but not limited to damages for loss of goodwill, work\nstoppage, computer failure or malfunction, or any and all other commercial\ndamages or losses), even if such Contributor has been advised of the\npossibility of such damages.\n\n9. Accepting Warranty or Additional Liability. While redistributing the Work\nor Derivative Works thereof, You may choose to offer, and charge a fee for,\nacceptance of support, warranty, indemnity, or other liability obligations\nand/or rights consistent with this License. However, in accepting such\nobligations, You may act only on Your own behalf and on Your sole\nresponsibility, not on behalf of any other Contributor, and only if You agree\nto indemnify, defend, and hold each Contributor harmless for any liability\nincurred by, or claims asserted against, such Contributor by reason of your\naccepting any such warranty or additional liability.\n\nEND OF TERMS AND CONDITIONS\n\nArchive v0.8.1: 5 files, 16554 bytes\n\nFiles: CHANGELOG.md (4964b), LICENSE.txt (9157b), skill-card.md (2341b), SKILL.md (20308b), _meta.json (131b)\n\nFile v0.8.1:SKILL.md\n\n---\nname: update-skill\ndescription: \"Thorough on-demand refresh of one skill in a skills repository: researches usage/upstream/docs in parallel, gates twice for approval, bumps version, updates CHANGELOG, runs the repo's validation, then commits and watches CI. Install the pond MCP (https://pond.cascade.fyi/) for the prior-session usage angle; without it that angle is skipped. Use to update, refresh, or check the freshness of a specific skill.\"\nargument-hint: \"[skill-name]\"\ndisable-model-invocation: true\nmetadata:\n version: \"0.8.1\"\n openclaw:\n homepage: https://github.com/tenequm/skills/tree/main/skills/update-skill\n emoji: \"🔄\"\n upstream: \"keep-a-changelog@2.0.0\"\n---\n\n# Update Skill\n\nRun a thorough on-demand refresh of one skill in a skills repository. Two hard human-approval gates ensure no edits or commits happen without explicit confirmation.\n\nThe target skill is: $ARGUMENTS\n\nIf no argument was provided, run `ls ${CLAUDE_PROJECT_DIR}/skills/` and ask the user which to update. Stop until confirmed. Then verify `${CLAUDE_PROJECT_DIR}/skills/$ARGUMENTS/SKILL.md` exists; if not, list skills and ask again. Throughout this run, `` refers to the resolved skill name.\n\n## Operating rules\n\nThese rules apply across all phases:\n\n- **GATE 1 stops before any edit.** Do NOT call Edit or Write until the user replies affirmatively to the GATE 1 banner.\n- **GATE 2 stops before any commit or push.** Do NOT run `git commit` or `git push` until the user replies affirmatively to the GATE 2 banner.\n- **Privacy scan is a hard blocker.** Skills in a public repo can publish on merge, so the run does not reach a commit while a Phase 6 leak finding is unresolved.\n- **Sticky posture.** Once GATE 1 has been emitted, \"report findings first\" persists across follow-up rounds in the same session. If the user replies `changes` or asks for revisions, re-emit the gate after revising; never silently apply.\n- **Non-resume.** If the session is interrupted between GATE 1 and GATE 2, re-run `/update-skill ` from scratch. There is no checkpoint or resume mechanism.\n- **Duplicate triggers.** If a scheduled task or a repeated invocation fires while a run is holding at a gate, hold at the emitted gate and answer from the existing report - never redo research or re-apply edits.\n- **No `--no-verify`, no `--amend`, no force-push** unless the user explicitly authorizes it for this run. Per the repo's CLAUDE.md or AGENTS.md.\n- **Working directory.** Every path, every `just check`, and every working git command (`status`/`diff`/`add`/`commit`/`push`) in the phases below runs against `` - the worktree created in Phase 0 if the user opted in, otherwise `${CLAUDE_PROJECT_DIR}`. Use absolute paths under ``; do not mix in the main checkout once a worktree is chosen. The exception is Phase 0's own `git worktree add`/`remove`, which must run against `${CLAUDE_PROJECT_DIR}` (the main checkout).\n\n## Phase 0 - Worktree choice (ask first)\n\nAfter resolving ``, ask exactly once: \"Run this update in a dedicated git worktree, so you can update other skills in parallel? (yes / no)\". Wait for the reply.\n\n- **no** (default) -> set `` = `${CLAUDE_PROJECT_DIR}` and proceed to Phase 1 in the current checkout.\n- **yes** -> create an isolated worktree on a fresh branch and use it as `` for the entire run:\n ```bash\n git -C \"${CLAUDE_PROJECT_DIR}\" worktree add \"${CLAUDE_PROJECT_DIR}/../skills-\" -b chore/update-\n ```\n Set `` = `${CLAUDE_PROJECT_DIR}/../skills-`. If that path or branch already exists, add the same numeric suffix (`-2`, `-3`, ...) to both the worktree path and the branch name until both are free, and carry that suffix into ``. Every later phase - reads, edits, `just check`, diff review, commit, push - operates inside ``. The Phase 7 branch guard will see `chore/update-` and route to the push + PR flow automatically. Keep the worktree until the PR is **merged** - follow-up review rounds reuse it instead of recreating it. Then clean up in order: `git -C \"${CLAUDE_PROJECT_DIR}\" worktree remove \"\"` first, then delete the branch (`git branch -d chore/update-`) - a branch delete fails while a worktree still holds the branch. `git worktree remove` refuses if there are uncommitted changes (leave it in place and tell the user if so); `git worktree prune` clears stale entries left by interrupted runs. If a generated file (e.g. `README.md`) conflicts when the PR falls behind the default branch, rebase and re-run the generator - never hand-merge generated output. If the user aborts before a PR exists, remove the worktree and delete the branch the same way.\n\n## Phase 1 - Pre-flight read\n\nRead every file in `skills//` end-to-end, in parallel:\n- `skills//SKILL.md`\n- All files under `skills//references/` (use Glob first to enumerate)\n- `skills//CHANGELOG.md` (if present)\n\nCapture state for the rest of the run:\n- `metadata.version` (current)\n- `metadata.upstream` (current; parse to `{name: version}` map; empty if absent)\n- Topmost CHANGELOG entry date (if `CHANGELOG.md` exists; this is the \"last verified\" signal)\n- `git log -1 --format=%cs -- skills//` date (last touch)\n- `LICENSE.txt` (or the repo's equivalent) present and non-empty - publish pipelines and repo linters commonly hard-fail without it; if missing, queue a fix row in the Phase 3 report\n- `bootstrap_needed` flag = true if `metadata.upstream` is missing OR `CHANGELOG.md` is missing - **unless the skill is upstreamless by nature** (it wraps no package, spec, or living doc - e.g. a workflow or writing skill like `polish`). For those, omitting `metadata.upstream` is correct, not a gap: derive `bootstrap_needed` from the missing `CHANGELOG.md` alone and skip the upstream-candidate proposal.\n\n## Phase 2 - Parallel research\n\nDispatch three research subagents in a single message, one per angle. Subagents run in the background by default (Claude Code v2.1.198+): collect every agent's completion before starting Phase 3. If the user supplied a seed finding (a bug they hit, a release they know about), pass it verbatim to the relevant agent - specific leads converge fastest. **Adapt each angle to the skill**: a skill wrapping a package researches that package's releases and source; a skill tracking living docs or a spec researches those docs and their source repos; a skill with no upstream at all still gets the usage angle.\n\n- **Usage** (pond - optional): if the pond MCP (`mcp__pond__pond_search`) is available, mine it with NO `project` filter for footguns, scenario-specific breakage, inefficiencies, gaps, and recurring misunderstandings the skill could absorb. Keep the query semantic (concepts, not project names); scope with filters. These are **advisory leads, not facts** - never verified, ground-checked in Phase 3. **If pond is not installed, skip this angle entirely** - dispatch only the upstream and docs agents, and note \"Usage angle skipped: pond MCP not available (https://pond.cascade.fyi/)\" in the Phase 3 report.\n- **Upstream**: releases, commits, and merged PRs since the last-verified date. Read real source - clone to a local scratch dir (e.g. `~/pjv//`, lowercase) or use the GitHub MCP pinned to a concrete tag/SHA. For skills wrapping a CLI, also ground-truth against the live installed binary (` --help`, real invocations) - docs and clones lag shipped behavior.\n- **Docs**: the current canonical docs, read from source (raw `.md` or cloned repo), not model-summarized. Two distinct jobs, **both required**:\n - **(a) Drift check** - compare the docs against the skill's current `SKILL.md` and `references/`, flagging API changes, deprecated or removed symbols, and patterns the skill should adopt. This is anchored to what the skill already says.\n - **(b) Coverage sweep** - enumerate upstream's *current* feature/concept surface from the docs nav / table of contents, the API index, and the \"what's new\" / changelog. List every major capability, primitive, or concept the skill has **zero mention of**. Do NOT anchor this to existing skill content - the whole point is to find net-new surface the skill is silent about (`ADD` findings). This is the step a \"verify what's there\" pass structurally misses.\n\nEvery finding is one bulleted line: `[KIND]` (`ADD`/`CHANGE`/`DEPRECATE`/`REMOVE`/`FIX`/`SECURITY`), a one-line summary, an exact quote from the source (no paraphrase), and a citation. pond findings also carry `status: advisory`. Merge all returns into one list, deduped by `(KIND, citation)`.\n\n## Phase 3 - Verify, report, GATE 1\n\n### Ground-truth verification (before the report)\n\nNo row ships unverified. Before a finding becomes a row, confirm it against primary source read **today**:\n\n- Verify the finding's claim **and the existing skill text it touches** - links, enumerated lists, pinned versions, version-coupled examples. Spot-check the skill's other upstream-coupled claims even where no finding landed; silent staleness is the common miss.\n- A row asserting upstream state (a bug, API shape, version, behavior) cites the primary source checked - cloned `repo@SHA file:line`, a release, or a docs URL; a pond citation alone is insufficient, so re-ground it or drop it. A row that is purely experiential enrichment (a recurring gap or confusion) may keep its pond citation, but verify the wording you write is technically correct.\n- Drop a pond-reported bug already fixed upstream; correct any finding whose pond framing the source contradicts.\n- **Coverage-gap rows** (net-new concepts from the Phase 2(b) sweep) are verified two ways: confirm the concept exists in today's source (cite it), **and** confirm the skill genuinely omits it - grep the skill for the concept and any synonyms before claiming it's absent, so a renamed-but-present feature isn't reported as missing.\n- Scope-check every usage-derived row: a learning about private infrastructure (internal hosts, personal tooling, machine-specific setups) belongs in the user's own CLAUDE.md or memory, not a public skill. Route it there and drop the row - the Phase 6 leak scan cannot make this judgment call.\n\n### Report\n\nPrint a structured report, sections in order:\n\n1. **Tracked packages diff** - `package | pinned | latest | delta`, or \"no upstream packages tracked.\"\n2. **Proposed `metadata.upstream`** - the new flat string. No floating tags (`@latest`/`@next`/`@beta`/`@canary`); pin to a concrete tag or SHA.\n3. **Proposed CHANGELOG entry** - a Keep a Changelog block ready to commit.\n4. **Proposed edits** - one row per smallest atomic change, each with a stable ID (`A1`/`C1`/`D1`/`R1`/`F1`/`S1`...): ` | target file | one-line summary | citation`. Batch trivially-related changes into one row; past ~20 rows, consider whether the skill needs a rewrite rather than a patch. When ADD rows are numerous, include the projected post-apply `SKILL.md` line count; if it would cross the repo's size cap (500 lines in this repo), plan the `references/` split as part of the proposal, not as a surprise after apply.\n5. **New-concept coverage** (**always present, never omitted**) - the result of the Phase 2(b) coverage sweep. Either a table of net-new upstream concepts the skill omits (each becoming an `ADD` row above), or the explicit statement that there are none. End this section with the verbatim attestation below. Coverage need not be complete to pass - but any gap in what you could enumerate (JS-gated docs, rate limits, unreachable pages) must be named here, not silently dropped:\n ```\n Coverage sweep: enumerated upstream's current surface from . Net-new concepts the skill omits: / none since . Not reachable this run: .\n ```\n6. **Bootstrap proposal** (only when `bootstrap_needed`): candidate upstream packages greppable from the skill's content, each as ` (mentioned x, first cite: :)` for the user to confirm or prune; plus a seed `CHANGELOG.md`. Propose only upstreams whose releases would invalidate the skill's content - the package, spec, or living doc the skill teaches. A tool mentioned incidentally (a validator run once, a CLI in one example) is not an upstream candidate. If the skill is **upstreamless by nature**, say so explicitly, propose no candidates, and leave `metadata.upstream` omitted - only seed the `CHANGELOG.md`.\n\n### No-op short-circuit\n\nIf sections 1-4 yield zero rows AND the Phase 2(b) coverage sweep found no omitted concepts (section 5 attestation says \"none\") AND `bootstrap_needed` is false, print this verbatim and exit cleanly - no file changes, no commit. Never short-circuit without the section 5 attestation present:\n\n```\nAll current as of . Last verified per CHANGELOG.md on against .\n```\n\n### CHANGELOG format\n\n[Keep a Changelog](https://keepachangelog.com/en/2.0.0/) format. The dated entry uses only the sections it has content for (Added / Changed / Deprecated / Removed / Fixed / Security), plus a `Verified against: ` trailer **only if** a tracked package version actually changed this run. Mark breaking changes inside Changed/Removed with a leading `**Breaking:**` marker, and pin the KaC link in preambles to the version followed (both per KaC 2.0.0).\n\nWhen `bootstrap_needed`, create the full file with this header:\n\n```markdown\n# Changelog\n\nAll notable changes to this skill will be documented in this file.\n\nThe format is based on [Keep a Changelog](https://keepachangelog.com/en/2.0.0/),\nand this skill adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).\n\n## [Unreleased]\n\n## [] - \n- Initial CHANGELOG; tracking established.\n```\n\n### GATE 1 banner (verbatim)\n\n```\nGATE 1 - APPROVE TO EDIT? (yes / yes / drop / changes / no)\n```\n\nReply parsing:\n- `yes` / `yes all` -> apply every row\n- `yes A1-A4 C1` -> apply only those rows (and the listed package version updates, if any)\n- `drop D1,R2` -> apply everything except those\n- `changes ` -> revise the report and re-emit GATE 1\n- `no` -> abort, no changes\n\nDo NOT call Edit or Write until you receive an affirmative. Every revision round re-emits GATE 1; never silently apply.\n\n## Phase 4 - Apply\n\nApply each approved row with Edit/Write; batch independent edits in parallel. Then, in order:\n\n1. Update `metadata.upstream` to the new comma-separated `@` list. Reject floating tags - stop with an error if one appears. Skip entirely if the skill is upstreamless by nature - leave `metadata.upstream` omitted.\n2. Bump `metadata.version` (semver per the repo's CLAUDE.md or AGENTS.md: patch for fixes, minor for new content/sections, major for breaking removal).\n3. Append the new dated entry to `CHANGELOG.md` directly under `[Unreleased]`, above the previous entry. Add the `Verified against:` trailer only if a tracked version changed this run.\n4. If `bootstrap_needed`, write the full `CHANGELOG.md` from the bootstrap header plus the approved seed entry.\n5. When pasting upstream doc examples into a `SKILL.md` body, never let a `!` at line start or after whitespace directly touch a backticked command - Claude Code executes it at skill load, even inside code fences, and repo linters may reject it. Keep such examples in `references/` or break the adjacency.\n6. Check the post-apply `SKILL.md` line count against the repo's cap (500 here); if crossed, execute the `references/` split planned in Phase 3.\n\n## Phase 5 - Repo validation gate\n\nIf the repo defines a validation command - check its CLAUDE.md/AGENTS.md or `Justfile`/`package.json` (e.g. `just check`, `npm run lint`, `make check`) - run it from `` (the repo root, or the Phase 0 worktree). In this repo that is `just check`, which also regenerates `README.md` (the most common CI failure cause). On failure, surface the error verbatim, fix the root cause, and re-run until clean. If the failure looks unrelated to this run's edits, attribute before debugging: stash the changes (`git stash -u`) and re-run the gate on a clean tree. Failing identically means the breakage is pre-existing (an environment flake or repo issue) - unstash, report it to the user, and don't sink this run into debugging it. No `--no-verify`, no `--amend`, no hook-skipping. If the repo has no validation gate, skip this phase and note it.\n\n## Phase 6 - Privacy scan + diff review + GATE 2\n\n### Privacy / leak scan (hard blocker)\n\nSkills in a public repo can publish on merge, and any research source can leak into the diff - especially pond, which draws on private cross-project conversations. This scan runs every time, whether or not pond was used. Before showing the diff, dispatch a dedicated agent (separate from the Phase 2 research agents) to scan the added/changed lines **and every new untracked file** under `skills//` and `README.md` (if the repo generates one). `git diff` alone misses brand-new files (e.g. a fresh `references/` doc) - enumerate them with `git status --porcelain` and give the agent their full content.\n\nIt flags anything unsafe for a public skill: secrets (keys, tokens, passwords, `.env` values, connection strings), personal data (real names, emails, handles), and the easy-to-miss ones - non-public project or repo names, internal hostnames or endpoints, ticket IDs, local machine paths, pond session IDs. Intentional public references are fine (the public repo owner, official upstream repos and docs, published package names, spec URLs). The agent returns `[LEAK] : - - suggested redaction: ` per issue, or exactly `NO LEAKS FOUND`.\n\nAn unresolved `[LEAK]` is a hard blocker: redact each finding, re-run the scan, and repeat until clean before GATE 2. Hold the commit message to the same public-safe standard.\n\n### Diff review\n\nPrint `git status`, `git diff --stat`, and per-file diffs for `SKILL.md`, every changed `references/` file, `CHANGELOG.md`, and `README.md`. Then print this recovery hint verbatim, immediately above the gate banner:\n\n```\nTo discard everything: git restore . && git clean -fd skills//\n```\n\n```\nGATE 2 - APPROVE COMMIT + PUSH? (yes / no)\n```\n\nWait for explicit confirmation. Do not commit on ambiguous responses.\n\n## Phase 7 - Commit, push, watch\n\n**Branch guard first.** Run `git rev-parse --abbrev-ref HEAD`. If the result is not the repo's default branch, ask the user: push to the current branch and open a PR (recommended), push directly to the default branch (only on explicit instruction - if the repo auto-publishes on merge, this skips PR review and ships straight to the registry), or cancel.\n\nCommit with a conventional-commit message (type per content, per the repo's CLAUDE.md or AGENTS.md) using the HEREDOC pattern:\n\n```bash\ngit commit -m \"$(cat <<'EOF'\n(): \n\n\nEOF\n)\"\n```\n\n- **On the default branch**: `git push`, then, if the repo has CI, `gh run watch` the triggered run. On CI failure, surface logs verbatim; do not auto-retry.\n- **On a feature branch**: `git push -u origin `, then `gh pr create` with a body summarizing the Phase 3 report. Skip `gh run watch` at this point - PR CI is typically non-publishing, and some publish-on-merge repos run no PR CI at all. The run is not done at PR creation: once the PR merges, watch the default-branch publish run (`gh run watch`), confirm the publish landed, then do the Phase 0 cleanup (worktree first, then branch).\n\nUpdating several skills in one session? Land them together: batch into one push, or merge the PRs back-to-back and watch only the final publish run - each push to the default branch typically triggers a full republish.\n\nIf the repo auto-publishes on merge (e.g. to a registry via CI), confirm the publish landed once CI is green. The published slug and release/tag naming follow the repo's own pipeline - check its CLAUDE.md/AGENTS.md (the published slug can differ from the folder name).\n\n## Done\n\nReport a one-line summary to the user: skill name, version delta, tracked packages updated, CI status. If the repo's skills are consumed through an installer (e.g. `npx skills`), remind the user to refresh installed copies (`npx skills update `) once the publish lands.\n\nFile v0.8.1:_meta.json\n\n{\n \"ownerId\": \"kn76gpsgjw5chv0xvzbzcb8cxn81x46r\",\n \"slug\": \"update-skill\",\n \"version\": \"0.8.1\",\n \"publishedAt\": 1784746113963\n}\n\nFile v0.8.1:CHANGELOG.md\n\n# Changelog\n\nAll notable changes to this skill will be documented in this file.\n\nThe format is based on [Keep a Changelog](https://keepachangelog.com/en/2.0.0/),\nand this skill adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).\n\n## [Unreleased]\n\n## [0.8.1] - 2026-07-22\n\n### Added\n\n- skill-card.md release record following NVIDIA's skill-card format\n- metadata.openclaw block (emoji, homepage) for ClawHub display\n\n## [0.8.0] - 2026-07-10\n\n### Added\n- Worktree lifecycle hardening from real runs: keep the worktree until the PR merges (follow-up rounds reuse it), remove the worktree before deleting its branch, `git worktree prune` for stale entries, and regenerate (never hand-merge) generated-file conflicts like README.md on rebase.\n- Phase 3 line-budget planning: report the projected SKILL.md size when additive rows land and plan a references/ split when it would exceed the repo's cap.\n- Phase 5 failure-attribution step: when the validation gate fails in a way unrelated to the edits, stash and re-run on a clean tree before debugging.\n- Phase 3 public-vs-private scope call on usage-derived findings: private-infra learnings go to user memory/CLAUDE.md, never the public skill.\n- Phase 2 research inputs: ground-truth CLI-wrapping skills against the live installed CLI, and accept user-supplied seed findings as explicit leads.\n- Operating rule for duplicate/scheduled triggers firing mid-run: hold at the emitted gate, never redo research.\n- Phase 4 authoring caution: never let a `!` at line start or after whitespace directly touch a backticked command in SKILL.md bodies (Claude Code executes it at load, even in code fences).\n- Phase 1 pre-flight now verifies LICENSE.txt presence; Done phase reminds to propagate published updates to installed copies; Phase 7 batches multi-skill updates into one push when CI republishes per push.\n- `metadata.upstream` now tracks `keep-a-changelog@2.0.0` - the spec the skill embeds a template of, whose releases invalidate content (proven this run).\n\n### Changed\n- Keep a Changelog citations and the bootstrap header template moved from 1.1.0 to 2.0.0 (six change types and dates unchanged; adds the `**Breaking:**` marker convention and version-pinned format links).\n- Phase 2 notes subagents run in the background by default (Claude Code v2.1.198+): collect all completions before Phase 3.\n- Phase 7 feature-branch flow now follows through merge: watch the default-branch publish CI after the PR merges (some repos have no PR CI at all), then clean up branch and worktree.\n\n### Fixed\n- Bootstrap upstream proposal no longer promotes incidentally-mentioned tools: candidates must be things whose releases would invalidate the skill's content.\n- Phase 6 leak scan explicitly covers untracked new files, which `git diff` misses.\n\nVerified against: keep-a-changelog@2.0.0\n\n## [0.7.0] - 2026-06-16\n\n### Added\n- Phase 0 worktree choice: the run now asks once whether to operate in a dedicated git worktree (`git worktree add ... -b chore/update-`), enabling parallel updates of multiple skills without README/index/diff contention. All phases operate against a new `` variable (the worktree if chosen, else `${CLAUDE_PROJECT_DIR}`); the existing Phase 7 branch guard handles the resulting feature-branch PR flow, and the worktree is removed after the run.\n\n## [0.6.0] - 2026-06-05\n\n### Added\n- Restored the `argument-hint: \"[skill-name]\"` frontmatter field removed in 0.5.0. It is a valid, functional Claude Code field for user-invoked skills (used in Anthropic's own `skills//SKILL.md` examples) and is documented in this repo's `skills-best-practices`; it is simply outside the open Agent Skills spec, which ignores unknown fields.\n\n### Fixed\n- Aligned the repo linter (`scripts/check_skills.py`) with the optional Claude Code skill/command fields documented in `skills-best-practices` (`argument-hint`, `when_to_use`, `arguments`, `model`, `effort`, `context`, `agent`, `hooks`). The previous allowlist rejected fields the repo's own guidance endorses.\n\n## [0.5.0] - 2026-06-05\n\n### Added\n- Apache-2.0 `LICENSE.txt` (required for publishing).\n- Upstreamless-by-nature escape hatch: skills that wrap no package/spec/doc (workflow or writing skills) cleanly omit `metadata.upstream` and skip the bootstrap upstream-candidate proposal instead of being nagged.\n\n### Changed\n- Generalized for use in any skills repository. The pond usage angle is now optional with an explicit skip-and-fallback when the pond MCP is absent (https://pond.cascade.fyi/). Phase 5 reframed as a repo-agnostic validation gate, and Phase 7 defers publish/slug/release-tag specifics to the repo's own pipeline (CLAUDE.md/AGENTS.md) instead of hardcoding this repo's ClawHub scripts and release-tag naming.\n\n### Removed\n- `argument-hint` frontmatter field to pass the repo's lint allowlist (restored in 0.6.0 once the allowlist was corrected; the body already handles the no-argument case regardless).\n\nFile v0.8.1:skill-card.md\n\n## Description:
\nUpdate Skill guides an agent through a gated refresh of one skill repository entry, including research, version and changelog updates, validation, and commit or PR follow-through.
\n\nThis skill is ready for commercial/non-commercial use.
\n\n## Publisher:
\n[tenequm](https://clawhub.ai/user/tenequm)
\n\n### License/Terms of Use:
\nApache 2.0
\n\n\n## Use Case:
\nDevelopers and maintainers use this skill to refresh a single skill in a skills repository, review proposed edits at approval gates, update release metadata, run validation, and prepare repository changes for publication.
\n\n### Deployment Geography for Use:
\nGlobal
\n\n## Known Risks and Mitigations:
\nRisk: Agent-assisted refreshes can introduce incorrect or misleading changes to skill files or release metadata.
\nMitigation: Review the Gate 1 proposed edits, validation output, and Gate 2 diff before approving changes.
\nRisk: After approval, the workflow can commit and push repository changes that may publish through the repository pipeline.
\nMitigation: Approve Gate 2 only after confirming the target branch, privacy scan result, diff, and CI or publication expectations.
\n\n\n## Reference(s):
\n- [Skill homepage](https://github.com/tenequm/skills/tree/main/skills/update-skill)
\n- [Keep a Changelog 2.0.0](https://keepachangelog.com/en/2.0.0/)
\n- [Semantic Versioning](https://semver.org/spec/v2.0.0.html)
\n- [Pond MCP](https://pond.cascade.fyi/)
\n\n\n## Skill Output:
\n**Output Type(s):** [text, markdown, code, shell commands, configuration, guidance]
\n**Output Format:** [Markdown reports with inline shell commands, proposed file edits, changelog entries, and git workflow guidance]
\n**Output Parameters:** [1D]
\n**Other Properties Related to Output:** [Uses two human approval gates before applying edits and before committing or pushing repository changes.]
\n\n## Skill Version(s):
\n0.8.1 (source: metadata.version, release.version, and CHANGELOG.md, released 2026-07-22)
\n\n## Ethical Considerations:
\nUsers should evaluate whether this skill is appropriate for their environment, review any generated or modified files before relying on them, and apply their organization's safety, security, and compliance requirements before deployment.
\n\nFile v0.8.1:LICENSE.txt\n\nApache License\nVersion 2.0, January 2004\nhttps://www.apache.org/licenses/\n\nTERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION\n\n1. Definitions.\n\n\"License\" shall mean the terms and conditions for use, reproduction, and\ndistribution as defined by Sections 1 through 9 of this document.\n\n\"Licensor\" shall mean the copyright owner or entity authorized by the\ncopyright owner that is granting the License.\n\n\"Legal Entity\" shall mean the union of the acting entity and all other\nentities that control, are controlled by, or are under common control with\nthat entity. For the purposes of this definition, \"control\" means (i) the\npower, direct or indirect, to cause the direction or management of such\nentity, whether by contract or otherwise, or (ii) ownership of fifty percent\n(50%) or more of the outstanding shares, or (iii) beneficial ownership of\nsuch entity.\n\n\"You\" (or \"Your\") shall mean an individual or Legal Entity exercising\npermissions granted by this License.\n\n\"Source\" form shall mean the preferred form for making modifications,\nincluding but not limited to software source code, documentation source, and\nconfiguration files.\n\n\"Object\" form shall mean any form resulting from mechanical transformation or\ntranslation of a Source form, including but not limited to compiled object\ncode, generated documentation, and conversions to other media types.\n\n\"Work\" shall mean the work of authorship, whether in Source or Object form,\nmade available under the License, as indicated by a copyright notice that is\nincluded in or attached to the work (an example is provided in the Appendix\nbelow).\n\n\"Derivative Works\" shall mean any work, whether in Source or Object form,\nthat is based on (or derived from) the Work and for which the editorial\nrevisions, annotations, elaborations, or other modifications represent, as a\nwhole, an original work of authorship. For the purposes of this License,\nDerivative Works shall not include works that remain separable from, or\nmerely link (or bind by name) to the interfaces of, the Work and Derivative\nWorks thereof.\n\n\"Contribution\" shall mean any work of authorship, including the original\nversion of the Work and any modifications or additions to that Work or\nDerivative Works thereof, that is intentionally submitted to Licensor for\ninclusion in the Work by the copyright owner or by an individual or Legal\nEntity authorized to submit on behalf of the copyright owner. For the\npurposes of this definition, \"submitted\" means any form of electronic, verbal,\nor written communication sent to the Licensor or its representatives,\nincluding but not limited to communication on electronic mailing lists, source\ncode control systems, and issue tracking systems that are managed by, or on\nbehalf of, the Licensor for the purpose of discussing and improving the Work,\nbut excluding communication that is conspicuously marked or otherwise\ndesignated in writing by the copyright owner as \"Not a Contribution.\"\n\n\"Contributor\" shall mean Licensor and any individual or Legal Entity on\nbehalf of whom a Contribution has been received by Licensor and subsequently\nincorporated within the Work.\n\n2. Grant of Copyright License. Subject to the terms and conditions of this\nLicense, each Contributor hereby grants to You a perpetual, worldwide,\nnon-exclusive, no-charge, royalty-free, irrevocable copyright license to\nreproduce, prepare Derivative Works of, publicly display, publicly perform,\nsublicense, and distribute the Work and such Derivative Works in Source or\nObject form.\n\n3. Grant of Patent License. Subject to the terms and conditions of this\nLicense, each Contributor hereby grants to You a perpetual, worldwide,\nnon-exclusive, no-charge, royalty-free, irrevocable (except as stated in this\nsection) patent license to make, have made, use, offer to sell, sell, import,\nand otherwise transfer the Work, where such license applies only to those\npatent claims licensable by such Contributor that are necessarily infringed by\ntheir Contribution(s) alone or by combination of their Contribution(s) with\nthe Work to which such Contribution(s) was submitted. If You institute patent\nlitigation against any entity (including a cross-claim or counterclaim in a\nlawsuit) alleging that the Work or a Contribution incorporated within the Work\nconstitutes direct or contributory patent infringement, then any patent\nlicenses granted to You under this License for that Work shall terminate as of\nthe date such litigation is filed.\n\n4. Redistribution. You may reproduce and distribute copies of the Work or\nDerivative Works thereof in any medium, with or without modifications, and in\nSource or Object form, provided that You meet the following conditions:\n\n(a) You must give any other recipients of the Work or Derivative Works a copy\nof this License; and\n\n(b) You must cause any modified files to carry prominent notices stating that\nYou changed the files; and\n\n(c) You must retain, in the Source form of any Derivative Works that You\ndistribute, all copyright, patent, trademark, and attribution notices from\nthe Source form of the Work, excluding those notices that do not pertain to\nany part of the Derivative Works; and\n\n(d) If the Work includes a \"NOTICE\" text file as part of its distribution,\nthen any Derivative Works that You distribute must include a readable copy of\nthe attribution notices contained within such NOTICE file, excluding those\nnotices that do not pertain to any part of the Derivative Works, in at least\none of the following places: within a NOTICE text file distributed as part of\nthe Derivative Works; within the Source form or documentation, if provided\nalong with the Derivative Works; or, within a display generated by the\nDerivative Works, if and wherever such third-party notices normally appear.\nThe contents of the NOTICE file are for informational purposes only and do not\nmodify the License. You may add Your own attribution notices within Derivative\nWorks that You distribute, alongside or as an addendum to the NOTICE text from\nthe Work, provided that such additional attribution notices cannot be\nconstrued as modifying the License.\n\nYou may add Your own copyright statement to Your modifications and may provide\nadditional or different license terms and conditions for use, reproduction, or\ndistribution of Your modifications, or for any such Derivative Works as a\nwhole, provided Your use, reproduction, and distribution of the Work otherwise\ncomplies with the conditions stated in this License.\n\n5. Submission of Contributions. Unless You explicitly state otherwise, any\nContribution intentionally submitted for inclusion in the Work by You to the\nLicensor shall be under the terms and conditions of this License, without any\nadditional terms or conditions. Notwithstanding the above, nothing herein\nshall supersede or modify the terms of any separate license agreement you may\nhave executed with Licensor regarding such Contributions.\n\n6. Trademarks. This License does not grant permission to use the trade names,\ntrademarks, service marks, or product names of the Licensor, except as\nrequired for reasonable and customary use in describing the origin of the Work\nand reproducing the content of the NOTICE file.\n\n7. Disclaimer of Warranty. Unless required by applicable law or agreed to in\nwriting, Licensor provides the Work (and each Contributor provides its\nContributions) on an \"AS IS\" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY\nKIND, either express or implied, including, without limitation, any warranties\nor conditions of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A\nPARTICULAR PURPOSE. You are solely responsible for determining the\nappropriateness of using or redistributing the Work and assume any risks\nassociated with Your exercise of permissions under this License.\n\n8. Limitation of Liability. In no event and under no legal theory, whether in\ntort (including negligence), contract, or otherwise, unless required by\napplicable law (such as deliberate and grossly negligent acts) or agreed to in\nwriting, shall any Contributor be liable to You for damages, including any\ndirect, indirect, special, incidental, or consequential damages of any\ncharacter arising as a result of this License or out of the use or inability to\nuse the Work (including but not limited to damages for loss of goodwill, work\nstoppage, computer failure or malfunction, or any and all other commercial\ndamages or losses), even if such Contributor has been advised of the\npossibility of such damages.\n\n9. Accepting Warranty or Additional Liability. While redistributing the Work\nor Derivative Works thereof, You may choose to offer, and charge a fee for,\nacceptance of support, warranty, indemnity, or other liability obligations\nand/or rights consistent with this License. However, in accepting such\nobligations, You may act only on Your own behalf and on Your sole\nresponsibility, not on behalf of any other Contributor, and only if You agree\nto indemnify, defend, and hold each Contributor harmless for any liability\nincurred by, or claims asserted against, such Contributor by reason of your\naccepting any such warranty or additional liability.\n\nEND OF TERMS AND CONDITIONS\n\nArchive v0.8.0: 5 files, 16602 bytes\n\nFiles: CHANGELOG.md (4795b), LICENSE.txt (9157b), skill-card.md (2769b), SKILL.md (20200b), _meta.json (131b)\n\nFile v0.8.0:SKILL.md\n\n---\nname: update-skill\ndescription: \"Thorough on-demand refresh of one skill in a skills repository: researches usage/upstream/docs in parallel, gates twice for approval, bumps version, updates CHANGELOG, runs the repo's validation, then commits and watches CI. Install the pond MCP (https://pond.cascade.fyi/) for the prior-session usage angle; without it that angle is skipped. Use to update, refresh, or check the freshness of a specific skill.\"\nargument-hint: \"[skill-name]\"\ndisable-model-invocation: true\nmetadata:\n version: \"0.8.0\"\n upstream: \"keep-a-changelog@2.0.0\"\n---\n\n# Update Skill\n\nRun a thorough on-demand refresh of one skill in a skills repository. Two hard human-approval gates ensure no edits or commits happen without explicit confirmation.\n\nThe target skill is: $ARGUMENTS\n\nIf no argument was provided, run `ls ${CLAUDE_PROJECT_DIR}/skills/` and ask the user which to update. Stop until confirmed. Then verify `${CLAUDE_PROJECT_DIR}/skills/$ARGUMENTS/SKILL.md` exists; if not, list skills and ask again. Throughout this run, `` refers to the resolved skill name.\n\n## Operating rules\n\nThese rules apply across all phases:\n\n- **GATE 1 stops before any edit.** Do NOT call Edit or Write until the user replies affirmatively to the GATE 1 banner.\n- **GATE 2 stops before any commit or push.** Do NOT run `git commit` or `git push` until the user replies affirmatively to the GATE 2 banner.\n- **Privacy scan is a hard blocker.** Skills in a public repo can publish on merge, so the run does not reach a commit while a Phase 6 leak finding is unresolved.\n- **Sticky posture.** Once GATE 1 has been emitted, \"report findings first\" persists across follow-up rounds in the same session. If the user replies `changes` or asks for revisions, re-emit the gate after revising; never silently apply.\n- **Non-resume.** If the session is interrupted between GATE 1 and GATE 2, re-run `/update-skill ` from scratch. There is no checkpoint or resume mechanism.\n- **Duplicate triggers.** If a scheduled task or a repeated invocation fires while a run is holding at a gate, hold at the emitted gate and answer from the existing report - never redo research or re-apply edits.\n- **No `--no-verify`, no `--amend`, no force-push** unless the user explicitly authorizes it for this run. Per the repo's CLAUDE.md or AGENTS.md.\n- **Working directory.** Every path, every `just check`, and every working git command (`status`/`diff`/`add`/`commit`/`push`) in the phases below runs against `` - the worktree created in Phase 0 if the user opted in, otherwise `${CLAUDE_PROJECT_DIR}`. Use absolute paths under ``; do not mix in the main checkout once a worktree is chosen. The exception is Phase 0's own `git worktree add`/`remove`, which must run against `${CLAUDE_PROJECT_DIR}` (the main checkout).\n\n## Phase 0 - Worktree choice (ask first)\n\nAfter resolving ``, ask exactly once: \"Run this update in a dedicated git worktree, so you can update other skills in parallel? (yes / no)\". Wait for the reply.\n\n- **no** (default) -> set `` = `${CLAUDE_PROJECT_DIR}` and proceed to Phase 1 in the current checkout.\n- **yes** -> create an isolated worktree on a fresh branch and use it as `` for the entire run:\n ```bash\n git -C \"${CLAUDE_PROJECT_DIR}\" worktree add \"${CLAUDE_PROJECT_DIR}/../skills-\" -b chore/update-\n ```\n Set `` = `${CLAUDE_PROJECT_DIR}/../skills-`. If that path or branch already exists, add the same numeric suffix (`-2`, `-3`, ...) to both the worktree path and the branch name until both are free, and carry that suffix into ``. Every later phase - reads, edits, `just check`, diff review, commit, push - operates inside ``. The Phase 7 branch guard will see `chore/update-` and route to the push + PR flow automatically. Keep the worktree until the PR is **merged** - follow-up review rounds reuse it instead of recreating it. Then clean up in order: `git -C \"${CLAUDE_PROJECT_DIR}\" worktree remove \"\"` first, then delete the branch (`git branch -d chore/update-`) - a branch delete fails while a worktree still holds the branch. `git worktree remove` refuses if there are uncommitted changes (leave it in place and tell the user if so); `git worktree prune` clears stale entries left by interrupted runs. If a generated file (e.g. `README.md`) conflicts when the PR falls behind the default branch, rebase and re-run the generator - never hand-merge generated output. If the user aborts before a PR exists, remove the worktree and delete the branch the same way.\n\n## Phase 1 - Pre-flight read\n\nRead every file in `skills//` end-to-end, in parallel:\n- `skills//SKILL.md`\n- All files under `skills//references/` (use Glob first to enumerate)\n- `skills//CHANGELOG.md` (if present)\n\nCapture state for the rest of the run:\n- `metadata.version` (current)\n- `metadata.upstream` (current; parse to `{name: version}` map; empty if absent)\n- Topmost CHANGELOG entry date (if `CHANGELOG.md` exists; this is the \"last verified\" signal)\n- `git log -1 --format=%cs -- skills//` date (last touch)\n- `LICENSE.txt` (or the repo's equivalent) present and non-empty - publish pipelines and repo linters commonly hard-fail without it; if missing, queue a fix row in the Phase 3 report\n- `bootstrap_needed` flag = true if `metadata.upstream` is missing OR `CHANGELOG.md` is missing - **unless the skill is upstreamless by nature** (it wraps no package, spec, or living doc - e.g. a workflow or writing skill like `polish`). For those, omitting `metadata.upstream` is correct, not a gap: derive `bootstrap_needed` from the missing `CHANGELOG.md` alone and skip the upstream-candidate proposal.\n\n## Phase 2 - Parallel research\n\nDispatch three research subagents in a single message, one per angle. Subagents run in the background by default (Claude Code v2.1.198+): collect every agent's completion before starting Phase 3. If the user supplied a seed finding (a bug they hit, a release they know about), pass it verbatim to the relevant agent - specific leads converge fastest. **Adapt each angle to the skill**: a skill wrapping a package researches that package's releases and source; a skill tracking living docs or a spec researches those docs and their source repos; a skill with no upstream at all still gets the usage angle.\n\n- **Usage** (pond - optional): if the pond MCP (`mcp__pond__pond_search`) is available, mine it with NO `project` filter for footguns, scenario-specific breakage, inefficiencies, gaps, and recurring misunderstandings the skill could absorb. Keep the query semantic (concepts, not project names); scope with filters. These are **advisory leads, not facts** - never verified, ground-checked in Phase 3. **If pond is not installed, skip this angle entirely** - dispatch only the upstream and docs agents, and note \"Usage angle skipped: pond MCP not available (https://pond.cascade.fyi/)\" in the Phase 3 report.\n- **Upstream**: releases, commits, and merged PRs since the last-verified date. Read real source - clone to a local scratch dir (e.g. `~/pjv//`, lowercase) or use the GitHub MCP pinned to a concrete tag/SHA. For skills wrapping a CLI, also ground-truth against the live installed binary (` --help`, real invocations) - docs and clones lag shipped behavior.\n- **Docs**: the current canonical docs, read from source (raw `.md` or cloned repo), not model-summarized. Two distinct jobs, **both required**:\n - **(a) Drift check** - compare the docs against the skill's current `SKILL.md` and `references/`, flagging API changes, deprecated or removed symbols, and patterns the skill should adopt. This is anchored to what the skill already says.\n - **(b) Coverage sweep** - enumerate upstream's *current* feature/concept surface from the docs nav / table of contents, the API index, and the \"what's new\" / changelog. List every major capability, primitive, or concept the skill has **zero mention of**. Do NOT anchor this to existing skill content - the whole point is to find net-new surface the skill is silent about (`ADD` findings). This is the step a \"verify what's there\" pass structurally misses.\n\nEvery finding is one bulleted line: `[KIND]` (`ADD`/`CHANGE`/`DEPRECATE`/`REMOVE`/`FIX`/`SECURITY`), a one-line summary, an exact quote from the source (no paraphrase), and a citation. pond findings also carry `status: advisory`. Merge all returns into one list, deduped by `(KIND, citation)`.\n\n## Phase 3 - Verify, report, GATE 1\n\n### Ground-truth verification (before the report)\n\nNo row ships unverified. Before a finding becomes a row, confirm it against primary source read **today**:\n\n- Verify the finding's claim **and the existing skill text it touches** - links, enumerated lists, pinned versions, version-coupled examples. Spot-check the skill's other upstream-coupled claims even where no finding landed; silent staleness is the common miss.\n- A row asserting upstream state (a bug, API shape, version, behavior) cites the primary source checked - cloned `repo@SHA file:line`, a release, or a docs URL; a pond citation alone is insufficient, so re-ground it or drop it. A row that is purely experiential enrichment (a recurring gap or confusion) may keep its pond citation, but verify the wording you write is technically correct.\n- Drop a pond-reported bug already fixed upstream; correct any finding whose pond framing the source contradicts.\n- **Coverage-gap rows** (net-new concepts from the Phase 2(b) sweep) are verified two ways: confirm the concept exists in today's source (cite it), **and** confirm the skill genuinely omits it - grep the skill for the concept and any synonyms before claiming it's absent, so a renamed-but-present feature isn't reported as missing.\n- Scope-check every usage-derived row: a learning about private infrastructure (internal hosts, personal tooling, machine-specific setups) belongs in the user's own CLAUDE.md or memory, not a public skill. Route it there and drop the row - the Phase 6 leak scan cannot make this judgment call.\n\n### Report\n\nPrint a structured report, sections in order:\n\n1. **Tracked packages diff** - `package | pinned | latest | delta`, or \"no upstream packages tracked.\"\n2. **Proposed `metadata.upstream`** - the new flat string. No floating tags (`@latest`/`@next`/`@beta`/`@canary`); pin to a concrete tag or SHA.\n3. **Proposed CHANGELOG entry** - a Keep a Changelog block ready to commit.\n4. **Proposed edits** - one row per smallest atomic change, each with a stable ID (`A1`/`C1`/`D1`/`R1`/`F1`/`S1`...): ` | target file | one-line summary | citation`. Batch trivially-related changes into one row; past ~20 rows, consider whether the skill needs a rewrite rather than a patch. When ADD rows are numerous, include the projected post-apply `SKILL.md` line count; if it would cross the repo's size cap (500 lines in this repo), plan the `references/` split as part of the proposal, not as a surprise after apply.\n5. **New-concept coverage** (**always present, never omitted**) - the result of the Phase 2(b) coverage sweep. Either a table of net-new upstream concepts the skill omits (each becoming an `ADD` row above), or the explicit statement that there are none. End this section with the verbatim attestation below. Coverage need not be complete to pass - but any gap in what you could enumerate (JS-gated docs, rate limits, unreachable pages) must be named here, not silently dropped:\n ```\n Coverage sweep: enumerated upstream's current surface from . Net-new concepts the skill omits: / none since . Not reachable this run: .\n ```\n6. **Bootstrap proposal** (only when `bootstrap_needed`): candidate upstream packages greppable from the skill's content, each as ` (mentioned x, first cite: :)` for the user to confirm or prune; plus a seed `CHANGELOG.md`. Propose only upstreams whose releases would invalidate the skill's content - the package, spec, or living doc the skill teaches. A tool mentioned incidentally (a validator run once, a CLI in one example) is not an upstream candidate. If the skill is **upstreamless by nature**, say so explicitly, propose no candidates, and leave `metadata.upstream` omitted - only seed the `CHANGELOG.md`.\n\n### No-op short-circuit\n\nIf sections 1-4 yield zero rows AND the Phase 2(b) coverage sweep found no omitted concepts (section 5 attestation says \"none\") AND `bootstrap_needed` is false, print this verbatim and exit cleanly - no file changes, no commit. Never short-circuit without the section 5 attestation present:\n\n```\nAll current as of . Last verified per CHANGELOG.md on against .\n```\n\n### CHANGELOG format\n\n[Keep a Changelog](https://keepachangelog.com/en/2.0.0/) format. The dated entry uses only the sections it has content for (Added / Changed / Deprecated / Removed / Fixed / Security), plus a `Verified against: ` trailer **only if** a tracked package version actually changed this run. Mark breaking changes inside Changed/Removed with a leading `**Breaking:**` marker, and pin the KaC link in preambles to the version followed (both per KaC 2.0.0).\n\nWhen `bootstrap_needed`, create the full file with this header:\n\n```markdown\n# Changelog\n\nAll notable changes to this skill will be documented in this file.\n\nThe format is based on [Keep a Changelog](https://keepachangelog.com/en/2.0.0/),\nand this skill adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).\n\n## [Unreleased]\n\n## [] - \n- Initial CHANGELOG; tracking established.\n```\n\n### GATE 1 banner (verbatim)\n\n```\nGATE 1 - APPROVE TO EDIT? (yes / yes / drop / changes / no)\n```\n\nReply parsing:\n- `yes` / `yes all` -> apply every row\n- `yes A1-A4 C1` -> apply only those rows (and the listed package version updates, if any)\n- `drop D1,R2` -> apply everything except those\n- `changes ` -> revise the report and re-emit GATE 1\n- `no` -> abort, no changes\n\nDo NOT call Edit or Write until you receive an affirmative. Every revision round re-emits GATE 1; never silently apply.\n\n## Phase 4 - Apply\n\nApply each approved row with Edit/Write; batch independent edits in parallel. Then, in order:\n\n1. Update `metadata.upstream` to the new comma-separated `@` list. Reject floating tags - stop with an error if one appears. Skip entirely if the skill is upstreamless by nature - leave `metadata.upstream` omitted.\n2. Bump `metadata.version` (semver per the repo's CLAUDE.md or AGENTS.md: patch for fixes, minor for new content/sections, major for breaking removal).\n3. Append the new dated entry to `CHANGELOG.md` directly under `[Unreleased]`, above the previous entry. Add the `Verified against:` trailer only if a tracked version changed this run.\n4. If `bootstrap_needed`, write the full `CHANGELOG.md` from the bootstrap header plus the approved seed entry.\n5. When pasting upstream doc examples into a `SKILL.md` body, never let a `!` at line start or after whitespace directly touch a backticked command - Claude Code executes it at skill load, even inside code fences, and repo linters may reject it. Keep such examples in `references/` or break the adjacency.\n6. Check the post-apply `SKILL.md` line count against the repo's cap (500 here); if crossed, execute the `references/` split planned in Phase 3.\n\n## Phase 5 - Repo validation gate\n\nIf the repo defines a validation command - check its CLAUDE.md/AGENTS.md or `Justfile`/`package.json` (e.g. `just check`, `npm run lint`, `make check`) - run it from `` (the repo root, or the Phase 0 worktree). In this repo that is `just check`, which also regenerates `README.md` (the most common CI failure cause). On failure, surface the error verbatim, fix the root cause, and re-run until clean. If the failure looks unrelated to this run's edits, attribute before debugging: stash the changes (`git stash -u`) and re-run the gate on a clean tree. Failing identically means the breakage is pre-existing (an environment flake or repo issue) - unstash, report it to the user, and don't sink this run into debugging it. No `--no-verify`, no `--amend`, no hook-skipping. If the repo has no validation gate, skip this phase and note it.\n\n## Phase 6 - Privacy scan + diff review + GATE 2\n\n### Privacy / leak scan (hard blocker)\n\nSkills in a public repo can publish on merge, and any research source can leak into the diff - especially pond, which draws on private cross-project conversations. This scan runs every time, whether or not pond was used. Before showing the diff, dispatch a dedicated agent (separate from the Phase 2 research agents) to scan the added/changed lines **and every new untracked file** under `skills//` and `README.md` (if the repo generates one). `git diff` alone misses brand-new files (e.g. a fresh `references/` doc) - enumerate them with `git status --porcelain` and give the agent their full content.\n\nIt flags anything unsafe for a public skill: secrets (keys, tokens, passwords, `.env` values, connection strings), personal data (real names, emails, handles), and the easy-to-miss ones - non-public project or repo names, internal hostnames or endpoints, ticket IDs, local machine paths, pond session IDs. Intentional public references are fine (the public repo owner, official upstream repos and docs, published package names, spec URLs). The agent returns `[LEAK] : - - suggested redaction: ` per issue, or exactly `NO LEAKS FOUND`.\n\nAn unresolved `[LEAK]` is a hard blocker: redact each finding, re-run the scan, and repeat until clean before GATE 2. Hold the commit message to the same public-safe standard.\n\n### Diff review\n\nPrint `git status`, `git diff --stat`, and per-file diffs for `SKILL.md`, every changed `references/` file, `CHANGELOG.md`, and `README.md`. Then print this recovery hint verbatim, immediately above the gate banner:\n\n```\nTo discard everything: git restore . && git clean -fd skills//\n```\n\n```\nGATE 2 - APPROVE COMMIT + PUSH? (yes / no)\n```\n\nWait for explicit confirmation. Do not commit on ambiguous responses.\n\n## Phase 7 - Commit, push, watch\n\n**Branch guard first.** Run `git rev-parse --abbrev-ref HEAD`. If the result is not the repo's default branch, ask the user: push to the current branch and open a PR (recommended), push directly to the default branch (only on explicit instruction - if the repo auto-publishes on merge, this skips PR review and ships straight to the registry), or cancel.\n\nCommit with a conventional-commit message (type per content, per the repo's CLAUDE.md or AGENTS.md) using the HEREDOC pattern:\n\n```bash\ngit commit -m \"$(cat <<'EOF'\n(): \n\n\nEOF\n)\"\n```\n\n- **On the default branch**: `git push`, then, if the repo has CI, `gh run watch` the triggered run. On CI failure, surface logs verbatim; do not auto-retry.\n- **On a feature branch**: `git push -u origin `, then `gh pr create` with a body summarizing the Phase 3 report. Skip `gh run watch` at this point - PR CI is typically non-publishing, and some publish-on-merge repos run no PR CI at all. The run is not done at PR creation: once the PR merges, watch the default-branch publish run (`gh run watch`), confirm the publish landed, then do the Phase 0 cleanup (worktree first, then branch).\n\nUpdating several skills in one session? Land them together: batch into one push, or merge the PRs back-to-back and watch only the final publish run - each push to the default branch typically triggers a full republish.\n\nIf the repo auto-publishes on merge (e.g. to a registry via CI), confirm the publish landed once CI is green. The published slug and release/tag naming follow the repo's own pipeline - check its CLAUDE.md/AGENTS.md (the published slug can differ from the folder name).\n\n## Done\n\nReport a one-line summary to the user: skill name, version delta, tracked packages updated, CI status. If the repo's skills are consumed through an installer (e.g. `npx skills`), remind the user to refresh installed copies (`npx skills update `) once the publish lands.\n\nFile v0.8.0:_meta.json\n\n{\n \"ownerId\": \"kn76gpsgjw5chv0xvzbzcb8cxn81x46r\",\n \"slug\": \"update-skill\",\n \"version\": \"0.8.0\",\n \"publishedAt\": 1783691498647\n}\n\nFile v0.8.0:CHANGELOG.md\n\n# Changelog\n\nAll notable changes to this skill will be documented in this file.\n\nThe format is based on [Keep a Changelog](https://keepachangelog.com/en/2.0.0/),\nand this skill adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).\n\n## [Unreleased]\n\n## [0.8.0] - 2026-07-10\n\n### Added\n- Worktree lifecycle hardening from real runs: keep the worktree until the PR merges (follow-up rounds reuse it), remove the worktree before deleting its branch, `git worktree prune` for stale entries, and regenerate (never hand-merge) generated-file conflicts like README.md on rebase.\n- Phase 3 line-budget planning: report the projected SKILL.md size when additive rows land and plan a references/ split when it would exceed the repo's cap.\n- Phase 5 failure-attribution step: when the validation gate fails in a way unrelated to the edits, stash and re-run on a clean tree before debugging.\n- Phase 3 public-vs-private scope call on usage-derived findings: private-infra learnings go to user memory/CLAUDE.md, never the public skill.\n- Phase 2 research inputs: ground-truth CLI-wrapping skills against the live installed CLI, and accept user-supplied seed findings as explicit leads.\n- Operating rule for duplicate/scheduled triggers firing mid-run: hold at the emitted gate, never redo research.\n- Phase 4 authoring caution: never let a `!` at line start or after whitespace directly touch a backticked command in SKILL.md bodies (Claude Code executes it at load, even in code fences).\n- Phase 1 pre-flight now verifies LICENSE.txt presence; Done phase reminds to propagate published updates to installed copies; Phase 7 batches multi-skill updates into one push when CI republishes per push.\n- `metadata.upstream` now tracks `keep-a-changelog@2.0.0` - the spec the skill embeds a template of, whose releases invalidate content (proven this run).\n\n### Changed\n- Keep a Changelog citations and the bootstrap header template moved from 1.1.0 to 2.0.0 (six change types and dates unchanged; adds the `**Breaking:**` marker convention and version-pinned format links).\n- Phase 2 notes subagents run in the background by default (Claude Code v2.1.198+): collect all completions before Phase 3.\n- Phase 7 feature-branch flow now follows through merge: watch the default-branch publish CI after the PR merges (some repos have no PR CI at all), then clean up branch and worktree.\n\n### Fixed\n- Bootstrap upstream proposal no longer promotes incidentally-mentioned tools: candidates must be things whose releases would invalidate the skill's content.\n- Phase 6 leak scan explicitly covers untracked new files, which `git diff` misses.\n\nVerified against: keep-a-changelog@2.0.0\n\n## [0.7.0] - 2026-06-16\n\n### Added\n- Phase 0 worktree choice: the run now asks once whether to operate in a dedicated git worktree (`git worktree add ... -b chore/update-`), enabling parallel updates of multiple skills without README/index/diff contention. All phases operate against a new `` variable (the worktree if chosen, else `${CLAUDE_PROJECT_DIR}`); the existing Phase 7 branch guard handles the resulting feature-branch PR flow, and the worktree is removed after the run.\n\n## [0.6.0] - 2026-06-05\n\n### Added\n- Restored the `argument-hint: \"[skill-name]\"` frontmatter field removed in 0.5.0. It is a valid, functional Claude Code field for user-invoked skills (used in Anthropic's own `skills//SKILL.md` examples) and is documented in this repo's `skills-best-practices`; it is simply outside the open Agent Skills spec, which ignores unknown fields.\n\n### Fixed\n- Aligned the repo linter (`scripts/check_skills.py`) with the optional Claude Code skill/command fields documented in `skills-best-practices` (`argument-hint`, `when_to_use`, `arguments`, `model`, `effort`, `context`, `agent`, `hooks`). The previous allowlist rejected fields the repo's own guidance endorses.\n\n## [0.5.0] - 2026-06-05\n\n### Added\n- Apache-2.0 `LICENSE.txt` (required for publishing).\n- Upstreamless-by-nature escape hatch: skills that wrap no package/spec/doc (workflow or writing skills) cleanly omit `metadata.upstream` and skip the bootstrap upstream-candidate proposal instead of being nagged.\n\n### Changed\n- Generalized for use in any skills repository. The pond usage angle is now optional with an explicit skip-and-fallback when the pond MCP is absent (https://pond.cascade.fyi/). Phase 5 reframed as a repo-agnostic validation gate, and Phase 7 defers publish/slug/release-tag specifics to the repo's own pipeline (CLAUDE.md/AGENTS.md) instead of hardcoding this repo's ClawHub scripts and release-tag naming.\n\n### Removed\n- `argument-hint` frontmatter field to pass the repo's lint allowlist (restored in 0.6.0 once the allowlist was corrected; the body already handles the no-argument case regardless).\n\nFile v0.8.0:skill-card.md\n\n## Description:
\nRefreshes a selected skill by researching upstream and documentation changes, presenting proposed edits behind approval gates, updating changelog and version metadata, running validation, and preparing commit and CI follow-through.
\n\nThis skill is ready for commercial/non-commercial use.
\n\n## Publisher:
\n[tenequm](https://clawhub.ai/user/tenequm)
\n\n### License/Terms of Use:
\nApache 2.0
\n\n\n## Use Case:
\nDevelopers and maintainers use this skill to refresh a specific agent skill against current upstream and documentation signals, review proposed changes, update release metadata, validate the repository, and prepare a reviewed commit or pull request.
\n\n### Deployment Geography for Use:
\nGlobal
\n\n## Known Risks and Mitigations:
\nRisk: The skill can modify skill files and release metadata in a repository after approval, which may affect published behavior.
\nMitigation: Use the built-in GATE 1 and GATE 2 approval points, review the proposed edits and final diff, and run the repository validation gate before committing or pushing.
\nRisk: Optional prior-session usage research can introduce private, irrelevant, or misleading context into a public skill update.
\nMitigation: Skip the usage angle when pond is unavailable, treat usage findings as advisory, scope-check them for public suitability, and complete the privacy/leak scan before commit.
\nRisk: Branch, worktree, push, and CI actions may publish changes through repository automation if approved without sufficient review.
\nMitigation: Confirm the branch and push path at GATE 2, avoid direct default-branch pushes unless intentional, and watch the relevant CI or publish run after approval.
\n\n\n## Reference(s):
\n- [ClawHub skill page](https://clawhub.ai/tenequm/skills/update-skill)
\n- [Pond MCP](https://pond.cascade.fyi/)
\n- [Keep a Changelog 2.0.0](https://keepachangelog.com/en/2.0.0/)
\n- [Semantic Versioning 2.0.0](https://semver.org/spec/v2.0.0.html)
\n\n\n## Skill Output:
\n**Output Type(s):** [Text, Markdown, Code, Shell commands, Configuration, Guidance]
\n**Output Format:** [Markdown reports with inline shell commands and repository file edits]
\n**Output Parameters:** [1D]
\n**Other Properties Related to Output:** [Requires explicit user approval before edits and before commit or push.]
\n\n## Skill Version(s):
\n0.8.0 (source: frontmatter, changelog, server release metadata)
\n\n## Ethical Considerations:
\nUsers should evaluate whether this skill is appropriate for their environment, review any generated or modified files before relying on them, and apply their organization's safety, security, and compliance requirements before deployment.
\n\nFile v0.8.0:LICENSE.txt\n\nApache License\nVersion 2.0, January 2004\nhttps://www.apache.org/licenses/\n\nTERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION\n\n1. Definitions.\n\n\"License\" shall mean the terms and conditions for use, reproduction, and\ndistribution as defined by Sections 1 through 9 of this document.\n\n\"Licensor\" shall mean the copyright owner or entity authorized by the\ncopyright owner that is granting the License.\n\n\"Legal Entity\" shall mean the union of the acting entity and all other\nentities that control, are controlled by, or are under common control with\nthat entity. For the purposes of this definit\n\nArchive v0.7.0: 5 files, 13701 bytes\n\nFiles: CHANGELOG.md (2387b), LICENSE.txt (9157b), skill-card.md (2276b), SKILL.md (16252b), _meta.json (131b)\n\nArchive v0.6.0: 5 files, 12878 bytes\n\nFiles: CHANGELOG.md (1890b), LICENSE.txt (9157b), skill-card.md (2494b), SKILL.md (14484b), _meta.json (131b)\n\nArchive v0.5.0: 5 files, 12426 bytes\n\nFiles: CHANGELOG.md (1112b), LICENSE.txt (9157b), skill-card.md (2273b), SKILL.md (14454b), _meta.json (131b)","readmeExcerpt":"Skill: update-skill Owner: tenequm Summary: Thorough on-demand refresh of one skill in a skills repo - researches usage, upstream, and docs in parallel, gates twice for approval, bumps version, updates CHANGELOG, validates, commits, watches CI. Use to check a skill's freshness. Tags: latest:0.8.3 Version history: v0.8.3 | 2026-09-09T10:14:05.664Z | user Updated update-skill from 0.8.2 to 0.8.3. Changes: - modified CH","codeSnippets":[],"executableExamples":[{"language":"bash","snippet":"git -C \"${CLAUDE_PROJECT_DIR}\" worktree add \"${CLAUDE_PROJECT_DIR}/../skills-\" -b chore/update-"},{"language":"text","snippet":"Coverage sweep: enumerated upstream's current surface from . Net-new concepts the skill omits: / none since . Not reachable this run: ."},{"language":"text","snippet":"All current as of . Last verified per CHANGELOG.md on against ."},{"language":"markdown","snippet":"# Changelog\n\nAll notable changes to this skill will be documented in this file.\n\nThe format is based on [Keep a Changelog](https://keepachangelog.com/en/2.0.0/),\nand this skill adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).\n\n## [Unreleased]\n\n## [] - \n- Initial CHANGELOG; tracking established."},{"language":"text","snippet":"GATE 1 - APPROVE TO EDIT? (yes / yes / drop / changes / no)"},{"language":"text","snippet":"To discard everything: git restore . && git clean -fd skills//"}],"parameters":null,"dependencies":[],"permissions":[],"extractedFiles":[{"path":"SKILL.md","content":"---\nname: update-skill\ndescription: Thorough on-demand refresh of one skill in a skills repo - researches usage, upstream, and docs in parallel, gates twice for approval, bumps version, updates CHANGELOG, validates, commits, watches CI. Use to check a skill's freshness.\nargument-hint: \"[skill-name]\"\ndisable-model-invocation: true\nmetadata:\n version: \"0.8.3\"\n categories: \"agents, automation\"\n topics: \"skill-maintenance, versioning, changelog, research, agent-skills\"\n openclaw:\n homepage: https://github.com/tenequm/skills/tree/main/skills/update-skill\n emoji: \"🔄\"\n upstream: \"keep-a-changelog@2.0.0\"\n---\n\n# Update Skill\n\nRun a thorough on-demand refresh of one skill in a skills repository. Two hard human-approval gates ensure no edits or commits happen without explicit confirmation.\n\nThe target skill is: $ARGUMENTS\n\nIf no argument was provided, run `ls ${CLAUDE_PROJECT_DIR}/skills/` and ask the user which to update. Stop until confirmed. Then verify `${CLAUDE_PROJECT_DIR}/skills/$ARGUMENTS/SKILL.md` exists; if not, list skills and ask again. Throughout this run, `` refers to the resolved skill name.\n\n## Operating rules\n\nThese rules apply across all phases:\n\n- **GATE 1 stops before any edit.** Do NOT call Edit or Write until the user replies affirmatively to the GATE 1 banner.\n- **GATE 2 stops before any commit or push.** Do NOT run `git commit` or `git push` until the user replies affirmatively to the GATE 2 banner.\n- **Privacy scan is a hard blocker.** Skills in a public repo can publish on merge, so the run does not reach a commit while a Phase 6 leak finding is unresolved.\n- **Sticky posture.** Once GATE 1 has been emitted, \"report findings first\" persists across follow-up rounds in the same session. If the user replies `changes` or asks for revisions, re-emit the gate after revising; never silently apply.\n- **Non-resume.** If the session is interrupted between GATE 1 and GATE 2, re-run `/update-skill ` from scratch. There is no checkpoint or resume mechanism.\n- **Duplicate triggers.** If a scheduled task or a repeated invocation fires while a run is holding at a gate, hold at the emitted gate and answer from the existing report - never redo research or re-apply edits.\n- **No `--no-verify`, no `--amend`, no force-push** unless the user explicitly authorizes it for this run. Per the repo's CLAUDE.md or AGENTS.md.\n- **Working directory.** Every path, every `just check`, and every working git command (`status`/`diff`/`add`/`commit`/`push`) in the phases below runs against `` - the worktree created in Phase 0 if the user opted in, otherwise `${CLAUDE_PROJECT_DIR}`. Use absolute paths under ``; do not mix in the main checkout once a worktree is chosen. The exception is Phase 0's own `git worktree add`/`remove`, which must run against `${CLAUDE_PROJECT_DIR}` (the main checkout).\n\n## Phase 0 - Worktree choice (ask first)\n\nAfter resolving ``, ask exactly once: \"Run this update in a dedicated git worktree, so"},{"path":"_meta.json","content":"{\n \"ownerId\": \"kn76gpsgjw5chv0xvzbzcb8cxn81x46r\",\n \"slug\": \"update-skill\",\n \"version\": \"0.8.3\",\n \"publishedAt\": 1788948845664\n}"},{"path":"CHANGELOG.md","content":"# Changelog\n\nAll notable changes to this skill will be documented in this file.\n\nThe format is based on [Keep a Changelog](https://keepachangelog.com/en/2.0.0/),\nand this skill adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).\n\n## [Unreleased]\n\n## [0.8.3] - 2026-09-09\n\n### Changed\n- Description condensed to fit the repo's 250-character limit.\n\n## [0.8.2] - 2026-08-21\n\n### Changed\n\n- Declared ClawHub browse categories (`agents, automation`) and topics in `metadata`, so the release pipeline publishes them instead of leaving the skill in the `other` category.\n\n### Removed\n\n- `skill-card.md`. The ClawHub CLI strips a root `skill-card.md` from every publish and the registry generates its own card, so the authored file never reached ClawHub.\n\n## [0.8.1] - 2026-07-22\n\n### Added\n\n- skill-card.md release record following NVIDIA's skill-card format\n- metadata.openclaw block (emoji, homepage) for ClawHub display\n\n## [0.8.0] - 2026-07-10\n\n### Added\n- Worktree lifecycle hardening from real runs: keep the worktree until the PR merges (follow-up rounds reuse it), remove the worktree before deleting its branch, `git worktree prune` for stale entries, and regenerate (never hand-merge) generated-file conflicts like README.md on rebase.\n- Phase 3 line-budget planning: report the projected SKILL.md size when additive rows land and plan a references/ split when it would exceed the repo's cap.\n- Phase 5 failure-attribution step: when the validation gate fails in a way unrelated to the edits, stash and re-run on a clean tree before debugging.\n- Phase 3 public-vs-private scope call on usage-derived findings: private-infra learnings go to user memory/CLAUDE.md, never the public skill.\n- Phase 2 research inputs: ground-truth CLI-wrapping skills against the live installed CLI, and accept user-supplied seed findings as explicit leads.\n- Operating rule for duplicate/scheduled triggers firing mid-run: hold at the emitted gate, never redo research.\n- Phase 4 authoring caution: never let a `!` at line start or after whitespace directly touch a backticked command in SKILL.md bodies (Claude Code executes it at load, even in code fences).\n- Phase 1 pre-flight now verifies LICENSE.txt presence; Done phase reminds to propagate published updates to installed copies; Phase 7 batches multi-skill updates into one push when CI republishes per push.\n- `metadata.upstream` now tracks `keep-a-changelog@2.0.0` - the spec the skill embeds a template of, whose releases invalidate content (proven this run).\n\n### Changed\n- Keep a Changelog citations and the bootstrap header template moved from 1.1.0 to 2.0.0 (six change types and dates unchanged; adds the `**Breaking:**` marker convention and version-pinned format links).\n- Phase 2 notes subagents run in the background by default (Claude Code v2.1.198+): collect all completions before Phase 3.\n- Phase 7 feature-branch flow now follows through merge: watch the default-branch publish CI after the PR merges (some repos have no P"},{"path":"skill-card.md","content":"## Description:\n\nThorough on-demand refresh of one skill in a skills repo - researches usage, upstream, and docs in parallel, gates twice for approval, bumps version, updates CHANGELOG, validates, commits, watches CI. Use to check a skill's freshness.\n\nThis skill is ready for commercial/non-commercial use.\n\n## Publisher:\n\n[tenequm](https://clawhub.ai/user/tenequm)\n\n### License/Terms of Use:\n\nMIT-0\n\n## Use Case:\n\nDevelopers and maintainers use this skill to refresh a selected skill in a skills repository, review proposed updates, apply approved changes, update release notes, validate the repository, and prepare publication after explicit approval.\n\n### Deployment Geography for Use:\n\nGlobal\n\n## Known Risks and Mitigations:\n\nRisk: The skill gives an agent broad authority to edit, validate, commit, push, and potentially publish changes after approval prompts.\n\nMitigation: Install only in trusted skill repositories, use trusted skill names, and review proposed edits and diffs before approving GATE 1 or GATE 2.\n\nRisk: The skill can query cross-project conversation data through Pond without a project boundary.\n\nMitigation: Avoid or disable Pond research unless that search is explicitly intended, and keep public-scope and leak-scan review active before publication.\n\n## Reference(s):\n\n- [ClawHub skill page](https://clawhub.ai/tenequm/skills/update-skill)\n- [Project homepage](https://github.com/tenequm/skills/tree/main/skills/update-skill)\n\n## Skill Output:\n\n**Output Type(s):** [text, markdown, code, shell commands, configuration, guidance]\n\n**Output Format:** [Markdown reports, repository file edits, and shell command sequences]\n\n**Output Parameters:** [1D]\n\n**Other Properties Related to Output:** [Requires explicit human approval before edits and before commit or push.]\n\n## Skill Version(s):\n\n0.8.3 (source: frontmatter and server release evidence)\n\n## Ethical Considerations:\n\nUsers should evaluate whether this skill is appropriate for their environment, review any generated or modified files before relying on them, and apply their organization's safety, security, and compliance requirements before deployment."},{"path":"LICENSE.txt","content":"Apache License\nVersion 2.0, January 2004\nhttps://www.apache.org/licenses/\n\nTERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION\n\n1. Definitions.\n\n\"License\" shall mean the terms and conditions for use, reproduction, and\ndistribution as defined by Sections 1 through 9 of this document.\n\n\"Licensor\" shall mean the copyright owner or entity authorized by the\ncopyright owner that is granting the License.\n\n\"Legal Entity\" shall mean the union of the acting entity and all other\nentities that control, are controlled by, or are under common control with\nthat entity. For the purposes of this definition, \"control\" means (i) the\npower, direct or indirect, to cause the direction or management of such\nentity, whether by contract or otherwise, or (ii) ownership of fifty percent\n(50%) or more of the outstanding shares, or (iii) beneficial ownership of\nsuch entity.\n\n\"You\" (or \"Your\") shall mean an individual or Legal Entity exercising\npermissions granted by this License.\n\n\"Source\" form shall mean the preferred form for making modifications,\nincluding but not limited to software source code, documentation source, and\nconfiguration files.\n\n\"Object\" form shall mean any form resulting from mechanical transformation or\ntranslation of a Source form, including but not limited to compiled object\ncode, generated documentation, and conversions to other media types.\n\n\"Work\" shall mean the work of authorship, whether in Source or Object form,\nmade available under the License, as indicated by a copyright notice that is\nincluded in or attached to the work (an example is provided in the Appendix\nbelow).\n\n\"Derivative Works\" shall mean any work, whether in Source or Object form,\nthat is based on (or derived from) the Work and for which the editorial\nrevisions, annotations, elaborations, or other modifications represent, as a\nwhole, an original work of authorship. For the purposes of this License,\nDerivative Works shall not include works that remain separable from, or\nmerely link (or bind by name) to the interfaces of, the Work and Derivative\nWorks thereof.\n\n\"Contribution\" shall mean any work of authorship, including the original\nversion of the Work and any modifications or additions to that Work or\nDerivative Works thereof, that is intentionally submitted to Licensor for\ninclusion in the Work by the copyright owner or by an individual or Legal\nEntity authorized to submit on behalf of the copyright owner. For the\npurposes of this definition, \"submitted\" means any form of electronic, verbal,\nor written communication sent to the Licensor or its representatives,\nincluding but not limited to communication on electronic mailing lists, source\ncode control systems, and issue tracking systems that are managed by, or on\nbehalf of, the Licensor for the purpose of discussing and improving the Work,\nbut excluding communication that is conspicuously marked or otherwise\ndesignated in writing by the copyright owner as \"Not a Contribution.\"\n\n\"Contributor\" shall mean Licensor and any individ"}],"languages":[],"docsSourceLabel":"CLAWHUB","editorialOverview":null,"editorialQuality":{"score":100,"threshold":65,"status":"thin","wordCount":2143,"uniquenessScore":43,"reasons":["uniqueness-below-45"]}},"media":{"evidence":{"source":"no-media","verified":false,"confidence":"low","updatedAt":"2026-10-10T17:34:51.303Z","emptyReason":"No screenshots, media assets, or demo links are available."},"primaryImageUrl":null,"mediaAssetCount":0,"assets":[],"demoUrl":null},"ownerResources":{"evidence":{"source":"unclaimed","verified":false,"confidence":"low","updatedAt":"2026-10-10T17:34:51.303Z","emptyReason":"This page has not been claimed by the agent owner."},"hasCustomPage":false,"customPageUpdatedAt":null,"customLinks":[],"structuredLinks":{"docsUrl":null,"demoUrl":null,"supportUrl":null,"pricingUrl":null,"statusUrl":null},"customPage":null},"relatedAgents":{"evidence":{"source":"protocol-neighbors","verified":false,"confidence":"medium","updatedAt":"2026-10-10T21:43:22.575Z","emptyReason":null},"items":[{"id":"8ebccd8e-3863-4187-8355-c3f14e1f9edf","entityType":"agent","canonicalPath":"/agent/iofficeai-aionui","slug":"iofficeai-aionui","name":"AionUi","description":"Free, local, open-source 24/7 Cowork app and OpenClaw for Gemini CLI, Claude Code, Codex, OpenCode, Qwen Code, Goose CLI, Auggie, and more | 🌟 Star if you like it!","url":"https://github.com/iOfficeAI/AionUi","homepage":"https://www.aionui.com","source":"GITHUB_REPOS","protocols":["MCP","OPENCLAW"],"capabilities":[],"safetyScore":100,"overallRank":70,"updatedAt":"2026-10-09T19:11:12.944Z","createdAt":"2026-02-25T03:38:16.584Z","downloads":null},{"id":"b917f68a-ebff-438e-84f8-3f4b2494c0bc","entityType":"agent","canonicalPath":"/agent/activepieces-activepieces","slug":"activepieces-activepieces","name":"activepieces","description":"AI Agents & MCPs & AI Workflow Automation • (~400 MCP servers for AI agents) • AI Automation / AI Agent with MCPs • AI Workflows & AI Agents • MCPs for AI Agents","url":"https://github.com/activepieces/activepieces","homepage":"https://www.activepieces.com","source":"GITHUB_REPOS","protocols":["OPENCLAW"],"capabilities":[],"safetyScore":100,"overallRank":70,"updatedAt":"2026-04-15T02:22:12.426Z","createdAt":"2026-02-25T03:38:12.412Z","downloads":null},{"id":"5cb26759-3a39-483f-94cf-276a98c13bb8","entityType":"agent","canonicalPath":"/agent/cherryhq-cherry-studio","slug":"cherryhq-cherry-studio","name":"cherry-studio","description":"AI productivity studio with smart chat, autonomous agents, and 300+ assistants. Unified access to frontier LLMs","url":"https://github.com/CherryHQ/cherry-studio","homepage":"https://cherry-ai.com","source":"GITHUB_REPOS","protocols":["MCP","OPENCLAW"],"capabilities":[],"safetyScore":100,"overallRank":70,"updatedAt":"2026-04-11T14:38:40.986Z","createdAt":"2026-02-25T03:38:19.379Z","downloads":null},{"id":"6f6582d0-5d76-4f0f-b81d-86520247950b","entityType":"agent","canonicalPath":"/agent/copilotkit-copilotkit","slug":"copilotkit-copilotkit","name":"CopilotKit","description":"The Frontend for Agents & Generative UI. React + Angular","url":"https://github.com/CopilotKit/CopilotKit","homepage":"https://docs.copilotkit.ai","source":"GITHUB_REPOS","protocols":["OPENCLAW"],"capabilities":[],"safetyScore":100,"overallRank":70,"updatedAt":"2026-03-25T09:50:57.846Z","createdAt":"2026-02-25T03:39:14.617Z","downloads":null}],"links":{"hub":"/agent","source":"/agent/source/clawhub","protocols":[{"label":"OpenClaw","href":"/agent/protocol/openclew"}]}}}