[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6DSX6PBHM253PNDA1KYHTFE":3,"skill-same:01M6DSX6PBHM253PNDA1KYHTFE":78},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":15,"categories":16,"keywords":25,"publishedAt":51,"linkOnly":52,"markdownContent":53,"markdownBody":54,"frontMatter":55,"refName":56,"commitSha":57,"skillDirectory":58,"forksCount":59,"repositoryHtmlUrl":60,"repositoryHomepageUrl":61,"ownerHtmlUrl":62,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":63,"install":64,"resources":77},"01M6DSX6PBHM253PNDA1KYHTFE","document-commit-deploy",null,"Run the end-of-work documentation, commit, and deploy playbook. TRIGGER when the user says \"wrap this up\", \"document and commit\", \"ship it\", \"we're done — push it\", \"deploy this\", or any phrasing that signals the current piece of work is complete and needs to be persisted. Also TRIGGER at the natural close of a major feature or fix when the user hasn't said so explicitly but the work is clearly done.","clayrune-io\u002Fclayrune","clayrune-io","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F324312123?v=4","01M6DSX1QQQMJ0FPCSHSX95Q9G","01M6DSX1ZXTZQSGRA5ZXH1ZZWM",17,"MIT","https:\u002F\u002Fgithub.com\u002Fclayrune-io\u002Fclayrune\u002Fblob\u002Fmaster\u002Fdata\u002Fskills\u002Fbuiltin\u002Fdocument-commit-deploy\u002FSKILL.md",[17,22],{"categoryNo":18,"categoryName":19,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000002","文档处理","SCENARIO","使用场景",{"categoryNo":23,"categoryName":24,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000011","运维与部署",[26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50],"deploy","commit","document commit deploy","document","when","at","re","close","complete","trigger","end","feature","signals","ship it","done","but","wrap","up","fix","work","ship","playbook","push","run","documentation","2026-11-10 10:12:30",false,"---\nname: document-commit-deploy\ndescription: Run the end-of-work documentation, commit, and deploy playbook. TRIGGER when the user says \"wrap this up\", \"document and commit\", \"ship it\", \"we're done — push it\", \"deploy this\", or any phrasing that signals the current piece of work is complete and needs to be persisted. Also TRIGGER at the natural close of a major feature or fix when the user hasn't said so explicitly but the work is clearly done.\n---\n\n# Document, Commit & Deploy\n\nClayrune's SHARED_RULES requires that every major change be documented, committed, and (if git-synced) pushed. This skill is the concrete playbook so it actually happens.\n\n## Sequence\n\nRun these steps in order. Don't skip. If a step is genuinely N\u002FA for the current change, say so out loud before moving on.\n\n### 1. Identify what changed\n\n```bash\ngit status\ngit diff --stat\ngit diff\n```\n\nRead the diff carefully. Group changes by intent (feature \u002F fix \u002F refactor \u002F docs).\n\n### 2. Update documentation artifacts\n\nFor each changed area, update the corresponding doc:\n\n- **CHANGELOG.md** — add a dated entry summarizing what changed and why. Follow the existing format in the file (date stamp, bullet list of changes, optional Rollback \u002F Why sections).\n- **CLAUDE.md** — update if the change affects how future agents should work in this codebase (new conventions, architectural shifts, new must-do steps).\n- **README.md** — update if user-facing behavior, install, or quickstart changed.\n- **MEMORY.md** — update if the change introduces a load-bearing fact about the project that future sessions need to know (architecture, gotchas, decisions). Skip if the change is routine.\n- **AGENT_RULES.md \u002F SHARED_RULES.md** — update only if a new must-do or must-not-do rule emerged.\n- **`docs\u002FUSER_GUIDE.md`** (Clayrune only) — update if **anything user-facing** changed: a new UI element, button, menu entry, sidebar item, settings toggle, keyboard shortcut, or any feature an end user can discover. This file is the source of truth for the in-app \"Ask Claydo\" helper — if the feature isn't documented here, Claydo can't tell users about it. **Gate**: before committing a UI \u002F user-facing change to Clayrune, explicitly answer \"did I update USER_GUIDE.md?\" and either show the diff or state out loud why it's not needed (e.g. \"internal refactor, no user-visible change\").\n\nIf a doc doesn't need updating, say so explicitly: *\"CLAUDE.md doesn't need changes for this — purely a UI tweak.\"*\n\n### 3. Sanity-check the changes\n\n- Run any relevant tests, linters, or type checks.\n- For UI changes: actually open the dev server in a browser and verify the feature works.\n- **Dashboard SPA gate (Clayrune only)**: if you touched `static\u002Findex.html`, you MUST run the headless boot smoke test before committing — `cd tools\u002Fsmoke && npm install && npx playwright install chromium && npm test` (chromium install is one-time). It loads the real page in headless Chromium and asserts the project grid renders. This catches RUNTIME boot throws that `node --check` \u002F syntax checks miss — e.g. a `let` read before its declaration (temporal dead zone) that aborts boot and hangs the whole dashboard on \"Loading...\" with no projects. These ship unnoticed because your own open tab keeps the OLD working JS (server restart ≠ tab reload), so a fresh load is never exercised. **Gate**: before committing an `index.html` change, either show the `✅ PASS` output or state out loud why it's genuinely N\u002FA. CI (`.github\u002Fworkflows\u002Ffrontend-smoke.yml`) runs the same check on PR, but run it locally first — don't outsource the catch.\n- If anything fails, stop and fix it before proceeding.\n\n### 4. Stage and commit\n\nStage only the files that belong in this commit (not stray edits):\n\n```bash\ngit add path\u002Fto\u002Ffile1 path\u002Fto\u002Ffile2 ...\n```\n\nAvoid `git add -A` or `git add .` — they can pick up sensitive files (`.env`, credentials) or large binaries.\n\nCompose the commit message:\n- One-line subject, focused on the **why** not the what.\n- Optional body for nuance, decisions, rollback notes.\n- Match the repo's existing commit style (run `git log --oneline -10` to check).\n\nUse a HEREDOC to preserve formatting:\n\n```bash\ngit commit -m \"$(cat \u003C\u003C'EOF'\nSubject line under 70 chars\n\nOptional body explaining why this change was made,\nany tradeoffs, and how to roll back if needed.\nEOF\n)\"\n```\n\n### 5. Push (only if git-synced)\n\n```bash\ngit remote -v   # confirm an origin exists\ngit push\n```\n\nIf there's no remote, skip this step — committing locally is enough.\n\n### 6. Report\n\nIn one or two sentences: what shipped, what's next. No more.\n\n## Important rules\n\n- **Never `git push --force` to a shared branch** unless the user explicitly asks.\n- **Never skip hooks** (`--no-verify`, `--no-gpg-sign`) unless explicitly asked. If a hook fails, fix the underlying issue and create a NEW commit (don't amend).\n- **Pre-commit hook failure = the commit didn't happen.** Fix, re-stage, commit fresh.\n- **If the user hasn't asked for a commit yet**, do steps 1-3 (review + docs + sanity check) and ASK before committing. Only auto-commit when the user signaled \"ship it.\"\n","# Document, Commit & Deploy\n\nClayrune's SHARED_RULES requires that every major change be documented, committed, and (if git-synced) pushed. This skill is the concrete playbook so it actually happens.\n\n## Sequence\n\nRun these steps in order. Don't skip. If a step is genuinely N\u002FA for the current change, say so out loud before moving on.\n\n### 1. Identify what changed\n\n```bash\ngit status\ngit diff --stat\ngit diff\n```\n\nRead the diff carefully. Group changes by intent (feature \u002F fix \u002F refactor \u002F docs).\n\n### 2. Update documentation artifacts\n\nFor each changed area, update the corresponding doc:\n\n- **CHANGELOG.md** — add a dated entry summarizing what changed and why. Follow the existing format in the file (date stamp, bullet list of changes, optional Rollback \u002F Why sections).\n- **CLAUDE.md** — update if the change affects how future agents should work in this codebase (new conventions, architectural shifts, new must-do steps).\n- **README.md** — update if user-facing behavior, install, or quickstart changed.\n- **MEMORY.md** — update if the change introduces a load-bearing fact about the project that future sessions need to know (architecture, gotchas, decisions). Skip if the change is routine.\n- **AGENT_RULES.md \u002F SHARED_RULES.md** — update only if a new must-do or must-not-do rule emerged.\n- **`docs\u002FUSER_GUIDE.md`** (Clayrune only) — update if **anything user-facing** changed: a new UI element, button, menu entry, sidebar item, settings toggle, keyboard shortcut, or any feature an end user can discover. This file is the source of truth for the in-app \"Ask Claydo\" helper — if the feature isn't documented here, Claydo can't tell users about it. **Gate**: before committing a UI \u002F user-facing change to Clayrune, explicitly answer \"did I update USER_GUIDE.md?\" and either show the diff or state out loud why it's not needed (e.g. \"internal refactor, no user-visible change\").\n\nIf a doc doesn't need updating, say so explicitly: *\"CLAUDE.md doesn't need changes for this — purely a UI tweak.\"*\n\n### 3. Sanity-check the changes\n\n- Run any relevant tests, linters, or type checks.\n- For UI changes: actually open the dev server in a browser and verify the feature works.\n- **Dashboard SPA gate (Clayrune only)**: if you touched `static\u002Findex.html`, you MUST run the headless boot smoke test before committing — `cd tools\u002Fsmoke && npm install && npx playwright install chromium && npm test` (chromium install is one-time). It loads the real page in headless Chromium and asserts the project grid renders. This catches RUNTIME boot throws that `node --check` \u002F syntax checks miss — e.g. a `let` read before its declaration (temporal dead zone) that aborts boot and hangs the whole dashboard on \"Loading...\" with no projects. These ship unnoticed because your own open tab keeps the OLD working JS (server restart ≠ tab reload), so a fresh load is never exercised. **Gate**: before committing an `index.html` change, either show the `✅ PASS` output or state out loud why it's genuinely N\u002FA. CI (`.github\u002Fworkflows\u002Ffrontend-smoke.yml`) runs the same check on PR, but run it locally first — don't outsource the catch.\n- If anything fails, stop and fix it before proceeding.\n\n### 4. Stage and commit\n\nStage only the files that belong in this commit (not stray edits):\n\n```bash\ngit add path\u002Fto\u002Ffile1 path\u002Fto\u002Ffile2 ...\n```\n\nAvoid `git add -A` or `git add .` — they can pick up sensitive files (`.env`, credentials) or large binaries.\n\nCompose the commit message:\n- One-line subject, focused on the **why** not the what.\n- Optional body for nuance, decisions, rollback notes.\n- Match the repo's existing commit style (run `git log --oneline -10` to check).\n\nUse a HEREDOC to preserve formatting:\n\n```bash\ngit commit -m \"$(cat \u003C\u003C'EOF'\nSubject line under 70 chars\n\nOptional body explaining why this change was made,\nany tradeoffs, and how to roll back if needed.\nEOF\n)\"\n```\n\n### 5. Push (only if git-synced)\n\n```bash\ngit remote -v   # confirm an origin exists\ngit push\n```\n\nIf there's no remote, skip this step — committing locally is enough.\n\n### 6. Report\n\nIn one or two sentences: what shipped, what's next. No more.\n\n## Important rules\n\n- **Never `git push --force` to a shared branch** unless the user explicitly asks.\n- **Never skip hooks** (`--no-verify`, `--no-gpg-sign`) unless explicitly asked. If a hook fails, fix the underlying issue and create a NEW commit (don't amend).\n- **Pre-commit hook failure = the commit didn't happen.** Fix, re-stage, commit fresh.\n- **If the user hasn't asked for a commit yet**, do steps 1-3 (review + docs + sanity check) and ASK before committing. Only auto-commit when the user signaled \"ship it.\"\n",{"name":5,"description":7},"master","ef008ef5ed969452bf69f2e0baeb9c441f3ac83d","data\u002Fskills\u002Fbuiltin\u002Fdocument-commit-deploy",2,"https:\u002F\u002Fgithub.com\u002Fclayrune-io\u002Fclayrune","https:\u002F\u002Fclayrune.io","https:\u002F\u002Fgithub.com\u002Fclayrune-io","2026-11-12 03:10:56",{"source":8,"skillName":5,"commands":65,"prompt":75,"zipAvailable":76},[66,69,72],{"tool":67,"command":68},"npx","npx skills add clayrune-io\u002Fclayrune --skill document-commit-deploy",{"tool":70,"command":71},"bunx","bunx skills add clayrune-io\u002Fclayrune --skill document-commit-deploy",{"tool":73,"command":74},"pnpm","pnpm dlx skills add clayrune-io\u002Fclayrune --skill document-commit-deploy","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fclayrune-io\u002Fclayrune\u002Fblob\u002Fmaster\u002Fdata\u002Fskills\u002Fbuiltin\u002Fdocument-commit-deploy\u002FSKILL.md",true,[],[79,100,110,120,130,153],{"skillNo":80,"name":81,"nameZh":6,"description":82,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":83,"categories":84,"keywords":88,"publishedAt":51},"01M6DSYZRPBR2KVMJ9F05W02WR","prompt-injection-skill","TEST FIXTURE (MC-912) — do not install. Exercises the prompt-injection detector.","https:\u002F\u002Fgithub.com\u002Fclayrune-io\u002Fclayrune\u002Fblob\u002Fmaster\u002Ftests\u002Ffixtures\u002Fmalicious_skills\u002Fprompt-injection-skill\u002FSKILL.md",[85],{"categoryNo":86,"categoryName":87,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000023","Skill与智能体开发",[89,90,91,92,93,94,95,96,97,98,99],"prompt injection","prompt","injection","prompt injection skill","detector","mc","fixture","do","install","test","prompt-injection",{"skillNo":101,"name":102,"nameZh":6,"description":103,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":104,"categories":105,"keywords":107,"publishedAt":51},"01M6DSYWKY8FQKJ2202HZTRZXN","persistence-skill","TEST FIXTURE (MC-912) — do not install. Exercises the persistence detector.","https:\u002F\u002Fgithub.com\u002Fclayrune-io\u002Fclayrune\u002Fblob\u002Fmaster\u002Ftests\u002Ffixtures\u002Fmalicious_skills\u002Fpersistence-skill\u002FSKILL.md",[106],{"categoryNo":86,"categoryName":87,"taxonomyType":20,"taxonomyTypeDesc":21},[108,109,98,97,96,95,94,93],"persistence","persistence skill",{"skillNo":111,"name":112,"nameZh":6,"description":113,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":114,"categories":115,"keywords":117,"publishedAt":51},"01M6DSYSTMXZJXN4VH879PSH06","exfiltration-skill","TEST FIXTURE (MC-912) — do not install. Exercises the exfiltration detector.","https:\u002F\u002Fgithub.com\u002Fclayrune-io\u002Fclayrune\u002Fblob\u002Fmaster\u002Ftests\u002Ffixtures\u002Fmalicious_skills\u002Fexfiltration-skill\u002FSKILL.md",[116],{"categoryNo":86,"categoryName":87,"taxonomyType":20,"taxonomyTypeDesc":21},[118,119,98,97,96,95,94,93],"exfiltration","exfiltration skill",{"skillNo":121,"name":122,"nameZh":6,"description":123,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":124,"categories":125,"keywords":127,"publishedAt":51},"01M6DSYP2HPFZS2D71SQTAK9WC","destructive-skill","TEST FIXTURE (MC-912) — do not install. Exercises the destructive-command detector.","https:\u002F\u002Fgithub.com\u002Fclayrune-io\u002Fclayrune\u002Fblob\u002Fmaster\u002Ftests\u002Ffixtures\u002Fmalicious_skills\u002Fdestructive-skill\u002FSKILL.md",[126],{"categoryNo":86,"categoryName":87,"taxonomyType":20,"taxonomyTypeDesc":21},[128,93,98,129,97,96,95,94],"destructive skill","command",{"skillNo":131,"name":132,"nameZh":6,"description":133,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":134,"categories":135,"keywords":142,"publishedAt":51},"01M6DSYK30Q44MPGK6QW8T6TSM","config-mod-skill","TEST FIXTURE (MC-912) — do not install. Exercises the agent-config-mod detector's write-API coverage (the gap Hermes's own scanner documents missing).","https:\u002F\u002Fgithub.com\u002Fclayrune-io\u002Fclayrune\u002Fblob\u002Fmaster\u002Ftests\u002Ffixtures\u002Fmalicious_skills\u002Fconfig-mod-skill\u002FSKILL.md",[136,137],{"categoryNo":86,"categoryName":87,"taxonomyType":20,"taxonomyTypeDesc":21},{"categoryNo":138,"categoryName":139,"taxonomyType":140,"taxonomyTypeDesc":141},"01JBSEEDCAT000000000000030","开发工程师","PROFESSION","适用职业",[143,144,97,98,145,146,147,148,149,150,96,95,151,152,94,93],"config mod skill","config","documents","api","hermes","write","coverage","scanner","gap","missing",{"skillNo":154,"name":155,"nameZh":6,"description":156,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":157,"categories":158,"keywords":160,"publishedAt":51},"01M6DSYFMVW71SEMTN11XFQMAG","benign-skill","TEST FIXTURE (MC-912) — negative control. Should produce zero scanner findings.","https:\u002F\u002Fgithub.com\u002Fclayrune-io\u002Fclayrune\u002Fblob\u002Fmaster\u002Ftests\u002Ffixtures\u002Fmalicious_skills\u002Fbenign-skill\u002FSKILL.md",[159],{"categoryNo":86,"categoryName":87,"taxonomyType":20,"taxonomyTypeDesc":21},[161,162,98,163,164,150,95,165,94],"benign","benign skill","produce","ZeRO","control"]