name	confidence-check
description	实现前 5 维度置信度打勾（去重/架构/官方文档/OSS 参考/根因），≥90% 才准开工。100-200 token 省 5K-50K token。

Confidence Check Skill

目的

在开始实现之前评估置信度，防止错方向返工。

硬门槛：总分 ≥ 90% 才准开工。

何时使用

实现任何任务之前调用，确保：

没有重复实现
架构合规
官方文档读过
找到可工作的 OSS 参考
根因已定位

置信度评分维度

按下面 5 个维度打分（0.0-1.0），加权求和。

1. No Duplicate Implementations?（25%）

检查：在当前代码库搜同类功能

# 用 Grep 找相似函数
# 用 Glob 找相关模块

✅ 未找到重复 → 过
❌ 已有类似实现 → 不过（应复用而不是新写）

2. Architecture Compliance?（25%）

检查：技术栈是否一致

读 CLAUDE.md、PLANNING.md、AGENTS.md
确认沿用现有模式（ORM、cache、queue、HTTP client）
避免无必要地引入新依赖
✅ 复用现有栈（比如 Pydantic + FastAPI + SQLAlchemy + Redis）→ 过
❌ 无理由引入新框架 → 不过

3. Official Documentation Verified?（20%）

检查：动手前读官方文档

Context7 MCP 查最新官方文档
Exa MCP 做技术发现与对比
WebFetch 直接拉文档 URL
确认 API 签名 / 版本兼容 / 弃用警告
✅ 官方文档已核对 → 过
❌ 靠训练数据猜 → 不过

4. Working OSS Implementations Referenced?（15%）

检查：有没有靠谱的 OSS 参考

搜 GitHub 找相近实现
核对是否真有 tests / 近期提交 / 合理 star 数
避免拿 demo / POC 当生产参考
✅ 找到可工作的 OSS 参考 → 过
❌ 没找到同类实现 → 不过

5. Root Cause Identified?（15%）

检查：真问题定位了吗？

分析错误信息 / stack trace / 日志
区分症状和根因
确认不是在治标
✅ 根因清楚 → 过
❌ 只看到症状 → 不过

置信度计算

Total = Check1 (25%) + Check2 (25%) + Check3 (20%) + Check4 (15%) + Check5 (15%)

Total ≥ 0.90:  ✅ 开工
0.70 ≤ Total < 0.90:  ⚠️  先列出备选方案 / 追问用户
Total < 0.70:  ❌ STOP，补上下文再来

输出格式

📋 Confidence Checks:
   ✅ No duplicate implementations found
   ✅ Uses existing tech stack (FastAPI + Pydantic + SQLAlchemy)
   ✅ Official documentation verified (Context7: FastAPI 0.115)
   ✅ Working OSS implementation found (github.com/xxx/yyy, 3.2k stars)
   ✅ Root cause identified (N+1 query in repo layer)

📊 Confidence: 1.00 (100%)
✅ High confidence — proceeding to implementation

ROI

Token 账：100-200 token 的置信度检查，省下 5,000-50,000 token 的返工。

错方向返工的平均成本（3-10 次 edit + 1 次 review + 1 次 refactor）≈ 20,000-50,000 token；前置检查 200 token 以内就能拦下绝大多数风险。

与 MCC 其它组件的配合

/tdd 前：先跑 confidence-check，不到 90% 先补齐再写测试
/implement 前：plan 产出后、动手前，跑一次确认
/plan 产出后：plan 里的技术选型通过 confidence-check 才进 implement 阶段
confidence < 0.7 时：切到 /prd 或 product-lens skill 补需求侧上下文

Más de este repositorio

mismo repositorio

codex-audit

18811184907/mcc

Claude 用 codex CLI 做差异化对抗审查 + Layer 2 二审 + auto-fix 全链路。**v2.8.0 起流式 streaming**：codex 思考过程实时事件流（onEvent 回调每个 thread.started / item.completed / turn.completed），idle-timeout（90s 没新事件才算卡死）替代固定 totalTimeout。runCodexAudit 是 async，要 await。三层架构：Layer 1 codex (OpenAI) 流式产 finding → Layer 2 finding-validator subagent (Claude fresh) 独立复现 → Layer 3 通过自动 Edit 修不询问用户。触发：/plan 完成 / /implement 大改动 / /review 3 路并行 / /pr 4 路 PR 预检。codex 是不同模型 = 不同盲区，跟 Claude 互补不替代。**全自动 — 用户从不需要手动管 codex**。

2026-04-304

user-vault

18811184907/mcc

Claude 自动接管用户级跨项目敏感配置（personal API key / 个人 PAT / git 全局身份 / 跨项目 SSH host）。触发：用户提到跨项目通用 secret、或 project-vault 检测到条目应提升到用户级、或用户问'跨项目共用 secret 放哪'。写 ~/.claude/USER_VAULT.md，hook 自动 sync 到 .user-env.{sh,ps1} + git --global + ~/.ssh/config。与 project-vault 分工：本 skill 跨项目，project-vault 单项目。

2026-04-294

claudemd-sync

18811184907/mcc

Claude 主动沉淀用户跨项目偏好到 ~/.claude/CLAUDE.md，post-hook 自动 commit+push 到 dotfiles repo 跨设备同步。触发：用户说'记下这个偏好 / 沉淀到 CLAUDE.md / 把这个习惯加进去'、用户连续多次重复同样反馈（'又忘了'）、或做了跨项目通用决策（'以后所有项目都用 zod'）。仅追加不覆盖。与 continuous-learning-v2 分工：本 skill 主动显式沉淀偏好，learning-v2 被动观察行为。

2026-04-294

database-schema-doc

18811184907/mcc

Claude 自动维护 docs/SCHEMA.md。触发：用户提到表结构（'加 users 表，字段 email/password'）、写改 ORM 模型（Prisma/SQLAlchemy/TypeORM）、写改 migration SQL、或问'数据库表结构在哪'。不存在自动建（从 ORM 抽骨架），存在直接 Edit 加表/字段；业务含义缺失填 '_TODO_' 占位。与 architecture-decision-records 分工：本 skill 记结构现状，ADR 记选型决策（如选 Postgres）。

2026-04-294

dev-changelog

18811184907/mcc

Claude 自动维护开发实时流水日志 docs/CHANGELOG-DEV.md，记**正在发生**的需求/进度/坑/下一步。触发：用户讲新需求或改主意（◇）、Claude 完成 ≥30 行或跨文件改动（✓）、遇 blocker（⚠）、决定下一步（→）。与 git log（已落盘代码）/ ADR（终态决策）/ SCHEMA（结构）/ mistakes（bug 根因）分工——本 skill 记进行中状态。每条 ≤5 行倒序。

2026-04-294

project-vault

18811184907/mcc

Claude 自动接管项目级敏感配置（API key / DB 密码 / 部署 IP / SSH / token）。触发：用户在对话里说出任何 secret 或 IP、或代码里硬编 secret、或问 '.env 怎么放 / token 存哪'。写 .claude/PROJECT_VAULT.md，hook 自动 sync 到 .env.local + .env.example + ~/.ssh/config + SECRETS-INDEX.md，强制 .gitignore。与 user-vault 分工：本 skill 单项目，跨项目用 user-vault。

2026-04-294

name	confidence-check
description	实现前 5 维度置信度打勾（去重/架构/官方文档/OSS 参考/根因），≥90% 才准开工。100-200 token 省 5K-50K token。

Confidence Check Skill

目的

在开始实现之前评估置信度，防止错方向返工。

硬门槛：总分 ≥ 90% 才准开工。

何时使用

实现任何任务之前调用，确保：

没有重复实现
架构合规
官方文档读过
找到可工作的 OSS 参考
根因已定位

置信度评分维度

按下面 5 个维度打分（0.0-1.0），加权求和。

1. No Duplicate Implementations?（25%）

检查：在当前代码库搜同类功能

# 用 Grep 找相似函数
# 用 Glob 找相关模块

✅ 未找到重复 → 过
❌ 已有类似实现 → 不过（应复用而不是新写）

2. Architecture Compliance?（25%）

检查：技术栈是否一致

读 CLAUDE.md、PLANNING.md、AGENTS.md
确认沿用现有模式（ORM、cache、queue、HTTP client）
避免无必要地引入新依赖
✅ 复用现有栈（比如 Pydantic + FastAPI + SQLAlchemy + Redis）→ 过
❌ 无理由引入新框架 → 不过

3. Official Documentation Verified?（20%）

检查：动手前读官方文档

Context7 MCP 查最新官方文档
Exa MCP 做技术发现与对比
WebFetch 直接拉文档 URL
确认 API 签名 / 版本兼容 / 弃用警告
✅ 官方文档已核对 → 过
❌ 靠训练数据猜 → 不过

4. Working OSS Implementations Referenced?（15%）

检查：有没有靠谱的 OSS 参考

搜 GitHub 找相近实现
核对是否真有 tests / 近期提交 / 合理 star 数
避免拿 demo / POC 当生产参考
✅ 找到可工作的 OSS 参考 → 过
❌ 没找到同类实现 → 不过

5. Root Cause Identified?（15%）

检查：真问题定位了吗？

分析错误信息 / stack trace / 日志
区分症状和根因
确认不是在治标
✅ 根因清楚 → 过
❌ 只看到症状 → 不过

置信度计算

Total = Check1 (25%) + Check2 (25%) + Check3 (20%) + Check4 (15%) + Check5 (15%)

Total ≥ 0.90:  ✅ 开工
0.70 ≤ Total < 0.90:  ⚠️  先列出备选方案 / 追问用户
Total < 0.70:  ❌ STOP，补上下文再来

输出格式

📋 Confidence Checks:
   ✅ No duplicate implementations found
   ✅ Uses existing tech stack (FastAPI + Pydantic + SQLAlchemy)
   ✅ Official documentation verified (Context7: FastAPI 0.115)
   ✅ Working OSS implementation found (github.com/xxx/yyy, 3.2k stars)
   ✅ Root cause identified (N+1 query in repo layer)

📊 Confidence: 1.00 (100%)
✅ High confidence — proceeding to implementation

ROI

Token 账：100-200 token 的置信度检查，省下 5,000-50,000 token 的返工。

错方向返工的平均成本（3-10 次 edit + 1 次 review + 1 次 refactor）≈ 20,000-50,000 token；前置检查 200 token 以内就能拦下绝大多数风险。

与 MCC 其它组件的配合

/tdd 前：先跑 confidence-check，不到 90% 先补齐再写测试
/implement 前：plan 产出后、动手前，跑一次确认
/plan 产出后：plan 里的技术选型通过 confidence-check 才进 implement 阶段
confidence < 0.7 时：切到 /prd 或 product-lens skill 补需求侧上下文