技能介绍

它解决什么问题

技能仓库的贡献长期面临三类失控：格式不统一（有人交 3 段文档，有人填满 16 节模板）、质量无法量化（'看起来能用'成了唯一的验收标准）、Git 历史混乱（一个 PR 塞下多个技能，回滚时牵一发动全身）。project-developer 把这套模糊的人工判断换成一张可执行的门禁表。

核心机制

五道闸门，任何贡献先过一遍：类型（新技能、升级还是修复）、完整性、是否符合 16-section 模板、rubric 分数是否达标、与现有技能是否冲突。任一闸门失败即阻断，并给出具体修复动作，而不是'请修改后重提'。

评分即红线：Expert 阈值 7.0 以下直接 BLOCK。文档里的反例很典型——一份 6.8 分的技能被拦下，并列出了补齐 2.2 分的动作：补 2 个带明确阈值的领域框架、扩到 3 个完整场景流、加 5 条领域风险。分数不是数字游戏，缺什么补什么。

工程化心智：能脚本化的闸门就脚本化，CI 里跑 yamllint 和内部链接校验；每次提交绑定 issue 或 PR；一个 commit 只做一件事。沟通也是命令式的——直接输出 git checkout -b feature/terraform-expert，而不是建议。

适用边界

明确不做的事比会做的事更重要：领域内容交给 domain expert 技能，rubric 评分交给 skill-writer，issue 管理交给 GitHub 项目板，文档交给 tech-writer。文档还列出六类反模式，包括 commit 过载、刷分、scope creep，每条都标了严重级别和修复方式。