Back to Details

product-judgement

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Product Judgement

Product Judgement

Audit the product as a connected system.
Product Judgement is the orchestration Skill for the four foundational Skills:
  • Focal—what belongs on a screen, what waits, and what wins attention.
  • Compass—how a person moves between screens without getting lost.
  • Flywheel—where momentum drops across the relationship and what earns the next stage.
  • Soul—which working moments deserve craft and memory.
It is not a fifth design lens and it does not replace the four local methodologies. It runs them against a shared evidence map, keeps their boundaries intact, reconciles their findings, and returns one prioritized audit. Do not invent a fifth score or average the native totals together.
将产品作为一个互联系统进行审核。
Product Judgement是整合四项基础Skill的协调工具：
  • Focal——确定哪些内容应出现在屏幕上，哪些需要延后展示，哪些应吸引用户注意力。
  • Compass——确保用户在不同屏幕间切换时不会迷路。
  • Flywheel——找出用户与产品关系中动力流失的节点，以及能推动关系进入下一阶段的因素。
  • Soul——识别哪些交互时刻值得精心打造，让用户留下深刻记忆。
它并非第五种设计视角，也不会替代上述四种局部方法论。它基于统一的证据图谱应用这些方法，保持各方法的边界清晰，整合它们的发现，并输出一份优先级明确的审核报告。请勿创建第五种评分标准，也不要将四项原生评分简单平均。

Use it when

使用场景

Use Product Judgement when the question is larger than one screen, one flow, one relationship stage, or one expressive moment:
  • audit the whole app or a meaningful product area;
  • find why a working product feels incoherent, hard to navigate, low-value, or forgettable;
  • decide which UX problem to fix first when several Skills identify related issues;
  • reconcile screen, journey, relationship, and memory findings into one implementation sequence.
For a narrower question, invoke the local Skill directly. A single dashboard belongs to Focal; an onboarding path belongs to Compass; a first-value or retention problem belongs to Flywheel; a happy-path authorship problem belongs to Soul.
当问题范围超出单屏幕、单流程、单关系阶段或单个表达时刻时，使用Product Judgement：
  • 审核整个应用或产品的重要模块；
  • 找出运行中的产品为何显得不连贯、难以导航、价值感低或缺乏记忆点；
  • 当多个Skill发现相关问题时，确定应优先修复哪一个UX问题；
  • 将屏幕、旅程、用户关系和记忆点相关的发现整合为一套可落地的实现顺序。
针对更细分的问题，请直接调用对应的局部Skill。单个仪表盘属于Focal的范畴；引导流程属于Compass；首次价值交付或留存问题属于Flywheel；核心路径的体验打造问题属于Soul。

Evidence and context

证据与上下文

Accept a codebase, live product, clickable prototype, Figma or Paper frames, screenshots, or a product description. Also accept the surrounding product context: the PRD (Product Requirements Document), product brief, strategy or goal documents, user research, personas, journey maps, analytics or funnel data, support themes, experiment history, and technical, accessibility, legal, or safety constraints. The artifact tells you what exists; these materials explain why it exists, for whom, and what success means. The more relevant context available, the more specific and defensible the audit. Prefer the codebase when it is available because it can expose routes, components, state transitions, validation, persistence, re-entry behavior, copy, and implementation constraints that frames cannot.
Before auditing, collect or infer the following and label assumptions:
  • business goal, product requirements, success criteria, and the outcome that matters;
  • primary audience, expertise, situation, and stakes;
  • the user's intended first-value event;
  • the primary entry points and journeys;
  • known constraints, evidence, metrics, or unresolved questions.
Do not stall when context is missing. State the missing context in Coverage or Basis, use 
not shown
for consequential states or lifecycle moments that the evidence does not expose, and name the fastest validating check.
可接受的材料包括代码库、上线产品、可点击原型、Figma或Paper框架、截图或产品描述。同时也接受产品的周边上下文信息：PRD（产品需求文档）、产品 brief、战略或目标文档、用户研究、用户画像、旅程地图、分析或漏斗数据、支持主题、实验历史，以及技术、无障碍、法律或安全约束。产品工件展示了当前的状态，而这些材料解释了产品为何存在、服务于谁以及成功的标准是什么。可用的相关上下文越丰富，审核结果就越具体、越有说服力。如果有代码库，优先使用它，因为它能暴露框架无法展示的路由、组件、状态转换、验证、持久化、重入行为、文案和实现约束。
在审核前，收集或推断以下信息并标注假设：
  • 业务目标、产品需求、成功标准以及关键成果；
  • 核心受众、专业能力、使用场景和风险；
  • 用户预期的首次价值交付事件；
  • 主要入口点和用户旅程；
  • 已知约束、证据、指标或未解决的问题。
如果缺少上下文，无需停滞。在覆盖范围或依据部分说明缺失的内容，对于证据未展示的重要状态或生命周期时刻，标注为
not shown
，并指出最快的验证方式。

Figma and Paper

Figma与Paper

Frames are valid evidence for visible structure, hierarchy, copy, and the transitions they actually show. They are not proof of behavior. When auditing from frames:
  1. Point the agent at one frame or component for Focal.
  2. Select the ordered set of frames, including branches and meaningful variants, for Compass. Say which frames are in sequence; do not make the agent guess the path order.
  3. Include first-run, success, error, empty, loading, permission, interruption, and re-entry frames when they exist.
  4. Mark persistence, validation, timing, and unseen lifecycle behavior as 
    not shown
    unless the frames or prototype demonstrate them.
Useful prompts include 
/focal audit this dashboard
and 
/compass audit this flow
. A holistic pass is 
/product-judgement audit this app
with the relevant frames selected.
框架可作为可见结构、层级、文案以及实际展示的转场效果的有效证据，但无法证明产品行为。基于框架进行审核时：
  1. 针对Focal，将Agent指向单个框架或组件。
  2. 针对Compass，选择有序的框架集合，包括分支和有意义的变体，并说明框架的顺序；不要让Agent猜测路径顺序。
  3. 如有首次运行、成功、错误、空状态、加载、权限、中断和重入等框架，请一并包含。
  4. 除非框架或原型能展示持久化、验证、计时和未展示的生命周期行为，否则将这些内容标注为
    not shown
    。
有用的指令包括
/focal audit this dashboard
和
/compass audit this flow
。整体审核可使用
/product-judgement audit this app
并选择相关框架。

Keep the four boundaries clear

保持四项Skill的边界清晰

Use the failure's location and consequence to assign a primary owner. Several Skills may mention the same symptom, but the holistic audit prints one issue with one owner and any dependencies.
QuestionPrimary ownerKeep it out of this Skill
What belongs here, what waits, and what should draw attention?Focal—the screen-local decision surfaceDo not turn it into a navigation, retention, or expressive-treatment fix.
Can the user reach the destination, know where they are, and keep their state?Compass—the path and its seamsDo not score local hierarchy or call every extra step a retention problem.
Does the relationship earn trust, first value, recognition, return, or advocacy?Flywheel—the stage transition and lifecycleDo not use it to replace a missing Back affordance, lost route, or screen-level action model.
Once the floor holds, what deserves to be remembered?Soul—the authored moment and its frequencyDo not decorate a maze, hide a trust failure, or treat novelty as a retention strategy.
根据问题出现的位置和影响，确定主要负责的Skill。多个Skill可能提到同一症状，但整体审核报告中每个问题应只归属一个主要负责Skill，并标注任何依赖关系。
问题主要负责Skill请勿归为该Skill范畴
哪些内容应放在此处，哪些延后，哪些应吸引注意力？Focal——屏幕层面的决策范围不要将其转化为导航、留存或表达性处理的修复问题。
用户能否到达目标位置、了解自身所处位置并保持状态？Compass——路径及其衔接处不要为本地层级评分，也不要将每一步额外操作都视为留存问题。
用户与产品的关系是否能赢得信任、实现首次价值交付、获得认可、促使用户返回或传播推荐？Flywheel——阶段转换和生命周期不要用它来替代缺失的返回按钮、丢失的路由或屏幕级操作模型。
在基础体验达标后，哪些内容值得被记住？Soul——精心打造的时刻及其出现频率不要用装饰掩盖流程混乱、信任缺失，也不要将新颖性视为留存策略。

The two common overlaps

两种常见重叠场景

Compass vs Flywheel. Compass asks whether the route is understandable, economical, reversible, and stateful: Where do I go? What is next? How do I get back? Flywheel asks whether the effort and uncertainty on that route earn the next relationship stage: Why should I continue? Is this too much work or exposure before value? A hidden step, dead end, or lost state is Compass. A coherent but over-demanding setup, premature ask, or effort that delays first value is Flywheel. Use both when both conditions are present; make the path defect the primary owner when it blocks access to the stage.
Flywheel vs Soul. Flywheel owns whether value lands, is recognized, and creates a reason to return. Soul owns how a working moment is authored, placed, and made memorable. If people do not return because they never reached or recognized value, fix Flywheel. If value lands and the path holds but the experience is anonymous, use Soul. Soul may identify motion or expressive treatment that strengthens a Flywheel win or emotion, but it must wait behind trust, comprehension, accessibility, and path integrity.
Focal has the same boundary rule: a confusing action surface is Focal; a misleading product promise or missing evidence across the relationship is Flywheel; a broken transition is Compass. Do not let a local symptom acquire the wrong owner just because it appears on a screen.
Compass vs Flywheel：Compass关注路径是否易懂、高效、可逆且保持状态：我该去哪里？下一步是什么？如何返回？ Flywheel关注路径上的付出和不确定性是否能推动用户关系进入下一阶段：我为什么要继续？在获得价值前是否需要付出过多努力或承担过多风险？ 隐藏步骤、死胡同或状态丢失属于Compass的问题。流程连贯但设置要求过高、过早索要权限或延迟首次价值交付属于Flywheel的问题。如果两种情况都存在，同时使用两个Skill；当路径缺陷阻碍用户进入下一阶段时，将路径问题作为主要负责项。
Flywheel vs Soul：Flywheel负责价值是否传递到位、是否被用户感知并促使用户返回。Soul负责交互时刻的打造、定位和记忆点设计。如果用户不返回是因为从未获得或感知到价值，修复Flywheel的问题。如果价值已传递且流程顺畅，但体验缺乏辨识度，使用Soul优化。Soul可能会识别出能强化Flywheel成果或情感的动效或表达性处理，但必须在信任、理解、无障碍和路径完整性达标后再进行。
Focal也遵循同样的边界规则：混乱的操作界面属于Focal；产品承诺误导或用户关系中缺乏证据属于Flywheel；转场失效属于Compass。不要仅仅因为症状出现在屏幕上，就将局部问题归错负责Skill。

The audit workflow

审核流程

Run the four local methodologies in this order. This is the evidence order, not an automatic fix order.
按以下顺序执行四项局部方法论。这是证据处理顺序，而非自动修复顺序。

1. Frame the audit and map coverage

1. 确定审核范围并绘制覆盖图谱

Establish the product, audience, stakes, first value, business goal, and evidence basis. Build a compact map with four views:
  • Screens—entry, first decision, first value, repeat use, re-entry, high-stakes actions, and failure or recovery states.
  • Journeys—the primary entry-to-outcome flows, branches, deep links, Back behavior, interruption, and resume behavior.
  • Relationship—arrival, trust, activation before value, first value, return, lapse, re-engagement, and advocacy.
  • Memory—the default happy path, its beats, frequency, ending, and any moments already carrying expressive treatment.
Use the same implementation locator throughout: surface or transition · exact app state · lifecycle moment. Keep rendered state separate from occurrence. For example, 
Import screen · validation error · first-run activation
is precise; 
onboarding
is not.
明确产品、受众、风险、首次价值交付、业务目标和证据依据。构建包含四个视图的简洁图谱：
  • 屏幕——入口、首次决策、首次价值交付、重复使用、重入、高风险操作以及失败或恢复状态。
  • 旅程——从入口到结果的主要流程、分支、深度链接、返回行为、中断和恢复行为。
  • 用户关系——初次接触、建立信任、价值交付前的激活、首次价值交付、返回、流失、重新激活和传播推荐。
  • 记忆点——默认的核心路径、关键节点、出现频率、结束方式以及任何已进行表达性处理的时刻。
全程使用统一的实现定位方式：界面或转场 · 具体应用状态 · 生命周期时刻。区分渲染状态和发生场景。例如，
Import screen · validation error · first-run activation
是精准的；而
onboarding
则不够具体。

2. Run Focal on the decision surfaces

2. 对决策界面运行Focal

Load Focal and its review contract. Review the screens that carry the primary decisions or expose the largest relationship stages. Include representative variants rather than pretending one screenshot proves every state. Preserve Focal's native 
/12
score and One Screen, One Clear Intent verdict.
Record which screen issue is local and which one is actually a path, lifecycle, or memory issue for the later reconciliation.
加载Focal及其评审协议。评审承载主要决策或展示用户关系重要阶段的屏幕。包含具有代表性的变体，而非假设一张截图能涵盖所有状态。保留Focal原生的
/12
评分和One Screen, One Clear Intent（单屏单明确目标）结论。
记录哪些屏幕问题是局部的，哪些实际上是路径、生命周期或记忆点问题，以便后续整合。

3. Run Compass on the primary journeys

3. 对主要旅程运行Compass

Load Compass and its review contract. Review the primary journeys as ordered paths, including the seams where state, context, or entry points can fail. Preserve Compass's native 
/12
score and Never Lost verdict.
Do not use Compass to rescore every screen. Use Focal for local structure and Compass for the route between those surfaces.
加载Compass及其评审协议。将主要旅程视为有序路径进行评审，包括状态、上下文或入口点可能失效的衔接处。保留Compass原生的
/12
评分和Never Lost（永不迷路）结论。
不要用Compass重新为每个屏幕评分。局部结构使用Focal，屏幕间的路由使用Compass。

4. Run Flywheel across the relationship

4. 针对用户关系运行Flywheel

Load Flywheel and its review contract. Name first value before diagnosing. Score all four plays—Trust, Friction, Wins, and Emotion—then identify the earliest leaking stage, not merely the largest downstream symptom. Preserve Flywheel's native 
/16
score and diagnosis.
Use the Compass map as evidence for the route, but keep the question separate: Compass explains whether the user can traverse the path; Flywheel explains whether the path earns the next relationship stage.
加载Flywheel及其评审协议。在诊断前明确首次价值交付的定义。对四个维度——信任、摩擦、成果、情感——进行评分，然后找出最早出现流失的阶段，而非仅关注下游最严重的症状。保留Flywheel原生的
/16
评分和诊断结果。
使用Compass图谱作为路径的证据，但保持问题独立：Compass说明用户能否遍历路径；Flywheel说明路径是否能推动用户关系进入下一阶段。

5. Run Soul after checking the floor

5. 在基础体验达标后运行Soul

Load Soul and its review contract. Sweep the default happy path, assign frequency and state to each beat, and preserve Soul's native 
/16
score and authored-state verdict.
If Focal, Compass, or Flywheel finds a broken floor, still record the Soul findings, but sequence expressive treatment after the structural or lifecycle repair. Do not use delight to cover confusion, a maze, a trust break, or invisible value.
加载Soul及其评审协议。梳理默认核心路径，为每个关键节点分配频率和状态，保留Soul原生的
/16
评分和体验打造状态结论。
如果Focal、Compass或Flywheel发现基础体验存在问题，仍需记录Soul的发现，但表达性处理的优化应排在结构或生命周期修复之后。不要用愉悦感掩盖困惑、流程混乱、信任缺失或隐形价值。

6. Reconcile without flattening the Skills

6. 整合结果但不弱化各Skill的作用

Create one issue ledger from the four native reports:
  1. Deduplicate findings that describe the same condition.
  2. Assign one primary owner using the boundary rules above.
  3. Keep the exact surface or transition, state, and lifecycle locator.
  4. Record dependencies, such as 
    Soul after Compass
    or 
    Flywheel after Focal
    .
  5. Preserve every local score, verdict, and component score rationale; do not average unlike totals into a false Product Judgement score.
  6. Separate observed, inferred, walked, tested, and measured claims.
Set the priority changes by dependency and consequence. Rank concrete implementation changes, not just findings or Skill owners:
  1. Stop material harm, coercion, hidden cost, permission, or safety failures.
  2. Repair the earliest blocker on the route to first value—often trust or path integrity.
  3. Fix screen-local decision surfaces that keep the user from acting or understanding.
  4. Make delivered value visible and earn the next relationship stage.
  5. Spend Soul's expressive budget only after the path, value, and trust floor holds.
This order can change when evidence shows a different upstream dependency. Do not force every product through the same backlog.
从四份原生报告中创建一份问题清单：
  1. 合并描述同一问题的发现。
  2. 根据上述边界规则分配一个主要负责Skill。
  3. 保留精准的界面或转场、状态和生命周期定位信息。
  4. 记录依赖关系，例如
    Soul after Compass
    或
    Flywheel after Focal
    。
  5. 保留所有局部评分、结论和组件评分的依据；不要将不同类型的总分平均为虚假的Product Judgement评分。
  6. 区分观察到的、推断的、模拟的、测试的和测量的结论。
根据依赖关系和影响确定优先级变化。对具体的实现变更进行排序，而非仅对发现或Skill负责项排序：
  1. 停止造成实质性伤害、强制操作、隐藏成本、权限滥用或安全失效的问题。
  2. 修复首次价值交付路径上最早出现的阻碍——通常是信任或路径完整性问题。
  3. 修复阻碍用户操作或理解的屏幕局部决策界面问题。
  4. 让已交付的价值可见，并推动用户关系进入下一阶段。
  5. 只有在路径、价值和信任基础达标后，才投入资源进行Soul的表达性优化。
当证据显示存在不同的上游依赖时，可调整此顺序。不要强制所有产品遵循相同的待办事项顺序。

Holistic output

整体输出

Run all four local audits first, then return this wrapper. Keep the local reports available in working notes; print their full locked templates only when the user asks for the detailed passes. The Score rationale section is required: never report a native total such as 
Focal 7/12
without its component rationales. Each component must use the local chain evidence → consequence → rubric anchor → next-point change. The Priority changes section is also required: each item must name the owner, exact surface or transition, app state, lifecycle moment, concrete change, reason for its rank, and dependency.
markdown
**Verdict:** <coherent | needs structural work | needs lifecycle work | needs authorship> · <one biggest cross-scale issue>

**Product:** <what it is, for whom> · goal: <business or user outcome> · first value: <event, or "undefined"> · stakes: <low | medium | high>
**Coverage:** <screens, journeys, relationship stages, states, and lifecycle moments reviewed> · gaps: <material gaps, or "none">
**Basis:** <observed from a screenshot or artifact | inferred from code | tested in a prototype or live product | walked from a description | measured from product data> · confirm with: <fastest validating check>
**Blocker:** <None. | concise blocker reason>
先完成四项局部审核，再返回此汇总内容。将局部报告保留在工作笔记中；仅当用户要求详细报告时，才输出完整的锁定模板。评分依据部分是必填项：切勿仅报告
Focal 7/12
这类原生总分而不提供组件评分依据。每个组件必须遵循局部逻辑链：证据 → 影响 → 评分标准锚点 → 下一步变更。优先级变更部分也是必填项：每个条目必须指明负责Skill、具体界面或转场、应用状态、生命周期时刻、具体变更、排序理由和依赖关系。
markdown
**Verdict:** <coherent | needs structural work | needs lifecycle work | needs authorship> · <one biggest cross-scale issue>

**Product:** <what it is, for whom> · goal: <business or user outcome> · first value: <event, or "undefined"> · stakes: <low | medium | high>
**Coverage:** <screens, journeys, relationship stages, states, and lifecycle moments reviewed> · gaps: <material gaps, or "none">
**Basis:** <observed from a screenshot or artifact | inferred from code | tested in a prototype or live product | walked from a description | measured from product data> · confirm with: <fastest validating check>
**Blocker:** <None. | concise blocker reason>

Four-scale scorecard

Four-scale scorecard

SkillNative verdictScoreCross-scale finding
Focal<Clear Intent verdict>_/12 · ./4<one line>
Compass<Never Lost verdict>_/12 · ./4<one line>
Flywheel<earliest leaking stage>_/16 · ./4<one line>
Soul<authored-state verdict>_/16 · ./4<one line>
SkillNative verdictScoreCross-scale finding
Focal<Clear Intent verdict>_/12 · ./4<one line>
Compass<Never Lost verdict>_/12 · ./4<one line>
Flywheel<earliest leaking stage>_/16 · ./4<one line>
Soul<authored-state verdict>_/16 · ./4<one line>

Score rationale

Score rationale

  • Focal <_/12>: Information Architecture _/4 — <evidence → consequence → rubric anchor → next-point change>; Progressive Disclosure _/4 — <evidence → consequence → rubric anchor → next-point change>; Visual Hierarchy _/4 — <evidence → consequence → rubric anchor → next-point change>.
  • Compass <_/12>: Orientation _/4 — <evidence → consequence → rubric anchor → next-point change>; Path Economy _/4 — <evidence → consequence → rubric anchor → next-point change>; Continuity _/4 — <evidence → consequence → rubric anchor → next-point change>.
  • Flywheel <_/16>: Trust _/4 — <evidence → consequence → rubric anchor → next-point change>; Friction _/4 — <evidence → consequence → rubric anchor → next-point change>; Wins _/4 — <evidence → consequence → rubric anchor → next-point change>; Emotion _/4 — <evidence → consequence → rubric anchor → next-point change>.
  • Soul <_/16>: Baseline _/4 — <evidence → consequence → rubric anchor → next-point change>; Placement _/4 — <evidence → consequence → rubric anchor → next-point change>; Proportion _/4 — <evidence → consequence → rubric anchor → next-point change>; Signature _/4 — <evidence → consequence → rubric anchor → next-point change>.
  • Focal <_/12>: Information Architecture _/4 — <evidence → consequence → rubric anchor → next-point change>; Progressive Disclosure _/4 — <evidence → consequence → rubric anchor → next-point change>; Visual Hierarchy _/4 — <evidence → consequence → rubric anchor → next-point change>.
  • Compass <_/12>: Orientation _/4 — <evidence → consequence → rubric anchor → next-point change>; Path Economy _/4 — <evidence → consequence → rubric anchor → next-point change>; Continuity _/4 — <evidence → consequence → rubric anchor → next-point change>.
  • Flywheel <_/16>: Trust _/4 — <evidence → consequence → rubric anchor → next-point change>; Friction _/4 — <evidence → consequence → rubric anchor → next-point change>; Wins _/4 — <evidence → consequence → rubric anchor → next-point change>; Emotion _/4 — <evidence → consequence → rubric anchor → next-point change>.
  • Soul <_/16>: Baseline _/4 — <evidence → consequence → rubric anchor → next-point change>; Placement _/4 — <evidence → consequence → rubric anchor → next-point change>; Proportion _/4 — <evidence → consequence → rubric anchor → next-point change>; Signature _/4 — <evidence → consequence → rubric anchor → next-point change>.

Cross-scale findings

Cross-scale findings

  • [P0–P3 · <Focal | Compass | Flywheel | Soul>] At: <surface or transition> · state: <exact app state> · lifecycle: <exact lifecycle moment>. <Name>—<observation and cost>. Fix: <specific change>. Depends on: <owner or "none">.
  • [P0–P3 · <Focal | Compass | Flywheel | Soul>] At: <surface or transition> · state: <exact app state> · lifecycle: <exact lifecycle moment>. <Name>—<observation and cost>. Fix: <specific change>. Depends on: <owner or "none">.

Priority changes

Priority changes

  1. Priority 1 · <P0–P3> · Now — <primary owner and stage> · At: <surface or transition> · state: <exact app state> · lifecycle: <exact lifecycle moment>. Change: <the concrete implementation change>. Why now: <the consequence and upstream reason>. Depends on: <owner or "none">.
  2. Priority 2 · <P0–P3> · Next — <primary owner> · At: <surface or transition> · state: <exact app state> · lifecycle: <exact lifecycle moment>. Change: <the change unlocked by Now>. Why now: <the consequence and dependency>. Depends on: <owner or "none">.
  3. Priority 3 · <P0–P3> · Then — <primary owner> · At: <surface or transition> · state: <exact app state> · lifecycle: <exact lifecycle moment>. Change: <the change that makes value, return, or comprehension stronger>. Why now: <the consequence and dependency>. Depends on: <owner or "none">.
  4. Priority 4 · <P0–P3> · After the floor holds — Soul · At: <surface or transition> · state: <exact app state> · lifecycle: <exact lifecycle moment>. Change: <the one or two moments worth authoring, or "None yet."> Why now: <why expressive treatment is ready—or not ready>. Depends on: <owner or "none">.
  1. Priority 1 · <P0–P3> · Now — <primary owner and stage> · At: <surface or transition> · state: <exact app state> · lifecycle: <exact lifecycle moment>. Change: <the concrete implementation change>. Why now: <the consequence and upstream reason>. Depends on: <owner or "none">.
  2. Priority 2 · <P0–P3> · Next — <primary owner> · At: <surface or transition> · state: <exact app state> · lifecycle: <exact lifecycle moment>. Change: <the change unlocked by Now>. Why now: <the consequence and dependency>. Depends on: <owner or "none">.
  3. Priority 3 · <P0–P3> · Then — <primary owner> · At: <surface or transition> · state: <exact app state> · lifecycle: <exact lifecycle moment>. Change: <the change that makes value, return, or comprehension stronger>. Why now: <the consequence and dependency>. Depends on: <owner or "none">.
  4. Priority 4 · <P0–P3> · After the floor holds — Soul · At: <surface or transition> · state: <exact app state> · lifecycle: <exact lifecycle moment>. Change: <the one or two moments worth authoring, or "None yet."> Why now: <why expressive treatment is ready—or not ready>. Depends on: <owner or "none">.

Handoffs and validation

Handoffs and validation

  • Focal: <screen(s) to review or rebuild, with state and lifecycle>.
  • Compass: <journey or seam to review or rebuild, with state and lifecycle>.
  • Flywheel: <stage and first-value or return check to validate>.
  • Soul: <moment to author only after its dependency holds>.
  • Validation: <fastest behavior, user test, or metric for the highest-consequence claim>.

Never emit a vague location such as `the onboarding` or `the dashboard` when a screen, transition, state, and lifecycle moment can be named. If the evidence cannot support that precision, say `not shown` and name what would expose it.
  • Focal: <screen(s) to review or rebuild, with state and lifecycle>.
  • Compass: <journey or seam to review or rebuild, with state and lifecycle>.
  • Flywheel: <stage and first-value or return check to validate>.
  • Soul: <moment to author only after its dependency holds>.
  • Validation: <fastest behavior, user test, or metric for the highest-consequence claim>.

切勿使用`the onboarding`或`the dashboard`这类模糊的定位，应明确命名屏幕、转场、状态和生命周期时刻。如果证据无法支持这种精准度，标注为`not shown`并说明需要哪些信息才能暴露该内容。

Routing

路由规则

  • No argument → explain that this is the whole-app audit and ask for the product, codebase, prototype, or selected frames plus the primary goal.
  • audit
    / 
    review
    / 
    critique
     → run the full workflow above. Treat 
    audit
    as the default command.
  • A single-screen request → hand off to 
    /focal
    and do not run the other three unless the user asks for a holistic pass.
  • A single-flow request → hand off to 
    /compass
    ; add 
    /flywheel
    only when the question includes activation, value, return, or a relationship leak.
  • A single moment or expressive-treatment request → hand off to 
    /soul
    , after checking whether the floor is sound.
  • A build request → use the relevant local build Skill; Product Judgement is an audit and reconciliation layer, not a replacement for the Screen, Flow, Stage, or Moment Specs.
  • 无指令 → 说明这是全应用审核工具，并请求提供产品、代码库、原型或选定框架以及核心目标。
  • audit
    / 
    review
    / 
    critique
     → 执行上述完整流程。默认将
    audit
    作为指令。
  • 单屏幕请求 → 转交至
    /focal
    ，除非用户要求进行整体审核，否则不运行其他三项Skill。
  • 单流程请求 → 转交至
    /compass
    ；仅当问题涉及激活、价值交付、返回或用户关系流失时，才添加
    /flywheel
    。
  • 单个时刻或表达性处理请求 → 在确认基础体验达标后，转交至
    /soul
    。
  • 构建请求 → 使用对应的局部构建Skill；Product Judgement是审核和整合层，不能替代Screen、Flow、Stage或Moment Specs。

Source files

源文件

Read the sibling Skill spines and their review contracts when running the local passes:
  • Focal · review
  • Compass · review
  • Flywheel · review
  • Soul · review
执行局部审核时，请阅读相关的Skill核心文档及其评审协议：
  • Focal · review
  • Compass · review
  • Flywheel · review
  • Soul · review