[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6CG0F0X7Y2FR2SZSXGZGT2M":3,"skill-same:01M6CG0F0X7Y2FR2SZSXGZGT2M":75},{"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":23,"publishedAt":44,"linkOnly":45,"markdownContent":46,"markdownBody":47,"frontMatter":48,"refName":49,"commitSha":50,"skillDirectory":51,"forksCount":14,"repositoryHtmlUrl":52,"repositoryHomepageUrl":6,"ownerHtmlUrl":53,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":54,"install":55,"resources":68},"01M6CG0F0X7Y2FR2SZSXGZGT2M","neko-agent-evaluation",null,"Plan, create, validate, run, and analyze script-driven evaluations and evidence-based Skill\u002FPrompt optimization for Neko Agent behavior changes. Use when work affects prompts, Skills, capability or tool routing, provider\u002Fmodel selection, AgentSession workflows, asynchronous tasks, validation\u002Frecovery, or TUI Agent event projection; also use when asked to add an Agent evaluation, verify a real Agent path, analyze a Skill\u002FPrompt quality defect, or provide Agent evaluation evidence for OpenSpec, review, or release readiness.","OpenNekoPaw\u002Fneko-suite","OpenNekoPaw","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F15809061?v=4","01M6CG05V2N1TRWA7J8N1SCXPB","NekoPaw","01M6CG05ZQR78WBSHEMA0Q0362",0,"AGPL-3.0","https:\u002F\u002Fgithub.com\u002FOpenNekoPaw\u002Fneko-suite\u002Fblob\u002Fmain\u002F.codex\u002Fskills\u002Fneko-agent-evaluation\u002FSKILL.md",[18],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43],"neko agent evaluation","agent evaluation","Evaluation","tool","openspec","selection","provider","evidence","use","prompt","model","analyze","review","Optimization","asynchronous","routing","create","tasks","model selection","workflows","2026-11-10 10:12:30",false,"---\nname: neko-agent-evaluation\ndescription: Plan, create, validate, run, and analyze script-driven evaluations and evidence-based Skill\u002FPrompt optimization for Neko Agent behavior changes. Use when work affects prompts, Skills, capability or tool routing, provider\u002Fmodel selection, AgentSession workflows, asynchronous tasks, validation\u002Frecovery, or TUI Agent event projection; also use when asked to add an Agent evaluation, verify a real Agent path, analyze a Skill\u002FPrompt quality defect, or provide Agent evaluation evidence for OpenSpec, review, or release readiness.\n---\n\n# Neko Agent Evaluation\n\nProduce path-level evidence for real Neko Agent behavior through the repository's\nexternal Evaluation platform.\n\n## Preserve Ownership\n\nTreat Neko Agent as the system under test:\n\n- Keep authoring decisions, suites, fixtures, orchestration, assertions, Judges,\n  comparisons, and reports in the repository Evaluation platform.\n- Drive the complete TUI session owner and input path. Do not import a turn runner,\n  create another session assembly, or count mock behavior as acceptance.\n- Keep runtime observability neutral. Add a generally useful runtime fact or\n  control only when the owning contract lacks evidence required beyond\n  Evaluation.\n- Do not register Evaluation authoring or execution as an Agent Skill, product\n  capability, or alternate CLI workflow.\n- Keep Market identity, versioning, publication, installation, and distribution\n  outside Evaluation. Skill targets use portable identity plus the Host-owned\n  source\u002Flocation projection and content fingerprint.\n\nBefore acting, read the relevant OpenSpec artifacts, Agent architecture, current\nEvaluation developer documentation, changed runtime code, existing indexed\nsuites, and executable runner tests. Current code and strict suite discovery are\nauthoritative when historical reports disagree.\n\n## Decide Whether Evaluation Is Required\n\nRequire focused real behavior evidence when a change can affect:\n\n- Prompt composition or Skill selection, injection, method, or output;\n- capability\u002FTool registration, routing, validation, result handling, or\n  permissions;\n- provider, model, profile, or effective runtime configuration;\n- multi-turn sessions, queues, continuation, asynchronous tasks, cancellation,\n  resume, recovery, or artifact delivery;\n- runtime evidence projected to TUI or another Agent host.\n\nUse deterministic tests instead when a change is limited to pure parsing,\nstrict schema validation, or unrelated non-Agent logic. An exclusion must name\nthe deterministic validation and explain why real Agent behavior cannot change.\n\n## Authoring Decision\n\nFor every affected behavior, choose exactly one disposition:\n\n- `reuse`: an existing suite already proves the changed contract;\n- `update`: the owner remains correct but cases, evidence, fixtures, or profiles\n  must change;\n- `create`: no suite owns the behavior and a new target-scoped suite is needed;\n- `excluded`: deterministic non-Agent validation is sufficient.\n\nUse the repository change-to-suite mapping before choosing. Do not assign an\nunmapped path to a convenient default suite. Record the user-visible behavior,\ntarget owner, selected suite, coverage delta, and rationale in the active\nchange or its Evaluation evidence.\n\nFor a Skill target, distinguish same-named project, personal, builtin, plugin,\nand Marketplace sources through the full Host identity. Bind the case to the\nHost-computed package fingerprint for the tested development snapshot. Do not\ninvent Skill semver or derive identity from an active selection.\n\n## Define Evidence Before Prompts\n\nFor each case, state:\n\n1. user behavior;\n2. canonical runtime path;\n3. observable runtime or artifact evidence;\n4. forbidden fallback;\n5. expected result;\n6. expected fail-visible behavior.\n\nEvidence should prove activation\u002Finjection, effective model\u002Fconfiguration,\nTool\u002Ftask\u002Fprocess state, durable artifact identity, diagnostics, and source\nprovenance as applicable. A final answer is evidence of output, not proof of the\npath that produced it.\n\nAudit current runtime facts and public validators before accepting the case. If\nrequired evidence is unavailable, identify the minimal neutral observability\ngap and report the case blocked. Do not substitute metadata, weak text matching,\nmanual assumptions, or silent fallback.\n\n## Select Focused Coverage\n\nStart with the smallest set that can reject an incorrect implementation:\n\n- one canonical positive case proving the new path;\n- one boundary or failure case proving unavailable, invalid, denied, disabled,\n  or wrong-target states cannot return success;\n- artifact, workflow, quality, regression, paraphrase, or holdout cases only\n  where the behavior requires them.\n\nArtifact-producing changes need durable identity and owning-validator evidence.\nPrompt and Skill changes should cover trigger paraphrases and adjacent negative\nrequests. Workflow changes should prove ordering and terminal state. Prelaunch\nreplacements should poison or explicitly reject the old path.\n\nUse deterministic hard gates for path, configuration, process, format,\npermission, artifact, and no-fallback behavior. Use an owning-domain validator\nfor real artifact quality. Use a Judge only for subjective quality after hard\ngates pass; it cannot repair or override a deterministic failure.\n\nConfiguration variants must correspond to real session-scoped product settings\nand be proven from effective runtime evidence. Do not add Evaluation-only flags.\nWhen an ablation removes an implementation rather than changing a supported\nsetting, compare isolated revisions or builds through the external platform.\n\n## Validate and Run\n\nFollow the progressive validation and execution workflow documented by the\nEvaluation platform:\n\n1. validate key-free schemas, runner semantics, assertions, reports, and every\n   indexed suite;\n2. validate the selected case without provider-backed behavior;\n3. run the same focused case through the real TUI when credentials, network,\n   model access, configuration, and fixtures are available;\n4. use repeated samples when making stability or quality claims.\n\nConcrete commands, suite\u002Fscenario fields, controller operations, assertion\nkinds, and report file layouts belong in the platform developer documentation,\nnot in this Skill.\n\n## Interpret Evidence\n\nRead assertion-level evidence before the overall outcome. Confirm:\n\n- requested and effective target\u002Fmodel\u002Fconfiguration identities match;\n- canonical-path evidence is complete and bounded fact collections did not drop\n  required observations;\n- forbidden Skills, Tools, models, adapters, legacy fields, and fallbacks did\n  not participate;\n- task\u002Fprocess state reached the expected terminal condition;\n- durable artifacts exist under stable identities and passed owning validators;\n- Judge input was allowlisted and its score remains supplemental;\n- baseline inputs are comparable before describing improvement;\n- every repetition is retained and cost availability is explicit.\n\nSeparate target behavior failure, Evaluation infrastructure failure,\nconfiguration invalidity, and non-comparability. Failure attribution is a\nhypothesis unless evidence proves the owning layer; record confidence and\nmissing evidence instead of presenting guesses as root cause.\n\n## Optimize From Evidence\n\nOptimize Prompt or Skill content only after Evaluation evidence identifies an\nobserved content-quality failure and supports its owner. Preserve the observed\nfailure, suspected owner, confidence, evidence references, and missing evidence\nas separate facts. Route Capability or Tool, runtime or session, provider,\nartifact, and Evaluation infrastructure defects to their canonical owners;\ndo not compensate for them with Prompt wording. Treat Prompt routing as\noptimizable only when independent evidence confirms Prompt ownership.\n\nFor a Skill, bind every development state to its complete Host identity and\nHost-computed package fingerprint. Keep same-named project, personal, builtin,\nplugin, and Marketplace sources distinct. Record only explicit baseline,\ncandidate, evaluated, accepted, rejected, or superseded checkpoints; do not\nturn ordinary file saves into versions. Carry continuity across a rename or\nmove only through explicit lineage. Keep this development history outside the\nportable Skill package, and keep package versions, publication, installation,\nand distribution in Market ownership.\n\nProduce a reviewable plan and candidate artifact without changing canonical\ncontent. Require explicit human approval bound to the identity, base and\ncandidate fingerprints, scope, budget, and protected Evaluation matrix. Apply\nan approved candidate through the normal repository change workflow, then\ncompare isolated baseline and candidate targets with matching policies. Hide\ncandidate identity from comparative Judges and from optimizer-hidden holdouts.\n\nAccept a candidate only when canonical path hard gates, holdout cases, protected\nregressions, and real output-content quality evidence all pass. Formatting,\nlatency, token use, cost, or a favorable visible-case average cannot override a\nprotected failure. Stop at candidate, iteration, time, token, cost, or\nno-improvement limits, and never retry a behavior failure into success. Record\naccepted and rejected outcomes with their evidence and remaining bias or\noverfitting risk; local acceptance is not Market publication.\n\n## Record Residual Risk\n\nRecord the suite\u002Fcase\u002Frun, real execution attempted, target and model identities,\npath and no-fallback evidence, artifact evidence, quality stage, report location,\nusage\u002Fcost availability, blocked or skipped cases, and remaining risk.\n\nKey-free validation, dry-run selection, mock output, direct turn injection, a\ngood final answer, or a single Judge score are not real Agent behavior\nacceptance. When infrastructure is unavailable, preserve the exact blocker and\nthe behavior still unverified.\n\n## Output Format\n\n```text\nEvaluation Scope\n- Change\u002Ffeature:\n- Decision and owning suite:\n- Why real Evaluation is or is not required:\n- Canonical path and forbidden fallback:\n\nCases\n- Reused, updated, created, or excluded:\n- Evidence and coverage:\n- Missing observability:\n\nVerification\n- Key-free validation:\n- Real cases and reports:\n- Blocked or unexecuted cases:\n\nInterpretation\n- Result and quality comparison:\n- Confirmed failures vs attribution hypotheses:\n\nResidual Risk\n- ...\n```\n","# Neko Agent Evaluation\n\nProduce path-level evidence for real Neko Agent behavior through the repository's\nexternal Evaluation platform.\n\n## Preserve Ownership\n\nTreat Neko Agent as the system under test:\n\n- Keep authoring decisions, suites, fixtures, orchestration, assertions, Judges,\n  comparisons, and reports in the repository Evaluation platform.\n- Drive the complete TUI session owner and input path. Do not import a turn runner,\n  create another session assembly, or count mock behavior as acceptance.\n- Keep runtime observability neutral. Add a generally useful runtime fact or\n  control only when the owning contract lacks evidence required beyond\n  Evaluation.\n- Do not register Evaluation authoring or execution as an Agent Skill, product\n  capability, or alternate CLI workflow.\n- Keep Market identity, versioning, publication, installation, and distribution\n  outside Evaluation. Skill targets use portable identity plus the Host-owned\n  source\u002Flocation projection and content fingerprint.\n\nBefore acting, read the relevant OpenSpec artifacts, Agent architecture, current\nEvaluation developer documentation, changed runtime code, existing indexed\nsuites, and executable runner tests. Current code and strict suite discovery are\nauthoritative when historical reports disagree.\n\n## Decide Whether Evaluation Is Required\n\nRequire focused real behavior evidence when a change can affect:\n\n- Prompt composition or Skill selection, injection, method, or output;\n- capability\u002FTool registration, routing, validation, result handling, or\n  permissions;\n- provider, model, profile, or effective runtime configuration;\n- multi-turn sessions, queues, continuation, asynchronous tasks, cancellation,\n  resume, recovery, or artifact delivery;\n- runtime evidence projected to TUI or another Agent host.\n\nUse deterministic tests instead when a change is limited to pure parsing,\nstrict schema validation, or unrelated non-Agent logic. An exclusion must name\nthe deterministic validation and explain why real Agent behavior cannot change.\n\n## Authoring Decision\n\nFor every affected behavior, choose exactly one disposition:\n\n- `reuse`: an existing suite already proves the changed contract;\n- `update`: the owner remains correct but cases, evidence, fixtures, or profiles\n  must change;\n- `create`: no suite owns the behavior and a new target-scoped suite is needed;\n- `excluded`: deterministic non-Agent validation is sufficient.\n\nUse the repository change-to-suite mapping before choosing. Do not assign an\nunmapped path to a convenient default suite. Record the user-visible behavior,\ntarget owner, selected suite, coverage delta, and rationale in the active\nchange or its Evaluation evidence.\n\nFor a Skill target, distinguish same-named project, personal, builtin, plugin,\nand Marketplace sources through the full Host identity. Bind the case to the\nHost-computed package fingerprint for the tested development snapshot. Do not\ninvent Skill semver or derive identity from an active selection.\n\n## Define Evidence Before Prompts\n\nFor each case, state:\n\n1. user behavior;\n2. canonical runtime path;\n3. observable runtime or artifact evidence;\n4. forbidden fallback;\n5. expected result;\n6. expected fail-visible behavior.\n\nEvidence should prove activation\u002Finjection, effective model\u002Fconfiguration,\nTool\u002Ftask\u002Fprocess state, durable artifact identity, diagnostics, and source\nprovenance as applicable. A final answer is evidence of output, not proof of the\npath that produced it.\n\nAudit current runtime facts and public validators before accepting the case. If\nrequired evidence is unavailable, identify the minimal neutral observability\ngap and report the case blocked. Do not substitute metadata, weak text matching,\nmanual assumptions, or silent fallback.\n\n## Select Focused Coverage\n\nStart with the smallest set that can reject an incorrect implementation:\n\n- one canonical positive case proving the new path;\n- one boundary or failure case proving unavailable, invalid, denied, disabled,\n  or wrong-target states cannot return success;\n- artifact, workflow, quality, regression, paraphrase, or holdout cases only\n  where the behavior requires them.\n\nArtifact-producing changes need durable identity and owning-validator evidence.\nPrompt and Skill changes should cover trigger paraphrases and adjacent negative\nrequests. Workflow changes should prove ordering and terminal state. Prelaunch\nreplacements should poison or explicitly reject the old path.\n\nUse deterministic hard gates for path, configuration, process, format,\npermission, artifact, and no-fallback behavior. Use an owning-domain validator\nfor real artifact quality. Use a Judge only for subjective quality after hard\ngates pass; it cannot repair or override a deterministic failure.\n\nConfiguration variants must correspond to real session-scoped product settings\nand be proven from effective runtime evidence. Do not add Evaluation-only flags.\nWhen an ablation removes an implementation rather than changing a supported\nsetting, compare isolated revisions or builds through the external platform.\n\n## Validate and Run\n\nFollow the progressive validation and execution workflow documented by the\nEvaluation platform:\n\n1. validate key-free schemas, runner semantics, assertions, reports, and every\n   indexed suite;\n2. validate the selected case without provider-backed behavior;\n3. run the same focused case through the real TUI when credentials, network,\n   model access, configuration, and fixtures are available;\n4. use repeated samples when making stability or quality claims.\n\nConcrete commands, suite\u002Fscenario fields, controller operations, assertion\nkinds, and report file layouts belong in the platform developer documentation,\nnot in this Skill.\n\n## Interpret Evidence\n\nRead assertion-level evidence before the overall outcome. Confirm:\n\n- requested and effective target\u002Fmodel\u002Fconfiguration identities match;\n- canonical-path evidence is complete and bounded fact collections did not drop\n  required observations;\n- forbidden Skills, Tools, models, adapters, legacy fields, and fallbacks did\n  not participate;\n- task\u002Fprocess state reached the expected terminal condition;\n- durable artifacts exist under stable identities and passed owning validators;\n- Judge input was allowlisted and its score remains supplemental;\n- baseline inputs are comparable before describing improvement;\n- every repetition is retained and cost availability is explicit.\n\nSeparate target behavior failure, Evaluation infrastructure failure,\nconfiguration invalidity, and non-comparability. Failure attribution is a\nhypothesis unless evidence proves the owning layer; record confidence and\nmissing evidence instead of presenting guesses as root cause.\n\n## Optimize From Evidence\n\nOptimize Prompt or Skill content only after Evaluation evidence identifies an\nobserved content-quality failure and supports its owner. Preserve the observed\nfailure, suspected owner, confidence, evidence references, and missing evidence\nas separate facts. Route Capability or Tool, runtime or session, provider,\nartifact, and Evaluation infrastructure defects to their canonical owners;\ndo not compensate for them with Prompt wording. Treat Prompt routing as\noptimizable only when independent evidence confirms Prompt ownership.\n\nFor a Skill, bind every development state to its complete Host identity and\nHost-computed package fingerprint. Keep same-named project, personal, builtin,\nplugin, and Marketplace sources distinct. Record only explicit baseline,\ncandidate, evaluated, accepted, rejected, or superseded checkpoints; do not\nturn ordinary file saves into versions. Carry continuity across a rename or\nmove only through explicit lineage. Keep this development history outside the\nportable Skill package, and keep package versions, publication, installation,\nand distribution in Market ownership.\n\nProduce a reviewable plan and candidate artifact without changing canonical\ncontent. Require explicit human approval bound to the identity, base and\ncandidate fingerprints, scope, budget, and protected Evaluation matrix. Apply\nan approved candidate through the normal repository change workflow, then\ncompare isolated baseline and candidate targets with matching policies. Hide\ncandidate identity from comparative Judges and from optimizer-hidden holdouts.\n\nAccept a candidate only when canonical path hard gates, holdout cases, protected\nregressions, and real output-content quality evidence all pass. Formatting,\nlatency, token use, cost, or a favorable visible-case average cannot override a\nprotected failure. Stop at candidate, iteration, time, token, cost, or\nno-improvement limits, and never retry a behavior failure into success. Record\naccepted and rejected outcomes with their evidence and remaining bias or\noverfitting risk; local acceptance is not Market publication.\n\n## Record Residual Risk\n\nRecord the suite\u002Fcase\u002Frun, real execution attempted, target and model identities,\npath and no-fallback evidence, artifact evidence, quality stage, report location,\nusage\u002Fcost availability, blocked or skipped cases, and remaining risk.\n\nKey-free validation, dry-run selection, mock output, direct turn injection, a\ngood final answer, or a single Judge score are not real Agent behavior\nacceptance. When infrastructure is unavailable, preserve the exact blocker and\nthe behavior still unverified.\n\n## Output Format\n\n```text\nEvaluation Scope\n- Change\u002Ffeature:\n- Decision and owning suite:\n- Why real Evaluation is or is not required:\n- Canonical path and forbidden fallback:\n\nCases\n- Reused, updated, created, or excluded:\n- Evidence and coverage:\n- Missing observability:\n\nVerification\n- Key-free validation:\n- Real cases and reports:\n- Blocked or unexecuted cases:\n\nInterpretation\n- Result and quality comparison:\n- Confirmed failures vs attribution hypotheses:\n\nResidual Risk\n- ...\n```\n",{"name":5,"description":7},"main","9204f2e36f084a956241ea3f8e76080c07989947",".codex\u002Fskills\u002Fneko-agent-evaluation","https:\u002F\u002Fgithub.com\u002FOpenNekoPaw\u002Fneko-suite","https:\u002F\u002Fgithub.com\u002FOpenNekoPaw","2026-07-16 01:36:41",{"source":8,"skillName":5,"commands":56,"prompt":66,"zipAvailable":67},[57,60,63],{"tool":58,"command":59},"npx","npx skills add OpenNekoPaw\u002Fneko-suite --skill neko-agent-evaluation",{"tool":61,"command":62},"bunx","bunx skills add OpenNekoPaw\u002Fneko-suite --skill neko-agent-evaluation",{"tool":64,"command":65},"pnpm","pnpm dlx skills add OpenNekoPaw\u002Fneko-suite --skill neko-agent-evaluation","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FOpenNekoPaw\u002Fneko-suite\u002Fblob\u002Fmain\u002F.codex\u002Fskills\u002Fneko-agent-evaluation\u002FSKILL.md",true,[69],{"path":70,"resourceType":71,"resourceTypeDesc":72,"sizeBytes":73,"sourceHtmlUrl":74},"agents\u002Fopenai.yaml","REFERENCE","参考文档",242,"https:\u002F\u002Fgithub.com\u002FOpenNekoPaw\u002Fneko-suite\u002Fblob\u002Fmain\u002F.codex\u002Fskills\u002Fneko-agent-evaluation\u002Fagents\u002Fopenai.yaml",[76,107,114,122,132,148],{"skillNo":77,"name":78,"nameZh":6,"description":79,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":80,"categories":81,"keywords":87,"publishedAt":44},"01M6CG11R2EF1EVSYN54S4QYFX","vscode-extension-debugger","This skill enables debugging VS Code extensions and their webviews through Chrome DevTools Protocol (CDP).\nIt should be used when:\n- Debugging VS Code extension webviews (custom editors, panels, sidebars)\n- Inspecting DOM structure of extension webviews\n- Taking screenshots of VS Code windows or webviews\n- Executing JavaScript in extension webviews\n- Monitoring console output from extensions\nTriggers on: \"debug extension\", \"inspect webview\", \"extension screenshot\", \"webview DOM\", \"VS Code debugging\"","https:\u002F\u002Fgithub.com\u002FOpenNekoPaw\u002Fneko-suite\u002Fblob\u002Fmain\u002Fskills\u002Fvscode-extension-debugger\u002FSKILL.md",[82],{"categoryNo":83,"categoryName":84,"taxonomyType":85,"taxonomyTypeDesc":86},"01JBSEEDCAT000000000000030","开发工程师","PROFESSION","适用职业",[88,89,90,91,92,93,94,95,96,97,98,99,100,101,102,103,104,105,106],"vscode extension debugger","vscode","vscode extension","debugger","windows","cdp","screenshots","chrome","javascript","chrome devtools","monitoring","debug extension","debug","debugging","code","console","protocol","screenshot","devtools",{"skillNo":108,"name":36,"nameZh":6,"description":109,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":110,"categories":111,"keywords":112,"publishedAt":44},"01M6CG10F0FAXC8QY4H4FTKGEE","Review functional Home artifacts.","https:\u002F\u002Fgithub.com\u002FOpenNekoPaw\u002Fneko-suite\u002Fblob\u002Fmain\u002Fscripts\u002Fwebview-functional\u002Ffixtures\u002Fhome\u002F.agents\u002Fskills\u002Freview\u002FSKILL.md",[],[36,113],"artifacts",{"skillNo":115,"name":116,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":117,"categories":118,"keywords":119,"publishedAt":44},"01M6CG0YY2R6ZTQ20MBNMP2MM3","eval-existing-target-skill","https:\u002F\u002Fgithub.com\u002FOpenNekoPaw\u002Fneko-suite\u002Fblob\u002Fmain\u002Fscripts\u002Fagent-eval\u002Fshared-fixtures\u002Fskill-existing-target-workspace\u002F.agents\u002Fskills\u002Feval-existing-target-skill\u002FSKILL.md",[],[120,121],"eval existing target skill","eval",{"skillNo":123,"name":124,"nameZh":6,"description":125,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":126,"categories":127,"keywords":128,"publishedAt":44},"01M6CG0XK0G6FC21JSG8DBN31B","evaluation-artifact-author","Author a deterministic portable Skill package when the user requests evaluation artifact evidence.","https:\u002F\u002Fgithub.com\u002FOpenNekoPaw\u002Fneko-suite\u002Fblob\u002Fmain\u002Fscripts\u002Fagent-eval\u002Fshared-fixtures\u002Fskill-artifact-workspace\u002F.agents\u002Fskills\u002Fevaluation-artifact-author\u002FSKILL.md",[],[129,26,31,130,131],"evaluation artifact author","package","user",{"skillNo":133,"name":134,"nameZh":6,"description":135,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":136,"licenseFileUrl":6,"sourceHtmlUrl":137,"categories":138,"keywords":139,"publishedAt":44},"01M6CG0VBX3TK0J87H9DXX9758","openspec-propose","Propose a new change with all artifacts generated in one step. Use when the user wants to quickly describe what they want to build and get a complete proposal with design, specs, and tasks ready for implementation.","MIT","https:\u002F\u002Fgithub.com\u002FOpenNekoPaw\u002Fneko-suite\u002Fblob\u002Fmain\u002F.codex\u002Fskills\u002Fopenspec-propose\u002FSKILL.md",[],[28,140,113,141,142,143,41,131,144,32,145,146,147],"openspec propose","design","cli","change","generated","ready","implementation","build",{"skillNo":149,"name":150,"nameZh":6,"description":151,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":136,"licenseFileUrl":6,"sourceHtmlUrl":152,"categories":153,"keywords":154,"publishedAt":44},"01M6CG0S1NP7PBG7SP5WH3WA22","openspec-explore","Enter explore mode - a thinking partner for exploring ideas, investigating problems, and clarifying requirements. Use when the user wants to think through something before or during a change.","https:\u002F\u002Fgithub.com\u002FOpenNekoPaw\u002Fneko-suite\u002Fblob\u002Fmain\u002F.codex\u002Fskills\u002Fopenspec-explore\u002FSKILL.md",[],[155,156,28,143,131,32,157,158,142],"openspec explore","explore","think","thinking partner"]