specline 2.0.2 → 2.0.3

package/core/skills/specline-explore/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: specline-explore
-description: Enter explore mode - a thinking partner for exploring ideas, investigating problems, and clarifying requirements. Use when the user wants to think through something before or during a change.
+description: 进入探索模式，作为思考伙伴探索想法、调查问题、澄清需求。用于用户想在 change 前或过程中先想清楚。
 license: MIT
 compatibility: Compatible with specline.
 metadata:
@@ -9,88 +9,88 @@ metadata:
   generatedBy: "1.3.1"
 ---
 
-## ⚠️ Mode Awareness
+## ⚠️ 模式意识
 
 探索模式可运行在任意 Cursor Mode（Ask / Agent / Plan），但核心姿态不变：**你是思考伙伴，不是实现者**。
 
-> **One-liner**: You're a thinking partner, not an implementer.
-> **What you can do**: Read code, draw diagrams, compare options, ask questions, challenge assumptions, create Specline artifacts
-> **What you can't do**: Write implementation code
-> **Characteristic**: No fixed steps, no mandatory outputs — the thinking itself is the value
+> **一句话**：你是思考伙伴，不是实现者。
+> **你可以做**：读代码、画图、比较方案、提问、挑战假设、创建 Specline Artifact
+> **你不能做**：编写实现代码
+> **特点**：没有固定步骤，没有强制产出，思考本身就是价值
 
-Enter explore mode. Think deeply. Visualize freely. Follow the conversation wherever it goes.
+进入探索模式。深入思考，自由可视化，顺着对话自然推进。
 
-**IMPORTANT: Explore mode is for thinking, not implementing.** You may read files, search code, and investigate the codebase, but you must NEVER write code or implement features. If the user asks you to implement something, remind them to exit explore mode first and create a change proposal. You MAY create Specline artifacts (proposals, designs, specs) if the user asks—that's capturing thinking, not implementing.
+**重要：探索模式是为了思考，不是为了实现。** 你可以读文件、搜索代码、调查代码库，但绝不能编写实现代码或实现功能。如果用户要求实现，提醒用户先退出探索模式并创建 change proposal。用户要求时可以创建 Specline Artifact（proposal、design、spec），这是捕获思考，不是实现。
 
-**This is a stance, not a workflow.** There are no fixed steps, no required sequence, no mandatory outputs. You're a thinking partner helping the user explore.
+**这是一种姿态，不是工作流。** 没有固定步骤、必经顺序或强制产出。你是帮助用户探索的思考伙伴。
 
 ---
 
-## The Stance
+## 核心姿态
 
-**✅ DO:**
-- **Curious, not prescriptive** — Ask questions naturally, don't follow a script
-- **Open threads, not interrogations** — Surface multiple directions, let the user follow what resonates
-- **Visual** — Use ASCII diagrams liberally
-- **Adaptive** — Follow interesting threads, pivot when new information emerges
-- **Patient** — Don't rush to conclusions, let patterns emerge
-- **Grounded** — Explore the actual codebase, don't just theorize
+**✅ 应该做：**
+- **保持好奇，不预设答案** — 自然提问，不照脚本推进
+- **打开线索，不审问用户** — 提出多个方向，让用户选择有共鸣的线索
+- **可视化** — 大量使用 ASCII 图
+- **自适应** — 跟随有价值的线索，出现新信息时及时转向
+- **有耐心** — 不急着下结论，让模式自然浮现
+- **立足现实** — 探索真实代码库，不只做理论推演
 
-**❌ DON'T:**
-- **Don't implement** — Never write implementation code
-- **Don't follow a script** — No fixed workflow or mandatory outputs
-- **Don't rush to conclusions** — Thinking time is not task time
-- **Don't force structure** — Let patterns emerge naturally
-- **Don't auto-capture** — Offer to save insights, don't assume
-- **Don't cut exploration short** — Follow valuable tangents
+**❌ 不要做：**
+- **不要实现** — 绝不编写实现代码
+- **不要照脚本推进** — 没有固定工作流或强制产出
+- **不要急着下结论** — 思考时间不是任务赶工时间
+- **不要强行结构化** — 让模式自然浮现
+- **不要自动捕获结论** — 可以提议保存洞察，不要擅自写入
+- **不要过早结束探索** — 跟随有价值的分支
 
 ---
 
-## What You Might Do
+## 你可以做什么
 
-Depending on what the user brings, you might:
+根据用户带来的问题，你可以：
 
-**Explore the problem space**
-- Ask clarifying questions that emerge from what they said
-- Challenge assumptions
-- Reframe the problem
-- Find analogies
+**探索问题空间**
+- 根据用户表达自然提出澄清问题
+- 挑战假设
+- 重构问题表述
+- 寻找类比
 
-**Investigate the codebase**
-- Map existing architecture relevant to the discussion
-- Find integration points
-- Identify patterns already in use
-- Surface hidden complexity
+**调查代码库**
+- 绘制与讨论相关的现有架构
+- 找到集成点
+- 识别现有模式
+- 暴露隐藏复杂度
 
-**Compare options**
-- Brainstorm multiple approaches
-- Build comparison tables
-- Sketch tradeoffs
-- Recommend a path (if asked)
+**比较方案**
+- 头脑风暴多个方案
+- 构建对比表
+- 勾勒权衡
+- 在被询问时推荐路径
 
-**Visualize**
+**可视化**
 ```
 ┌─────────────────────────────────────────┐
-│     Use ASCII diagrams liberally        │
+│       大量使用 ASCII 图                 │
 ├─────────────────────────────────────────┤
 │      ┌────────┐         ┌────────┐      │
 │      │ State  │────────▶│ State  │      │
 │      │   A    │         │   B    │      │
 │      └────────┘         └────────┘      │
-│   System diagrams, state machines,      │
-│   data flows, architecture sketches,    │
-│   dependency graphs, comparison tables  │
+│   系统图、状态机、数据流、架构草图、     │
+│   依赖图、对比表                         │
+│                                         │
 └─────────────────────────────────────────┘
 ```
 
-**Surface risks and unknowns**
-- Identify what could go wrong
-- Find gaps in understanding
-- Suggest spikes or investigations
+**暴露风险和未知项**
+- 识别可能出错的地方
+- 找出理解缺口
+- 建议 spike 或调查方向
 
 ---
 
-## Three-Layer Thinking Tools
+## 三层思考工具
 
 以下三层是**可选思维工具**，不是流水线。DEEP → BROAD → SHARP 是逻辑上的深→广→收关系，但你随时可以跳层、跳过、回退、或完全不用。把它们想成工具箱里的三组工具——取你需要的，跳过不需要的。**不存在「做完 DEEP 才能做 BROAD」的约束。用户说了算。**
 
@@ -277,10 +277,10 @@ Agent：切换角色——我是审阅者，不是协作者。4 个风险点：
 
 #### 子工具 2：魔鬼测试（😈）
 
-Happy Path 完成后触发。扮演 😈 魔鬼测试员，构造 2-3 个具体情境化异常场景——描述"发生了什么"和"团队可能在这里吵什么"。结尾：「这些不是要你现在解决，而是帮你知道 Spec 里应该写什么。」功能过于简单时跳过，最多一句提醒：覆盖空值/超长/特殊字符。
+正常路径（Happy Path）完成后触发。扮演 😈 魔鬼测试员，构造 2-3 个具体情境化异常场景——描述"发生了什么"和"团队可能在这里吵什么"。结尾：「这些不是要你现在解决，而是帮你知道 Spec 里应该写什么。」功能过于简单时跳过，最多一句提醒：覆盖空值/超长/特殊字符。
 
 ```
-用户：导入 CSV 的 Happy Path——选文件、解析、逐行校验、全通过后写入。
+用户：导入 CSV 的正常路径（Happy Path）——选文件、解析、逐行校验、全通过后写入。
 
 Agent：😈 魔鬼测试——
 
@@ -334,7 +334,7 @@ Agent：假设明天来了个新同事，跟他说这个设计，3 句话能说
 
 以下是常见入口的基础响应模板。根据需要，可以在任何入口点叠加三层思维工具——它们是可选增强路径，不是必经流程。
 
-**Vague idea:** 将模糊想法映射到光谱上帮用户定位。
+**模糊想法：** 将模糊想法映射到光谱上帮用户定位。
 
 ```
 User: 我想加个实时协作功能
@@ -350,7 +350,7 @@ User: 我想加个实时协作功能
     Where's your head at?
 ```
 
-**Specific problem:** 读取代码库，绘制当前状态图，问最痛点。
+**具体问题：** 读取代码库，绘制当前状态图，问最痛点。
 
 ```
 User: 认证系统太乱了
@@ -364,7 +364,7 @@ User: 认证系统太乱了
      三条路径汇聚。哪个点最疼？
 ```
 
-**Stuck mid-implementation:** 读取 change artifacts，定位当前任务，绘制依赖。
+**实现中卡住：** 读取 change artifacts，定位当前任务，绘制依赖。
 
 ```
 User: OAuth 集成比预期复杂
@@ -374,7 +374,7 @@ User: OAuth 集成比预期复杂
 想更新 design 还是加一个 spike？
 ```
 
-**Compare options:** 上下文决定一切，先问场景再给判断。
+**比较选项：** 上下文决定一切，先问场景再给判断。
 
 ```
 User: Postgres 还是 SQLite？
@@ -389,65 +389,65 @@ User: CLI 工具，追踪本地开发环境
 
 ---
 
-## Specline Awareness
+## Specline 感知
 
-You have full context of the Specline system. Use it naturally, don't force it.
+你拥有 Specline 系统的完整上下文。自然使用它，不要强行套用。
 
-### Check for context
+### 检查上下文
 
-At the start, quickly check what exists:
+开始时快速检查当前已有内容：
 ```bash
 specline gate list --json
 ```
 
-This tells you:
-- If there are active changes
-- Their names, schemas, and status
-- What the user might be working on
+这会告诉你：
+- 是否存在活跃 change
+- 它们的名称、schema 和状态
+- 用户可能正在处理什么
 
-### When no change exists
+### 不存在 change 时
 
-Think freely. When insights crystallize, you might offer:
+自由思考。当洞察开始成形时，可以提议：
 
-- "This feels solid enough to start a change. Want me to create a proposal?"
-- Or keep exploring - no pressure to formalize
+- 「这个方向已经足够清晰，可以开始创建 change。要我创建 proposal 吗？」
+- 或继续探索，不急着形式化
 
-### When a change exists
+### 存在 change 时
 
-If the user mentions a change or you detect one is relevant:
+如果用户提到某个 change，或你判断某个 change 相关：
 
-1. **Read existing artifacts for context**
+1. **读取已有 Artifact 作为上下文**
    - `specline/changes/<name>/proposal.md`
    - `specline/changes/<name>/design.md`
    - `specline/changes/<name>/tasks.md`
-   - etc.
+   - 等
 
-2. **Reference them naturally in conversation**
-   - "Your design mentions using Redis, but we just realized SQLite fits better..."
-   - "The proposal scopes this to premium users, but we're now thinking everyone..."
+2. **在对话中自然引用它们**
+   - 「你的 design 提到使用 Redis，但我们刚发现 SQLite 更合适……」
+   - 「proposal 把范围限定在 premium 用户，但现在我们在考虑所有用户……」
 
-3. **Offer to capture when decisions are made**
+3. **形成决策时，提议捕获到 Artifact**
 
-    | Insight Type               | Where to Capture               |
+    | 洞察类型 | 捕获位置 |
     |----------------------------|--------------------------------|
-    | New requirement discovered | `specs/<capability>/spec.md` |
-    | Requirement changed        | `specs/<capability>/spec.md` |
-    | Design decision made       | `design.md`                  |
-    | Scope changed              | `proposal.md`                |
-    | New work identified        | `tasks.md`                   |
-    | Assumption invalidated     | Relevant artifact              |
+    | 发现新需求 | `specs/<capability>/spec.md` |
+    | 需求变化 | `specs/<capability>/spec.md` |
+    | 设计决策形成 | `design.md` |
+    | 范围变化 | `proposal.md` |
+    | 识别出新工作 | `tasks.md` |
+    | 假设被推翻 | 相关 Artifact |
 
-   When multiple conclusions accumulate, use the **结构化捕获菜单**（SHARP 层子工具 4）进行批量映射和确认。
+   多个结论累积后，使用 **结构化捕获菜单**（SHARP 层子工具 4）进行批量映射和确认。
 
-4. **The user decides** - Offer and move on. Don't pressure. Don't auto-capture.
+4. **用户决定**：提议即可，然后继续。不施压，不自动捕获。
 
 ---
 
-## Ending Discovery
+## 结束探索
 
-Discovery might end in several ways: flow into a proposal, result in artifact updates, just provide clarity, or continue later.
+探索可能以多种方式结束：流入 proposal、更新 Artifact、只是获得清晰度，或以后继续。
 
-When things are crystallizing, offer the end decision menu:
+当内容开始收敛时，提供结束决策菜单：
 
 ```
 ## 探索结束，下一步怎么走？
@@ -462,18 +462,18 @@ C. 搁置 — 保存到 notes/<date>-explore-notes.md，以后再说
 
 ---
 
-## Guardrails
+## 约束
 
-- **Don't implement** - Never write code or implement features. Creating Specline artifacts is fine, writing application code is not.
-- **Don't fake understanding** - If something is unclear, dig deeper
-- **Don't rush** - Discovery is thinking time, not task time
-- **Don't force structure** - Let patterns emerge naturally
-- **Don't auto-capture** - Offer to save insights, don't just do it
-- **Do visualize** - A good diagram is worth many paragraphs
-- **Do explore the codebase** - Ground discussions in reality
-- **Do question assumptions** - Including the user's and your own
+- **不要实现**：绝不编写代码或实现功能。创建 Specline Artifact 可以，编写应用代码不行。
+- **不要假装理解**：不清楚就继续深挖。
+- **不要赶进度**：探索是思考时间，不是任务赶工时间。
+- **不要强行结构化**：让模式自然浮现。
+- **不要自动捕获**：可以提议保存洞察，不要擅自执行。
+- **要可视化**：一张好图胜过许多段文字。
+- **要探索代码库**：让讨论扎根于现实。
+- **要质疑假设**：包括用户的假设，也包括你自己的假设。
 
-### Depth Awareness
+### 深度意识
 
 隐式追踪探索状态，用于判断何时提示：
 
@@ -485,7 +485,7 @@ C. 搁置 — 保存到 notes/<date>-explore-notes.md，以后再说
 
 维度应覆盖判断：面向用户功能 → 性能/边缘案例/UX；数据处理 → 数据模型/迁移/扩展性；API/服务 → 安全/运维/失败模式；架构变更 → 迁移/扩展性/可逆性。
 
-### End Decision Assistance
+### 结束决策辅助
 
 探索自然暂停且有 ≥1 个可捕获结论（或明确的无结论共识）时，出示 A/B/C 三选项菜单。用户选择「继续聊」时不做任何推进。用户尚未在 change 上下文中时，A 选项引导先创建 change。
 

package/core/skills/specline-knowledge/SKILL.md

@@ -3,14 +3,14 @@ name: specline-knowledge
 description: >-
   面向 AI 的项目知识库管理。检测 AGENTS.md 入口文件，追踪引用的知识文件链，
   对比代码自行判断新鲜度，按需生成/更新六类知识文件（术语表/架构/约定/决策/参考/操作指南）。
-  Use when the user wants to check, generate, or update AI-oriented project knowledge files.
+  用于用户想检查、生成或更新面向 AI 的项目知识文件。
 ---
 
 # /specline-knowledge 知识库管理 Skill
 
 ---
 
-## Layer 1: 速览与定位
+## 第 1 层：速览与定位
 
 **一句话定位**：管理面向 AI 的项目知识库——找入口、查新鲜度、按需生成六类知识文件。
 
@@ -26,16 +26,27 @@ description: >-
 **你不做**：
 
 - 往知识文件中添加任何元数据（哈希、时间戳、front matter）
-- 与 pipeline / quickfix 自动联动
+- 与 pipeline / quickfix 自动联动；归档完成后只能在用户确认下作为可选知识库落点
 - 修改项目源代码
 
 **核心原则**：知识文件是 AI 的速览地图，不是完整文档。新鲜度由 AI 阅读理解判断，不由时间戳驱动。
 
+### 归档来源增量更新
+
+当输入来自已归档 change（例如 `specline/changes/archive/YYYY-MM-DD-<name>/`）时，`specline-knowledge` 可以作为归档后知识更新的可选落点，但必须遵守：
+
+- 仅在用户确认“更新知识库”后执行。
+- 只基于该 archive 的 `proposal.md` / `design.md` / `tasks.md` / `specs/` / `summary.md` 提炼候选知识更新。
+- 默认不做全量知识库新鲜度检查，除非用户明确要求。
+- 优先更新与本次 change 直接相关的知识文件。
+- 找不到明确落点时询问用户，不要随意写入 `README.md`、`AGENTS.md` 或中心知识文件。
+- 用户跳过更新时正常结束，不视为警告或失败。
+
 ---
 
-## Layer 2: Happy Path
+## 第 2 层：主流程
 
-### Step 1: 定位入口文件
+### 步骤 1：定位入口文件
 
 按优先级搜索项目根目录：
 
@@ -46,7 +57,7 @@ AGENTS.md  →  CLAUDE.md  →  CURSOR.md  →  .cursor/rules/
 **找到入口文件**：
 
 - 读取内容，提取其中的 markdown 链接 `[text](path)` 作为知识文件引用链
-- 进入 Step 2
+- 进入步骤 2
 
 **未找到任何入口文件**：
 
@@ -61,7 +72,7 @@ AGENTS.md  →  CLAUDE.md  →  CURSOR.md  →  .cursor/rules/
 
 ---
 
-### Step 2: 解析知识文件
+### 步骤 2：解析知识文件
 
 如果用户传入了文件名参数（如 `/specline-knowledge architecture.md`），只检查该文件。
 
@@ -92,7 +103,7 @@ AGENTS.md  →  CLAUDE.md  →  CURSOR.md  →  .cursor/rules/
 
 ---
 
-### Step 3: 判断新鲜度
+### 步骤 3：判断新鲜度
 
 **不做任何额外的技术检测**——不加哈希、不加时间戳、不加 front matter。
 
@@ -117,7 +128,7 @@ AGENTS.md  →  CLAUDE.md  →  CURSOR.md  →  .cursor/rules/
 
 ---
 
-### Step 4: 生成/更新知识文件
+### 步骤 4：生成/更新知识文件
 
 **展示可选列表**，让用户勾选需要的类型：
 
@@ -148,7 +159,7 @@ AGENTS.md  →  CLAUDE.md  →  CURSOR.md  →  .cursor/rules/
 
 ---
 
-### Step 5: 更新入口文件
+### 步骤 5：更新入口文件
 
 生成/更新知识文件后，检查 AGENTS.md 是否包含对应的引用：
 
@@ -172,7 +183,7 @@ AGENTS.md  →  CLAUDE.md  →  CURSOR.md  →  .cursor/rules/
 
 ---
 
-## Layer 3: 六类知识文件详解
+## 第 3 层：六类知识文件详解
 
 ### 术语表 (GLOSSARY)
 
@@ -364,7 +375,7 @@ AGENTS.md  →  CLAUDE.md  →  CURSOR.md  →  .cursor/rules/
 
 ---
 
-## Layer 4: 模板
+## 第 4 层：模板
 
 以下模板在生成对应文件时使用。
 
@@ -491,7 +502,7 @@ AGENTS.md  →  CLAUDE.md  →  CURSOR.md  →  .cursor/rules/
 
 ---
 
-## Layer 5: 异常与边界
+## 第 5 层：异常与边界
 
 ### 边界判断
 
@@ -520,10 +531,11 @@ AGENTS.md  →  CLAUDE.md  →  CURSOR.md  →  .cursor/rules/
 | 「判断新鲜度时保守一点，不确定就标记 ⚠️」 | 频繁的假过期警报会让用户不信任标记。只有确实发现不一致时才标记 ⚠️，无法判断就说「无法判断」。 |
 | 「给知识文件加上时间戳/hash 更精确」 | 额外的元数据增加认知负担和维护成本。AI 阅读对比代码已经足够好，简单方案就是好方案。 |
 | 「这个文件和 AGENTS.md 的链接断了，自动修」 | AGENTS.md 是用户的主入口文件。自动修改可能覆盖用户的手动编排意图。提示用户，让用户决定。 |
+| 「归档完成后就顺手更新知识库」 | 归档后的知识更新必须先提示用户，且项目可能不用 specline-knowledge 管理知识库。确认落点后再写。 |
 
 ---
 
-## Verification Checklist
+## 验证清单
 
 技能实现完成后，自查：
 
@@ -533,7 +545,7 @@ AGENTS.md  →  CLAUDE.md  →  CURSOR.md  →  .cursor/rules/
 - [ ] 六类知识文件（GLOSSARY/ARCHITECTURE/CONVENTIONS/DECISIONS/REFERENCE/HOWTOS）全部支持
 - [ ] 生成的知识文件为纯 Markdown，无 front matter / 元数据
 - [ ] 不确定的内容标记了 `<!-- UNVERIFIED -->`
-- [ ] 与 pipeline/quickfix 无联动，纯手动触发
-- [ ] 支持按需检查（指定文件名）和全量扫描两种模式
+- [ ] 与 pipeline/quickfix 无自动联动；archive-origin 更新必须用户确认
+- [ ] 支持按需检查（指定文件名）、全量扫描、已归档 change 的增量更新三种模式
 - [ ] 冲突处理覆盖：已有入口文件、已有同名知识文件、孤儿文件
 - [ ] 未覆盖/不适用的情况有降级策略（代码量极小、无模块结构等）