@sushanglewis/lincoln 1.5.5 → 1.6.1

package/framework/.claude/skills/build-product-prototype/prompts/main.md

@@ -4,29 +4,16 @@ You are executing the Lincoln workflow step `product-prototype`: turn approved p
 
 ## Goal
 
-Create field and UI specifications as HTML doc pages, and produce a high-fidelity interactive HTML prototype that the PM can inspect directly in the issue-package portal (`{process_slug}/index.html`). A Pencil prototype is optional; the HTML prototype is the primary review artifact.
+Create field and UI specifications as HTML doc pages, and produce a high-fidelity interactive HTML prototype that the PM can inspect directly in the issue-package portal (`{process_slug}/index.html`). The HTML prototype is the primary review artifact; a Pencil prototype is optional and produced only if the PM explicitly asks for it.
 
 ## Reference templates
 
-Use the following read-only templates as the style/layout reference. Copy/adapt them into the issue package; do not modify the templates themselves.
-
-- `.claude/templates/issue-package/page-prototype.html.tpl` — minimal starter page with theme sync support.
-- `.claude/templates/issue-package/prototypes/app/main/page.html.tpl` — main app window with sidebar + WebView placeholder.
-- `.claude/templates/issue-package/prototypes/app/onboarding/page.html.tpl` — login/onboarding card.
-- `.claude/templates/issue-package/prototypes/app/settings/page.html.tpl` — two-column settings page.
-- `.claude/templates/issue-package/prototypes/app/overlays/page.html.tpl` — avatar menu / about / toast overlays.
-- `.claude/templates/issue-package/prototypes/app/tray/page.html.tpl` — system-tray scenario controller. When the product has a macOS menubar presence, create thin scenario pages under `pages/prototype/app/tray/` showing at minimum: default state, unread-badge state, and menu-open state. These pages must **not** redraw the tray inside the app prototype; instead they send `postMessage({type:'lincoln-tray-state', unread:<int>, open:<bool>}, '*')` to the portal so the portal-level macOS tray updates. See the tray template for the exact snippet.
-- `.claude/templates/issue-package/prototypes/app/org/page.html.tpl` — organization list.
-- `.claude/templates/issue-package/prototypes/web/dashboard/page.html.tpl` — web dashboard shell.
-- `.claude/templates/issue-package/prototypes/web/list/page.html.tpl` — web list view shell.
-- `.claude/templates/issue-package/prototypes/web/form/page.html.tpl` — web form shell.
-- `.claude/templates/issue-package/prototypes/web/detail/page.html.tpl` — web detail shell.
-- `.claude/templates/issue-package/prototypes/mobile/home/page.html.tpl` — mobile home feed shell.
-- `.claude/templates/issue-package/prototypes/mobile/chat/page.html.tpl` — mobile chat shell.
-- `.claude/templates/issue-package/prototypes/mobile/settings/page.html.tpl` — mobile settings list shell.
-- `.claude/templates/issue-package/prototypes/mobile/profile/page.html.tpl` — mobile profile shell.
-- `.claude/templates/issue-package/assets/prototype.css` — shared styles (tokens, dark mode, window shell, sidebar, forms, overlays, web/mobile shells).
-- `.claude/templates/issue-package/assets/prototype.js` — shared UI builders and mock data (`window.LincolnPrototype`), including `frameApp`, `frameWeb`, `frameMobile`.
+The default rendering templates are:
+
+- `.claude/templates/issue-package/page-doc-structured.html.tpl` — structured doc page used for `fields.html` and `ui-spec.html`.
+- `.claude/templates/issue-package/page-prototype-structured.html.tpl` — data-driven prototype page used for all `pages/prototype/**/*.html`.
+
+You may still read the categorized example templates under `.claude/templates/issue-package/prototypes/` for layout inspiration, but generate pages through `python scripts/lincoln_render.py` rather than copying templates by hand.
 
 ## Input
 
@@ -37,22 +24,98 @@ Use the following read-only templates as the style/layout reference. Copy/adapt
 
 1. Verify `{process_slug}/pages/docs/design-review.html` contains `<!-- status: approved -->` or `[x] PM 已确认设计文档`.
 2. Read the approved design package under `{process_slug}/pages/docs/`, including `flows.html` and `page-map.html`.
-3. Write `{process_slug}/pages/docs/fields.html` using `.claude/templates/issue-package/page-doc.html.tpl` with screen/form fields, data type, required/optional status, validation, default value, copy, error state, and source data object.
+3. Write `{process_slug}/pages/docs/fields.html` using the structured renderer:
+
+   ```bash
+   python scripts/lincoln_render.py \
+     --stage product-prototype \
+     --target {process_slug}/pages/docs/fields.html \
+     --title "字段说明" --nav-label "字段" --version v1.0 --uid fields \
+     --data {process_slug}/pages/docs/fields.yaml
+   ```
+
+   The YAML should contain a `fields` array (optionally grouped under `groups`):
+
+   ```yaml
+   intro: "本页面列出所有 screen/form 字段规格。"
+   annotations:
+     doc-purpose: "字段规格"
+     doc-fields: "字段名 — 类型 — 必填 — 说明"
+   fields:
+     - name: "手机号"
+       type: "string"
+       required: true
+       validation: "大陆手机号正则"
+       default: ""
+       copy: "请输入手机号"
+       error: "手机号格式不正确"
+       source: "model/user"
+   ```
+
 4. Write `{process_slug}/pages/docs/ui-spec.html` covering the interaction-document delivery standards:
    - 用户场景与流程: who, when, goal, trigger, completion criteria.
    - 界面流转图: screen-to-screen flow mapped to the business flow in `flows.html`.
    - 页面交互说明: per-screen layout elements, interaction rules (events, responses, navigation), and field validation/error handling.
    - 交互 Demo/原型: links to the HTML prototype pages under `pages/prototype/` and a summary of key interactions.
-5. **Plan prototype generation granularity.** Before writing prototype pages, list every screen from `flows.html` and `page-map.html`. Group them into cohesive clusters (e.g. onboarding, main shell, settings, overlays, tray). Generate one cluster at a time. After each cluster, verify that every page in the cluster has complete annotation meta tags before starting the next cluster. This prevents agent context exhaustion and keeps each page's documentation and interactions complete.
-6. Create interactive HTML prototypes under `{process_slug}/pages/prototype/{app,web,mobile}/` by adapting the reference templates above. Pick the right shell (`frameApp`, `frameWeb`, or `frameMobile`) from `LincolnPrototype.ui` for the product form-factor. Every page must:
+
+   Use the structured renderer with `--data` containing `sections`, `pages`, and `interactions` as appropriate.
+
+5. **Plan prototype generation granularity.** Before writing prototype pages, list every screen from `flows.html` and `page-map.html`. Group them into cohesive clusters (e.g. onboarding, main shell, settings, overlays, tray). Generate one cluster at a time. After each cluster, verify that every page has complete annotation meta tags before starting the next cluster.
+
+6. Create interactive HTML prototypes under `{process_slug}/pages/prototype/{app,web,mobile}/` using the structured prototype renderer:
+
+   ```bash
+   python scripts/lincoln_render.py \
+     --stage product-prototype \
+     --target {process_slug}/pages/prototype/web/dashboard/page.html \
+     --title "仪表盘" --nav-label "仪表盘" --nav-group "Prototype" --uid page-dashboard \
+     --data {process_slug}/pages/prototype/web/dashboard/page.yaml
+   ```
+
+   Prototype YAML schema:
+
+   ```yaml
+   layout:
+     type: web          # web | app | mobile
+     shell: dashboard   # dashboard | list | form | detail | main | onboarding | settings | overlays | tray | org
+     title: "仪表盘"
+     active: dashboard
+     navItems:
+       - {id: dashboard, label: 概览, href: ./dashboard/page.html}
+       - {id: list, label: 列表, href: ./list/page.html}
+   annotations:
+     doc-purpose: "展示核心指标与快捷入口"
+     doc-layout: "顶部导航 | 指标卡片网格 | 列表区"
+     doc-fields: "..."
+     doc-stories: "..."
+     doc-rules: "..."
+     doc-boundaries: "..."
+     doc-exceptions: "..."
+     doc-refs: "flows.html | page-map.html"
+   components:
+     - type: html
+       uid: dashboard-metrics
+       props:
+         html: '<div class="metric-grid">...'>
+     - type: wv
+       props:
+         kind: chat
+   interactions:
+     - trigger: "点击指标卡片"
+       action: "跳转到详情页"
+       target: "detail/page.html"
+   ```
+
+   Every page must:
    - Link to `../../../assets/prototype.css` and `../../../assets/prototype.js` (depth 3) or `../../../../assets/...` (depth 4) depending on its path.
-   - Include the theme sync IIFE shown in the starter template.
+   - Include theme sync support (built into the structured template).
    - Include `<meta name="prototype-base" content="../../../">` (or `../../../../` for depth 4).
-   - Include `<meta name="page-uid" content="...">`, `<meta name="nav-group" content="...">`, and `<meta name="nav-label" content="...">` with a short Chinese label for the left nav.
-   - Include the annotation meta tags `doc-purpose`, `doc-layout`, `doc-fields`, `doc-boundaries`, `doc-exceptions`. Also include `doc-stories`, `doc-rules`, `doc-refs` when they add clarity, so the portal right panel explains functionality, layout, fields, boundary cases, and exception flows.
+   - Include `<meta name="page-uid" content="...">`, `<meta name="nav-group" content="...">`, and `<meta name="nav-label" content="...">` (injected by the renderer from CLI args; annotations come from the YAML `annotations` block).
+   - Provide the full annotation meta tags so the portal right panel explains functionality, layout, fields, boundary cases, and exception flows.
    - Use `LincolnPrototype.ui` builders and `prototype.css` tokens for every visual element so both light and dark themes render correctly; verify both themes by toggling the portal theme switch.
    - Assign a stable `data-uid` attribute to every interactive element, screen region, and WebView placeholder.
    - Override `LincolnPrototype.data` in the page script for issue-specific mock data (user, org, webviews, settings, unread items).
+
 7. Optionally create or update `{process_slug}/designs/<design_id>/prototype.pen` with Pencil tools if the PM explicitly asks for a Pencil prototype. If you use Pencil tools, call `get_editor_state(include_schema: true)` first and use `snapshot_layout` to check for clipping/overlap.
 8. Update the root `{process_slug}/pages/docs/prd.html` section 9 "相关产物链接" with the `ui-spec.html`, `fields.html`, and HTML prototype links. If the PRD already has an approved snapshot, warn the PM that changes require a version bump and re-freeze via `python scripts/lincoln_prd.py freeze`.
 9. Ask the PM to open `{process_slug}/index.html` in a browser, toggle the theme switch in the macOS menubar, and review both light and dark renderings of each prototype page inside the portal.

package/framework/.claude/skills/clarify-requirements/prompts/main.md

@@ -20,24 +20,90 @@ Produce a clear, agreed-upon `{process_slug}/pages/docs/requirements.html` and t
 ## Steps
 
 1. Read `{process_slug}/interviews/<session-id>/transcript.md`, `summary.md`, and `raw-insights.md`.
-2. Draft an initial `{process_slug}/pages/docs/requirements.html` using `.claude/templates/issue-package/page-doc.html.tpl`. Embed the Markdown source in the `<script type="text/markdown" id="docSource">` block and include a `<!-- version: v1.0 -->` marker. Required sections:
-   - `背景`
-   - `问题`
-   - `用户`
-   - `方案`
-   - `验收标准`
-   - `非目标`
-   - `开放问题`
+2. Draft an initial `{process_slug}/pages/docs/requirements.html` using `python scripts/lincoln_render.py --stage clarify --target {process_slug}/pages/docs/requirements.html --title "需求文档" --nav-label "需求" --version v1.0 --uid requirements --data {process_slug}/pages/docs/requirements.yaml`. The YAML data file should follow this schema:
+
+   ```yaml
+   intro: "一句话概括本需求。"
+   annotations:
+     doc-purpose: "说明本次需求要解决的核心问题"
+     doc-layout: "单页文档"
+     doc-stories: "作为 <角色> 我想要 <目标> 以便 <价值>"
+     doc-rules: "列出关键业务规则"
+     doc-boundaries: "列出边界情况"
+     doc-exceptions: "列出异常流"
+   sections:
+     - title: "背景"
+       content: "..."
+     - title: "问题"
+       content: "..."
+     - title: "用户"
+       content: "..."
+     - title: "方案"
+       content: "..."
+     - title: "验收标准"
+       content: "..."
+     - title: "非目标"
+       content: "..."
+     - title: "开放问题"
+       content: "..."
+   ```
+
+   The renderer will inject the YAML as `pageData` and render structured sections automatically. You may also pass `--markdown` for a free-form supplement.
 3. Identify 1-3 ambiguities or missing details, and tag each with its Johari quadrant (认知象限): 知道自己知道 → 复述确认题; 知道自己不知道 → 直接回答 + coach; 不知道自己知道 → 展示已有资产; 不知道自己不知道 → 探查题.
 4. Ask the human PM these questions one batch at a time in the terminal, using the quadrant-appropriate style.
 5. Update `requirements.html` based on the answers (always rewrite the full file; do not mutate in-place).
 6. Repeat until the PM confirms the requirements are clear.
-7. Also generate `{process_slug}/pages/docs/user-stories.html` from the finalized requirements using the same doc-page template.
-8. Generate the root-level PRD at `{process_slug}/pages/docs/prd.html` using `.claude/templates/issue-package/page-doc.html.tpl`. It must include:
-   - `<!-- version: v1.0 -->` marker inside the `docSource` block.
-   - Meta tags: `doc-title`, `nav-group="Docs"`, `doc-version="v1.0"`, and a stable `doc-uid`.
-   - All required sections: 1.需求背景, 2.用户故事, 3.功能拆解, 4.业务流程图, 5.验收标准, 6.业务规则, 7.非功能需求, 8.关联系统/接口, 9.相关产物链接, 10.风险与开放问题.
-   - A links table in section 9 pointing to interviews, requirements.html, user-stories.html, and downstream design/prototype/OpenSpec artifacts.
+7. Also generate `{process_slug}/pages/docs/user-stories.html` from the finalized requirements using the structured renderer with `--data` containing a `stories` array:
+
+   ```yaml
+   intro: "基于已确认需求提炼的用户故事清单。"
+   annotations:
+     doc-purpose: "用户故事全景"
+   stories:
+     - who: "作为 访客用户"
+       want: "我想要 通过微信扫码登录"
+       so: "以便 不用注册密码"
+       acceptance: "扫码后 3 秒内完成登录"
+       source: "prd#section-2"
+   ```
+
+8. Generate the root-level PRD at `{process_slug}/pages/docs/prd.html` using the structured renderer with `--stage clarify --uid prd`. The data YAML must include `intro`, `annotations`, and `sections` for the 10 required PRD sections:
+
+   ```yaml
+   intro: "一句话 PRD 概述。"
+   annotations:
+     doc-purpose: "XXX 产品需求文档"
+     doc-stories: "..."
+     doc-rules: "..."
+     doc-boundaries: "..."
+     doc-exceptions: "..."
+     doc-refs: "requirements.html | user-stories.html"
+   sections:
+     - title: "1. 需求背景"
+       content: "..."
+     - title: "2. 用户故事"
+       content: "..."
+     - title: "3. 功能拆解"
+       content: "..."
+     - title: "4. 业务流程图"
+       content: "..."
+     - title: "5. 验收标准"
+       content: "..."
+     - title: "6. 业务规则"
+       content: "..."
+     - title: "7. 非功能需求"
+       content: "..."
+     - title: "8. 关联系统/接口"
+       content: "..."
+     - title: "9. 相关产物链接"
+       content: "| 产物 | 路径 | 状态 |"
+     - title: "10. 风险与开放问题"
+       content: "..."
+   ```
+
+   It must also carry:
+   - `<!-- version: v1.0 -->` marker (added automatically by the renderer from `--version`).
+   - Meta tags: `doc-title`, `nav-group="Docs"`, `doc-version="v1.0"`, and a stable `doc-uid` (all injected by the renderer).
 9. When the PM confirms, add an approval marker inside `requirements.html`: `<!-- status: approved -->`.
 10. After human approval, run `python scripts/lincoln_prd.py freeze` to create the immutable snapshot `{process_slug}/pages/docs/snapshots/prd-v1.0.html`.
 11. Run `python scripts/stage_loader.py --stage clarify --action record-artifacts` to persist the artifact paths and refresh `{process_slug}/assets/js/package-data.js`.

package/framework/.claude/skills/draft-product-design/prompts/main.md

@@ -1,10 +1,10 @@
 # draft-product-design
 
-You are executing the Lincoln workflow step `product-design-docs`: turn approved requirements into a concise product design review package for the human PM.
+You are executing the Lincoln workflow step `product-design-docs`: turn approved requirements into a concise product design review package (a set of HTML documents) for the human PM.
 
 ## Goal
 
-Create `{process_slug}/pages/docs/` HTML design documents with enough product, data, flow, feasibility, and technical framing for PM review and later development planning, without creating unnecessary review burden.
+Create `{process_slug}/pages/docs/` HTML design documents with enough product, data, flow, feasibility, and technical framing for PM review and later development planning, without creating unnecessary review burden. This step does **not** produce UI specs, field specs, or prototypes — those belong to the next stage `product-prototype`.
 
 ## Input
 
@@ -21,16 +21,27 @@ Create `{process_slug}/pages/docs/` HTML design documents with enough product, d
 
 1. Validate that `{process_slug}/pages/docs/requirements.html` is approved (contains `<!-- status: approved -->`).
 2. Read `{process_slug}/pages/docs/requirements.html`, `user-stories.html`, and the root-level `{process_slug}/pages/docs/prd.html`.
-3. Produce the design package under `{process_slug}/pages/docs/` using `.claude/templates/issue-package/page-doc.html.tpl`. Each page embeds Markdown in `<script type="text/markdown" id="docSource">` with a `<!-- version: v1.0 -->` marker and meta tags (`doc-title`, `nav-label`, `nav-group`, `doc-version`, `doc-uid`). Also include the annotation tags `doc-purpose`, `doc-layout`, `doc-fields`, `doc-boundaries`, `doc-exceptions` (and `doc-stories`, `doc-rules`, `doc-refs` when useful) so the portal right panel explains functionality, layout, fields, boundary cases, and exception flows:
-   - `design-review.html`: PM-facing entry point with decision summary, scope, links to all design docs, open questions, and approval checklist.
-   - `scenarios.html`: target users, primary scenarios, boundary scenarios, and non-goals.
-   - `feature-catalog.html`: concise feature list, priority, acceptance mapping, and source requirement links.
-   - `data-model.html`: core entities, fields, constraints, validation rules, and state transitions.
-   - `flows.html`: Mermaid user flow, business flow, screen flow, sequence diagram, and architecture diagram.
-   - `page-map.html`: page inventory, page relationships, navigation, and routing/state notes.
-   - `feasibility.html`: business feasibility, technical feasibility, current official framework/library options, usable open-source projects, risks, and recommended stack.
-   - `version-log.html`: design decision version history and rationale.
-   - `api-list.html`: internal and external APIs/data contracts the feature depends on.
+3. Produce the design package under `{process_slug}/pages/docs/` using `python scripts/lincoln_render.py --stage product-design-docs --target <path> --data <yaml>`. Each page uses the structured doc template; provide a YAML data file with `intro`, `annotations`, and the domain-specific keys below. The renderer injects the annotation metas (`doc-purpose`, `doc-layout`, `doc-fields`, `doc-boundaries`, `doc-exceptions`, plus `doc-stories`, `doc-rules`, `doc-refs` when useful) so the portal right panel explains functionality, layout, fields, boundary cases, and exception flows.
+
+   Common command pattern:
+   ```bash
+   python scripts/lincoln_render.py \
+     --stage product-design-docs \
+     --target issue-<N>/pages/docs/<page>.html \
+     --title "<标题>" --nav-label "<导航标签>" --version v1.0 --uid <uid> \
+     --data issue-<N>/pages/docs/<page>.yaml
+   ```
+
+   Page-specific data keys:
+   - `design-review.html`: `sections` (decision summary, scope, links, open questions, approval checklist).
+   - `scenarios.html`: `sections` plus optional `personas`, `primary`, `boundary`, `non_goals` arrays.
+   - `feature-catalog.html`: `features` array (`id`, `title`, `priority`, `acceptance`, `source`).
+   - `data-model.html`: `entities` array (`name`, `fields`, `constraints`, `states`).
+   - `flows.html`: `flows` array (`name`, `type`, `mermaid`, `steps`).
+   - `page-map.html`: `pages` array (`id`, `title`, `path`, `links`, `notes`).
+   - `feasibility.html`: `sections` plus `risks` and `options` arrays.
+   - `version-log.html`: `sections` plus `entries` array (`version`, `date`, `author`, `changes`, `rationale`).
+   - `api-list.html`: `apis` array (`name`, `method`, `endpoint`, `purpose`, `contract`).
 4. Create the PM→UX handoff contract at `{process_slug}/handoffs/pm-to-ux/pm-to-ux.handoff.yaml` referencing the approved design docs and PRD versions.
 5. Create the human-readable PM→UX handoff portal page at `{process_slug}/pages/docs/handoff-pm-to-ux-v1.0.html` and the narrative master handoff document at `{process_slug}/handoffs/pm-to-ux/master-handoff-pm-to-ux-v1.0.md`. These summarize core decisions, scope, open questions, and the context pack for the receiving UX Agent.
 6. Keep all documents traceable to the approved requirement and transcript timestamps where available.
@@ -44,5 +55,6 @@ Create `{process_slug}/pages/docs/` HTML design documents with enough product, d
 - Use Chinese for PM-facing content unless the requirements are in English.
 - Keep documents short and reviewable; prefer tables and Mermaid diagrams over long prose.
 - For technical frameworks and open-source projects, check current official docs or primary repositories before recommending.
+- Do not create UI specs, field specs, or prototypes in this step. Those are produced in the next stage `product-prototype`.
 - Do not create a Pencil prototype in this step.
 - After approval, tell the user to run: `claude build-product-prototype <session_id> <design_id>`.

package/framework/.claude/skills/lc-build-codebase-knowledge/SKILL.md

@@ -2,6 +2,8 @@
 name: lc-build-codebase-knowledge
 description: Use when starting Lincoln on an existing project with source code but no feature knowledge base yet.
 version: 1.0.0
+outputs:
+  - "knowledge/00-index.md"
 ---
 
 # Lincoln Build Codebase Knowledge

package/framework/.claude/skills/lc-explore-opensource/SKILL.md

@@ -2,6 +2,8 @@
 name: lc-explore-opensource
 description: Use during product design when the requirement can be solved or informed by existing open-source projects.
 version: 1.0.0
+outputs:
+  - "{process_slug}/docs/research/{change_name}-oss-options.md"
 ---
 
 # Lincoln Explore Open Source

package/framework/.claude/skills/lc-market-research/SKILL.md

@@ -9,7 +9,7 @@ inputs:
     description: 研究主题或产品决策背景
     required: false
 outputs:
-  - "{process_slug}/research/{session_id}/market-research.md"
+  - "{process_slug}/research/{session_id}/market.md"
 required_tools:
   - Bash
   - Read

package/framework/.claude/skills/lc-one-id/SKILL.md

@@ -0,0 +1,81 @@
+---
+name: lc-one-id
+description: |
+  查询并维护 Lincoln one-id 索引，按功能点、页面、字段等 ID 定位相关产物。
+  当你需要追溯某个 feature/page/field/doc 对应的设计文档、字段规格、原型页或实现产物时，调用本 skill。
+triggers:
+  - "one-id"
+  - "lincoln_id"
+  - "按 id 查询"
+  - "feature 关联"
+  - "页面 id"
+  - "字段 id"
+inputs:
+  - name: query
+    description: |
+      自然语言查询或 exact CLI 子命令。
+      例如：
+      - "lookup page/web-dashboard"
+      - "related feature/checkout-redesign"
+      - "list --type field"
+      - "create page/list-page --title 列表页 --path issue-9999-test/pages/prototype/web/list/page.html"
+    required: true
+outputs:
+  - one-id 条目详情或关联产物路径列表
+required_tools:
+  - Bash
+  - Read
+---
+
+# lc-one-id
+
+## Purpose
+
+Using [lc-one-id] to 查询并维护 Lincoln one-id 索引。
+
+one-id 是 Lincoln 跨阶段追溯的核心机制：PM/UX 阶段为页面、功能点、字段等建立稳定 ID，UE、研发、QA 阶段通过该 ID 查找相关产物，而不是凭路径猜测。
+
+one-id 索引文件位于 `{process_slug}/.lincoln/one-id/` 下，由 `scripts/lincoln_id.py` 管理。
+
+## When to use
+
+-  downstream 阶段（TDD 计划、实现、验收）需要确认某个 feature/page/field 的上游产物。
+-  创建或更新 one-id 条目时。
+-  检查某个 ID 是否已存在或查找关联项时。
+
+## How to use
+
+本 skill 会把你的 `query` 解析为 `scripts/lincoln_id.py` 命令，并通过 Bash 执行。
+
+常用命令：
+
+- 查询单个条目：
+  ```bash
+  scripts/lincoln_id.py lookup <type>/<id>
+  ```
+
+- 查询某个条目的所有关联项：
+  ```bash
+  scripts/lincoln_id.py related <type>/<id>
+  ```
+
+- 按类型列出所有条目：
+  ```bash
+  scripts/lincoln_id.py list --type <page|feature|field|doc>
+  ```
+
+- 创建或更新条目：
+  ```bash
+  scripts/lincoln_id.py create <type>/<id> \
+    --title "<title>" \
+    --path "<relative-path>" \
+    --source "<origin>" \
+    --relation "<type>/<id>"
+  ```
+
+`scripts/lincoln_id.py` 会自动发现当前工作区最新的 `issue-*/workflow-stage.yaml`，本 skill 不传递 `--state-file`。如果自动发现指向了错误的 issue 包，先让目标包成为最新 mtime，或清理旧沙盒包。
+
+## Output handling
+
+- 如果查询成功，返回条目 YAML 内容或关联列表，并据此读取对应产物文件。
+- 如果 ID 不存在或类型非法，脚本会返回非零退出码；此时应向用户汇报，而不是继续基于缺失信息推进。

package/framework/.claude/skills/lc-one-id/prompts/main.md

@@ -0,0 +1,35 @@
+# lc-one-id
+
+你是 Lincoln 的 one-id 查询助手。你的唯一任务是把用户的查询意图转换为 `scripts/lincoln_id.py` 命令并执行，然后返回结构化结果。
+
+## one-id 类型
+
+允许的类型前缀：
+
+- `page/` — 页面，如 `page/web-dashboard`
+- `feature/` — 功能点，如 `feature/checkout-redesign`
+- `field/` — 字段，如 `field/order-count`
+- `doc/` — 文档，如 `doc/ui-spec`
+
+## 命令映射
+
+| 意图 | Bash 命令 |
+|---|---|
+| 查询单个 ID | `scripts/lincoln_id.py lookup <type>/<id>` |
+| 查询关联项 | `scripts/lincoln_id.py related <type>/<id>` |
+| 按类型列出 | `scripts/lincoln_id.py list --type <type>` |
+| 创建/更新条目 | `scripts/lincoln_id.py create <type>/<id> --title "..." --path "..." --source "..." [--relation "<type>/<id>"]` |
+
+## 执行规则
+
+1.  如果 `query` 已经是合法的 CLI 子命令（如 `lookup page/web-dashboard`），直接拼接到 `scripts/lincoln_id.py` 后执行。
+2.  如果 `query` 是自然语言，先推断意图和 ID，再生成对应命令。
+3.  通过 Bash 运行命令，捕获 stdout/stderr 和 exit code。
+4.  exit code 为 0 时，返回结果摘要和关键字段（`path`、`title`、`relations`）。
+5.  exit code 非 0 时，明确告知用户失败原因，不要基于缺失或错误信息继续假设。
+6.  `lincoln_id.py` 会自动发现当前工作区最新的 `issue-*/workflow-stage.yaml`，不要传递 `--state-file`。如果它指向了错误的 issue 包，先通过 `touch issue-<N>/workflow-stage.yaml` 让目标包成为最新，或清理旧的沙盒包。
+
+## 返回格式
+
+- 成功：用简洁中文说明“查询到 X 个关联项”或“条目详情”，并列出相关产物路径。
+- 失败：说明命令、退出码和错误信息，建议下一步动作。

package/framework/.claude/skills/lc-stakeholder-research/SKILL.md

@@ -9,7 +9,7 @@ inputs:
     description: 研究主题或产品决策背景
     required: false
 outputs:
-  - "{process_slug}/research/{session_id}/stakeholder-research.md"
+  - "{process_slug}/research/{session_id}/stakeholders.md"
 required_tools:
   - Bash
   - Read

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

@@ -2,6 +2,8 @@
 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
+outputs:
+  - "{process_slug}/workflow-stage.yaml"
 ---
 
 # Lincoln Workflow Router

package/framework/.claude/stages/build-codebase-knowledge.yaml

@@ -1,4 +1,4 @@
-schema_version: 2.0.0
+schema_version: 3.0.0
 id: build-codebase-knowledge
 name: Build Codebase Knowledge
 description: 'Scans existing source code and builds knowledge base
@@ -8,31 +8,31 @@ description: 'Scans existing source code and builds knowledge base
   feature knowledge base. Triggered by existing-project-iteration
 
   template after workflow-router.'
-templates:
+workflows:
 - existing-project-iteration
 prerequisite_stage: workflow-router
 next_stage: clarify
 human_gate: false
+execution_mode: solo
+primary_action: lc-build-codebase-knowledge
 agent:
   primary: lc-knowledge-curator
   reviewers:
   - lc-engineer
   handoff_to: lc-pm
 skills:
-  required: []
+  required:
+  - lincoln:lc-build-codebase-knowledge
   optional: []
 artifacts:
   required:
   - knowledge/00-index.md
+references:
+  skill_prompt: .claude/skills/lc-build-codebase-knowledge/SKILL.md
+  agent_guide: .claude/agents/knowledge-curator.md
 context:
   goal: 为已有源码项目构建功能知识库，使后续 PM 迭代能基于事实。
-  constraints: '- 仅通过 scripts/stage_loader.py 更新 {process_slug}/workflow-stage.yaml。
-
-    - 禁止修改 {process_slug}/recordings/ 中的原始文件。
-
-    - 门控评估优先使用 AI 能力：读取产物并推理其完整性，而非仅依赖脚本化检查。
-
-    - 详细执行步骤、模板与工具见对应 skill prompt 和 .claude/agents/<primary_agent>.md。'
+  execution: "调用 lc-build-codebase-knowledge skill 扫描现有源码库，构建业务与技术知识索引，产出 knowledge/00-index.md 与 knowledge/03-features/ 下的功能知识文档，作为后续 PM 迭代的事实基础。"
 gates:
   entry:
   - check: previous_stage_completed

package/framework/.claude/stages/clarify.yaml

@@ -1,13 +1,27 @@
-schema_version: 2.0.0
+schema_version: 3.0.0
 id: clarify
 name: Clarify
 description: 'Explores requirements, resolves ambiguity, and produces
 
   confirmed requirements before design work begins.'
-templates: all
+workflows:
+- bug-fix
+- design-spike
+- existing-project-iteration
+- interview-to-knowledge
+- oss-first-design
 prerequisite_stage: ingest
 next_stage: product-design-docs
 human_gate: true
+execution_mode: both
+primary_action: clarify-requirements
+variables:
+- process_slug
+artifact_templates:
+  '{process_slug}/pages/docs/requirements.html': .claude/templates/issue-package/page-doc-structured.html.tpl
+  '{process_slug}/pages/docs/user-stories.html': .claude/templates/issue-package/page-doc-structured.html.tpl
+  '{process_slug}/pages/docs/prd.html': .claude/templates/issue-package/page-doc-structured.html.tpl
+  '{process_slug}/pages/docs/snapshots/prd-v*.html': .claude/templates/issue-package/page-doc-structured.html.tpl
 agent:
   primary: lc-pm
   reviewers:
@@ -28,21 +42,13 @@ artifacts:
   - '{process_slug}/pages/docs/prd.html'
   optional:
   - '{process_slug}/pages/docs/snapshots/prd-v*.html'
+references:
+  skill_prompt: .claude/skills/clarify-requirements/SKILL.md
+  agent_guide: .claude/agents/pm.md
 context:
   goal: 基于访谈产物（逐字稿、摘要、初始洞察）与人类 PM 进行多轮澄清，形成统一、可追溯、已确认的需求文档，并将 PRD 置于 HTML 门户（{process_slug}/pages/docs/prd.html）作为串联后续所有阶段的主线文档与单一事实来源。人类读者通过 {process_slug}/index.html 浏览所有产物。
-  constraints: '- 仅通过 scripts/stage_loader.py 更新 {process_slug}/workflow-stage.yaml。
-
-    - 禁止修改 {process_slug}/recordings/ 中的原始文件。
-
-    - 本阶段设有 human_gate，必须获得人类 PM 显式确认后才能进入下一阶段。
-
-    - PRD 必须位于 {process_slug}/pages/docs/prd.html，并携带 <!-- version: vX.Y --> 版本标记；确认后通过 scripts/lincoln_prd.py freeze 生成不可变的 pages/docs/snapshots/prd-vX.Y.html 快照。
-
-    - PRD 是产研流程的主线文档，需在后续阶段持续维护「相关产物链接」章节，指向设计、原型、OpenSpec、实现等产物。
-
-    - 门控评估优先使用 AI 能力：读取产物并推理其完整性，而非仅依赖脚本化检查。
-
-    - 详细执行步骤、模板与工具见对应 skill prompt 和 .claude/agents/<primary_agent>.md。'
+  execution: "调用 clarify-requirements skill 与人类 PM 进行多轮澄清对话，基于访谈产物识别歧义并达成共识；产出 requirements/user-stories/prd 三个 HTML 文档，PRD 携带 <!-- version: vX.Y --> 版本标记，确认后通过 scripts/lincoln_prd.py freeze 生成不可变的快照。"
+  constraints: "- PRD 必须位于 {process_slug}/pages/docs/prd.html，并携带 <!-- version: vX.Y --> 版本标记；确认后通过 scripts/lincoln_prd.py freeze 生成不可变的 pages/docs/snapshots/prd-vX.Y.html 快照。\n\n    - PRD 是产研流程的主线文档，需在后续阶段持续维护「相关产物链接」章节，指向设计、原型、OpenSpec、实现等产物。"
 gates:
   entry:
   - check: previous_stage_completed

package/framework/.claude/stages/explore-opensource.yaml

@@ -1,4 +1,4 @@
-schema_version: 2.0.0
+schema_version: 3.0.0
 id: explore-opensource
 name: Explore Open Source
 description: 'Researches existing open-source projects that can inform
@@ -6,31 +6,34 @@ description: 'Researches existing open-source projects that can inform
   or solve the current requirement. Triggered by oss-first-design
 
   template after clarify.'
-templates:
+workflows:
 - oss-first-design
 prerequisite_stage: clarify
 next_stage: product-design-docs
 human_gate: false
+execution_mode: solo
+primary_action: lc-explore-opensource
+variables:
+- process_slug
+- change_name
 agent:
   primary: lc-researcher
   reviewers:
   - lc-engineer
   handoff_to: lc-pm
 skills:
-  required: []
+  required:
+  - lincoln:lc-explore-opensource
   optional: []
 artifacts:
   required:
   - '{process_slug}/docs/research/{change_name}-oss-options.md'
+references:
+  skill_prompt: .claude/skills/lc-explore-opensource/SKILL.md
+  agent_guide: .claude/agents/researcher.md
 context:
   goal: 在设计阶段探索开源方案，避免从零造轮子，并为实现提供参考。
-  constraints: '- 仅通过 scripts/stage_loader.py 更新 {process_slug}/workflow-stage.yaml。
-
-    - 禁止修改 {process_slug}/recordings/ 中的原始文件。
-
-    - 门控评估优先使用 AI 能力：读取产物并推理其完整性，而非仅依赖脚本化检查。
-
-    - 详细执行步骤、模板与工具见对应 skill prompt 和 .claude/agents/<primary_agent>.md。'
+  execution: "调用 lc-explore-opensource skill 调研可复用的开源方案，评估其适配性、许可与维护状况，产出 {process_slug}/docs/research/{change_name}-oss-options.md，为产品设计与实现提供决策参考。"
 gates:
   entry:
   - check: previous_stage_completed