11

tui/internal/cc/prompts/brainstorm-continue.md

@@ -0,0 +1,28 @@
+/superpowers:brainstorming 讨论下 {issueNumber} 号工单
+
+用tea命令找工单
+
+## 后续 marker 维护（本会话有效）
+
+spec/plan 文件**一律在当前主 worktree（main 分支）创建**，不要为此新建或切换分支。创建后追加对应 marker:
+
+```
+opencli spx issue marker --issue <工单号> --type spec --value <spec 路径>
+opencli spx issue marker --issue <工单号> --type plan --value <plan 路径>
+```
+
+## 严禁擅自继续
+
+如果你创建/更新了 spec/plan 文件并 marker 已同步，**立即停下**汇报；不要进入实施流程。
+
+特别地：
+
+- 不要创建分支
+- 不要切换分支，包括 `git checkout` / `git switch`
+- 不要修改当前主 worktree 所在分支
+- spec/plan 一律在 main 分支（当前主 worktree）创建
+- 不要修改任何代码文件
+- 不要创建 PR
+- 不要调用 gitea 其他写操作（除上面的 marker 同步）
+
+只讨论需求与 spec/plan，必要时用 spx issue marker 更新 marker。

tui/internal/cc/prompts/brainstorm.md

@@ -0,0 +1,48 @@
+接下来我要实现下面这样的功能: {userRequest}
+
+你的任务：用 spx CLI 创建一个 Gitea 工单。spx 用法参考 `using-spx-cli` skill。
+
+## 工单格式
+
+先检查仓库的 `.gitea/ISSUE_TEMPLATE/` 目录：
+
+- 有模板（`.md` 或 `.yaml`）→ 严格按模板填 body：标题前缀、章节标题、必填字段都写齐
+- 没有模板 → 用普通 markdown 自由写
+
+无论哪种情况，body **末尾必须**包含这一行（且仅此一行；不要预先写其他 `<!-- spx:* -->` marker）：
+
+```
+<!-- spx:nonce={nonce} -->
+```
+
+## 创建
+
+把 body 写到 `/tmp/issue-body.md`，调 spx：
+
+```
+opencli spx issue create --title "<标题>" --body-file /tmp/issue-body.md
+```
+
+spx 返回工单号 + html_url。记下工单号，后续命令用。
+
+## 后续 marker 维护（本会话有效）
+
+**只有**当你真正创建了 spec 或 plan 文件后才追加对应 marker。路径形如 `docs/superpowers/specs/<slug>/spec.md` 或 `docs/superpowers/plans/<slug>/plan.md`。spec/plan 文件**一律在当前主 worktree（main 分支）创建**，不要为此新建或切换分支：
+
+```
+opencli spx issue marker --issue <工单号> --type spec --value <spec 路径>
+opencli spx issue marker --issue <工单号> --type plan --value <plan 路径>
+```
+
+spx 自动找到对应行替换或追加，保留所有其他 marker。**不要自己手写 `<!-- spx:* -->` 行**。
+
+## 严禁擅自继续
+
+成功创建工单后**立即停下**汇报：输出工单号 + html_url 即可。
+
+特别地：
+
+- 不要创建分支
+- 不要切换分支
+- 不要修改当前主 worktree 所在分支
+- spec/plan 一律在 main 分支（当前主 worktree）创建

tui/internal/cc/prompts/implement-plan.md

@@ -0,0 +1,13 @@
+/goal 使用子代理全程绿灯实施 @{planFile}，发起 PR 时务必在 PR body 中包含 "Closes #{issueNumber}"。
+
+**严禁合并 PR**：你的职责只到发起 PR 为止，后续审查反馈到了请继续修复并 push，永远不要执行 `tea pulls merge` 或任何合并操作。
+
+## 数据库迁移（alembic）
+
+多个 feature worktree 共用同一台 dev DB（`192.168.1.4:5433`）。任何 worktree 直接在共享库上跑迁移，都会让别的分支 `alembic upgrade` 崩（DB 里记着的 revision 在对方代码里不存在）。所以本会话：
+
+- 只用 `uv run alembic revision --autogenerate -m "..."` 生成迁移文件，**绝不手写 revision 文件**。
+- 生成后立即 `git add` 提交迁移文件，纳入 PR。
+- **绝不**对共享 dev DB（`192.168.1.4:5433`）或 prod 执行 `alembic upgrade` / `downgrade` 等任何改库命令。
+- 需要运行时验证迁移，就起一个一次性独立库（本地 docker postgres 或唯一命名的 scratch 库），在它上面 upgrade，验证完即丢弃，不要留痕。
+- 共享 dev DB 与 prod 的迁移合并后由用户统一执行，时机由用户决定。

tui/internal/cc/prompts/review.md

@@ -0,0 +1,18 @@
+/review 审查这个仓库的 PR #{prNumber}。
+
+用 `tea pulls {prNumber}` 看 PR 元信息（标题/描述/分支）。看代码差异用 git（当前目录就是 PR 分支的 worktree）：先 `git fetch origin main`，再 `git diff origin/main...HEAD`（概览可加 --stat）。注意 tea 没有 `diff` 子命令，不要尝试 `tea pulls diff`。
+
+## 提交审查意见
+
+把审查意见（markdown 格式）写到 `/tmp/review-{prNumber}.md`，调 spx：
+
+```
+opencli spx pr review-comment --pr {prNumber} --body-file /tmp/review-{prNumber}.md
+
+## 严禁
+
+- 不要在审查意见里建议"合并 PR"或"merge"
+- 不要执行 `tea pulls merge` 或任何合并命令
+- 不要 push 到 main / dev 分支
+
+合并权完全在用户手上,你的工作只是指出问题或确认通过。