Back to Details

chain-spec-risk-metrics

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Chain Spec Risk Metrics

Chain Spec Risk Metrics

Table of Contents

目录

Purpose

用途

This skill helps you create comprehensive plans for high-stakes initiatives by chaining together three critical components: clear specifications, proactive risk analysis, and measurable success metrics. It ensures initiatives are well-defined, risks are anticipated and mitigated, and progress can be objectively tracked.
该技能通过将三个关键环节结合起来，帮助你为高风险举措制定全面规划：明确的规范、主动的风险分析以及可衡量的成功指标。它能确保举措定义清晰、风险被提前识别并缓解，且进度可被客观追踪。

When to Use This Skill

何时使用该技能

Use this skill when you need to:
  • Plan complex implementations - Migrations, infrastructure changes, system redesigns requiring detailed specs
  • Launch new initiatives - Products, features, programs that need risk assessment and success measurement
  • Make high-stakes decisions - Strategic choices where failure modes must be identified and monitored
  • Coordinate cross-functional work - Initiatives requiring clear specifications for alignment and risk transparency
  • Request comprehensive planning - User asks "plan this migration", "create implementation roadmap", "what could go wrong?"
  • Establish accountability - Need clear success criteria and risk owners for governance
Trigger phrases:
  • "Plan this [migration/launch/implementation]"
  • "Create a roadmap for..."
  • "What could go wrong with..."
  • "How do we measure success for..."
  • "Write a spec that includes risks and metrics"
  • "Comprehensive plan with risk mitigation"
在以下场景中使用该技能：
  • 规划复杂实施项目 - 需要详细规范的迁移、基础设施变更、系统重设计
  • 启动新举措 - 需要风险评估和成功衡量的产品、功能、项目
  • 做出高风险决策 - 必须识别并监控失败模式的战略选择
  • 协调跨职能工作 - 需要明确规范以达成对齐和风险透明的举措
  • 请求全面规划 - 用户询问“规划此次迁移”、“创建实施路线图”、“可能会出什么问题？”
  • 建立问责机制 - 需要明确的成功标准和风险负责人以进行治理
触发短语：
  • “规划此次[迁移/上线/实施]”
  • “为……创建路线图”
  • “……可能会出什么问题？”
  • “我们如何衡量……的成功？”
  • “撰写包含风险和指标的规范”
  • “包含风险缓解的全面规划”

When NOT to Use This Skill

何时不使用该技能

Skip this skill when:
  • Quick decisions - Low-stakes choices don't need full premortem treatment
  • Specifications only - If user just needs a spec without risk/metrics analysis (use one-pager-prd or adr-architecture instead)
  • Risk analysis only - If focused solely on identifying risks (use project-risk-register or postmortem instead)
  • Metrics only - If just defining KPIs (use metrics-tree instead)
  • Already decided and executing - Use postmortem or reviews-retros-reflection for retrospectives
  • Brainstorming alternatives - Use brainstorm-diverge-converge to generate options first
在以下场景中跳过该技能：
  • 快速决策 - 低风险选择无需完整的事前剖析处理
  • 仅需规范 - 如果用户只需要规范而不需要风险/指标分析（请使用one-pager-prd或adr-architecture）
  • 仅需风险分析 - 如果仅专注于识别风险（请使用project-risk-register或postmortem）
  • 仅需指标 - 如果仅定义KPI（请使用metrics-tree）
  • 已决策并执行中 - 如需回顾请使用postmortem或reviews-retros-reflection
  • 头脑风暴备选方案 - 请先使用brainstorm-diverge-converge生成选项

What Is It?

技能定义

Chain Spec Risk Metrics is a meta-skill that combines three complementary techniques into a comprehensive planning artifact:
  1. Specification - Define what you're building/changing with clarity (scope, requirements, approach, timeline)
  2. Risk Analysis - Identify what could go wrong through premortem ("imagine we failed - why?") and create risk register with mitigations
  3. Success Metrics - Define measurable outcomes to track progress and validate success
Quick example:
Initiative: Migrate monolith to microservices
Spec: Decompose into 5 services (auth, user, order, inventory, payment), API gateway, shared data patterns
Risks:
  • Data consistency issues between services (High) → Implement saga pattern with compensation
  • Performance degradation from network hops (Medium) → Load test with production traffic patterns
Metrics:
  • Deployment frequency (target: 10+ per week, baseline: 2 per week)
  • API p99 latency (target: < 200ms, baseline: 150ms)
  • Mean time to recovery (target: < 30min, baseline: 2 hours)
Chain Spec Risk Metrics是一种元技能，它将三种互补的技术整合为一个全面的规划产物：
  1. 规范 - 清晰定义你要构建/变更的内容（范围、需求、方法、时间线）
  2. 风险分析 - 通过Premortem（“假设我们失败了——原因是什么？”）识别可能出现的问题，并创建带有缓解措施的风险登记册
  3. 成功指标 - 定义可衡量的结果以追踪进度并验证成功
简单示例：
举措： 将单体应用迁移至微服务
规范： 拆分为5个服务（认证、用户、订单、库存、支付）、API网关、共享数据模式
风险：
  • 服务间数据一致性问题（高）→ 实现带有补偿机制的saga模式
  • 网络跳点导致性能下降（中）→ 使用生产流量模式进行负载测试
指标：
  • 部署频率（目标：每周10+次，基准：每周2次）
  • API p99延迟（目标：<200ms，基准：150ms）
  • 平均恢复时间（目标：<30分钟，基准：2小时）

Workflow

工作流程

Copy this checklist and track your progress:
Chain Spec Risk Metrics Progress:
- [ ] Step 1: Gather initiative context
- [ ] Step 2: Write comprehensive specification
- [ ] Step 3: Conduct premortem and build risk register
- [ ] Step 4: Define success metrics and instrumentation
- [ ] Step 5: Validate completeness and deliver
Step 1: Gather initiative context
Ask user for the initiative goal, constraints (time/budget/resources), stakeholders, current state (baseline), and desired outcomes. Clarify whether this is a greenfield build, migration, enhancement, or strategic change. See resources/template.md for full context questions.
Step 2: Write comprehensive specification
Create detailed specification covering scope (what's in/out), approach (architecture/methodology), requirements (functional/non-functional), dependencies, timeline, and success criteria. For standard initiatives use resources/template.md; for complex multi-phase programs see resources/methodology.md for decomposition techniques.
Step 3: Conduct premortem and build risk register
Run premortem exercise: "Imagine 12 months from now this initiative failed spectacularly. What went wrong?" Identify risks across technical, operational, organizational, and external dimensions. For each risk document likelihood, impact, mitigation strategy, and owner. See Premortem Technique and Risk Register Structure sections, or resources/methodology.md for advanced risk assessment methods.
Step 4: Define success metrics and instrumentation
Identify leading indicators (early signals), lagging indicators (outcome measures), and counter-metrics (what you're NOT willing to sacrifice). Specify current baseline, target values, measurement method, and tracking cadence for each metric. See Metrics Framework and use resources/template.md for standard structure.
Step 5: Validate completeness and deliver
Self-check the complete artifact using resources/evaluators/rubric_chain_spec_risk_metrics.json. Ensure specification is clear and actionable, risks are comprehensive with mitigations, metrics measure actual success, and all three components reinforce each other. Minimum standard: Average score ≥ 3.5 across all criteria.
复制以下检查表并追踪进度：
Chain Spec Risk Metrics Progress:
- [ ] Step 1: Gather initiative context
- [ ] Step 2: Write comprehensive specification
- [ ] Step 3: Conduct premortem and build risk register
- [ ] Step 4: Define success metrics and instrumentation
- [ ] Step 5: Validate completeness and deliver
步骤1：收集举措背景信息
向用户询问举措目标、约束条件（时间/预算/资源）、利益相关者、当前状态（基准）以及期望结果。明确这是全新构建、迁移、优化还是战略变更。完整的背景问题请参考resources/template.md。
步骤2：撰写全面规范
创建详细规范，涵盖范围（包含/排除内容）、方法（架构/方法论）、需求（功能/非功能）、依赖项、时间线和成功标准。对于标准举措，请使用resources/template.md；对于复杂的多阶段项目，请查看resources/methodology.md了解分解技巧。
步骤3：执行Premortem并构建风险登记册
开展Premortem练习：“假设12个月后该举措彻底失败了，原因是什么？” 从技术、运营、组织和外部维度识别风险。为每个风险记录可能性、影响、缓解策略和负责人。请查看Premortem技术和风险登记册结构部分，或resources/methodology.md了解高级风险评估方法。
步骤4：定义成功指标和监测机制
识别领先指标（早期信号）、滞后指标（结果衡量）和反向指标（不愿牺牲的内容）。为每个指标指定当前基准、目标值、衡量方法和追踪频率。请查看指标框架并使用resources/template.md的标准结构。
步骤5：验证完整性并交付
使用resources/evaluators/rubric_chain_spec_risk_metrics.json对完整产物进行自我检查。确保规范清晰可执行、风险全面且带有缓解措施、指标能真正衡量成功，且三个环节相互支撑。最低标准：所有标准的平均得分≥3.5。

Common Patterns

常见模式

Premortem Technique

Premortem技术

  1. Set the scene: "It's [6/12/24] months from now. This initiative failed catastrophically."
  2. Brainstorm failure causes: Each stakeholder writes 3-5 reasons why it failed (independently first)
  3. Cluster and prioritize: Group similar failures, vote on likelihood and impact
  4. Convert to risk register: Each failure mode becomes a risk with mitigation plan
  1. 设定场景：“现在是[6/12/24]个月后，该举措彻底失败了。”
  2. 头脑风暴失败原因：每个利益相关者独立写下3-5个失败原因
  3. 归类并排序：将相似的失败原因分组，投票决定可能性和影响程度
  4. 转换为风险登记册：每个失败模式对应一个带有缓解计划的风险

Risk Register Structure

风险登记册结构

For each identified risk, document:
  • Risk description: Specific failure mode (not vague "project delay")
  • Category: Technical, operational, organizational, external
  • Likelihood: Low/Medium/High (or probability %)
  • Impact: Low/Medium/High (or cost estimate)
  • Mitigation strategy: What you'll do to reduce likelihood or impact
  • Owner: Who monitors and responds to this risk
  • Status: Open, Mitigated, Accepted, Closed
为每个识别出的风险记录：
  • 风险描述：具体的失败模式（而非模糊的“项目延迟”）
  • 类别：技术、运营、组织、外部
  • 可能性：低/中/高（或概率百分比）
  • 影响：低/中/高（或成本估算）
  • 缓解策略：将采取什么措施降低可能性或影响
  • 负责人：谁来监控和应对该风险
  • 状态：待处理、已缓解、已接受、已关闭

Metrics Framework

指标框架

Leading indicators (predict future success):
  • Deployment frequency, code review velocity, incident detection time
Lagging indicators (measure outcomes):
  • Uptime, user adoption, revenue impact, customer satisfaction
Counter-metrics (what you're NOT willing to sacrifice):
  • Code quality, team morale, security posture, user privacy
领先指标（预测未来成功）：
  • 部署频率、代码评审速度、事件检测时间
滞后指标（衡量结果）：
  • 可用性、用户 adoption、收入影响、客户满意度
反向指标（不愿牺牲的内容）：
  • 代码质量、团队士气、安全态势、用户隐私

Guardrails

注意准则

  • Don't skip any component - Spec without risks = blind spots; risks without metrics = unvalidated mitigations
  • Be specific in specifications - "Improve performance" is not a spec; "Reduce p99 API latency from 500ms to 200ms" is
  • Quantify risks - Use likelihood × impact scores to prioritize; don't treat all risks equally
  • Make metrics measurable - "Better UX" is not measurable; "Increase checkout completion from 67% to 75%" is
  • Assign owners - Every risk and metric needs a clear owner who monitors and acts
  • State assumptions explicitly - Document what you're assuming about resources, timelines, dependencies
  • Include counter-metrics - Always define what success does NOT mean sacrificing
  • Update as you learn - This is a living document; revisit after milestones to update risks/metrics
  • 不要跳过任何环节 - 无风险分析的规范=盲区；无指标的风险分析=未验证的缓解措施
  • 规范要具体 - “提升性能”不是规范；“将API p99延迟从500ms降低至200ms”才是
  • 量化风险 - 使用可能性×影响得分进行优先级排序；不要同等对待所有风险
  • 指标要可衡量 - “更好的UX”不可衡量；“将结账完成率从67%提升至75%”才是
  • 指定负责人 - 每个风险和指标都需要明确的监控和执行负责人
  • 明确假设条件 - 记录你对资源、时间线、依赖项的假设
  • 包含反向指标 - 始终定义成功不应牺牲的内容
  • 随学习更新 - 这是一份动态文档；在里程碑后重新审视并更新风险/指标

Quick Reference

快速参考

ComponentWhen to UseResource
TemplateStandard initiatives with known patternsresources/template.md
MethodologyComplex multi-phase programs, novel risksresources/methodology.md
ExamplesSee what good looks likeresources/examples/
RubricValidate before deliveringresources/evaluators/rubric_chain_spec_risk_metrics.json
组件使用场景资源
模板具有已知模式的标准举措resources/template.md
方法论复杂的多阶段项目、新型风险resources/methodology.md
示例参考优秀案例resources/examples/
评估准则交付前进行验证resources/evaluators/rubric_chain_spec_risk_metrics.json