技能介绍

在代码、技能配置或技术文档评审中，两类问题反复出现。一是直接开始评，却没有固定检查项，语法、逻辑、完整性、边界这几条容易漏。二是审查范围在 diff、长文档、整个技能目录之间来回切换，边界不清晰，报告格式也不统一。GLIC Check 把这类审查收敛为一套可复用的流程：用 GRAMMAR（语法）、LOGIC（逻辑）、INTEGRITY（完整性）、CONTAINMENT（约束）四个维度覆盖常规审查；当需要从 Agent 和 Human 两个视角评估可用性时，再启用 USABILITY 维度，用 UGLIC 模式完成五维检查。模式判定基于意图：当消息表达执行、检查、验证等动作时，例如 “UGLIC check”“do a uglic on X”“verify this”，会进入 UGLIC 模式；若只是提到 UGLIC 但并未要求执行，或未指定模式，则使用 GLIC 模式，而不是因为消息里出现了 “UGLIC” 就自动切模式。审查开始前先明确对象：this change 会解析为 git diff，check this skill 指整个技能目录，check this code 指向指定文件；若没有目标，技能会主动询问，而不是自行猜测。对大目标采用结构化读取：先扫描文件列表、frontmatter、标题、函数签名，再对错误处理、跨引用、frontmatter 和疑似构建产物等高风险区域进行深读，避免一次性加载全部引用，也避免漏读关键段落。每个维度都有 references/dimensions.md 中的子检查项，结论必须引用 file:line，不允许用“某处”或“有些地方”这种模糊描述。定级采用 ERR、WARN、INFO：功能受损、安全风险、文档与代码不一致、用户无法完成核心任务，以及任何可能静默失败的问题都标为 ERR；可维护性、一致性、隐性风险和交互摩擦属于 WARN；风格与小优化归为 INFO。同一检查、同一目标内，WARN 出现 3 次或以上会升级为 ERR；跨目标反复出现的问题不会自动升级，只会作为行业模式提示。报告遵循 references/output-format.md：标题标明目标和模式，每个维度一个子节，发现项按 U1、G2、L3、I1、C2 编号，末尾附汇总表，最后列出必须先修的 ERR。审查完成后会询问是否修复：先修 ERR，再处理 WARN，不擅自改动。大型目标还可以先运行 scripts/grep_antipatterns.sh，它会在执行完整检查表前筛出疑似问题：中英文中的模糊指令、SKILL.md 长度、frontmatter 字段纪律、构建产物残留、跨章节引用候选；脚本只负责发现，严重度判断和 file:line 引用仍由审查者完成。适用边界上，GLIC / UGLIC 面向单次审查快照，不是持续集成门禁；它不替代类型检查器、linter 或测试，复杂逻辑分支、跨文件一致性和安全风险仍需结合工具与人工判断。审查效果依赖目标文件可访问，超大代码库也只能覆盖被读取到的部分。