briefbound-project-review git:20260813.dec1d14A

Immutable. This exact content is served forever at /api/v1/blob/01dce76db78fabe3.

---
name: briefbound-project-review
description: Use when Briefbound workflow needs a Chinese-first review of an entire repository, codebase, architecture, technical debt, test coverage, risk modules, maintainability, onboarding state, or project health before planning, refactoring, takeover, or prioritization.
license: MIT
---

# Briefbound Project Review

## 目标

对整仓或明确子系统做只读、证据化审查，找出最影响完成率、误改率和用户价值的问题。PR/diff 使用 `briefbound-pr-review`，具体 bug 使用 `briefbound-bug-review`。

## Briefbound task contract

- Context Boundary: 审查范围、实际读取的入口/模块/测试/配置/git/运行证据和排除范围。
- Output Contract: 项目健康结论、风险排序 findings、可连续执行的修复顺序和 Route Out。
- Allowed Action: 默认只读；不编辑文件、移动分支或修改 index。用户要求修复时由 Briefbound Router 建立执行契约。
- Success Evidence: finding 绑定文件/命令/运行证据、影响、最小动作和验证条件。
- Stop Condition: 范围不明、对象变成 PR/具体 bug、关键证据缺失、需要写入或高风险决策。
- Route Out: `briefbound-simplification-audit`、`briefbound-planning`、`briefbound-bug-review`、`briefbound-performance-engineering`、`briefbound-pr-review`、`briefbound-router` 或 BLOCKED。

## 统一调用契约

- 只处理 Briefbound task contract 范围；不匹配时回 `briefbound-router` 或更具体 owner，复合任务不吞其他 owner。
- 用户可见内容默认中文；保留技术字面量；只报结论、证据、风险和产出；Route Out 仅以 Briefbound task contract 为准，末行写 `下一步建议: <一个具体动作>`。

## 深度与证据

- `QUICK`：目录、README、配置、测试入口和近期 git 信号。
- `STANDARD`：默认；增加关键链路、依赖、CI、测试质量和边界。
- `DEEP`：接手、重构或高风险发布前；增加热点历史、状态/数据/权限/迁移风险。

不要为了全面扫描全仓。先确认事实源和高信号入口，再沿用户目标钻取 owning modules；证据足以回答审查目标时停止。按需检查架构边界、修改热点、真实行为测试、配置/数据/权限、发布回滚和接续成本，不为未命中的通用清单继续扩读。

## Findings

严重度：`P0` 数据/安全/核心不可用；`P1` 高风险缺陷或关键契约/测试缺口；`P2` 明显增加误改和维护成本；`P3` 非阻塞改进。

每条必须包含：位置或命令证据、具体观察、影响、最小有效动作、验证条件。不得把“项目复杂”“测试不足”“TODO 很多”直接当 finding；孤立实现 bug 不升级为项目 finding，除非证据表明它代表重复模式、架构边界或系统性风险。

Telemetry Gap 与已确认问题分开；WATCHLIST 必须写明升级、降级或关闭所需的日志、指标、测试或时间窗口。

## 执行顺序

多个 finding 按依赖、用户价值、误改风险和验证成本排序，而不是只推荐一个：

- `SAFE_DIRECT`：已有修复许可时依次执行并验证，不逐项询问。
- `PLAN_THEN_EXECUTE`：存在设计分叉时先规划，再回到执行。
- `DEFERRED`：只记录触发条件。
- `BLOCKED`：停止并问一个不可约问题。

只有顺序会改变产品取舍、范围或高风险动作时才让用户选择。只读审查请求本轮停在报告；用户说“继续/开始修复/按顺序修”时从第一个非 Deferred/Blocked 项连续推进。

## 输出

```text
项目审查: HEALTHY / WATCHLIST / NEEDS_ATTENTION / HIGH_RISK / BLOCKED
范围与关键证据: ...
Findings:
- P0/P1/P2/P3 [位置] 问题；影响；最小动作；验证条件
执行顺序（仅多个后续动作时）:
1. <动作> [SAFE_DIRECT/PLAN_THEN_EXECUTE/DEFERRED/BLOCKED]
证据缺口与剩余风险: ...
下一步建议: <一个具体动作>
```

没有 finding 时明确说明未发现结构性问题，并用一句话说明最重要的未覆盖边界。不默认生成项目地图、矩阵、ledger、完整扫描清单或专项路由清单。