✨ feat(vscode): 七份提示词统一走 Handlebars，头脑风暴三档合一
- 模板引擎换成 Handlebars（noEscape，提示词是纯文本不能被转义），单花括号写法彻底退场
- brainstorm-continue / brainstorm-continue-prototype 两份并进 brainstorm.md，
用 {{#if issueNumber}} 分新建 / 续聊，续聊里用 {{#if prototypeFile}} 嵌原型段落，
设置面板对应的两个 textarea 一并删掉
- 模板上下文 = 工单 state JSON 全量字段 + issueNumber / userRequest / nonce /
planFile / prNumber / prRef，以后模板想用新字段不用改扩展代码
- 各会话入口共用一条 state 读取路径，读失败只记 warn 按空状态继续，不拦开会话
- 升级后首次启动把存量自定义提示词迁到双花括号并合并成一份，改写前把
settings.json 备份成 settings.json.bak-<时间戳>，迁移动作全写日志
- 装 handlebars 时给 vsce 传递依赖的老 semver 加 trustPolicyExclude 豁免，
否则 no-downgrade 策略卡住整个装包
Claude-Session: https://claude.ai/code/session_01Kgmb1LvrPmFX3NoUDB4zZC
This commit is contained in:
cruldra committed
1 parent
efeac8c978
commit
7bac5c8b03
28 files changed
+853
-424
No files matched your search
@@ -1,8 +0,0 @@
|
||||
工单已有原型插件 {prototypeFile}，先读它了解已经定下来的界面和交互，在此基础上只对齐还不明确的地方，不要从零重画。
|
||||
|
||||
**原型要改时只能交给本工单已经开着的原型会话**：先 ListAgents 找到它，再 SendMessage 说清要改哪块、为什么改、改完怎么算对，然后等它回报。
|
||||
|
||||
- 原型会话终端名：issue-{issueNumber}-原型
|
||||
- 原型会话 id：{prototypeSessionId}（它 transcript 的文件名就是这个 id）
|
||||
|
||||
严禁用下面这些方式代替：Agent 工具派子代理 / fork 分身 / 后台代理，自己动插件代码，翻 git log 猜会话。ListAgents 里没有这个原型会话就**停下告诉我**去工单面板的「原型会话id」行点 ▶ 起一个，不要自作主张换别的做法。
|
||||
@@ -1,32 +0,0 @@
|
||||
/ecc:grilling 讨论下 {issueNumber} 号工单
|
||||
|
||||
用 tea 命令找工单，用 `ecc:grilling` 技能讨论细节，用表单形式和我交互，每次只问一个问题（成组的问题也拆成一次一问）。
|
||||
|
||||
{prototypeRef}
|
||||
|
||||
## 产物与顺序
|
||||
|
||||
1. 需求讨论到共识后，用 Skill 工具调 `ecc:spec` 写设计文档到 `.claude/specs/<stem>.md`，让我确认。
|
||||
2. 设计文档我确认后，用 Skill 工具调 `ecc:plan`，参数是设计文档路径，产出 `.claude/plans/<stem>.md`；计划出来后停下等我确认。
|
||||
3. `<stem>` 取工单标题的英文短横线名，设计文档与计划共用同一个 stem；文件名里不要带 `spec` / `plan` 字样，目录已经表达了。工单已有 marker 就沿用其中的 stem。
|
||||
|
||||
## marker 维护（本会话有效）
|
||||
|
||||
设计文档 / 计划文件**一律在当前主 worktree（main 分支）创建并提交**（`ecc:spec` 默认不提交，这里要显式提交），每次只提交这两个文件（提交信息形如 `📝 docs: #<工单号> 设计文档` / `📝 docs: #<工单号> 实施计划`），不要为此新建或切换分支。创建后追加对应 marker：
|
||||
|
||||
```
|
||||
opencli spx issue marker --issue <工单号> --type spec --value .claude/specs/<stem>.md
|
||||
opencli spx issue marker --issue <工单号> --type plan --value .claude/plans/<stem>.md
|
||||
```
|
||||
|
||||
## 严禁擅自继续
|
||||
|
||||
如果你创建/更新了设计文档或计划文件并 marker 已同步，**立即停下**汇报；不要进入实施流程。
|
||||
|
||||
特别地：
|
||||
|
||||
- 不要创建分支
|
||||
- 不要切换分支，包括 `git checkout` / `git switch`
|
||||
- 除设计文档 / 计划文件外不要修改任何文件
|
||||
- 不要创建 PR
|
||||
- 不要调用 gitea 其他写操作（除上面的 marker 同步）
|
||||
@@ -1,4 +1,49 @@
|
||||
接下来我要实现下面这样的功能: {userRequest}
|
||||
{{#if issueNumber}}
|
||||
/ecc:grilling 讨论下 {{issueNumber}} 号工单
|
||||
|
||||
用 tea 命令找工单，用 `ecc:grilling` 技能讨论细节，用表单形式和我交互，每次只问一个问题（成组的问题也拆成一次一问）。
|
||||
|
||||
{{#if prototypeFile}}
|
||||
工单已有原型插件 {{prototypeFile}}，先读它了解已经定下来的界面和交互，在此基础上只对齐还不明确的地方，不要从零重画。
|
||||
|
||||
**原型要改时只能交给本工单已经开着的原型会话**：先 ListAgents 找到它，再 SendMessage 说清要改哪块、为什么改、改完怎么算对，然后等它回报。
|
||||
|
||||
- 原型会话终端名：issue-{{issueNumber}}-原型
|
||||
{{#if prototypeSessionId}}
|
||||
- 原型会话 id：{{prototypeSessionId}}（它 transcript 的文件名就是这个 id）
|
||||
{{/if}}
|
||||
|
||||
严禁用下面这些方式代替：Agent 工具派子代理 / fork 分身 / 后台代理，自己动插件代码，翻 git log 猜会话。ListAgents 里没有这个原型会话就**停下告诉我**去工单面板的「原型会话id」行点 ▶ 起一个，不要自作主张换别的做法。
|
||||
|
||||
{{/if}}
|
||||
## 产物与顺序
|
||||
|
||||
1. 需求讨论到共识后，用 Skill 工具调 `ecc:spec` 写设计文档到 `.claude/specs/<stem>.md`，让我确认。
|
||||
2. 设计文档我确认后，用 Skill 工具调 `ecc:plan`，参数是设计文档路径，产出 `.claude/plans/<stem>.md`；计划出来后停下等我确认。
|
||||
3. `<stem>` 取工单标题的英文短横线名，设计文档与计划共用同一个 stem；文件名里不要带 `spec` / `plan` 字样，目录已经表达了。工单已有 marker 就沿用其中的 stem。
|
||||
|
||||
## marker 维护（本会话有效）
|
||||
|
||||
设计文档 / 计划文件**一律在当前主 worktree（main 分支）创建并提交**（`ecc:spec` 默认不提交，这里要显式提交），每次只提交这两个文件（提交信息形如 `📝 docs: #<工单号> 设计文档` / `📝 docs: #<工单号> 实施计划`），不要为此新建或切换分支。创建后追加对应 marker：
|
||||
|
||||
```
|
||||
opencli spx issue marker --issue <工单号> --type spec --value .claude/specs/<stem>.md
|
||||
opencli spx issue marker --issue <工单号> --type plan --value .claude/plans/<stem>.md
|
||||
```
|
||||
|
||||
## 严禁擅自继续
|
||||
|
||||
如果你创建/更新了设计文档或计划文件并 marker 已同步，**立即停下**汇报；不要进入实施流程。
|
||||
|
||||
特别地：
|
||||
|
||||
- 不要创建分支
|
||||
- 不要切换分支，包括 `git checkout` / `git switch`
|
||||
- 除设计文档 / 计划文件外不要修改任何文件
|
||||
- 不要创建 PR
|
||||
- 不要调用 gitea 其他写操作（除上面的 marker 同步）
|
||||
{{else}}
|
||||
接下来我要实现下面这样的功能: {{userRequest}}
|
||||
|
||||
你的任务：用 spx CLI 创建一个 Gitea 工单。spx 用法参考 `using-spx-cli` skill。
|
||||
|
||||
@@ -12,7 +57,7 @@
|
||||
无论哪种情况，body **末尾必须**包含这一行（且仅此一行；不要预先写其他 `<!-- spx:* -->` marker）：
|
||||
|
||||
```
|
||||
<!-- spx:nonce={nonce} -->
|
||||
<!-- spx:nonce={{nonce}} -->
|
||||
```
|
||||
|
||||
## 创建
|
||||
@@ -52,3 +97,4 @@ spx 自动找到对应行替换或追加，保留所有其他 marker。**不要
|
||||
- 不要创建分支
|
||||
- 不要切换分支
|
||||
- 除设计文档 / 计划文件外不要改动或提交任何文件
|
||||
{{/if}}
|
||||
@@ -1,5 +1,5 @@
|
||||
/ecc:tdd @{planFile}
|
||||
/ecc:tdd @{{planFile}}
|
||||
|
||||
按计划实施 {issueNumber} 号工单：具体编码派子代理去做，全程保持测试绿灯。计划里的验证命令只当意图，落地时用仓库自己的 test / lint / typecheck 命令。提 PR 前先自审并修掉严重问题：把 `git diff origin/main...HEAD` 交给 `ecc:code-reviewer` 子代理（`/ecc:code-review` 的本地模式只看未提交改动，提交过就看不到了）。发起 PR 时务必在 PR body 中包含 "Closes #{issueNumber}"。
|
||||
按计划实施 {{issueNumber}} 号工单：具体编码派子代理去做，全程保持测试绿灯。计划里的验证命令只当意图，落地时用仓库自己的 test / lint / typecheck 命令。提 PR 前先自审并修掉严重问题：把 `git diff origin/main...HEAD` 交给 `ecc:code-reviewer` 子代理（`/ecc:code-review` 的本地模式只看未提交改动，提交过就看不到了）。发起 PR 时务必在 PR body 中包含 "Closes #{{issueNumber}}"。
|
||||
|
||||
**严禁合并 PR**：你的职责只到发起 PR 为止，后续审查反馈到了请继续修复并 push，永远不要执行 `tea pulls merge` 或任何合并操作。
|
||||
@@ -1,3 +1,3 @@
|
||||
/ecc:figma-plugin-prototyping 给 {issueNumber} 号工单画原型：先读工单正文锁定要画的界面和状态，再写本地 Figma 插件把画板和点击流做出来。画完汇报插件路径和怎么导入，不要改业务代码。
|
||||
/ecc:figma-plugin-prototyping 给 {{issueNumber}} 号工单画原型：先读工单正文锁定要画的界面和状态，再写本地 Figma 插件把画板和点击流做出来。画完汇报插件路径和怎么导入，不要改业务代码。
|
||||
|
||||
画完用 `opencli spx issue marker --issue {issueNumber} --type prototype --value <manifest.json 的仓库相对路径>` 把原型插件挂到工单上，再汇报。
|
||||
画完用 `opencli spx issue marker --issue {{issueNumber}} --type prototype --value <manifest.json 的仓库相对路径>` 把原型插件挂到工单上，再汇报。
|
||||
@@ -1,6 +1,6 @@
|
||||
审查这个仓库的 PR #{prNumber}。
|
||||
审查这个仓库的 PR #{{prNumber}}。
|
||||
|
||||
用 `tea pulls {prNumber}` 看 PR 元信息（标题/描述/分支）。看代码差异用 git（当前目录就是 PR 分支的 worktree）：先 `git fetch origin main`，再 `git diff origin/main...HEAD`（概览可加 --stat）。注意 tea 没有 `diff` 子命令，不要尝试 `tea pulls diff`。
|
||||
用 `tea pulls {{prNumber}}` 看 PR 元信息（标题/描述/分支）。看代码差异用 git（当前目录就是 PR 分支的 worktree）：先 `git fetch origin main`，再 `git diff origin/main...HEAD`（概览可加 --stat）。注意 tea 没有 `diff` 子命令，不要尝试 `tea pulls diff`。
|
||||
|
||||
## 审查方式
|
||||
|
||||
@@ -14,10 +14,10 @@ ECC 的 `/ecc:review-pr` 和 `/ecc:code-review` 的 PR 模式都走 `gh`，对 G
|
||||
|
||||
## 提交审查意见
|
||||
|
||||
把审查意见（markdown 格式）写到 `/tmp/review-{prNumber}.md`，调 spx：
|
||||
把审查意见（markdown 格式）写到 `/tmp/review-{{prNumber}}.md`，调 spx：
|
||||
|
||||
```
|
||||
opencli spx pr review-comment --pr {prNumber} --body-file /tmp/review-{prNumber}.md
|
||||
opencli spx pr review-comment --pr {{prNumber}} --body-file /tmp/review-{{prNumber}}.md
|
||||
```
|
||||
|
||||
审查结束以后，删除所有审查过程中创建的临时 worktree（`git worktree remove --force <路径>`），你当前所在的 worktree 除外。
|
||||
|
||||
@@ -1,3 +1,3 @@
|
||||
/pr-acceptance-testing 验收 {issueNumber} 号工单（{prRef}）。
|
||||
/pr-acceptance-testing 验收 {{issueNumber}} 号工单（{{prRef}}）。
|
||||
|
||||
验收目标以工单正文为准，不要再问验收哪个。测出问题就停下报告，不要顺手改代码。
|
||||
Reference in new issue
Block a user