easy-coding-harness 0.1.5 → 0.1.6
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/README.md +46 -1
- package/package.json +1 -1
- package/templates/common/skills/ec-analysis/SKILL.md +151 -38
package/README.md
CHANGED
|
@@ -37,7 +37,52 @@ easy-coding --version
|
|
|
37
37
|
- `y`：常规功能升级
|
|
38
38
|
- `z`：日常 bug 修复
|
|
39
39
|
|
|
40
|
-
|
|
40
|
+
### 0.1.6
|
|
41
|
+
|
|
42
|
+
- ec-analysis 改为模板先行（template-first）工作流：分析阶段先创建 dev-spec.md 骨架，再逐步填充各章节。
|
|
43
|
+
- ec-analysis 模板从英文简写替换为完整中文结构化模板，12 个核心必填章节 + 3 个条件展开章节。
|
|
44
|
+
- 新增修订处理规则：用户修改意见必须重新输出完整方案，不允许只回差异摘要。
|
|
45
|
+
- 自检门禁新增"占位符是否全部替换"检查项。
|
|
46
|
+
- 测试策略补充人工验收和无法验证项。
|
|
47
|
+
- 将版本记录从 CHANGELOG.md 迁移到 README.md 统一维护。
|
|
48
|
+
- 新增项目级 CLAUDE.md 和 AGENTS.md 约束文件。
|
|
49
|
+
|
|
50
|
+
### 0.1.5
|
|
51
|
+
|
|
52
|
+
- ec-analysis 模板结构化改进：Change plan 改为五项一行式，Implementation units 输出完整 unit 表，Test strategy 内嵌 testability table + test points。
|
|
53
|
+
|
|
54
|
+
### 0.1.4
|
|
55
|
+
|
|
56
|
+
- 将宽终端 CLI banner 调整为 `ANSI Shadow` 厚重色块字形，恢复类似截图中的块状阴影质感。
|
|
57
|
+
- 中等宽度终端使用 `Small Shadow`，窄终端继续使用 `Small Slant`，避免标题溢出。
|
|
58
|
+
- 保留 0.1.3 的 cyan/blue 分层配色和副标题样式。
|
|
59
|
+
- 修复主约束模板中状态栏示例使用外层双反引号，可能导致 agent 复述 Ready 状态栏时在末尾多带一个反引号的问题。
|
|
60
|
+
|
|
61
|
+
### 0.1.3
|
|
62
|
+
|
|
63
|
+
- 修复 0.1.2 CLI banner 字体过于块状、左右压缩导致难以辨认的问题。
|
|
64
|
+
- 默认字体改为更舒展的 `Big`，中等宽度终端使用 `Doom`，窄终端继续使用 `Small Slant`。
|
|
65
|
+
- 保留 0.1.2 的 cyan/blue 分层配色和副标题样式。
|
|
66
|
+
- 将 hook 注入的 Easy Coding 状态提示收口为单行 Markdown 状态栏，展示 Ready、Waiting init、当前任务、任务状态和 handoff 来源。
|
|
67
|
+
|
|
68
|
+
### 0.1.2
|
|
69
|
+
|
|
70
|
+
- 改进 agent 平台选择提示，明确说明使用 Space 切换选择、Enter 进入确认。
|
|
71
|
+
- 平台选择后增加二次确认，避免误按回车直接按默认平台安装。
|
|
72
|
+
- 优化 CLI 启动标题，默认使用带阴影感的 `ANSI Shadow` 字体，并为窄终端提供 fallback。
|
|
73
|
+
|
|
74
|
+
### 0.1.1
|
|
75
|
+
|
|
76
|
+
- 修复 `easy-coding init` 将任意 `.easy-coding` 目录误判为已安装 harness 的问题。
|
|
77
|
+
- 新增旧版 `easy-coding` skill 产物识别，允许在保留旧数据的前提下接入新 harness。
|
|
78
|
+
- `project-init` 任务会记录旧资产清单，供 `ec-init` 校验、保留和补全旧数据产物。
|
|
79
|
+
- 将 CLI 版本源统一到 `package.json`，避免源码常量与包版本漂移。
|
|
80
|
+
|
|
81
|
+
### 0.1.0
|
|
82
|
+
|
|
83
|
+
- 首个内测基线版本。
|
|
84
|
+
- 提供 `easy-coding init`、`add-agent`、`upgrade`、`status` 基础命令。
|
|
85
|
+
- 支持 Claude Code、Codex、Qoder 三个平台的 skills、hooks、agents 和主约束安装。
|
|
41
86
|
|
|
42
87
|
## 命令
|
|
43
88
|
|
package/package.json
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: ec-analysis
|
|
3
|
-
description: ANALYSIS-stage skill. Use when ec-workflow enters ANALYSIS.
|
|
3
|
+
description: ANALYSIS-stage skill. Use when ec-workflow enters ANALYSIS. Creates the dev-spec skeleton FIRST (template-first), then fills incrementally — producing the narrative plan, execution plan (execution.jsonl), and test strategy. Ends in WAITING_CONFIRM. Grounds every conclusion in real code, never restates the requirement.
|
|
4
4
|
---
|
|
5
5
|
|
|
6
6
|
# ec-analysis — turn a requirement into a confirmable plan
|
|
@@ -27,35 +27,130 @@ by **name**, never local paths). For each involved repo, read its ABSTRACT to un
|
|
|
27
27
|
interface. Cache any local path the user provides only in `state.json.repo_paths`. If a repo
|
|
28
28
|
name cannot be located locally, ask the user for the path before proceeding.
|
|
29
29
|
|
|
30
|
-
##
|
|
31
|
-
|
|
32
|
-
|
|
33
|
-
|
|
34
|
-
|
|
35
|
-
|
|
36
|
-
|
|
37
|
-
|
|
38
|
-
|
|
39
|
-
|
|
40
|
-
|
|
41
|
-
|
|
42
|
-
|
|
43
|
-
|
|
44
|
-
|
|
45
|
-
|
|
46
|
-
|
|
47
|
-
|
|
48
|
-
|
|
49
|
-
|
|
50
|
-
|
|
51
|
-
|
|
52
|
-
|
|
53
|
-
|
|
54
|
-
|
|
55
|
-
|
|
56
|
-
|
|
57
|
-
|
|
58
|
-
|
|
30
|
+
## Analysis procedure (template-first)
|
|
31
|
+
|
|
32
|
+
Create `.easy-coding/tasks/{task-id}/dev-spec.md` with the COMPLETE template skeleton (next
|
|
33
|
+
section) BEFORE reading source code. Every section header and `{待填写}` placeholder must
|
|
34
|
+
exist in the file before any content is filled. Then fill incrementally:
|
|
35
|
+
|
|
36
|
+
1. **Skeleton** — write dev-spec.md with all section headers and `{待填写}` placeholders.
|
|
37
|
+
2. **项目模式 + 任务类型** — fill immediately from task context.
|
|
38
|
+
3. **需求解析** — parse the requirement into 目标 / 输入 / 输出 / 边界.
|
|
39
|
+
4. **现状** — read the actual source files; cite real file paths, classes, call chains. Fill
|
|
40
|
+
the section with evidence. A section that contains no file:line references is invalid.
|
|
41
|
+
5. **冲突摘要 + 待用户决策** — compare requirement against RULES, ABSTRACT, and current code.
|
|
42
|
+
6. **影响面分析 + 改动范围** — enumerate affected modules, fill the table with encoding evidence.
|
|
43
|
+
7. **修改方案 + 实施拆解** — design the approach, decompose into units, decide strategy.
|
|
44
|
+
8. **测试策略 + 风险与注意事项** — classify testability, list test points, identify risks.
|
|
45
|
+
9. **Conditional sections** — fill 背景数据应用 / 核心改动明细 / 前端实现映射 only if
|
|
46
|
+
applicable. Omit entirely if not applicable — never pad.
|
|
47
|
+
10. **Self-check** — run the gates below. Fix any failure in place.
|
|
48
|
+
|
|
49
|
+
Each step is an Edit to the already-existing file. Do not delete the skeleton and rewrite —
|
|
50
|
+
update each section in place.
|
|
51
|
+
|
|
52
|
+
## Required output: dev-spec.md template
|
|
53
|
+
|
|
54
|
+
The skeleton below is the minimum required structure. Write it verbatim as step 1 of the
|
|
55
|
+
procedure above. Omit a conditional section entirely if it does not apply — never pad.
|
|
56
|
+
|
|
57
|
+
````markdown
|
|
58
|
+
[阶段：ANALYSIS]
|
|
59
|
+
|
|
60
|
+
## 技术方案：{任务标题}
|
|
61
|
+
|
|
62
|
+
### 项目模式
|
|
63
|
+
{初创项目/迭代项目}
|
|
64
|
+
|
|
65
|
+
### 任务类型
|
|
66
|
+
{新功能 / Bug 修复 / 重构 / 性能优化 / 前端设计实现}
|
|
67
|
+
|
|
68
|
+
### 需求解析
|
|
69
|
+
- **目标**：{待填写 — 真正要解决的问题}
|
|
70
|
+
- **输入**：{待填写 — 用户输入 / 系统输入 / 触发条件}
|
|
71
|
+
- **输出**：{待填写 — 最终交付结果}
|
|
72
|
+
- **边界**：{待填写 — 明确不做什么}
|
|
73
|
+
|
|
74
|
+
### 现状
|
|
75
|
+
- **相关代码 / 页面 / 接口 / 模块**：{待填写 — 基于实际文件与代码的现状说明}
|
|
76
|
+
- **当前实现方式**：{待填写 — 现在是如何工作的}
|
|
77
|
+
- **现有问题 / 缺口**：{待填写 — 为什么需要改}
|
|
78
|
+
- **证据**：{待填写 — 引用的关键文件、类、页面、接口，含 file:line}
|
|
79
|
+
|
|
80
|
+
### 冲突摘要
|
|
81
|
+
- 需求 vs RULES：{待填写 或 "无冲突"}
|
|
82
|
+
- 需求 vs ABSTRACT：{待填写 或 "无冲突"}
|
|
83
|
+
- 需求 vs 现有代码：{待填写 或 "无冲突"}
|
|
84
|
+
- Dev-Spec vs 现有代码：{待填写 或 "无冲突"}
|
|
85
|
+
|
|
86
|
+
### 待用户决策
|
|
87
|
+
- {待填写 — 影响技术路线、接口、改动范围的问题逐条列出；若无则写"无"}
|
|
88
|
+
|
|
89
|
+
### 影响面分析
|
|
90
|
+
- **涉及模块**：{待填写}
|
|
91
|
+
- **核心类 / 页面 / 接口**：{待填写}
|
|
92
|
+
- **数据库变更**：{有/无}
|
|
93
|
+
- **接口变更**：{有/无}
|
|
94
|
+
- **关联历史任务**：{待填写 — 相关短期记忆序号；无则"无"}
|
|
95
|
+
|
|
96
|
+
### 改动范围
|
|
97
|
+
| 改动文件 | 改动类型 | 文件编码 | 改动核心内容 |
|
|
98
|
+
|----------|---------|---------|-------------|
|
|
99
|
+
| `{文件路径}` | 新增 | 项目编码 {X}，依据：{xxx} | {核心改动} |
|
|
100
|
+
| `{文件路径}` | 修改 | 保持原编码 {X} | {核心改动} |
|
|
101
|
+
| `{文件路径}` | 删除 | — | {删除原因} |
|
|
102
|
+
|
|
103
|
+
### 修改方案
|
|
104
|
+
- **总体改法**：{待填写 — 一句话说清改哪里、怎么改}
|
|
105
|
+
- **后端改动**：{待填写；不涉及则写"不涉及"}
|
|
106
|
+
- **前端改动**：{待填写；不涉及则写"不涉及"}
|
|
107
|
+
- **兼容处理**：{待填写 — 旧逻辑如何迁移、保留或替换}
|
|
108
|
+
- **风险点**：{待填写 — 最容易出问题的位置}
|
|
109
|
+
|
|
110
|
+
### 实施拆解
|
|
111
|
+
|
|
112
|
+
| 单元 | 说明 | 类型 | 涉及文件 | 依赖 |
|
|
113
|
+
|------|------|------|---------|------|
|
|
114
|
+
| U1 | {title} | {backend/frontend/test/...} | {files} | — |
|
|
115
|
+
| U2 | {title} | {type} | {files} | — |
|
|
116
|
+
| U3 | {title} | {type} | {files} | U1, U2 |
|
|
117
|
+
|
|
118
|
+
**执行策略**：{parallel / sequential / single}
|
|
119
|
+
- 第一批（并行）：U1 {title} ｜ U2 {title}
|
|
120
|
+
- 第二批（等待第一批）：U3 {title}
|
|
121
|
+
（若 single：单一实施单元，主 agent 直接执行）
|
|
122
|
+
|
|
123
|
+
### 测试策略
|
|
124
|
+
|
|
125
|
+
| 测试点 | 级别 | 归属单元 | 方式 | 验证命令 |
|
|
126
|
+
|--------|------|---------|------|---------|
|
|
127
|
+
| {描述} | 必测 | U1 | 单测 | `npm test -- --filter=xxx` |
|
|
128
|
+
| {描述} | 应测 | U2 | 快照 | `npm test -- --snapshot` |
|
|
129
|
+
|
|
130
|
+
- **人工验收**：{待填写 — 用户需要检查的关键行为}
|
|
131
|
+
- **无法验证项**：{待填写 — 无 / 说明缺失环境、数据或权限}
|
|
132
|
+
|
|
133
|
+
### 风险与注意事项
|
|
134
|
+
- {风险 1}
|
|
135
|
+
- {风险 2}
|
|
136
|
+
````
|
|
137
|
+
|
|
138
|
+
> **编码规则**：修改已有文件必须保持原始编码；新文件声明项目编码并附证据；证据冲突或
|
|
139
|
+
> 未知时标记"需用户确认"。用户可在确认前覆盖任何编码单元格。
|
|
140
|
+
|
|
141
|
+
**条件展开章节**（仅在满足条件时添加，否则完全不出现）：
|
|
142
|
+
|
|
143
|
+
- `### 背景数据应用` — 命中项目知识资产（ABSTRACT.md、BUSINESS.md、TECHNICAL.md、RULES.md）
|
|
144
|
+
且其内容影响本次方案时展开。含架构参考、业务记忆、技术记忆、记忆冲突、规范约束。
|
|
145
|
+
- `### 核心改动明细` — 多模块且改动范围表不足以表达当前逻辑和目标逻辑时展开。
|
|
146
|
+
逐文件列出"当前逻辑 → 准备怎么改"。
|
|
147
|
+
- `### 前端实现映射` — 涉及前端页面、组件、交互时展开。含页面/模块映射、组件映射、
|
|
148
|
+
数据来源、Mock 使用计划。
|
|
149
|
+
|
|
150
|
+
**禁止输出**：
|
|
151
|
+
- 仅复述需求、几乎不引用代码现状的空泛方案。
|
|
152
|
+
- 只列"已加载哪些信息"但不给出具体可实施改法。
|
|
153
|
+
- 为了凑格式输出与本次任务无关的条件章节。
|
|
59
154
|
|
|
60
155
|
## Implementation units → execution.jsonl
|
|
61
156
|
|
|
@@ -95,19 +190,37 @@ owning unit and the verify command.
|
|
|
95
190
|
|
|
96
191
|
**3. No-test reasons** — one line each; the user can overturn any verdict at confirmation.
|
|
97
192
|
|
|
193
|
+
**4. Human acceptance** — items requiring manual verification by the user.
|
|
194
|
+
|
|
195
|
+
**5. Cannot-verify items** — items that cannot be verified in the current environment,
|
|
196
|
+
with reason (missing infra, data, credentials, or API contract).
|
|
197
|
+
|
|
98
198
|
Write the confirmed strategy to `.easy-coding/tasks/{task-id}/test-strategy.md` (the
|
|
99
199
|
VERIFICATION baseline).
|
|
100
200
|
|
|
101
|
-
## Self-check
|
|
201
|
+
## Self-check gates (reject your own draft if any fails)
|
|
202
|
+
|
|
203
|
+
- 每个"现状"断言是否引用了真实文件/类/行号？
|
|
204
|
+
- 是否有具体的修改方案，而非仅罗列"已加载的文件"？
|
|
205
|
+
- 不适用的条件章节是否已完全省略（而非留空）？
|
|
206
|
+
- 实施拆解的单元、依赖、策略是否与改动范围表一致？
|
|
207
|
+
- 改动范围表中每行是否填写了文件编码及证据？
|
|
208
|
+
- 所有 `{待填写}` 占位符是否已替换为实际内容？
|
|
209
|
+
|
|
210
|
+
## Revision handling
|
|
211
|
+
|
|
212
|
+
On user revision request at WAITING_CONFIRM, do NOT reply with only a change summary.
|
|
213
|
+
Re-output the COMPLETE revised dev-spec.md:
|
|
102
214
|
|
|
103
|
-
|
|
104
|
-
|
|
105
|
-
-
|
|
106
|
-
|
|
215
|
+
1. Prepend a `### 修订摘要` listing each user request and its impact on the plan. If the
|
|
216
|
+
user changed a file encoding, explain the per-file adjustment.
|
|
217
|
+
2. Re-output the full plan following the template above (核心必填 + applicable conditional
|
|
218
|
+
sections), incorporating all revisions.
|
|
219
|
+
3. Overwrite the `plan` record in execution.jsonl with the new strategy.
|
|
220
|
+
4. Update test-strategy.md if test scope changed.
|
|
221
|
+
5. Re-enter WAITING_CONFIRM and wait for explicit user confirmation.
|
|
107
222
|
|
|
108
223
|
## End state
|
|
109
224
|
|
|
110
225
|
Present the full plan, then set stage to WAITING_CONFIRM and hand control back to
|
|
111
|
-
ec-workflow.
|
|
112
|
-
and re-enter WAITING_CONFIRM; overwrite the `plan` record in execution.jsonl with the new
|
|
113
|
-
strategy. Never start implementing from this skill.
|
|
226
|
+
ec-workflow. Never start implementing from this skill.
|