@sushanglewis/lincoln 1.5.0 → 1.5.1

package/framework/.claude/skills/lc-workflow-router/SKILL.md

@@ -0,0 +1,41 @@
+---
+name: lc-workflow-router
+description: Use at the start of a Lincoln session to run session intake (recon, situation judgment, Johari confirmation) and select the most appropriate workflow template.
+version: 1.1.0
+---
+
+# Lincoln Workflow Router
+
+## Purpose
+
+Using [lc-workflow-router] to run session intake and select the most appropriate workflow template.
+
+Runs session intake on a cold start — overview recon (摸排), five-element situation judgment, Johari confirmation — then inspects the confirmed context and chooses a workflow template from `.claude/workflows/`.
+
+## When to Use
+
+- At session start when the hook injects 「=== Lincoln 开场引导 ===」(no state file, or `current_stage: not_started`).
+- At session start when `<process_slug>/workflow-stage.yaml` has no `workflow.template`.
+- When the human PM says "重新评估工作流" or asks to switch templates.
+
+## Inputs
+
+- `prompts/intake-prompt.md` — the intake procedure to run first on a cold start
+- Repository root contents (overview recon only, ≤ 8 read-only operations)
+- `<process_slug>/workflow-stage.yaml`
+- Human's stated intent (interview, bug fix, design spike, existing project, etc.)
+
+## Outputs
+
+- `.context/lc-intake.md` — recon summary, situation judgment, confirmation record (session-level, gitignored)
+- Recommended `workflow.template` name
+- Recommended `current_run.current_stage`
+- Confidence score and 1-3 confirmation questions if needed
+
+## Rules
+
+- On a cold start (hook guidance block or `current_stage: not_started`), follow `prompts/intake-prompt.md` BEFORE selecting a template; then continue with `prompts/router-prompt.md`.
+- Do not proceed with any implementation until the PM confirms or overrides the recommended template.
+- If context is ambiguous, prefer the simplest template that matches the stated intent.
+- Document the reasoning in `current_run.context_assessment`.
+- When reporting the routing decision to the PM, declare: `Using lc-workflow-router to select workflow: <name> because <reason>`, and record it in `.context/lc-intake.md`.

package/framework/.claude/skills/lc-workflow-router/prompts/intake-prompt.md

@@ -0,0 +1,91 @@
+# session-intake prompt（开场引导）
+
+You are the Lincoln Session Intake guide. 当会话开始但 Lincoln 还没有可驱动的工作状态（无状态文件，或 `current_stage: not_started`）时，你的任务是基于当前可掌握的信息，自然地指导与辅助用户：先摸排，再判断，经确认后有策略地开展。
+
+本流程由会话启动 hook 的「=== Lincoln 开场引导 ===」指令块触发，也是 lc-workflow-router 选择模板之前的前置步骤。
+
+## 何时触发
+
+- hook 输出「=== Lincoln 开场引导 ===」块（fresh repo、issue 号不明、或 `current_stage: not_started`）。
+- 用户对当前要做什么明显迷茫（"我不知道从哪开始"），即使状态文件已存在。
+
+活跃阶段（`current_stage` 为进行中阶段）不触发本流程——按阶段上下文继续工作即可。
+
+## 第一步：摸排（概览级侦察）
+
+目的：用最少的读取建立"这个仓库/这个用户大概处于什么状态"的整体印象。**概览级，不是代码审查。**
+
+信号清单（按价值排序，够用就停）：
+
+| 信号 | 获取方式 | 能判断什么 |
+|------|----------|-----------|
+| 顶层结构 | `ls` 仓库根目录 | 有没有代码、knowledge/、工作包、文档 |
+| README 前 100 行 | Read（限前 100 行） | 项目定位、面向谁、当前阶段自述 |
+| `knowledge/00-index.md` | Read（若存在） | 已沉淀的业务/技术知识 |
+| 开放 issues | `gh issue list --limit 10`（gh 不可用则跳过） | 已知问题与优先级 |
+| `{process_slug}/documents.yaml` | Read（若存在） | 工作包内已有产物与确认状态 |
+| interviews / recordings 存在性 | `ls`（不读内容） | 是否有待处理的访谈原料 |
+| 用户首条消息 | 对话上下文 | 最直接的意图信号 |
+
+硬限制：
+
+- 只读操作总数 **≤ 8 次**。超过即停止摸排，用已有信息做判断。
+- **不读源码文件内容**（不看 `src/`、`tools/`、`scripts/` 的实现）。
+- **不调用深度扫描技能**（如 `lc-build-codebase-knowledge`）——那是后续阶段的事。
+- 除 `.context/lc-intake.md`（session 级记录，gitignored）外**不写任何文件**。
+- `gh` 不可用：跳过 issues 信号，在判断中标注该缺失，不阻塞。
+
+## 第二步：判断（处境评估）
+
+基于摸排结果与用户首条消息，输出五要素判断，并给出置信度：
+
+1. **角色**：用户大概是谁（PM / 工程师 / 设计师 / 独立 maker / 首次接触者）。
+2. **流程位置**：当前处于 Lincoln 流程的哪个位置（未初始化 / 工作包未启动 / 某阶段中途 / 游离于流程外的自由任务）。
+3. **问题**：用户面前最可能的 1-2 个问题或任务是什么。
+4. **目标**：用户想达到的状态（尽可能引用用户原话）。
+5. **象限初判**：对每个关键目标项，初判其 Johari 认知象限（见下）。
+
+置信度：high / medium / low。信息不足时**不编造**——直接说"信息不足"，把缺口变成下一步的问题。
+
+将摸排摘要与判断写入 `.context/lc-intake.md`（字段：摸排摘要 ≤10 行 / 处境判断 / 确认记录）。
+
+## 第三步：询问和确认（Johari 认知象限）
+
+把判断展示给用户，然后按象限设计确认动作。**每轮最多 3 个问题**；高置信度时可以只问 1 个。
+
+| 象限 | 含义 | 策略 |
+|------|------|------|
+| 知道自己知道 | 用户清楚目标与做法 | 复述确认题：用你的话复述，防会错意 |
+| 知道自己不知道 | 用户清楚但缺信息/方法 | 直接回答 + coach：给背景、给选项，不反问 |
+| 不知道自己知道 | 仓库里已有答案（knowledge/issue/文档） | 展示已有资产："这些已有产物可能已经回答了你的问题" |
+| 不知道自己不知道 | 盲区：未意识到的风险或缺失 | 探查题：用具体场景暴露风险，而非抽象提问 |
+
+原则：
+
+- 问题必须具体、可回答；避免"你想要什么？"式的空泛提问。
+- 不替用户答题：宁可多问一轮，不假设。
+- 用户的纠正直接更新 `.context/lc-intake.md` 的确认记录。
+
+## 第四步：有策略的开展（收敛与路由）
+
+**收敛标准**（两条都满足才允许进入执行）：
+
+1. 每个目标都有**明确的验收标准**（怎样算完成，用户认可）。
+2. 执行路径已确定（走哪个工作流 / 哪个阶段 / 哪条 solo 路径）。
+
+收敛后按处境路由，脚本一律由你代为执行，不让用户敲命令：
+
+| 处境 | 路由 |
+|------|------|
+| 无工作包 + 团队协作意图（有 issue 号） | 代为执行 `scripts/init-lincoln-branch.sh --issue-number <N>`，进入 team 工作流 |
+| 无工作包 + 个人快速迭代意图 | 转 router-prompt.md 选择模板，用 `lc-wf-*` 启动 solo 工作流 |
+| 已有工作包且 `current_stage: not_started` | 代为执行 `scripts/stage_loader.py --stage <stage> --action validate-entry`，进入第一阶段 |
+| 与 Lincoln 流程无关的独立问题 | 直接回答，不强行套流程 |
+
+## 禁忌
+
+- 确认完成前**不做任何实现性工作**（不写代码、不改文档、不动状态文件）。
+- 不替用户回答问题，不编造摸排中没看到的证据。
+- 无 issue 号时不擅自创建 GitHub issue；先问。
+- 不把摸排做成代码审查：超出 8 次只读上限就是失败。
+- 用户已明确表示熟悉流程并要求直接执行时，尊重其选择，把确认压缩到最低（复述一句 + 一个确认题）。

package/framework/.claude/skills/lc-workflow-router/prompts/router-prompt.md

@@ -0,0 +1,44 @@
+# workflow-router prompt
+
+You are the Lincoln Workflow Router. Your job is to assess the current project context and recommend a workflow template.
+
+前置依赖：在冷启动（hook 输出「=== Lincoln 开场引导 ===」，或 `current_stage: not_started`）时，先按 `prompts/intake-prompt.md` 完成 摸排 → 判断 → Johari 确认，再进入下面的模板选择；该流程的摸排摘要、处境判断与确认记录保存在 `.context/lc-intake.md`，可直接复用，不要重复侦察。
+
+## Context signals
+
+1. Repository structure:
+   - Does `knowledge/` already contain feature/requirement notes?
+   - Does `src/` or equivalent source directory exist?
+   - Are there open GitHub Issues or a `.github/linked-issues.yaml`?
+   - Is there an `{process_slug}/interviews/` directory with recordings?
+
+2. `<process_slug>/workflow-stage.yaml`:
+   - What is `current_run.current_stage`?
+   - Have any stages been completed?
+
+3. User intent from the opening message:
+   - Interview recording → `interview-to-knowledge`
+   - Bug report / specific issue → `bug-fix`
+   - "Design this" / "Spike" → `design-spike`
+   - "We have an existing codebase" → `existing-project-iteration`
+   - "Find open source solutions" → `oss-first-design`
+
+## Steps
+
+1. Confirm current stage from the hook-loaded state (read `<process_slug>/workflow-stage.yaml` only if needed).
+2. List top-level directories and key files to assess context.
+3. Choose the best template from `.claude/workflows/`.
+4. If confidence is low, ask the PM at most 3 clarifying questions.
+5. Once confirmed, set `current_run.workflow_template` and `current_stage` in `<process_slug>/workflow-stage.yaml` via `scripts/stage_loader.py`.
+6. Write a one-sentence `current_run.context_assessment` summary.
+
+## Output format
+
+```yaml
+workflow_template: <template-name>
+current_stage: <stage-id>
+confidence: high | medium | low
+reasoning: <one sentence>
+```
+
+Do not execute the workflow yourself. Only select and configure it.

package/framework/.claude/skills/plan-tdd-development/SKILL.md

@@ -0,0 +1,31 @@
+---
+name: plan-tdd-development
+description: 基于已确认产品设计和原型生成 TDD 研发计划
+triggers:
+  - "生成 TDD 研发计划"
+  - "plan-tdd-development"
+inputs:
+  - name: session_id
+    description: 访谈会话 ID
+    required: true
+  - name: design_id
+    description: 产品设计 ID
+    required: true
+outputs:
+  - "{process_slug}/pages/docs/tdd-plan.html"
+required_tools:
+  - Read
+  - Bash
+  - Write
+---
+
+# plan-tdd-development
+
+## Purpose
+
+Using [plan-tdd-development] to 基于已确认产品设计和原型生成 TDD 研发计划.
+
+
+基于已确认产品设计、字段规格、UI 规格和 Pencil 原型生成 TDD 研发计划。
+
+运行入口： prompts/main.md

package/framework/.claude/skills/plan-tdd-development/prompts/main.md

@@ -0,0 +1,44 @@
+# plan-tdd-development
+
+You are executing the Lincoln workflow step `tdd-development-plan`: turn the confirmed product design and prototype into a TDD development plan.
+
+## Goal
+
+Create `{process_slug}/pages/docs/tdd-plan.html` as the bridge from product design to OpenSpec and GitHub Issues.
+
+## Input
+
+- `session_id`: the interview session identifier
+- `design_id`: the product design identifier
+
+## 子技能准备
+
+在执行本 prompt 前：
+1. 调用 `superpowers:writing-plans` 规划 `tdd-plan.html` 结构。
+2. 遵循 `superpowers:test-driven-development` 方法论：确保每个任务切片都是“先写失败测试 → 最小实现 → 重构”序列。
+3. 在 `tdd-plan.html` 的 Markdown source 头部加入：  
+   `> **Required sub-skill:** Use superpowers:test-driven-development for all implementation`
+
+## Steps
+
+1. Verify that `{process_slug}/pages/docs/ui-spec.html` contains `<!-- prototype-status: approved -->` or `[x] PM 已确认原型`.
+2. Confirm `{process_slug}/designs/<design_id>/prototype.pen`, `{process_slug}/pages/docs/fields.html`, and the design review package exist.
+3. Read the confirmed design docs and inspect the `.pen` through Pencil tools if visual structure is needed.
+4. Write `{process_slug}/pages/docs/tdd-plan.html` using `.claude/templates/issue-package/page-doc.html.tpl`. It must embed Markdown in `<script type="text/markdown" id="docSource">` with a `<!-- version: v1.0 -->` marker and meta tags (`doc-title`, `nav-group`, `doc-version`, `doc-uid`). Content must include:
+   - Source links to `requirements.html`, `design-review.html`, `fields.html`, `ui-spec.html`, and `prototype.pen`
+   - Acceptance criteria mapping
+   - Test scenarios grouped by user workflow
+   - Red/green/refactor implementation sequence
+   - Unit, integration, contract, UI, and regression test boundaries
+   - Data fixtures and validation cases
+   - Task slices suitable for OpenSpec tasks and GitHub Issues
+   - Risks, dependencies, and out-of-scope items
+5. Add `<!-- status: ready-for-openspec -->` when the plan is complete.
+6. Run `python scripts/stage_loader.py --stage tdd-development-plan --action record-artifacts`.
+
+## Rules
+
+- Keep the plan executable by an engineer without requiring extra product decisions.
+- Every task slice must map back to a design artifact and acceptance criterion.
+- Do not generate OpenSpec artifacts in this step.
+- After completion, tell the user to run: `claude propose-with-openspec <session_id> <design_id> <change_name>`.

package/framework/.claude/skills/process-interview/SKILL.md

@@ -0,0 +1,32 @@
+---
+name: process-interview
+description: 处理访谈录音，生成转写、摘要和初始洞察
+triggers:
+  - "处理访谈录音"
+  - "process-interview"
+inputs:
+  - name: recording_path
+    description: 录音文件路径，如 {process_slug}/recordings/2026-06-27-stakeholder.m4a 或 {process_slug}/interviews/{session_id}/audio.wav
+    required: true
+outputs:
+  - "{process_slug}/interviews/{session_id}/metadata.json"
+  - "{process_slug}/interviews/{session_id}/transcript.md"
+  - "{process_slug}/interviews/{session_id}/summary.md"
+  - "{process_slug}/interviews/{session_id}/raw-insights.md"
+required_tools:
+  - Read
+  - Bash
+---
+
+# process-interview
+
+## Purpose
+
+Using [process-interview] to 处理访谈录音，生成转写、摘要和初始洞察.
+
+
+处理访谈录音，生成带时间戳与说话人标签的 transcript、summary 和 raw-insights。
+
+录音应优先由 `tools/lincoln-record` 生成，输出到 `{process_slug}/interviews/{session_id}/audio.wav`，然后调用本 skill 进行转写与后处理。
+
+运行入口： prompts/main.md

package/framework/.claude/skills/process-interview/prompts/main.md

@@ -0,0 +1,47 @@
+# process-interview
+
+You are executing the Lincoln workflow step `ingest`: process a stakeholder interview recording.
+
+## Goal
+
+Extract structured information from the audio file and write artifacts to `{process_slug}/interviews/<session-id>/`.
+
+## Input
+
+- `recording_path`: path to the audio file (e.g., `{process_slug}/recordings/2026-06-27-stakeholder.m4a`)
+
+## Steps
+
+1. Validate the file exists and is one of the supported formats: `.mp3`, `.m4a`, `.wav`, `.mp4`, `.mov`.
+2. Derive `session_id` from the filename without extension (e.g., `2026-06-27-stakeholder`).
+3. Create directory `{process_slug}/interviews/<session-id>/`.
+4. Extract audio track if input is video using `ffmpeg`.
+5. Transcribe using Whisper (prefer local `faster-whisper`; fallback to OpenAI Whisper API if local fails).
+6. Generate `transcript.md` with timestamped Speaker A/B segments.
+7. Generate `summary.md` with:
+   - `关键主题`
+   - `决策`
+   - `行动项`
+   - `开放问题`
+8. Generate `raw-insights.md` with Agent's preliminary observations about potential requirements.
+9. Write `metadata.json` with:
+   - sessionId
+   - originalFile
+   - duration
+   - processedAt
+   - transcriptModel
+   - status
+
+## Output Artifacts
+
+- `{process_slug}/interviews/<session-id>/metadata.json`
+- `{process_slug}/interviews/<session-id>/transcript.md`
+- `{process_slug}/interviews/<session-id>/summary.md`
+- `{process_slug}/interviews/<session-id>/raw-insights.md`
+
+## Rules
+
+- Do not modify the original recording file.
+- If transcription fails, write a partial artifact and report the error clearly.
+- Use Chinese for the summary and insights unless the interview is in English.
+- After completion, tell the user the next command: `claude clarify-requirements <session-id>`.

package/framework/.claude/skills/propose-with-openspec/SKILL.md

@@ -0,0 +1,37 @@
+---
+name: propose-with-openspec
+description: 基于已确认 TDD 研发计划调用 OpenSpec CLI 生成变更提案 artifact
+triggers:
+  - "生成 OpenSpec 提案"
+  - "propose-with-openspec"
+inputs:
+  - name: session_id
+    description: 访谈会话 ID
+    required: true
+  - name: design_id
+    description: 产品设计 ID
+    required: true
+  - name: change_name
+    description: OpenSpec 变更名称，如 add-csv-export
+    required: true
+outputs:
+  - "{process_slug}/openspec/changes/{change_name}/proposal.md"
+  - "{process_slug}/openspec/changes/{change_name}/design.md"
+  - "{process_slug}/openspec/changes/{change_name}/tasks.md"
+  - "{process_slug}/openspec/changes/{change_name}/specs/"
+required_tools:
+  - Read
+  - Bash
+  - Write
+---
+
+# propose-with-openspec
+
+## Purpose
+
+Using [propose-with-openspec] to 基于已确认 TDD 研发计划调用 OpenSpec CLI 生成变更提案 artifact.
+
+
+调用 OpenSpec CLI 基于 TDD 研发计划生成完整变更提案 artifact。
+
+运行入口： prompts/main.md

package/framework/.claude/skills/propose-with-openspec/prompts/main.md

@@ -0,0 +1,53 @@
+# propose-with-openspec
+
+You are executing the Lincoln workflow step `propose`: generate an OpenSpec change proposal directly using the OpenSpec CLI.
+
+## Goal
+
+Invoke `openspec propose` using the confirmed TDD development plan to create the standard OpenSpec artifact directory under `{process_slug}/openspec/changes/<change-name>/`.
+
+## Input
+
+- `session_id`: the interview session identifier
+- `design_id`: the product design identifier
+- `change_name`: a short kebab-case change name (e.g., `add-csv-export`)
+
+## Steps
+
+1. Read `{process_slug}/pages/docs/requirements.html` (extract Markdown from the `docSource` block).
+2. Read `{process_slug}/pages/docs/tdd-plan.html`, `design-review.html`, `feature-catalog.html`, `data-model.html`, `flows.html`, `feasibility.html`, `fields.html`, and `ui-spec.html` (extract embedded Markdown where needed).
+3. Verify `{process_slug}/pages/docs/tdd-plan.html` contains `<!-- status: ready-for-openspec -->`.
+4. Ensure `{process_slug}/openspec/changes/<change_name>/` does not already exist, or ask the user if they want to overwrite.
+5. Call the OpenSpec CLI. Try the following forms in order:
+   - `openspec propose <change_name> --from {process_slug}/pages/docs/tdd-plan.html`
+   - `openspec propose <change_name>` and pipe the TDD plan plus design summary into stdin
+   - If neither works, read the OpenSpec CLI help (`openspec propose --help`) and adapt.
+6. Verify the generated artifacts:
+   - `{process_slug}/openspec/changes/<change_name>/proposal.md`
+   - `{process_slug}/openspec/changes/<change_name>/specs/` (at least one file)
+   - `{process_slug}/openspec/changes/<change_name>/design.md`
+   - `{process_slug}/openspec/changes/<change_name>/tasks.md`
+7. Ensure the OpenSpec artifact references:
+   - `{process_slug}/pages/docs/tdd-plan.html`
+   - `{process_slug}/designs/<design_id>/prototype.pen`
+   - Core design docs under `{process_slug}/pages/docs/`
+8. Call `superpowers:verification-before-completion` to verify the artifacts before claiming completion:
+   - Run `python scripts/validate_stage.py --phase exit --check openspec_artifact_complete --args <change_name>,<design_id>`
+   - Run `python scripts/validate_stage.py --phase exit --check tasks_extracted --args <change_name>`
+   - Read the output and confirm PASS. Do not claim completion without fresh verification evidence.
+9. If any artifact is missing, empty, or missing design references, report the error and pause for human intervention.
+10. Run `python scripts/stage_loader.py --stage propose --action record-artifacts`.
+
+## Output Artifacts
+
+- `{process_slug}/openspec/changes/<change_name>/proposal.md`
+- `{process_slug}/openspec/changes/<change_name>/specs/*.md`
+- `{process_slug}/openspec/changes/<change_name>/design.md`
+- `{process_slug}/openspec/changes/<change_name>/tasks.md`
+
+## Rules
+
+- Do not bypass the OpenSpec CLI by manually writing the artifact files.
+- Preserve the OpenSpec structure exactly as the CLI generates it.
+- OpenSpec tasks must be driven by `{process_slug}/pages/docs/tdd-plan.html`.
+- After success, tell the user to run: `claude split-to-github <session_id> <change_name>`.

package/framework/.claude/skills/split-to-github/SKILL.md

@@ -0,0 +1,32 @@
+---
+name: split-to-github
+description: 将 OpenSpec tasks 拆分为 GitHub Issues
+triggers:
+  - "拆分到 GitHub"
+  - "split-to-github"
+inputs:
+  - name: session_id
+    description: 访谈会话 ID
+    required: true
+  - name: change_name
+    description: OpenSpec 变更名称
+    required: true
+outputs:
+  - .github/linked-issues.yaml
+required_tools:
+  - Read
+  - Bash
+  - Write
+  - mcp__plugin_ecc_github__create_issue
+---
+
+# split-to-github
+
+## Purpose
+
+Using [split-to-github] to 将 OpenSpec tasks 拆分为 GitHub Issues.
+
+
+读取 OpenSpec tasks 并拆分为带清晰边界和验收标准的 GitHub Issues。
+
+运行入口： prompts/main.md

package/framework/.claude/skills/split-to-github/prompts/main.md

@@ -0,0 +1,42 @@
+# split-to-github
+
+You are executing the Lincoln workflow step `split`: convert OpenSpec tasks into GitHub Issues in the configured target repository.
+
+## Goal
+
+Create one GitHub Issue per actionable task from `{process_slug}/openspec/changes/<change_name>/tasks.md`.
+
+## Input
+
+- `session_id`: the interview session identifier
+- `change_name`: the OpenSpec change name
+
+## Steps
+
+1. Read `.github/openspec-config.yml` to get the target repository `owner/name`.
+2. Read `{process_slug}/openspec/changes/<change_name>/tasks.md`.
+3. Parse the task list. For each task:
+   - Create a GitHub Issue in the target repo using `gh issue create` or the GitHub MCP.
+   - Title: clear, action-oriented
+   - Body must include:
+     - User story
+     - Acceptance criteria
+     - Source interview: `{process_slug}/interviews/<session_id>/`
+     - Source requirement: `{process_slug}/requirements/<session_id>/requirements.md`
+     - Source OpenSpec change: `{process_slug}/openspec/changes/<change_name>/`
+     - Relevant transcript timestamps
+   - Apply labels: `from-interview`, `openspec`
+4. Write `.github/linked-issues.yaml` mapping tasks to issue numbers.
+5. Update `{process_slug}/requirements/<session_id>/requirements.md` to record the created issue numbers.
+
+## Output Artifacts
+
+- `.github/linked-issues.yaml`
+- Updated `{process_slug}/requirements/<session_id>/requirements.md`
+- GitHub Issues in the target repository
+
+## Rules
+
+- Do not create issues without a clear acceptance criterion.
+- Each issue should map to exactly one OpenSpec task.
+- After completion, tell the user the issues are ready for implementation.

package/framework/.claude/skills/sync-to-knowledge/SKILL.md

@@ -0,0 +1,35 @@
+---
+name: sync-to-knowledge
+description: PR 合并后将代码和 issue 沉淀到 Obsidian 知识库
+triggers:
+  - "同步到知识库"
+  - "sync-to-knowledge"
+inputs:
+  - name: issue_number
+    description: GitHub Issue 编号
+    required: true
+  - name: pr_number
+    description: GitHub PR 编号
+    required: true
+outputs:
+  - .github/lincoln-sync-queue/pr-{pr_number}.yaml
+  - knowledge/01-interviews/{session_id}.md
+  - knowledge/02-requirements/{requirement_id}.md
+  - knowledge/03-features/{feature_slug}.md
+  - knowledge/04-decisions/{decision_id}.md
+required_tools:
+  - Read
+  - Bash
+  - Write
+---
+
+# sync-to-knowledge
+
+## Purpose
+
+Using [sync-to-knowledge] to PR 合并后将代码和 issue 沉淀到 Obsidian 知识库.
+
+
+PR 合并后读取代码 diff、issue、需求文档和 OpenSpec design，沉淀到 Obsidian 知识库。
+
+运行入口： prompts/main.md

package/framework/.claude/skills/sync-to-knowledge/prompts/main.md

@@ -0,0 +1,54 @@
+# sync-to-knowledge
+
+You are executing the Lincoln workflow step `sync-knowledge`: after a PR is merged, review the code and issue, then update the project Obsidian vault with both business and technical knowledge.
+
+## Goal
+
+Ensure every merged issue leaves behind a complete, linked feature note in `knowledge/`.
+
+## Input
+
+- `issue_number`: the GitHub Issue number
+- `pr_number`: the merged Pull Request number
+
+## 子技能准备
+
+在执行本 prompt 时：
+1. 调用 `gsd-docs-update` 生成或更新知识文档，确保文档内容与代码库一致。
+2. 若同步失败，调用 `gsd-forensics` 进行失败复盘，找到根因后再继续。
+
+## Steps
+
+1. Read `.github/openspec-config.yml` for the target repository.
+2. Fetch the issue and PR details using `gh` or GitHub MCP.
+3. Find the linked requirement and OpenSpec change from the issue body.
+4. Read the related files:
+   - `{process_slug}/requirements/<session>/requirements.md`
+   - `{process_slug}/openspec/changes/<change>/design.md`
+   - `{process_slug}/openspec/changes/<change>/tasks.md`
+5. Review the merged PR diff.
+6. Create or update `knowledge/03-features/<feature-slug>.md` using the feature-note template.
+7. Ensure the feature note has both:
+   - `业务知识` section: background, user needs, acceptance criteria, value
+   - `技术知识` section: implementation overview, code locations, design decisions, dependencies, API/data models
+8. Create/update supporting notes:
+   - `knowledge/01-interviews/<session>.md` if not exists
+   - `knowledge/02-requirements/<requirement-id>.md`
+   - `knowledge/04-decisions/<decision-id>.md` for any architecture decisions
+9. Use Obsidian wikilinks (`[[...]]`) to connect notes.
+10. Check for conflicts with existing knowledge. If a conflict is found, pause and ask the human PM.
+
+## Output Artifacts
+
+- `knowledge/03-features/<feature-slug>.md`
+- `knowledge/02-requirements/<requirement-id>.md`
+- `knowledge/01-interviews/<session>.md`
+- `knowledge/04-decisions/<decision-id>.md` (if applicable)
+- Updated `knowledge/00-index.md`
+
+## Rules
+
+- A feature note without both business and technical sections is invalid.
+- Every note must link back to its source interview, requirement, issue, and PR.
+- Do not overwrite human edits without noting the changes.
+- After completion, summarize what was updated in the vault.

package/framework/.claude/skills/workflow-continue/SKILL.md

@@ -0,0 +1,24 @@
+---
+name: workflow-continue
+description: 人类修改文件后继续被暂停的工作流
+triggers:
+  - "继续工作流"
+  - "workflow-continue"
+inputs: []
+outputs:
+  - 推进当前 stage 到下一个节点
+required_tools:
+  - Read
+  - Bash
+---
+
+# workflow-continue
+
+## Purpose
+
+Using [workflow-continue] to 人类修改文件后继续被暂停的工作流.
+
+
+在人类修改文件或回复后继续被暂停的 Lincoln 工作流。
+
+运行入口： prompts/main.md

package/framework/.claude/skills/workflow-continue/prompts/main.md

@@ -0,0 +1,25 @@
+# workflow-continue
+
+You are resuming a paused Lincoln workflow after human intervention.
+
+## Goal
+
+Re-read the current workflow state, detect what changed, and continue from the appropriate step.
+
+## Steps
+
+1. Confirm the current stage from the hook-loaded state (read `<process_slug>/workflow-stage.yaml` only if needed).
+2. Identify the current step and its status (paused, waiting_for_human, validation_failed).
+3. Re-read all artifacts associated with the current step.
+4. If the human edited files directly, compare the current version with the version recorded in the state file and summarize the diff.
+5. Re-run the entry/exit validators for the current step.
+6. If validation passes, continue to the next step.
+7. If validation fails, report the failures and pause again.
+8. If resuming after a merged PR, read `.github/lincoln-sync-queue/pr-<pr_number>.yaml` to get the pending `issue_number` and `pr_number`.
+
+## Rules
+
+- Always acknowledge what the human changed before continuing.
+- Do not skip steps.
+- If the human wants to abort or restart a step, respect that instruction.
+- Keep responses concise: state what was detected, what was validated, and what happens next.