harness-step1-create-agent-md

Name: harness-step1-create-agent-md
Author: simbajigege

113stars21forks

How to install harness-step1-create-agent-md?

simbajigege/book2skills/harness-step1-create-agent-md

$npx -y skills add simbajigege/book2skills --skill harness-step1-create-agent-md

Installs into the current project.

Summary

Harness Engineering 第一阶段：扫描现有项目，生成 AGENTS.md（目录文件）和完整的 docs/ 知识库结构。当用户想要"为项目添加 agent 支持"、"让 AI 更好地理解我的项目"、"开始 harness engineering"、 "创建 AGENTS.md"、"搭建 agent 文档结构"、"让 Claude Code 更好地工作"时，立即使用此 skill。也适用于用户说"帮我把项目文档整理好给 agent 用"、"我想开始用 AI agent 开发"、 "梳理这个项目能解决什么业务问题"或要求建立 busines

Files · 1

View on GitHub

SKILL.md

1	# Harness Step 1: 创建 AGENTS.md 与 docs/ 知识库
2
3	## 目标
4
5	为项目建立 agent 可读的知识库地基：
6	- 一份简短的 `AGENTS.md`（~100 行，作为"目录"而非百科全书）
7	- 一套 `docs/` 目录结构，存放真正的知识
8
9	核心原则：agent 看不到的东西就不存在。项目的业务定位、目标用户、解决的问题、架构决策、命名约定和技术选型，必须以文件形式存在于仓库中。
10
11	---
12
13	## 执行步骤
14
15	### Step 1：扫描项目
16
17	按顺序收集项目信息，已知信息跳过，不要重复提问：
18
19	```bash
20	# 1. 项目根目录结构（2层）
21	find . -maxdepth 2 -not -path '/node_modules/' -not -path '/.git/' \
22	-not -path '/__pycache__/' -not -path '/dist/' -not -path '/.next/' \| sort
23
24	# 2. 识别技术栈
25	cat package.json 2>/dev/null \|\| cat pyproject.toml 2>/dev/null \|\| \
26	cat go.mod 2>/dev/null \|\| cat Cargo.toml 2>/dev/null \|\| echo "未找到包管理文件"
27
28	# 3. 查看是否已有文档
29	ls -la *.md 2>/dev/null; ls -la docs/ 2>/dev/null
30
31	# 4. 查看 README（如有）
32	head -80 README.md 2>/dev/null \|\| head -80 readme.md 2>/dev/null
33	```
34
35	从扫描结果中提取：
36	- 项目名称和用途（从 README 或 package.json）
37	- 业务定位和用户价值（服务谁、解决什么问题、提供哪些可见能力）
38	- 典型业务场景（从 README 功能、示例、截图说明和已有产品文档提取）
39	- 技术栈（语言、框架、主要依赖）
40	- 目录结构（主要模块划分）
41	- 已有文档（避免重复，复用现有内容）
42
43	业务内容必须区分“仓库明确声明的现有能力”和“根据功能推断的潜在场景”。仅有营销描述、没有代码或产品文档证据的内容标注「待 Step 2 验证」。
44
45	### Step 2：生成 docs/ 目录结构
46
47	创建以下文件（内容根据扫描结果填写，不要留空占位符）：
48
49	必须创建的文件：
50
51	```
52	AGENTS.md ← 目录文件，~100行
53	docs/
54	├── business-solution.md ← 业务定位、用户问题、解决方案和能力边界
55	├── ARCHITECTURE.md ← 模块划分、依赖关系
56	├── CONVENTIONS.md ← 命名规则、代码风格
57	├── TECH_DECISIONS.md ← 技术选型理由
58	├── QUALITY.md ← 验收标准、完成定义
59	└── exec-plans/
60	├── active/ ← 当前进行中的计划（空目录，放 .gitkeep）
61	├── completed/ ← 已完成的计划（空目录，放 .gitkeep）
62	├── backlog.md ← 待开发功能列表（已知需求，尚未排期）
63	└── tech-debt-tracker.md ← 已知技术债务
64	```
65
66	可选创建（根据项目实际情况判断）：
67
68	```
69	docs/
70	├── design-docs/ ← 有复杂设计决策时创建
71	├── product-specs/ ← 有产品规格时创建
72	└── references/ ← 有外部文档需要本地化时创建
73	```
74
75	### Step 3：写 AGENTS.md
76
77	严格遵守以下格式，控制在 100 行以内：
78
79	```markdown
80	# [项目名称] — Agent 工作指南
81
82	## 这是什么项目
83	[1-3句话：项目用途、核心功能、服务对象]
84
85	## 快速定向
86	- 我在哪个目录？运行 `pwd` 确认工作目录
87	- 技术栈：[语言] + [框架] + [主要工具]
88	- 入口文件：[主要入口，如 src/main.ts、app/main.py]
89	- 启动命令：[如何启动开发服务器]
90	- 测试命令：[如何跑测试]
91
92	## 知识库地图
93	在做任何修改前，先阅读相关文档：
94
95	\| 我想了解... \| 去读这个文件 \|
96	\|------------\|-------------\|
97	\| 业务定位、目标用户、解决什么问题 \| `docs/business-solution.md` \|
98	\| 整体架构、模块划分 \| `docs/ARCHITECTURE.md` \|
99	\| 命名规则、代码风格 \| `docs/CONVENTIONS.md` \|
100	\| 技术选型原因 \| `docs/TECH_DECISIONS.md` \|
101	\| 什么叫"完成" \| `docs/QUALITY.md` \|
102	\| 当前进行中的计划 \| `docs/exec-plans/active/` \|
103	\| 待开发功能列表 \| `docs/exec-plans/backlog.md` \|
104	\| 已知技术债务 \| `docs/exec-plans/tech-debt-tracker.md` \|
105
106	## 工作规范
107	1. 改之前先读：修改任何模块前，先读对应的架构文档
108	2. 完成即提交：每个功能完成后立即 git commit，写清楚做了什么
109	3. 更新文档：如果你的修改影响了架构或约定，同步更新 docs/
110	4. 不要猜：看不懂的地方先读文档，文档没有再问
111
112	## 禁止事项
113	[根据项目实际情况填写，例如：]
114	- 不要直接修改 `generated/` 目录下的文件（自动生成）
115	- 不要跳过测试直接合并
116	- 不要在 service 层引用 UI 组件（见 docs/ARCHITECTURE.md）
117	```
118
119	### Step 4：写各个 docs/ 文件
120
121	每个文件的内容要求：
122
123	`docs/business-solution.md`
124	- 一句话业务定位，以及项目不是什么
125	- 目标用户/角色和各自的核心任务
126	- 当前业务痛点与项目能力的对应关系
127	- 3-8 个有证据支持的典型业务场景
128	- 一条核心端到端业务流程（从用户输入到获得业务结果）
129	- 能力边界、风险和不适用场景
130	- 现有能力与待开发设想必须明确分开
131	- 如果目标行业、商业模式或业务指标无法从仓库判断，标注「待补充：需业务负责人确认」
132
133	`docs/ARCHITECTURE.md`
134	- 模块/包的划分和职责
135	- 依赖方向规则（哪层能引用哪层）
136	- 主要数据流
137	- 不要写实现细节，写"是什么"和"为什么这样分"
138
139	`docs/CONVENTIONS.md`
140	- 文件命名规则
141	- 变量/函数/类命名规则
142	- 目录组织规则
143	- 注释风格
144	- 任何团队约定俗成的习惯
145
146	`docs/TECH_DECISIONS.md`
147	- 为什么选这个框架而不是其他
148	- 为什么用这个库
149	- 历史上做过的重要架构决定和原因
150	- 如果扫描时无法判断原因，写"待补充"并注明这是需要人工填写的
151
152	`docs/QUALITY.md`
153	- 一个功能算"完成"的标准（Definition of Done）
154	- 代码审查检查清单
155	- 测试覆盖要求
156	- 性能基准（如果有）
157
158	`docs/exec-plans/backlog.md`
159	- 已知但尚未排期的待开发功能列表，这一点可以向用户询问
160	- 每条格式：`[优先级: P1/P2/P3] 功能描述 — 背景说明`
161	- 注意：backlog 是"想做但还没做"，不是技术债务（技术债务是"已有但做得不好"）
162	- 如果扫描时发现后端已实现但前端未上线的功能、或文档中提到的计划中功能，写入此处
163	- 如果扫描时没有发现明显的 backlog，写空列表并注明"待发现时补充"
164
165	`docs/exec-plans/tech-debt-tracker.md`
166	- 已知的技术债务列表（现有代码中质量不佳、需要改进的部分）
167	- 每条格式：`[优先级] 问题描述 — 影响范围`
168	- 注意：不要把 backlog（待开发功能）混入此文件
169	- 如果扫描时没有发现明显债务，写空列表并注明"待发现时补充"
170
171	---
172
173	## 质量检验
174
175	生成完成后，自检以下问题：
176
177	- [ ] AGENTS.md 是否控制在 150 行以内？
178	- [ ] AGENTS.md 里是否有具体的启动/测试命令（而非"见文档"）？
179	- [ ] business-solution.md 是否说明了服务谁、解决什么问题、如何产生价值和能力边界？
180	- [ ] business-solution.md 是否将现有能力与潜在二开设想明确分开？
181	- [ ] docs/ 里的文件是否有实际内容，而非空占位符？
182	- [ ] TECH_DECISIONS.md 里无法判断的决策是否标注了"待补充"？
183	- [ ] 目录表里的每个链接是否对应实际存在的文件？
184
185	---
186
187	## 完成后告知用户
188
189	输出一个简短摘要：
190	1. 创建了哪些文件
191	2. 提取出的业务定位、目标用户和主要解决方案
192	3. 哪些内容是从项目扫描中推断的（可能需要人工核实）
193	4. 哪些字段需要用户手动补充（标注了"待补充"的地方）
194	5. 下一步：运行 `harness-step2-fill-docs` 深度验证业务能力和技术知识库

People who liked this also viewed

6 picks

Type

harness-step1-create-agent-md

113stars21forks

View on GitHub

How to install harness-step1-create-agent-md?

simbajigege/book2skills/harness-step1-create-agent-md

$npx -y skills add simbajigege/book2skills --skill harness-step1-create-agent-md

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Harness Step 1: 创建 AGENTS.md 与 docs/ 知识库
2
3	## 目标
4
5	为项目建立 agent 可读的知识库地基：
6	- 一份简短的 `AGENTS.md`（~100 行，作为"目录"而非百科全书）
7	- 一套 `docs/` 目录结构，存放真正的知识
8
9	核心原则：agent 看不到的东西就不存在。项目的业务定位、目标用户、解决的问题、架构决策、命名约定和技术选型，必须以文件形式存在于仓库中。
10
11	---
12
13	## 执行步骤
14
15	### Step 1：扫描项目
16
17	按顺序收集项目信息，已知信息跳过，不要重复提问：
18
19	```bash
20	# 1. 项目根目录结构（2层）
21	find . -maxdepth 2 -not -path '/node_modules/' -not -path '/.git/' \
22	-not -path '/__pycache__/' -not -path '/dist/' -not -path '/.next/' \| sort
23
24	# 2. 识别技术栈
25	cat package.json 2>/dev/null \|\| cat pyproject.toml 2>/dev/null \|\| \
26	cat go.mod 2>/dev/null \|\| cat Cargo.toml 2>/dev/null \|\| echo "未找到包管理文件"
27
28	# 3. 查看是否已有文档
29	ls -la *.md 2>/dev/null; ls -la docs/ 2>/dev/null
30
31	# 4. 查看 README（如有）
32	head -80 README.md 2>/dev/null \|\| head -80 readme.md 2>/dev/null
33	```
34
35	从扫描结果中提取：
36	- 项目名称和用途（从 README 或 package.json）
37	- 业务定位和用户价值（服务谁、解决什么问题、提供哪些可见能力）
38	- 典型业务场景（从 README 功能、示例、截图说明和已有产品文档提取）
39	- 技术栈（语言、框架、主要依赖）
40	- 目录结构（主要模块划分）
41	- 已有文档（避免重复，复用现有内容）
42
43	业务内容必须区分“仓库明确声明的现有能力”和“根据功能推断的潜在场景”。仅有营销描述、没有代码或产品文档证据的内容标注「待 Step 2 验证」。
44
45	### Step 2：生成 docs/ 目录结构
46
47	创建以下文件（内容根据扫描结果填写，不要留空占位符）：
48
49	必须创建的文件：
50
51	```
52	AGENTS.md ← 目录文件，~100行
53	docs/
54	├── business-solution.md ← 业务定位、用户问题、解决方案和能力边界
55	├── ARCHITECTURE.md ← 模块划分、依赖关系
56	├── CONVENTIONS.md ← 命名规则、代码风格
57	├── TECH_DECISIONS.md ← 技术选型理由
58	├── QUALITY.md ← 验收标准、完成定义
59	└── exec-plans/
60	├── active/ ← 当前进行中的计划（空目录，放 .gitkeep）
61	├── completed/ ← 已完成的计划（空目录，放 .gitkeep）
62	├── backlog.md ← 待开发功能列表（已知需求，尚未排期）
63	└── tech-debt-tracker.md ← 已知技术债务
64	```
65
66	可选创建（根据项目实际情况判断）：
67
68	```
69	docs/
70	├── design-docs/ ← 有复杂设计决策时创建
71	├── product-specs/ ← 有产品规格时创建
72	└── references/ ← 有外部文档需要本地化时创建
73	```
74
75	### Step 3：写 AGENTS.md
76
77	严格遵守以下格式，控制在 100 行以内：
78
79	```markdown
80	# [项目名称] — Agent 工作指南
81
82	## 这是什么项目
83	[1-3句话：项目用途、核心功能、服务对象]
84
85	## 快速定向
86	- 我在哪个目录？运行 `pwd` 确认工作目录
87	- 技术栈：[语言] + [框架] + [主要工具]
88	- 入口文件：[主要入口，如 src/main.ts、app/main.py]
89	- 启动命令：[如何启动开发服务器]
90	- 测试命令：[如何跑测试]
91
92	## 知识库地图
93	在做任何修改前，先阅读相关文档：
94
95	\| 我想了解... \| 去读这个文件 \|
96	\|------------\|-------------\|
97	\| 业务定位、目标用户、解决什么问题 \| `docs/business-solution.md` \|
98	\| 整体架构、模块划分 \| `docs/ARCHITECTURE.md` \|
99	\| 命名规则、代码风格 \| `docs/CONVENTIONS.md` \|
100	\| 技术选型原因 \| `docs/TECH_DECISIONS.md` \|
101	\| 什么叫"完成" \| `docs/QUALITY.md` \|
102	\| 当前进行中的计划 \| `docs/exec-plans/active/` \|
103	\| 待开发功能列表 \| `docs/exec-plans/backlog.md` \|
104	\| 已知技术债务 \| `docs/exec-plans/tech-debt-tracker.md` \|
105
106	## 工作规范
107	1. 改之前先读：修改任何模块前，先读对应的架构文档
108	2. 完成即提交：每个功能完成后立即 git commit，写清楚做了什么
109	3. 更新文档：如果你的修改影响了架构或约定，同步更新 docs/
110	4. 不要猜：看不懂的地方先读文档，文档没有再问
111
112	## 禁止事项
113	[根据项目实际情况填写，例如：]
114	- 不要直接修改 `generated/` 目录下的文件（自动生成）
115	- 不要跳过测试直接合并
116	- 不要在 service 层引用 UI 组件（见 docs/ARCHITECTURE.md）
117	```
118
119	### Step 4：写各个 docs/ 文件
120
121	每个文件的内容要求：
122
123	`docs/business-solution.md`
124	- 一句话业务定位，以及项目不是什么
125	- 目标用户/角色和各自的核心任务
126	- 当前业务痛点与项目能力的对应关系
127	- 3-8 个有证据支持的典型业务场景
128	- 一条核心端到端业务流程（从用户输入到获得业务结果）
129	- 能力边界、风险和不适用场景
130	- 现有能力与待开发设想必须明确分开
131	- 如果目标行业、商业模式或业务指标无法从仓库判断，标注「待补充：需业务负责人确认」
132
133	`docs/ARCHITECTURE.md`
134	- 模块/包的划分和职责
135	- 依赖方向规则（哪层能引用哪层）
136	- 主要数据流
137	- 不要写实现细节，写"是什么"和"为什么这样分"
138
139	`docs/CONVENTIONS.md`
140	- 文件命名规则
141	- 变量/函数/类命名规则
142	- 目录组织规则
143	- 注释风格
144	- 任何团队约定俗成的习惯
145
146	`docs/TECH_DECISIONS.md`
147	- 为什么选这个框架而不是其他
148	- 为什么用这个库
149	- 历史上做过的重要架构决定和原因
150	- 如果扫描时无法判断原因，写"待补充"并注明这是需要人工填写的
151
152	`docs/QUALITY.md`
153	- 一个功能算"完成"的标准（Definition of Done）
154	- 代码审查检查清单
155	- 测试覆盖要求
156	- 性能基准（如果有）
157
158	`docs/exec-plans/backlog.md`
159	- 已知但尚未排期的待开发功能列表，这一点可以向用户询问
160	- 每条格式：`[优先级: P1/P2/P3] 功能描述 — 背景说明`
161	- 注意：backlog 是"想做但还没做"，不是技术债务（技术债务是"已有但做得不好"）
162	- 如果扫描时发现后端已实现但前端未上线的功能、或文档中提到的计划中功能，写入此处
163	- 如果扫描时没有发现明显的 backlog，写空列表并注明"待发现时补充"
164
165	`docs/exec-plans/tech-debt-tracker.md`
166	- 已知的技术债务列表（现有代码中质量不佳、需要改进的部分）
167	- 每条格式：`[优先级] 问题描述 — 影响范围`
168	- 注意：不要把 backlog（待开发功能）混入此文件
169	- 如果扫描时没有发现明显债务，写空列表并注明"待发现时补充"
170
171	---
172
173	## 质量检验
174
175	生成完成后，自检以下问题：
176
177	- [ ] AGENTS.md 是否控制在 150 行以内？
178	- [ ] AGENTS.md 里是否有具体的启动/测试命令（而非"见文档"）？
179	- [ ] business-solution.md 是否说明了服务谁、解决什么问题、如何产生价值和能力边界？
180	- [ ] business-solution.md 是否将现有能力与潜在二开设想明确分开？
181	- [ ] docs/ 里的文件是否有实际内容，而非空占位符？
182	- [ ] TECH_DECISIONS.md 里无法判断的决策是否标注了"待补充"？
183	- [ ] 目录表里的每个链接是否对应实际存在的文件？
184
185	---
186
187	## 完成后告知用户
188
189	输出一个简短摘要：
190	1. 创建了哪些文件
191	2. 提取出的业务定位、目标用户和主要解决方案
192	3. 哪些内容是从项目扫描中推断的（可能需要人工核实）
193	4. 哪些字段需要用户手动补充（标注了"待补充"的地方）
194	5. 下一步：运行 `harness-step2-fill-docs` 深度验证业务能力和技术知识库

People who liked this also viewed

6 picks

Type