用途
该技能面向需要为某个具体代码仓库生成 Greptile 拉取请求审查配置的场景。Greptile 是语义化 PR 审查器，不是 linter。它的价值在于捕捉有意义的缺陷、安全问题、架构违规和契约漂移，而不是把语义审查预算浪费在类似 lint 的琐碎问题上。
适合使用 Greptile 的领域包括：架构边界、安全不变量、API 契约、性能陷阱、依赖误用、合规以及跨文件推理。分号、格式、导入排序等应交给 ESLint、Prettier、Ruff、RuboCop、golangci-lint 等工具。
Greptile 从 PR 的源分支读取仓库本地配置，变更在下一个 PR 或重新审查时生效，不会追溯应用。优先使用 .greptile/ 目录而非旧版 greptile.json。
主要能力
技能提供决策树，按任务类型指向不同参考文档：首次设置、权限或索引；编写或调整 .greptile/config.json 与 files.json；设计仓库专属审查规则；匹配常见技术栈或 monorepo 布局；需要完整端到端示例；接入状态检查、API 触发或 CI/CD；调试被忽略的配置、噪音审查或发布检查。
默认只生成仓库真正需要的文件：config.json 始终生成；rules.md 仅在规则需要示例、迁移说明或细致叙述时生成；files.json 仅在文档、规格或 schema 能实质性改善审查时生成；子目录 .greptile/config.json 仅在某个子树需要不同严格度或额外规则时生成。
起始配置建议：默认 strictness 为 2，commentTypes 为 ["logic", "syntax"]；仅当仓库缺乏强格式化或 lint 时才加入 "style"；从 5-10 条高信号规则起步，而不是 20 条泛化规则；若从 greptile.json 迁移，应移动到 .greptile/ 并删除旧文件。
使用方式
技能按六个阶段顺序执行。
第一阶段：分类请求与当前 Greptile 状态。先阅读 setup.md 和 config-spec.md。在写入任何内容前切换到目标仓库根目录；若使用共享 fixture 或示例仓库，先复制到临时仓库或 worktree，保持源 fixture 不变。然后判断任务类型：新设置、调整现有配置、monorepo 拆分、排障或集成。搜索仓库中现有的 .greptile/ 文件夹、旧版 greptile.json、可作为 files.json 输入的文档/规格/schema（如 Prisma/Drizzle schema、OpenAPI/Swagger 规格、ADR 文档、架构文档、共享类型定义文件，排除 README 和 changelog），以及现有 linter/formatter 配置。若配置已存在，保留可用部分，仅根据仓库证据收紧。
第二阶段：映射审查面。阅读 patterns.md。通过读取工作区配置、列出顶层目录、读取根级和应用级依赖清单、搜索风险敏感目录来映射仓库，覆盖七个方面：结构、技术栈、风险区域、生成/噪音文件、有用上下文文件、现有质量控制、反复出现的失败模式。探索深度按仓库规模调整，小仓库可能只需目录列表和依赖清单，大型 monorepo 需检查每个顶层包的用途、关键依赖和风险敏感目录。
第三阶段：选择文件拓扑与严格度。阅读 config-spec.md。始终生成根 .greptile/config.json。仅在需要时生成 rules.md、files.json 或子配置。monorepo 规则：优先根默认值加子覆盖，仅在审查需求真正分化处使用。严格度建议：大多数生产代码用 2；支付、认证、安全关键或合规密集路径用 1；内部工具、原型或低风险目录用 3。仅在用户要求或仓库工作流明显需要时调整 PR 过滤器或摘要行为。
第四阶段：从架构信号工程化语义规则。阅读 rules-engineering.md。每条规则必须仓库专属、具体、可度量、可操作、有范围、语义化且可识别。根据观察到的仓库信号决定规则类别：认证/支付/PII/文件系统/shell/IPC/密钥对应安全与合规；控制器/服务/仓库/包边界对应架构边界；OpenAPI 规格/共享 SDK/后端仓库/设计系统对应 API 契约与依赖；ORM 使用/查询构建器/后台任务/缓存/异步工作流对应性能与数据完整性；不同技术栈或风险特征的 monorepo 包对应级联配置。规则编写启发：最多 5-10 条规则起步；每条规则绑定实际仓库路径、库、契约或失败模式；告诉 Greptile 正确替代方案，而不仅是要避免什么；若子配置可能禁用某父级规则，给每条父级规则一个 id；若规则适用于仓库大多数文件而非特定子系统，可能过于宽泛。
第五阶段：精确限定规则、上下文和文件目标。阅读 patterns.md。scope 必须是 glob 数组，绝不能是逗号分隔字符串；ignorePatterns 必须是换行分隔字符串，不是数组；上下文文件应限定到它所服务的代码；patternRepositories 仅用于真实的跨仓库契约或设计系统，格式为 org/repo；从通用忽略模式起步，为第二阶段发现的生成或高噪音目录添加项目专属模式；若已有强 lint/格式化，不要添加风格导向的 Greptile 规则。
第六阶段：验证、输出并在需要时恢复。阅读 troubleshooting.md 和 anti-patterns.md。最终输出前检查：JSON 本地验证通过；scope 值是字符串数组；ignorePatterns 是换行分隔字符串；strictness 为 1、2 或 3；commentTypes 仅使用 "logic"、"syntax"、"style"、"info"；patternRepositories 使用 org/repo 而非完整 URL；files.json 仅指向实际存在的文件；没有规则重复 lint/格式化工具；迁移后不存在 .greptile/ 与 greptile.json 共存。输出应包含：.greptile/ 目录结构的 markdown 代码块、每个生成文件的完整内容、与具体仓库证据绑定的推理注释、一个 canary 测试规则（临时规则验证 Greptile 读取配置，验证后移除）、以及替换 greptile.json 时的迁移说明。若文件系统可访问，除非用户明确要求仅草稿输出，否则先写入/更新仓库中的 .greptile/ 文件。
若 Greptile 行为仍不正确，按顺序恢复：仓库是否已索引；JSON 是否有效；.greptile/ 是否与 greptile.json 冲突；配置是否在 PR 源分支上；scope 是否实际匹配变更文件；strictness 是否抑制了所用严重度；作者/分支/文件限制过滤器是否排除了该 PR。强制重新审查，验证后移除任何 canary 规则。
适用场景
适用于为特定仓库首次设置 Greptile 审查配置、调整现有配置、为 monorepo 不同包设置不同严格度或规则、排查配置被忽略或审查噪音问题、以及将 Greptile 接入状态检查、API 触发或 CI/CD 交付工作流。
限制
Greptile 是语义化审查器，不应承担 linter 职责。配置变更仅对下一个 PR 或重新审查生效，不追溯。技能强调规则必须仓库专属且有明确范围，避免泛化规则。关于具体平台支持、收费、价格等信息，资料中暂未提供。