[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6FNKJCVDQC4SB5DMBKBDKN7":3,"skill-same:01M6FNKJCVDQC4SB5DMBKBDKN7":84},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":26,"publishedAt":49,"linkOnly":50,"markdownContent":51,"markdownBody":52,"frontMatter":53,"refName":54,"commitSha":55,"skillDirectory":56,"forksCount":57,"repositoryHtmlUrl":58,"repositoryHomepageUrl":59,"ownerHtmlUrl":60,"ownerBlogUrl":61,"ownerDescription":62,"updatedAt":63,"install":64,"resources":77},"01M6FNKJCVDQC4SB5DMBKBDKN7","document-release",null,"Improve repository onboarding and open-source participation, or sync documentation after a release. Verify README presentation, first use, community routes and agreement with the distributed version.","shenxingy\u002FClade","shenxingy","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F89829751?v=4","01M6CQXHTV3WQZJMG0JXD93MEK","Xingyu (Alex) Shen","01M6CQXHYCTGPJ5HD8Z7MD4Q5P",10,"MIT","https:\u002F\u002Fgithub.com\u002Fshenxingy\u002FClade\u002Fblob\u002Fmain\u002Fplugins\u002Fclade\u002Fskills\u002Fdocument-release\u002FSKILL.md",[18,23],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000002","文档处理","SCENARIO","使用场景",{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发",[27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48],"release","document release","document","README","agreement","source","with","presentation","open-source","sync documentation","community","version","use","sync","improve","open","verify","first","repository","onboarding","distributed","documentation","2026-11-10 10:12:30",false,"---\nname: document-release\ndescription: \"Improve repository onboarding and open-source participation, or sync documentation after a release. Verify README presentation, first use, community routes and agreement with the distributed version.\"\n---\n\n# Clade for Codex\n\nThis workflow runs **directly in Codex**. Do not launch the `claude` CLI or\ndelegate the workflow to Clade's MCP bridge.\n\nCodex compatibility rules:\n\n- Plugin skills are namespaced. Invoke this workflow explicitly as\n  `$clade:document-release`; a bare `$name` does not select the installed Clade plugin.\n- Read the nearest `AGENTS.md` files for repository instructions. If a project\n  has only `CLAUDE.md`, treat it as legacy project guidance and read it too.\n- Store new Clade working state under `.clade\u002F` (or `~\u002F.clade\u002F` for personal\n  state). Existing legacy Claude state may be read for migration, but do not\n  create new vendor-specific state.\n- A `\u002Fskill-name` reference means the corresponding Codex\n  `$clade:skill-name` plugin skill, or the same workflow invoked naturally when\n  explicit skill invocation is not available.\n- Use Codex web, file, shell, image, and subagent capabilities when the source\n  workflow names a vendor-specific tool. If a capability is unavailable, use\n  the documented fallback instead of spawning another agent CLI.\n- Paths such as `\u003Cplugin-root>\u002F...` are relative to the installed Clade plugin\n  containing this `SKILL.md`; resolve that root before invoking a helper.\n\n## Canonical Clade workflow\n\nYou are the Document Release skill. Improve repository onboarding and keep\ndocumentation aligned with what users can obtain.\n\nFor a repository creation, substantial README\u002Fsetup or open-source onboarding\nrequest, use Step 2 and its reference as the acceptance standard before drafting.\nFor a release, analyze its changes and sync the affected documentation. A\nREADME task does not require a release or authorize one.\n\n---\n\n## Step 0: Pre-flight\n\n```bash\ngit branch --show-current\ngit log --oneline -5\ngit diff --stat origin\u002Fmain..HEAD 2>\u002Fdev\u002Fnull || git diff --stat HEAD~3..HEAD\n```\n\nFor release synchronization, resolve the release from the request and history;\nask only if it remains ambiguous. An onboarding request already supplies scope.\n\n---\n\n## Step 0b: `--dry-run`\n\nWhen invoked with `--dry-run`, run Steps 1-6 as ANALYSIS ONLY: make no `Edit`\ncall and never reach the `committer` in Step 7. Emit the Step 7 report block\nwith every line prefixed `would update:`. The flag was advertised in the\nargument-hint and read by nothing, so a run asking to preview rewrote and\ncommitted the docs.\n\n## Step 1: Diff analysis\n\nClassify changes into categories:\n- **New features** — new functionality users can use\n- **Changed behavior** — existing features that work differently\n- **Removed** — deleted functionality or deprecated APIs\n- **Infrastructure** — internal changes, no user-visible effect\n\nThis classification determines which docs need updating.\n\n---\n\n## Step 2: README audit\n\nRead `references\u002Frepository-entrypoints.md` before auditing. Inventory root,\nlocalized and independently distributed package READMEs, with their setup and\nsupport destinations. A README is the first product visit: discovery →\nunderstanding → credible proof → first successful use. Text edits alone do not\nestablish a usable entry point.\n\n**Check each section:**\n\n| Section | What to verify |\n|---|---|\n| First screen | Can a new reader identify the audience, outcome, maturity and next action? |\n| Product evidence | Does a real screenshot, terminal\u002Fdemo, input\u002Foutput comparison or diagram explain the product? Logos\u002Fbadges alone do not count. Are fixtures and illustrations labeled? |\n| Presentation | Do images load and remain legible on phone\u002Fdesktop and light\u002Fdark? Is there useful hierarchy rather than a wall of text? |\n| Feature list | Does it reflect new\u002Fremoved features? |\n| Numeric counts | \"N skills\", \"M hooks\" — do the numbers match reality? |\n| Architecture diagram | Still accurate after structural changes? |\n| Install instructions | Still work? Any new steps needed? |\n| Quick start \u002F examples | Still valid? New examples needed? |\n| Configuration | New env vars or config options documented? |\n| Repository and help map | Are real responsibilities, architecture\u002Fdocs, support and contribution paths easy to find and reachable? |\n| Distribution | Do commands, claims and images match the source preview, package or release readers are directed to? |\n| Participation | Can the intended audience use the help\u002Freport\u002Fcontribution routes? Are advertised starter tasks concrete and available? |\n\n**For each stale section:**\n- Fix factual errors and outdated counts immediately (no permission needed)\n- Implement reversible documentation and presentation fixes within the user's\n  authorized scope. Ask only for missing material facts, genuine conflicting\n  directions or an action that needs separate authority.\n\nFor a new or substantially revised entry point, inspect relevant projects in\nthe same category, including their actual rendered media and navigation. Do not\ncopy one layout across unrelated products or treat stars as usability evidence.\nRun the first-use path in an isolated context, inspect the rendered README, and\nrepair findings. Record source, rendered and runtime evidence separately;\nunavailable checks stay unverified. Use `frontend-design` for visual changes.\n\n**Numeric count rule:** If README mentions counts (e.g., \"28 skills\"), re-count the actual files:\n```bash\nls configs\u002Fskills\u002F | wc -l       # skill count\nls configs\u002Fhooks\u002F*.sh | wc -l    # hook count\nls configs\u002Fscripts\u002F*.sh | wc -l  # script count\n```\nUpdate every README variant to match.\n\n---\n\n## Step 3: CHANGELOG update\n\nIf the project has a CHANGELOG.md or CHANGES.md, follow its existing convention.\nFor onboarding work, describe user-visible changes under Unreleased where that\nsection is used; do not invent a release version or date.\n\n**Voice rules:**\n- User-facing language: \"You can now...\" not \"We implemented...\"\n- Past tense for fixes: \"Fixed a bug where...\" not \"Fix bug in...\"\n- Omit internal refactors unless they affect public API\n\n**CHANGELOG polish** (not rewrite):\n- Add an entry for this release if one doesn't exist\n- Format: `## [version] — YYYY-MM-DD` followed by `### Added \u002F Fixed \u002F Changed \u002F Removed`\n- Group related changes into one line (don't list every commit)\n- NEVER delete or rewrite existing entries\n- Use file-editing tools, never Write — preserve what's already there\n\n```markdown\n## [1.4.0] — 2026-03-30\n\n### Added\n- `\u002Finvestigate` skill — root cause analysis with Iron Law and structured debug reports\n- `\u002Fcso` skill — OWASP + STRIDE security audit\n- `\u002Fretro` skill — data-driven engineering retrospective from git history\n- `\u002Fdocument-release` skill — post-ship documentation sync\n\n### Fixed\n- Guardian hook no longer false-positives on variable assignment strings containing migration patterns\n```\n\n---\n\n## Step 4: AGENTS.md sync\n\nRead the project `AGENTS.md`. Check if any of these need updating:\n- **Architecture section** — new modules, changed import DAG, new files\n- **Key commands** — new scripts or changed verify commands\n- **File map table** — new files not yet listed\n- **Code rules** — new patterns established in this release\n\nUpdate only what changed — don't add commentary or restructure.\n\n---\n\n## Step 5: Task-list cleanup\n\n```bash\ncat TODO.md 2>\u002Fdev\u002Fnull || echo \"No TODO.md\"\n```\n\nFor each `- [ ]` item: check if it was completed in this release (Glob\u002FGrep for the implementation).\n- Mark completed items as `- [x]` with the completion date in a comment if helpful\n- Flag stale items (referenced code no longer exists)\n\nAlso scan changed files for inline `TODO`\u002F`FIXME`\u002F`HACK` comments added in this release:\n```bash\ngit diff HEAD~5..HEAD | grep \"^+\" | grep -E \"TODO|FIXME|HACK|XXX\"\n```\nUpdate the project's existing task-list file under the appropriate section;\ndo not create a second TODO\u002FTODOS spelling.\n\n---\n\n## Step 6: Cross-doc consistency check\n\nQuick scan to verify docs agree with each other:\n- README feature list vs AGENTS.md architecture — same modules?\n- Version in README vs package.json\u002FVERSION file — same?\n- Every doc reachable from README or AGENTS.md? (orphan docs are invisible)\n\n---\n\n## Step 7: Commit doc changes\n\nIf any docs were updated:\n```bash\ncommitter \"docs: sync documentation after [release description]\" \\\n  README.md CHANGELOG.md AGENTS.md TODO.md\n# (only include files that actually changed)\n```\n\nReport what was updated:\n```\nDocumentation sync complete:\n  ✓ README.md — updated skill count (24 → 28), added new skills to feature list\n  ✓ CHANGELOG.md — added v1.4.0 entry\n  ✓ AGENTS.md — updated Key File Map with 4 new skill dirs\n  ✓ TODO.md — marked 6 items complete, added 2 new FIXMEs from code scan\n  ✓ Committed: docs: sync documentation after skills v1.4.0 release\n```\n\n---\n\n## Completion Status\n\n- ✅ **DONE** — all docs updated and committed\n- ⚠ **DONE_WITH_CONCERNS** — docs updated but some sections couldn't be auto-verified (e.g., diagram accuracy)\n- ❌ **BLOCKED** — required facts, access, or authority are unavailable. Create missing documentation within the authorized scope; do not ask the user to write it merely because it does not exist.\n- ❓ **NEEDS_CONTEXT** — the requested scope or release remains ambiguous after inspection.\n\n---\n\n## What NOT to do\n\n- Rewrite or reorganize docs beyond the requested onboarding or release scope\n- Delete existing CHANGELOG entries\n- Update unrelated docs\n- Split release-related docs into a separate \"cleanup\" PR; keep them with that\n  release. Standalone onboarding work is its own reviewable change.\n\n## Delivery completion\n\nIf this workflow changes files or external state:\n\n- Inspect the real final state before responding, including `git status` for a\n  repository task.\n- Never report `DONE` while task-owned changes are uncommitted. Use or continue\n  `$clade:delivery` and create a repository-compliant checkpoint or preserve\n  the work when committing is unavailable.\n- When the user request or trusted repository policy makes publication,\n  deployment, or live verification part of the task, do not silently downgrade\n  the result to local-only work.\n- If a required delivery transition lacks authority, credentials, a destination,\n  or reachable external state, report `BLOCKED` or `NEEDS_CONTEXT` rather than\n  appending a \"not committed\u002Fpushed\u002Fdeployed\" caveat after `DONE`.\n","# Clade for Codex\n\nThis workflow runs **directly in Codex**. Do not launch the `claude` CLI or\ndelegate the workflow to Clade's MCP bridge.\n\nCodex compatibility rules:\n\n- Plugin skills are namespaced. Invoke this workflow explicitly as\n  `$clade:document-release`; a bare `$name` does not select the installed Clade plugin.\n- Read the nearest `AGENTS.md` files for repository instructions. If a project\n  has only `CLAUDE.md`, treat it as legacy project guidance and read it too.\n- Store new Clade working state under `.clade\u002F` (or `~\u002F.clade\u002F` for personal\n  state). Existing legacy Claude state may be read for migration, but do not\n  create new vendor-specific state.\n- A `\u002Fskill-name` reference means the corresponding Codex\n  `$clade:skill-name` plugin skill, or the same workflow invoked naturally when\n  explicit skill invocation is not available.\n- Use Codex web, file, shell, image, and subagent capabilities when the source\n  workflow names a vendor-specific tool. If a capability is unavailable, use\n  the documented fallback instead of spawning another agent CLI.\n- Paths such as `\u003Cplugin-root>\u002F...` are relative to the installed Clade plugin\n  containing this `SKILL.md`; resolve that root before invoking a helper.\n\n## Canonical Clade workflow\n\nYou are the Document Release skill. Improve repository onboarding and keep\ndocumentation aligned with what users can obtain.\n\nFor a repository creation, substantial README\u002Fsetup or open-source onboarding\nrequest, use Step 2 and its reference as the acceptance standard before drafting.\nFor a release, analyze its changes and sync the affected documentation. A\nREADME task does not require a release or authorize one.\n\n---\n\n## Step 0: Pre-flight\n\n```bash\ngit branch --show-current\ngit log --oneline -5\ngit diff --stat origin\u002Fmain..HEAD 2>\u002Fdev\u002Fnull || git diff --stat HEAD~3..HEAD\n```\n\nFor release synchronization, resolve the release from the request and history;\nask only if it remains ambiguous. An onboarding request already supplies scope.\n\n---\n\n## Step 0b: `--dry-run`\n\nWhen invoked with `--dry-run`, run Steps 1-6 as ANALYSIS ONLY: make no `Edit`\ncall and never reach the `committer` in Step 7. Emit the Step 7 report block\nwith every line prefixed `would update:`. The flag was advertised in the\nargument-hint and read by nothing, so a run asking to preview rewrote and\ncommitted the docs.\n\n## Step 1: Diff analysis\n\nClassify changes into categories:\n- **New features** — new functionality users can use\n- **Changed behavior** — existing features that work differently\n- **Removed** — deleted functionality or deprecated APIs\n- **Infrastructure** — internal changes, no user-visible effect\n\nThis classification determines which docs need updating.\n\n---\n\n## Step 2: README audit\n\nRead `references\u002Frepository-entrypoints.md` before auditing. Inventory root,\nlocalized and independently distributed package READMEs, with their setup and\nsupport destinations. A README is the first product visit: discovery →\nunderstanding → credible proof → first successful use. Text edits alone do not\nestablish a usable entry point.\n\n**Check each section:**\n\n| Section | What to verify |\n|---|---|\n| First screen | Can a new reader identify the audience, outcome, maturity and next action? |\n| Product evidence | Does a real screenshot, terminal\u002Fdemo, input\u002Foutput comparison or diagram explain the product? Logos\u002Fbadges alone do not count. Are fixtures and illustrations labeled? |\n| Presentation | Do images load and remain legible on phone\u002Fdesktop and light\u002Fdark? Is there useful hierarchy rather than a wall of text? |\n| Feature list | Does it reflect new\u002Fremoved features? |\n| Numeric counts | \"N skills\", \"M hooks\" — do the numbers match reality? |\n| Architecture diagram | Still accurate after structural changes? |\n| Install instructions | Still work? Any new steps needed? |\n| Quick start \u002F examples | Still valid? New examples needed? |\n| Configuration | New env vars or config options documented? |\n| Repository and help map | Are real responsibilities, architecture\u002Fdocs, support and contribution paths easy to find and reachable? |\n| Distribution | Do commands, claims and images match the source preview, package or release readers are directed to? |\n| Participation | Can the intended audience use the help\u002Freport\u002Fcontribution routes? Are advertised starter tasks concrete and available? |\n\n**For each stale section:**\n- Fix factual errors and outdated counts immediately (no permission needed)\n- Implement reversible documentation and presentation fixes within the user's\n  authorized scope. Ask only for missing material facts, genuine conflicting\n  directions or an action that needs separate authority.\n\nFor a new or substantially revised entry point, inspect relevant projects in\nthe same category, including their actual rendered media and navigation. Do not\ncopy one layout across unrelated products or treat stars as usability evidence.\nRun the first-use path in an isolated context, inspect the rendered README, and\nrepair findings. Record source, rendered and runtime evidence separately;\nunavailable checks stay unverified. Use `frontend-design` for visual changes.\n\n**Numeric count rule:** If README mentions counts (e.g., \"28 skills\"), re-count the actual files:\n```bash\nls configs\u002Fskills\u002F | wc -l       # skill count\nls configs\u002Fhooks\u002F*.sh | wc -l    # hook count\nls configs\u002Fscripts\u002F*.sh | wc -l  # script count\n```\nUpdate every README variant to match.\n\n---\n\n## Step 3: CHANGELOG update\n\nIf the project has a CHANGELOG.md or CHANGES.md, follow its existing convention.\nFor onboarding work, describe user-visible changes under Unreleased where that\nsection is used; do not invent a release version or date.\n\n**Voice rules:**\n- User-facing language: \"You can now...\" not \"We implemented...\"\n- Past tense for fixes: \"Fixed a bug where...\" not \"Fix bug in...\"\n- Omit internal refactors unless they affect public API\n\n**CHANGELOG polish** (not rewrite):\n- Add an entry for this release if one doesn't exist\n- Format: `## [version] — YYYY-MM-DD` followed by `### Added \u002F Fixed \u002F Changed \u002F Removed`\n- Group related changes into one line (don't list every commit)\n- NEVER delete or rewrite existing entries\n- Use file-editing tools, never Write — preserve what's already there\n\n```markdown\n## [1.4.0] — 2026-03-30\n\n### Added\n- `\u002Finvestigate` skill — root cause analysis with Iron Law and structured debug reports\n- `\u002Fcso` skill — OWASP + STRIDE security audit\n- `\u002Fretro` skill — data-driven engineering retrospective from git history\n- `\u002Fdocument-release` skill — post-ship documentation sync\n\n### Fixed\n- Guardian hook no longer false-positives on variable assignment strings containing migration patterns\n```\n\n---\n\n## Step 4: AGENTS.md sync\n\nRead the project `AGENTS.md`. Check if any of these need updating:\n- **Architecture section** — new modules, changed import DAG, new files\n- **Key commands** — new scripts or changed verify commands\n- **File map table** — new files not yet listed\n- **Code rules** — new patterns established in this release\n\nUpdate only what changed — don't add commentary or restructure.\n\n---\n\n## Step 5: Task-list cleanup\n\n```bash\ncat TODO.md 2>\u002Fdev\u002Fnull || echo \"No TODO.md\"\n```\n\nFor each `- [ ]` item: check if it was completed in this release (Glob\u002FGrep for the implementation).\n- Mark completed items as `- [x]` with the completion date in a comment if helpful\n- Flag stale items (referenced code no longer exists)\n\nAlso scan changed files for inline `TODO`\u002F`FIXME`\u002F`HACK` comments added in this release:\n```bash\ngit diff HEAD~5..HEAD | grep \"^+\" | grep -E \"TODO|FIXME|HACK|XXX\"\n```\nUpdate the project's existing task-list file under the appropriate section;\ndo not create a second TODO\u002FTODOS spelling.\n\n---\n\n## Step 6: Cross-doc consistency check\n\nQuick scan to verify docs agree with each other:\n- README feature list vs AGENTS.md architecture — same modules?\n- Version in README vs package.json\u002FVERSION file — same?\n- Every doc reachable from README or AGENTS.md? (orphan docs are invisible)\n\n---\n\n## Step 7: Commit doc changes\n\nIf any docs were updated:\n```bash\ncommitter \"docs: sync documentation after [release description]\" \\\n  README.md CHANGELOG.md AGENTS.md TODO.md\n# (only include files that actually changed)\n```\n\nReport what was updated:\n```\nDocumentation sync complete:\n  ✓ README.md — updated skill count (24 → 28), added new skills to feature list\n  ✓ CHANGELOG.md — added v1.4.0 entry\n  ✓ AGENTS.md — updated Key File Map with 4 new skill dirs\n  ✓ TODO.md — marked 6 items complete, added 2 new FIXMEs from code scan\n  ✓ Committed: docs: sync documentation after skills v1.4.0 release\n```\n\n---\n\n## Completion Status\n\n- ✅ **DONE** — all docs updated and committed\n- ⚠ **DONE_WITH_CONCERNS** — docs updated but some sections couldn't be auto-verified (e.g., diagram accuracy)\n- ❌ **BLOCKED** — required facts, access, or authority are unavailable. Create missing documentation within the authorized scope; do not ask the user to write it merely because it does not exist.\n- ❓ **NEEDS_CONTEXT** — the requested scope or release remains ambiguous after inspection.\n\n---\n\n## What NOT to do\n\n- Rewrite or reorganize docs beyond the requested onboarding or release scope\n- Delete existing CHANGELOG entries\n- Update unrelated docs\n- Split release-related docs into a separate \"cleanup\" PR; keep them with that\n  release. Standalone onboarding work is its own reviewable change.\n\n## Delivery completion\n\nIf this workflow changes files or external state:\n\n- Inspect the real final state before responding, including `git status` for a\n  repository task.\n- Never report `DONE` while task-owned changes are uncommitted. Use or continue\n  `$clade:delivery` and create a repository-compliant checkpoint or preserve\n  the work when committing is unavailable.\n- When the user request or trusted repository policy makes publication,\n  deployment, or live verification part of the task, do not silently downgrade\n  the result to local-only work.\n- If a required delivery transition lacks authority, credentials, a destination,\n  or reachable external state, report `BLOCKED` or `NEEDS_CONTEXT` rather than\n  appending a \"not committed\u002Fpushed\u002Fdeployed\" caveat after `DONE`.\n",{"name":5,"description":7},"main","bb20646cb013d2f52f854743fcee83dcc5ccfbd9","plugins\u002Fclade\u002Fskills\u002Fdocument-release",6,"https:\u002F\u002Fgithub.com\u002Fshenxingy\u002FClade","https:\u002F\u002Falexshen.dev\u002Fen\u002Fblog\u002Fclade","https:\u002F\u002Fgithub.com\u002Fshenxingy","https:\u002F\u002Falexshen.dev\u002F","Founding Engineer @ Scam AI | ECE @ Duke University | Data Science @ Duke Kunshan University","2026-11-11 10:54:30",{"source":8,"skillName":5,"commands":65,"prompt":75,"zipAvailable":76},[66,69,72],{"tool":67,"command":68},"npx","npx skills add shenxingy\u002FClade --skill document-release",{"tool":70,"command":71},"bunx","bunx skills add shenxingy\u002FClade --skill document-release",{"tool":73,"command":74},"pnpm","pnpm dlx skills add shenxingy\u002FClade --skill document-release","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fshenxingy\u002FClade\u002Fblob\u002Fmain\u002Fplugins\u002Fclade\u002Fskills\u002Fdocument-release\u002FSKILL.md",true,[78],{"path":79,"resourceType":80,"resourceTypeDesc":81,"sizeBytes":82,"sourceHtmlUrl":83},"references\u002Frepository-entrypoints.md","REFERENCE","参考文档",8921,"https:\u002F\u002Fgithub.com\u002Fshenxingy\u002FClade\u002Fblob\u002Fmain\u002Fplugins\u002Fclade\u002Fskills\u002Fdocument-release\u002Freferences\u002Frepository-entrypoints.md",[85,103,135,155,180,195],{"skillNo":86,"name":87,"nameZh":6,"description":88,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":89,"categories":90,"keywords":92,"publishedAt":49},"01M6FNPBA3494GF2W7V4MMAKG3","worktree","Create or inspect runtime-adaptive isolated Git workspaces with explicit ownership and delivery routing","https:\u002F\u002Fgithub.com\u002Fshenxingy\u002FClade\u002Fblob\u002Fmain\u002Fplugins\u002Fclade\u002Fskills\u002Fworktree\u002FSKILL.md",[91],{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},[87,93,94,33,95,96,97,98,99,100,101,102],"adaptive","inspect","ownership","delivery routing","runtime","delivery","workspaces","git","routing","create",{"skillNo":104,"name":105,"nameZh":6,"description":106,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":107,"categories":108,"keywords":115,"publishedAt":49},"01M6FNP75BY8CS006EWGN29FM0","web-search","Route online research and URL reading to native tools or TinyFish MCP\u002FAPI; prepare targeted requests, handle progress and failures, and check returned evidence. Applies to web search, fetching, and bulk collection; excludes repository\u002Ffile search.","https:\u002F\u002Fgithub.com\u002Fshenxingy\u002FClade\u002Fblob\u002Fmain\u002Fplugins\u002Fclade\u002Fskills\u002Fweb-search\u002FSKILL.md",[109,110],{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":111,"categoryName":112,"taxonomyType":113,"taxonomyTypeDesc":114},"01JBSEEDCAT000000000000030","开发工程师","PROFESSION","适用职业",[116,117,118,45,119,120,121,122,123,124,125,126,127,128,129,130,131,132,133,134],"web search","search","web","file","research","MCP","requests","collection","reading","URL","native","bulk","progress","file search","route","tinyfish","evidence","check","api",{"skillNo":136,"name":43,"nameZh":6,"description":137,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":138,"categories":139,"keywords":141,"publishedAt":49},"01M6FNP2616DRTZRSZJQM3HPHY","Verify project behavior anchors — compilation, tests, and interaction checks after autonomous runs. NOT the Codex built-in \u002Fverify (which runs the app to observe a single change working) — this one walks the AGENTS.md \"Features (Behavior Anchors)\" list.","https:\u002F\u002Fgithub.com\u002Fshenxingy\u002FClade\u002Fblob\u002Fmain\u002Fplugins\u002Fclade\u002Fskills\u002Fverify\u002FSKILL.md",[140],{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},[43,142,143,144,145,146,147,148,149,150,151,152,153,154],"app","single","features","which","interaction","tests","project","observe","autonomous","behavior","list","change","codex",{"skillNo":156,"name":157,"nameZh":6,"description":158,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":159,"categories":160,"keywords":162,"publishedAt":49},"01M6FNNX95R9H29BNERFY15704","tasks","Coordinate dependency-aware project tasks across independent Codex, Codex, Kimi and human sessions using Beads. Use for shared plans, claiming work, task handoffs, acceptance and agent monitoring snapshots.","https:\u002F\u002Fgithub.com\u002Fshenxingy\u002FClade\u002Fblob\u002Fmain\u002Fplugins\u002Fclade\u002Fskills\u002Ftasks\u002FSKILL.md",[161],{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},[157,163,164,165,148,166,167,168,169,170,171,172,173,174,39,175,176,177,178,179,154],"for","plans","work","shared","across","human","task","coordinate","kimi","snapshots","agent monitoring","dependency","using beads","beads","monitoring","acceptance","sessions",{"skillNo":181,"name":40,"nameZh":6,"description":182,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":183,"categories":184,"keywords":186,"publishedAt":49},"01M6FNNTAD1BCZX5Q9TC55MZCH","End-of-session documentation sync — updates TODO.md and PROGRESS.md only (run \u002Fcommit after to commit everything)","https:\u002F\u002Fgithub.com\u002Fshenxingy\u002FClade\u002Fblob\u002Fmain\u002Fplugins\u002Fclade\u002Fskills\u002Fsync\u002FSKILL.md",[185],{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},[40,187,188,48,189,190,191,192,128,193,194],"session","run","commit","only","documentation sync","updates","end","todo",{"skillNo":196,"name":197,"nameZh":6,"description":198,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":199,"categories":200,"keywords":202,"publishedAt":49},"01M6FNNPTR5H23MD3849E66WYA","status","Show a provider-neutral, freshness-aware snapshot of active Agent work, Git delivery, execution identity, and usage limits. Use for “what's going on right now”, what is running, progress updates, active runtime\u002Fprovider\u002Fmodel, or stuck-work checks.","https:\u002F\u002Fgithub.com\u002Fshenxingy\u002FClade\u002Fblob\u002Fmain\u002Fplugins\u002Fclade\u002Fskills\u002Fstatus\u002FSKILL.md",[201],{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},[197,97,203,204,163,192,205,206,128,207,98,208,209,39,210,165,211,212,100,213],"running","limits","usage","now","active","show","provider","snapshot","model","execution","identity"]