一家社区工具借用站有一个预约日历。新维护者让 Claude Code 修复「取消预约后日期仍显示已满」的问题，助手却先改样式，再改缓存，始终没有固定复现步骤。开发者入门 Skill 的第一项练习，可以把这样的任务改造成有证据的调试、有限的代码修改和可重跑的测试。以下只用本地副本、虚构预约与练习分支，最后再把稳定步骤沉淀成自己的项目方法。
先学会判断技能有没有真正参与任务
Skill 是方法说明与资源的包，可能包含脚本。它与 IDE 扩展的安装、界面和运行机制不同，实际能做什么还取决于宿主提供的工具。先写任务卡：取消一个虚构预约后，日历应显示释放的名额；允许修改预约状态与日历读取路径，其他费用和通知逻辑暂不纳入。保存当前构建、运行方式和一条已知正常预约，作为后续比较基线。
需要寻找候选时先检查是否已有 SkillPI Skill Finder。没有时阅读官方仓库说明，按当前宿主支持的方式安装启用。把任务、语言、测试框架、允许目录与产物要求交给它，要求返回来源、版本和不适配条件。不要照着相似名字安装一个无法查看的包。阅读实际 SKILL.md、附带脚本和依赖后，记录来源版本与安装位置，再按宿主文档验证加载。
验收分三层。先确认宿主能发现技能，再要求它在这项任务中明确采用该方法，最后观察是否产生有效证据。一个按顺序列出的调试报告可能仍然建立在猜测上，需要检查每个结论能否指向代码或运行结果。给它缺少复现数据的练习输入时，应报告缺失信息；给它完整夹具时，应能找到同一故障。这样比仅看到技能名称更能说明作用。
调试先固定状态，再验证根因
准备一把虚构电钻、一个日期和两个可用名额。创建两个预约使日期满额，取消其中一个，再按当前规则刷新页面。记录取消响应、预约状态、日历接口返回与最终显示。明确系统要求立即可见还是允许有一段缓存时间，并按契约设置等待条件。拿另一把工具作为对照，避免把所有日历都刷新后掩盖实际影响范围。每次记录构建和请求编号，防止比较了不同环境。
沿取消写入、可用量计算、缓存读取和组件显示逐层观察。假设数据库状态已取消，但日历响应仍返回零名额，那么先比较绕过练习缓存的结果和正常读取结果。保持预约数据与时钟不变，只改变一项测试条件。若响应已正确而页面仍满额，把排查移到组件状态或请求更新。让假设预测下一条观察，出现反例时记录并回到最后一个有证据的边界，不连续修改多个层后再猜是哪项有效。
确认原因后先写能捕捉旧行为的回归。例如固定同一工具与日期，取消后读取应返回一个可用名额，另一工具的结果不变。再修改负责失效或更新的具体路径，核对重复取消、取消失败以及并发预约不会被错误覆盖。测试不仅检查响应成功，还要断言具体数量与状态。给旧实现与修复实现相同输入，保留失败到通过的对照，才能知道用例确实覆盖原故障。
编程辅助把实现、重构和解释分开
让助手先说明调用路径、输入输出和允许的变更，再生成最小差异。评审时检查新增依赖、时间行为、缓存范围与错误处理。若修复只需要更新一个工具日期的缓存键，就解释该键为何覆盖正确范围。没有证据需要时，其他重构留给后续任务。写测试和写文档都围绕本次契约，不能用改预期来掩盖错误。运行失败时保留输出，区分环境问题和断言不满足。
若后续确实要重构可用量计算，先保存现有正确行为样本，再按接口或函数边界逐步替换。每一步重复同样的检查，比较结果和异常分支。助手生成解释时应指向当前实现与实际调用方，不以一段概括代替源码核对。交付记录写清哪些命令执行过、哪些只是建议，缺依赖或不可用的检查明确留下原因和补测方式。
页面回归可使用 Webapp Testing。已核对条目描述 Python 与 Playwright 在运行中的本地应用上执行交互，保存脚本、截图和浏览器日志。把它放在修复后的日历验收，提供服务启动方式、虚构夹具和预期状态，先观察控件再操作。准备浏览器依赖并核对执行范围。页面结果用于补充接口与单元回归，不能替代对并发和数据一致性的专门检查。
把跑通的方法做成项目自己的小技能
重复修过几次同类任务后，整理真正稳定的步骤。按当前宿主官方技能文档编写名称、用途描述、输入要求、执行顺序和产物格式。把本地调试记录作为例子：复现卡、假设与对照、有限补丁、回归和交接。长参考放到单独文件并给入口，需要脚本时明确依赖与路径。不要把这次的工具编号写成永远固定的业务条件，也不要把临时猜测写成项目规则。
为自定义方法留一组正反样本。预约状态故障应触发，纯文案润色不应触发，缺构建或夹具时应先补信息。再测试一个无法成立的根因假设，观察它能否按反例更新判断。请另一位维护者用同一任务复跑，检查产物是否足以接手。若自动激活不稳定，先核对描述、冲突名称和加载范围；显式调用能运行不等于自动选择已经可靠。记录方法版本与验收结果，升级后回放这些样本。
交接与后续维护
最终包包含源版本、安装位置、夹具、修复差异、检查输出和页面证据。维护者应该能回答是哪一步出错、补丁为什么改变结果，以及哪些分支尚未覆盖。回退前确认旧实现能处理当前练习数据，恢复后跑一条正常预约。日后新增技能先针对缺口做对照试用，确定用途与产物更合适再替换关联。用复核时间、误修和返工评估收益，不能以调用次数或流程条目数代替正确交付。
常见问题
前端开发也适合先分析根因吗？
适合把现象固定为状态、输入和可观察结果。页面、接口和缓存的责任边界都可能影响显示，按证据决定排查层。具体工具仍需匹配项目语言和运行环境。
安装多项技能会不会冲突或变慢？
可能出现同名、重复触发、工具开销或互相矛盾的要求。记录当前启用项，一次试用一个变化，用相同任务比较时间与产物。按需加载不能证明所有配置都没有开销。
怎么知道技能生效了？
核对发现、调用与实际结果。看它是否使用当前夹具、验证假设并执行有效检查，而非只复述方法名称。未执行的建议不能计作测试通过。
可以直接共享自己写的方法吗？
先去除凭据和真实数据，写清依赖、范围、版本与失败处理，并用正反样本复验。共享者应知道这是在哪个环境验过的方法，换宿主仍需重新确认加载和工具支持。