@fitlab-ai/agent-infra 0.8.5 → 0.9.1

package/templates/.agents/skills/plan-task/SKILL.zh-CN.md

@@ -3,6 +3,7 @@ name: plan-task
 description: >
   为任务设计技术方案和实施计划。
   当需求已明确、需要在编码前形成技术方案时使用。
+  仅当对话包含可解析的任务引用时才可自动调用本技能。
 ---
 
 # 设计技术方案
@@ -22,26 +23,24 @@ description: >
 运行以下命令，并把原文粘贴到回复正文和本轮产物的 `## 状态核对` 段：
 
 ```bash
-git status -s
-ls -la .agents/workspace/active/{task-id}/
-tail .agents/workspace/active/{task-id}/task.md
+agent-infra-internal task-snapshot {task-id} --format text
 ```
 
 状态核对完成前，禁止任何关于外部状态的断言（例如“代码没变”“测试已通过”“没有其他引用”），包括思考阶段。本门禁只提供结构下限；逐条证据配对和真实性仍需按报告模板与审查要求核对。
 
-## 任务入参短号别名
+## 任务上下文解析
 
-> 如果 `{task-id}` 入参匹配 `^[#]?[0-9]+$`（裸数字或带 `#` 前缀），先读取 `.agents/rules/task-short-id.md` 的「SKILL 入参解析」段执行解析；后续命令视 `{task-id}` 为解析后的全长 `TASK-YYYYMMDD-HHMMSS` 形式。
+> 入口允许省略 task ref，也接受旧位置 task ref 或 `--task <ref>` / `-t <ref>`。先从完整参数中分离 task scope 并原样保留其他业务操作数，再调用 `agent-infra-internal task-context resolve {task-scope}`；`{task-scope}` 为空、位置 ref 或 task flag 之一。只读取结构化结果的 `taskId`，后续把 `{task-id}` 绑定为该完整 `TASK-YYYYMMDD-HHMMSS`。解析失败时透传非零退出码，不自行扫描任务。
 
-## 步骤开始：写入 started 标记
+> 解析任务引用，并确认任务位于本技能支持的状态或目录且存在 `task.md`；无法定位时按未找到任务处理并停止。
 
-确认前置条件后、本轮第一个产出动作之前，向 task.md `## 活动日志` 追加一条 started 标记（与本轮 done 条目同基名 + ` [started]` 后缀，note 用 `started`）：
+## 步骤开始：声明 started 事件
 
-```
-- {YYYY-MM-DD HH:mm:ss±HH:MM} — **Plan Task (Round {N}) [started]** by {agent} — started
-```
+确认前置条件和轮次后、本轮第一个产出动作之前执行：
 
-`ai task log` 会把它与步骤完成时（步骤 7）写入的 done 条目配对成一行（进行中 → 已完成）。格式与配对规则见 `.agents/rules/task-management.md` 的「Activity Log started / done 双标记约定」。
+```bash
+agent-infra-internal task-event {task-id} plan.started --agent {agent}
+```
 
 ## 执行步骤
 ### 1. 验证前置条件
@@ -54,22 +53,13 @@ tail .agents/workspace/active/{task-id}/task.md
 
 如果任一文件缺失，提示用户先完成前置步骤。
 
-### 2. 确定方案轮次
-
-扫描 `.agents/workspace/active/{task-id}/` 目录中的方案产物文件：
-- 如果不存在 `plan.md` 且不存在 `plan-r*.md` → 本轮为第 1 轮，产出 `plan.md`
-- 如果存在 `plan.md` 且不存在 `plan-r*.md` → 本轮为第 2 轮，产出 `plan-r2.md`
-- 如果存在 `plan-r{N}.md` → 本轮为第 N+1 轮，产出 `plan-r{N+1}.md`
+### 2. 解析方案上下文
 
-记录：
-- `{plan-round}`：本轮方案轮次
-- `{plan-artifact}`：本轮方案产物文件名
+运行 `agent-infra-internal task-artifact {task-id} inspect --family plan`。仅当结果为 `ready` 时继续；从 `inputs` 取得最新 `{analysis-artifact}`，从 `next.round` / `next.name` 取得 `{plan-round}` / `{plan-artifact}`。不得自行扫描轮次或拼装文件名。随后执行 started 事件并复核返回身份。
 
 ### 3. 阅读需求分析
 
-扫描任务目录中的分析产物文件（`analysis.md`、`analysis-r{N}.md`）：
-- 如果存在 `analysis-r{N}.md`，读取最高 N 的文件
-- 否则读取 `analysis.md`
+读取步骤 2 核心返回的最新 `{analysis-artifact}`，
 以理解：
 - 需求及其背景
 - 相关文件和代码结构
@@ -77,7 +67,7 @@ tail .agents/workspace/active/{task-id}/task.md
 - 已识别的技术风险
 - 工作量和复杂度评估
 
-**Round ≥ 2：响应上一轮审查（仅当存在审查产物时）**：若任务目录存在 `review-plan.md` / `review-plan-r{N}.md`，读取最高轮次的审查报告；在本轮方案产物中新增 `## 对上一轮审查的响应` 段，对每条发现先 Read/Grep 核实，再按 `.agents/rules/review-handshake.md` 的四态（`accepted` / `adjusted` / `refuted` / `cannot-judge`）处置——每态都要附相称证据，不默认顺从；并把处置回写 task.md `## 审查分歧账本` 对应行（stage=plan，round +1）。未决分歧写入 `## 未决问题`。Round 1 无审查，跳过本段。
+**Round ≥ 2：响应上一轮审查（仅当存在审查产物时）**：若任务目录存在 `review-plan.md` / `review-plan-r{N}.md`，读取最高轮次的审查报告；在本轮方案产物中新增 `## 对上一轮审查的响应` 段，对每条发现先 Read/Grep 核实，再按 `.agents/rules/review-handshake.md` 的四态（`accepted` / `adjusted` / `refuted` / `cannot-judge`）处置——每态都要附相称证据，不默认顺从；随后逐条调用 `agent-infra-internal task-ledger {task-id} finding-respond --id {ledger-id} --round {plan-round} --status {四态} --evidence {相称证据}`。未决分歧写入 `## 未决问题`。Round 1 无审查，跳过本段。
 
 ### 4. 理解问题
 
@@ -98,7 +88,7 @@ tail .agents/workspace/active/{task-id}/task.md
 - [ ] 定义验证策略（测试、手动检查）
 - [ ] 评估方案的影响和风险
 
-遇到本轮新增的关键设计决策时，按 `.agents/rules/no-mid-flow-questions.md` 判据，把详情块（背景/选项/影响/推荐）写入方案产物的 `## 人工裁决待办` 段 `### HD-N：<标题> [needs-human-decision]`（`HD-N` 全局唯一，规则见 `.agents/rules/review-handshake.md`），并回写 `HD-` 账本行（evidence 指向 `{plan-artifact}#HD-N`）；普通未决问题仍写 `## 未决问题`。
+遇到本轮新增的关键设计决策时，按 `.agents/rules/no-mid-flow-questions.md` 判据，先调用 `agent-infra-internal task-ledger {task-id} decision-next-id` 取得 `HD-N`，按 `.agents/rules/human-decision-context.md` 写入方案产物的 `## 人工裁决待办` 段 `### HD-N：<标题> [needs-human-decision]`，再调用 `decision-upsert --id {HD-N} --stage plan --artifact {plan-artifact}`；普通未决问题仍写 `## 未决问题`。
 
 **设计原则**：
 1. **架构合理性**：选择结构正确的方案，改动大小不是首要依据。不要为了减少 diff 而在不合理的结构上叠加
@@ -113,42 +103,25 @@ tail .agents/workspace/active/{task-id}/task.md
 
 ### 7. 更新任务状态
 
-获取当前时间：
-
-```bash
-date "+%Y-%m-%d %H:%M:%S%z" | sed 's/\([+-][0-9][0-9]\)\([0-9][0-9]\)$/\1:\2/'
-```
-
 更新 `.agents/workspace/active/{task-id}/task.md`：
-- `current_step`：technical-design
-- `assigned_to`：{当前 AI 代理}
-- `updated_at`：{当前时间}
-- `agent_infra_version`：按 `.agents/rules/version-stamp.md` 取值
-- 记录本轮方案产物：`{plan-artifact}`（Round `{plan-round}`）
-- 如任务模板包含 `## 设计` 段落，更新为指向 `{plan-artifact}` 的链接
-- 在工作流进度中标记 technical-design 为已完成，并注明实际轮次（如果任务模板支持）
+- 仅更新工作量、审查响应等本技能拥有的业务内容；产物链接、阶段与完成日志由 completed 事件统一登记
 - 在追加工作流 Activity Log 条目之前，基于技术方案（实施步骤数、涉及文件、测试矩阵范围、集成面）重估 `effort`。若重估值与 `task.md` 当前值不一致：
   - 用新值覆盖 frontmatter 的 `effort` 字段
   - 在本轮方案产物 `{plan-artifact}` 中追加 `## 工作量重估` 段，记录一条：`effort {old} → {new} (rationale: {基于本轮方案的简短依据})`
   若重估值与当前值一致，跳过：不写入 `## 工作量重估` 段。后续 Flow A 同步会读取可能更新过的 frontmatter，并自动把新值同步到 Issue。
-- **追加**到 `## Activity Log`（不要覆盖之前的记录）：
-  ```
-  - {YYYY-MM-DD HH:mm:ss±HH:MM} — **Plan Task (Round {N})** by {agent} — Plan completed, awaiting human review → {artifact-filename}
-  ```
+- 完成业务内容更新后执行 `agent-infra-internal task-event {task-id} plan.completed --agent {agent} --artifact {plan-artifact}`，由核心原子登记链接、阶段、代理、时间、版本和 Activity Log。
 
 如果 task.md 中存在有效的 `issue_number`，执行以下同步操作（任一失败则跳过并继续）：
-- 执行前先读取 `.agents/rules/issue-sync.md`，完成 upstream 仓库检测和权限检测
-- 按 issue-sync.md 设置 `status: pending-design-work`
-- 创建或更新 `.agents/rules/issue-sync.md` 中定义的 task 评论标记（按 issue-sync.md 的 task.md 评论同步规则）
-- 发布 `{plan-artifact}` 评论
-- 读取 `.agents/rules/issue-fields.md`，按流程 A 把 `task.md` 中所有非空的 Issue 字段（`priority`/`effort`/`start_date`/`target_date`）同步到 Issue（幂等；`has_push=false` 或取数/写入失败时跳过，不阻断）
+- 调用 `agent-infra-internal platform-issue sync {task-id} --agent {agent} --status pending-design-work --fields`
+- 调用 `agent-infra-internal platform-comment sync {task-id} --kind task --agent {agent}`
+- 调用 `agent-infra-internal platform-comment sync {task-id} --kind artifact --artifact {plan-artifact} --agent {agent}`
 
 ### 8. 完成校验
 
 运行完成校验，确认任务产物和同步状态符合规范：
 
 ```bash
-node .agents/scripts/validate-artifact.js gate plan-task .agents/workspace/active/{task-id} {plan-artifact} --format text
+agent-infra-internal task-verify {task-id} plan.completed --artifact {plan-artifact} --format text
 ```
 
 处理结果：
@@ -162,7 +135,7 @@ node .agents/scripts/validate-artifact.js gate plan-task .agents/workspace/activ
 
 > 仅在校验通过后执行本步骤。
 
-> **重要**：以下「下一步」中列出的所有 TUI 命令格式必须完整输出，不要只展示当前 AI 代理对应的格式。如果 `.agents/.airc.json` 中配置了自定义 TUI（`customTUIs`），读取每个工具的 `name` 和 `invoke`，按同样格式补充对应命令行（`${skillName}` 替换为技能名，`${projectName}` 替换为项目名）。 渲染最终输出前，先读取 `.agents/rules/next-step-output.md` 并落实其两类规则：(1) 「下一步」命令把 `{task-ref}` 渲染为短号 `#NN`（未分配/已释放时回退完整 TASK-id）；(2) 在面向用户输出的绝对最后一行追加 `Completed at` 收尾行（成功、错误、早退等任何面向用户输出都适用，不限于校验通过的成功态）。
+> **重要**：以下「下一步」中列出的所有 TUI 命令格式必须完整输出，不要只展示当前 AI 代理对应的格式。如果 `.agents/.airc.json` 中配置了自定义 TUI（`customTUIs`），读取每个工具的 `name` 和 `invoke`，按同样格式补充对应命令行（`${skillName}` 替换为技能名，`${projectName}` 替换为项目名）。 渲染最终输出前，先读取 `.agents/rules/next-step-output.md` 并落实其两类规则：(1) 「下一步」命令把 `{task-ref}` 渲染为短号 `NN`（未分配/已释放时回退完整 TASK-id）；(2) 在面向用户输出的绝对最后一行追加 `Completed at` 收尾行（成功、错误、早退等任何面向用户输出都适用，不限于校验通过的成功态）。
 
 输出格式：
 ```

package/templates/.agents/skills/plan-task/config/verify.en.json

@@ -27,14 +27,12 @@
         "Verification Strategy",
         "State Check"
       ],
-      "freshness_minutes": 30,
       "required_patterns": [
         "^\\$ "
       ]
     },
     "activity-log": {
-      "expected_action_pattern": "(Plan Task|Technical Design) \\(Round \\d+\\)",
-      "freshness_minutes": 30
+      "expected_action_pattern": "(Plan Task|Technical Design) \\(Round \\d+\\)"
     },
     "review-ledger": {
       "stage_scope": ["analysis"]

package/templates/.agents/skills/plan-task/config/verify.zh-CN.json

@@ -27,14 +27,12 @@
         "验证策略",
         "状态核对"
       ],
-      "freshness_minutes": 30,
       "required_patterns": [
         "^\\$ "
       ]
     },
     "activity-log": {
-      "expected_action_pattern": "(Plan Task|Technical Design) \\(Round \\d+\\)",
-      "freshness_minutes": 30
+      "expected_action_pattern": "(Plan Task|Technical Design) \\(Round \\d+\\)"
     },
     "review-ledger": {
       "stage_scope": ["analysis"]

package/templates/.agents/skills/post-release/SKILL.en.md

@@ -1,98 +1,28 @@
 ---
 name: post-release
 description: >
-  Run post-release follow-up tasks.
-  Use when a release has shipped and follow-up housekeeping is needed.
+  Run post-release processing.
+  Use after a version has been published and needs finalization.
 ---
 
-# Post-release Tasks
+# Post-release
 
-Run the standard follow-up workflow after a release tag has been pushed.
-
-## Execution Flow
-
-### 1. Detect the Latest Released Version
-
-```bash
-git tag --sort=-v:refname | grep -E '^v[0-9]+\.[0-9]+\.[0-9]+$' | head -n 1
-```
-
-- Detect the latest `vX.Y.Z` tag, then strip the `v` prefix when you need the version number in later steps
-- If no tag is found, error: "No released version tag found. Please create and push a release tag first."
-
-### 2. Verify Clean Workspace
-
-```bash
-git status --short
-```
-
-- If there are uncommitted changes, error: "Workspace has uncommitted changes. Please commit or stash first."
-
-### 3. Prepare the Next Development Version
-
-<!-- TODO: Replace this step with your project's version bump command -->
-
-```bash
-# TODO: Replace with your project's post-release version bump command
-# npm version prerelease --preid=alpha --no-git-tag-version
-```
-
-- Update lockfiles or generated version metadata if your project needs them
-- Keep all version references in sync after the bump
-
-### 4. Rebuild Generated Artifacts
-
-<!-- TODO: Replace this step with your project's rebuild command -->
+## 1. Inspect Channel Facts
 
 ```bash
-# TODO: Replace with your project's artifact rebuild command
+agent-infra-internal release-workflow inspect {version}
 ```
 
-- Rebuild any generated files, embedded assets, or inline templates affected by the new version
-- If your project has no generated artifacts, remove this step in the project-specific copy
+Pending or unknown is blocked; a definite failure is failed.
 
-### 5. Run Other Post-release Tasks (Optional)
-
-<!-- TODO: Add project-specific follow-up tasks such as demo capture, docs publishing, or downstream notifications -->
-
-- Examples: record a terminal demo, refresh a docs site, notify downstream teams, update release dashboards
-- If a task here displays or captures the just-released version (e.g., recording a CLI demo), move it **before** Step 3 — otherwise it will reflect the next development version, not the release
-- If there are no extra tasks, remove this step in the project-specific copy
-
-### 6. Create the Follow-up Commit
+## 2. Run Post-release
 
 ```bash
-git add -A
-git commit -m "chore: prepare next dev iteration after v{released-version}"
+agent-infra-internal release-workflow post {version}
 ```
 
-### 7. Output Summary
-
-> **IMPORTANT**: All TUI command formats listed below must be output in full. Do not show only the format for the current AI agent. If `.agents/.airc.json` configures custom TUIs (via `customTUIs`), read each tool's `name` and `invoke`, then add the matching command line in the same format (`${skillName}` becomes the skill name and `${projectName}` becomes the project name).
-
-```
-Post-release tasks completed.
-
-Summary:
-- Released version: {released-version}
-- Next development version: {new-version}
-- Extra tasks completed: {summary}
-
-Next step (manual):
-- Push branch: git push origin {current-branch}
-```
-
-## Notes
-
-1. **No arguments**: Detect the released version from the latest tag instead of asking the user to repeat it
-2. **Clean workspace required**: Avoid mixing unrelated edits into the post-release commit
-3. **Project-specific customization**: Replace the TODO steps with the commands your project actually needs
-4. **Local-only workflow**: This skill prepares local changes and does not push automatically
+The core owns build, next development version, inline artifacts, explicit-path commit, normal push, and post-write inspection.
 
-## Error Handling
+## 3. Report the Snapshot
 
-- No release tag found: Prompt the user to finish the release first
-- Dirty workspace: Prompt the user to commit or stash changes
-- Version bump failed: Display the command error and stop
-- Artifact rebuild failed: Display the build error and stop
-- Git commit failed: Display the error and leave the workspace intact for manual recovery
+Report channel, smoke, commit, and push facts without presenting degraded or blocked as complete.

package/templates/.agents/skills/post-release/SKILL.zh-CN.md

@@ -7,92 +7,22 @@ description: >
 
 # 发布后处理
 
-在版本标签推送完成后，执行标准化的发布后收尾流程。
-
-## 执行流程
-
-### 1. 检测最新发布版本
-
-```bash
-git tag --sort=-v:refname | grep -E '^v[0-9]+\.[0-9]+\.[0-9]+$' | head -n 1
-```
-
-- 检测最新 `vX.Y.Z` 标签，并在后续步骤中去除 `v` 前缀得到版本号
-- 如果没有找到标签，报错："No released version tag found. Please create and push a release tag first."
-
-### 2. 验证工作区干净
-
-```bash
-git status --short
-```
-
-- 如果存在未提交变更，报错："Workspace has uncommitted changes. Please commit or stash first."
-
-### 3. 准备下一个开发版本
-
-<!-- TODO: 将此步骤替换为你的项目版本 bump 命令 -->
-
-```bash
-# TODO: 替换为你的项目发布后版本 bump 命令
-# npm version prerelease --preid=alpha --no-git-tag-version
-```
-
-- 如果项目需要，记得同步锁文件或其他版本元数据
-- 版本 bump 后保持所有版本引用一致
-
-### 4. 重新生成构建产物
-
-<!-- TODO: 将此步骤替换为你的项目产物重建命令 -->
+## 1. 检查渠道事实
 
 ```bash
-# TODO: 替换为你的项目产物重建命令
+agent-infra-internal release-workflow inspect {version}
 ```
 
-- 重建所有受新版本号影响的生成文件、内嵌产物或内联模板
-- 如果项目没有生成产物，请在项目特化版本中删除此步骤
+pending/unknown 必须 blocked，确定失败必须 failed。
 
-### 5. 执行其他发布后任务（可选）
-
-<!-- TODO: 添加项目特定的发布后任务，例如录制演示、发布文档站或通知下游 -->
-
-- 示例：录制终端演示、刷新文档站、通知下游团队、更新发布面板
-- 如果这一步里的任务需要显示或捕获刚发布的版本号（例如录制 CLI 演示），把它挪到**第 3 步「准备下一个开发版本」之前**——否则会反映下一个开发版本号，而不是 released 版本号
-- 如果没有额外任务，请在项目特化版本中删除此步骤
-
-### 6. 创建后处理提交
+## 2. 执行后处理
 
 ```bash
-git add -A
-git commit -m "chore: prepare next dev iteration after v{released-version}"
+agent-infra-internal release-workflow post {version}
 ```
 
-### 7. 输出摘要
-
-> **重要**：以下「下一步」中列出的所有 TUI 命令格式必须完整输出，不要只展示当前 AI 代理对应的格式。如果 `.agents/.airc.json` 中配置了自定义 TUI（`customTUIs`），读取每个工具的 `name` 和 `invoke`，按同样格式补充对应命令行（`${skillName}` 替换为技能名，`${projectName}` 替换为项目名）。
-
-```
-发布后处理已完成。
-
-结果摘要：
-- 已发布版本：{released-version}
-- 新开发版本：{new-version}
-- 额外任务完成情况：{summary}
-
-下一步（手动执行）：
-- 推送分支：git push origin {current-branch}
-```
-
-## 注意事项
-
-1. **无参数设计**：从最新标签自动检测已发布版本，不要求用户重复输入
-2. **需要干净工作区**：避免把无关改动带入发布后提交
-3. **项目定制**：将带 TODO 的步骤替换为你的项目实际命令
-4. **仅本地执行**：本技能只准备本地变更，不自动推送
+core 负责 build、下一开发版本、内联产物、显式路径 commit 与普通 push，并在写后复核。
 
-## 错误处理
+## 3. 输出摘要
 
-- 未找到发布标签：提示用户先完成发布
-- 工作区不干净：提示先提交或暂存
-- 版本 bump 失败：显示命令错误并停止
-- 产物重建失败：显示构建错误并停止
-- Git 提交失败：显示错误并保留当前工作区供人工处理
+报告全部渠道、smoke、commit 与 push 事实，不把 degraded/blocked 表述为完成。

package/templates/.agents/skills/refine-title/SKILL.en.md

@@ -60,7 +60,7 @@ If the user confirms:
 - for an Issue, update the title by following the "Update Issues" command in `.agents/rules/issue-pr-commands.md`
 - for a PR, update the title by following the "Update PRs" command in `.agents/rules/issue-pr-commands.md`
 
-Title changes require write permission. Follow the permission-degradation rules in `.agents/rules/issue-pr-commands.md` and `.agents/rules/issue-sync.md`; if permission is unavailable, skip the change and inform the user.
+Before changing a title, run `agent-infra-internal platform-context resolve` for upstream and capabilities, then follow the Issue metadata intent contract in `.agents/rules/issue-pr-commands.md`; if permission is unavailable, skip the change and inform the user.
 
 ### 5. Inform User
 

package/templates/.agents/skills/refine-title/SKILL.zh-CN.md

@@ -60,7 +60,7 @@ Issue/PR #{id} 分析结果：
 - 对于 Issue：按 `.agents/rules/issue-pr-commands.md` 中的 “Issue 更新” 命令设置标题
 - 对于 PR：按 `.agents/rules/issue-pr-commands.md` 中的 “PR 更新” 命令设置标题
 
-标题修改需要写权限，按 `.agents/rules/issue-pr-commands.md` 与 `.agents/rules/issue-sync.md` 中的权限降级规则执行；无权限时跳过修改操作并告知用户。
+标题修改前调用 `agent-infra-internal platform-context resolve` 取得 upstream 与 capabilities，再按 `.agents/rules/issue-pr-commands.md` 的 Issue metadata intent 契约执行；无权限时跳过修改操作并告知用户。
 
 ### 5. 告知用户
 

package/templates/.agents/skills/release/SKILL.en.md

@@ -2,188 +2,41 @@
 name: release
 description: >
   Run the version release workflow.
-  Use when you are ready to cut and publish a new version.
+  Use when preparing and publishing a version. Parameter: X.Y.Z.
 ---
 
-# Version Release
+# Release
 
-Execute the version release workflow for the specified version.
+Release state is derived from external facts and prepare/publish require separate authorization.
 
-<!-- TODO: Adapt the steps below to your project's release process -->
+## 1. Validate Input and Entropy Report
 
-## Execution Flow
+Confirm SemVer and the human release checkpoint.
 
-### 1. Parse and Validate Version
-
-Extract version from arguments. Must match `X.Y.Z` format.
-
-Parse components:
-- MAJOR = X, MINOR = Y, PATCH = Z
-- Release version = `X.Y.Z`
-
-If format is invalid, error: "Version format incorrect, expected X.Y.Z (e.g. 1.2.3)"
-
-### 2. Verify Clean Workspace
+## 2. Inspect Facts
 
 ```bash
-git status --short
+agent-infra-internal release-workflow inspect {version}
 ```
 
-If there are uncommitted changes, error: "Workspace has uncommitted changes. Please commit or stash first."
-
-### 3. Pre-release Verification
-
-<!-- TODO: Replace with your project's pre-release verification steps -->
-
-Run any checks that must pass before preparing a release:
+## 3. Prepare
 
 ```bash
-git branch --show-current
-# TODO: Replace with your project's test/build verification commands
+agent-infra-internal release-workflow prepare {version} --entropy-report {path}
 ```
 
-Verification guidance:
-- Confirm the release is being prepared from the correct branch for your project
-- Run the full validation commands required by your release process
-
-Handling rules:
-- If the current branch is unexpected, print a warning or exit based on your policy
-- If any verification command fails, stop the release process and fix the issue first
-
-### 4. Update Version References
-
-<!-- TODO: Replace with your project's version update steps -->
-
-Search for version references in project files and update them:
-
-```bash
-# Find files with version references
-# Search for current version pattern
-# Update version strings
-```
+Stop after prepare; never publish implicitly.
 
-**Common files to update**:
-- `package.json` (Node.js)
-- `package-lock.json` (Node.js; run `npm install --package-lock-only` after updating `package.json`)
-- `pom.xml` (Maven)
-- `setup.py` / `pyproject.toml` (Python)
-- `version.go` (Go)
-- `README.md` (documentation)
-- `SECURITY.md` / `SECURITY.zh-CN.md` (supported version table)
-
-**Exclude from version replacement**:
-- `.agents/`, `.agents/workspace/`, `.claude/`, `.codex/`, `.gemini/`, `.opencode/` (AI tool configs)
-
-If the project uses `package-lock.json`, run `npm install --package-lock-only` after updating `package.json` so the lockfile version stays in sync.
-
-### 5. Rebuild Artifacts
-
-<!-- TODO: Replace with your project's artifact rebuild steps -->
-
-If version updates affect generated files, embedded metadata, or bundled assets, rebuild them now:
-
-```bash
-# TODO: Replace with your project's rebuild command(s)
-```
-
-Execution guidance:
-- Run this after updating version references so generated artifacts pick up the new version
-- If your project has no generated artifacts, document that explicitly in the project-specific skill
-- If the rebuild fails, stop the release process and fix the build first
-
-### 6. Create Release Commit
-
-```bash
-git add -A
-git commit -m "chore: release v{version}"
-```
+## 4. Publish Separately
 
-### 7. Create Git Tag
+Only after explicit user authorization:
 
 ```bash
-git tag v{version}
+agent-infra-internal release-workflow publish {version}
 ```
 
-### 8. Manage Milestones
-
-Close the milestone for the released version when it exists, and create the missing planning milestones for the next cycle.
-
-Run:
-
-```bash
-bash .agents/skills/release/scripts/manage-milestones.sh "$MAJOR" "$MINOR" "$PATCH"
-```
-
-The script is responsible for:
-- Read `.agents/rules/label-milestone-setup.md` before this step
-- Use its milestone list and update commands to load and adjust current milestones
-- Closing `{MAJOR}.{MINOR}.{PATCH}` when it exists and is still open
-- Ensuring `{MAJOR}.{MINOR}.{PATCH+1}` and `{MAJOR}.{MINOR}.x` exist
-- When `PATCH=0`, also ensuring `{MAJOR}.{MINOR+1}.0` and `{MAJOR}.{MINOR+1}.x`
-- Printing a milestone summary with the released milestone action and new milestone count
-
-### 9. Output Summary
-
-> **IMPORTANT**: All TUI command formats listed below must be output in full. Do not show only the format for the current AI agent. If `.agents/.airc.json` configures custom TUIs (via `customTUIs`), read each tool's `name` and `invoke`, then add the matching command line in the same format (`${skillName}` becomes the skill name and `${projectName}` becomes the project name).
-
-```
-Release v{version} prepared.
-
-Release info:
-- Version: {version}
-- Release commit: {commit-hash}
-- Tag: v{version}
-
-Files updated: {count}
-
-Next steps (manual):
-
-1. Push branch:
-   git push origin {current-branch}
-
-2. Push tag:
-   git push origin v{version}
-
-3. (Optional) Generate release notes:
-   - Claude Code / OpenCode: /create-release-note {version}
-   - Gemini CLI: /{{project}}:create-release-note {version}
-   - Codex CLI: $create-release-note {version}
-
-4. (Optional) Run post-release follow-up tasks:
-   - Claude Code / OpenCode: /post-release
-   - Gemini CLI: /{{project}}:post-release
-   - Codex CLI: $post-release
-```
-
-### Rollback Instructions
-
-If something went wrong:
-```bash
-# Delete tag
-git tag -d v{version}
-
-# Reset commit
-git reset --soft HEAD~1
-
-# Restore files
-git checkout -- .
-```
-
-## Notes
-
-1. **Clean workspace required**: Must have no uncommitted changes
-2. **No auto-push**: All operations are local only; user pushes manually
-3. **Pre-release verification**: Replace the Step 3 TODOs with the branch, test, and validation commands your release process requires
-4. **Generated artifacts**: Replace the Step 5 TODOs when version changes affect generated files, bundled assets, or embedded metadata
-5. **Release automation**: If pushing a tag triggers CI/CD or package publishing, confirm the required credentials and pipeline settings first
-6. **Version replacement scope**: Search determines which files to update; exclude AI tool directories
-7. **Adapt to your project**: The version update and rebuild steps above are generic; customize them for your project's versioning scheme
-8. **Milestone coordination**: Releases should create the next planning milestones automatically; initialize the taxonomy first with `init-milestones` when needed
+Push refs normally, preserve partial success for replay, and never force push.
 
-## Error Handling
+## 5. Report Facts
 
-- Invalid version format: Prompt correct format and exit
-- Dirty workspace: Prompt to commit or stash
-- Verification failure: Display the failing check and stop the release
-- Artifact rebuild failure: Display the build error and stop the release
-- Git operation failure: Display error and provide rollback instructions
+Show the snapshot and every TUI command. Treat unknown external state as blocked.