Skep

---
name: skep
description: 基于当前仓库进行证据驱动的方案审视：先自主探索并阅读相关代码、配置、文档与测试，再提出有依据的质疑，评估优点、缺点、风险、可行性与预期效果，并通过讨论推进决策。用于需要判断当前方案是否可行、效果是否达标、是否应调整技术路线或实现策略时。
---

# Skep

## Overview

执行“证据优先”的怀疑式评审。先探索仓库并建立事实基础，再给判断与质疑，避免无依据的泛化怀疑。

## Non-Negotiable Rules

1. 先证据后结论
- 在形成判断前，先阅读与问题直接相关的仓库文件。

2. 关键结论必须可追溯
- 每个关键判断必须绑定证据来源。
- 优先引用具体文件与行号；无法给行号时，至少给文件路径与命令结果。

3. 显式区分信息类型
- 将内容标注为“事实”“推断”或“未知”。
- 不将推断表述为已验证事实。

4. 信息不足时先补证据
- 若证据不足以支撑结论，先继续探索，再给暂定判断。

5. 禁止空泛质疑
- 每个质疑都必须说明触发它的证据与潜在影响。

## Repo Exploration Workflow

1. 对齐目标与边界
- 复述当前方案、目标、约束与验收标准。
- 明确本轮要验证的核心问题。

2. 绘制相关文件地图
- 使用 `rg` / `rg --files` 定位实现入口、调用链、配置、测试与文档。
- 先读直接相关文件，再按调用关系扩展。

3. 深读关键实现
- 重点阅读：核心逻辑、数据流、错误处理、边界条件、回退逻辑。
- 识别方案成立依赖的关键假设。

4. 校验现有验证信号
- 检查是否存在测试、日志、指标、实验记录或基线结果。
- 若缺少验证信号，明确指出验证盲区。

5. 汇总证据并形成判断
- 建立“结论 -> 证据 -> 影响 -> 置信度”的映射。

## Feasibility and Effect Evaluation

1. 可行性判断
- 输出可行性等级：高 / 中 / 低。
- 说明前置条件、阻塞项、可回滚性与实施复杂度。

2. 效果判断
- 说明当前方案理论收益与落地收益是否一致。
- 给出可量化指标、预期改善区间与验证方式。
- 若无法量化，明确原因与替代验证方案。

3. 风险判断
- 说明触发条件、影响范围、可观测信号与缓解动作。

## Evidence-Grounded Questioning

对每个关键质疑使用以下结构：
- 质疑点：具体问题是什么。
- 触发证据：哪段实现或配置导致该问题。
- 潜在影响：若不处理会造成什么后果。
- 验证动作：最小成本如何确认真伪。

## Output Template

1. 当前方案与目标复述
2. 证据清单（已阅读文件与关键观察）
3. 可行性判断（含置信度）
4. 效果判断（指标与验证路径）
5. 当前方案优点
6. 当前方案缺点与风险
7. 可替代方案与取舍对比
8. 推荐方案与具体实现步骤
9. 需要继续讨论的决策问题

## Discussion Loop

- 在结尾提出 1 到 3 个最关键决策问题，推动下一步。
- 用户补充新信息后，更新结论与置信度，不重复旧内容。
- 存在高不确定性时，优先给出低成本验证实验，再决定是否推进。