@fitlab-ai/agent-infra 0.8.5 → 0.9.1

package/templates/.agents/skills/analyze-task/SKILL.en.md

@@ -3,6 +3,7 @@ name: analyze-task
 description: >
   Analyze a task and produce a requirements document.
   Use when you need to understand a task's requirements, scope, and risks before designing a solution.
+  Only invoke this skill automatically when the conversation includes a resolvable task reference.
 ---
 
 # Analyze Task
@@ -10,7 +11,7 @@ description: >
 ## Boundary / Critical Rules
 
 - This skill only outputs a requirements analysis document (`analysis.md` or `analysis-r{N}.md`) and does not modify any business code
-- Base the analysis strictly on the existing requirements, context, and source information in `task.md`
+- Base the analysis strictly on the existing task input, requirements, context, and source information in `task.md`
 - After executing this skill, you **must** immediately update task status in task.md
 
 Version stamp rule: when creating or updating `task.md` frontmatter, read `.agents/rules/version-stamp.md` first and write or refresh `agent_infra_version`.
@@ -22,26 +23,20 @@ After loading workflow / skill / rules instructions, and before any task-state j
 Run these commands and paste the raw output into both the user-facing reply and this round's `## State Check` section:
 
 ```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
 ```
 
 Before the state check is complete, do not make external-state assertions such as "the code is unchanged", "tests passed", or "there are no other references", including in reasoning. This gate is only a structural floor; evidence pairing and authenticity still require the report template and review discipline.
 
-## Task id short ref
+## Task Context Resolution
 
-> If `{task-id}` matches `^[#]?[0-9]+$` (bare numeric or `#`-prefixed), follow the "SKILL parameter resolver" section of `.agents/rules/task-short-id.md`; treat `{task-id}` as the resolved full `TASK-YYYYMMDD-HHMMSS` form for every downstream command.
+> The entry point may omit the task ref and also accepts a legacy positional ref or `--task <ref>` / `-t <ref>`. Separate task scope from the full arguments while preserving every business operand, then call `agent-infra-internal task-context resolve {task-scope}` where `{task-scope}` is empty, one positional ref, or one task flag. Read only `taskId` from the structured result and bind `{task-id}` to that full `TASK-YYYYMMDD-HHMMSS` for downstream commands. Pass through resolution failures without scanning tasks locally.
 
-## Step Start: Write the started Marker
+> Resolve the task reference, then confirm that the task is in a state or directory supported by this skill and that `task.md` exists; if it cannot be located, handle it as a missing task and stop.
 
-After prerequisites pass and before this round's first artifact action, append a started marker to task.md `## Activity Log` (same base action as this round's done entry plus a ` [started]` suffix, note `started`):
+## Step Start: Declare the started Event
 
-```
-- {YYYY-MM-DD HH:mm:ss±HH:MM} — **Analyze Task (Round {N}) [started]** by {agent} — started
-```
-
-`ai task log` pairs it with the done entry written on completion (step 7) onto one row (in progress → done). Format and pairing rules: see the "Activity Log started / done dual-marker convention" in `.agents/rules/task-management.md`.
+After resolving the artifact context and before this round's first artifact action, run `agent-infra-internal task-event {task-id} analyze.started --agent {agent}` and verify the returned `artifactContext`.
 
 ## Steps
 
@@ -54,20 +49,14 @@ Note: `{task-id}` format is `TASK-{yyyyMMdd-HHmmss}`, for example `TASK-20260306
 
 If `task.md` is missing, tell the user to create or import the task first.
 
-### 2. Determine the Analysis Round
+### 2. Resolve the Analysis Context
 
-Scan `.agents/workspace/active/{task-id}/` for analysis artifact files:
-- If neither `analysis.md` nor `analysis-r*.md` exists -> this is Round 1 and must create `analysis.md`
-- If `analysis.md` exists and no `analysis-r*.md` exists -> this is Round 2 and must create `analysis-r2.md`
-- If `analysis-r{N}.md` exists -> this is Round N+1 and must create `analysis-r{N+1}.md`
-
-Record:
-- `{analysis-round}`: the current analysis round
-- `{analysis-artifact}`: the artifact filename for this round
+Run `agent-infra-internal task-artifact {task-id} inspect --family analysis`. Continue only for `ready`; take `{analysis-round}` / `{analysis-artifact}` from `next.round` / `next.name` and revision inputs from `inputs`. Do not scan rounds or construct names in the skill.
 
 ### 3. Read Task Context
 
 Read `task.md` carefully to understand:
+- sources, facts and evidence, constraints, decision states, acceptance criteria, and open questions captured under `## Task Input` (fall back compatibly when the section is absent)
 - task title, description, and requirement list
 - context information (Issue, PR, branch, alert numbers, etc.)
 - currently known affected files and constraints
@@ -77,7 +66,7 @@ If `task.md` contains these source fields, also read the corresponding source in
 - `codescan_alert_number` - Code Scanning alert
 - `security_alert_number` - Dependabot alert
 
-**Round ≥ 2: respond to the prior review (only when a review artifact exists)**: if the task directory contains `review-analysis.md` / `review-analysis-r{N}.md`, read the highest-round review report; add a `## Response to Prior Review` section to this round's analysis artifact, and for each finding verify it via Read/Grep, then dispose of it with one of the four states in `.agents/rules/review-handshake.md` (`accepted` / `adjusted` / `refuted` / `cannot-judge`) — every state needs commensurate evidence, never defaulting to compliance; write the disposition back to the matching row in the task.md disagreement ledger (stage=analysis, round +1). Record any open disagreement under `## Open Questions`. Round 1 has no review, so skip this section.
+**Round ≥ 2: respond to the prior review (only when a review artifact exists)**: if the task directory contains `review-analysis.md` / `review-analysis-r{N}.md`, read the highest-round review report; add a `## Response to Prior Review` section to this round's analysis artifact, and for each finding verify it via Read/Grep, then dispose of it with one of the four states in `.agents/rules/review-handshake.md` (`accepted` / `adjusted` / `refuted` / `cannot-judge`) with commensurate evidence. Submit each response through `agent-infra-internal task-ledger {task-id} finding-respond --id {ledger-id} --round {analysis-round} --status {state} --evidence {evidence}`. Record open disagreements under `## Open Questions`. Round 1 skips this section.
 
 ### 4. Requirement Sufficiency Gate
 
@@ -101,6 +90,8 @@ Runs after Step 0 state check and Step 3 (questioning is an external-state actio
 - no answer carried → restate `pending_question` and take Scenario B early-exit below (do not increase `question_count`).
 
 **4.3 Sufficiency judgment** (objective checklist; any gap hit means insufficient):
+- first aggregate `## Task Input`, description, context, requirements, and remote sources; an analysis-owned `## Requirements` section being unpopulated is not by itself insufficient;
+- goals, scope, constraints, or acceptance criteria already recorded in task input count as provided and must not be asked again;
 - description/requirements empty, or a single sentence with no verifiable acceptance criteria;
 - missing goal or impact scope (unclear what to change / who is affected);
 - requirement items contradict each other, or key terms are undefined and block analysis.
@@ -112,12 +103,11 @@ Runs after Step 0 state check and Step 3 (questioning is an external-state actio
   1. Decide this round's question (consistent with 4.2):
      - if a `pending_question` already exists (the previous question is still unanswered) → restate that `pending_question`, do **not** modify it and do **not** increment `question_count`;
      - otherwise (no pending question) → pick the single highest-value question (acceptance criteria > scope > ambiguity) and write `## Brainstorming`: `status: asking`, `pending_question: <question>`, `question_count += 1`.
-  2. Update frontmatter: `current_step: requirement-analysis`, `assigned_to`, `updated_at`, `agent_infra_version` (read `.agents/rules/version-stamp.md` first); if `start_date` is empty, also write today's date (`date +%F`) to satisfy the required `start_date` check at the requirement-analysis stage.
-  3. Append to Activity Log: `- {YYYY-MM-DD HH:mm:ss±HH:MM} — **Analyze Task (Brainstorming)** by {agent} — Asked Q{question_count}, awaiting answer`.
-  4. Issue sync (when `issue_number` exists, skip on any failure): read `.agents/rules/issue-sync.md` first for upstream / permission detection; update only the **task comment** per the task.md comment sync rule; keep the `status` label at `pending-design-work`; do **not** publish an analysis artifact comment.
-  5. Verification (replaces the step 8 artifact gate): `node .agents/scripts/validate-artifact.js check task-meta .agents/workspace/active/{task-id} --skill analyze-task --format text` (the early-exit set `current_step: requirement-analysis` and wrote `start_date`, so it should pass); also keep `rg -n 'Analyze Task \(Brainstorming\)' .agents/workspace/active/{task-id}/task.md` and the task-comment sync evidence. Do **not** run the artifact gate, nor `check activity-log` / `check platform-sync` (both bind to the analysis artifact path).
-  6. User output: show only the current **single question** plus how to answer/continue (re-trigger `analyze-task {task-ref}` with the answer), and append the `Completed at` line per `.agents/rules/next-step-output.md`.
-  7. **STOP** and wait for the answer. The next trigger returns to this step.
+  2. If `start_date` is empty, write today (`date +%F`), then run `agent-infra-internal task-event {task-id} analyze.awaiting-input --agent {agent} --question {question_count}` so the core updates base metadata and Activity Log.
+  3. Issue sync (when `issue_number` exists, skip on any failure): run `agent-infra-internal platform-comment sync {task-id} --kind task --agent {agent}` to update only the **task comment**; keep the `status` label at `pending-design-work`; do **not** publish an analysis artifact comment.
+  4. Verification (replaces the step 8 artifact gate): `agent-infra-internal task-verify {task-id} analyze.awaiting-input --format text` (the early-exit set `current_step: requirement-analysis` and wrote `start_date`, so it should pass); also keep `rg -n 'Analyze Task \(Brainstorming\)' .agents/workspace/active/{task-id}/task.md` and the task-comment sync evidence. Do **not** run the artifact gate, nor `check activity-log` / `check platform-sync` (both bind to the analysis artifact path).
+  5. User output: show only the current **single question** plus how to answer/continue (re-trigger `analyze-task {task-ref}` with the answer), and append the `Completed at` line per `.agents/rules/next-step-output.md`.
+  6. **STOP** and wait for the answer. The next trigger returns to this step.
 
 ### 5. Perform Requirements Analysis
 
@@ -191,14 +181,7 @@ Create `.agents/workspace/active/{task-id}/{analysis-artifact}`.
 ## 人工裁决待办
 
 > Write this section only when this round upgraded a `[needs-human-decision]` key design decision; omit otherwise.
-> One `### HD-N` block per item (`HD-N` is globally unique, see `.agents/rules/review-handshake.md`), and upsert the matching `HD-` row in task.md `## Review Disagreement Ledger` (evidence pointing to `{analysis-artifact}#HD-N`).
-
-### HD-{N}：{title} [needs-human-decision]
-
-- **Background**: {why it became a pending decision}
-- **Options**: {A / B / …}
-- **Impact**: {scope / boundaries / precedent}
-- **Recommendation**: {recommended option and rationale}
+> First run `agent-infra-internal task-ledger {task-id} decision-next-id` to obtain `HD-N`, write the self-contained block according to `.agents/rules/human-decision-context.md`, then run `decision-upsert --id {HD-N} --stage analysis --artifact {analysis-artifact}`. Do not scan ids or assemble ledger rows.
 
 ## Effort and Complexity Assessment
 - Complexity: {High/Medium/Low}
@@ -207,17 +190,7 @@ Create `.agents/workspace/active/{task-id}/{analysis-artifact}`.
 
 ### 7. Update Task Status
 
-Get the current time:
-
-```bash
-date "+%Y-%m-%d %H:%M:%S%z" | sed 's/\([+-][0-9][0-9]\)\([0-9][0-9]\)$/\1:\2/'
-```
-
 Update `.agents/workspace/active/{task-id}/task.md`:
-- `current_step`: requirement-analysis
-- `assigned_to`: {current AI agent}
-- `updated_at`: {current time}
-- `agent_infra_version`: value from `.agents/rules/version-stamp.md`
 - Record the analysis artifact for this round: `{analysis-artifact}` (Round `{analysis-round}`)
 - If the task template contains a `## Analysis` section, update it to link to `{analysis-artifact}`
 - Mark requirement-analysis as complete in workflow progress and include the actual round when the task template supports it
@@ -225,17 +198,14 @@ Update `.agents/workspace/active/{task-id}/task.md`:
   - Overwrite the `priority` field in frontmatter with the new value
   - Append a `## Priority Re-estimate` section to this round's analysis artifact `{analysis-artifact}`, recording: `priority {old} → {new} (rationale: {short basis grounded in this analysis})`
   If the re-estimated value matches the current value, skip it: do not write the `## Priority Re-estimate` section. The Flow A sync that follows reads the possibly updated frontmatter and propagates the new value to the Issue automatically.
-- **Append** to `## Activity Log` (do NOT overwrite previous entries):
-  ```
+After the business fields are updated, run `agent-infra-internal task-event {task-id} analyze.completed --agent {agent} --artifact {analysis-artifact}` so the core atomically records the link, stage, agent, metadata, and Activity Log.
   - {YYYY-MM-DD HH:mm:ss±HH:MM} — **Analyze Task (Round {N})** by {agent} — Analysis completed → {analysis-artifact}
   ```
 
 If task.md contains a valid `issue_number`, perform these sync actions (skip and continue on any failure):
-- Read `.agents/rules/issue-sync.md` before syncing, and complete upstream repository detection plus permission detection
-- Set `status: pending-design-work` by following issue-sync.md
-- Create or update the task comment marker defined in `.agents/rules/issue-sync.md` (follow the task.md comment sync rule in issue-sync.md)
-- Publish the `{analysis-artifact}` comment
-- Read `.agents/rules/issue-fields.md` and follow Flow A to sync every non-empty Issue field (`priority`/`effort`/`start_date`/`target_date`) from `task.md` to the Issue (idempotent; skip without blocking when `has_push=false` or the fetch/write fails)
+- Run `agent-infra-internal platform-issue sync {task-id} --agent {agent} --status pending-design-work --fields`
+- Run `agent-infra-internal platform-comment sync {task-id} --kind task --agent {agent}`
+- Run `agent-infra-internal platform-comment sync {task-id} --kind artifact --artifact {analysis-artifact} --agent {agent}`
 
 ### 8. Verification Gate
 
@@ -244,7 +214,7 @@ If task.md contains a valid `issue_number`, perform these sync actions (skip and
 Run the verification gate to confirm the task artifact and sync state are valid:
 
 ```bash
-node .agents/scripts/validate-artifact.js gate analyze-task .agents/workspace/active/{task-id} {analysis-artifact} --format text
+agent-infra-internal task-verify {task-id} analyze.completed --artifact {analysis-artifact} --format text
 ```
 
 Handle the result as follows:
@@ -260,7 +230,7 @@ Keep the gate output in your reply as fresh evidence. Do not claim completion wi
 
 > Execute this step only after the verification gate passes.
 
-> **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). Before rendering the final output, read `.agents/rules/next-step-output.md` and apply both of its rules: (1) render `{task-ref}` in the "Next steps" commands as the short id `#NN` (falling back to the full TASK-id when unallocated or released); (2) append the `Completed at` line as the very last line of the user-facing output (this applies to every user-facing output — success, error, and early-return paths alike, not only the success path).
+> **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). Before rendering the final output, read `.agents/rules/next-step-output.md` and apply both of its rules: (1) render `{task-ref}` in the "Next steps" commands as the short id `NN` (falling back to the full TASK-id when unallocated or released); (2) append the `Completed at` line as the very last line of the user-facing output (this applies to every user-facing output — success, error, and early-return paths alike, not only the success path).
 
 Output format:
 ```

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

@@ -3,6 +3,7 @@ name: analyze-task
 description: >
   分析任务并输出需求分析文档。
   当需要在动手设计前厘清某个任务的需求、影响范围与风险时使用。
+  仅当对话包含可解析的任务引用时才可自动调用本技能。
 ---
 
 # 分析任务
@@ -10,7 +11,7 @@ description: >
 ## 行为边界 / 关键规则
 
 - 本技能仅产出需求分析文档（`analysis.md` 或 `analysis-r{N}.md`）—— 不修改任何业务代码
-- 严格基于 `task.md` 中已有的需求、上下文和来源信息展开分析
+- 严格基于 `task.md` 中已有的任务输入、需求、上下文和来源信息展开分析
 - 执行本技能后，你**必须**立即更新 task.md 中的任务状态
 
 版本戳规则：创建或更新 `task.md` frontmatter 时，先读取 `.agents/rules/version-stamp.md`，并写入或刷新 `agent_infra_version`。
@@ -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} — **Analyze 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} analyze.started --agent {agent}
+```
 
 ## 执行步骤
 ### 1. 验证前置条件
@@ -53,20 +52,14 @@ tail .agents/workspace/active/{task-id}/task.md
 
 如果缺少 `task.md`，提示用户先创建或导入任务。
 
-### 2. 确定分析轮次
-
-扫描 `.agents/workspace/active/{task-id}/` 目录中的分析产物文件：
-- 如果不存在 `analysis.md` 且不存在 `analysis-r*.md` → 本轮为第 1 轮，产出 `analysis.md`
-- 如果存在 `analysis.md` 且不存在 `analysis-r*.md` → 本轮为第 2 轮，产出 `analysis-r2.md`
-- 如果存在 `analysis-r{N}.md` → 本轮为第 N+1 轮，产出 `analysis-r{N+1}.md`
+### 2. 解析分析上下文
 
-记录：
-- `{analysis-round}`：本轮分析轮次
-- `{analysis-artifact}`：本轮分析产物文件名
+运行 `agent-infra-internal task-artifact {task-id} inspect --family analysis`。仅当结果为 `ready` 时继续；从 `next.round` / `next.name` 记录 `{analysis-round}` / `{analysis-artifact}`，从 `inputs` 读取修订上下文。不得自行扫描轮次或拼装文件名。随后执行 started 事件，并以事件返回的 `artifactContext` 复核同一身份。
 
 ### 3. 阅读任务上下文
 
 仔细阅读 `task.md` 以理解：
+- `## 任务输入` 中已捕获的来源、事实与证据、约束、决策状态、验收标准和未决事项（栏目不存在时兼容回退）
 - 任务标题、描述和需求列表
 - 上下文信息（Issue、PR、分支、告警编号等）
 - 当前已知的受影响文件和约束
@@ -76,7 +69,7 @@ tail .agents/workspace/active/{task-id}/task.md
 - `codescan_alert_number` - Code Scanning 告警
 - `security_alert_number` - Dependabot 告警
 
-**Round ≥ 2：响应上一轮审查（仅当存在审查产物时）**：若任务目录存在 `review-analysis.md` / `review-analysis-r{N}.md`，读取最高轮次的审查报告；在本轮分析产物中新增 `## 对上一轮审查的响应` 段，对每条发现先 Read/Grep 核实，再按 `.agents/rules/review-handshake.md` 的四态（`accepted` / `adjusted` / `refuted` / `cannot-judge`）处置——每态都要附相称证据，不默认顺从；并把处置回写 task.md `## 审查分歧账本` 对应行（stage=analysis，round +1）。未决分歧写入 `## 未决问题`。Round 1 无审查，跳过本段。
+**Round ≥ 2：响应上一轮审查（仅当存在审查产物时）**：若任务目录存在 `review-analysis.md` / `review-analysis-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 {analysis-round} --status {四态} --evidence {相称证据}`。未决分歧写入 `## 未决问题`。Round 1 无审查，跳过本段。
 
 ### 4. 入口需求充分性闸门
 
@@ -100,6 +93,8 @@ tail .agents/workspace/active/{task-id}/task.md
 - 未携带答案 → 复述 `pending_question`，按下文场景 B 提问早退（不增加 `question_count`）。
 
 **4.3 充分性判定**（客观清单，命中任一缺口即判为不足）：
+- 先聚合 `## 任务输入`、描述、上下文、需求及远端来源；分析阶段尚未填写 `## 需求` 本身不构成不足；
+- 已在任务输入中记录的目标、范围、约束或验收标准视为已提供，不得重复询问；
 - 描述/需求为空，或仅一句话且无可验证的验收标准；
 - 缺少目标或受影响范围（不知道要改什么 / 影响谁）；
 - 需求条目自相矛盾，或关键名词未定义而无法分析。
@@ -111,12 +106,11 @@ tail .agents/workspace/active/{task-id}/task.md
   1. 确定本轮要问的问题（与 4.2 保持一致）：
      - 若已存在 `pending_question`（上一问尚未得到答案）→ 复述该 `pending_question`，**不**修改它、**不**增加 `question_count`；
      - 否则（无待答问题）→ 选最高价值的一个问题（验收标准 > 范围 > 歧义），写入 `## Brainstorming`：`status: asking`、`pending_question: <问题>`、`question_count += 1`。
-  2. 更新 frontmatter：`current_step: requirement-analysis`、`assigned_to`、`updated_at`、`agent_infra_version`（先读 `.agents/rules/version-stamp.md`）；若 `start_date` 为空，同时写入当日日期（`date +%F`），以满足 requirement-analysis 阶段 `start_date` 必填校验。
-  3. 追加 Activity Log：`- {YYYY-MM-DD HH:mm:ss±HH:MM} — **Analyze Task (Brainstorming)** by {agent} — Asked Q{question_count}, awaiting answer`。
-  4. Issue 同步（存在 `issue_number` 时，任一失败跳过）：先读 `.agents/rules/issue-sync.md` 完成 upstream / 权限检测；仅按 task.md 评论同步规则更新 **task 评论**；`status` label 维持 `pending-design-work`；**不**发布分析产物评论。
-  5. 校验（替代步骤 8 的 artifact gate）：`node .agents/scripts/validate-artifact.js check task-meta .agents/workspace/active/{task-id} --skill analyze-task --format text`（早退已置 `current_step: requirement-analysis` 且已写入 `start_date`，预期通过）；并保留 `rg -n 'Analyze Task \(Brainstorming\)' .agents/workspace/active/{task-id}/task.md` 与 task 评论同步证据。**不**跑 artifact gate，也不跑 `check activity-log` / `check platform-sync`（二者绑定分析产物路径）。
-  6. 用户输出：只展示当前**单个问题** + 如何回答/继续（再次触发 `analyze-task {task-ref}` 并附答案），并按 `.agents/rules/next-step-output.md` 在末行追加 `Completed at`。
-  7. **STOP**，等待回答。下一次触发回到本步骤。
+  2. 若 `start_date` 为空，写入当日日期（`date +%F`）；随后执行 `agent-infra-internal task-event {task-id} analyze.awaiting-input --agent {agent} --question {question_count}`，由核心统一更新基础 frontmatter 和 Activity Log。
+  3. Issue 同步（存在 `issue_number` 时，任一失败跳过）：调用 `agent-infra-internal platform-comment sync {task-id} --kind task --agent {agent}` 更新 **task 评论**；`status` label 维持 `pending-design-work`；**不**发布分析产物评论。
+  4. 校验（替代步骤 8 的 artifact gate）：`agent-infra-internal task-verify {task-id} analyze.awaiting-input --format text`（早退已置 `current_step: requirement-analysis` 且已写入 `start_date`，预期通过）；并保留 `rg -n 'Analyze Task \(Brainstorming\)' .agents/workspace/active/{task-id}/task.md` 与 task 评论同步证据。**不**跑 artifact gate，也不跑 `check activity-log` / `check platform-sync`（二者绑定分析产物路径）。
+  5. 用户输出：只展示当前**单个问题** + 如何回答/继续（再次触发 `analyze-task {task-ref}` 并附答案），并按 `.agents/rules/next-step-output.md` 在末行追加 `Completed at`。
+  6. **STOP**，等待回答。下一次触发回到本步骤。
 
 ### 5. 执行需求分析
 
@@ -190,14 +184,7 @@ tail .agents/workspace/active/{task-id}/task.md
 ## 人工裁决待办
 
 > 仅当本轮升级了 `[needs-human-decision]` 关键设计决策时写本段；没有则省略。
-> 每项一个 `### HD-N` 块（`HD-N` 全局唯一，见 `.agents/rules/review-handshake.md`），并在 task.md `## 审查分歧账本` upsert 对应 `HD-` 行（evidence 指向 `{analysis-artifact}#HD-N`）。
-
-### HD-{N}：{标题} [needs-human-decision]
-
-- **背景**：{为何成为待裁决项}
-- **选项**：{A / B / …}
-- **影响**：{范围 / 边界 / 先例}
-- **推荐**：{推荐选项及理由}
+> 每项先调用 `agent-infra-internal task-ledger {task-id} decision-next-id` 取得 `HD-N`，按 `.agents/rules/human-decision-context.md` 写自足 `### HD-N` 块，再调用 `decision-upsert --id {HD-N} --stage analysis --artifact {analysis-artifact}`；不得扫描编号或手写账本行。
 
 ## 工作量和复杂度评估
 - 复杂度：{高/中/低}
@@ -206,35 +193,18 @@ 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`：requirement-analysis
-- `assigned_to`：{当前 AI 代理}
-- `updated_at`：{当前时间}
-- `agent_infra_version`：按 `.agents/rules/version-stamp.md` 取值
-- 记录本轮分析产物：`{analysis-artifact}`（Round `{analysis-round}`）
-- 如任务模板包含 `## 分析` 段落，更新为指向 `{analysis-artifact}` 的链接
-- 在工作流进度中标记 requirement-analysis 为已完成，并注明实际轮次（如果任务模板支持）
+- 仅更新优先级、Brainstorming、审查响应等本技能拥有的业务内容；产物链接、阶段与完成日志由 completed 事件统一登记
 - 在追加工作流 Activity Log 条目之前，基于分析结果（业务影响、风险、依赖、阻塞条件）重估 `priority`。若重估值与 `task.md` 当前值不一致：
   - 用新值覆盖 frontmatter 的 `priority` 字段
   - 在本轮分析产物 `{analysis-artifact}` 中追加 `## 优先级重估` 段，记录一条：`priority {old} → {new} (rationale: {基于本轮分析的简短依据})`
   若重估值与当前值一致，跳过：不写入 `## 优先级重估` 段。后续 Flow A 同步会读取可能更新过的 frontmatter，并自动把新值同步到 Issue。
-- **追加**到 `## Activity Log`（不要覆盖之前的记录）：
-  ```
-  - {YYYY-MM-DD HH:mm:ss±HH:MM} — **Analyze Task (Round {N})** by {agent} — Analysis completed → {analysis-artifact}
-  ```
+- 完成业务内容更新后执行 `agent-infra-internal task-event {task-id} analyze.completed --agent {agent} --artifact {analysis-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 评论同步规则）
-- 发布 `{analysis-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 {analysis-artifact} --agent {agent}`
 
 ### 8. 完成校验
 
@@ -243,7 +213,7 @@ date "+%Y-%m-%d %H:%M:%S%z" | sed 's/\([+-][0-9][0-9]\)\([0-9][0-9]\)$/\1:\2/'
 运行完成校验，确认任务产物和同步状态符合规范：
 
 ```bash
-node .agents/scripts/validate-artifact.js gate analyze-task .agents/workspace/active/{task-id} {analysis-artifact} --format text
+agent-infra-internal task-verify {task-id} analyze.completed --artifact {analysis-artifact} --format text
 ```
 
 处理结果：
@@ -259,7 +229,7 @@ node .agents/scripts/validate-artifact.js gate analyze-task .agents/workspace/ac
 
 > 仅在校验通过后执行本步骤。
 
-> **重要**：以下「下一步」中列出的所有 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/analyze-task/config/verify.en.json

@@ -27,14 +27,12 @@
         "Effort and Complexity Assessment",
         "State Check"
       ],
-      "freshness_minutes": 30,
       "required_patterns": [
         "^\\$ "
       ]
     },
     "activity-log": {
-      "expected_action_pattern": "(Analyze Task|Requirement Analysis) \\(Round \\d+\\)",
-      "freshness_minutes": 30
+      "expected_action_pattern": "(Analyze Task|Requirement Analysis) \\(Round \\d+\\)"
     },
     "platform-sync": {
       "when": "issue_number_exists",

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

@@ -27,14 +27,12 @@
         "工作量和复杂度评估",
         "状态核对"
       ],
-      "freshness_minutes": 30,
       "required_patterns": [
         "^\\$ "
       ]
     },
     "activity-log": {
-      "expected_action_pattern": "(Analyze Task|Requirement Analysis) \\(Round \\d+\\)",
-      "freshness_minutes": 30
+      "expected_action_pattern": "(Analyze Task|Requirement Analysis) \\(Round \\d+\\)"
     },
     "platform-sync": {
       "when": "issue_number_exists",

package/templates/.agents/skills/block-task/SKILL.en.md

@@ -3,6 +3,7 @@ name: block-task
 description: >
   Mark a task as blocked and record the reason.
   Use when a task cannot proceed because of an external blocker and you need to park it with a reason.
+  Only invoke this skill automatically when the conversation includes a resolvable task reference.
 ---
 
 # Block Task
@@ -21,19 +22,15 @@ description: >
 
 Version stamp rule: when creating or updating `task.md` frontmatter, read `.agents/rules/version-stamp.md` first and write or refresh `agent_infra_version`.
 
-## Task id short ref
+## Task Context Resolution
 
-> If `{task-id}` matches `^[#]?[0-9]+$` (bare numeric or `#`-prefixed), follow the "SKILL parameter resolver" section of `.agents/rules/task-short-id.md`; treat `{task-id}` as the resolved full `TASK-YYYYMMDD-HHMMSS` form for every downstream command.
+> The entry point may omit the task ref and also accepts a legacy positional ref or `--task <ref>` / `-t <ref>`. Separate task scope from the full arguments while preserving every business operand, then call `agent-infra-internal task-context resolve {task-scope}` where `{task-scope}` is empty, one positional ref, or one task flag. Read only `taskId` from the structured result and bind `{task-id}` to that full `TASK-YYYYMMDD-HHMMSS` for downstream commands. Pass through resolution failures without scanning tasks locally.
 
-## Step Start: Write the started Marker
+> Resolve the task reference, then confirm that the task is in a state or directory supported by this skill and that `task.md` exists; if it cannot be located, handle it as a missing task and stop.
 
-After prerequisites pass and before this step's first artifact action, append a started marker to task.md `## Activity Log` (same base action as this step's done entry plus a ` [started]` suffix, note `started`):
+## Step Start: Local Lifecycle Boundary
 
-```
-- {YYYY-MM-DD HH:mm:ss±HH:MM} — **Block Task [started]** by {agent} — started
-```
-
-`ai task log` pairs it with the done entry written on completion onto one row (in progress → done). See the "Activity Log started / done dual-marker convention" in `.agents/rules/task-management.md`.
+After prerequisites pass, Step 3 declares one lifecycle intent that atomically writes the started/done pair, base metadata, directory move, and short-id release. Do not write those pieces manually first.
 
 ## Steps
 
@@ -53,33 +50,20 @@ Before blocking, thoroughly analyze:
 - [ ] What solutions have been attempted?
 - [ ] What help or information is needed to unblock?
 
-### 3. Update Task Metadata
-
-Get the current time:
+### 3. Apply the Local Lifecycle Intent
 
 ```bash
-date "+%Y-%m-%d %H:%M:%S%z" | sed 's/\([+-][0-9][0-9]\)\([0-9][0-9]\)$/\1:\2/'
+agent-infra-internal task-lifecycle {task-id} block --agent {agent} \
+  --reason "{one-line reason}" --unblock-condition "{unblock condition}"
 ```
 
-Update `.agents/workspace/active/{task-id}/task.md`:
-- `status`: blocked
-- `blocked_at`: {current timestamp}
-- `updated_at`: {current timestamp}
-- `agent_infra_version`: value from `.agents/rules/version-stamp.md`
-- **Append** to `## Activity Log` (do NOT overwrite previous entries):
-  ```
-  - {YYYY-MM-DD HH:mm:ss±HH:MM} — **Block Task** by {agent} — {one-line reason}
-  ```
+Only `status=applied|no-op` means the local block completed. On `status=failed`, show the structured error and recovery steps and retry the same intent; do not manually edit task.md, move the directory, or release the short id.
 
-Add a blocking information section to task.md.
+### 4. Verify the Local Final State
 
-### 4. Move Task to Blocked Directory
-
-```bash
-mv .agents/workspace/active/{task-id} .agents/workspace/blocked/{task-id}
-```
+Confirm `targetState=blocked`, the target path, and the committed short-id effect.
 
-### 5. Verify Move
+### 5. Preserve Recovery Identity
 
 ```bash
 ls .agents/workspace/blocked/{task-id}/task.md
@@ -89,22 +73,15 @@ ls .agents/workspace/blocked/{task-id}/task.md
 
 Check whether `task.md` includes a valid `issue_number`. If not, skip this step.
 
-> Status-label sync rules live in `.agents/rules/issue-sync.md`. Read that file before syncing, and complete upstream repository detection plus permission detection.
-
-If a valid `issue_number` exists, set `status: blocked` by following issue-sync.md.
+If a valid `issue_number` exists, run `agent-infra-internal platform-issue sync {task-id} --agent {agent} --status blocked`.
+Then run `agent-infra-internal platform-comment sync {task-id} --kind task --agent {agent}`.
 
 ### 7. Verification Gate
 
-**Release short id** (after the directory has already been moved; the script is idempotent and returns 0 even if the task isn't registered):
-
-```bash
-node .agents/scripts/task-short-id.js release "$task_id" || true
-```
-
 Run the verification gate to confirm the task artifact and sync state are valid:
 
 ```bash
-node .agents/scripts/validate-artifact.js gate block-task .agents/workspace/blocked/{task-id} --format text
+agent-infra-internal task-verify {task-id} block-task.completed --format text
 ```
 
 Handle the result as follows:
@@ -118,7 +95,7 @@ Keep the gate output in your reply as fresh evidence. Do not claim completion wi
 
 > Execute this step only after the verification gate passes.
 
-> **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). Before rendering the final output, read `.agents/rules/next-step-output.md` and apply both of its rules: (1) render `{task-ref}` in the "Next steps" commands as the short id `#NN` (falling back to the full TASK-id when unallocated or released); (2) append the `Completed at` line as the very last line of the user-facing output (this applies to every user-facing output — success, error, and early-return paths alike, not only the success path).
+> **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). Before rendering the final output, read `.agents/rules/next-step-output.md` and apply both of its rules: (1) render `{task-ref}` in the "Next steps" commands as the short id `NN` (falling back to the full TASK-id when unallocated or released); (2) append the `Completed at` line as the very last line of the user-facing output (this applies to every user-facing output — success, error, and early-return paths alike, not only the success path).
 
 > **Optional sandbox-cleanup hint (gated)**: Render the "Optional: clean up this task's sandbox" block — placed after "Archived to" and before "To unblock" in the output below — only when BOTH (1) `.agents/.airc.json` has a `sandbox` field and (2) task.md's `branch` field exists and is not `main` / `master`; otherwise omit the whole block. `{branch}` is the `branch` value from the task.md you already loaded (the task has moved to blocked/, so read it from `.agents/workspace/blocked/{task-id}/task.md`). This block is independent of "Next step" semantics.
 
@@ -136,8 +113,7 @@ Optional: clean up this task's sandbox
 ai sandbox rm {branch}
 
 To unblock when the issue is resolved:
-  mv .agents/workspace/blocked/{task-id} .agents/workspace/active/{task-id}
-  # Then update task.md: status -> active, remove blocked_at
+  agent-infra-internal task-lifecycle {task-id} activate --agent {agent} --note "{activation note}"
 
 Next step - check task status after unblocking:
   - Claude Code / OpenCode: /check-task {task-ref}
@@ -160,13 +136,11 @@ Next step - check task status after unblocking:
 When the blocking issue is resolved:
 
 ```bash
-# 1. Move back to active
-mv .agents/workspace/blocked/{task-id} .agents/workspace/active/{task-id}
-
-# 2. Update task.md: set status to active, update timestamps
-# 3. Resume from where you left off (check current_step)
+agent-infra-internal task-lifecycle {task-id} activate --agent {agent} --note "{activation note}"
 ```
 
+Resume from the preserved `current_step`. On failure, retry the same intent from the structured recovery fields instead of hand-editing lifecycle state.
+
 ## Notes
 
 1. **When to block**: Only block when you genuinely cannot proceed. If it is a difficulty you can work through, try harder first.