[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M7DME9MB03N3RTZ05FS91MF8":3,"skill-same:01M7DME9MB03N3RTZ05FS91MF8":45},{"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":17,"publishedAt":18,"linkOnly":19,"markdownContent":20,"markdownBody":21,"frontMatter":22,"refName":24,"commitSha":25,"skillDirectory":26,"forksCount":27,"repositoryHtmlUrl":28,"repositoryHomepageUrl":29,"ownerHtmlUrl":30,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":31,"install":32,"resources":44},"01M7DME9MB03N3RTZ05FS91MF8","correct",null,"找出这个仓库里代理反复犯的错，并让每一种都没法再犯。先改架构，再靠类型，再靠点名改法的 lint，然后测试，文档放最后。用于 \u002Fcorrect。","fenfenxu\u002Fpstack-zh","fenfenxu","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F2194243?v=4","01M7DMDSWBASX3NXC18FPHDJ8G","01M7DMDSWV8ASCZ4PH6YFXHPSJ",3,"MIT","https:\u002F\u002Fgithub.com\u002Ffenfenxu\u002Fpstack-zh\u002Fblob\u002Fmain\u002Fskills\u002Fcorrect\u002FSKILL.md",[],[],"2026-11-15 14:19:17",false,"---\nname: correct\ndescription: \"找出这个仓库里代理反复犯的错，并让每一种都没法再犯。先改架构，再靠类型，再靠点名改法的 lint，然后测试，文档放最后。用于 \u002Fcorrect。\"\ndisable-model-invocation: true\n---\n\n# Correct\n\n操作者一直在这个仓库里纠正代理犯同样的错。改这个仓库，让下一个代理没法再犯。\n\n假定每个贡献者都是代理。它只看见自己打开的文件，抄最近的例子，走能编译通过的最短路径。把仓库设计成这样：从单个文件看起来对的改动，对整个仓库也是对的。\n\n## 找出错误类别\n\n先读最近的提交、回退、评审评论、给代理的说明文件，以及解释绕过做法的注释。把错误分成几类。同一类发生过两次，才算一类。\n\n## 在够用的最高一层修好每一类\n\n1. **用架构消掉它。** 每一份状态只留一个所有者，每一项任务只留一种支持的做法。藏住内部，让错误的导入失败。把靠人手同步的多份清单换成唯一的一份。删掉旧做法，以及代理会去抄的死代码。\n2. **用类型挡住，让坏状态写不进去。** 如果坏代码还能编译通过，就加一条 lint 或 CI 检查，报错里点名该改用的文件、类型或函数。这种写法已经很常见时，只在这次改动又多加一处时才让检查失败。\n3. **用测试卡住行为。** 某个测试在它检查的行为坏掉时仍然能通过，或者只有内部实现变了它就失败，就修好或删掉这个测试。\n4. **最后才写文档或给代理的规则，而且只写需要判断的情况。** 代理跳过它们，什么检查都不会失败。\n\n## 修好，并证明检查会失败\n\n然后现在就修最常见的几类，每类一次提交。每条新检查都要用一次真实犯过的错证明它会失败。同一条命令在本地和 CI 里都跑。例外写在出错的那一行，带上原因、到期日，以及一个人的批准。\n\n## 留一张规则对照表\n\n最后，在给代理的说明文件里留一张表，把每条规则和卡住它的机制配在一起。操作者纠正你时，修好这个错，并补上规则。规则已经在表里、却没有东西去卡住它，这就是重复发生，所以在同一次改动里，在够用的最高一层修掉。某类错误已经不可能发生时，删掉对应的规则。\n\n**回复：** 每一类错误、它的证据、你选的那一层，以及为什么更高一层行不通。\n","# Correct\n\n操作者一直在这个仓库里纠正代理犯同样的错。改这个仓库，让下一个代理没法再犯。\n\n假定每个贡献者都是代理。它只看见自己打开的文件，抄最近的例子，走能编译通过的最短路径。把仓库设计成这样：从单个文件看起来对的改动，对整个仓库也是对的。\n\n## 找出错误类别\n\n先读最近的提交、回退、评审评论、给代理的说明文件，以及解释绕过做法的注释。把错误分成几类。同一类发生过两次，才算一类。\n\n## 在够用的最高一层修好每一类\n\n1. **用架构消掉它。** 每一份状态只留一个所有者，每一项任务只留一种支持的做法。藏住内部，让错误的导入失败。把靠人手同步的多份清单换成唯一的一份。删掉旧做法，以及代理会去抄的死代码。\n2. **用类型挡住，让坏状态写不进去。** 如果坏代码还能编译通过，就加一条 lint 或 CI 检查，报错里点名该改用的文件、类型或函数。这种写法已经很常见时，只在这次改动又多加一处时才让检查失败。\n3. **用测试卡住行为。** 某个测试在它检查的行为坏掉时仍然能通过，或者只有内部实现变了它就失败，就修好或删掉这个测试。\n4. **最后才写文档或给代理的规则，而且只写需要判断的情况。** 代理跳过它们，什么检查都不会失败。\n\n## 修好，并证明检查会失败\n\n然后现在就修最常见的几类，每类一次提交。每条新检查都要用一次真实犯过的错证明它会失败。同一条命令在本地和 CI 里都跑。例外写在出错的那一行，带上原因、到期日，以及一个人的批准。\n\n## 留一张规则对照表\n\n最后，在给代理的说明文件里留一张表，把每条规则和卡住它的机制配在一起。操作者纠正你时，修好这个错，并补上规则。规则已经在表里、却没有东西去卡住它，这就是重复发生，所以在同一次改动里，在够用的最高一层修掉。某类错误已经不可能发生时，删掉对应的规则。\n\n**回复：** 每一类错误、它的证据、你选的那一层，以及为什么更高一层行不通。\n",{"name":5,"description":7,"disable-model-invocation":23},true,"main","e4477188d43269545432a83e4ac5d0733a812d09","skills\u002Fcorrect",0,"https:\u002F\u002Fgithub.com\u002Ffenfenxu\u002Fpstack-zh","http:\u002F\u002Fpstack.ganhai.cloud","https:\u002F\u002Fgithub.com\u002Ffenfenxu","2026-10-21 12:14:41",{"source":8,"skillName":5,"commands":33,"prompt":43,"zipAvailable":23},[34,37,40],{"tool":35,"command":36},"npx","npx skills add fenfenxu\u002Fpstack-zh --skill correct",{"tool":38,"command":39},"bunx","bunx skills add fenfenxu\u002Fpstack-zh --skill correct",{"tool":41,"command":42},"pnpm","pnpm dlx skills add fenfenxu\u002Fpstack-zh --skill correct","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Ffenfenxu\u002Fpstack-zh\u002Fblob\u002Fmain\u002Fskills\u002Fcorrect\u002FSKILL.md",[],[46,53,60,67,74,81],{"skillNo":47,"name":48,"nameZh":6,"description":49,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":50,"categories":51,"keywords":52,"publishedAt":18},"01M7DMHJV7QMEE1F43FFW98FV8","why","用于「为什么 X 是这样实现的」「为什么选了 Y」、设计理由、回归、事后复盘，或数据支撑的阈值问题。发现可用 MCP 并并行查询各证据类别（源码控制、工单跟踪、长文文档、实时聊天、基础设施可观测性、错误跟踪、产品分析数仓），然后返回带引用的决策与权衡解读。运行时行为请用 how。","https:\u002F\u002Fgithub.com\u002Ffenfenxu\u002Fpstack-zh\u002Fblob\u002Fmain\u002Fskills\u002Fwhy\u002FSKILL.md",[],[],{"skillNo":54,"name":55,"nameZh":6,"description":56,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":57,"categories":58,"keywords":59,"publishedAt":18},"01M7DMHHRSS2SCZN6HWSANBJ35","unslop","从任意写作中剔除 AI 痕迹。","https:\u002F\u002Fgithub.com\u002Ffenfenxu\u002Fpstack-zh\u002Fblob\u002Fmain\u002Fskills\u002Funslop\u002FSKILL.md",[],[],{"skillNo":61,"name":62,"nameZh":6,"description":63,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":64,"categories":65,"keywords":66,"publishedAt":18},"01M7DMHGFGH2YT86WQ6A53693W","typescript-best-practices","TypeScript 最佳实践。读取或编辑任意 .ts 或 .tsx 文件时使用。","https:\u002F\u002Fgithub.com\u002Ffenfenxu\u002Fpstack-zh\u002Fblob\u002Fmain\u002Fskills\u002Ftypescript-best-practices\u002FSKILL.md",[],[],{"skillNo":68,"name":69,"nameZh":6,"description":70,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":71,"categories":72,"keywords":73,"publishedAt":18},"01M7DMHEA1EGG2D9XQ33N66GDS","technical-writing","分层技术写作标准：Diátaxis 结构、Google 开发者风格句子、STE 指令规则、Global English 句法。用于 \u002Ftechnical-writing，或撰写\u002F审查文档、RFC、README、PR 描述、commit message 时。","https:\u002F\u002Fgithub.com\u002Ffenfenxu\u002Fpstack-zh\u002Fblob\u002Fmain\u002Fskills\u002Ftechnical-writing\u002FSKILL.md",[],[],{"skillNo":75,"name":76,"nameZh":6,"description":77,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":78,"categories":79,"keywords":80,"publishedAt":18},"01M7DMHCEXE1YRDR6XC1RXBG76","teach","用平实语言解释一段工作，让人真正理解。运行 how 与 why skill，把发现织成一份清晰说明。用于「teach me this」「help me really understand X」「explain this change or subsystem to me」。","https:\u002F\u002Fgithub.com\u002Ffenfenxu\u002Fpstack-zh\u002Fblob\u002Fmain\u002Fskills\u002Fteach\u002FSKILL.md",[],[],{"skillNo":82,"name":83,"nameZh":6,"description":84,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":85,"categories":86,"keywords":87,"publishedAt":18},"01M7DMH9KNBP83SHAW4TGZ4713","tdd","仅当用户明确要求 TDD、失败测试或回归测试时使用，或 bug 有明显且廉价的本地测试目标时使用。测试路径不清、昂贵、偏集成或未要求时跳过。","https:\u002F\u002Fgithub.com\u002Ffenfenxu\u002Fpstack-zh\u002Fblob\u002Fmain\u002Fskills\u002Ftdd\u002FSKILL.md",[],[]]