@baoanaz/cviauto 0.6.5 → 0.6.8

package/dist/templates/common/bundled-skills/trellis-session-insight/references/triggering-patterns.md

@@ -1,12 +1,12 @@
-# Triggering Patterns
+# 触发模式
 
-Verbatim user phrasings that should make an AI reach for `cviauto mem`. Calibrate instinct against these — if a user message hits one of these patterns and you do not reach for `mem`, you probably missed an obvious recall.
+用户的确切表述，这些表述应使 AI 主动使用 `cviauto mem`。根据这些模式校准直觉——如果用户消息匹配其中某个模式而你却没有使用 `mem`，那你很可能错过了一次明显的回忆检索。
 
-Patterns are grouped by the *intent* behind the phrasing, not the surface words. The same intent shows up in different languages and registers.
+模式按表述背后的**意图**分组，而非表面用词。同一意图会以不同语言和语域出现。
 
-## Past-solution recall
+## 过往解决方案回忆
 
-The user is asking "how did we (or I) solve this before". Past dialogue holds the answer; the codebase shows the result but not the reasoning.
+用户正在问"我们（或我）之前是怎么解决这个的"。过往对话中存有答案；代码库展示了结果而非推理过程。
 
 - "How did we solve this last time?"
 - "What did we end up doing about X?"
@@ -15,11 +15,11 @@ The user is asking "how did we (or I) solve this before". Past dialogue holds th
 - "之前是怎么搞定 X 的?"
 - "我记得以前修过类似的"
 
-Reach: `cviauto mem search "<symptom keyword>" --global --limit 10`, then `context` into the hit that looks closest.
+操作：`cviauto mem search "<症状关键词>" --global --limit 10`，然后对看起来最匹配的命中结果执行 `context`。
 
-## Decision retrieval
+## 决策检索
 
-The user is referencing a decision that lives in old dialogue, not in any committed file. Look in brainstorm windows.
+用户正在引用一个存在于旧对话中、而非任何已提交文件中的决策。请在头脑风暴窗口中查找。
 
 - "What was the decision on X?"
 - "Did we decide to use Postgres or SQLite?"
@@ -28,11 +28,11 @@ The user is referencing a decision that lives in old dialogue, not in any commit
 - "关于 X 我们之前是怎么定的?"
 - "之前讨论过 X 的方案吗?"
 
-Reach: `cviauto mem search "<decision keyword>"` to find the session, then `extract <id> --phase brainstorm` to recover the discussion.
+操作：`cviauto mem search "<决策关键词>"` 找到会话，然后 `extract <id> --phase brainstorm` 恢复讨论内容。
 
-## Cross-session continuation
+## 跨会话续接
 
-The user resumed work after a gap and the context is implicit.
+用户在间隔一段时间后恢复工作，上下文是隐式的。
 
 - "Where were we?"
 - "Continue from last time."
@@ -41,11 +41,11 @@ The user resumed work after a gap and the context is implicit.
 - "我们上次做到哪了"
 - "接着昨天那个任务"
 
-Reach: `cviauto mem list --task <current-task-dir>` to find the most recent sessions tied to the active task, then `extract` the last one.
+操作：`cviauto mem list --task <current-task-dir>` 找到与当前任务关联的最近会话，然后 `extract` 最后一个。
 
-## Familiar-bug debugging
+## 熟悉 bug 排查
 
-The current bug feels like one already seen. Past sessions probably hold the resolution path.
+当前的 bug 感觉像是之前遇到过的。过往会话中很可能保存了解决路径。
 
 - "I feel like I've hit this before."
 - "Doesn't this look like that bug from last month?"
@@ -54,11 +54,11 @@ The current bug feels like one already seen. Past sessions probably hold the res
 - "这个 bug 是不是上次那个?"
 - "怎么又是这个 error?"
 
-Reach: `cviauto mem search "<error message fragment>" --global`. Anchor on a short, distinctive token from the actual error string.
+操作：`cviauto mem search "<错误信息片段>" --global`。从实际错误字符串中锚定一个短小、有辨识度的 token。
 
-## Self-pattern spotting
+## 自我模式识别
 
-The user is asking whether they keep repeating the same kind of mistake or decision.
+用户正在问自己是否在反复犯同类错误或做同类决策。
 
 - "Do I always make this mistake?"
 - "How often have I run into X?"
@@ -67,11 +67,11 @@ The user is asking whether they keep repeating the same kind of mistake or decis
 - "我老犯这个错?"
 - "这类问题之前出现过几次?"
 
-Reach: `cviauto mem search "<topic>" --global --limit 50` and scan the dates / projects in the listing. Optionally `extract` two or three for comparison.
+操作：`cviauto mem search "<话题>" --global --limit 50` 并浏览列表中的日期/项目。可选地对两三个结果执行 `extract` 进行比较。
 
-## Finish-work retrospective (on demand)
+## 完成工作复盘（按需）
 
-The user explicitly wants to look back at this task — not as a forced step, only when they ask.
+用户明确希望回顾本次任务——不是强制步骤，仅在用户要求时执行。
 
 - "Summarize what we did in this task."
 - "What were the key decisions / surprises?"
@@ -80,14 +80,14 @@ The user explicitly wants to look back at this task — not as a forced step, on
 - "记一下这次踩的坑"
 - "复盘下这个任务"
 
-Reach: identify the current task's session id (from `.cviauto/.runtime/sessions/*.json` or `mem list --task <task-dir>`), then `extract <id> --phase brainstorm` and `--phase implement`. Present a summary — surface concrete file:line citations where possible. Whether to also write the summary somewhere (PRD, spec, notes file) is the user's call; offer, don't auto-write.
+操作：识别当前任务的会话 ID（从 `.cviauto/.runtime/sessions/*.json` 或 `mem list --task <task-dir>`），然后 `extract <id> --phase brainstorm` 和 `--phase implement`。给出摘要——尽可能提供具体的文件:行号引用。是否将摘要写入某处（PRD、spec、笔记文件）由用户决定；主动提议，不要自动写入。
 
-## Anti-patterns: do NOT reach for `mem` here
+## 反模式：不要在以下场景使用 `mem`
 
-- "What does this function do?" → read the file.
-- "Why is this test failing?" → read the test output and the file.
-- "What's the right pattern for X in our codebase?" → grep / read spec files.
-- "What's the latest npm version of Y?" → call `npm view`.
-- "Fix this bug." → debug. Reach for `mem` only if you suspect prior context exists; otherwise it is noise.
+- "这个函数是做什么的？" → 读取文件。
+- "这个测试为什么失败？" → 读取测试输出和文件。
+- "我们代码库中 X 的正确模式是什么？" → grep / 读取 spec 文件。
+- "Y 的最新 npm 版本是什么？" → 调用 `npm view`。
+- "修复这个 bug。" → 调试。只有在你怀疑存在先验上下文时才使用 `mem`；否则它只是噪音。
 
-The bar stays: would a senior teammate ask "didn't we already talk about this?" before answering? If yes, reach for `mem`. If no, don't.
+判断标准始终是：在回答之前，一个资深同事会问"我们之前不是讨论过这个吗？" 如果是，就使用 `mem`。如果不是，就不要用。

package/dist/templates/common/bundled-skills/trellis-spec-bootstrap/SKILL.md

@@ -3,39 +3,39 @@ name: cviauto-spec-bootstrap
 description: "Bootstrap project-specific Cviauto coding specs with a platform-neutral single-agent workflow. Use when creating or refreshing .cviauto/spec guidelines, analyzing a codebase with GitNexus, ABCoder, or source inspection, decomposing package/layer spec work, and writing real codebase-backed spec docs without placeholder text."
 ---
 
-# Cviauto Spec Bootstrap
+# Cviauto Spec 引导
 
-Use this skill to create or refresh `.cviauto/spec/` guidelines from the real codebase. One capable agent owns the full loop: analyze the repository, choose the spec boundaries, write the docs, and verify the result. The workflow does not depend on a specific host, CLI, or agent brand.
+使用此技能从真实代码库创建或刷新 `.cviauto/spec/` 指南。一个有能力 Agent 拥有完整循环：分析仓库、选择 spec 边界、编写文档、验证结果。此工作流不依赖特定的宿主、CLI 或 Agent 品牌。
 
-## Workflow
+## 工作流
 
-1. Confirm Cviauto is initialized and inspect the current `.cviauto/spec/` tree.
-2. Analyze the repository architecture with the best available tools: GitNexus, ABCoder, language tooling, and direct source reads.
-3. Decompose the spec work by package and layer only when that reflects the actual codebase.
-4. Fill or reshape the spec files with concrete patterns, file paths, examples, and anti-patterns from the project.
-5. Verify that the final specs are internally consistent and contain no template placeholders.
+1. 确认 Cviauto 已初始化并检查当前 `.cviauto/spec/` 树。
+2. 使用最佳可用工具分析仓库架构：GitNexus、ABCoder、语言工具和直接源码阅读。
+3. 仅在反映实际代码库时按 package 和 layer 分解 spec 工作。
+4. 用项目中的具体模式、文件路径、示例和反模式填充或重塑 spec 文件。
+5. 验证最终 spec 内部一致且不含模板占位符。
 
-## Reference Routing
+## 参考路由
 
-| Need | Read |
+| 需求 | 阅读 |
 |------|------|
-| Repository architecture analysis | [references/repository-analysis.md](references/repository-analysis.md) |
-| Spec work decomposition and task planning | [references/spec-task-planning.md](references/spec-task-planning.md) |
-| Writing high-signal Cviauto spec files | [references/spec-writing.md](references/spec-writing.md) |
-| GitNexus and ABCoder MCP setup | [references/mcp-setup.md](references/mcp-setup.md) |
-
-## Operating Rules
-
-- Treat templates as starting points, not contracts. Delete, rename, split, or add spec files when the repository calls for it.
-- Prefer source-backed rules over generic advice. Every important recommendation should point at a real file or repeated local pattern.
-- Keep execution single-owner by default. Optional helper agents are an implementation detail, not a requirement or user-visible dependency.
-- Do not write platform-specific instructions unless the target project already standardizes on that platform.
-- Do not leave placeholder text, empty headings, or copied boilerplate in `.cviauto/spec/`.
-
-## Done Criteria
-
-- `.cviauto/spec/` describes the project as it exists now.
-- Each relevant package or layer has practical coding guidance with real examples.
-- Non-applicable template sections are removed.
-- `index.md` files match the final spec file set.
-- Any required setup or analysis assumptions are documented in the relevant spec or task notes.
+| 仓库架构分析 | [references/repository-analysis.md](references/repository-analysis.md) |
+| Spec 工作分解与任务规划 | [references/spec-task-planning.md](references/spec-task-planning.md) |
+| 编写高信号 Cviauto spec 文件 | [references/spec-writing.md](references/spec-writing.md) |
+| GitNexus 和 ABCoder MCP 设置 | [references/mcp-setup.md](references/mcp-setup.md) |
+
+## 操作规则
+
+- 将模板视为起点，而非契约。当仓库需要时，删除、重命名、拆分或添加 spec 文件。
+- 优先基于源码的规则而非通用建议。每条重要建议都应指向真实文件或重复出现的本地模式。
+- 默认保持单执行者。可选的辅助 Agent 是实现细节，而非需求或用户可见的依赖。
+- 除非目标项目已标准化在该平台上，否则不编写平台特定指令。
+- 不在 `.cviauto/spec/` 中留占位符文本、空标题或复制的样板内容。
+
+## 完成标准
+
+- `.cviauto/spec/` 描述了项目当前的实际状态。
+- 每个相关 package 或 layer 都有包含真实示例的实用编码指导。
+- 不适用的模板部分已移除。
+- `index.md` 文件与最终 spec 文件集匹配。
+- 任何所需设置或分析假设已在相关 spec 或任务笔记中记录。

package/dist/templates/common/bundled-skills/trellis-spec-bootstrap/references/mcp-setup.md

@@ -1,57 +1,57 @@
-# MCP Setup
+# MCP 设置
 
-GitNexus and ABCoder are recommended when bootstrapping Cviauto specs because they expose architecture and AST context to the agent. They are tool choices, not platform requirements. Configure them through whatever MCP mechanism your agent host provides.
+GitNexus 和 ABCoder 是在引导 Cviauto 规格（spec）时推荐使用的工具，因为它们能向 agent 暴露架构和 AST 上下文。它们是工具选择，而非平台要求。请通过你的 agent 宿主提供的任何 MCP 机制来配置它们。
 
 ## GitNexus
 
-GitNexus builds a code knowledge graph from the repository. Use it for module boundaries, execution flows, dependency relationships, blast radius, and graph queries.
+GitNexus 从仓库构建代码知识图谱。用于模块边界、执行流程、依赖关系、影响范围（blast radius）和图查询。
 
-### Install and Index
+### 安装与索引
 
 ```bash
-# Run from the repository root.
+# 从仓库根目录运行。
 npx gitnexus analyze
 
-# Check index status.
+# 检查索引状态。
 npx gitnexus status
 
-# Re-index after code changes when the analysis is stale.
+# 代码变更后，当分析结果过时时重新索引。
 npx gitnexus analyze
 ```
 
-The index is written to `.gitnexus/`. Keep embeddings only if the project already uses them; otherwise a normal index is enough for spec bootstrapping.
+索引写入 `.gitnexus/` 目录。仅在项目已使用嵌入（embeddings）时才保留它们；否则，普通索引就足以支持 spec 引导。
 
-### MCP Server Command
+### MCP 服务器命令
 
-Use this server command in the host's MCP configuration:
+在宿主 MCP 配置中使用以下服务器命令：
 
 ```bash
 npx -y gitnexus mcp
 ```
 
-### Useful Tools
+### 常用工具
 
-| Tool | Purpose |
+| 工具 | 用途 |
 |------|---------|
-| `gitnexus_query` | Find execution flows and functional areas by concept |
-| `gitnexus_context` | Inspect callers, callees, references, and process participation for a symbol |
-| `gitnexus_impact` | Understand blast radius before changing a symbol |
-| `gitnexus_detect_changes` | Check changed symbols and affected flows before finishing |
-| `gitnexus_cypher` | Run direct graph queries |
-| `gitnexus_list_repos` | List indexed repositories |
+| `gitnexus_query` | 按概念查找执行流程和功能区域 |
+| `gitnexus_context` | 检查某个符号的调用者、被调用者、引用以及参与的执行流程 |
+| `gitnexus_impact` | 在修改某个符号之前了解其影响范围 |
+| `gitnexus_detect_changes` | 在完成前检查变更的符号和受影响的功能流程 |
+| `gitnexus_cypher` | 运行直接图查询 |
+| `gitnexus_list_repos` | 列出已索引的仓库 |
 
 ## ABCoder
 
-ABCoder parses code into UniAST and gives precise package, file, and node-level structure. Use it for signatures, type shapes, implementations, dependencies, and reverse references.
+ABCoder 将代码解析为 UniAST，并提供精确的包、文件和节点级结构。用于签名、类型形态、实现、依赖关系和反向引用。
 
-### Install
+### 安装
 
 ```bash
 go install github.com/cloudwego/abcoder@latest
 abcoder --help
 ```
 
-### Parse Repositories
+### 解析仓库
 
 ```bash
 abcoder parse /absolute/path/to/package \
@@ -60,31 +60,31 @@ abcoder parse /absolute/path/to/package \
   --output ~/abcoder-asts
 ```
 
-For monorepos, parse each package with a stable `--name` so task notes can reference the same repository names.
+对于 monorepo，使用稳定的 `--name` 解析每个包，以便任务笔记可以引用相同的仓库名称。
 
-### MCP Server Command
+### MCP 服务器命令
 
-Use this server command in the host's MCP configuration:
+在宿主 MCP 配置中使用以下服务器命令：
 
 ```bash
 abcoder mcp ~/abcoder-asts
 ```
 
-### Useful Tools
+### 常用工具
 
-| Tool | Layer | Purpose |
+| 工具 | 层级 | 用途 |
 |------|-------|---------|
-| `list_repos` | 1 | List parsed repositories |
-| `get_repo_structure` | 2 | Inspect packages and files |
-| `get_package_structure` | 3 | Inspect nodes within a package |
-| `get_file_structure` | 3 | Inspect functions, classes, types, and signatures in a file |
-| `get_ast_node` | 4 | Retrieve code, dependencies, references, and implementations |
+| `list_repos` | 1 | 列出已解析的仓库 |
+| `get_repo_structure` | 2 | 检查包和文件 |
+| `get_package_structure` | 3 | 检查包内的节点 |
+| `get_file_structure` | 3 | 检查文件中的函数、类、类型和签名 |
+| `get_ast_node` | 4 | 检索代码、依赖关系、引用和实现 |
 
-## Verification
+## 验证
 
-After configuration, verify from the agent host that both MCP servers are visible. Then run one simple query against each server before starting the spec writing pass.
+配置完成后，从 agent 宿主验证两个 MCP 服务器均可见。然后在开始 spec 编写之前，对每个服务器运行一个简单查询。
 
 ```bash
 ls .gitnexus/meta.json
 ls ~/abcoder-asts/*.json
-```
+```

package/dist/templates/common/bundled-skills/trellis-spec-bootstrap/references/repository-analysis.md

@@ -1,30 +1,30 @@
-# Repository Analysis
+# 仓库分析
 
-The goal is to discover the project's real architecture before writing rules. Do not start from generic spec templates and fill blanks. Start from the code, then let the spec structure follow.
+目标是在编写规则之前发现项目的真实架构。不要从通用 spec 模板开始填空，而应从代码出发，让 spec 结构跟随代码。
 
-## Analysis Order
+## 分析顺序
 
-1. Read the existing `.cviauto/spec/` tree and note which files are templates, outdated, or already project-specific.
-2. Inspect package manifests, build scripts, workspace config, and top-level documentation to identify packages and runtime layers.
-3. Use GitNexus for execution flows, module clusters, dependency hubs, and impact-sensitive areas.
-4. Use ABCoder or language-native tooling for exact signatures, types, class boundaries, and implementation examples.
-5. Read representative source and test files directly before turning any finding into a spec rule.
+1. 阅读现有的 `.cviauto/spec/` 目录树，注意哪些文件是模板、哪些已过时、哪些已针对项目定制。
+2. 检查包清单、构建脚本、工作区配置和顶层文档，以识别包和运行时分层。
+3. 使用 GitNexus 获取执行流程、模块集群、依赖枢纽和影响敏感区域。
+4. 使用 ABCoder 或语言原生工具获取精确的签名、类型、类边界和实现示例。
+5. 在将任何发现转化为 spec 规则之前，直接阅读有代表性的源文件和测试文件。
 
-## What To Capture
+## 需要捕获的内容
 
-| Area | Questions |
+| 领域 | 要回答的问题 |
 |------|-----------|
-| Package boundaries | What does each package own? What imports cross boundaries? |
-| Runtime layers | Which code is CLI, backend, frontend, worker, shared library, test-only, or tooling? |
-| Core abstractions | Which types, services, stores, commands, routes, or adapters define the system shape? |
-| Data flow | Where does user input enter, how is it validated, and where does state persist? |
-| Error handling | How are failures represented, logged, surfaced, and tested? |
-| Configuration | Where do defaults, environment config, generated files, and templates live? |
-| Tests | Which test styles are trusted examples for new work? |
+| 包边界 | 每个包拥有什么？哪些导入跨越了边界？ |
+| 运行时分层 | 哪些代码是 CLI、后端、前端、worker、共享库、仅测试代码或工具？ |
+| 核心抽象 | 哪些类型、服务、存储、命令、路由或适配器定义了系统形态？ |
+| 数据流 | 用户输入从哪里进入，如何验证，状态在哪里持久化？ |
+| 错误处理 | 失败如何表示、记录、暴露和测试？ |
+| 配置 | 默认值、环境配置、生成文件和模板分别存放在哪里？ |
+| 测试 | 哪些测试风格可以作为新工作的可信范例？ |
 
-## GitNexus Usage
+## GitNexus 用法
 
-Start broad, then inspect specific symbols:
+从宽泛入手，然后检查具体符号：
 
 ```text
 gitnexus_query({query: "CLI command execution flow"})
@@ -33,11 +33,11 @@ gitnexus_context({name: "SymbolName"})
 gitnexus_cypher({query: "MATCH (n)-[r]->(m) RETURN n.name, type(r), m.name LIMIT 30"})
 ```
 
-Use GitNexus results to find important files and flows. Do not quote graph output as the final authority until you have checked the relevant source files.
+使用 GitNexus 结果来查找重要文件和流程。在检查相关源文件之前，不要将图输出作为最终权威。
 
-## ABCoder Usage
+## ABCoder 用法
 
-Use ABCoder when the spec needs exact code shapes:
+当 spec 需要精确的代码形态时使用 ABCoder：
 
 ```text
 list_repos()
@@ -46,14 +46,14 @@ get_file_structure({repo_name: "package-name", file_path: "src/example.ts"})
 get_ast_node({repo_name: "package-name", node_ids: [{mod_path: "...", pkg_path: "...", name: "SymbolName"}]})
 ```
 
-ABCoder is most valuable for documenting constructor patterns, function signatures, type contracts, and reference chains.
+ABCoder 在记录构造器模式、函数签名、类型契约和引用链时最有价值。
 
-## Analysis Notes
+## 分析笔记
 
-Keep short notes while analyzing. The notes should include:
+分析时保持简短记录。笔记应包含：
 
-- Package or layer name.
-- Files that define the local pattern.
-- Rules the spec should teach.
-- Anti-patterns found in old code, comments, tests, or migration paths.
-- Spec files that should be created, deleted, renamed, or merged.
+- 包或层名称。
+- 定义了本地模式的文件。
+- spec 应教授的规则。
+- 在旧代码、注释、测试或迁移路径中发现的的反模式（anti-pattern）。
+- 应创建、删除、重命名或合并的 spec 文件。

package/dist/templates/common/bundled-skills/trellis-spec-bootstrap/references/spec-task-planning.md

@@ -1,61 +1,61 @@
-# Spec Task Planning
+# Spec 任务规划
 
-Use a single agent as the default execution model. The agent may create Cviauto tasks for traceability, but the skill should not require a specific platform, CLI, or parallel worker model.
+使用单个 agent 作为默认执行模型。agent 可以创建 Cviauto 任务以便追踪，但此 skill 不应要求特定平台、CLI 或并行 worker 模型。
 
-## Decomposition
+## 分解
 
-Create spec work units around real ownership boundaries:
+围绕真实的归属边界创建 spec 工作单元：
 
-- One package when a package has its own conventions.
-- One layer when the same package has distinct frontend, backend, CLI, worker, or shared-library rules.
-- One cross-cutting guide when a pattern spans packages and is not owned by one layer.
+- 当一个包有自己的约定时，作为一个工作单元。
+- 当同一个包有独立的前端、后端、CLI、worker 或共享库规则时，每个层作为一个工作单元。
+- 当某个模式跨越多个包且不属于某个层时，作为一个跨领域指南。
 
-Avoid artificial decomposition. A small library usually needs one focused spec pass, not several tasks.
+避免人为分解。一个小型库通常只需要一次集中的 spec 编写，而不是多个任务。
 
-## Task Shape
+## 任务形态
 
-When a Cviauto task is useful, write a concise PRD with these sections:
+当 Cviauto 任务有用时，编写一份简洁的 PRD，包含以下章节：
 
 ```markdown
-# Fill <package-or-layer> Cviauto Specs
+# 填写 <包或层名称> Cviauto Specs
 
-## Goal
-Write project-specific `.cviauto/spec/` guidance for <scope>.
+## 目标（Goal）
+为 <范围> 编写项目特定的 `.cviauto/spec/` 指导。
 
-## Scope
-- Spec directory:
-- Source directories to inspect:
-- Tests to inspect:
-- Out of scope:
+## 范围（Scope）
+- Spec 目录：
+- 需要检查的源目录：
+- 需要检查的测试：
+- 超出范围：
 
-## Architecture Context
-Summarize the concrete findings from repository analysis.
+## 架构上下文（Architecture Context）
+汇总仓库分析中的具体发现。
 
-## Files To Create Or Update
+## 需要创建或更新的文件
 - `.cviauto/spec/.../index.md`
 - `.cviauto/spec/.../<topic>.md`
 
-## Rules
-- Adapt the spec file set to the real codebase.
-- Use real source examples with file paths.
-- Remove template-only sections that do not apply.
-- Do not modify product source code unless the task explicitly asks for it.
-
-## Acceptance Criteria
-- [ ] Specs contain concrete examples and anti-patterns from the repository.
-- [ ] No placeholder text remains.
-- [ ] Index files match the final spec files.
-- [ ] Claims are backed by source files, tests, or project docs.
+## 规则
+- 让 spec 文件集适配真实代码库。
+- 使用带有文件路径的真实源码示例。
+- 删除不适用的纯模板章节。
+- 除非任务明确要求，否则不要修改产品源代码。
+
+## 验收标准（Acceptance Criteria）
+- [ ] Spec 包含来自仓库的具体示例和反模式。
+- [ ] 没有残留的占位文本。
+- [ ] 索引文件与实际 spec 文件匹配。
+- [ ] 所有声明都有源文件、测试或项目文档作为支撑。
 ```
 
-## Optional Helper Agents
+## 可选的辅助 Agent
 
-If the host supports subagents, helpers can inspect independent packages or run verification. They are optional. The main agent still owns integration and final quality.
+如果宿主支持子 agent，辅助 agent 可以检查独立的包或运行验证。它们是可选的。主 agent 仍然负责集成和最终质量。
 
-Helper tasks must have clear ownership:
+辅助任务必须有明确的归属：
 
-- Read-only research tasks may inspect any source needed for the assigned scope.
-- Write tasks should own disjoint spec directories.
-- Verification tasks should check placeholder removal, broken links, and consistency.
+- 只读研究任务可以检查分配给其范围内的任何源文件。
+- 写入任务应拥有互不重叠的 spec 目录。
+- 验证任务应检查占位符残留、断链和一致性。
 
-Do not encode helper-agent names, vendor-specific commands, or platform-specific routing in the skill. Put only the required work and acceptance criteria in the task.
+不要在 skill 中硬编码辅助 agent 名称、供应商特定命令或平台特定路由。在任务中只放入所需的工作和验收标准。

package/dist/templates/common/bundled-skills/trellis-spec-bootstrap/references/spec-writing.md

@@ -1,70 +1,70 @@
-# Spec Writing
+# Spec 编写
 
-Cviauto specs are coding guidance for future agents. They should explain how to work in this repository, not how a generic project might be organized.
+Cviauto spec 是面向未来 agent 的编码指导。它们应当解释如何在这个仓库中工作，而不是描述一个通用项目可能如何组织。
 
-## Write From Evidence
+## 基于证据编写
 
-Each important rule should be backed by one of these:
+每条重要规则都应得到以下内容之一的支持：
 
-- A source file that demonstrates the preferred pattern.
-- A test file that shows expected behavior.
-- A project document that defines the convention.
-- A repeated pattern across multiple files.
+- 一个展示了首选模式的源文件。
+- 一个展示了预期行为的测试文件。
+- 一个定义了该约定的项目文档。
+- 跨多个文件重复出现的模式。
 
-Use short snippets only when they make the rule clearer. Prefer linking to the file path and naming the symbol or behavior.
+仅在能使规则更清晰时使用简短代码片段。优先链接到文件路径并命名符号或行为。
 
-## File Structure
+## 文件结构
 
-Keep the spec tree aligned with the project:
+保持 spec 目录树与项目对齐：
 
-- Keep `index.md` as the navigation file for the spec directory.
-- Split topics when developers would look for them independently.
-- Merge topics when separate files would repeat the same rule.
-- Delete template files that do not apply.
-- Add new files for important local patterns the template missed.
+- 保留 `index.md` 作为 spec 目录的导航文件。
+- 当开发者会独立查找某个主题时，将其拆分。
+- 当独立文件会重复同一规则时，将主题合并。
+- 删除不适用的模板文件。
+- 为模板遗漏的重要本地模式添加新文件。
 
-## Content Standards
+## 内容标准
 
-Good spec sections include:
+好的 spec 章节应包含：
 
-- When the rule applies.
-- The local pattern to follow.
-- The source or test files that prove the pattern.
-- Common mistakes or anti-patterns.
-- Verification commands or checks when they are specific and reliable.
+- 规则适用的场景。
+- 应遵循的本地模式。
+- 证明该模式的源文件或测试文件。
+- 常见错误或反模式。
+- 当具体可靠时，提供验证命令或检查方法。
 
-Avoid:
+应避免：
 
-- Placeholder prose.
-- Generic framework advice.
-- Tool instructions that only work in one agent host.
-- Long copied code blocks.
-- Rules based on a single accidental implementation detail.
+- 占位文字。
+- 通用框架建议。
+- 仅在某个 agent 宿主中有效的工具指令。
+- 大段复制的代码块。
+- 基于单个偶然实现细节的规则。
 
-## Example Shape
+## 示例形态
 
 ```markdown
-## Command Handlers
+## 命令处理器（Command Handlers）
 
-Command handlers should keep argument parsing, validation, and side effects separate. The local pattern is:
+命令处理器应将参数解析、验证和副作用分离。本地模式是：
 
-- Parse CLI flags at the command boundary.
-- Convert raw inputs into typed task options before invoking core logic.
-- Keep filesystem writes in the command or service layer, not in template helpers.
+- 在命令边界解析 CLI 标志。
+- 在调用核心逻辑之前，将原始输入转换为类型化的任务选项。
+- 将文件系统写入保留在命令层或服务层，而非模板辅助函数中。
 
-Reference files:
+参考文件：
 - `packages/cli/src/commands/example.ts`
 - `packages/cli/test/commands/example.test.ts`
 
-Avoid passing raw `process.argv` or unvalidated config objects into shared helpers.
+避免将原始 `process.argv` 或未验证的配置对象传递给共享辅助函数。
 ```
 
-## Final Pass
+## 最终检查
 
-Before finishing:
+完成前：
 
 ```bash
 grep -R "To be filled\\|TODO: fill\\|placeholder" .cviauto/spec
 ```
 
-Also check links, index files, and whether any spec still describes a template rather than this repository.
+同时检查链接、索引文件，以及是否有 spec 仍然描述模板而非本仓库。