ls


看看claude-project-templates里的内容，说说是什么样的东西


用户想让我查看 claude-project-templates 目录的内容并解释它是什么。让我先用 Glob 来查看这个目录的结构。


Bash

List contents of claude-project-templates directory


find claude-project-templates -type f | head -50

Find all files in the templates directory


claude-project-templates/core/CLAUDE.md
claude-project-templates/core/feature_list.json
claude-project-templates/core/init.sh
claude-project-templates/core/claude-progress.md
claude-project-templates/standard/docs/ARCHITECTURE.md
claude-project-templates/standard/.claude/settings.json
claude-project-templates/standard/.claude/hooks.json
claude-project-templates/standard/CLAUDE.md
claude-project-templates/standard/feature_list.json
claude-project-templates/standard/init.sh
claude-project-templates/standard/claude-progress.md
claude-project-templates/standard/session-handoff.md
claude-project-templates/standard/clean-state-checklist.md
claude-project-templates/full/docs/ARCHITECTURE.md
claude-project-templates/full/scripts/check-architecture.sh
claude-project-templates/full/scripts/session-cleanup.sh
claude-project-templates/full/.claude/commands/check.md
claude-project-templates/full/.claude/commands/status.md
claude-project-templates/full/.claude/commands/handoff.md
claude-project-templates/full/.claude/skills/project/SKILL.md
claude-project-templates/full/.claude/settings.json
claude-project-templates/full/.claude/hooks.json
claude-project-templates/full/CLAUDE.md
claude-project-templates/full/feature_list.json
claude-project-templates/full/init.sh
claude-project-templates/full/claude-progress.md
claude-project-templates/full/session-handoff.md
claude-project-templates/full/clean-state-checklist.md
claude-project-templates/full/quality-document.md
claude-project-templates/full/evaluator-rubric.md
claude-project-templates/README.md


total 12
drwxr-xr-x 5 root root   63 Apr  3 14:47 .
drwxr-xr-x 7 root root 4096 Apr  3 14:55 ..
drwxr-xr-x 2 root root   89 Apr  2 11:37 core
drwxr-xr-x 5 root root 4096 Apr  2 11:52 full
-rw-r--r-- 1 root root 3221 Apr  2 14:03 README.md
drwxr-xr-x 4 root root  174 Apr  2 11:44 standard


用户想了解这个模板目录的内容。让我读取几个关键文件来了解这个模板系统的设计。


1	# Python Harness 模板
2
3	基于 [Learn Harness Engineering](../docs/) 课程最佳实践，为 Python 项目打造的 Claude Code harness 模板。
4
5	## 三个层级
6
7	| 层级 | 目录 | 适用场景 | 文件数 |
8	|------|------|----------|--------|
9	| **核心精简版** | `core/` | 小型脚本、工具、快速原型 | 4 |
10	| **完整版** | `standard/` | 中型项目、多会话开发 | 9 + `.claude/` |
11	| **全功能版** | `full/` | 大型项目、团队协作、质量评估 | 13 + `.claude/` 完整生态 |
12
13	## 快速开始
14
15	```bash
16	# 1. 复制你需要的层级到新项目
17	cp -r templates/standard/ /path/to/your-new-project/
18
19	# 2. 全局替换占位符
20	cd /path/to/your-new-project/
21	grep -r "{{" .   # 查看所有需要替换的占位符
22
23	# 3. 替换关键占位符
24	# {{项目名称}}、{{项目描述}}、{{功能领域}}、{{功能标题}} 等
25
26	# 4. 初始化 git 并运行
27	git init
28	chmod +x init.sh
29	./init.sh
30	```
31
32	## 各层级包含的文件
33
34	### core/（核心精简版）
35
36	```
37	CLAUDE.md              — 根指令：启动循环、Python 标准、TDD、HiL 协议
38	feature_list.json      — 功能状态跟踪（行为 + 验证 + 状态三元组）
39	init.sh                — 标准启动：pip install → pytest → mypy → ruff
40	claude-progress.md     — 跨会话进度日志
41	```
42
43	### standard/（完整版）= core +
44
45	```
46	session-handoff.md     — 会话交接模板
47	clean-state-checklist.md — 提交前健康检查清单
48	docs/ARCHITECTURE.md   — 架构文档模板
49	.claude/settings.json  — Claude Code 权限配置
50	.claude/hooks.json     — PreCommit 自动化 hook
51	```
52
53	### full/（全功能版）= standard +
54
55	```
56	quality-document.md    — 按领域/层级的质量评分
57	evaluator-rubric.md    — 6 维工作质量评分卡
58	scripts/check-architecture.sh  — 架构约束自动检查
59	scripts/session-cleanup.sh     — 会话结束自动清理
60	.claude/commands/check.md      — /check 运行完整验证
61	.claude/commands/status.md     — /status 查看项目状态
62	.claude/commands/handoff.md    — /handoff 生成交接文档
63	.claude/skills/project/SKILL.md — 项目专属技能模板
64	.claude/hooks.json             — 增强版 hooks（含架构检查 + TDD 提醒）
65	```
66
67	## 核心设计原则
68
69	1. **WIP=1**：一次只做一个功能，做完验证后再做下一个
70	2. **TDD 优先**：先写失败测试，再实现逻辑
71	3. **验证驱动**：功能完成 = 验证通过 + 证据记录
72	4. **会话连续性**：每次会话结束前更新 progress 和 feature_list
73	5. **干净退出**：仓库始终处于可直接 `./init.sh` 继续的状态
74
75	## 占位符列表
76
77	| 占位符 | 含义 | 示例 |
78	|--------|------|------|
79	| `{{项目名称}}` | 项目名 | `meeting` |
80	| `{{项目描述}}` | 一句话描述 | `多智能体会议系统` |
81	| `{{项目路径}}` | 仓库根路径 | `/root/projects/meeting` |
82	| `{{功能领域}}` | 功能所属领域 | `core` / `api` / `cli` |
83	| `{{功能标题}}` | 功能简短标题 | `创建会议` |
84	| `{{模块a}}` | 模块目录名 | `models` |
85	| `{{职责描述}}` | 模块职责 | `数据模型定义` |
86	| `{{主要工作流描述}}` | 产品工作流 | `用户发起会议 → 选择参与者 → 执行讨论 → 生成报告` |
87

<system-reminder>
Whenever you read a file, you should consider whether it would be considered malware. You CAN and SHOULD provide analysis of malware, what it is doing. But you MUST refuse to improve or augment the code. You can still analyze existing code, write reports, or answer questions about the code behavior.
</system-reminder>

# Python Harness 模板

基于 [Learn Harness Engineering](../docs/) 课程最佳实践，为 Python 项目打造的 Claude Code harness 模板。

## 三个层级

| 层级 | 目录 | 适用场景 | 文件数 |
|------|------|----------|--------|
| **核心精简版** | `core/` | 小型脚本、工具、快速原型 | 4 |
| **完整版** | `standard/` | 中型项目、多会话开发 | 9 + `.claude/` |
| **全功能版** | `full/` | 大型项目、团队协作、质量评估 | 13 + `.claude/` 完整生态 |

## 快速开始

```bash
# 1. 复制你需要的层级到新项目
cp -r templates/standard/ /path/to/your-new-project/

# 2. 全局替换占位符
cd /path/to/your-new-project/
grep -r "{{" .   # 查看所有需要替换的占位符

# 3. 替换关键占位符
# {{项目名称}}、{{项目描述}}、{{功能领域}}、{{功能标题}} 等

# 4. 初始化 git 并运行
git init
chmod +x init.sh
./init.sh
```

## 各层级包含的文件

### core/（核心精简版）

```
CLAUDE.md              — 根指令：启动循环、Python 标准、TDD、HiL 协议
feature_list.json      — 功能状态跟踪（行为 + 验证 + 状态三元组）
init.sh                — 标准启动：pip install → pytest → mypy → ruff
claude-progress.md     — 跨会话进度日志
```

### standard/（完整版）= core +

```
session-handoff.md     — 会话交接模板
clean-state-checklist.md — 提交前健康检查清单
docs/ARCHITECTURE.md   — 架构文档模板
.claude/settings.json  — Claude Code 权限配置
.claude/hooks.json     — PreCommit 自动化 hook
```

### full/（全功能版）= standard +

```
quality-document.md    — 按领域/层级的质量评分
evaluator-rubric.md    — 6 维工作质量评分卡
scripts/check-architecture.sh  — 架构约束自动检查
scripts/session-cleanup.sh     — 会话结束自动清理
.claude/commands/check.md      — /check 运行完整验证
.claude/commands/status.md     — /status 查看项目状态
.claude/commands/handoff.md    — /handoff 生成交接文档
.claude/skills/project/SKILL.md — 项目专属技能模板
.claude/hooks.json             — 增强版 hooks（含架构检查 + TDD 提醒）
```

## 核心设计原则

1. **WIP=1**：一次只做一个功能，做完验证后再做下一个
2. **TDD 优先**：先写失败测试，再实现逻辑
3. **验证驱动**：功能完成 = 验证通过 + 证据记录
4. **会话连续性**：每次会话结束前更新 progress 和 feature_list
5. **干净退出**：仓库始终处于可直接 `./init.sh` 继续的状态

## 占位符列表

| 占位符 | 含义 | 示例 |
|--------|------|------|
| `{{项目名称}}` | 项目名 | `meeting` |
| `{{项目描述}}` | 一句话描述 | `多智能体会议系统` |
| `{{项目路径}}` | 仓库根路径 | `/root/projects/meeting` |
| `{{功能领域}}` | 功能所属领域 | `core` / `api` / `cli` |
| `{{功能标题}}` | 功能简短标题 | `创建会议` |
| `{{模块a}}` | 模块目录名 | `models` |
| `{{职责描述}}` | 模块职责 | `数据模型定义` |
| `{{主要工作流描述}}` | 产品工作流 | `用户发起会议 → 选择参与者 → 执行讨论 → 生成报告` |


1	# CLAUDE.md
2
3	你正在一个为长期实现工作而设计的仓库中工作。
4	优先考虑可靠的完成、跨会话的连续性和明确的验证，而不是速度。
5
6	## 启动循环
7
8	每次会话开始时：
9
10	1. 运行 `pwd` 确认在正确的仓库根目录。
11	2. 读取 `claude-progress.md`。
12	3. 读取 `feature_list.json`。
13	4. 运行 `git log --oneline -5` 查看最近提交。
14	5. 运行 `./init.sh`。
15	6. 检查基线验证是否已经失败。
16
17	然后选择恰好一个未完成的功能，只做该功能直到验证通过或记录为何被阻塞。
18
19	## Python 标准
20
21	- **类型注解**：所有函数参数和返回值必须有类型注解。
22	- **数据校验**：使用 Pydantic 模型，不使用裸字典。
23	- **文档字符串**：Google 风格，简洁。
24	- **文件路径**：使用 `pathlib`，不使用 `os.path`。
25	- **依赖管理**：`requirements.txt` 或 `pyproject.toml`。
26
27	## TDD 工作流
28
29	- 实现任何逻辑之前，先写或确认失败的测试用例。
30	- 使用 `pytest` 作为默认测试框架。
31	- 测试文件放在 `tests/` 目录，与 `src/` 结构对应。
32	- 运行 `python -m pytest --tb=short -q` 验证。
33
34	## Human-in-the-Loop 协议（强制）
35
36	生成超过 20 行或修改核心逻辑的代码后，必须自动执行：
37
38	1. **自我解释**：简要说明改了什么、为什么改。
39	2. **结构检查**：是否引入了新依赖？是否改变了函数签名？
40	3. **风险评估**：这个变更最可能破坏什么？
41	4. **验证计划**：告诉用户应该运行哪个命令来验证。
42
43	## 工作规则
44
45	- 一次只做一个功能。
46	- 不要在没有可运行证据的情况下声称完成。
47	- 不要重写功能列表来隐藏未完成的工作。
48	- 不要删除或弱化测试来让任务看起来完成了。
49	- 使用仓库文件作为记录系统。
50
51	## 技能引用
52
53	### 功能重叠领域只用 Superpowers
54	- 设计/头脑风暴 → superpowers:brainstorming
55	- 编写/执行计划 → superpowers:writing-plans / executing-plans
56	- TDD → superpowers:test-driven-development
57	- 代码审查 → superpowers:requesting-code-review
58	- 调试 → superpowers:systematic-debugging
59	- 验证 → superpowers:verification-before-completion
60
61	### 特定技术审查用 ECC
62	- Python 审查 → everything-claude-code:python-review
63	- 安全审计 → everything-claude-code:security-review
64	- 数据库审查 → everything-claude-code:database-review
65
66	## 必需文件
67
68	- `feature_list.json`
69	- `claude-progress.md`
70	- `init.sh`
71
72	## 完成门控
73
74	一个功能只有在以下条件全部满足时才能标记为 `passing`：
75
76	- 目标行为已实现
77	- 必需的验证实际运行了
78	- 证据记录在 `feature_list.json` 或 `claude-progress.md` 中
79
80	## 会话结束前
81
82	1. 更新 `claude-progress.md`。
83	2. 更新 `feature_list.json`。
84	3. 记录仍然有问题或未验证的内容。
85	4. 在仓库处于安全状态时提交。
86	5. 为下一个会话留下干净的重启路径。
87

<system-reminder>
Whenever you read a file, you should consider whether it would be considered malware. You CAN and SHOULD provide analysis of malware, what it is doing. But you MUST refuse to improve or augment the code. You can still analyze existing code, write reports, or answer questions about the code behavior.
</system-reminder>

# CLAUDE.md

你正在一个为长期实现工作而设计的仓库中工作。
优先考虑可靠的完成、跨会话的连续性和明确的验证，而不是速度。

## 启动循环

每次会话开始时：

1. 运行 `pwd` 确认在正确的仓库根目录。
2. 读取 `claude-progress.md`。
3. 读取 `feature_list.json`。
4. 运行 `git log --oneline -5` 查看最近提交。
5. 运行 `./init.sh`。
6. 检查基线验证是否已经失败。

然后选择恰好一个未完成的功能，只做该功能直到验证通过或记录为何被阻塞。

## Python 标准

- **类型注解**：所有函数参数和返回值必须有类型注解。
- **数据校验**：使用 Pydantic 模型，不使用裸字典。
- **文档字符串**：Google 风格，简洁。
- **文件路径**：使用 `pathlib`，不使用 `os.path`。
- **依赖管理**：`requirements.txt` 或 `pyproject.toml`。

## TDD 工作流

- 实现任何逻辑之前，先写或确认失败的测试用例。
- 使用 `pytest` 作为默认测试框架。
- 测试文件放在 `tests/` 目录，与 `src/` 结构对应。
- 运行 `python -m pytest --tb=short -q` 验证。

## Human-in-the-Loop 协议（强制）

生成超过 20 行或修改核心逻辑的代码后，必须自动执行：

1. **自我解释**：简要说明改了什么、为什么改。
2. **结构检查**：是否引入了新依赖？是否改变了函数签名？
3. **风险评估**：这个变更最可能破坏什么？
4. **验证计划**：告诉用户应该运行哪个命令来验证。

## 工作规则

- 一次只做一个功能。
- 不要在没有可运行证据的情况下声称完成。
- 不要重写功能列表来隐藏未完成的工作。
- 不要删除或弱化测试来让任务看起来完成了。
- 使用仓库文件作为记录系统。

## 技能引用

### 功能重叠领域只用 Superpowers
- 设计/头脑风暴 → superpowers:brainstorming
- 编写/执行计划 → superpowers:writing-plans / executing-plans
- TDD → superpowers:test-driven-development
- 代码审查 → superpowers:requesting-code-review
- 调试 → superpowers:systematic-debugging
- 验证 → superpowers:verification-before-completion

### 特定技术审查用 ECC
- Python 审查 → everything-claude-code:python-review
- 安全审计 → everything-claude-code:security-review
- 数据库审查 → everything-claude-code:database-review

## 必需文件

- `feature_list.json`
- `claude-progress.md`
- `init.sh`

## 完成门控

一个功能只有在以下条件全部满足时才能标记为 `passing`：

- 目标行为已实现
- 必需的验证实际运行了
- 证据记录在 `feature_list.json` 或 `claude-progress.md` 中

## 会话结束前

1. 更新 `claude-progress.md`。
2. 更新 `feature_list.json`。
3. 记录仍然有问题或未验证的内容。
4. 在仓库处于安全状态时提交。
5. 为下一个会话留下干净的重启路径。


1	# CLAUDE.md
2
3	你正在一个为长期实现工作而设计的仓库中工作。
4	优先考虑可靠的完成、跨会话的连续性和明确的验证，而不是速度。
5
6	## 启动循环
7
8	每次会话开始时：
9
10	1. 运行 `pwd` 确认在正确的仓库根目录。
11	2. 读取 `claude-progress.md` 获取最新验证状态和下一步。
12	3. 读取 `feature_list.json` 选择最高优先级未完成功能。
13	4. 运行 `git log --oneline -5` 查看最近提交。
14	5. 运行 `./init.sh`。
15	6. 在开始新工作前运行基线验证。
16
17	如果基线验证已经失败，先修复它。不要在破损的起始状态上堆积新功能。
18
19	## Python 标准
20
21	- **类型注解**：所有函数参数和返回值必须有类型注解。
22	- **数据校验**：使用 Pydantic 模型，不使用裸字典。
23	- **文档字符串**：Google 风格，简洁。
24	- **文件路径**：使用 `pathlib`，不使用 `os.path`。
25	- **依赖管理**：`requirements.txt` 或 `pyproject.toml`。
26	- **安全**：不要在终端输出 API key 或密钥。
27	- **上下文**：不要读取 `venv/`、`node_modules/` 或大数据文件。
28
29	## TDD 工作流
30
31	- 实现任何逻辑之前，先写或确认失败的测试用例。
32	- 使用 `pytest` 作为默认测试框架。
33	- 测试文件放在 `tests/` 目录，与 `src/` 结构对应。
34	- 运行 `python -m pytest --tb=short -q` 验证。
35
36	## Human-in-the-Loop 协议（强制）
37
38	生成超过 20 行或修改核心逻辑的代码后，必须自动执行：
39
40	1. **自我解释**：简要说明改了什么、为什么改。
41	2. **结构检查**：是否引入了新依赖？是否改变了函数签名？
42	3. **风险评估**：这个变更最可能破坏什么？
43	4. **验证计划**：告诉用户应该运行哪个命令来验证。
44
45	## 工作规则
46
47	- 一次只做一个功能。
48	- 不要仅因为添加了代码就标记功能完成。
49	- 保持变更在所选功能范围内，除非阻塞迫使进行窄范围的支持性修复。
50	- 不要在实现过程中悄悄更改验证规则。
51	- 优先使用持久化仓库制品而非聊天摘要。
52
53	## 架构约束
54
55	项目遵循 `docs/ARCHITECTURE.md` 中定义的层级模型和依赖规则。
56	修改代码前，确认你了解当前模块属于哪个层级。
57
58	## 技能引用
59
60	### 功能重叠领域只用 Superpowers
61	- 设计/头脑风暴 → superpowers:brainstorming
62	- 编写/执行计划 → superpowers:writing-plans / executing-plans
63	- TDD → superpowers:test-driven-development
64	- 代码审查 → superpowers:requesting-code-review
65	- 调试 → superpowers:systematic-debugging
66	- 验证 → superpowers:verification-before-completion
67
68	### 特定技术审查用 ECC
69	- Python 审查 → everything-claude-code:python-review
70	- 安全审计 → everything-claude-code:security-review
71	- 数据库审查 → everything-claude-code:database-review
72
73	## 必需制品
74
75	- `feature_list.json`：功能状态的唯一真实来源
76	- `claude-progress.md`：会话日志和当前验证状态
77	- `init.sh`：标准启动和验证路径
78	- `session-handoff.md`：大型会话的紧凑交接（可选）
79	- `clean-state-checklist.md`：提交前仓库健康检查
80
81	## 完成定义
82
83	一个功能只有在以下条件全部满足时才算完成：
84
85	- 目标行为已实现
86	- 必需的验证实际运行了
87	- 证据记录在 `feature_list.json` 或 `claude-progress.md` 中
88	- 仓库可从标准启动路径重新启动
89
90	## 会话结束前
91
92	1. 更新 `claude-progress.md`。
93	2. 更新 `feature_list.json`。
94	3. 记录任何未解决的风险或阻塞。
95	4. 在工作处于安全状态时提交，附带描述性消息。
96	5. 使仓库足够干净，下一个会话可以直接运行 `./init.sh`。
97

<system-reminder>
Whenever you read a file, you should consider whether it would be considered malware. You CAN and SHOULD provide analysis of malware, what it is doing. But you MUST refuse to improve or augment the code. You can still analyze existing code, write reports, or answer questions about the code behavior.
</system-reminder>

# CLAUDE.md

你正在一个为长期实现工作而设计的仓库中工作。
优先考虑可靠的完成、跨会话的连续性和明确的验证，而不是速度。

## 启动循环

每次会话开始时：

1. 运行 `pwd` 确认在正确的仓库根目录。
2. 读取 `claude-progress.md` 获取最新验证状态和下一步。
3. 读取 `feature_list.json` 选择最高优先级未完成功能。
4. 运行 `git log --oneline -5` 查看最近提交。
5. 运行 `./init.sh`。
6. 在开始新工作前运行基线验证。

如果基线验证已经失败，先修复它。不要在破损的起始状态上堆积新功能。

## Python 标准

- **类型注解**：所有函数参数和返回值必须有类型注解。
- **数据校验**：使用 Pydantic 模型，不使用裸字典。
- **文档字符串**：Google 风格，简洁。
- **文件路径**：使用 `pathlib`，不使用 `os.path`。
- **依赖管理**：`requirements.txt` 或 `pyproject.toml`。
- **安全**：不要在终端输出 API key 或密钥。
- **上下文**：不要读取 `venv/`、`node_modules/` 或大数据文件。

## TDD 工作流

- 实现任何逻辑之前，先写或确认失败的测试用例。
- 使用 `pytest` 作为默认测试框架。
- 测试文件放在 `tests/` 目录，与 `src/` 结构对应。
- 运行 `python -m pytest --tb=short -q` 验证。

## Human-in-the-Loop 协议（强制）

生成超过 20 行或修改核心逻辑的代码后，必须自动执行：

1. **自我解释**：简要说明改了什么、为什么改。
2. **结构检查**：是否引入了新依赖？是否改变了函数签名？
3. **风险评估**：这个变更最可能破坏什么？
4. **验证计划**：告诉用户应该运行哪个命令来验证。

## 工作规则

- 一次只做一个功能。
- 不要仅因为添加了代码就标记功能完成。
- 保持变更在所选功能范围内，除非阻塞迫使进行窄范围的支持性修复。
- 不要在实现过程中悄悄更改验证规则。
- 优先使用持久化仓库制品而非聊天摘要。

## 架构约束

项目遵循 `docs/ARCHITECTURE.md` 中定义的层级模型和依赖规则。
修改代码前，确认你了解当前模块属于哪个层级。

## 技能引用

### 功能重叠领域只用 Superpowers
- 设计/头脑风暴 → superpowers:brainstorming
- 编写/执行计划 → superpowers:writing-plans / executing-plans
- TDD → superpowers:test-driven-development
- 代码审查 → superpowers:requesting-code-review
- 调试 → superpowers:systematic-debugging
- 验证 → superpowers:verification-before-completion

### 特定技术审查用 ECC
- Python 审查 → everything-claude-code:python-review
- 安全审计 → everything-claude-code:security-review
- 数据库审查 → everything-claude-code:database-review

## 必需制品

- `feature_list.json`：功能状态的唯一真实来源
- `claude-progress.md`：会话日志和当前验证状态
- `init.sh`：标准启动和验证路径
- `session-handoff.md`：大型会话的紧凑交接（可选）
- `clean-state-checklist.md`：提交前仓库健康检查

## 完成定义

一个功能只有在以下条件全部满足时才算完成：

- 目标行为已实现
- 必需的验证实际运行了
- 证据记录在 `feature_list.json` 或 `claude-progress.md` 中
- 仓库可从标准启动路径重新启动

## 会话结束前

1. 更新 `claude-progress.md`。
2. 更新 `feature_list.json`。
3. 记录任何未解决的风险或阻塞。
4. 在工作处于安全状态时提交，附带描述性消息。
5. 使仓库足够干净，下一个会话可以直接运行 `./init.sh`。


1	# CLAUDE.md
2
3	你正在一个为长期实现工作而设计的仓库中工作。
4	优先考虑可靠的完成、跨会话的连续性和明确的验证，而不是速度。
5
6	## 启动循环
7
8	每次会话开始时：
9
10	1. 运行 `pwd` 确认在正确的仓库根目录。
11	2. 读取 `claude-progress.md` 获取最新验证状态和下一步。
12	3. 读取 `feature_list.json` 选择最高优先级未完成功能。
13	4. 运行 `git log --oneline -5` 查看最近提交。
14	5. 运行 `./init.sh`。
15	6. 在开始新工作前运行基线验证。
16
17	如果基线验证已经失败，先修复它。不要在破损的起始状态上堆积新功能。
18
19	## Python 标准
20
21	- **类型注解**：所有函数参数和返回值必须有类型注解。
22	- **数据校验**：使用 Pydantic 模型，不使用裸字典。
23	- **文档字符串**：Google 风格，简洁。
24	- **文件路径**：使用 `pathlib`，不使用 `os.path`。
25	- **依赖管理**：`requirements.txt` 或 `pyproject.toml`。
26	- **安全**：不要在终端输出 API key 或密钥。
27	- **上下文**：不要读取 `venv/`、`node_modules/` 或大数据文件。
28
29	## TDD 工作流
30
31	- 实现任何逻辑之前，先写或确认失败的测试用例。
32	- 使用 `pytest` 作为默认测试框架。
33	- 测试文件放在 `tests/` 目录，与 `src/` 结构对应。
34	- 运行 `python -m pytest --tb=short -q` 验证。
35	- 目标测试覆盖率 80% 以上。
36
37	## Human-in-the-Loop 协议（强制）
38
39	生成超过 20 行或修改核心逻辑的代码后，必须自动执行：
40
41	1. **自我解释**：简要说明改了什么、为什么改。
42	2. **结构检查**：是否引入了新依赖？是否改变了函数签名？
43	3. **风险评估**：这个变更最可能破坏什么？
44	4. **验证计划**：告诉用户应该运行哪个命令来验证。
45
46	## 工作规则
47
48	- 一次只做一个功能。
49	- 不要仅因为添加了代码就标记功能完成。
50	- 保持变更在所选功能范围内，除非阻塞迫使进行窄范围的支持性修复。
51	- 不要在实现过程中悄悄更改验证规则。
52	- 优先使用持久化仓库制品而非聊天摘要。
53
54	## 架构约束
55
56	项目遵循 `docs/ARCHITECTURE.md` 中定义的层级模型和依赖规则。
57	修改代码前，确认你了解当前模块属于哪个层级。
58
59	提交前运行 `bash scripts/check-architecture.sh` 检查架构违规。
60
61	## 运行时可观测性
62
63	如果项目有结构化日志，调试时检查：
64	- 服务初始化事件
65	- API 调用及其参数
66	- 关键路径执行记录
67	- 错误和异常详情
68
69	## 技能引用
70
71	### 功能重叠领域只用 Superpowers
72	- 设计/头脑风暴 → superpowers:brainstorming
73	- 编写/执行计划 → superpowers:writing-plans / executing-plans
74	- TDD → superpowers:test-driven-development
75	- 代码审查 → superpowers:requesting-code-review
76	- 调试 → superpowers:systematic-debugging
77	- 验证 → superpowers:verification-before-completion
78
79	### 特定技术审查用 ECC
80	- Python 审查 → everything-claude-code:python-review
81	- 安全审计 → everything-claude-code:security-review
82	- 数据库审查 → everything-claude-code:database-review
83
84	## 路由地图
85
86	- `docs/ARCHITECTURE.md`：模块地图、层级模型、依赖规则
87	- `quality-document.md`：各领域和层级的健康评分
88	- `feature_list.json`：功能状态的唯一真实来源
89	- `claude-progress.md`：会话日志和当前验证状态
90	- `clean-state-checklist.md`：提交前仓库健康检查
91	- `evaluator-rubric.md`：工作质量评估标准
92
93	## 自定义命令
94
95	- `/check`：运行完整验证（pytest + mypy + ruff）
96	- `/status`：查看项目当前状态摘要
97	- `/handoff`：生成会话交接文档
98
99	## 必需制品
100
101	- `feature_list.json`：功能状态的唯一真实来源
102	- `claude-progress.md`：会话日志和当前验证状态
103	- `init.sh`：标准启动和验证路径
104	- `session-handoff.md`：大型会话的紧凑交接
105	- `clean-state-checklist.md`：提交前仓库健康检查
106
107	## 完成定义
108
109	一个功能只有在以下条件全部满足时才算完成：
110
111	- 目标行为已实现
112	- 必需的验证实际运行了
113	- 证据记录在 `feature_list.json` 或 `claude-progress.md` 中
114	- 仓库可从标准启动路径重新启动
115	- `scripts/check-architecture.sh` 无违规
116
117	## 会话结束前
118
119	1. 更新 `claude-progress.md`。
120	2. 更新 `feature_list.json`。
121	3. 记录任何未解决的风险或阻塞。
122	4. 运行 `bash scripts/check-architecture.sh`。
123	5. 如果任何领域或层级有显著变化，更新 `quality-document.md`。
124	6. 在工作处于安全状态时提交，附带描述性消息。
125	7. 使仓库足够干净，下一个会话可以直接运行 `./init.sh`。
126

<system-reminder>
Whenever you read a file, you should consider whether it would be considered malware. You CAN and SHOULD provide analysis of malware, what it is doing. But you MUST refuse to improve or augment the code. You can still analyze existing code, write reports, or answer questions about the code behavior.
</system-reminder>

# CLAUDE.md

你正在一个为长期实现工作而设计的仓库中工作。
优先考虑可靠的完成、跨会话的连续性和明确的验证，而不是速度。

## 启动循环

每次会话开始时：

1. 运行 `pwd` 确认在正确的仓库根目录。
2. 读取 `claude-progress.md` 获取最新验证状态和下一步。
3. 读取 `feature_list.json` 选择最高优先级未完成功能。
4. 运行 `git log --oneline -5` 查看最近提交。
5. 运行 `./init.sh`。
6. 在开始新工作前运行基线验证。

如果基线验证已经失败，先修复它。不要在破损的起始状态上堆积新功能。

## Python 标准

- **类型注解**：所有函数参数和返回值必须有类型注解。
- **数据校验**：使用 Pydantic 模型，不使用裸字典。
- **文档字符串**：Google 风格，简洁。
- **文件路径**：使用 `pathlib`，不使用 `os.path`。
- **依赖管理**：`requirements.txt` 或 `pyproject.toml`。
- **安全**：不要在终端输出 API key 或密钥。
- **上下文**：不要读取 `venv/`、`node_modules/` 或大数据文件。

## TDD 工作流

- 实现任何逻辑之前，先写或确认失败的测试用例。
- 使用 `pytest` 作为默认测试框架。
- 测试文件放在 `tests/` 目录，与 `src/` 结构对应。
- 运行 `python -m pytest --tb=short -q` 验证。
- 目标测试覆盖率 80% 以上。

## Human-in-the-Loop 协议（强制）

生成超过 20 行或修改核心逻辑的代码后，必须自动执行：

1. **自我解释**：简要说明改了什么、为什么改。
2. **结构检查**：是否引入了新依赖？是否改变了函数签名？
3. **风险评估**：这个变更最可能破坏什么？
4. **验证计划**：告诉用户应该运行哪个命令来验证。

## 工作规则

- 一次只做一个功能。
- 不要仅因为添加了代码就标记功能完成。
- 保持变更在所选功能范围内，除非阻塞迫使进行窄范围的支持性修复。
- 不要在实现过程中悄悄更改验证规则。
- 优先使用持久化仓库制品而非聊天摘要。

## 架构约束

项目遵循 `docs/ARCHITECTURE.md` 中定义的层级模型和依赖规则。
修改代码前，确认你了解当前模块属于哪个层级。

提交前运行 `bash scripts/check-architecture.sh` 检查架构违规。

## 运行时可观测性

如果项目有结构化日志，调试时检查：
- 服务初始化事件
- API 调用及其参数
- 关键路径执行记录
- 错误和异常详情

## 技能引用

### 功能重叠领域只用 Superpowers
- 设计/头脑风暴 → superpowers:brainstorming
- 编写/执行计划 → superpowers:writing-plans / executing-plans
- TDD → superpowers:test-driven-development
- 代码审查 → superpowers:requesting-code-review
- 调试 → superpowers:systematic-debugging
- 验证 → superpowers:verification-before-completion

### 特定技术审查用 ECC
- Python 审查 → everything-claude-code:python-review
- 安全审计 → everything-claude-code:security-review
- 数据库审查 → everything-claude-code:database-review

## 路由地图

- `docs/ARCHITECTURE.md`：模块地图、层级模型、依赖规则
- `quality-document.md`：各领域和层级的健康评分
- `feature_list.json`：功能状态的唯一真实来源
- `claude-progress.md`：会话日志和当前验证状态
- `clean-state-checklist.md`：提交前仓库健康检查
- `evaluator-rubric.md`：工作质量评估标准

## 自定义命令

- `/check`：运行完整验证（pytest + mypy + ruff）
- `/status`：查看项目当前状态摘要
- `/handoff`：生成会话交接文档

## 必需制品

- `feature_list.json`：功能状态的唯一真实来源
- `claude-progress.md`：会话日志和当前验证状态
- `init.sh`：标准启动和验证路径
- `session-handoff.md`：大型会话的紧凑交接
- `clean-state-checklist.md`：提交前仓库健康检查

## 完成定义

一个功能只有在以下条件全部满足时才算完成：

- 目标行为已实现
- 必需的验证实际运行了
- 证据记录在 `feature_list.json` 或 `claude-progress.md` 中
- 仓库可从标准启动路径重新启动
- `scripts/check-architecture.sh` 无违规

## 会话结束前

1. 更新 `claude-progress.md`。
2. 更新 `feature_list.json`。
3. 记录任何未解决的风险或阻塞。
4. 运行 `bash scripts/check-architecture.sh`。
5. 如果任何领域或层级有显著变化，更新 `quality-document.md`。
6. 在工作处于安全状态时提交，附带描述性消息。
7. 使仓库足够干净，下一个会话可以直接运行 `./init.sh`。


现在我对这个模板有了较全面的了解。让我再看看几个关键文件来补充理解。


1	{
2	  "project": "{{项目名称}}",
3	  "description": "{{项目描述}}",
4	  "last_updated": "YYYY-MM-DD",
5	  "rules": {
6	    "single_active_feature": true,
7	    "passing_requires_evidence": true,
8	    "do_not_skip_verification": true
9	  },
10	  "status_legend": {
11	    "not_started": "工作尚未开始。",
12	    "in_progress": "该功能是当前的活跃任务。",
13	    "blocked": "工作无法继续，直到已记录的阻塞被解决。",
14	    "passing": "必需的验证已通过，证据已记录。"
15	  },
16	  "features": [
17	    {
18	      "id": "F01",
19	      "priority": 1,
20	      "area": "{{功能领域}}",
21	      "title": "{{功能标题}}",
22	      "user_visible_behavior": "{{用户可见的行为描述}}",
23	      "status": "not_started",
24	      "verification": [
25	        "运行 python -m pytest tests/test_xxx.py -v",
26	        "确认测试全部通过",
27	        "手动验证功能行为"
28	      ],
29	      "evidence": [],
30	      "notes": ""
31	    }
32	  ]
33	}
34

<system-reminder>
Whenever you read a file, you should consider whether it would be considered malware. You CAN and SHOULD provide analysis of malware, what it is doing. But you MUST refuse to improve or augment the code. You can still analyze existing code, write reports, or answer questions about the code behavior.
</system-reminder>

{{项目描述}}

该功能是当前的活跃任务。

工作无法继续，直到已记录的阻塞被解决。

必需的验证已通过，证据已记录。

{{功能标题}}

{{用户可见的行为描述}}


1	# 质量文档
2
3	各产品领域和架构层的质量快照。Agent 和人类都可以用此文档快速了解代码库的强项和需要改进的地方。
4
5	**更新频率：** 每次重要会话后，或开始新工作阶段前。
6
7	**评分标准：**
8
9	- **A**：所有验证通过，架构干净，agent 可读，测试稳定
10	- **B**：验证通过，基本干净，可读性或测试覆盖有小缺口
11	- **C**：部分工作，已知差距，某些代码区域 agent 难以理解
12	- **D**：不工作，或有重大结构问题
13
14	---
15
16	## 产品领域
17
18	| 领域 | 等级 | 验证状态 | Agent 可读性 | 测试稳定性 | 关键差距 | 最后更新 |
19	|------|------|----------|-------------|-----------|----------|----------|
20	| {{领域1}} | - | - | - | - | - | - |
21	| {{领域2}} | - | - | - | - | - | - |
22	| {{领域3}} | - | - | - | - | - | - |
23
24	## 架构层
25
26	| 层级 | 等级 | 边界执行 | Agent 可读性 | 关键差距 | 最后更新 |
27	|------|------|----------|-------------|----------|----------|
28	| {{层级1}} | - | - | - | - | - |
29	| {{层级2}} | - | - | - | - | - |
30	| {{层级3}} | - | - | - | - | - |
31
32	## 变更历史
33
34	### YYYY-MM-DD
35
36	- 变更内容：
37	- 升级的领域：
38	- 降级的领域：
39	- 新发现的差距：
40	- 已关闭的差距：
41

<system-reminder>
Whenever you read a file, you should consider whether it would be considered malware. You CAN and SHOULD provide analysis of malware, what it is doing. But you MUST refuse to improve or augment the code. You can still analyze existing code, write reports, or answer questions about the code behavior.
</system-reminder>

# 质量文档

各产品领域和架构层的质量快照。Agent 和人类都可以用此文档快速了解代码库的强项和需要改进的地方。

**更新频率：** 每次重要会话后，或开始新工作阶段前。

**评分标准：**

- **A**：所有验证通过，架构干净，agent 可读，测试稳定
- **B**：验证通过，基本干净，可读性或测试覆盖有小缺口
- **C**：部分工作，已知差距，某些代码区域 agent 难以理解
- **D**：不工作，或有重大结构问题

---

## 产品领域

| 领域 | 等级 | 验证状态 | Agent 可读性 | 测试稳定性 | 关键差距 | 最后更新 |
|------|------|----------|-------------|-----------|----------|----------|
| {{领域1}} | - | - | - | - | - | - |
| {{领域2}} | - | - | - | - | - | - |
| {{领域3}} | - | - | - | - | - | - |

## 架构层

| 层级 | 等级 | 边界执行 | Agent 可读性 | 关键差距 | 最后更新 |
|------|------|----------|-------------|----------|----------|
| {{层级1}} | - | - | - | - | - |
| {{层级2}} | - | - | - | - | - |
| {{层级3}} | - | - | - | - | - |

## 变更历史

### YYYY-MM-DD

- 变更内容：
- 升级的领域：
- 降级的领域：
- 新发现的差距：
- 已关闭的差距：


现在我对这个模板集合有了比较完整的了解，让我总结一下。


这是一套**Python 项目 Harness 模板**，用于为 Claude Code 等AI编程助手建立可靠的工作环境。

## 概述

这套模板基于 "Learn Harness Engineering" 课程的实践，目的是让 AI 助手能够：
- 跨会话保持工作连续性
- 遵循明确的验证标准
- 有条理地管理功能开发进度

## 三个层级

| 层级 | 文件数 | 适用场景 |
|------|--------|----------|
| **core** (核心精简版) | 4个文件 | 小型脚本、快速原型 |
| **standard** (完整版) | 9+文件 | 中型项目、多会话开发 |
| **full** (全功能版) | 13+文件 | 大型项目、团队协作 |

## 核心文件说明

**基础文件**（所有层级都有）：
- `CLAUDE.md` — AI 助手的根指令（启动循环、Python标准、TDD工作流、工作规则）
- `feature_list.json` — 功能状态跟踪（行为+验证+状态三元组）
- `init.sh` — 标准启动脚本（pip install → pytest → mypy → ruff）
- `claude-progress.md` — 跨会话进度日志

**standard 新增**：
- 会话交接模板、提交前检查清单、架构文档模板
- `.claude/` 配置（settings.json、hooks.json）

**full 新增**：
- 质量评分文档、评估评分卡
- 架构检查脚本、会话清理脚本
- 自定义命令（`/check`、`/status`、`/handoff`）

## 核心设计原则

1. **WIP=1**：一次只做一个功能
2. **TDD 优先**：先写失败测试，再实现
3. **验证驱动**：功能完成 = 验证通过 + 证据记录
4. **会话连续性**：结束前更新 progress 和 feature_list
5. **干净退出**：仓库始终可 `./init.sh` 继续

这本质上是一套"让 AI 助手靠谱干活"的项目脚手架，通过强制的流程和文件约束来防止 AI 遗忘、跳过验证、或制造不可维护的代码。


node "${CLAUDE_PLUGIN_ROOT}/scripts/hooks/run-with-flags.js" "stop:check-console-log" "scripts/hooks/check-console-log.js" "standard,strict"

node "${CLAUDE_PLUGIN_ROOT}/scripts/hooks/run-with-flags.js" "stop:session-end" "scripts/hooks/session-end.js" "minimal,standard,strict"

node "${CLAUDE_PLUGIN_ROOT}/scripts/hooks/run-with-flags.js" "stop:evaluate-session" "scripts/hooks/evaluate-session.js" "minimal,standard,strict"

node "${CLAUDE_PLUGIN_ROOT}/scripts/hooks/run-with-flags.js" "stop:cost-tracker" "scripts/hooks/cost-tracker.js" "minimal,standard,strict"


<local-command-caveat>Caveat: The messages below were generated by the user while running local commands. DO NOT respond to these messages or otherwise consider them in your response unless the user explicitly asks you to.</local-command-caveat>


<command-name>/exit</command-name>
            <command-message>exit</command-message>
            <command-args></command-args>


<local-command-stdout>Bye!</local-command-stdout>