analyze-trajectory

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Analyze Trajectory

分析轨迹

You are doing a deep dive into a recurring failure pattern. The harness's pre-computed

YOUR TRAJECTORY

block surfaces that something is recurring; this skill helps you understand why and produce a focused diagnosis.

This skill exists because raw GitHub Actions logs are too large and noisy to digest in your main context window. The pattern (Recursive Language Model — see Reithan's reference in issue #226) is: keep your root context small, dispatch a sub-agent to read the raw logs, and have the sub-agent return a 1-3 sentence summary. Recurse if the summary surfaces a deeper question.

你正在深入分析一种重复出现的故障模式。Harness预先计算的

YOUR TRAJECTORY

模块显示出存在重复问题；本技能可帮助你理解问题产生的原因，并生成一份针对性的诊断结果。

本技能的存在是因为原始GitHub Actions日志过大且噪音过多，无法在主上下文窗口中处理。其模式为递归语言模型（参考Reithan在第226号问题中的说明）：保持根上下文简洁，调度子Agent读取原始日志，由子Agent返回1-3句话的摘要。如果摘要引出更深层次的问题，则进行递归分析。

When to use

使用场景

Trigger this skill when ANY of these hold:

```
YOUR TRAJECTORY
```
flagged a
```
STUCK
```
task (≥3 attempts in window, 0 successes)
A CI error fingerprint appeared
```
≥2×
```
in the recurring-errors section
Multiple revert commits appeared across recent sessions (the trajectory's "Reverts in window" line shows the count)
A specific issue (e.g.
```
#205
```
) has been mentioned in multiple session journals without resolution

当满足以下任意一种情况时，触发本技能：

```
YOUR TRAJECTORY
```
标记了
```
STUCK
```
任务（在统计窗口内尝试≥3次，成功率为0）
CI错误特征在重复错误部分出现≥2次
近期会话中出现多个回滚提交（轨迹的“窗口内回滚次数”行显示具体数量）
某个特定问题（如
```
#205
```
）在多个会话日志中被提及但未解决

When NOT to use

不适用场景

The trajectory looks healthy. Don't spelunk for problems that aren't there — that's just burning sub-agent budget.
The failure is well-understood already (you already know the cause from journal/learnings). Skip straight to the fix.
You're inside Phase B (implementation) and the failure is the task you're currently doing — fix it directly, don't recurse.

轨迹显示一切正常。不要无中生有地寻找问题——这只会浪费子Agent的资源。
故障原因已明确（你已从日志/经验中了解到原因）。直接跳过诊断步骤，进入修复环节。
处于阶段B（实施阶段）且故障是当前正在执行的任务——直接修复，无需递归分析。

Procedure

操作流程

1. Frame the question (single sentence)

1. 明确问题（单句表述）

Examples of well-framed questions:

"Why does the evaluator phase fail with 'AnthropicError: rate_limit_exceeded' on sessions day-53, day-55, and day-56?"
"Why was the task 'Add /fallback flag' reverted on 6 separate sessions? What's the recurring blocker?"
"What does run 4321 look like at the moment of failure?"

A good question names a specific event (run id, session day, error fingerprint) and what you want to know about it. Don't ask vague questions like "what's wrong with my trajectory?"

问题表述示例：

“为什么评估阶段在第53、55、56天的会话中因‘AnthropicError: rate_limit_exceeded’失败？”
“为什么‘添加/fallback标志’任务在6个不同会话中被回滚？重复出现的障碍是什么？”
“第4321次运行在故障发生时的状态是什么？”

一个好的问题应明确指出特定事件（运行ID、会话日期、错误特征）以及你想了解的内容。不要提出模糊的问题，比如“我的轨迹出了什么问题？”

2. Identify the artifact

2. 确定分析对象

For each question, pick exactly one artifact to fetch:

CI failure → run id from the trajectory's CI errors section.
```
gh run view <id> --log-failed
```
(drop
```
--repo
```
; gh auto-detects from the local clone's origin remote, which is the right one)
Reverted task → commit SHA of the revert.
```
git show <sha>
```
and the next-newer commit's full diff

Session-level wreckage → audit.jsonl from that session. Note:

$YOYO_AUDIT_DIR

is set by the harness ONLY inside

scripts/skill_evolve.sh

(a different invocation than evolve.sh). When loaded inside a normal evolve session, you must fetch the audit-log branch yourself first:

bash

git fetch --depth 50 origin audit-log:audit-log
AUDIT_WT=$(mktemp -d)
git worktree add "$AUDIT_WT" audit-log
ls "$AUDIT_WT/sessions/" | tail -10
# ... read what you need ...
git worktree remove --force "$AUDIT_WT"

针对每个问题，选择恰好一个分析对象：

CI故障 → 从轨迹的CI错误部分获取运行ID。执行命令
```
gh run view <id> --log-failed
```
（无需添加
```
--repo
```
；gh会自动从本地克隆的origin远程仓库检测，这是正确的仓库）
回滚任务 → 回滚提交的SHA值。执行
```
git show <sha>
```
并查看下一个较新提交的完整差异

会话级故障 → 该会话的audit.jsonl文件。注意：

$YOYO_AUDIT_DIR

仅在

scripts/skill_evolve.sh

（与evolve.sh的调用方式不同）中由Harness设置。在普通evolve会话中加载时，你必须自行先获取audit-log分支：

bash

git fetch --depth 50 origin audit-log:audit-log
AUDIT_WT=$(mktemp -d)
git worktree add "$AUDIT_WT" audit-log
ls "$AUDIT_WT/sessions/" | tail -10
# ... 读取所需内容 ...
git worktree remove --force "$AUDIT_WT"

3. Decide: direct read or sub-agent?

3. 决定：直接读取还是使用子Agent？

Estimate the artifact size first:

bash

gh run view <id> --log-failed 2>/dev/null | wc -c

< 5KB: read it directly with
```
read_file
```
or
```
bash
```
. Skip sub-agent — the cost isn't worth it.
≥ 5KB: dispatch a sub-agent. Don't load raw logs into your main context.

先估算分析对象的大小：

bash

gh run view <id> --log-failed 2>/dev/null | wc -c

小于5KB：使用
```
read_file
```
或bash直接读取。无需使用子Agent——成本不值得。
大于等于5KB：调度子Agent。不要将原始日志加载到主上下文中。

3.5. Handle large artifacts (token-aware chunking)

3.5. 处理大文件（基于Token的分块）

Before dispatching a sub-agent, estimate whether the artifact fits in a single sub-agent's context:

estimated_tokens = artifact_bytes / 4

If estimated_tokens ≤ 30,000 (roughly half a sub-agent's context window): proceed to Step 4 as normal — single sub-agent dispatch.

If estimated_tokens > 30,000: the artifact is too large for one sub-agent to digest reliably. Split and fan out:

Split into chunks of ~20,000 tokens (~80,000 bytes) with 2,000-token (~8,000 byte) overlap between consecutive chunks. The overlap ensures error context that spans a chunk boundary isn't lost.

Store each chunk separately in shared state:

shared_state set key="trajectory.run-<id>.chunk-1" value="<first 80KB>"
shared_state set key="trajectory.run-<id>.chunk-2" value="<next 80KB, starting 8KB before the split>"
...

Dispatch one sub-agent per chunk with the prompt:

You are analyzing CHUNK <N> of <M> from a CI log.

The chunk is stored in shared state under key "trajectory.run-<id>.chunk-<N>".
Read it with: shared_state get key="trajectory.run-<id>.chunk-<N>"

Question: <your single-sentence question from step 1>

Reply with ONLY a JSON object (no markdown fences, no prose):
{
  "summary": "1-3 sentences on what this chunk reveals about the failure",
  "key_lines": ["relevant line 1", "relevant line 2"],
  "chunk_relevant": true,
  "confidence": "high|medium|low"
}

If this chunk contains no information relevant to the question, set chunk_relevant to false
and keep summary/key_lines minimal.

Merge chunk results — after all chunk sub-agents return, store their combined results in shared state and dispatch one final merge sub-agent:

shared_state set key="trajectory.run-<id>.chunk-results" value="<JSON array of chunk responses>"

Merge sub-agent prompt:

You are merging analyses from <M> chunks of a single CI log.

The chunk analyses are stored in shared state under key "trajectory.run-<id>.chunk-results".
Read them with: shared_state get key="trajectory.run-<id>.chunk-results"

Original question: <your single-sentence question from step 1>

Synthesize the chunk analyses into a single diagnosis.
Reply with ONLY a JSON object (no markdown fences, no prose):
{
  "summary": "1-3 sentences explaining the root cause",
  "key_lines": ["most important line 1", "most important line 2"],
  "deeper_question": null,
  "confidence": "high|medium|low"
}

The merge sub-agent's response is your diagnosis — validate it using the same JSON contract rules in Step 4.

Chunking counts toward the recursion cap (Step 5): each chunk sub-agent is depth 1, the merge sub-agent is depth 1. If chunking used 4 chunk agents + 1 merge agent, you've used 1 of your 3 recursion levels. You can still recurse on a

deeper_question

from the merge result, but be mindful of the budget.

调度子Agent前，估算文件是否能放入单个子Agent的上下文窗口：

estimated_tokens = artifact_bytes / 4

如果estimated_tokens ≤ 30,000（约为子Agent上下文窗口的一半）：按正常流程进入步骤4——单次调度子Agent。

如果estimated_tokens > 30,000：文件过大，单个子Agent无法可靠处理。需拆分并并行处理：

拆分文件：将文件拆分为约20,000 Token（约80,000字节）的块，连续块之间保留2,000 Token（约8,000字节）的重叠部分。重叠部分可确保跨越块边界的错误上下文不会丢失。

将每个块单独存储到共享状态：

shared_state set key="trajectory.run-<id>.chunk-1" value="<first 80KB>"
shared_state set key="trajectory.run-<id>.chunk-2" value="<next 80KB, starting 8KB before the split>"
...

为每个块调度一个子Agent，提示语如下：

You are analyzing CHUNK <N> of <M> from a CI log.

The chunk is stored in shared state under key "trajectory.run-<id>.chunk-<N>".
Read it with: shared_state get key="trajectory.run-<id>.chunk-<N>"

Question: <your single-sentence question from step 1>

Reply with ONLY a JSON object (no markdown fences, no prose):
{
  "summary": "1-3 sentences on what this chunk reveals about the failure",
  "key_lines": ["relevant line 1", "relevant line 2"],
  "chunk_relevant": true,
  "confidence": "high|medium|low"
}

If this chunk contains no information relevant to the question, set chunk_relevant to false
and keep summary/key_lines minimal.

合并块分析结果——所有块的子Agent返回结果后，将合并后的结果存储到共享状态，并调度一个最终的合并子Agent：

shared_state set key="trajectory.run-<id>.chunk-results" value="<JSON array of chunk responses>"

合并子Agent的提示语：

You are merging analyses from <M> chunks of a single CI log.

The chunk analyses are stored in shared state under key "trajectory.run-<id>.chunk-results".
Read them with: shared_state get key="trajectory.run-<id>.chunk-results"

Original question: <your single-sentence question from step 1>

Synthesize the chunk analyses into a single diagnosis.
Reply with ONLY a JSON object (no markdown fences, no prose):
{
  "summary": "1-3 sentences explaining the root cause",
  "key_lines": ["most important line 1", "most important line 2"],
  "deeper_question": null,
  "confidence": "high|medium|low"
}

合并子Agent的响应即为诊断结果——使用步骤4中的相同JSON规则验证结果。

分块会占用递归上限（步骤5）：每个块的子Agent深度为1，合并子Agent深度为1。如果分块使用了4个块Agent +1个合并Agent，则已使用了3个递归层级中的1个。你仍可针对合并结果中的

deeper_question

进行递归，但需注意资源限制。

4. Dispatch a sub-agent (if needed)

4. 调度子Agent（如需）

Store the artifact in shared state first — don't paste large logs into the sub-agent prompt. Sub-agents automatically have access to the

shared_state

tool and share the same key-value store as their parent.

Use the namespace convention

trajectory.<key>

for all artifacts stored by this skill.

bash

undefined

先将分析对象存储到共享状态——不要将大型日志粘贴到子Agent的提示语中。子Agent自动有权访问

shared_state

工具，并与父Agent共享相同的键值存储。

本技能存储的所有分析对象均使用

trajectory.<key>

命名空间约定。

bash

undefined

1. Fetch the artifact into a shell variable

1. 将分析对象获取到shell变量中

LOG=$(gh run view <id> --log-failed 2>/dev/null)

2. Store it in shared state (the parent agent calls this directly)

2. 将其存储到共享状态（父Agent直接调用此命令）

shared_state set key="trajectory.run-<id>" value="$LOG"


Then dispatch the sub-agent with a **reference**, not the artifact itself:

Question: <your single-sentence question from step 1>

The CI log is stored in shared state under key "trajectory.run-<id>". Read it with: shared_state get key="trajectory.run-<id>"

Reply with ONLY a JSON object (no markdown fences, no prose) matching this schema:

{ "summary": "1-3 sentences explaining the root cause, with no surrounding quotes", "key_lines": ["file.rs:42:11 borrow of moved value", "AnthropicError: rate_limit_exceeded"], "deeper_question": null, "confidence": "medium" }

Field rules:

summary: free string, 1-3 sentences
key_lines: array of 1-5 short strings (max 100 chars each) that prove the cause
deeper_question: JSON null when no follow-up is needed; otherwise a single-sentence string
confidence: exactly one of "high", "medium", or "low"


Sub-agents inherit RTK compression on bash output and directory restrictions, but they do NOT inherit skills. Keep the sub-agent prompt fully self-contained — don't reference other skills. Sub-agents share the parent's `SharedState` store automatically (via `SharedStateTool` wired by `build_sub_agent_tool`).

**Validate the sub-agent response** — after the sub-agent returns, check:

1. **Parse as JSON.** Strip any leading/trailing whitespace and markdown code fences (` ```json ... ``` `) that sub-agents sometimes add despite instructions.
2. **Check required fields.** The parsed object must contain all four keys: `summary` (string), `key_lines` (array of strings), `deeper_question` (string or null), `confidence` (one of `"high"`, `"medium"`, `"low"`).
3. **If valid** → proceed to Step 5 (recursion check).
4. **If invalid** → retry ONCE with this prompt:

Your previous response was not valid JSON or was missing required fields.

Please respond with ONLY a JSON object (no markdown, no explanation): { "summary": "1-3 sentences explaining the root cause", "key_lines": ["key line 1", "key line 2"], "deeper_question": null, "confidence": "high|medium|low" }

Required fields: summary (string), key_lines (array), deeper_question (string or null), confidence ("high"|"medium"|"low").


5. **If retry also fails** → fall back gracefully (see below).

**Sub-agent failure fallback** — if the sub-agent (a) errors, (b) returns non-JSON twice (initial + retry), (c) returns truncated JSON that can't be repaired, or (d) is unavailable as a tool:

1. Append the raw response to `memory/learnings.jsonl` as a learning entry with `pattern_key: trajectory.subagent_malformed_response` so we can debug later.
2. Extract whatever text the sub-agent did return and treat it as the `summary` field. Construct a synthetic response: `{"summary": "<raw text, first 500 chars>", "key_lines": [], "deeper_question": null, "confidence": "low"}`.
3. If even the raw text is empty or the sub-agent errored entirely, downgrade to a direct read of the artifact: use `shared_state get key="trajectory.run-<id>"` to retrieve the stored log, then read the last 50-100 lines in your main context.
4. Produce a low-confidence diagnosis from what you can see directly. Skip recursion (no point — sub-agent path is broken).
5. Mark the diagnosis with `confidence: low (sub-agent unavailable)` so downstream decisions know to be cautious.

shared_state set key="trajectory.run-<id>" value="$LOG"


然后通过**引用**而非分析对象本身来调度子Agent：

Question: <your single-sentence question from step 1>

The CI log is stored in shared state under key "trajectory.run-<id>". Read it with: shared_state get key="trajectory.run-<id>"

Reply with ONLY a JSON object (no markdown fences, no prose) matching this schema:

Field rules:

summary: free string, 1-3 sentences
key_lines: array of 1-5 short strings (max 100 chars each) that prove the cause
deeper_question: JSON null when no follow-up is needed; otherwise a single-sentence string
confidence: exactly one of "high", "medium", or "low"


子Agent继承bash输出的RTK压缩和目录限制，但**不继承技能**。子Agent的提示语必须完全独立——不要引用其他技能。子Agent自动与父Agent共享`SharedState`存储（通过`build_sub_agent_tool`连接的`SharedStateTool`）。

**验证子Agent的响应**——子Agent返回结果后，检查：

1. **是否可解析为JSON**。去除子Agent有时会添加的首尾空白和markdown代码块标记（` ```json ... ``` `），即使提示语中已说明不要添加。
2. **是否包含必填字段**。解析后的对象必须包含四个键：`summary`（字符串）、`key_lines`（字符串数组）、`deeper_question`（字符串或null）、`confidence`（`"high"`、`"medium"`或`"low"`中的一个）。
3. **如果有效** → 进入步骤5（递归检查）。
4. **如果无效** → 使用以下提示语重试一次：

Your previous response was not valid JSON or was missing required fields.

Required fields: summary (string), key_lines (array), deeper_question (string or null), confidence ("high"|"medium"|"low").


5. **如果重试也失败** → 优雅降级（见下文）。

**子Agent失败的降级方案**——如果子Agent出现以下情况：(a) 报错，(b) 两次返回非JSON内容（初始+重试），(c) 返回无法修复的截断JSON，或(d) 工具不可用：

1. 将原始响应作为学习条目追加到`memory/learnings.jsonl`中，设置`pattern_key: trajectory.subagent_malformed_response`，以便后续调试。
2. 提取子Agent返回的所有文本，将其作为`summary`字段。构造一个合成响应：`{"summary": "<raw text, first 500 chars>", "key_lines": [], "deeper_question": null, "confidence": "low"}`。
3. 如果甚至原始文本为空或子Agent完全报错，则降级为直接读取分析对象：使用`shared_state get key="trajectory.run-<id>"`检索存储的日志，然后在主上下文中读取最后50-100行。
4. 根据你能直接看到的内容生成低置信度的诊断结果。跳过递归（无意义——子Agent路径已损坏）。
5. 在诊断结果中标记`confidence: low (sub-agent unavailable)`，以便下游决策时保持谨慎。

5. Recurse if the sub-agent returns

deeper_question

5. 如果子Agent返回

deeper_question

则进行递归

confidence

"low"

AND

deeper_question

is a non-null string (JSON null returns false on this check, but if you see the literal string

"null"

treat it as null too — that's a sub-agent bug worth logging), run another sub-agent dispatch with the narrower question. Reuse the same artifact; the sub-agent will focus differently.

Hard cap: recursion depth = 3. That's: initial dispatch → 1st recursion → 2nd recursion. After that, accept whatever you have. The cap is informed by the recursive-LM literature (RLM blog, alexzhang13.github.io/blog/2025/rlm/) and prevents runaway agent costs.

If you hit the cap without

confidence == "high"

, that's still a valid outcome — write the diagnosis with whatever clarity you have and flag it as "needs follow-up".

如果

confidence

为

"low"

且

deeper_question

为非null字符串（JSON null会被视为false，但如果看到字面字符串

"null"

也视为null——这是一个需要记录的子Agent bug），则使用更具体的问题再次调度子Agent。重复使用相同的分析对象；子Agent会聚焦于不同的点。

硬限制：递归深度=3。即：初始调度→第一次递归→第二次递归。超过此限制后，接受现有结果。该限制基于递归LM文献（RLM博客，alexzhang13.github.io/blog/2025/rlm/），可防止Agent资源失控消耗。

如果达到限制但

confidence != "high"

，这仍是有效的结果——根据现有清晰度撰写诊断结果，并标记为“需后续跟进”。

6. Aggregate to a single diagnosis

6. 汇总为单一诊断结果

Produce a 3-5 sentence diagnosis paragraph that includes:

What recurs: one-line summary of the pattern
Root cause (or best-guess): from the sub-agent's summary
Evidence: ≤3 specific lines or run IDs
Suggested next attempt: one concrete action (a different approach, a new task, or "log to learnings.jsonl and skip for now")

Write the diagnosis somewhere durable:

If you're in a normal evolve session and this informed your task choice → cite it in the assessment doc
If you're investigating a specific issue → comment on the issue with the diagnosis
Always also append a
```
learnings.jsonl
```
entry. The
```
pattern_key
```
field (optional in the standard schema, see
```
skills/communicate/SKILL.md
```
) takes a kebab-case
```
<verb>.<object>
```
value — for trajectory-derived diagnoses, use
```
pattern_key: trajectory.<short-slug>
```
(e.g.,
```
trajectory.fallback_provider_stuck
```
,
```
trajectory.evaluator_rate_limit
```
). This lets skill-evolve cluster recurring trajectory findings.

生成一段3-5句话的诊断段落，包含：

重复出现的问题：对模式的单行总结
根本原因（或最佳猜测）：来自子Agent的摘要
证据：≤3个特定行或运行ID
建议的下一步操作：一个具体的行动（不同的方法、新任务，或“记录到learnings.jsonl并暂时跳过”）

将诊断结果写入持久化位置：

如果在普通evolve会话中，且诊断结果影响了你的任务选择→在评估文档中引用它
如果在调查特定问题→在问题下评论诊断结果
始终同时追加一条
```
learnings.jsonl
```
条目。
```
pattern_key
```
字段（标准 schema 中可选，见
```
skills/communicate/SKILL.md
```
）采用短横线分隔的
```
<verb>.<object>
```
格式——对于基于轨迹的诊断，使用
```
pattern_key: trajectory.<short-slug>
```
（例如
```
trajectory.fallback_provider_stuck
```
、
```
trajectory.evaluator_rate_limit
```
）。这可让skill-evolve聚类重复出现的轨迹发现。

Pitfalls

注意事项

Don't ask the sub-agent to make decisions. It summarizes evidence; you decide what to do. Sub-agents in chained recursion can drift if asked to plan.
Don't recurse on
confidence: high
. The whole point is to stop early when you have a clear answer.
Don't dump multiple artifacts to one sub-agent. One artifact per dispatch keeps the sub-agent focused and the JSON output reliable. Store each artifact under a separate
```
trajectory.<key>
```
in shared state.
Don't forget the recursion cap. 3 is the hard limit. If you find yourself wanting depth 4, your initial question was probably too vague — go back to step 1.
Skills do not chain. Sub-agents don't load this skill or any other; you must include the question and shared-state key reference in the sub-agent's prompt directly.
Don't run this skill inside Phase B (implementation). That's task-execution time, not introspection time. Save the diagnosis for the next session's Phase A1 (assess).

不要让子Agent做决策。它只总结证据；决策由你做出。如果要求递归链中的子Agent进行规划，可能会出现偏差。
当
confidence: high
时不要递归。核心目标是在得到明确答案时尽早停止。
不要将多个分析对象发送给一个子Agent。每次调度仅发送一个分析对象，可保持子Agent专注，且JSON输出更可靠。将每个分析对象存储在共享状态中单独的
```
trajectory.<key>
```
下。
不要忘记递归上限。3是硬限制。如果你想进行第4层递归，可能初始问题过于模糊——回到步骤1重新定义问题。
技能无法链式调用。子Agent不会加载本技能或其他任何技能；你必须在子Agent的提示语中直接包含问题和共享状态键的引用。
不要在阶段B（实施阶段）运行本技能。此阶段是任务执行时间，而非内省时间。将诊断工作留到下一个会话的A1阶段（评估）进行。

Verification

验证标准

A diagnosis is "good enough" when ALL of:

It names a concrete file/line/condition (not "something with the API")
It cites at least one specific run id or commit SHA
The suggested next attempt is different from what's already been tried (otherwise you'll just hit the same wall)
The total work used ≤3 sub-agent dispatches

If the diagnosis fails any of these, recurse one more time (within the cap) or accept the partial result and document the open question in

learnings.jsonl

当满足以下所有条件时，诊断结果即为“足够好”：

明确指出具体的文件/行/条件（而非“API相关问题”）
至少引用一个特定的运行ID或提交SHA
建议的下一步操作与已尝试的操作不同（否则会遇到相同的障碍）
总共使用了≤3次子Agent调度

如果诊断结果不满足任何一条，在限制范围内再递归一次，或者接受部分结果并在

learnings.jsonl

中记录未解决的问题。

What this skill deliberately does NOT do

本技能刻意不做的事情

Does not modify code. Diagnosis is the output. The actual fix is a normal task on a future evolve session — it's better to step away with the diagnosis written down and let the next session's planning agent decide whether to act on it.
Does not auto-create issues. If the diagnosis is worth filing, do it via
```
communicate
```
skill in the same session — but it's a separate decision, not part of this skill's procedure.
Does not write to
audit-log
branch. The branch is read-only from this skill's perspective.

不修改代码。诊断是输出结果。实际修复是未来evolve会话中的常规任务——最好先写下诊断结果，让下一个会话的规划Agent决定是否采取行动。
不自动创建问题。如果诊断结果值得创建问题，可在同一会话中通过
```
communicate
```
技能完成——但这是一个独立的决策，不属于本技能的操作流程。
不写入
audit-log
分支。从本技能的角度来看，该分支是只读的。

analyze-trajectory

Original

Translation

Analyze Trajectory

分析轨迹

When to use

使用场景

When NOT to use

不适用场景

Procedure

操作流程

1. Frame the question (single sentence)

1. 明确问题（单句表述）

2. Identify the artifact

2. 确定分析对象

3. Decide: direct read or sub-agent?

3. 决定：直接读取还是使用子Agent？

3.5. Handle large artifacts (token-aware chunking)

3.5. 处理大文件（基于Token的分块）

4. Dispatch a sub-agent (if needed)

4. 调度子Agent（如需）

1. Fetch the artifact into a shell variable

1. 将分析对象获取到shell变量中

2. Store it in shared state (the parent agent calls this directly)

2. 将其存储到共享状态（父Agent直接调用此命令）

5. Recurse if the sub-agent returns
`deeper_question`

5. 如果子Agent返回
`deeper_question`
则进行递归

6. Aggregate to a single diagnosis

6. 汇总为单一诊断结果

Pitfalls

注意事项

Verification

验证标准

What this skill deliberately does NOT do

本技能刻意不做的事情

analyze-trajectory

Original

Translation

Analyze Trajectory

分析轨迹

When to use

使用场景

When NOT to use

不适用场景

Procedure

操作流程

1. Frame the question (single sentence)

1. 明确问题（单句表述）

2. Identify the artifact

2. 确定分析对象

3. Decide: direct read or sub-agent?

3. 决定：直接读取还是使用子Agent？

3.5. Handle large artifacts (token-aware chunking)

3.5. 处理大文件（基于Token的分块）

4. Dispatch a sub-agent (if needed)

4. 调度子Agent（如需）

1. Fetch the artifact into a shell variable

1. 将分析对象获取到shell变量中

2. Store it in shared state (the parent agent calls this directly)

2. 将其存储到共享状态（父Agent直接调用此命令）

5. Recurse if the sub-agent returns deeper_question

5. 如果子Agent返回deeper_question则进行递归

6. Aggregate to a single diagnosis

6. 汇总为单一诊断结果

Pitfalls

注意事项

Verification

验证标准

What this skill deliberately does NOT do

本技能刻意不做的事情

5. Recurse if the sub-agent returns
`deeper_question`

5. 如果子Agent返回
`deeper_question`
则进行递归