Confidence check
My personal collection of handcrafted AI agent skills — original prompting modules for code quality, knowledge exploration, and daily productivity.
npx -y skills add unix2dos/skills --skill confidence-checkAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 3 stars3 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
Use when starting complex tasks like feature development, bug fixes, or code refactoring - runs a pre-implementation confidence check to avoid wasting tokens on wrong directions
SKILL.md
5.0 KB, as published. Nobody here has run it
实施前置信度检查
在动手写代码前花 100-200 tokens 做检查，可避免走错方向浪费 5,000-50,000 tokens。
自动触发规则
触发检查的场景
识别到以下复杂任务时 自动触发：
| 任务类型 | 触发关键词 |
|---|---|
| 新功能开发 | 实现、开发、添加、创建功能、implement、add feature |
| Bug 修复 | 修复、解决、fix、bug、错误、问题 |
| 代码重构 | 重构、优化、refactor、改进 |
| 架构变更 | 架构、设计、迁移、migrate |
跳过检查的场景
以下情况 不触发检查：
- 单行修改、变量重命名
- 纯文档变更（README、注释）
- 代码阅读/解释请求
- 代码审查类请求（「看看有没有问题」「review 一下」「检查代码质量」「有没有 bug」）——注意区分：有具体报错信息或复现步骤的才是 Bug 修复，纯粹让你「看看」的是代码阅读请求。跳过时回复：「我会直接阅读代码。如果有具体报错信息或复现步骤，告诉我可以触发 Bug 修复检查。」
- 用户明确说"跳过检查"（需先提醒风险）
检查流程
步骤 0：确认任务对象存在
在识别任务类型之前，先确认请求中是否包含具体的操作对象（文件名、函数名、模块名、组件名、错误信息等）。
如果请求没有指定任何具体对象（例如「优化一下」「改改这个」「让它更快」），停止，不得开始检查，直接回复：
请告诉我你想操作的具体文件或功能，我才能进行有针对性的检查。例如：「优化 UserService.ts 中的 getUserList 方法」。
等待用户补充信息后，再从步骤 1 开始。
步骤 1：识别任务类型
分析用户请求，判断属于以下哪种类型：
- 新功能开发
- Bug 修复
- 代码重构
步骤 2：执行对应检查项
根据任务类型，执行对应的检查项。每项检查需要 实际执行（使用工具搜索）+ 上下文分析。
新功能开发检查项
| 检查项 | 权重 | 执行方式 |
|---|---|---|
| 重复实现检查 | 40% | 使用 grep/glob 搜索代码库，查找是否已有类似实现 |
| 架构合规检查 | 30% | 检查 CLAUDE.md/AGENTS.md、审查现有代码模式 |
| 官方文档验证 | 30% | 搜索官方文档，确认 API 用法和最佳实践 |
Bug 修复检查项
| 检查项 | 权重 | 执行方式 |
|---|---|---|
| 根因分析 | 40% | 审查错误日志、堆栈跟踪，定位问题根源 |
| 官方文档验证 | 30% | 搜索相关 API/库的文档和已知问题 |
| OSS 参考方案 | 30% | 搜索 GitHub Issues、Stack Overflow 查找解决方案 |
代码重构检查项
| 检查项 | 权重 | 执行方式 |
|---|---|---|
| 架构合规检查 | 50% | 确认重构方向符合项目架构规范 |
| 重复实现检查 | 30% | 确认没有重复造轮子 |
| OSS 最佳实践 | 20% | 参考开源项目的类似实现 |
步骤 3：计算综合评分
每项检查评分为 0-100%，根据权重计算综合得分。
步骤 4：做出决策
| 综合评分 | 决策 | 行为 |
|---|---|---|
| ≥80% | ✅ 继续实施 | 直接开始编码 |
| 70-79% | ⚠️ 需要澄清 | 提出问题，等待用户确认 |
| <70% | ❌ 暂停 | 说明风险，请求补充信息 |
输出格式
检查完成后，输出以下格式的报告：
📋 实施前置信度检查
任务类型：[新功能 / Bug修复 / 重构]
检查结果：
[✅/❌] 重复实现检查 - [具体发现说明]
[✅/❌] 架构合规检查 - [具体发现说明]
[✅/❌] 官方文档验证 - [具体发现说明]
[✅/❌] OSS 参考方案 - [具体发现说明]
[✅/❌] 根因分析 - [具体发现说明]（仅 Bug 修复）
综合评分：XX%
决策：[✅ 继续实施 / ⚠️ 需要澄清 / ❌ 暂停并补充信息]
建议：
- [可操作的具体建议 1]
- [可操作的具体建议 2]
跳过检查的处理
如果用户要求跳过检查（如"跳过检查"、"直接开始"、"不用检查"），先输出以下风险提醒：
⚠️ 跳过前置检查可能带来的风险：
- 40% 的"简单"任务存在重复实现
- 30% 的返工由架构假设错误导致
- 5 分钟检查可节省 3 小时调试时间
你已经完成了哪些检查？确认继续吗？
等待用户确认后，再开始实施。
常见风险信号
| 用户想法 | 实际风险 |
|---|---|
| "这个太简单了，不用检查" | 40% 的"简单"任务会写出重复代码 |
| "我已经知道架构了" | 30% 的返工由错误假设导致 |
| "官方文档太耗时间" | 5 分钟阅读可节省 3 小时调试 |