@ccoalm/ccl-skills 0.1.0

package/dist/assets/marketplace/plugins/ccl-skills/skills/release-doc-writer/SKILL.md

@@ -0,0 +1,64 @@
+---
+name: release-doc-writer
+description: 提测文档 / 上线文档 / 发布文档 / test handoff / release doc / launch notes / 补上线范围 / 发布证据 → write, fill, or review test-handoff and release-document substance from Git/config/deploy/verification evidence without owning release orchestration, merge authorization, or production mutation.
+---
+
+# Release Doc Writer（提测 / 上线文档编写）
+
+Use this skill when the task is to write, fill, review, or update test-handoff, release, or launch documentation: delivery scope, config changes, migrations, dependencies, scripts, worker/queue decisions, verification evidence, rollback notes, MR handoff notes, or Feishu/Lark handoff sections.
+
+This skill owns **document substance and evidence discipline**. It does **not** authorize deployment, merge, tag, production mutation, branch reset, or overall release orchestration. For full production release coordination, use `release-coordination`.
+
+## Skip / route
+
+- Full production release lifecycle, MR merge authorization, tag gate, pipeline follow-up, post-release reset → `release-coordination`.
+- Rollout/canary/rollback strategy or live deploy/config control plane → `platform-release-engineering`.
+- Risk gate decision before release → `feature-risk-router`.
+- What tests to run or how to prove behavior → `testing-strategy`.
+- Active production error or failed smoke → `defect-diagnosis`.
+- Pure wording polish after facts are fixed → `tighten-doc`.
+- Actual Feishu/Lark API mechanics → the corresponding document tooling.
+
+## Evidence workflow
+
+1. **Establish source range** — identify repo/service list, base ref, head ref, and whether the evidence is commit log, changed-file summary, line-level diff, CI output, runtime state, or document read-back.
+2. **Write scope from evidence** — group by user-visible or operational capability; do not infer scope from branch names, MR titles, memory, or another model's summary alone.
+3. **Scope confirmation handoff** — if the actual diff/log scope is broader or narrower than the stated release intent, stop and route the release decision back to `release-coordination` before writing it as settled fact.
+4. **Config gate** — before writing “no config change”, check config definitions/defaults, usage sites, deployment/config surfaces, and absent-value behavior enough to justify the claim.
+5. **Operational sections** — inspect touched migrations, jobs, dependencies, external services, workers, queues, scripts, and enable/disable flags; record enabled, intentionally disabled, deferred, and not-run decisions.
+6. **Testing scope section** — write planned/needed test coverage from confirmed diff; route full matrix or command design to `testing-strategy`.
+7. **Verification section** — list only tests, CI, smoke, runtime checks, logs, or metrics actually run or observed. Otherwise say `未验证 / 待验证`.
+8. **Rollback notes** — write concrete rollback constraints evidenced by diff/config/data/runtime state; route strategy design to `platform-release-engineering`.
+9. **Read back edits** — after editing collaborative docs, re-fetch the edited section and comment state when available.
+
+## Comment-safe document editing
+
+- Inspect the target section and existing comments before editing.
+- Avoid full-document replacement when comments or anchors exist.
+- Preserve existing structure: table stays table, list stays list, heading hierarchy stays unchanged.
+- Replace placeholders or target cells/blocks narrowly; append only when no placeholder exists.
+- Do not overwrite unrelated sections.
+
+## MR handoff boundary
+
+If the task includes preparing MR/PR handoff text, the release document should be updated first and the MR description should cite the document and decisions. Creating or updating an MR is not merge authorization; route merge authorization and lifecycle sequencing to `release-coordination`.
+
+## Minimal checklist
+
+- [ ] Repos/services and base/head refs recorded.
+- [ ] Scope based on Git diff/log or equivalent first-hand evidence.
+- [ ] Scope mismatch, over-broad branches, or target-ref drift routed back to `release-coordination` instead of being written as confirmed.
+- [ ] Testing scope section output from diff evidence, or imported from `release-coordination`, and not treated as executed verification.
+- [ ] Config/default/usage/deploy surfaces checked.
+- [ ] Migrations/jobs/dependencies/scripts/workers/queues checked where touched.
+- [ ] Enabled, disabled, deferred, and not-run decisions documented.
+- [ ] Verification claims match actual evidence depth.
+- [ ] Collaborative doc edits are narrow and comment-safe.
+- [ ] Edited section read back.
+- [ ] Final response states evidence depth and gaps.
+
+## References
+
+- `references/release-evidence-workflow.md`
+- `references/comment-safe-release-doc.md`
+- `references/release-testing-scope-section.md`

package/dist/assets/marketplace/plugins/ccl-skills/skills/release-doc-writer/agents/openai.yaml

@@ -0,0 +1,4 @@
+interface:
+  display_name: "Release Doc Writer"
+  short_description: "Write release docs from evidence"
+  default_prompt: "Use $release-doc-writer to fill release scope, config changes, operational decisions, verification evidence, and rollback notes from first-hand evidence."

package/dist/assets/marketplace/plugins/ccl-skills/skills/release-doc-writer/references/comment-safe-release-doc.md

@@ -0,0 +1,19 @@
+# Comment-safe Release-doc Editing
+
+For collaborative release documents:
+
+1. Resolve the actual document and target section.
+2. Fetch the section with stable block/table/list identifiers when the tooling supports it.
+3. List comments or anchors before editing.
+4. Edit only target blocks, table cells, rows, or list items.
+5. Preserve document structure and heading hierarchy.
+6. Re-fetch the edited section and comment state after editing.
+
+Avoid:
+
+- Replacing the whole document body.
+- Flattening tables into prose or lists.
+- Deleting placeholders that carry comment anchors.
+- Claiming a doc was updated without read-back evidence.
+
+Final responses should state the edited section, read-back marker, comment status, and evidence limitations.

package/dist/assets/marketplace/plugins/ccl-skills/skills/release-doc-writer/references/release-evidence-workflow.md

@@ -0,0 +1,23 @@
+# Release Evidence Workflow
+
+Release docs must separate evidence depth from conclusions.
+
+Evidence classes:
+
+- `commit-log`: commits in the release range were inspected.
+- `changed-file-summary`: file paths/status/stat were inspected.
+- `line-level-diff`: relevant hunks were inspected.
+- `config-surface`: definitions/defaults/usages/deploy injection were inspected.
+- `ci-observed`: CI or test output was read.
+- `runtime-observed`: live or staged runtime state was read.
+- `doc-readback`: edited document section was fetched after edit.
+
+Rules:
+
+- “No config change” requires config-surface evidence, not memory.
+- “Tests passed” requires a specific observed run.
+- A testing-scope section is required for release docs with scope/verification/handoff content. It is planned coverage, not verification evidence; only list it as executed verification after a concrete run or observed result exists.
+- “Script not needed” must become either “script absent/not touched” or “script exists and is intentionally not run this release”.
+- Deferred flags, workers, queues, and scripts still belong in the doc when the diff contains the capability.
+- Do not make module-level diff review sound like a full line-level audit.
+- If the evidence range is much broader than the intended release, or the target/base ref changed after the document was drafted, stop and route scope confirmation back to `release-coordination`; do not silently rewrite the doc as if the scope were settled.

package/dist/assets/marketplace/plugins/ccl-skills/skills/release-doc-writer/references/release-testing-scope-section.md

@@ -0,0 +1,15 @@
+# Release Testing Scope Section
+
+When writing a release document, include a testing-scope section whenever the document has release scope, verification, or handoff sections.
+
+Derive it from confirmed diff evidence, not branch names or memory. If `release-coordination` already produced a test-scope prompt, import it and adapt it to the document structure.
+
+Recommended fields:
+
+- **Must-cover capabilities**: changed user journeys, APIs/contracts, admin/operator paths, compatibility modes.
+- **Operational checks**: config/defaults, migrations, scripts, jobs, workers, queues, dependencies, external integrations, deploy surfaces.
+- **Regression focus**: touched modules, direct consumers, adjacent paths, frozen past failures, rollback-sensitive paths.
+- **Smoke suggestions**: minimal pre-release/post-release smoke needed for confidence.
+- **Open gaps**: live-only checks, unavailable environments, manual owners, or items needing `testing-strategy`.
+
+Do not write the testing-scope section as verification evidence. Verification evidence must cite actual runs or observations. If the user asks for layer choice, scenario matrix, mocks/fixtures, E2E versus integration choice, executable tests, or CI gate design, route to `testing-strategy`.

package/dist/assets/marketplace/plugins/ccl-skills/skills/requirement-baseline/SKILL.md

@@ -0,0 +1,87 @@
+---
+name: requirement-baseline
+description: 现状盘点 / 当前能力梳理 / 现有流程、页面、API、数据、运营规则盘点 / as-is audit / current state inventory —— 交付物是**现状清单本身**：现在怎么运作、已有哪些能力与例外、事实来源与 freshness、缺口和冲突，含按 commit 固定的代码现状取证。Skip 要的是意图、用户故事、验收标准、问题池（「到底要什么」）→ requirement-intent；要的是本轮改哪些、不改哪些、切几版（变更边界）→ requirement-scope；问线上是否已启用 → platform-observability；代码/项目质量评估 → product-rd-workflow；bug 根因 → defect-diagnosis。
+---
+
+# Requirement Baseline
+
+把「现在到底怎么运作」变成一份有来源、有 freshness、缺口显式的 as-is 清单。改需求之前先弄清现状、已有能力是什么、缺口在哪里时进入本技能。
+
+**选型与评估依赖现状事实时同样进本技能**：判断采用/扩展/替换/下线哪个组件、某能力是否已存在、某系统当下如何运作——结论落在别处（`product-rd-workflow` 的 gate），但支撑结论的事实归本技能取证，取证纪律见硬约束 1。
+
+## 硬约束（先读，全程适用）
+
+1. **不下产品决策。** 只描述现状，不判断「应该怎么改」。代码、数据、架构等描述性证据**不裁决 should-be**。最高频的越界形态是**拿可用性证据当选型结论**：仓库活跃度、最近提交时间、「跑得起来」「有 API」「另一个候选已停更」只说明某物存在且能用，不说明它该被采用——这类事实照记，但不得推出「所以选它」。该记而常被略过的是候选的**自述定位**（README 首句、manifest 描述）——它出自制品自身，属现状事实；查不到就记「自述定位未查到」并列出已查来源，不得代拟。**层级归属分现状与目标两栏，不可混填**：现状层级按部署配置、依赖图等有来源的现状证据照记（这是本技能的本职，不因目标架构缺失而丢弃）；目标层级仅当有来源的目标架构**明确写到该候选**时才记，架构未确认与架构未涵盖该候选要分别记明，作为证据缺口交回决策 owner，不得靠推断补齐。
+2. **三态判定，权威 baseline 不得记 N/A。** 用共享契约的 current-state 三态；新鲜权威 baseline 记 `satisfied-by-authoritative-baseline`。
+3. **`not-applicable` 的全部前置条件**：仅当是有边界的存在性检查、**且**能证明净新增、**且**不触及既有流程、权限、数据、API、规则、迁移、兼容或旧版本行为时才可判。任一条不成立即不得判。
+4. **未查到 ≠ 不存在。** 正常取证后仍未查到的能力、接口、数据、权限、审核流或模型能力，不得写成已确定字段；对应 requirement 行不得设为 `closed`。
+5. **关闭表只补自己那部分。** 唯一 canonical 是 `requirement-doc-writer/references/requirement-closure-contract.md`。本技能以 `evidence-derived` 只填 as-is 描述性事实，或有效已批准规范性来源授权范围内的字段；记录 decision_authority、source、推导、冲突处置和重开条件，**只提出行状态候选，不得把整行设为 `closed`**。
+
+### 安全 4 问（命中即阻断）
+
+现状涉及身份、计费、配额、租户/用户隔离、权限、删除、覆盖时，盘点必须逐项记录安全 4 问的现状答案（无命中则显式记"无安全敏感输入"）。命中上述任一项时，必须先读取 `requirement-doc-writer/references/security-four-questions.md`（问题本体与现状（as-is）应用细则 canonical）再作答，并在产物中写明所依据的 canonical 文件名 `security-four-questions.md`（实测：要求一段**固定字样**的旧写法命中率仅 20.5%，而逐项作答与写明来源文件分别可达 82% / 59%——本仓无法机械校验运行时产物，故只要求可核的实质，不要求不可核的字面戳）；凭记忆或转述作答、未写明来源、或命中后仍记"无命中"，均为违规。**读取不可得时（本会话无文件读取工具 / 文件缺失 / 读取失败）走这条路径，不得声称已读**：改写 `依据: 不可得(<原因>)`；按常驻反射尽力作答、本节标 `interim` 并写出解除方式，缺口连同风险标签交 `feature-risk-router`，由风险 owner 决定是否接受**推迟**——接受的是推迟、不是关闭：本节转正式关闭仍须真实读取 canonical 后逐项重答；agent 与需求提出方均不得自行判为已关闭。always-on 常驻反射见 agent-context/session-start.md「设计期安全 4 问」；本节只定义产物落点与交接。
+
+命中后把风险标签和 gate 选择交给 `feature-risk-router`；需要研发改动时交给 `product-rd-workflow`。
+
+## 产出
+
+| 模块 | 内容 |
+| --- | --- |
+| 事实来源 | 文档、界面、代码、配置、数据样例、运营规则、访谈记录；标注新旧和可信度 |
+| 用户路径 | 用户入口、步骤、状态变化、异常/回退路径 |
+| 系统路径 | 页面/API/服务/数据/规则之间的链路；不确定处标注 |
+| 已有能力 | 已可用能力、约束、默认行为、例外规则；盘点对象是候选组件/服务时另记其自述定位（查不到就填「自述定位未查到」并列出已查来源，不得留空或代拟），层级归属分现状栏与目标栏：现状栏只填有来源的现状证据（部署配置、依赖图等），目标栏仅在目标架构明确写到该候选时填，否则按「架构未确认」与「架构未涵盖该候选」分别记明，两栏都不得填推断值 |
+| 缺口 | 与目标或问题陈述不匹配的空白、冲突、重复能力 |
+| 风险/不确定 | 事实不足、过期来源、权限/数据/删除/覆盖风险 |
+| 需求点关闭表 | 按共享契约补事实依据、freshness、冲突和证据缺口 |
+
+## Workflow
+
+1. 判定 current-state 三态：记录存在性检查范围；硬约束 3 的任一前置条件不成立时，不得判 `not-applicable`。
+2. 定义盘点对象：流程、页面、API、数据、规则、角色或能力边界。
+3. 主动查证：按共享契约完成一轮有界取证 pass；记录已查类别和未查原因，不假设未授权网络、生产或客户数据访问。
+4. 核验权威性、freshness 与适用范围：同等级权威产品来源冲突时立即升级；新权威源替代旧非权威源时记录冲突处置和重开条件。
+5. 画用户路径和系统路径，列出现有行为、入口、条件、限制和例外。
+6. 标缺口、冲突和风险：事实不足、目标不匹配、重复能力、规则矛盾和安全命中项分开写。
+7. 更新 `需求点关闭表`（按硬约束 5 的字段权限）。
+8. 交接决策 owner：把完整关闭表交回 lifecycle、`requirement-intent`、`requirement-scope`、`defect-diagnosis` 或风险 gate。
+
+## 不用本技能，改用谁
+
+- 要「到底要什么」（意图、用户故事、验收标准、问题池）→ `requirement-intent`。
+- 要变更边界（in/out、切片、appetite）→ `requirement-scope`；多阶段交付 → `product-rd-workflow`。
+- 问某能力线上是否已启用、要实时指标 → `platform-observability`。**代码里存在 ≠ 已部署启用**。
+- 代码质量、架构质量、项目整体评估 → `product-rd-workflow` 分派 stack/architecture/testing/UI owner。
+- bug、线上症状、失败测试、根因定位 → `defect-diagnosis`。
+- 风险 tag / gate 选择 → `feature-risk-router`。
+- 只润色已成文的盘点报告 → `tighten-doc`。
+
+## 完成标准
+
+逐条可核，缺一条即为 `interim` 而非完成：
+
+- 每条现状结论都有具名来源，并标了 freshness 与可信度；无来源的结论标为未确认。
+- 已查类别与**未查类别及其原因**都写出来了；未解析来源单独列出。
+- 盘点对象含候选组件/服务时，每个候选都记了自述定位、或记了「未查到」并列出已查来源；层级归属分现状与目标两栏——现状层级凡有来源现状证据的都记了，目标层级只在目标架构明确写到该候选时才记，另两种缺口（架构未确认／架构未涵盖该候选）分别记明而非留空或臆测。没有任何结论由活跃度、可运行性或「另一候选已停更」单独推出。
+- 三态判定已记录；若判 `not-applicable`，硬约束 3 的每条前置条件都逐条写明成立依据。
+- 缺口、冲突、风险三者分开列，未混进「已有能力」。
+- 关闭表只填了 `evidence-derived` 允许的字段，且没有任何整行被设为 `closed`。
+- 安全 4 问：记了「无命中」，或四项逐条答案 + 写明所依据的 canonical 文件名；读取不可得时写了 `不可得(<原因>)` 并把本节标 interim。
+
+## 输出模板
+
+```text
+现状盘点
+- 盘点对象：
+- 事实来源：
+- 用户路径：
+- 系统路径：
+- 已有能力：
+- 缺口 / 冲突：
+- 风险 / 不确定：
+- 未解析来源 / 未查类别及原因：
+- 需求点关闭表：
+- 安全 4 问：无命中 / <逐项作答四项>
+- 依据来源：<读到了写 `security-four-questions.md`；没读到写 `不可得(<原因>)` 并把本节标 interim。不得留空>
+- 下一步 owner：
+```

package/dist/assets/marketplace/plugins/ccl-skills/skills/requirement-baseline/agents/openai.yaml

@@ -0,0 +1,4 @@
+interface:
+  display_name: "Requirement Baseline"
+  short_description: "Inventory product current state"
+  default_prompt: "Use $requirement-baseline to inventory current product flows, capabilities, facts, gaps, risks, and uncertainties before deciding what to change."

package/dist/assets/marketplace/plugins/ccl-skills/skills/requirement-doc-writer/SKILL.md

@@ -0,0 +1,130 @@
+---
+name: requirement-doc-writer
+description: 写 PRD / 需求文档 / 产品需求文档 / 需求说明 / user story 文档 / 验收标准文档 / 产品需求正文 —— 在 lifecycle 判定 PRD Ready 之后，把已关闭的需求组装成人读的 PRD。Skip 需求实质不清 → requirement-intent；缺现状事实 → requirement-baseline；范围/版本切片/开放决策未关闭 → requirement-scope；Agent/Machine 技术规格 → llm-inference-integration；其评测与测试层 → testing-strategy；只是润色措辞 → tighten-doc。
+---
+
+# Requirement Doc Writer
+
+在 lifecycle 判定 `PRD Ready` 之后，把已关闭的需求组装成一份人能读懂、能评审的 PRD。已有澄清、现状盘点与范围关闭材料、所有需求点已有确定口径时进入本技能。
+
+## 硬约束（先读，全程适用）
+
+1. **Ready 是门，不是措辞。** 只消费带 `product`、`version`、`scope`、`closure_table_revision`、`behavior_inventory_revision`、`issued_at` 绑定的 lifecycle-issued `PRD Ready`；绑定不匹配或输入变化时回 lifecycle 重判。任一 P0 行不是 `closed`、或 Ready 条件任一不满足，**不得生成 PRD**。用语本身不决定状态，关闭表语义才是门。
+2. **`PRD Not Ready` 时不得输出 PRD 标题、目录、骨架、模板或正文**；WIP、讨论稿、会议材料也不得命名为 PRD。此时只输出产品决策视图并保留机器账本引用，不删底层审计字段。
+3. **writer 不改事实。** 不得修改推导、决策权、决策证据或行状态；不得把 `human-decision` 字段改成自动确定；不得设置整行 `closed`。
+4. **writer 不做技术设计。** 不得设计 Agent 技术 schema、prompt/model policy、tool contract 或 eval 实现——分别转 `llm-inference-integration`、架构/技术栈 owner 与 `testing-strategy`；writer 只检查命名引用、适用版本、owner 和逐条可追踪性在机器侧是否完整。
+5. **不冒充设计 owner。** UI/用户可见产品的 IA、交互、页面状态和原型由 `product-ui-ux-design` 产出或审核，writer 只转写已确认内容。
+
+### 安全 4 问（命中即阻断）
+
+PRD 涉及身份、计费、配额、租户/用户隔离、权限、删除、覆盖时，文档必须有"安全与滥用"小节，逐条写安全 4 问的答案；无命中则显式记"无安全敏感输入"，命中后仍记"无命中"为违规。作答前必须先读取 `references/security-four-questions.md`（问题本体与落点细则 canonical），并在产物中写明所依据的 canonical 文件名 `security-four-questions.md`（实测：要求一段**固定字样**的旧写法命中率仅 20.5%，而逐项作答与写明来源文件分别可达 82% / 59%——本仓无法机械校验运行时产物，故只要求可核的实质，不要求不可核的字面戳）；凭记忆或转述作答、未写明来源、或命中后仍记"无命中"，均为违规。**读取不可得时（本会话无文件读取工具 / 文件缺失 / 读取失败）走这条路径，不得声称已读**：改写 `依据: 不可得(<原因>)`；按常驻反射尽力作答、本节标 `interim` 并写出解除方式，缺口连同风险标签交 `feature-risk-router`，由风险 owner 决定是否接受**推迟**——接受的是推迟、不是关闭：本节转正式关闭仍须真实读取 canonical 后逐项重答；agent 与需求提出方均不得自行判为已关闭。always-on 常驻反射见 agent-context/session-start.md「设计期安全 4 问」；本节只定义产物落点与交接。
+
+命中后 PRD 只完成需求表达；风险标签/gate 交给 `feature-risk-router`，研发生命周期交给 `product-rd-workflow`。
+
+## 产出
+
+生成前读取 `references/requirement-closure-contract.md`。通过门后组装人读 PRD：**先帮读者建立产品认知，再表达已关闭的产品决定、业务规则、边界和验收。** 正文先回答三问：
+
+1. **这是什么产品**：区分目标/非目标用户、触发问题/一般愿望、可观察结果/宣传口号，并写出价值、P0 结果和至少一个明确非目标。只替换产品名仍适用于大量无关产品的句子不合格。
+2. **有哪些产品模块或等价结构**：模块按稳定产品能力、业务责任或价值流定义，参与端到端状态或结果变化，并说明作用、输入、输出、上游和下游。不得按路由、菜单、页面或弹窗定义模块；页面必须映射到模块，删掉页面名后说不清产品责任或结果的不是模块。非页面型产品可用能力地图、价值流、角色责任或状态流，但必须说明责任边界、关系和端到端运行，不得虚构模块或页面。
+3. **产品如何端到端运行**：主链路，以及关键异常、纠错和回退。
+
+正文推荐按以下顺序组织；可按读者需要调整，但**产品认知必须先于规则明细**：
+
+| 章节 | 内容 |
+| --- | --- |
+| 产品全景 | 用户、问题、价值、P0 结果、非目标 |
+| 模块地图 | 每个产品模块的作用、输入、输出、上下游及模块关系 |
+| 核心运行流程 | 端到端主链路、关键状态变化和结果；用户可见/UI 产品还须写流程明细与关键分支 |
+| 模块 / 页面体验与原型 | 模块到页面的映射、信息架构、界面关系、页面状态及设计 owner 产出或审核的原型 |
+| 关键业务规则 | 已关闭的产品决定、阈值、约束和适用条件 |
+| 异常与恢复 | 关键异常、取消、纠错、重试、恢复和回退 |
+| 角色 / 安全边界 | 角色、权限、信任边界及安全 4 问命中项 |
+| 端到端验收场景 | 按主场景、负向场景、边界场景或能力级组织；不逐条复制机器追踪表 |
+| 范围 / 依赖 / 发布边界 | in/out scope、版本切片、依赖、发布条件和不承诺事项 |
+
+流程明细与原型合同、验收场景拆分、反向投影对账、独立陌生读者复述门、以及分层不丢内容的规则，见 `references/prd-composition-contract.md`——组装正文前读它。
+
+## Workflow
+
+1. 校验 Ready 判定：确认 lifecycle 已完成 behavior inventory 对账、复合字段子项检查、合法人类决策证据和逐项安全/合规检查，并已把所有 P0 行设为 `closed`。
+2. `PRD Not Ready`：按硬约束 2 输出产品决策视图，停在这里。
+3. `PRD Ready`：确定文档目标和读者，以关闭表为生成输入和证据，组装人读 PRD，不重新解释或重签决策，也不直接投影完整关闭表。
+4. 按上面的三问与章节合同组装正文，细则按 `references/prd-composition-contract.md`。
+5. 用户可见/UI 产品：检查 `product-ui-ux-design` 的 IA、流程、页面状态和原型产出或审核；涉及 Agent/LLM/RAG/自动判断：检查独立 Agent/Machine Spec 引用。缺口转对应 owner。
+6. 建最小引用：机器账本、设计产物、Agent/Machine Spec 和测试证据的名称、位置、版本与 owner。
+7. 填依据并按场景拆分规则写验收：无来源不得写成确定结论。
+8. 运行 `tighten-doc`，得到 post-tighten 最终候选。
+9. 对最终候选跑反向投影对账，生成机器侧派生覆盖索引；任一适用 facet 无正文落点即失败。
+10. 对同一最终候选跑独立陌生读者复述门；保存结果和遗漏项。
+11. 交接：研发计划回 `product-rd-workflow`；TC 转 `test-artifact-management`；技术规格与评估工具转对应 owner。**反向对账和独立复述均通过后才可发布、分享、同步或提交。**
+
+## 不用本技能，改用谁
+
+- 需求实质未澄清 → `requirement-intent`。
+- Current-state 未满足共享契约三态及证据要求 → `requirement-baseline`；权威 baseline 不能写成 N/A。
+- 范围、版本切片、开放决策未关闭 → `requirement-scope`。
+- UI/用户可见产品的 IA、交互、页面状态和原型 → `product-ui-ux-design`；具体实现 → 相应 web/app/miniapp 技术栈 owner。
+- 只润色已定稿文档、去废话、改结构表达 → `tighten-doc`。
+- 测试用例文档、Feishu/Bitable TC → `test-artifact-management`；测试层/覆盖策略 → `testing-strategy`。
+- 多阶段研发交付、技术方案、实现/发布计划 → `product-rd-workflow`。
+
+## 完成标准
+
+逐条可核，缺一条即为 `interim` 而非完成：
+
+- Ready 绑定的六个字段都已核对，且当前 `version` / `scope` 的全部 P0 行为 `closed`。
+- 正文三问都答了，且「这是什么产品」经得起替换产品名的检验。
+- 每个模块写了作用、输入、输出、上下游；没有按页面或菜单定义的伪模块。
+- 反向投影对账已跑，覆盖索引已生成，无任一适用 facet 缺正文落点。
+- 独立陌生读者复述门已跑（reviewer 未参与起草、fresh context、只看正文），遗漏项已记录且无实质遗漏。
+- `tighten-doc` 已在最终候选上跑过，且对账与复述是在 post-tighten 候选上跑的。
+- 安全 4 问：记了「无命中」，或四项逐条答案 + 写明所依据的 canonical 文件名；读取不可得时写了 `不可得(<原因>)` 并把本节标 interim。
+
+## 输出模板
+
+### 仅 PRD Ready
+
+```text
+PRD / 需求文档
+1. 产品全景（用户 / 问题 / 价值 / P0 结果 / 非目标）
+2. 模块地图或等价结构（责任 / 输入 / 输出 / 上下游）
+3. 核心运行流程与流程明细（端到端主链路 / 动作 / 响应 / 状态 / 分支）
+4. 模块 / 页面体验、信息架构与原型（非 UI 时写 N/A 依据）
+5. 关键业务规则
+6. 异常与恢复（异常 / 纠错 / 回退）
+7. 角色与安全边界
+   - 安全 4 问：无命中 / <逐项作答四项>
+   - 依据来源：<读到了写 `security-four-questions.md`；没读到写 `不可得(<原因>)` 并把本节标 interim。不得留空>
+8. 端到端验收场景
+9. 范围、依赖与发布边界
+
+最小引用
+- 产物 / 位置 / 版本 / owner
+
+Agent/Machine Spec 引用（仅在涉及 Agent/LLM/RAG/自动判断时）
+- 产物 / 位置 / 版本 / owner
+```
+
+### PRD Not Ready
+
+```text
+产品决策视图
+- 待决定问题：
+- 候选 / 推荐：
+- 代价：
+- accountable_owner：<具名且有权限的人类 owner>
+- 受影响 requirement / P0：
+
+下一动作
+- <最小取证、授权或决策动作>
+
+机器账本
+- <关闭表引用或附录；保留全部逐字段审计元数据>
+```
+
+## Reference Loading
+
+- `references/requirement-closure-contract.md`：唯一 canonical 需求点关闭表，生成前必读。
+- `references/security-four-questions.md`：安全 4 问本体与各 owner 落点细则，命中时必读。
+- `references/prd-composition-contract.md`：流程明细与原型合同、验收场景拆分、反向投影对账、独立复述门、分层不丢内容。

package/dist/assets/marketplace/plugins/ccl-skills/skills/requirement-doc-writer/agents/openai.yaml

@@ -0,0 +1,4 @@
+interface:
+  display_name: "Requirement Doc Writer"
+  short_description: "Assemble lifecycle-ready PRDs"
+  default_prompt: "Use $requirement-doc-writer to assemble a human-readable PRD only after the lifecycle has issued PRD Ready; otherwise return the product decision view, next actions, and machine-ledger reference without drafting PRD content."

package/dist/assets/marketplace/plugins/ccl-skills/skills/requirement-doc-writer/references/prd-composition-contract.md

@@ -0,0 +1,35 @@
+# PRD 组装合同（流程明细 / 验收拆分 / 反向对账 / 复述门）
+
+`requirement-doc-writer` 在 `PRD Ready` 之后组装正文时逐节适用。入口的硬约束与章节合同在 `SKILL.md`，本文不重复。
+
+## 流程明细与原型合同
+
+- 用户可见/UI 产品的核心流程必须写明角色、触发、前置状态、逐步用户动作、系统响应、状态变化、页面反馈和成功结果，并覆盖适用的失败、冲突、冻结、恢复和返回分支；只有四至五条宏观链路不合格。
+- 人读正文必须包含设计 owner 已确认的信息架构、页面/surface 关系、关键页面状态，以及关键动作—系统响应—状态变化—页面反馈链，并说明这些结构对产品行为和流程的影响。每个核心页面或 surface 写明用户目标、主要区域与信息层级、主次动作、进入/离开/返回路径、与模块/流程的映射，以及适用的空、加载、部分、错误、禁用、成功、恢复、权限和风险状态。
+- `product-ui-ux-design` 负责 IA、交互、页面状态、原型设计及其验收，并产出或审核低保真原型、线框、流程图或等价的结构化页面描述。完整原型可嵌入正文，也可按名称、位置、版本和 owner 引用；外部链接只承载完整画布、视觉/交互细节和溯源，不得替代上条要求的 reader-facing 正文。writer 只能转写或组装设计 owner 已确认的内容并保全产品决定，不得自行冒充设计 owner；没有 Figma 不阻塞，只有一句页面列表不算原型。
+- 原型未定且会改变核心路径、产品行为、权限或验收时，不得标记为可交付 UI 开发；低风险视觉细节可由设计 owner 后续补齐。具体 web/app/miniapp 实现归相应技术栈 owner，测试证据归 `testing-strategy`，不得把这些 owner 的实现方法复制进 writer。
+- 非 UI 的 API、SDK、后台作业等可将原型标为 N/A，但必须记录无用户可见 surface 的依据；存在运营后台时不得整体标为 N/A，后台 surface 仍须写流程和状态。
+
+## 验收场景拆分
+
+角色/权限、前置状态、用户可见结果、失败结果、恢复路径或安全预期任一不同，必须拆成独立场景或明确分支；只有这些维度全部一致时才能聚合。`testing-strategy` 和 `test-artifact-management` 仍分别判断测试语义、层级与证据充分性以及结构化测试用例，不由 writer 代替。
+
+## 反向投影对账
+
+PRD 草稿完成后，对当前 `version` / `scope` 的全部 in-scope、`closed` requirements 按 reader-facing facet 逐项检查。每个适用 facet 单独映射到 PRD section anchor 或 acceptance scenario；至少区分产品行为/最终口径、rule/threshold、failure、cancel、rollback/recovery、compatibility、role/permission/security、dependency，以及 positive/negative/boundary acceptance。同一 requirement 可有多行；任一适用 facet 没有正文落点，PRD 失败。
+
+对账结果生成机器侧派生索引，至少保存 `requirement_id / source_field_or_subitem（或 reader-facing facet） / PRD section anchor or acceptance scenario / closure_table_revision / coverage status`。N/A 必须引用关闭表中已有的合法不适用依据，索引不得自行创造 N/A。该索引只证明正文覆盖，不是新的事实源，不复制字段值或决策元数据，不进入人读正文；测试语义、层级和证据充分性仍由 `testing-strategy` / `test-artifact-management` 判断。
+
+## 独立陌生读者复述门
+
+正文完成并经过 `tighten-doc` 后，必须对 post-tighten 最终候选执行独立复述。reviewer 必须未参与起草、使用 fresh context，且只能看到 PRD 正文，不得查看关闭表、Machine Spec、测试证据或背景对话；作者自评不算。
+
+reviewer 固定复述：产品/用户/问题/承诺结果/非目标；模块或等价能力及关系；完整主链路和关键异常；关键规则/阈值/适用条件；角色/权限/安全边界；关键负向/边界验收；范围/发布边界。对用户可见/UI 产品，还必须按上面「流程明细与原型合同」复述核心角色、触发、动作—系统响应—状态变化—页面反馈及适用分支，信息架构与核心页面/surface 关系，以及关键页面状态。保存复述结果和遗漏项；任一实质遗漏或错误均失败。正文实质内容或结构变化后必须重跑，失败时不得发布或通过 closeout。
+
+涉及 Agent/LLM/RAG/自动判断时，PRD 另列 Agent/Machine Spec 的最小引用。缺少独立规格时，不得标记为可交付 Agent 开发。
+
+## 分层不得丢内容
+
+人读正文不得复制机器账本、机器侧逐条 requirement inventory、逐字段关闭元数据、数据结构/字段合同、实现合同、评估计划、完整追踪矩阵或逐需求技术证据表。这些内容留在机器账本、Agent/Machine Spec 或测试证据产物；人读 PRD 仍须完整说明面向读者的产品模块和能力，并只保留机器侧产物的名称、链接或位置、版本、owner 等最小引用。**不得因分层而丢失已关闭产品决定、关键业务规则、阈值、权限/安全边界、依赖和验收。**
+
+引用只支持溯源或技术细节，不能替代正文中的产品行为、规则、阈值、异常、权限/安全、范围和验收；读者不打开引用也必须理解这些内容。

package/dist/assets/marketplace/plugins/ccl-skills/skills/requirement-doc-writer/references/requirement-closure-contract.md

@@ -0,0 +1,86 @@
+# 需求点关闭契约
+
+四个产品需求技能共享一张 `需求点关闭表`。每个技能只补自己的视图；不得复制、改名或另建状态表。
+
+| 字段 | 规则 |
+| --- | --- |
+| `requirement_id` | 稳定且唯一的需求点标识 |
+| 用户价值 | 该点为谁解决什么问题 |
+| 事实依据 | 来源、取证时间和 current-state 三态结论 |
+| 最终口径 | 已决定的产品行为；未决定时写阻塞点 |
+| 版本/范围 | `current_version`、`in`、`out`、`deferred`，以及适用时的 appetite/砍项 |
+| 异常/边界 | `failure`、`cancel`、`rollback/recovery`、`compatibility`，以及适用时的 `security/permission` |
+| 验收 | `positive`、`negative`、`boundary`、`evidence_shape` |
+| `closure_method` | 字段如何得到：`evidence-derived`、`low-risk-default` 或 `human-decision` |
+| `decision_authority` | 谁有权决定该字段：`descriptive-fact`、`bounded-agent-policy`、有权限的人类 owner，或仍有效且有批准记录的规范性产品来源；`bounded-agent-policy` 表示授权来自已批准的有界 Agent policy，而非 Agent 或模型自身 |
+| `decision_evidence` | 明确回答或已批准决策记录的 source/ref、`decided_at`、适用 version/scope |
+| `status` | 整条 requirement 的状态：`open`、`blocked`、`closed` 或 `deferred` |
+| `accountable_owner` | 当前人类用户，或具名、可追责且有相应决策权的人类角色 |
+| `reopen_condition` | 哪类新事实、冲突、变化或撤销会重开 |
+
+每个已填字段都必须携带自己的 `closure_method`、source、`decision_authority`；产品承诺字段还必须有 `decision_evidence`。不得用一组行级元数据代替逐字段记录。复合字段按上述子项判定：任一适用子项为 open，复合字段和整行均不能 `closed`；把子项判为不适用也必须有合法依据。
+
+## 推导与决策权
+
+代码、测试、界面、运行数据和架构只能证明 as-is 描述性事实，`decision_authority` 记为 `descriptive-fact`。它们不能单独决定 should-be 的最终产品行为、P0 范围、用户可见默认、权限/安全边界、异常/撤销/兼容政策、验收承诺或数值阈值。
+
+产品承诺字段只能由以下权威关闭：
+
+1. 当前人类用户，或具名、可追责且具备该项决策权的人类 owner 的明确决定。
+2. 仍有效、已批准并带人类 owner/批准记录的规范性产品来源；使用旧来源前核验版本、scope 和 freshness。
+
+Agent、模型、skill、workflow、工具，以及“产品团队”“需求负责人”等泛称不能签署。推荐、会议总结或 Agent 生成的关闭表不能反向成为授权证据。只知道 owner 角色但没有明确决定记录时，字段和整行保持 `open` / `blocked`。
+
+## 三档关闭权限
+
+1. **`evidence-derived` 可自动确定字段**：一手来源可确定 as-is 描述性事实；仍有效且具备上述批准记录的规范性产品来源可确定其授权范围内的产品承诺。每个字段记录 source、推导、版本、freshness、适用范围、冲突检查和重开条件。
+2. **`low-risk-default` 可自动确定单个非核心字段**：`decision_authority` 必须记为 `bounded-agent-policy`，表示授权来自仍有效、已批准且可引用的有界 Agent policy，而非 Agent 或模型自身。只限该 policy 和既有规则均允许的单个非核心、低风险、可逆展示或表达细节。每个字段的 `decision_evidence` 必须记录 policy ref/version/scope、该字段为何落在允许范围、默认值、影响、撤销方式和 `reopen_condition`。不得用于产品承诺、P0 范围、核心路径、验收、数值阈值、安全、权限、数据语义、整个需求点、整行状态或商业口径。没有可引用的已批准 policy 时不得使用 `low-risk-default`；字段保持 `open`，或转为 `human-decision`。
+3. **`human-decision` 必须由 accountable owner 决定字段**：产品方向、目标用户、核心路径、P0 in/out、商业模式、成功指标、多个方案的实质权衡、身份、权限、计费、隐私、合规、删除、覆盖和外部公开。Agent 只能给候选方案、推荐和代价，不能代签。
+
+`bounded-agent-policy` 的批准者必须是当前人类用户，或具名、可追责且具有 policy 治理权的人类 owner。Policy evidence 必须包含批准记录/ref、approver、`approved_at`、version 和 scope。当前用户对具体任务的明确授权可作为 task-scoped policy evidence；持久或跨任务 policy 必须有仓库内稳定引用及人类批准记录。同一 Agent/模型不得在当前任务中生成 policy 后自我引用授权；未经人类批准的 repo 文档、会议总结和关闭表均不是 policy。
+
+有界取证 pass 按以下顺序执行一次：① canonical owner/source；②与字段直接相关的当前代码、数据和规范；③记录已查类别及未查原因。证据缺失、冲突或过期时，在当前已授权来源内完成该 pass，并按权威性、freshness 和适用范围核对。同等级权威来源对产品口径冲突时立即升级，不用低等级描述性证据裁决。只有一轮有界 pass 完成、继续取证需要额外访问授权，或权威冲突仍未解决时，才升级为 `human-decision` / `blocked` 并提出最少一组问题。新权威源可替代旧非权威源，并以 `evidence-derived` 确定字段，但必须记录冲突处置和 `reopen_condition`。不得假设拥有未授权网络、生产环境或客户数据访问；输出不得包含 secret 或 PII。
+
+## Current-state 与 N/A
+
+Current-state 只能取三态：
+
+- `required-and-evidenced`：需要现状取证，且证据已满足。
+- `satisfied-by-authoritative-baseline`：由新鲜、权威且适用的 baseline 满足；baseline 不是 N/A。
+- `not-applicable`：有边界的存在性检查证明目标行为净新增，且不修改、复用、替换或依赖既有流程、权限、数据、API 或规则，也没有迁移、兼容或旧版本行为；必须记录检查范围。不能证明时为 unknown/blocked。
+
+安全/合规不得笼统 N/A。逐项检查身份、权限、计费、配额、隐私、删除、覆盖等触发类别并记录理由；任一项不确定即路由 `feature-risk-router`，artifact skill 不能自行判安全/合规 N/A。
+
+## 行状态权限
+
+Agent 只能自动确定具体字段，不能自动关闭整条 requirement。`requirement-intent`、`requirement-baseline` 和 `requirement-scope` 只能补各自字段并提出行状态候选。只有所有 P0 必填字段及适用子项均已确定、全部 `human-decision` 字段有合法 `accountable_owner` 和 `decision_evidence`，且安全与合规门已满足时，`product-rd-workflow` lifecycle 才能把整行 `status` 设为 `closed`。
+
+## 分层视图与产物
+
+- **机器账本**：保留完整关闭表及全部逐字段元数据。Agent 负责维护，产品人员无需手工逐格填写。
+- **产品决策视图**：只显示待决定问题、候选/推荐、代价、`accountable_owner`、受影响的 requirement/P0，以及机器账本引用。
+- **人读 PRD**：承载产品理解和面向读者的决策；用户可见/UI 内容必须由设计 owner 确认，非 UI 产品记录原型 N/A 的依据。具体正文和原型合同见[本技能“流程明细与原型合同”](../SKILL.md#流程明细与原型合同)。
+- **Agent/Machine Spec（如适用）**：承载数据结构/字段合同、实现合同、逐条需求追踪关系、评估计划，以及技术验证证据的引用与状态等机器合同与技术细节。
+
+关闭表是生成这些视图和产物的输入与证据，不等于人读 PRD 正文。不得把完整关闭表、逐字段关闭元数据、机器侧逐条 requirement inventory 或完整追踪矩阵直接投影进人读 PRD；人读 PRD 仍须完整说明面向读者的产品模块和能力，并只保留机器账本、Agent/Machine Spec 和测试证据的名称、位置、版本、owner 等最小引用。分层不得删除底层审计字段，也不得遗漏已关闭产品决定、关键业务规则、阈值、权限/安全边界、依赖和验收。
+
+人读 PRD 不得遗漏当前范围内已关闭的 reader-facing 决定；具体 facet 级覆盖索引和失败条件见[本技能“反向投影对账”](../SKILL.md#反向投影对账)。
+
+UI/用户可见产品的信息架构、交互、页面状态、原型设计及验收归 `product-ui-ux-design`；writer 不替代设计 owner。具体客户端实现归相应技术栈 owner，测试证据归 `testing-strategy`。
+
+`PRD Not Ready` 优先展示产品决策视图，并把机器账本作为引用或附录；不得为简化展示删除底层审计字段。
+
+## PRD Ready 门
+
+仅当以下条件全部满足，完整 lifecycle 才能判定 `PRD Ready`：
+
+- 问题已澄清。
+- Current-state 已记录三态之一，并满足相应证据要求。
+- 已与 `product-rd-workflow` 的独立可失败行为/acceptance inventory 对账；每个行为都有 `requirement_id`，或由合法 human decision 明确 `out` / `deferred`。未建行不等于不在范围。
+- P0 范围已确定，且 lifecycle 已按行状态权限把所有 P0 需求点设为 `closed`。
+- 版本/范围、异常/边界和验收的所有适用子项均已确定。
+- 安全与合规已完成；逐项检查后不适用的类别有合法依据。
+
+Lifecycle-issued Ready verdict 必须绑定 `product`、`version`、`scope`、`closure_table_revision`、`behavior_inventory_revision` 和 `issued_at`。关闭表、behavior inventory、P0 scope、human decision 或安全判断任一变化，旧 Ready 自动失效，必须重新判定。
+
+任一条件不满足即 `PRD Not Ready`。此时不得输出 PRD 标题、骨架或正文；只输出产品决策视图、下一动作和机器账本引用/附录。`deferred` 仅表示不进入当前版本，不能伪装成当前 P0 已关闭。

package/dist/assets/marketplace/plugins/ccl-skills/skills/requirement-doc-writer/references/security-four-questions.md

@@ -0,0 +1,38 @@
+# 安全 4 问（canonical）
+
+四个产品需求技能（`requirement-intent` / `requirement-baseline` / `requirement-scope` / `requirement-doc-writer`）共用同一份问题本体。改动先改本文件；各技能 `## 安全 4 问` 节只定义该技能的产物落点与交接，不复述、不改写问题本体。always-on 层（agent-context/session-start.md「设计期安全 4 问」）保留常驻反射全文——那是每会话注入的反射本体（实测区分度项），不是本文件的副本；bootstrap 的 Q2/Q4 是压缩常驻式（动词表为其子集：伪造/篡改、伪造/越权），完整谓词集以本文件为准——改动本文件动词表时同步核对 bootstrap 常驻式仍为其子集。
+
+## 触发
+
+设计、方案、需求澄清、现状盘点、范围界定或 PRD 触及：身份、计费、配额、租户/用户隔离、权限、删除、覆盖。always-on 层的走时点是交付路由之后、产出设计/方案 substance 之前。命不中（纯内部无关输入）显式记"无安全敏感输入"。
+
+## 问题本体（逐条走；散文里带一句"注意安全"不算）
+
+1. 哪些输入由调用方或用户可控。
+2. 伪造、篡改、重放、越权、重复提交、误删或覆盖这些输入的爆炸半径。
+3. 每个安全敏感值（身份、租户、金额、配额、权限）的信任根：安全敏感值必须从认证主体或服务端状态推导，绝不信请求体自带。
+4. 至少一条伪造/越权/误删/覆盖的负向用例。
+
+## 各产物落点
+
+- **澄清记录（`requirement-intent`）**：逐项包含四项答案；第 4 条写作负向验收用例。
+- **现状盘点（`requirement-baseline`，as-is 应用）**：Q1 问"当前哪些输入由调用方或用户可控"；Q3 照实记录当前信任根来自认证主体、服务端状态、配置、人工运营规则还是请求体——现状若就是请求体自报，照实记录并标注为风险，安全敏感值不得以请求体自报为权威（命中即记为必修风险）；Q4 是一个能证明现状是否防住伪造/越权/误删/覆盖的负向用例。
+- **改动范围（`requirement-scope`）**：范围表逐项记录四项答案；负向用例写入验收范围（如伪造租户、越权改配额、重复删除、覆盖他人数据）。
+- **PRD（`requirement-doc-writer`）**：文档必须有"安全与滥用"小节，逐条写四项答案；负向验收用例覆盖伪造身份/租户、越权、重复提交、误删/覆盖等。
+
+## 命中后的交接
+
+命中上述触发任一项时，风险标签与 gate 选择 → `feature-risk-router`；进入研发交付/生命周期 → `product-rd-workflow`。本文件只做安全反射与产物落点，不替代 `feature-risk-router` 的风险定级。
+
+## 机器可读 sync 登记表
+
+本文件「触发」与「问题本体」的动词表/触发词表被 `agent-context/session-start.md` 的常驻压缩式引用为子集。下方 `sync-registry:v1` 注释块是这些 canonical 词表的机器可读登记：`check-sync-pointers.sh` 从 bootstrap **实文本锚定抽取**压缩表并强制其保持为本登记的子集（alias 声明的等价形除外）、不低于 `q2-bootstrap-min`/`q4-bootstrap-min` 地板（防常驻反射被悄悄削减），且登记的每个 canonical 词必须真实出现在对应小节/条目行里（防只改登记不改正文）。改动上文词表时同步更新登记块。
+
+<!-- sync-registry:v1
+trigger-canonical: 身份,计费,配额,租户/用户隔离,权限,删除,覆盖
+q2-canonical: 伪造,篡改,重放,越权,重复提交,误删,覆盖
+q4-canonical: 伪造,越权,误删,覆盖
+q2-bootstrap-min: 伪造,篡改
+q4-bootstrap-min: 伪造,越权
+alias: 租户或用户隔离=租户/用户隔离
+-->