demand-risk-assessment

Requirement Risk Assessment Skill (v1.0)

Version Changes (v1.0)

• Round 1 (usable version) template landed: added in 0.12 the 0.121 general template, reducing output drift caused by "knowing two rounds of delivery are needed but not knowing how to write the first round".
• Evidence anchor tag standardization: unified in Phase 0 and key table column names 证据锚点([直引]/[复述]/[缺口]), and clarified the three-state notation, reducing discrepancies in wording when "references are restricted/original text cannot be found".
• Version history moved out: the main Skill retains only the current version changes; historical summaries are uniformly placed in the README, reducing tokens and execution drift.

0) Objectives (do not confuse)

This Skill answers only three things, and reasons must be given separately for each:

1. Whether it can be done: compliance-feasible + technically/resource-deliverable
2. Whether it is worth doing: comprehensive match of price/benefit/opportunity cost/long-term burden (including payment collection/liability risk)
3. How to do it more reliably: contract terms + execution process + technical controls + stop-loss mechanisms

Note: the total score is only a summary and cannot override a single fatal risk (red lines/hard gates take priority).

---

0.15) TL;DR (30-second quick execution)

Output order:First give the three conclusion questions + commitment gate status, then give evidence and actions (avoiding "looks very professional but is not actionable").

1. Phase 0: Structured extraction → key field snapshot + information sufficiency X/8(see 3 + 3.4)
2. Phase 0.25/0.5: Pitfall signals + conflict detection (see 4 + 5)
3. Phase 1: Red-line check (see 6) → if hit, 拒绝/暂停, do not enter full scoring
4. Commitment gate (see 2.6 / Appendix Q) → determines "can only pause / can only ROM / can lock milestones / can lock quote and schedule"
5. Phase 2: Structured scoring (see 7 + Appendices A/E/G/H) → output range + capping + confidence
6. Phases 3-6: Pre-mortem → risk table → terms/execution → minimum supplementary information set (see 8-11)

0.12) Two-round delivery protocol (default: usable first, then expand)

Purpose: reduce omissions and drift caused by a "one-time long report", so the user first gets actionable conclusions, then decides whether to expand the scoring/risk table details.

Default approach (unless the user explicitly requests "give a complete assessment in one go"):

1. Round 1 (usable version): output only 1.4【概览】 + 【关键字段快照(8项)】 + 【红线检查】 + 【踩坑信号(≤5)】 + 【冲突检测(≤5)】 + 【Top 缺口/假设(3-6)】 + 【需要补充的信息(≤10问)】。
2. Round 2 (full version, optional): after information is completed, output `【Scoring Overview】/【Risk Register】/【Negotiation Terms】/【Execution Plan】/【ROM】/【Order Splitting】, etc.

Exception (do the full version directly):

• The user explicitly says "please output according to the full template/give a scoring table/give ROM three scenarios + terms"; or the materials are already complete (information sufficiency ≥6/8 and conflicts can be resolved).

0.121) Round 1 (usable version) general template (recommended for direct reuse)

When the user's materials are incomplete, or you have not yet completed conflict resolution and the commitment gate determination, prioritize using this template to deliver an "executable first-version conclusion," and converge the gaps into ≤10 high-leverage questions.

## 【概览】（见 1.4，必须先给）
...

## 【关键字段快照（8项）】
...（见 3）

## 【红线检查】
...（见 6）

## 【踩坑信号（≤5）】
...（见 4）

## 【冲突检测（≤5）】
...（见 5）

## 【Top 缺口/关键假设（3-6）】
- ...

## 【需要补充的信息（按优先级，≤10问）】
1) ...（关联维度/为什么会改结论）

---

0.2) Minimum input set (layered; when information is insufficient, default to filling it in first)

When the user's input is very short, or you find that the "key field snapshot" is largely missing, prioritize guiding the user to fill in the following minimum information (write as much as possible; missing items will trigger capping/pause):

【项目/需求名称】：
【场景类型】常规/多需求对比/历史参考/应急/续约变更：
【目标（可验证）】：
【范围边界】in-scope / out-of-scope：（信息充分性 8 项之一）
【交付物清单】代码/文档/部署/培训/源代码归属等：（信息充分性 8 项之一）
【验收口径】验收清单/测试方式/时限/默认通过条件：（信息充分性 8 项之一）
【付款结构】预付款/里程碑/尾款占比/逾期处理：（信息充分性 8 项之一）
【工期与里程碑】用绝对日期时间点（例：2026-03-20 18:00 +08:00 或 Asia/Shanghai）：（信息充分性 8 项之一）
【关键依赖】客户侧账号/接口/数据/白名单/资质与最晚提供时间：（信息充分性 8 项之一）
【数据与合规】涉及的数据类型/授权/留存删除/跨境与共享（如适用）：（信息充分性 8 项之一）
【决策/验收负责人】（信息充分性 8 项之一）：

【预算/报价区间】（如已知）：
【计费口径】固定价/人天/里程碑：
【日费率/人天单价】（如需 ROM 报价/排期，缺省可留空）：

【应急（如适用）】真实 Deadline、可牺牲范围/质量底线、是否接受应急溢价/通道费：
【续约/变更（如适用）】历史履约/遗留债务、历史回款、变更频率与签字机制：
【AI/LLM（如适用）】效果指标与评测集、数据授权边界、成本与延迟预算、供应商与部署、安全与越权：

【保密限制】是否允许在输出中引用原文短句（≤25字）？如不允许：可否提供脱敏短句/字段值以便审计？

---

0.25) Quick entry (execution order: gates first, then scoring)

By default, execute in the following order (even if the output chooses "quick triage," internally the "gates" must still be run to completion):

1. Scenario identification(see 0.5)
2. Stage 0: Structured extraction + information sufficiency X/8(see 3 + 3.4)
3. Pitfall signal scan + conflict detection(see 4 + 5)
4. Red line check (prerequisite)(see 6)
   • Red line hit (with evidence) ⇒ the conclusion can only be 拒绝, skip the full scoring; only output "red line evidence + minimum risk set + clause/stop-loss recommendations + next steps"
   • Red line elements missing and cannot be determined ⇒ conclusion prioritizes 暂停（补齐前拒绝承诺）, only output "gaps + minimum supplementary information set"
5. Only when no red line is hit and information is sufficient: enter scoring (7) → Pre-mortem (8) → risk register (9) → decision/negotiation/execution (10) → minimum supplementary information set (11)

Note: scoring is only a summary; any "gate" (red line/hard gate/Score Capping/conflict) can directly rewrite the upper limit of the conclusion.

---

0.3) Applicable boundaries (to prevent overreach and false certainty)

• Does not replace legal advice: This Skill only provides a risk framework and clause recommendations; when disputes involve "liability/compensation/IP/data processing/security obligations," etc., it is recommended to involve legal counsel.
• Do not make factual assumptions: Historical references must be based on historical materials provided by the user; without materials, only "reusable patterns/recommendations" can be given.
• Do not fabricate evidence: Any "evidence anchor" must come from a short quote of the user's original text; if the user explicitly requests "no reposting/no quoting the original text," follow references/评估标准.md Appendix M use [复述] and mandatorily lower the confidence level, and enter if necessary 暂停。

---

0.5) Scenario identification (first priority)

After the user inputs, first identify the scenario type:

Scenario	Trigger condition	Evaluation focus
Routine evaluation	Single requirement/project	Standard full process
Multi-requirement comparison	"Compare A and B"/"which is better"/"priority ranking"	Horizontal comparison, difference analysis
Historical reference (requires user-provided materials)	"How was that previous project"/"similar project reference"	Historical pattern matching, experience reuse (must not fabricate historical results)
Emergency requirement	"very urgent"/"urgent"/"expedited"/"needed by tomorrow"/"today"	Emergency premium, channel fees, priority conflict impact (affordability)
Renewal/change	Hits "renewal/change/iteration/phase two"	Historical performance cost, change drift assessment
AI/LLM (additional tag, stackable)	"Large model/LLM/RAG/fine-tuning/Agent/conversation/generative"	Enable Appendix O special scan (effectiveness metrics/data authorization/cost and latency/injection and privilege escalation/vendor policy)

Note: AI/LLM is an "additional tag" and can coexist with scenarios such as emergency/renewal/multi-requirement comparison; during assessment, overlay the checks and questions from Appendix O on top of the standard process.

---

1) Output strategy (two tiers, avoid false precision)

A. Rapid triage (applicable: text is very short/large information gaps/only asking "can it be taken on")

Output only (must first give 1.4【概览】）：

• Overview: overall decision + three-question conclusion + information sufficiency/confidence + commitment gate (including strong commitment ceiling)
• Red-line conclusion (✅/❌/⚠️) + evidence anchors/gaps
• Pitfall signal hits (if any)
• 3-6 highest-leverage gaps/conflicts
• Minimum supplementary information set (≤10 questions)

B. Full assessment (applicable: evidence is sufficient or a decision/quote negotiation must be made)

Output a complete report according to the full process of this Skill.

C. Multi-requirement comparison (applicable: need to compare 2 or more requirements side by side)

Output comparison matrix:

• Independent scoring of each requirement
• Side-by-side comparison of dimensions
• Summary of advantages and disadvantages
• Recommendations

Suggested output format (assess independently first, then summarize and compare):

## 【多需求对比：结论与排序】
推荐排序: 1) 需求A 2) 需求B 3) 需求C
排序依据: [用1-3条可审计理由说明：红线/硬门/回款结构/范围确定性/工期风险…]

| 需求 | 结论 | 红线/硬门 | 总分(base) | 应急调整分(如有) | 置信度 | 3条关键风险 | 必须谈判条件(Top3) | 下一步 |
|------|------|-----------|------------|------------------|--------|-------------|---------------------|--------|
| A    | ...  | ...       | .../100     | ...              | ...    | ...         | ...                 | ...    |
| B    | ...  | ...       | .../100     | ...              | ...    | ...         | ...                 | ...    |

Input specification for multi-requirement comparison (must first clarify when information is insufficient):

• Each requirement must have an identifiable name (such as "Requirement A/Requirement B" or the real project name).
• If the user mixes multiple requirements in one passage and they cannot be separated: first ask the user to provide them segmented by requirement, or mark boundaries with headings before scoring ("imagining segmentation" is prohibited).
• If there is 暂停: must clearly state the reason why "the gap makes fair comparison impossible", and provide the "minimum supplementary information set (by priority)"; only rank after it is completed.

Ranking rules for multi-requirement comparison (default):

• First bucket by conclusion:接 > 谈判后接 > 暂停 > 拒绝
• Within the same bucket, rank further: those with fewer hard gates/red lines/Score Capping triggers first; then look at 总分(base) and confidence (confidence takes precedence over total score)

D. Historical reference (applicable: user wants "similar project reference/previous project retrospective")

If the userhas not providedhistorical materials (assessment reports, contract terms, retrospectives, key facts):
Output only "reusable failure modes/high-frequency pitfall signals/suggested clauses and stop-loss points", and clearly mark:[历史材料缺失，无法做事实性对照]。

E. Pause (applicable: information is insufficient to make a commitment)

When any of the following conditions is met, the conclusion must allow output as 暂停(not "refuse", and not "take after negotiation"):

• Red-line check shows ⚠️ 信息不足需补充 and that gap determines whether a red line is triggered;
• Information sufficiency <=4/8, and the user still asks you to "give now whether to take it or not";
• Conflicting items are dense (see Appendix I) and cannot be eliminated with existing materials;
• Any of the three—payment structure/acceptance/scope boundary—is "missing + non-inferable", making it impossible to form executable clauses and stop-loss points.

Interpretation standard:暂停 = "Do not make delivery commitments / do not lock in quotes / do not commit to schedules before the information is complete; only after it is complete do you enter full evaluation or quote negotiation."

F. Output trimming rules (default, to avoid "long but unusable")

Unless the user explicitly requests "expand details / attach the full table," output by default according to the following limits:

• Evidence ledger: by default output only the "key field snapshot (8 items)"; the full ledger is output only when (multi-requirement comparison / dense conflicts / user request).
• Pitfall signal scan: at most 5 items (sorted by impact on the conclusion).
• Conflict detection: at most 5 items (sorted by impact on the conclusion).
• Pre-mortem: 3 items is enough; each item no more than 6 lines.
• Risk register: 6-10 items; and above the table point out the Top 3 priorities (corresponding to negotiation / stop-loss actions).
• Negotiation conditions: 3-7 must-have conditions, and mark the Top 3 (the three that most affect the conclusion).

G. ROM quote/schedule (optional: the user wants a "quote/schedule/person-days" or is in quote negotiation)

Output goal: before the uncertainty has been eliminated,give only ranges + assumptions + verification actions, and bind the "conclusion ceiling/negotiation conditions" to the ROM, to avoid "making a verbal commitment first and then being burned by it."

Default rules:

• First determine the commitment gate (see 2.6/Appendix Q):ROM belongs to G1; before reaching G3, "locking the quote/locking the schedule/hard-coding the launch time" is prohibited.
• If in G0: do not output a ROM, output only 暂停 + the minimum supplementary information set (to avoid "insufficient information but it looks like a quote/schedule was given").
• If information sufficiency <6/8 or a key conflict/hard gate/capping is hit: output only the ROM range(do not give a single-point quote/single-point schedule).
• The ROM must explicitly list: the Top 3-6 key assumptions, the corresponding verification plan, and the "must-have negotiation conditions (Top3)."
• The ROM's range boundaries: use best/base/worst to align with the three-scenario criteria in Appendix H (and must not bypass the hard gates in Appendix E).

For the ROM reference criteria see references/评估标准.md Appendix N。

---

1.4) Output header (mandatory, all outputs must give this section first)

Purpose: to allow "whether the conclusion is consistent/whether there is an overreach commitment/whether the evidence is auditable" to be reviewed within 30 seconds; it also makes the summary of multi-requirement comparisons more stable.

Hard rules:

• Even if 拒绝/暂停/快速分诊 stops early, this section must still be output (otherwise it is easy to miss the commitment gate and the three-question conclusion).
• 信息充分性 If not calculated: write -/8（未评估） and explain the reason (for example: red-line early stop).

Unified template:

## 【概览】
总体决策: 接/谈判后接/暂停/拒绝
是否可做: 接/谈判后接/暂停/拒绝
是否值得做: 值得做/可做但不值得/暂停/N/A（红线早停）
如何做更稳（一句话）: [条款/流程/技术/止损] 的最高杠杆抓手（1-2条即可）

场景标签: 常规/多需求对比/历史参考/应急/续约变更 + AI/LLM(如适用)
总体置信度: 高/中/低
信息充分性: X/8 或 -/8（未评估）
承诺门: G0/G1/G2/G3（原因摘要）| 强承诺上限: 仅暂停/仅ROM/可锁里程碑/可锁报价排期

1.5) Minimum output template (deliverable even with early stop)

Purpose: when 拒绝/暂停/快速分诊 is triggered, avoid outputting a report that is "only a one-sentence conclusion" or "long but not executable."

T1 Reject (red line hit)

## 【概览】
总体决策: 拒绝
是否可做: 拒绝（红线）
是否值得做: N/A（红线早停）
如何做更稳（一句话）: 给出不触红线的替代路径/合规流程建议（不提供越权实现细节）
场景标签: ...
总体置信度: 中/高（红线证据明确时可高；引用受限或关键要素缺失时降为中/低）
信息充分性: -/8（红线早停）
承诺门: G0（红线）| 强承诺上限: 仅拒绝/仅暂停

## 【红线证据】
- [红线项]: 证据锚点（原文短引）

## 【风险最小集（不展开长报告）】
- 主要风险: ...
- 影响: legal/reputation/…（1句）

## 【下一步（若仍要推进）】
1) 需要用户补充/澄清: ...（缺口）
2) 或者：改造方案/替代路径（不触红线）: ...

T2 Pause (evaluate after the information is complete; refuse to commit before it is complete)

## 【概览】
总体决策: 暂停（补齐前拒绝承诺）
是否可做: 暂停
是否值得做: 暂停
如何做更稳（一句话）: 先把范围/验收/付款/依赖字段化并形成书面确认，再进入评估/报价谈判
场景标签: ...
总体置信度: 低/中
信息充分性: X/8
承诺门: G0（原因摘要）| 强承诺上限: 仅暂停/仅补齐信息后再评估

## 【关键缺口/冲突（Top 3-6）】
- 缺口/冲突: ...（影响：哪些维度/结论上限）

## 【需要补充的信息（按优先级，≤10问）】
1) ...（关联维度/为什么会改结论）

T3 Rapid triage (not a red line, but the gap is large/only asking "can it be taken on")

## 【概览】
总体决策: 接/谈判后接/暂停/拒绝（快速分诊）
是否可做: 接/谈判后接/暂停/拒绝
是否值得做: 值得做/可做但不值得/暂停
如何做更稳（一句话）: ...
场景标签: ...
总体置信度: 低/中
信息充分性: X/8
承诺门: G0/G1（原因摘要）| 强承诺上限: 仅暂停/仅ROM

红线: ✅/❌/⚠️（见【红线检查】或在此处给出 1 行结论+证据/缺口）

## 【踩坑信号（最多5条）】
- 命中: ...（证据锚点）→ 影响

## 【最高杠杆缺口/冲突（3-6条）】
- ...

## 【下一步：最小补充信息集（≤10问）】
1) ...

---

2) Mandatory rules (improve accuracy; violators are deemed incomplete)

1. Fabricating citations is prohibited: any "evidence anchor" must come from a short quote of the user's original text; if the user requests not to repost the original text, follow references/评估标准.md Appendix M use [复述] And explicitly mark it as "citation-limited". If not found, write:[未找到原文证据]。
2. Conflict priority: when a critical conflict occurs, the relevant dimension must not be scored 4-5, and the overall confidence usually must not be "High".
3. Gap-triggered score capping (Score Capping): strictly follow references/评估标准.md Appendix E, and in the reportlist the triggered items。
4. Nonlinear decision gates take priority over the total score: strictly follow Appendix E's "hard gates", and in the reportlist the triggered gates。
5. Stop loss first, optimism second: best/worst scenarios may only be built on the premise that "key assumptions have been made explicit", and must not bypass capping/hard gates.
6. Scoring criteria must be consistent: dimension scoring is unified as 0-5; the total score is unified as /100(formula see Appendix H). Any table must explicitly mark units.
7. Historical references must not allow "imagining the ending": unless the user provides historical assessment reports/project retrospectives/key facts, only "reusable risk patterns/clause recommendations" may be output; it must not assert "what happened at the time/what the outcome was".
8. For multi-requirement comparison, first independently, then compare: each requirement must first complete "red lines/pitfalls/conflicts/scoring/Pre-mortem/risk table" under the same criteria, then output horizontal differences and recommended ranking (a single combined total score must not be given alone).
9. The conclusion must be split into three questions: the final output must separately give "whether it can be done / whether it is worth doing / how to do it more reliably", and map them to evidence/gaps/conflicts and clause actions.
10. The conclusion set must include pause: when "insufficient information/critical red-line gaps/irreconcilable conflicts" are triggered, it must be allowed to output 暂停, and must not force a score or force a choice among "accept/accept after negotiation/reject".
11. Time must be auditable: when encountering expressions such as "tomorrow/next week/as soon as possible/the sooner the better", they must be transcribed into absolute time points (including time zone); when transcription is impossible, treat it as a critical gap and lower confidence/trigger pause or capping (especially affecting schedule feasibility and contingency identification).
12. Quotes/schedules must not be falsely precise: when the user requests "quote/schedule/person-days", output a ROM range by default (Appendix N); if information sufficiency < 6/8 or critical capping/conflicts are triggered, then "single-point quote/locked schedule commitment" is prohibited, and only "range + assumptions + mandatory negotiation conditions + verification plan" may be given.
13. best/worst must be verifiable: whenever best/worst or "if...then..." scenario reasoning is given, a "verification plan (Top 3-6)" must also be given at the same time, turning key assumptions into executable verification actions (Appendix N).
14. AI/LLM triggered special scan: when keywords such as "large model/LLM/RAG/fine-tuning/Agent/dialogue/generative" are hit, the red lines/pitfalls/questions and clauses of Appendix O must be superimposed; if any of the effectiveness metrics/evaluation set/data authorization/cost and latency cannot be fielded, the conclusion prioritizes 暂停 or at most 谈判后接(hard commitments on effectiveness are prohibited).
15. Security and operations must not be absent: when the requirement involves the public internet, login authentication, payments, personal information/sensitive information, external APIs, AI/LLM tool invocation/data return flows, etc., it must at least follow references/评估标准.md Appendix P follow-up question "minimum security/operations baseline"; gaps must enter the risk register and affect the conclusion ceiling/negotiation conditions (do not just write a single sentence "pay attention to security").
16. High uncertainty defaults to splitting the order: when information sufficiency <6/8, or key assumptions ≥ 3, or the ROM is marked as "for exploration only", by default recommend phased delivery of "Phase 0 (validation/Discovery) → Phase 1 (delivery)", and make Phase 0 a prerequisite milestone and payment/acceptance node (see 10.6).
17. Commitment gates must be explicitly given: when the user requests "lock the quote/lock the schedule/strong commitment to results/signed endorsement", you must output 承诺门: G0~G3(see 2.6/Appendix Q), and clearly state the "upper limit of what may be committed" (for example: ROM only/schedule cannot be locked/results cannot be committed).
18. Minimum disclosure of sensitive information: if evidence anchors and examples contain mobile phone numbers/email addresses/ID card numbers/bank card numbers/customer full names/specific addresses/account numbers/keys/tokens/private links, etc., they must be redacted with placeholders (e.g.,[客户A]、[金额X]、[Token已省略]), retaining only the minimum information needed to support the judgment.
19. Score→conclusion mapping is for summary only: if a "score range" is needed to assist in summarizing the conclusion, follow references/评估标准.md Appendix N3; however, any red line/hard gate/capping/conflict takes precedence over the score.

---

2.5) Decision algorithm (gates first, then score, to avoid the total score masking fatal risks)

Give the conclusion in the following order (and clearly state the hit items in the report):

1. Red line (Appendix B): if there is clear evidence of a hit ⇒ 拒绝; if key red-line elements are missing such that it cannot be judged ⇒ 暂停（补齐前拒绝承诺）。
2. Score Capping + Conflict (Appendix E/I): triggered items ⇒ apply a ceiling to the relevant dimensions; overall confidence is lowered according to Appendix G.
3. Nonlinear decision gate (Appendix E): any hit ⇒ conclusion at most 谈判后接(or 拒绝), and must not "take it".
4. Then look at the total score and range (Appendix H): the total score is only a summary; recommendations must be tied back to (red line/hard gate/risk register/negotiation conditions).

Note: when a "gate" and a "score" conflict, the "gate" prevails.

2.6) Commitment Gates (determining the extent to which you can commit)

Purpose: to converge strong commitments such as "take it/quote/schedule/results"strong commitmentsinto auditable thresholds; when evidence is insufficient, by default downgrade to 暂停 or ROM 区间, to avoid a single-point commitment backfiring.

G0-G3 (from low to high)

• G0: Pause gate(conservative by default)
  Trigger: red line ⚠️ and key elements missing, information sufficiency <=4/8, or any of scope/acceptance/payment is "missing + cannot be inferred".
  Allowed output:暂停(or if the red line is clear, 拒绝) + minimum supplementary information set.
  Prohibited: quote/lock schedule/commit go-live time/commit results.

• G1: ROM gate (for exploration only)
  Trigger: no red line hit, and information sufficiency >=5/8; allowed to form a ROM using "key assumptions + validation plan".
  Allowed output: ROM range (Appendix N) + mandatory negotiation conditions (Top3) + validation plan (Top 3-6).
  Prohibited: single-point pricing, locking the schedule, and making strong commitments about outcomes (especially AI/LLM).

• G2: Negotiable commitment gate (milestones may be locked, but strong commitments are still prohibited)
  Trigger: information sufficiency >=6/8, and scope/acceptance/payment/dependencies can be fielded; hard gates/conflicts have clear clauses as fallback.
  Allowed output: phased delivery (10.6) + milestone/acceptance/payment recommendations; may provide "conditional scheduling/pricing ranges" (with clauses and dependencies as preconditions).
  Prohibited: "locking down the schedule and single-point pricing" before the contract/dependencies are in place; prohibited to promise absolute AI/LLM outcomes.

• G3: Strong commitment gate (pricing/schedule may be locked, but boundaries must still be stated)
  Trigger: G2 conditions are met, and key clauses have been documented in writing (contract/order/email confirmation), key dependencies and the acceptance environment are available, and responsibility boundaries and stop-loss mechanisms are executable.
  Allowed output: under the premise of clear boundaries/assumptions/change mechanisms, pricing and schedule may be locked (it is still recommended to retain buffers and change clauses).
  Still prohibited: promising uncontrollable outcomes such as "100% error-free/outcomes guaranteed/unlimited liability"; for AI/LLM, only "evaluation criteria + thresholds + canary and rollback" may be promised.

Output requirements (mandatory)

• In the complete assessment's 【评分总览】 add one line:承诺门: Gx（原因摘要）| 强承诺上限: ...
• When the user explicitly requests "lock down the pricing/schedule/outcomes today," first give the commitment gate conclusion, then give the ROM/gaps and next steps (do not calculate the score first).

3) Phase 0: Structured extraction + evidence ledger (must be done first)

Extract the requirements text into fields, and record for each field:

• Status:明确 / 暗示(假设) / 缺失 / 冲突
• Evidence anchor: 1-3 short direct quotes from the original text; if the user requests not to repost the original text, follow references/评估标准.md Appendix M use [复述](and explicitly mark "citation restricted")
• Note: if it is an "implication," it must be written as a "key assumption"

Three states of evidence anchors (unified wording to reduce criteria drift):

• [直引] "...": a short direct quote from the user's original text or a short anonymized quote provided by the user (if it contains sensitive fields, anonymize it first per Appendix M)
• [复述] ...（引用受限）: the user does not allow posting the original text, but provides fielded facts/an auditable summary
• [缺口] ...: evidence is needed but was not found in the user's materials (must affect confidence/trigger capping/trigger one of the pause gates)

Mandatory requirements:

• First complete the full evidence ledger (internal step): used for subsequent scoring, capping, conflicts, and questions; avoid "scoring by feel."
• By default, output only a snapshot of key fields externally: unless the user requests it or multi-requirement comparison/conflict tracing is needed, do not expand the full ledger.

Default output (key field snapshot, 8 items):

## 【关键字段快照】
| 关键字段 | 状态(明确/暗示/缺失/冲突) | 证据锚点([直引]/[复述]/[缺口]) | 关键假设/缺口备注 |
|----------|---------------------------|--------------------|------------------|
| 范围边界 | ... | ... | ... |
| 交付物清单 | ... | ... | ... |
| 验收口径 | ... | ... | ... |
| 付款结构 | ... | ... | ... |
| 工期/里程碑 | ... | ... | ... |
| 关键依赖 | ... | ... | ... |
| 数据合规要点 | ... | ... | ... |
| 决策/验收负责人 | ... | ... | ... |

Expand on demand (full evidence ledger):

## 【证据账本（结构化抽取）】
| 字段 | 状态(明确/暗示/缺失/冲突) | 证据锚点([直引]/[复述]/[缺口]) | 关键假设(如有) | 缺口/冲突备注 |
|------|---------------------------|--------------------|----------------|--------------|
| 背景 | ... | ... | ... | ... |
| 目标 | ... | ... | ... | ... |
| 范围 | ... | ... | ... | ... |
| 交付物 | ... | ... | ... | ... |
| 验收 | ... | ... | ... | ... |
| ... | ... | ... | ... | ... |

3.1 Standard fields (cover as much as possible)

• Background: current pain points and drivers
• Objectives: business goals/success metrics (verifiable)
• Scope: in-scope / out-of-scope (boundaries)
• Deliverables: code/documentation/deployment/training/source code ownership, etc.
• Acceptance: acceptance criteria + process + time limit + default pass conditions
• Non-functional requirements: security/performance/availability/compliance/observability/compatibility (for public networks/sensitive data/external APIs, follow references/评估标准.md Appendix P to ask follow-up questions on the minimum baseline)
• Data and compliance: data type/sensitivity level/source authorization/retention and deletion/cross-border and sharing
• Dependencies and integrations: third-party APIs/internal systems/client-side inputs/account qualifications
• Stakeholders and decisions: decision-makers, owner, acceptance lead, feedback loop
• Plan and resources: milestones, key dates, client cooperation items, own-side resource constraints
• Commercial and contract: budget, payment milestones, change mechanism, maintenance scope, SLA (if any)
• Liability and boundaries: liability cap, indemnification scope, confidentiality, security obligations, dispute resolution

3.2 Renewal/change-specific fields (must be additionally extracted when the input hits "renewal/change/iteration/phase two")

• Historical performance: past delays/rework/dispute points, known遗留 defects/technical debt
• Current cost: support/operations/emergency投入 (person-days/frequency)
• Payment collection and credit: outstanding payments, historical overdue, entity changes
• Change history: number of scope drifts, whether there are change orders and signatures, whether orders are frequently inserted
• Assets and ownership: ownership of existing code/documentation, third-party dependencies and licenses, material authorization

3.3 Emergency request-specific fields (must be additionally extracted when the input hits hard signals such as "urgent/expedited/very urgent/queue jumping/today/tomorrow/48 hours/no time to go through the process")

• Real deadline: the deadline claimed by the client vs the actual executable window
• Impact of priority conflict: the impact of queue jumping on existing projects (delay, resource preemption, quality degradation), and convert it into "priority conflict tolerance" (A6) during scoring
• Emergency premium: whether expedited fees are included, whether additional resources need to be mobilized
• Channel fee: whether an "emergency channel" needs to be occupied, whether there are additional communication costs
• Quality sacrifice level: which quality/features can be sacrificed in exchange for time
• Acceptance risk: the probability of acceptance disputes rises under emergency mode

3.4 Information sufficiency quick check (to prevent "looks professional but unreliable")

For the following "key fields", count whether there isclear evidence:

• Scope boundaries, deliverable list, acceptance criteria, payment structure, duration/milestones, key dependencies, key data compliance points, decision/acceptance leads

Output:

• 信息充分性: X/8
• If <=4/8: default to "rapid triage" and prioritize giving 暂停(unless the user explicitly states "just exploring, no commitment/no quote/no scheduling"); in the full assessment, the overall confidence must not be "high".

---

4) Stage 0.25: Pitfall signal scan (mandatory)

Use references/评估标准.md Appendix C to do two things:

1. List the matched original short sentences (evidence anchors)
2. State which dimensions/conclusion tendencies it affects (at least: lower confidence, enter the risk register)

Rule: matched items must enter the "risk register" and at least affect confidence or trigger negotiation conditions (do not treat them merely as "complaints").

Output format:

## 【踩坑信号扫描】
- 命中: [话术/信号] - 证据锚点 - 影响

---

5) Stage 0.5: Conflict detection (mandatory)

According to references/评估标准.md Appendix I, detect key conflicts, output the list of matched items and evidence anchors, and state the impact:

• Which dimensions' score caps/confidence are affected
• Whether it triggers a tendency to "accept after negotiation/reject"

---

6) Stage 1: Redline check (prerequisite)

Use references/评估标准.md Appendix B. If any one hits: the conclusion can only be Reject or Pause (insufficient information; reject commitment until completed)。

Output format:

## 【红线检查】
✅ 通过 / ❌ 不通过 / ⚠️ 信息不足需补充
- [检查项]: 通过/不通过/不足 - 证据锚点或缺口

---

7) Phase 2: Structured scoring (evidence + confidence + three scenarios)

Dimensions and weights follow references/评估标准.md Appendix A; calculation formulas follow Appendix H.

7.0 Clarification of definitions (to avoid "score drift" in emergency scenarios)

• base total score (/100): uses only A1-A5 (total weight = 100).
• emergency adjustment score: calculated only when identified as an "emergency need", range -5 ~ +15(formula see references/评估标准.md Appendix H).
• emergency total score：base 总分 + 应急调整分(the report may show both the "emergency adjustment score" and the "emergency total score (whether capped)").

7.1 The scoring output must additionally include two items (auditability)

• Triggered Score Capping: list each one (from Appendix E)
• Triggered nonlinear decision gates: list each one (from Appendix E)

7.2 Score definitions (must be explicitly stated)

• 维度得分：0-5
• 贡献分: converted to /100 (for example A1 compliance risk:30 * 4/5 = 24）

7.3 Output format

## 【评分总览】
总分(base): XX/100 | 区间(best~worst): AA~BB/100 | 总体置信度: 高/中/低
信息充分性: X/8
承诺门: G0/G1/G2/G3（原因摘要）| 强承诺上限: 仅暂停/仅ROM/可锁里程碑/可锁报价排期
[应急评估]: 是/否
- 若是：应急调整分: (+/-)N（-5~+15）| 应急总分: ZZ/100（可注明是否封顶）| 应急溢价: X% | 优先级冲突可承受度: 低/中/高（越高越能插队） | 质量牺牲度: 0-5（越高越糟）

触发的 Score Capping:
- ...

触发的非线性决策门:
- ...

| 维度(权重) | 维度得分(base/best/worst, 0-5) | 贡献分(base, /100) | 置信度 | 证据/缺口/冲突 | 关键假设 |
|------------|---------------------------------|--------------------|--------|----------------|----------|
| 合规风险(30) | x/x/x | yy.y | ... | ... | ... |
| 可交付性(20) | x/x/x | yy.y | ... | ... | ... |
| 工期可行性(20) | x/x/x | yy.y | ... | ... | ... |
| 价格与收益匹配(20) | x/x/x | yy.y | ... | ... | ... |
| 协作与沟通风险(10) | x/x/x | yy.y | ... | ... | ... |
| [应急]优先级冲突可承受度(+10) | x/x/x | yy.y | ... | ... | ... |
| [应急]应急溢价覆盖(+5) | x/x/x | yy.y | ... | ... | ... |
| [应急]质量牺牲度(-5, 惩罚项) | x/x/x | yy.y | ... | ... | ... |

7.4 Supplementary scoring for emergency needs (additional scoring items for emergency scenarios)

When identified as an emergency need, add the following scoring items:

Additional dimension	Weight	Scoring description
Tolerability of priority conflict	+10	Impact of queue jumping on existing projectsTolerability level, 0-5 points (higher is more tolerable)
Emergency premium coverage	+5	Whether the expedited fee covers the additional cost, 0-5 points
Quality sacrifice level	-5	Penalty item: the greater the sacrifice, the higher the score, 0-5 points (reverse, 0 is best)

Note: emergency "channel fees/queue-jumping costs" should preferably be covered through emergency premium and milestone/change/acceptance clauses , rather than using "subjective score inflation" to bypass red lines, hard gates, and capping.

---

8) Phase 3: Pre-mortem (failure chains + interaction items)

Output at least 3 "most likely failure chains", and mandatorily include:

• Trigger conditions / amplification mechanisms / loss forms
• Early signals (observable)
• Stop-loss point (quantifiable)
• Monitoring and responsibility (frequency + responsible party)
• Preventive actions (contract/process/technology)

Additional requirement: point out at least 1-2 "interaction risks" (for example: unclear acceptance + overly large final payment + extremely short schedule will directly turn delays into bad debts/disputes).

---

9) Phase 4: Risk register (make recommendations actionable)

Output 6-10 risk items that truly "would change the conclusion or clauses", and converge them in a table:

• Risk statement (do not use abstract words)
• Impact (schedule/cost/quality/legal/reputation)
• Probability (1-5) and impact level (1-5), used for ranking (does not participate in the total score）
• Trigger conditions & early signals
• Prevention/mitigation (contract/process/technology)
• Kill Criteria (stop-loss/exit conditions)
• Risk ownership (who currently bears it? How is it transferred/shared?)
• Risk owner/responsible party (who monitors it, who acts on it)
• Evidence/gaps/conflicts (including pitfall signals/conflict hits)

Example format:

## 【风险登记表】
| 风险 | 影响类型 | 概率(1-5) | 影响(1-5) | 优先级(P*I) | 触发条件/早期信号 | 缓解动作 | Kill Criteria | 风险归属 | 责任方 | 证据/缺口 |
|------|----------|-----------|-----------|--------------|-------------------|----------|--------------|----------|--------|----------|
| ...  | ...      | ...       | ...       | ...          | ...               | ...      | ...          | ...      | ...    | ...      |

Recommended calibration (for quick consistency):

• Probability 1-5: 1=rarely happens; 3=may happen; 5=almost certain to happen
• Impact 1-5: 1=negligible; 3=requires extra person-days/delay but manageable; 5=major loss/legal or reputational incident

---

10) Phase 5: Decision + negotiation conditions + execution plan

10.1 Conclusion (choose one of four)

• Accept
• Accept after negotiation (mandatory conditions list)
• Reject
• Pause (reassess after filling information gaps; refuse to commit before gaps are filled)

The conclusion must be consistent with: red lines, capping, hard gates, and risk ownership.

暂停 typical triggers:

• The red-line check belongs to ⚠️ 信息不足需补充, and that gap determines whether a red line is triggered;
• Insufficient information sufficiency (<=4/8) and gaps are concentrated in acceptance/payment/scope/data compliance/key dependencies;
• Conflicting items cannot be resolved with existing materials (Appendix I).

10.2 Negotiation conditions (must be verifiable and executable)

Use references/评估标准.md Appendix D, and select only conditions strongly related to Phase 3/4. And mandatorily state: which "failure chain/risk item" each condition corresponds to.

Tip: If legal clause disputes arise regarding "liability/indemnity/IP/data processing/security obligations", it is recommended to involve legal review (this Skill provides a risk framework and does not replace legal advice).

10.3 Execution plan (turn risk into a plan)

At minimum include:

• Scope convergence and freeze point (when to freeze, how changes are charged)
• Milestones and acceptance cadence (acceptance window and deemed acceptance)
• Client-side dependency delivery checklist (who/when/format)
• Quality and security baseline (minimum observability/backup/permissions, etc.)
• Stop-loss triggers (overdue payment, change overrun, dependency unavailable, etc.)

10.4 ROM quote and scheduling (optional: explicitly requested by the user or in quote negotiation)

Output requirements:

• By default output the best/base/worst of range(do not give a single point).
• Each range must be bound to: key assumptions (<=6) + mandatory negotiation conditions (Top3) + validation plan (Top 3-6).
• If information sufficiency < 6/8 or a key hard gate/conflict/capping is triggered: explicitly write ROM 仅供探索，不可用于锁报价/锁排期。

For calibration and formulas, see references/评估标准.md Appendix N。

10.5 Validation plan (optional but strongly recommended: turn key assumptions into executable validation)

When any of the following applies, a validation plan must be output:

• You provided best/worst scenarios;
• There are >= 3 key assumptions;
• The user requests "quote now/lock the schedule now", but information sufficiency is insufficient or conflicts are unresolved.

Recommended format:

## 【验证计划（Top 3-6）】
| 假设/不确定点 | 验证方式（POC/Spike/样本数据/接口联调） | 通过标准（可验收） | 责任方 | 截止时间 |
|--------------|----------------------------------------|-------------------|--------|----------|
| ...          | ...                                    | ...               | ...    | ...      |

10.6 Phased delivery/split-order recommendations (optional but strongly recommended: turn uncertainty into milestones)

Applicable: insufficient information/many key assumptions/the client wants you to "lock the quote or lock the schedule now".

Goal: turn the "validation plan" intoNegotiable contract and payment milestones, to avoid bearing the full delivery risk all at once.

Recommended output format:

## 【阶段化交付/拆单建议】
Phase 0（验证/Discovery，先把关键假设打穿）:
- 目标: ...
- 交付物: POC/Spike/样本数据验证报告 + 明确范围边界 + 验收草案 + ROM 区间收敛
- 验收口径: ...（可验证）
- 工期: ...（区间） | 费用/计费口径: ...
- 关键止损点: ...（未达标则可终止/不进入 Phase 1）

Phase 1（交付）:
- 目标: ...
- 交付物: ...（按冻结范围）
- 里程碑与付款: 预付款/里程碑/尾款（尾款≤30%）+ 验收窗口 + 逾期默认通过

---

11) Stage 6: Minimum supplementary information set (high-leverage questions)

Output 5-12 questions, sorted by "likelihood of changing the conclusion". Each question must be labeled with:

• Related dimension/risk item
• Why it would change the conclusion (1 sentence)

Prioritize selecting/rewriting questions from references/评估标准.md of Appendix L: Minimum Supplementary Information Question Bank , then tailor them based on the current gaps.

---

Final output template (unified)

# 需求风险评估报告

## 【概览】
总体决策: 接/谈判后接/暂停/拒绝
是否可做: 接/谈判后接/暂停/拒绝
是否值得做: 值得做/可做但不值得/暂停/N/A（红线早停）
如何做更稳（一句话）: ...
场景标签: ...
总体置信度: 高/中/低
信息充分性: X/8 或 -/8（未评估）
承诺门: G0/G1/G2/G3（原因摘要）| 强承诺上限: 仅暂停/仅ROM/可锁里程碑/可锁报价排期

理由(1-3条，必须可审计): ...（映射到红线/硬门/冲突/付款与验收/关键依赖）

## 【关键字段快照（可选）】
| 关键字段 | 状态(明确/暗示/缺失/冲突) | 证据锚点([直引]/[复述]/[缺口]) | 关键假设/缺口备注 |
|----------|---------------------------|--------------------|------------------|
| 范围边界 | ... | ... | ... |
| 交付物清单 | ... | ... | ... |
| 验收口径 | ... | ... | ... |
| 付款结构 | ... | ... | ... |
| 工期/里程碑 | ... | ... | ... |
| 关键依赖 | ... | ... | ... |
| 数据合规要点 | ... | ... | ... |
| 决策/验收负责人 | ... | ... | ... |

## 【红线检查】
...

## 【踩坑信号扫描】
...

## 【冲突检测】
- 命中项: ...（证据锚点）
- 影响: ...

## 【关键假设清单】
- 假设1: ...（若不成立会如何影响结论/分数/条款）
- 假设2: ...

## 【验证计划（Top 3-6，可选但强烈推荐）】
| 假设/不确定点 | 验证方式（POC/Spike/样本数据/接口联调） | 通过标准（可验收） | 责任方 | 截止时间 |
|--------------|----------------------------------------|-------------------|--------|----------|
| ...          | ...                                    | ...               | ...    | ...      |

## 【评分总览】
...（含分值口径、触发的 Score Capping 与非线性决策门）

## 【ROM 报价与排期（可选）】
口径: best/base/worst（区间，不给单点承诺）
...

## 【阶段化交付/拆单建议（可选但推荐）】
Phase 0（验证/Discovery）: ...
Phase 1（交付）: ...

## 【Pre-mortem：最可能的失败链路】
1. ...
2. ...
3. ...

## 【风险登记表】
...

## 【谈判条件（必须达成）】
- [ ] 条件 ...（映射：失败链路/风险项）
- [ ] ...

## 【执行方案（把风险变成动作）】
- 范围与冻结: ...
- 里程碑与验收: ...
- 依赖与责任: ...
- 技术底线: ...
- 止损触发: ...

## 【需要补充的信息（按优先级）】
1. ...

---

Common failure modes (must avoid)

1. A single total score masks red lines: always execute Stage 1 + Appendix E nonlinear gates
2. Giving a high score despite missing evidence: execute Score Capping + low confidence + ask questions
3. Listing only risks without actions: every risk must map to a contract/process/technical control
4. Inconsistent conclusions: conclusions must be consistent with gates, payment, acceptance, and responsibility/risk ownership
5. Ignoring conflict/pitfall signals: items hit in Stage 0.25/0.5 must be reflected in scoring, confidence, and conclusions
6. Fabricated citations: must use the user's original text; if none, write[未找到原文证据]
7. Missing assessment of emergency scenarios: an emergency need was identified but the emergency scoring logic was not executed
8. No horizontal analysis in multi-requirement comparisons: only assessed separately, no dimensional comparison
9. False precision in quotes/schedules: giving a single-point quote/locked schedule despite insufficient information; should output a ROM range + assumptions + validation plan
10. best/worst with no validation hook: scenario projection gives no validation plan, making recommendations unactionable
11. Not splitting orders under high uncertainty: committing to full delivery all at once despite many key assumptions/insufficient information; should output a phased delivery recommendation from Phase 0→Phase 1 (see 10.6)
12. Security/operations left blank: failing to ask follow-up questions on the minimum security/operations baseline for public network/sensitive data scenarios, leading to launch incidents or loss of control over responsibility (Appendix P)

---

Trigger scenarios

• The user sends a PRD/meeting minutes/chat records/email
• The user asks "can this requirement be taken on/should we initiate the project/what are the risks/should we renew the contract/should the change be made"
• The user says "help me compare A and B"/"which is better"/"prioritize them"
• The user says "how was that previous project"/"reference to similar projects"
• The user says "very urgent"/"urgent"/"expedite"/"needed by tomorrow"
• The user requests "lock the quote/lock the schedule/give person-days" (requires ROM range + assumptions + validation plan, and order splitting if necessary)
• The user mentions "large model/LLM/RAG/fine-tuning/Agent/generative" and wants to assess performance metrics, data authorization, cost, and delivery risks
• When the input is very short: by default, first do a quick triage, then recommend filling in information to proceed to a full assessment

---

Quick usage example

When the user sends requirement text, directly execute the full assessment process and output the report.

Trigger the Skill when the user asks the following questions:

• "Help me see whether this requirement can be taken on"
• "What are the risks of this project?"
• "Evaluate this PRD"
• "Is this outsourcing requirement reliable?"
• "Can it be approved as a project?"
• "Help me compare these two requirements"
• "Which one has higher priority?"
• "What happened to that e-commerce project later?"
• "This is very urgent, needed tomorrow"

---

Self-check stress scenarios (used to verify whether the rules are truly followed)

1. Contract to be added later: The user says "build it first, the contract can be added later." Expected: hit a pitfall signal; conclusion at most 谈判后接 or 暂停; must give conditions such as "sign first/pay first/written confirmation".
2. Payment + acceptance results unclear: Expected: trigger a hard gate; conclusion cannot be 接; the risk register and negotiation conditions must cover payment and acceptance.
3. Emergency queue jumping: The user says "launch tomorrow/it is needed today/queue jump." Expected: identify the emergency; output an emergency adjustment score; clearly state the impact of queue jumping and the emergency premium/channel fee/sacrificed items.
4. Illegal use: The user explicitly describes gray-market/illegal use. Expected: red line hit => 拒绝, do not enter full scoring.
5. Multiple requirements mixed together and inseparable: The user mixes A/B/C in one paragraph with unclear boundaries. Expected: first ask the user to split paragraphs or mark boundaries; prohibit "imagining segmentation" before scoring and ranking.
6. Historical follow-up but no materials: The user asks "what happened to that project later?" Expected: mark [历史材料缺失，无法做事实性对照], provide only reusable patterns and a question checklist.
7. Information sufficiency <=4/8: Expected: by default prioritize 暂停(refuse commitment before completion), and output the minimum supplementary information set (<=10 questions).
8. Requesting an overall score without evidence: The user says "just give the total score first, do not cite." Expected: refuse to fabricate, require materials, or switch to rapid triage and lower confidence.
9. Citation restricted (do not repost original text): The user says "the materials cannot be forwarded/do not quote the original text." Expected: according to references/评估标准.md Appendix M use [复述] as evidence anchors, and lower confidence to no higher than "medium"; when key fields are missing, prioritize 暂停。
10. Strong AI/LLM performance commitments: The user says "must be 100% accurate/must not make mistakes/performance must be like ChatGPT," but does not provide an evaluation set or acceptance criteria. Expected: enable Appendix O; conclusion at most 谈判后接 or 暂停; must provide "evaluation set/metrics/acceptance criteria + disclaimer + validation plan (POC)."
11. Lock quote/lock schedule but insufficient information: The user requests "finalize the quote/schedule today," but information sufficiency < 6/8 or there are many key assumptions. Expected: prohibit single-point commitment; output ROM range + key assumptions + validation plan, and recommend phased delivery (10.6).
12. Public internet/sensitive data but no discussion of security operations: The user wants a fast launch and it involves login/permissions/personal information. Expected: according to Appendix P, ask follow-up questions for the minimum security/operations baseline; gaps enter the risk register and negotiation conditions; if necessary, conclusion 暂停。
13. Insists on "first produce the complete version" but refuses to supplement information: The user says "give the complete report first / fill in all the tables first, discuss the issues later," and information sufficiency <= 4/8 or key fields for red lines/payment/acceptance/scope are missing. Expected: still first follow 0.121 to deliver the usable version for round 1, and lock the conclusion at 暂停 or at most 谈判后接; clearly state the boundary of "refusing to commit/refusing to lock pricing and scheduling before the information is complete."