@sushanglewis/lincoln 1.6.3 → 1.8.0

package/framework/.claude/agents/pm.md

@@ -17,8 +17,8 @@ extends:
 
 1. 与人类 PM 多轮对话，将访谈或 issue 输入转化为统一、可追溯、已确认的需求与设计方案。
 2. 维护工作包门户 `index.html`：每新增或重命名一个文档/原型子页面，同步更新导航与「相关产物链接」表。
-3. 维护跨子页面影响关系：PRD、用户故事、数据模型等核心文档变更时，在门户中标注受影响的设计文档与原型页面，使下游阶段知悉影响范围。
-4. 对 designer 的输入完整性负责：PRD、用户故事、数据模型、流程图、页面地图必须完整、一致、无歧义；designer 回退确认时，PM 优先澄清，而非让 designer 自行假设。
+3. 维护跨子页面影响关系：PRD、用户故事、相关者分析、数据模型等核心文档变更时，在门户中标注受影响的设计文档与原型页面，使下游阶段知悉影响范围。
+4. 对 designer 的输入完整性负责：PRD、用户故事、相关者分析、数据模型、流程图、页面地图必须完整、一致、无歧义；designer 回退确认时，PM 优先澄清，而非让 designer 自行假设。
 5. 在 `product-prototype` 阶段以 reviewer 身份确认原型的功能、字段、流程与需求文档一致。
 
 ## 专属规则

package/framework/.claude/agents/security-reviewer.md

@@ -0,0 +1,57 @@
+---
+name: lc-security-reviewer
+description: Lincoln 安全审查员角色，专注于框架策略、hook 门控与实现中的安全风险识别。
+language: zh-CN
+extends:
+- agents/default.md
+model: sonnet
+---
+
+# Lincoln Security Reviewer
+
+你是 Lincoln 工作流中的安全审查员角色。本角色继承通用契约 [`agents/default.md`](agents/default.md)，并补充以下安全专业职责。
+
+## 关注点
+
+1. **策略完整性**
+   - `.claude/policies/*.yaml` 是否覆盖关键风险面（删除、写入、外部调用、git 推送等）。
+   - 策略是否可绕过（前缀命令 `sudo`、`cd &&`、`env VAR=`、路径遍历等）。
+
+2. **Hook 门控**
+   - `pre-tool-use.sh` 是否正确调用 `security_analyzer.py`。
+   - 危险操作（`rm -rf`、递归删除、绝对路径删除、git push）是否触发确认或阻断。
+   - 日志是否记录充分且不泄露敏感信息。
+
+3. **Harness 分发安全**
+   - 生成到 codex / opencode 的适配产物是否保留安全策略语义。
+   - 默认关闭的能力（hooks/skills）是否确实没有在产物中留下痕迹。
+
+4. **实现安全**
+   - 新增脚本是否验证输入、避免命令注入、避免路径遍历。
+   - 外部 API 调用是否经过允许列表或显式确认。
+   - 密钥、token 是否未硬编码。
+
+## 输出格式
+
+在 stage 评审中返回结构化反馈：
+
+```json
+{
+  "risks": [
+    {
+      "severity": "critical|high|medium|low",
+      "category": "policy|hook|harness|implementation|secret",
+      "description": "风险描述",
+      "location": "文件路径:行号",
+      "recommendation": "修复建议"
+    }
+  ],
+  "approvable": true|false
+}
+```
+
+## 工作原则
+
+- 不阻塞合法的研发活动，但对高危操作必须显式标记。
+- 优先使用自动化检查（策略、测试），人工评审作为补充。
+- 所有发现必须可追溯回具体文件与行号。

package/framework/.claude/harnesses/codex.yaml

@@ -1,7 +1,11 @@
 # codex harness manifest
 # 生成:AGENTS.md(项目根,角色契约 + lc-* 命令清单 + 轻量门控)
 #       ~/.codex/prompts/lc-*.md(用户级斜杠命令)
+#       ~/.codex/skills/<skill>/SKILL.md(用户级技能)
 #       .codex-plugin/plugin.json(显式声明 hooks:{} 以关闭默认 hook 回退)
+#       .codex/rules/**/*.md(项目级规则)
+#       .codex/hooks/*.sh(项目级 hook)
+#       .codex/mcp.json(项目级 MCP 配置)
 # spike 备注:codex 官方 docs 对 prompts frontmatter 描述不完整(网络受限),
 # 采用稳妥约定:prompt 文件为纯 markdown 正文;若真实 CLI 验证不符,
 # 移除 prompts target,命令说明已在 AGENTS.md 内联(回退方案零成本)。
@@ -13,8 +17,8 @@ capabilities:
   # (superpowers codex hooks 陷阱 obra/superpowers@7d8d3d4——hooks 字段缺失时
   # codex 回退到默认 hooks/hooks.json)。新增能力必须显式写出;空能力显式置 false,
   # 不得省略字段。验收测试:tests/test_harness_default_off.py
-  hooks: false
-  skills: false
+  hooks: true
+  skills: true
   agents: true        # 经 AGENTS.md 拼接承载
   commands: true
 
@@ -33,6 +37,31 @@ targets:
     scope: home
     transform: command-template
 
+  - kind: skill
+    source: .claude/skills/*/SKILL.md
+    output: "{home}/.codex/skills/{parent}/{name}.md"
+    scope: home
+    transform: copy
+
+  - kind: rule
+    source: .claude/rules/**/*.md
+    output: "{project}/.codex/rules/{relative_path}.md"
+    scope: project
+    transform: copy
+    optional: true
+
+  - kind: hook
+    source: .claude/hooks/*.sh
+    output: "{project}/.codex/hooks/{name}.sh"
+    scope: project
+    transform: copy
+
+  - kind: mcp
+    source: .claude/mcp/mcp.yaml
+    output: "{project}/.codex/mcp.json"
+    scope: project
+    transform: mcp-config
+
   - kind: plugin
     source: .claude-plugin/plugin.json
     output: "{project}/.codex-plugin/{name}.json"

package/framework/.claude/harnesses/command-map.yaml

@@ -244,6 +244,10 @@ commands:
     description: 已有源码项目的 Lincoln 迭代工作流
     action: python3 "$LINCOLN_ROOT/scripts/lincoln_workflow.py"
     args_hint: start --workflow existing-project-iteration
+  lc-wf-framework-self-improvement:
+    description: Lincoln 框架自身持续改进工作流（安全门控、harness 分发、摩擦学习、事件追踪、子代理委托）
+    action: python3 "$LINCOLN_ROOT/scripts/lincoln_workflow.py"
+    args_hint: start --workflow framework-self-improvement --issue-number <N>
   lc-wf-interview-to-knowledge:
     description: 从访谈录音到 GitHub Issues 再到 Obsidian 知识库沉淀的标准工作流
     action: python3 "$LINCOLN_ROOT/scripts/lincoln_workflow.py"

package/framework/.claude/harnesses/opencode.yaml

@@ -1,5 +1,10 @@
 # opencode harness manifest
-# 生成:.opencode/agent/*.md(角色)+ .opencode/command/lc-*.md(命令)
+# 生成:.opencode/agent/*.md(角色)
+#       .opencode/command/lc-*.md(命令)
+#       .opencode/skills/<skill>/SKILL.md(项目级技能)
+#       .opencode/rules/**/*.md(项目级规则)
+#       .opencode/hooks/*.sh(项目级 hook)
+#       .opencode/mcp.json(项目级 MCP 配置)
 # spike 结论(Context7 /anomalyco/opencode):
 #   agent frontmatter 字段:description/mode/model/temperature/tools/permission
 #   command 文件:frontmatter(description/agent/model)+ 正文模板($ARGUMENTS)
@@ -10,8 +15,8 @@ capabilities:
   # 缺省即关闭(#64):任何未显式声明的能力都可能被 harness 按默认值激活
   # (superpowers codex hooks 陷阱 obra/superpowers@7d8d3d4)。新增能力必须显式写出;
   # 空能力显式置 false,不得省略字段。验收测试:tests/test_harness_default_off.py
-  hooks: false        # 用插件(.opencode/plugin)替代,本版本从轻不生成
-  skills: false       # 以 agent/command 提示词承载
+  hooks: true
+  skills: true
   agents: true
   commands: true
 
@@ -30,3 +35,28 @@ targets:
     output: "{project}/.opencode/command/{name}.md"
     scope: project
     transform: command-template
+
+  - kind: skill
+    source: .claude/skills/*/SKILL.md
+    output: "{project}/.opencode/skills/{parent}/{name}.md"
+    scope: project
+    transform: copy
+
+  - kind: rule
+    source: .claude/rules/**/*.md
+    output: "{project}/.opencode/rules/{relative_path}.md"
+    scope: project
+    transform: copy
+    optional: true
+
+  - kind: hook
+    source: .claude/hooks/*.sh
+    output: "{project}/.opencode/hooks/{name}.sh"
+    scope: project
+    transform: copy
+
+  - kind: mcp
+    source: .claude/mcp/mcp.yaml
+    output: "{project}/.opencode/mcp.json"
+    scope: project
+    transform: mcp-config

package/framework/.claude/hooks/hooks.yaml

@@ -0,0 +1,37 @@
+---
+schema_version: 1.0.0
+description: |
+  Declarative hook registry for Lincoln.
+  Each entry declares the shell hook file, the events it handles, the harnesses
+  it applies to, and its execution order. Lower order values run first.
+
+hooks:
+  - name: pre-tool-use
+    file: pre-tool-use.sh
+    events: [pre_tool_use]
+    harnesses: [claude-code, codex, opencode]
+    order: 10
+
+  - name: on-session-start
+    file: on-session-start.sh
+    events: [session_start]
+    harnesses: [claude-code]
+    order: 10
+
+  - name: on-stop
+    file: on-stop.sh
+    events: [session_stop]
+    harnesses: [claude-code]
+    order: 10
+
+  - name: post-tool-use
+    file: post-tool-use.sh
+    events: [post_tool_use]
+    harnesses: [claude-code]
+    order: 10
+
+  - name: on-pr-event
+    file: on-pr-event.sh
+    events: [pull_request]
+    harnesses: [claude-code]
+    order: 10

package/framework/.claude/hooks/on-session-start.sh

@@ -263,7 +263,22 @@ echo "Design ID: ${DESIGN_ID:-(unset)}"
 echo "Waiting for: $WAITING_FOR"
 echo ""
 
-# 4. Load stage context, agent role, and workflow template (summaries only)
+# 4. Recall relevant knowledge before injecting full context.
+RECALL_JSON=$("$PYTHON" "$FRAMEWORK_ROOT/scripts/lincoln_recall.py" \
+    --query "$CURRENT_STAGE" \
+    --top-k 5 \
+    --format json \
+    2>/dev/null || echo '{"docs":[]}')
+_RECALL_COUNT=$(echo "$RECALL_JSON" | "$PYTHON" -c "import sys,json; print(len(json.load(sys.stdin).get('docs',[])))" 2>/dev/null || echo 0)
+if [[ "$_RECALL_COUNT" -gt 0 ]]; then
+    echo "=== Lincoln 相关知识 ==="
+    echo "$RECALL_JSON" | "$PYTHON" -c "import sys,json; docs=json.load(sys.stdin).get('docs',[]); [print(f'- [{d[\"title\"]}]({d[\"path\"]}) — score {d[\"score\"]}') for d in docs]"
+    echo ""
+    echo "=== End Lincoln 相关知识 ==="
+    echo ""
+fi
+
+# 5. Load stage context, agent role, and workflow template (summaries only)
 if [[ "$CURRENT_STAGE" != "not_started" ]]; then
     STAGE_YAML="$FRAMEWORK_ROOT/.claude/stages/$CURRENT_STAGE.yaml"
     if [[ -f "$STAGE_YAML" ]]; then
@@ -339,7 +354,7 @@ else
     NEEDS_OPENING_GUIDANCE="true"
 fi
 
-# 5. Load Conductor / OMC context
+# 6. Load Conductor / OMC context
 if [[ -d "$ROOT/.context" || -d "$ROOT/.omc" ]]; then
     echo "=== Conductor / OMC Context ==="
     for dir in "$ROOT/.context" "$ROOT/.omc"; do
@@ -362,7 +377,7 @@ if [[ -d "$ROOT/.context" || -d "$ROOT/.omc" ]]; then
     echo ""
 fi
 
-# 6. Read last node handoff
+# 7. Read last node handoff
 HANDOFF_FILE=""
 if [[ "$LAST_NODE" != "{}" ]]; then
     HANDOFF_FILE=$(echo "$LAST_NODE" | "$PYTHON" -c "import sys,json; print(json.load(sys.stdin).get('handoff_file',''))" 2>/dev/null || echo "")
@@ -387,7 +402,7 @@ if [[ -n "$PROCESS_SLUG" && -d "$ROOT/$PROCESS_SLUG/handoffs" ]]; then
     fi
 fi
 
-# 7. Run status summary
+# 8. Run status summary
 STATUS_OUTPUT=$("$PYTHON" "$FRAMEWORK_ROOT/scripts/lincoln-status.py" --format markdown --state-file "$STATE_FILE" 2>/dev/null) || STATUS_OUTPUT=""
 if [[ -n "$STATUS_OUTPUT" ]]; then
     echo "=== Lincoln Status Summary ==="
@@ -396,7 +411,7 @@ if [[ -n "$STATUS_OUTPUT" ]]; then
     echo ""
 fi
 
-# 8. Opening guidance for a work package that has not started yet
+# 9. Opening guidance for a work package that has not started yet
 if [[ "${NEEDS_OPENING_GUIDANCE:-}" == "true" ]]; then
     _LINCOLN_GUIDANCE_INJECTED="true"
     echo "=== Lincoln 开场引导 ==="

package/framework/.claude/hooks/on-stop.sh

@@ -101,4 +101,26 @@ if [[ -n "$CURRENT_STAGE" && ( "$STAGE_STATUS" == "waiting_for_human" || "$STAGE
         >/dev/null 2>&1 || true
 fi
 
+# Record session stop lifecycle event (best-effort).
+"$PYTHON" - "$STATE_FILE" "$FRAMEWORK_ROOT" <<'PY' >/dev/null 2>&1 || true
+import sys
+sys.path.insert(0, sys.argv[2])
+from pathlib import Path
+from scripts import lincoln_trace
+lincoln_trace.append_event_entry(
+    Path(sys.argv[1]),
+    "session",
+    {"event_type": "session_ended"},
+)
+PY
+
+# Score session friction asynchronously; failures must not block hook exit.
+(
+    "$PYTHON" "$FRAMEWORK_ROOT/scripts/lincoln_friction.py" \
+        --root "$FRAMEWORK_ROOT" \
+        --state-file "$STATE_FILE" \
+        --tail-lines 500 \
+        >/dev/null 2>&1 || true
+) &
+
 exit 0

package/framework/.claude/hooks/pre-tool-use.sh

@@ -220,6 +220,28 @@ if [[ "$STAGE_STATUS" == "not_started" || "$STAGE_STATUS" == "entry_validating"
     fi
 fi
 
+# SecurityAnalyzer: evaluate side-effect tools against risk policy.
+# File deletion requires explicit human confirmation; git push / API calls are logged.
+if is_side_effect "$TOOL_NAME"; then
+    SECURITY_LOG_DIR="$FRAMEWORK_ROOT/$PROCESS_SLUG/logs"
+    SECURITY_RESULT=$("$PYTHON" "$FRAMEWORK_ROOT/scripts/security_analyzer.py" \
+        --root "$FRAMEWORK_ROOT" \
+        --tool "$TOOL_NAME" \
+        --args "$TOOL_ARGS" \
+        --process-slug "$PROCESS_SLUG" \
+        --log-dir "$SECURITY_LOG_DIR" \
+        2>/dev/null || echo '{"level":"unknown","confirm_required":true,"message":"Security analyzer failed."}')
+
+    CONFIRM_REQUIRED=$(echo "$SECURITY_RESULT" | "$PYTHON" -c 'import sys,json; print(json.load(sys.stdin).get("confirm_required", False))')
+    SECURITY_MESSAGE=$(echo "$SECURITY_RESULT" | "$PYTHON" -c 'import sys,json; print(json.load(sys.stdin).get("message", ""))')
+
+    if [[ "$CONFIRM_REQUIRED" == "True" ]]; then
+        echo "BLOCKED: $SECURITY_MESSAGE" >&2
+        echo "Run: $PYTHON $FRAMEWORK_ROOT/scripts/stage_loader.py --stage $CURRENT_STAGE --action approve-gate --approved-by human-pm" >&2
+        exit 1
+    fi
+fi
+
 # When paused/waiting_for_human/validation_failed, only allow read-only tools
 if [[ "$STAGE_STATUS" == "paused" || "$STAGE_STATUS" == "waiting_for_human" || "$STAGE_STATUS" == "validation_failed" ]]; then
     if [[ "$TOOL_NAME" != "Read" && "$TOOL_NAME" != "Grep" && "$TOOL_NAME" != "Glob" ]]; then

package/framework/.claude/mcp/mcp.yaml

@@ -0,0 +1,34 @@
+---
+schema_version: 1.0.0
+description: |
+  Declarative MCP server configuration for Lincoln.
+  This file is the single source of truth; `scripts/lincoln_harness_adapter.py`
+  distributes it to Codex / OpenCode harnesses in their native formats.
+  Sensitive values use `${VAR}` placeholders and are resolved from `.env` or the
+  runtime environment. Never commit real secrets.
+
+servers:
+  pencil:
+    command: npx
+    args:
+      - "-y"
+      - "@pencil/mcp-server"
+    env:
+      PENCIL_API_KEY: ${PENCIL_API_KEY}
+    enabled: true
+    description: Pencil design-file MCP server for .pen import/export.
+    harness_overrides:
+      codex:
+        enabled: false
+      opencode:
+        enabled: false
+
+  github:
+    command: npx
+    args:
+      - "-y"
+      - "@modelcontextprotocol/server-github"
+    env:
+      GITHUB_PERSONAL_ACCESS_TOKEN: ${GITHUB_PERSONAL_ACCESS_TOKEN}
+    enabled: true
+    description: GitHub operations - issues, PRs, repos.

package/framework/.claude/policies/friction.yaml

@@ -0,0 +1,18 @@
+schema_version: 1.0.0
+thresholds:
+  prompt_user: 5
+  auto_suggest: 3
+weights:
+  tool_failed: 2
+  tool_rejected: 3
+  retry_spike: 3
+  human_override: 5
+  long_session: 1
+long_session_minutes: 30
+retry_count_threshold: 3
+signals:
+  - tool_failed
+  - tool_rejected
+  - retry_spike
+  - human_override
+  - long_session

package/framework/.claude/policies/security.yaml

@@ -0,0 +1,46 @@
+schema_version: 1.0.0
+policies:
+  - name: recursive-delete
+    tool: Bash
+    condition: 'command matches "rm -r" or "rm -rf"'
+    level: high
+    message: "递归删除风险极高，需人工确认。"
+    confirm: true
+
+  - name: file-deletion
+    tool: Bash
+    condition: 'command matches any of ["rm", "rmdir"]'
+    level: high
+    message: "文件/目录删除操作不可逆，需人工确认。"
+    confirm: true
+
+  - name: git-push
+    tool: Bash
+    condition: 'command matches "git push"'
+    level: medium
+    message: "git push 将改变远程仓库状态。"
+    confirm: false
+    log: true
+
+  - name: external-api-call
+    tool: Bash
+    condition: 'command matches any external HTTP client (curl, wget, httpie)'
+    level: medium
+    message: "正在调用外部 API。"
+    confirm: false
+    log: true
+
+  - name: file-write-outside-process
+    tool: Write|Edit
+    condition: "target outside current process_slug"
+    level: high
+    message: "不允许写入当前 issue 工作包之外的产物目录。"
+    confirm: true
+
+  - name: file-write-inside-process
+    tool: Write|Edit
+    condition: "target inside current process_slug"
+    level: medium
+    message: "写入当前 issue 工作包内的文件。"
+    confirm: false
+    log: true

package/framework/.claude/schemas/design-review-feedback.json

@@ -0,0 +1,32 @@
+{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "title": "Design Review Feedback",
+  "type": "object",
+  "required": ["findings"],
+  "properties": {
+    "findings": {
+      "type": "array",
+      "items": {
+        "type": "object",
+        "required": ["severity", "summary"],
+        "properties": {
+          "severity": {
+            "type": "string",
+            "enum": ["critical", "high", "medium", "low"]
+          },
+          "summary": {
+            "type": "string",
+            "maxLength": 500
+          },
+          "file": {
+            "type": "string"
+          },
+          "recommendation": {
+            "type": "string",
+            "maxLength": 1000
+          }
+        }
+      }
+    }
+  }
+}

package/framework/.claude/schemas/stage-definition.schema.json

@@ -100,6 +100,28 @@
             { "type": "null" }
           ],
           "description": "Agent role to hand off to at stage end"
+        },
+        "parallel_specialists": {
+          "type": "array",
+          "items": {
+            "type": "string",
+            "pattern": "^[a-z][a-z0-9-]*$"
+          },
+          "default": [],
+          "description": "Specialist agents that may be invoked in parallel during this stage"
+        },
+        "merge_strategy": {
+          "type": "string",
+          "enum": ["priority", "vote", "consensus"],
+          "default": "priority",
+          "description": "How to combine outputs from parallel specialists"
+        },
+        "output_schema": {
+          "oneOf": [
+            { "type": "string", "minLength": 1 },
+            { "type": "null" }
+          ],
+          "description": "JSON Schema path for structured specialist outputs"
         }
       },
       "additionalProperties": false

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

@@ -60,7 +60,9 @@ You may still read the categorized example templates under `.claude/templates/is
 
    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.
+5. **Plan prototype generation granularity.** Before writing prototype pages, derive a **角色×场景矩阵** from `scenarios.html` and `page-map.html`: rows are the user roles/personas, columns are the key scenarios (including boundary cases such as empty, loading, error, success). Every cell that a real user can reach must map to exactly one prototype sub-page; the matrix itself is written into `ui-spec.html` (章节 `## 角色×场景矩阵`) and serves as the splitting contract. Then group the sub-pages 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.
+
+   Each cluster is organized by one main shell page (e.g. `pages/prototype/{app,web,mobile}/main/page.html`) whose `navItems` link to all sub-pages of that cluster, so the portal viewer can walk every role/scenario state from a single entry page.
 
 6. Create interactive HTML prototypes under `{process_slug}/pages/prototype/{app,web,mobile}/` using the structured prototype renderer:
 
@@ -112,6 +114,7 @@ You may still read the categorized example templates under `.claude/templates/is
    - 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="...">` (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.
+   - State the applicable role(s), scenario, page state (default / empty / loading / error / success), and which functions are visible and usable in that state via the `doc-purpose`, `doc-rules`, and `doc-boundaries` annotations, so each sub-page precisely depicts what a given role sees and can do in that case.
    - 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).
@@ -131,6 +134,8 @@ You may still read the categorized example templates under `.claude/templates/is
 
 ## Rules
 
+- `fields.html` and `ui-spec.html` are doc pages: each opens with `## 页面意图` and `## 边界`, follows standard Markdown structure (single H1, H2 chapters, tables over prose), and links instead of duplicating content from `flows.html` / `page-map.html` / `scenarios.html`.
+- The prototype sub-pages are the interactive GUI evidence for the PM stage: each one must precisely depict the page state and available functions of a specific role in a specific scenario (see the 角色×场景矩阵 in `ui-spec.html`). Do not merge multiple roles/scenarios into one page when their visible states differ.
 - The HTML prototype is the primary review artifact; Pencil is optional.
 - Always reuse the shared `prototype.css` and `prototype.js` assets. Do not inline all styles or rebuild the component library from scratch.
 - Keep controls and states complete enough for implementation: default, hover/focus where relevant, disabled, empty, loading, error, and success.

package/framework/.claude/skills/clarify-requirements/SKILL.md

@@ -10,6 +10,7 @@ inputs:
     required: true
 outputs:
   - "{process_slug}/pages/docs/requirements.html"
+  - "{process_slug}/pages/docs/stakeholders.html"
   - "{process_slug}/pages/docs/user-stories.html"
   - "{process_slug}/pages/docs/prd.html"
   - "{process_slug}/pages/docs/snapshots/prd-v*.html"

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

@@ -33,11 +33,44 @@ Produce a clear, agreed-upon `{process_slug}/pages/docs/requirements.html` and t
    Write `{process_slug}/pages/docs/requirements.md` as a regular Markdown document. Use H2 headings for the major chapters (e.g. `## 背景`, `## 问题`, `## 用户`, `## 方案`, `## 验收标准`, `## 非目标`, `## 开放问题`). Within each chapter you may use paragraphs, bullet lists, tables, and ` ```mermaid ` diagrams freely. If a rigid table (e.g. a user-story table) is clearer, you may still create a YAML `--data` file and use `page-doc-structured.html.tpl`.
 
    The renderer will derive `nav-label`, `version`, and `uid` automatically if omitted. Include `<!-- version: v1.0 -->` near the top of the Markdown file.
-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.md` based on the answers and re-render `requirements.html` (always rewrite the Markdown source and re-render; do not mutate HTML in-place).
-6. Repeat until the PM confirms the requirements are clear.
-7. Also generate `{process_slug}/pages/docs/user-stories.html`. You may either write a Markdown file or use the structured renderer with `--data` containing a `stories` array, whichever fits the material:
+3. Perform a stakeholder analysis and produce `{process_slug}/pages/docs/stakeholders.html`.
+
+   First, check whether `{process_slug}/research/{session_id}/stakeholders.md` already exists from the `pm-research` workflow. If it does, read it and use it as a starting point rather than starting from scratch.
+
+   Identify all stakeholders that are relevant to the requirement. For each stakeholder, capture at least the following dimensions in a structured table:
+
+   | Dimension | Description |
+   |-----------|-------------|
+   | 角色名称 | A concise role label (e.g., 最终用户, 需求提出方, 建设方, 运营方, 成本承担方, 方向决策者, 影响者/守门人). |
+   | 具体是谁 | The actual person, team, or group, if known. |
+   | 与需求的关系 | How they interact with the product or requirement. |
+   | 权力/影响力 | Their ability to affect decisions or outcomes (高/中/低 + 一句话说明). |
+   | 利益诉求 | What they want from this product or requirement. |
+   | 经济价值 | Monetary, efficiency, or cost-related value they gain or lose. |
+   | 情绪价值 | Emotional or experiential value (e.g., 愉悦感, 安全感, 掌控感, 归属感). |
+   | 个人实现价值 | Self-actualization value (e.g., 成长, 成就感, 认同感, 影响力). |
+   | 心理预期 | Their implicit expectations, anxieties, or assumptions. |
+   | 潜在冲突 | Tensions or misalignments with other stakeholders. |
+   | 应对策略 | How the product team should engage or satisfy this stakeholder. |
+
+   Also capture stakeholder relationships: who depends on whom, who can block whom, and who shares goals.
+
+   Render the artifact:
+
+   ```bash
+   python scripts/lincoln_render.py \
+     --stage clarify \
+     --target {process_slug}/pages/docs/stakeholders.html \
+     --title "相关者分析" \
+     --markdown {process_slug}/pages/docs/stakeholders.md
+   ```
+
+   Write `{process_slug}/pages/docs/stakeholders.md` as a regular Markdown document with H2 chapters such as `## 相关者清单`, `## 关系与冲突`, `## 关键洞察`, `## 开放问题`. Include `<!-- version: v1.0 -->` near the top.
+4. Identify 1-3 ambiguities or missing details, and tag each with its Johari quadrant (认知象限): 知道自己知道 → 复述确认题; 知道自己不知道 → 直接回答 + coach; 不知道自己知道 → 展示已有资产; 不知道自己不知道 → 探查题.
+5. Ask the human PM these questions one batch at a time in the terminal, using the quadrant-appropriate style.
+6. Update `requirements.md` and `stakeholders.md` based on the answers and re-render both `requirements.html` and `stakeholders.html` (always rewrite the Markdown source and re-render; do not mutate HTML in-place).
+7. Repeat until the PM confirms the requirements are clear.
+8. Also generate `{process_slug}/pages/docs/user-stories.html`. You may either write a Markdown file or use the structured renderer with `--data` containing a `stories` array, whichever fits the material:
 
    ```bash
    python scripts/lincoln_render.py \
@@ -47,7 +80,7 @@ Produce a clear, agreed-upon `{process_slug}/pages/docs/requirements.html` and t
      --markdown {process_slug}/pages/docs/user-stories.md
    ```
 
-8. Generate the root-level PRD at `{process_slug}/pages/docs/prd.html` using the Markdown-first renderer:
+9. Generate the root-level PRD at `{process_slug}/pages/docs/prd.html` using the Markdown-first renderer:
 
    ```bash
    python scripts/lincoln_render.py \
@@ -73,17 +106,23 @@ Produce a clear, agreed-upon `{process_slug}/pages/docs/requirements.html` and t
    It must also carry:
    - `<!-- version: v1.0 -->` marker (added automatically by the renderer from the Markdown file or `--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`.
+10. When the PM confirms, add an approval marker inside `requirements.html`: `<!-- status: approved -->`.
+11. After human approval, run `python scripts/lincoln_prd.py freeze` to create the immutable snapshot `{process_slug}/pages/docs/snapshots/prd-v1.0.html`.
+12. 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`.
 
 ## Human Interaction Rules
 
 - Ask at most 3 questions per turn.
 - After each answer, update the document and show the changed sections.
-- If the PM edits `requirements.html` or `prd.html` directly and runs `workflow-continue`, re-read the file and continue from there.
+- If the PM edits `requirements.html`, `stakeholders.html`, or `prd.html` directly and runs `workflow-continue`, re-read the file and continue from there.
 - Do not proceed to the next step until the PM explicitly confirms (e.g., says "confirm" or "确认").
 
+## 页面纪律
+
+- Every document page opens with `## 页面意图` (目标读者 + 本页回答什么问题) and `## 边界` (本页不覆盖什么 + 单一事实来源链接).
+- Content follows standard Markdown: a single H1, H2 chapters, and tables/Mermaid over long prose. Never duplicate content across pages — link to the single source of truth instead.
+- These pages are business-facing: 需求背景、用户角色、旅程、业务状态、业务流程、验收标准. Technical research or solution comparisons performed while clarifying are only background for the PM's decision — do not register them into any page; they may be summarized later into the archived `feasibility.html` by the design stage.
+
 ## 认知象限确认（Johari）
 
 澄清问题按 Johari 四象限设计与标注：
@@ -103,6 +142,7 @@ Produce a clear, agreed-upon `{process_slug}/pages/docs/requirements.html` and t
 ## Output Artifacts
 
 - `{process_slug}/pages/docs/requirements.html`
+- `{process_slug}/pages/docs/stakeholders.html`
 - `{process_slug}/pages/docs/user-stories.html`
 - `{process_slug}/pages/docs/prd.html` (root-level PRD, versioned)
 - `{process_slug}/pages/docs/snapshots/prd-v1.0.html` (immutable snapshot after approval)

package/framework/.claude/skills/draft-product-design/SKILL.md

@@ -13,6 +13,7 @@ inputs:
     required: true
 outputs:
   - "{process_slug}/pages/docs/design-review.html"
+  - "{process_slug}/pages/docs/decisions.html"
   - "{process_slug}/pages/docs/scenarios.html"
   - "{process_slug}/pages/docs/feature-catalog.html"
   - "{process_slug}/pages/docs/data-model.html"