[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6C7GXBD36HCCFHP75B4MASC":3,"skill-same:01M6C7GXBD36HCCFHP75B4MASC":68},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":15,"categories":16,"keywords":17,"publishedAt":22,"linkOnly":23,"markdownContent":24,"markdownBody":25,"frontMatter":26,"refName":27,"commitSha":28,"skillDirectory":29,"forksCount":30,"repositoryHtmlUrl":31,"repositoryHomepageUrl":6,"ownerHtmlUrl":32,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":33,"install":34,"resources":47},"01M6C7GXBD36HCCFHP75B4MASC","shared-guidance-neutrality",null,"Reviewer checklist for changes to package-shipped guidance surfaces. Enforces semantic project-neutrality and project-local preservation of removed Kynetic context.","lepahc\u002Fkynetic-spec","lepahc","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F255431765?v=4","01M6C7E6Z0C8SE1X6PJ2F9Q1CX","01M6C7E744QKNYBVZ7KV7Z69GF",1,"MIT","https:\u002F\u002Fgithub.com\u002Flepahc\u002Fkynetic-spec\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fshared-guidance-neutrality\u002FSKILL.md",[],[18,19,20,21],"shared guidance neutrality","package","reviewer","context","2026-11-10 10:12:30",false,"---\nname: shared-guidance-neutrality\ndescription: Reviewer checklist for changes to package-shipped guidance\n  surfaces. Enforces semantic project-neutrality and project-local preservation\n  of removed Kynetic context.\n---\n\u003C!-- kspec-managed -->\n# Shared-Guidance Neutrality\n\nReviewer checklist for changes to package-shipped or shared guidance surfaces in this self-hosting repository. Enforces semantic project-neutrality and ensures any Kynetic-only instruction removed from shared text has a project-local home.\n\n## When This Skill Applies\n\nApply this checklist whenever a task or plan changes any of these **shared\u002Fpackage guidance surfaces**:\n\n- `templates\u002Fskills\u002F` — package core skill sources\n- `templates\u002Fskills\u002Fmanifest.yaml` — package skill manifest\n- `templates\u002Fagents-sections\u002F` — static agent-instruction sections shipped with the package\n- `plugin\u002Fplugins\u002Fkspec\u002Fskills\u002F` — package plugin skill copies shipped to consumers\n- Rendered package\u002Fcore skill outputs under `.agents\u002Fskills\u002F` when their source is a package core skill (the `kspec-` prefixed entries), NOT a project-local `.kspec\u002Fskills\u002F` skill\n- Rendered package\u002Fcore skill outputs under `.factory\u002Fskills\u002F` when they are generated from package core skill sources\n- Generated `kspec-agents.md` sections that come from package templates (the `templates\u002Fagents-sections\u002F` outputs)\n\nIt does NOT apply to project-local skills (`.kspec\u002Fskills\u002F`), project meta conventions, `AGENTS.md`, or other project-local context — those surfaces are expected to carry Kynetic self-hosting policy.\n\n## Why This Exists\n\nThis repository is self-hosting: it both ships the kspec package and uses kspec to manage its own work. Shared guidance surfaces are consumed by every kspec project, not just Kynetic. When Kynetic self-hosting policy leaks into shared text, every consumer is taught Kynetic's branch names, source paths, toolchain, and review policy as if they were universal kspec mechanics.\n\nThis neutrality is a **semantic property of prose**. String scanners can be evaded by paraphrasing and produce false positives on legitimate uses (e.g., kspec docs naturally mention `kspec` commands). Reviewer judgment is the durable enforcement mechanism; this skill encodes the judgment criteria.\n\n## The Semantic Review Rule\n\nPackage-shipped guidance describes **universal kspec mechanics only**.\n\nThe following classes of instruction belong in **project-local context** (`AGENTS.md`, project-local `.kspec\u002Fskills\u002F`, or project meta conventions), not in shared\u002Fpackage guidance:\n\n| Class | Belongs in shared guidance? | Examples (must NOT appear as universal in shared text) |\n|---|---|---|\n| Branch policy | No | `main`, `dev`, \"rebase onto `dev`\", \"PR against `main`\" |\n| External review policy | No | \"open a GitHub PR\", `gh pr create`, `PR #...` references |\n| Repo\u002Fsource paths | No (when describing consumer workflow) | `templates\u002Fskills\u002F`, `src\u002Fparser\u002Fvalidate.ts`, `packages\u002Fweb-ui\u002F` presented as places the consumer must edit |\n| Toolchain\u002Fquality gates | No | `npm test`, `npm run lint`, `npm run typecheck`, oxlint, Vitest specifics |\n| Generated-artifact maintenance rules | No (consumer doesn't generate package artifacts) | \"regenerate `kspec-agents.md` after editing `templates\u002Fskills\u002F`\", `.factory\u002Fskills\u002F` refresh rules |\n| Dispatch workflow choices | No (when policy not mechanism) | \"do NOT create GitHub PRs for dispatched work\" as universal |\n| Fixed agent ids | No | hard-coded `task-worker`, `pr-reviewer`, `kynetic.meta.yaml` references presented as guaranteed |\n| Runtime-specific tool names | No (when not universally available) | `AskUserQuestion` and other adapter-specific tool names |\n| Concrete workflow\u002Ftrait refs | No (unless universally seeded) | refs like `@trait-foo` presented as guaranteed when `kspec setup` doesn't seed them for every consumer |\n\nUniversal kspec **mechanics** (always allowed in shared text):\n\n- Commands a consumer always has after `kspec init`: `kspec task submit`, `kspec review get`, `kspec validate`, `kspec agent dispatch status`, etc.\n- The lifecycle and review-record model itself\n- AC annotation syntax and trait coverage semantics\n- Spec\u002Ftask\u002Fplan\u002Finbox concepts and CLI mechanics\n- Shadow branch behavior as a kspec feature\n- Generic project guidance that points to project config, project meta, or dynamic data sections instead of hard-coding values\n\n## Reviewer Checklist\n\nWhen a change touches any shared\u002Fpackage guidance surface, review **both directions** below. A change that passes one direction but fails the other is still a request_changes.\n\n### Direction 1 — Shared text must not hard-code Kynetic-only policy as universal\n\nFor every edited line or new line in shared guidance:\n\n- [ ] Branch names (`main`, `dev`, etc.) are not presented as required defaults. If a branch is named, it is framed as an example controlled by project configuration, or replaced with \"the project's integration branch\" \u002F \"the project-defined target branch\".\n- [ ] External review process (GitHub PRs, `gh` commands, `PR #...`) is not presented as universal kspec policy. Dispatched-work review is described via kspec review records and the supported merge helper; external PR policy is acknowledged as project\u002Fhuman policy when mentioned at all.\n- [ ] Repository paths used as **package-maintainer** instructions (e.g., \"edit `templates\u002Fskills\u002F\u003Cid>\u002FSKILL.md`\") do not appear in **consumer-facing** workflow text. Consumer text should direct the reader to project-local sources (`.kspec\u002Fskills\u002F`) or the matching `kspec` command.\n- [ ] Quality gates are described as \"the project-defined format\u002Flint\u002Ftype\u002Ftest gates\" or pointed at project context, not hard-coded to `npm`, oxlint, Vitest, or sharded test scripts.\n- [ ] Generated-artifact maintenance instructions (regenerate plugin copies, refresh `.factory\u002Fskills\u002F`, regenerate `kspec-agents.md` after template edits) appear only when the audience is the package maintainer, and are framed accordingly — not as universal kspec consumer workflow.\n- [ ] Agent ids (`task-worker`, `pr-reviewer`, etc.) and meta filenames (`kynetic.meta.yaml`) are not presented as guaranteed. Use \"configured worker\u002Freviewer agents\" or point readers to `kspec agent list`.\n- [ ] Runtime-specific tool names (e.g., `AskUserQuestion`) are not presented as universal. If used, frame as one possible adapter or rewrite to generic kspec mechanics.\n- [ ] Concrete workflow refs or trait refs in shared text are guaranteed by `kspec init` \u002F `kspec setup` for every consumer. If not, the reference is replaced with \"if this workflow exists in your project\" or a discovery command (`kspec item list --type trait`).\n\n### Direction 2 — Removed Kynetic-only instructions still have a project-local home\n\nFor every Kynetic-only instruction removed from or weakened in shared text:\n\n- [ ] The instruction is preserved in `AGENTS.md`, a project-local `.kspec\u002Fskills\u002F` skill attached to the relevant Kynetic agents, or a project meta convention — whichever is the right durable home.\n- [ ] The local home is reachable by future Kynetic worker\u002Freviewer agents without chat history (e.g., attached as a skill to the appropriate agent, or part of the always-rendered project context).\n- [ ] If the instruction was a procedural checklist too large for `AGENTS.md`, a project-local skill exists and is registered through `kspec meta` \u002F `kspec skill` commands.\n- [ ] Generated artifacts are regenerated (`kspec skill render`, `kspec agents generate`) if local context or shared sources changed in the same task.\n\n## Examples of Kynetic-Only Material\n\nUse these as concrete anchors when judging neutrality. They are illustrative, not exhaustive — apply the rule semantically, not as a string match.\n\n- Universal-sounding text that says \"before committing, run `npm run format:check`, `npm run lint -- --quiet`, `npm run typecheck`\" — Kynetic toolchain; describe as \"the project-defined quality gates\" in shared text and keep the concrete commands in `AGENTS.md` or `\u002Fwork-gates`.\n- Universal-sounding text that says \"rebase onto `dev`\" or \"open a PR against `main`\" — Kynetic branch\u002Freview policy; describe as \"the project-defined integration branch\" \u002F \"the project's review process\" in shared text.\n- Universal-sounding text that says \"edit `templates\u002Fskills\u002F\u003Cname>\u002FSKILL.md` to change a skill\" — Kynetic package-maintainer instruction; consumers should be directed to project-local skill sources and the supported `kspec skill` commands.\n- Universal-sounding text that names `task-worker`, `pr-reviewer`, or `kynetic.meta.yaml` — Kynetic-specific identifiers; describe as \"the configured worker\u002Freviewer agents\" and point at `kspec agent list`.\n- Universal-sounding text that uses `AskUserQuestion`, `gh pr create`, or `PR #1234` — runtime-specific or external-system-specific; rewrite to neutral kspec mechanics.\n- Universal-sounding text that references `@workflow-...` or `@trait-...` refs that are not seeded by every `kspec setup` — replace with discovery commands or \"if this workflow\u002Ftrait exists in your project\".\n\n## Why Prose-Neutrality Tests Are Insufficient\n\nDo not accept \"the markdown scanner passes\" as evidence of neutrality, and do not request that the worker add such a scanner unless the work was specifically scoped to add one. Reasons:\n\n- Wording changes frequently; string lists rot.\n- Semantically equivalent leaks can evade a denylist (e.g., \"the typical integration branch\" still implies a Kynetic-shaped default).\n- False positives on legitimate kspec mechanics produce churn and erode trust.\n- Mechanical render\u002Finstall\u002Fupdate tests cover **artifact consistency**, not prose neutrality. They are still required for that purpose; they are not a substitute for semantic review.\n\nApply this skill semantically. If a future hardening plan introduces a narrow lint for obvious forbidden tokens, that is supplementary, not a replacement for reviewer judgment.\n\n## Verdict Guidance\n\nApply existing severity classes from `\u002Freview-gates`:\n\n- **MUST-FIX** — shared text hard-codes Kynetic-only policy as universal, OR a Kynetic-only instruction was removed without a project-local home. Either failure breaks the contract this skill protects.\n- **SHOULD-FIX** — wording is neutral but a discovery command, dynamic-data pointer, or local-home pointer would make the guidance noticeably clearer for consumers or future Kynetic agents.\n- **SUGGESTION** — pure style\u002Fphrasing improvement with no neutrality implication.\n\nWhen a change is mixed (some neutral edits, some leaks), submit `request_changes` and identify each direction-1 \u002F direction-2 finding in its own thread so the worker can address them in one pass.\n\n## Evidence Log Addition\n\nFor changes touching shared\u002Fpackage guidance surfaces, the review evidence log (required by `\u002Freview-gates`) must additionally record:\n\n- Which shared\u002Fpackage surfaces were touched.\n- Which direction-1 \u002F direction-2 checks were applied.\n- Where any preserved Kynetic-only instruction now lives (file or meta ref).\n- Confirmation that generated artifacts (`kspec skill render`, `kspec agents generate`) were refreshed if local or shared sources changed.\n","\u003C!-- kspec-managed -->\n# Shared-Guidance Neutrality\n\nReviewer checklist for changes to package-shipped or shared guidance surfaces in this self-hosting repository. Enforces semantic project-neutrality and ensures any Kynetic-only instruction removed from shared text has a project-local home.\n\n## When This Skill Applies\n\nApply this checklist whenever a task or plan changes any of these **shared\u002Fpackage guidance surfaces**:\n\n- `templates\u002Fskills\u002F` — package core skill sources\n- `templates\u002Fskills\u002Fmanifest.yaml` — package skill manifest\n- `templates\u002Fagents-sections\u002F` — static agent-instruction sections shipped with the package\n- `plugin\u002Fplugins\u002Fkspec\u002Fskills\u002F` — package plugin skill copies shipped to consumers\n- Rendered package\u002Fcore skill outputs under `.agents\u002Fskills\u002F` when their source is a package core skill (the `kspec-` prefixed entries), NOT a project-local `.kspec\u002Fskills\u002F` skill\n- Rendered package\u002Fcore skill outputs under `.factory\u002Fskills\u002F` when they are generated from package core skill sources\n- Generated `kspec-agents.md` sections that come from package templates (the `templates\u002Fagents-sections\u002F` outputs)\n\nIt does NOT apply to project-local skills (`.kspec\u002Fskills\u002F`), project meta conventions, `AGENTS.md`, or other project-local context — those surfaces are expected to carry Kynetic self-hosting policy.\n\n## Why This Exists\n\nThis repository is self-hosting: it both ships the kspec package and uses kspec to manage its own work. Shared guidance surfaces are consumed by every kspec project, not just Kynetic. When Kynetic self-hosting policy leaks into shared text, every consumer is taught Kynetic's branch names, source paths, toolchain, and review policy as if they were universal kspec mechanics.\n\nThis neutrality is a **semantic property of prose**. String scanners can be evaded by paraphrasing and produce false positives on legitimate uses (e.g., kspec docs naturally mention `kspec` commands). Reviewer judgment is the durable enforcement mechanism; this skill encodes the judgment criteria.\n\n## The Semantic Review Rule\n\nPackage-shipped guidance describes **universal kspec mechanics only**.\n\nThe following classes of instruction belong in **project-local context** (`AGENTS.md`, project-local `.kspec\u002Fskills\u002F`, or project meta conventions), not in shared\u002Fpackage guidance:\n\n| Class | Belongs in shared guidance? | Examples (must NOT appear as universal in shared text) |\n|---|---|---|\n| Branch policy | No | `main`, `dev`, \"rebase onto `dev`\", \"PR against `main`\" |\n| External review policy | No | \"open a GitHub PR\", `gh pr create`, `PR #...` references |\n| Repo\u002Fsource paths | No (when describing consumer workflow) | `templates\u002Fskills\u002F`, `src\u002Fparser\u002Fvalidate.ts`, `packages\u002Fweb-ui\u002F` presented as places the consumer must edit |\n| Toolchain\u002Fquality gates | No | `npm test`, `npm run lint`, `npm run typecheck`, oxlint, Vitest specifics |\n| Generated-artifact maintenance rules | No (consumer doesn't generate package artifacts) | \"regenerate `kspec-agents.md` after editing `templates\u002Fskills\u002F`\", `.factory\u002Fskills\u002F` refresh rules |\n| Dispatch workflow choices | No (when policy not mechanism) | \"do NOT create GitHub PRs for dispatched work\" as universal |\n| Fixed agent ids | No | hard-coded `task-worker`, `pr-reviewer`, `kynetic.meta.yaml` references presented as guaranteed |\n| Runtime-specific tool names | No (when not universally available) | `AskUserQuestion` and other adapter-specific tool names |\n| Concrete workflow\u002Ftrait refs | No (unless universally seeded) | refs like `@trait-foo` presented as guaranteed when `kspec setup` doesn't seed them for every consumer |\n\nUniversal kspec **mechanics** (always allowed in shared text):\n\n- Commands a consumer always has after `kspec init`: `kspec task submit`, `kspec review get`, `kspec validate`, `kspec agent dispatch status`, etc.\n- The lifecycle and review-record model itself\n- AC annotation syntax and trait coverage semantics\n- Spec\u002Ftask\u002Fplan\u002Finbox concepts and CLI mechanics\n- Shadow branch behavior as a kspec feature\n- Generic project guidance that points to project config, project meta, or dynamic data sections instead of hard-coding values\n\n## Reviewer Checklist\n\nWhen a change touches any shared\u002Fpackage guidance surface, review **both directions** below. A change that passes one direction but fails the other is still a request_changes.\n\n### Direction 1 — Shared text must not hard-code Kynetic-only policy as universal\n\nFor every edited line or new line in shared guidance:\n\n- [ ] Branch names (`main`, `dev`, etc.) are not presented as required defaults. If a branch is named, it is framed as an example controlled by project configuration, or replaced with \"the project's integration branch\" \u002F \"the project-defined target branch\".\n- [ ] External review process (GitHub PRs, `gh` commands, `PR #...`) is not presented as universal kspec policy. Dispatched-work review is described via kspec review records and the supported merge helper; external PR policy is acknowledged as project\u002Fhuman policy when mentioned at all.\n- [ ] Repository paths used as **package-maintainer** instructions (e.g., \"edit `templates\u002Fskills\u002F\u003Cid>\u002FSKILL.md`\") do not appear in **consumer-facing** workflow text. Consumer text should direct the reader to project-local sources (`.kspec\u002Fskills\u002F`) or the matching `kspec` command.\n- [ ] Quality gates are described as \"the project-defined format\u002Flint\u002Ftype\u002Ftest gates\" or pointed at project context, not hard-coded to `npm`, oxlint, Vitest, or sharded test scripts.\n- [ ] Generated-artifact maintenance instructions (regenerate plugin copies, refresh `.factory\u002Fskills\u002F`, regenerate `kspec-agents.md` after template edits) appear only when the audience is the package maintainer, and are framed accordingly — not as universal kspec consumer workflow.\n- [ ] Agent ids (`task-worker`, `pr-reviewer`, etc.) and meta filenames (`kynetic.meta.yaml`) are not presented as guaranteed. Use \"configured worker\u002Freviewer agents\" or point readers to `kspec agent list`.\n- [ ] Runtime-specific tool names (e.g., `AskUserQuestion`) are not presented as universal. If used, frame as one possible adapter or rewrite to generic kspec mechanics.\n- [ ] Concrete workflow refs or trait refs in shared text are guaranteed by `kspec init` \u002F `kspec setup` for every consumer. If not, the reference is replaced with \"if this workflow exists in your project\" or a discovery command (`kspec item list --type trait`).\n\n### Direction 2 — Removed Kynetic-only instructions still have a project-local home\n\nFor every Kynetic-only instruction removed from or weakened in shared text:\n\n- [ ] The instruction is preserved in `AGENTS.md`, a project-local `.kspec\u002Fskills\u002F` skill attached to the relevant Kynetic agents, or a project meta convention — whichever is the right durable home.\n- [ ] The local home is reachable by future Kynetic worker\u002Freviewer agents without chat history (e.g., attached as a skill to the appropriate agent, or part of the always-rendered project context).\n- [ ] If the instruction was a procedural checklist too large for `AGENTS.md`, a project-local skill exists and is registered through `kspec meta` \u002F `kspec skill` commands.\n- [ ] Generated artifacts are regenerated (`kspec skill render`, `kspec agents generate`) if local context or shared sources changed in the same task.\n\n## Examples of Kynetic-Only Material\n\nUse these as concrete anchors when judging neutrality. They are illustrative, not exhaustive — apply the rule semantically, not as a string match.\n\n- Universal-sounding text that says \"before committing, run `npm run format:check`, `npm run lint -- --quiet`, `npm run typecheck`\" — Kynetic toolchain; describe as \"the project-defined quality gates\" in shared text and keep the concrete commands in `AGENTS.md` or `\u002Fwork-gates`.\n- Universal-sounding text that says \"rebase onto `dev`\" or \"open a PR against `main`\" — Kynetic branch\u002Freview policy; describe as \"the project-defined integration branch\" \u002F \"the project's review process\" in shared text.\n- Universal-sounding text that says \"edit `templates\u002Fskills\u002F\u003Cname>\u002FSKILL.md` to change a skill\" — Kynetic package-maintainer instruction; consumers should be directed to project-local skill sources and the supported `kspec skill` commands.\n- Universal-sounding text that names `task-worker`, `pr-reviewer`, or `kynetic.meta.yaml` — Kynetic-specific identifiers; describe as \"the configured worker\u002Freviewer agents\" and point at `kspec agent list`.\n- Universal-sounding text that uses `AskUserQuestion`, `gh pr create`, or `PR #1234` — runtime-specific or external-system-specific; rewrite to neutral kspec mechanics.\n- Universal-sounding text that references `@workflow-...` or `@trait-...` refs that are not seeded by every `kspec setup` — replace with discovery commands or \"if this workflow\u002Ftrait exists in your project\".\n\n## Why Prose-Neutrality Tests Are Insufficient\n\nDo not accept \"the markdown scanner passes\" as evidence of neutrality, and do not request that the worker add such a scanner unless the work was specifically scoped to add one. Reasons:\n\n- Wording changes frequently; string lists rot.\n- Semantically equivalent leaks can evade a denylist (e.g., \"the typical integration branch\" still implies a Kynetic-shaped default).\n- False positives on legitimate kspec mechanics produce churn and erode trust.\n- Mechanical render\u002Finstall\u002Fupdate tests cover **artifact consistency**, not prose neutrality. They are still required for that purpose; they are not a substitute for semantic review.\n\nApply this skill semantically. If a future hardening plan introduces a narrow lint for obvious forbidden tokens, that is supplementary, not a replacement for reviewer judgment.\n\n## Verdict Guidance\n\nApply existing severity classes from `\u002Freview-gates`:\n\n- **MUST-FIX** — shared text hard-codes Kynetic-only policy as universal, OR a Kynetic-only instruction was removed without a project-local home. Either failure breaks the contract this skill protects.\n- **SHOULD-FIX** — wording is neutral but a discovery command, dynamic-data pointer, or local-home pointer would make the guidance noticeably clearer for consumers or future Kynetic agents.\n- **SUGGESTION** — pure style\u002Fphrasing improvement with no neutrality implication.\n\nWhen a change is mixed (some neutral edits, some leaks), submit `request_changes` and identify each direction-1 \u002F direction-2 finding in its own thread so the worker can address them in one pass.\n\n## Evidence Log Addition\n\nFor changes touching shared\u002Fpackage guidance surfaces, the review evidence log (required by `\u002Freview-gates`) must additionally record:\n\n- Which shared\u002Fpackage surfaces were touched.\n- Which direction-1 \u002F direction-2 checks were applied.\n- Where any preserved Kynetic-only instruction now lives (file or meta ref).\n- Confirmation that generated artifacts (`kspec skill render`, `kspec agents generate`) were refreshed if local or shared sources changed.\n",{"name":5,"description":7},"main","c4b0de3035f8512bba7eb0a9b4e39ea2fbd3f08e",".claude\u002Fskills\u002Fshared-guidance-neutrality",2,"https:\u002F\u002Fgithub.com\u002Flepahc\u002Fkynetic-spec","https:\u002F\u002Fgithub.com\u002Flepahc","2026-07-22 18:57:40",{"source":8,"skillName":5,"commands":35,"prompt":45,"zipAvailable":46},[36,39,42],{"tool":37,"command":38},"npx","npx skills add lepahc\u002Fkynetic-spec --skill shared-guidance-neutrality",{"tool":40,"command":41},"bunx","bunx skills add lepahc\u002Fkynetic-spec --skill shared-guidance-neutrality",{"tool":43,"command":44},"pnpm","pnpm dlx skills add lepahc\u002Fkynetic-spec --skill shared-guidance-neutrality","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Flepahc\u002Fkynetic-spec\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fshared-guidance-neutrality\u002FSKILL.md",true,[48,54,60,64],{"path":49,"resourceType":50,"resourceTypeDesc":51,"sizeBytes":52,"sourceHtmlUrl":53},"README.md","REFERENCE","参考文档",3062,"https:\u002F\u002Fgithub.com\u002Fjiayaoqijia\u002Fcryptoskill\u002Fblob\u002Fmain\u002Fskills\u002Fai-crypto\u002Fxspoonai-official-test-suggestions\u002FREADME.md",{"path":55,"resourceType":56,"resourceTypeDesc":57,"sizeBytes":58,"sourceHtmlUrl":59},"scripts\u002Fmain.py","SCRIPT","脚本",12634,"https:\u002F\u002Fgithub.com\u002Fjiayaoqijia\u002Fcryptoskill\u002Fblob\u002Fmain\u002Fskills\u002Fai-crypto\u002Fxspoonai-official-test-suggestions\u002Fscripts\u002Fmain.py",{"path":61,"resourceType":50,"resourceTypeDesc":51,"sizeBytes":62,"sourceHtmlUrl":63},"SOURCE.md",370,"https:\u002F\u002Fgithub.com\u002Fjiayaoqijia\u002Fcryptoskill\u002Fblob\u002Fmain\u002Fskills\u002Fai-crypto\u002Fxspoonai-official-test-suggestions\u002FSOURCE.md",{"path":65,"resourceType":50,"resourceTypeDesc":51,"sizeBytes":66,"sourceHtmlUrl":67},"TRUST.auto.yaml",2183,"https:\u002F\u002Fgithub.com\u002Fjiayaoqijia\u002Fcryptoskill\u002Fblob\u002Fmain\u002Fskills\u002Fai-crypto\u002Fxspoonai-official-test-suggestions\u002FTRUST.auto.yaml",[69,87,93,101,112,120],{"skillNo":70,"name":71,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":72,"categories":73,"keywords":84,"publishedAt":22},"01M6C7KCZE43MDZ74FV3A5TDCQ","writing-specs","https:\u002F\u002Fgithub.com\u002Flepahc\u002Fkynetic-spec\u002Fblob\u002Fmain\u002Ftemplates\u002Fskills\u002Fwriting-specs\u002FSKILL.md",[74,79],{"categoryNo":75,"categoryName":76,"taxonomyType":77,"taxonomyTypeDesc":78},"01JBSEEDCAT000000000000018","写作与文案","SCENARIO","使用场景",{"categoryNo":80,"categoryName":81,"taxonomyType":82,"taxonomyTypeDesc":83},"01JBSEEDCAT000000000000036","内容创作者","PROFESSION","适用职业",[85,86],"writing","writing specs",{"skillNo":88,"name":89,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":90,"categories":91,"keywords":92,"publishedAt":22},"01M6C7KAK9CBJ87PX3BCW7B7YG","triage","https:\u002F\u002Fgithub.com\u002Flepahc\u002Fkynetic-spec\u002Fblob\u002Fmain\u002Ftemplates\u002Fskills\u002Ftriage\u002FSKILL.md",[],[89],{"skillNo":94,"name":95,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":96,"categories":97,"keywords":98,"publishedAt":22},"01M6C7K89VN6FJCT8M86K56EE8","triage-inbox","https:\u002F\u002Fgithub.com\u002Flepahc\u002Fkynetic-spec\u002Fblob\u002Fmain\u002Ftemplates\u002Fskills\u002Ftriage-inbox\u002FSKILL.md",[],[89,99,100],"inbox","triage inbox",{"skillNo":102,"name":103,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":104,"categories":105,"keywords":109,"publishedAt":22},"01M6C7K6F2342AC1TJCN9PM0ZB","triage-automation","https:\u002F\u002Fgithub.com\u002Flepahc\u002Fkynetic-spec\u002Fblob\u002Fmain\u002Ftemplates\u002Fskills\u002Ftriage-automation\u002FSKILL.md",[106],{"categoryNo":107,"categoryName":108,"taxonomyType":77,"taxonomyTypeDesc":78},"01JBSEEDCAT000000000000023","Skill与智能体开发",[89,110,111],"automation","triage automation",{"skillNo":113,"name":114,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":115,"categories":116,"keywords":117,"publishedAt":22},"01M6C7K3TFQ88QQBW3PXYDHQG2","task-work","https:\u002F\u002Fgithub.com\u002Flepahc\u002Fkynetic-spec\u002Fblob\u002Fmain\u002Ftemplates\u002Fskills\u002Ftask-work\u002FSKILL.md",[],[118,119],"work","task work",{"skillNo":121,"name":122,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":123,"categories":124,"keywords":125,"publishedAt":22},"01M6C7K168CH3XJCC3PDGA9H6C","review","https:\u002F\u002Fgithub.com\u002Flepahc\u002Fkynetic-spec\u002Fblob\u002Fmain\u002Ftemplates\u002Fskills\u002Freview\u002FSKILL.md",[],[122]]