agentsclimarketplace

P12 contemplation orchestrator

Skill gmaxxxie/ai-native-product-agent-skills/skills/p12-contemplation-orchestrator

AI Native Product Methodology — 80 executable skills across P0-P14 stages, covering needs discovery to aesthetic authority. From 8 books.

Install
npx -y skills add gmaxxxie/ai-native-product-agent-skills --skill p12-contemplation-orchestrator

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

  • no licenseNo license file was found in the repository. Code published without one is not open source by default, so using it at work is a question for whoever answers licensing questions where you are.

What its author says it does

Copied from the file, not written here

《观照》全书编排器——根据用户输入的问题类型，路由到对应的章节Skill，串联全链路决策修正流程

SKILL.md

15.2 KB, as published. Nobody here has run it

观照编排器（Contemplation Orchestrator）

适用场景

  • 产品经理面对复杂决策，不确定该从哪个视角切入
  • 团队想用《观照》框架做系统性复盘或决策评审
  • 需要将模糊的产品困惑拆解为具体检查步骤

输入

字段说明
user_question用户提出的核心问题或困惑
context可选：产品阶段、团队规模、行业等背景信息
focus_area可选：用户希望聚焦的章节/主题

输出

  • 推荐的 Skill 调用链（有序列表）
  • 每个 Skill 的调用理由
  • 聚合后的检查清单

工作流程

  1. 问题分类：分析 user_question，判断其核心属于哪个章节领域
  2. 构建调用链：按"前提→视角→问题→判断→表达→行动→收入→止损→反思"顺序排列
  3. 执行 Skill 调用：依次调用链中每个 Skill
  4. 聚合输出：汇总所有 Skill 的发现，生成结构化"观照报告"
  5. 行动建议：给出 1-3 条可直接执行的具体行动项

注意事项

  • 并非每个问题都需要走完全部 Skill，应根据问题类型智能裁剪
  • 如果只问局部问题，优先调用相关章节，不必强制从 Ch1 开始
  • 编排器本身不产出内容，只负责路由和聚合

核心概念

1. 观照（Contemplation）

  • 定义：一种在推进之前先回看自己的职业能力——回看自己是怎么定义问题的、怎么命名用户的、怎么相信某组数据的
  • 关键点：
    • 方法解决"怎么做"，观照处理"怎么做之前怎么看"
    • 不是慢下来发呆，而是一种前置校准能力
    • 没有方法团队会混乱；只有方法没有观照，团队会稳定地偏离正轨
    • 偏差常常发生在动作之前，而非动作之中

2. 八正道框架（Eightfold Path Framework）

  • 定义：书中的核心分析框架，按修正层次递进的八个维度
  • 关键点：
    • 正见（问题定义）→ 正思维（判断路径）→ 正语（组织表达）→ 正业（产品机制）→ 正命（商业逻辑）→ 正精进（努力方向）→ 正念（注意力）→ 正定（决策状态）
    • 正见放在最前——方向不正，速度就是风险
    • 八个维度不是独立工具，而是一条完整的修正链路

3. 方法前提检查（Method Prerequisite Check）

  • 定义：在调用任何方法之前，先验证该方法依赖的前提是否仍然成立
  • 关键点：
    • 旧方法没有失效，失效的是"产品还是原来那种产品"的默认
    • 前提没被重新校准时，方法不再是罗盘，而更像放大器
    • 把数据从"答案"降级为"警报器"

4. 三层问题分析（Three-Layer Problem Analysis）

  • 定义：现象层→场景层（情境层）→关系层的逐层深入分析法
  • 关键点：
    • 现象层：用户说了什么、数据发生了什么
    • 场景层：什么约束条件下、用户承担什么成本
    • 关系层：背后变化的是什么关系（工具与用户、人与AI、组织与结果）

5. 从方法到观照的转换

  • 定义：先修正看法再调用方法的工作模式
  • 关键点：
    • 产品方法处理动作问题，产品观照处理动作之前的看法问题
    • 观照不是替代方法，而是在方法之前运行
    • 对所有"太顺的答案"保留一点迟疑

深入核心概念

1. 观照作为前置校准能力

"产品方法解决的是动作问题，产品观照处理的是动作之前的看法问题。"

书稿在第二章明确区分了"方法"与"观照"的关系：方法关心的是"下一步做什么"，观照关心的是"我为什么会觉得下一步该这么做"。这两者不是替代关系，而是前后关系。没有方法，团队会混乱；只有方法没有观照，团队会稳定地偏离正轨。观照不是慢下来发呆，而是一种职业能力——在推进之前，先回看自己是怎么定义问题的、怎么命名用户的、怎么相信某组数据的。

在产品编排场景中，这意味着编排器不应直接跳入方法调用，而应在路由之前先做一次"看法校正"。当用户提出问题时，编排器需要先判断：这个问题的定义是否已被团队的位置和指标语言过滤过？用户说的"留存下降"到底是功能问题、信任问题还是商业模式问题？只有看法先被校正，后续的 Skill 调用链才能真正触及问题，而不是在错误的方向上高效运转。

2. 八正道的递进修正链路

"正见修问题定义，正思维修判断路径，正语修组织表达，正业修产品机制，正命修商业逻辑，正精进修努力方向，正念修注意力，正定修决策状态。"

书稿将八正道定义为一条完整的修正链路，而非八个独立工具。每个维度处理不同层次的偏差：正见解决"看到了什么"，正思维解决"怎么走到这个结论的"，正语解决"怎么说的"，正业解决"做的机制是否正当"，正命解决"赚钱方式是否扭曲了立场"，正精进解决"努力方向是否需要修正"，正念解决"注意力是否被表层信号吸走"。偏差常常发生在动作之前，而非动作之中。

编排器的核心职责是根据问题类型智能构建这条链路。不是每个问题都需要走完全部八个维度——一个"数据好看但感觉不对劲"的问题可能同时涉及正业、正命和正念；一个"方法以前有效现在不灵"的问题可能只需前提检查加正见。编排器应识别问题的修正层次，按需裁剪调用链，避免过度编排让用户觉得流程太重。

3. 三层问题分析的路由依据

"现象层：用户说了什么、数据发生了什么。场景层：什么约束条件下、用户承担什么成本。关系层：背后变化的是什么关系。"

书稿提出的三层分析法是编排器进行问题分类的核心依据。现象层最容易被看见，也最容易看错——团队往往在现象层就开始争论"这是什么问题"。场景层揭示用户的真实处境和成本结构，决定了"可行解空间"。关系层则揭示结构性原因和改变杠杆点。编排器应引导用户从现象层出发，逐步深入到场景层和关系层，再根据分析结果路由到对应 Skill。

在实际编排中，当用户描述的问题停留在现象层（如"搜索量下降"），编排器应先调用正见 Skill 帮助深入到关系层（如"用户不再愿意自己组织关键词"），再根据关系层洞察路由到具体修正 Skill。这种"先看深再路由"的模式，能避免编排器直接在表层问题上跳转，确保后续 Skill 的分析建立在更准确的问题定义之上。

分步执行

第 1 步：问题分类与路由

  1. 接收用户的 user_question
  2. 分析问题核心属于哪个修正维度：
    • 涉及"问题看不清/定义模糊" → 正见（p12a-contemplation-right-view）
    • 涉及"方法以前有效现在不灵" → 前提检查（p12a-contemplation-prerequisite-check）
    • 涉及"看法需要多角度审视" → 视角修正（p12a-contemplation-view-correction）
    • 涉及"判断依据混乱" → 正思维（p12a-contemplation-right-thinking）
    • 涉及"沟通失真/话术掩盖问题" → 正语（p12a-contemplation-right-speech）
    • 涉及"机制设计/行动正当性" → 正业（p12a-contemplation-right-action）
    • 涉及"商业模式/收入与立场" → 正命（p12a-contemplation-right-livelihood）
    • 涉及"该不该继续/止损" → 正精进（p12a-contemplation-right-effort）
    • 涉及"注意力/看数据但看不见问题" → 正念（p12a-contemplation-right-mindfulness）

第 2 步：构建调用链

  1. 如果问题跨多个维度，按八正道顺序排列调用链
  2. 默认完整链：前提检查 → 视角修正 → 正见 → 正思维 → 正语 → 正业 → 正命 → 正精进 → 正念
  3. 根据问题类型智能裁剪，局部问题优先调用相关章节

第 3 步：执行 Skill 调用

  1. 依次调用链中每个 Skill
  2. 将上一个 Skill 的输出作为下一个的参考上下文
  3. 记录每个 Skill 的发现和建议

第 4 步：聚合输出

  1. 汇总所有 Skill 的发现
  2. 生成结构化"观照报告"
  3. 报告包含：问题重新定义、关键偏差识别、修正建议

第 5 步：行动建议

  1. 给出 1-3 条可直接执行的具体行动项
  2. 每条行动项标注来自哪个修正维度
  3. 标注优先级和预期效果

示例 1：AI 功能上线后留存下降

场景描述

团队上线了一个 AI 写作助手功能，初期数据亮眼，但两个月后续费率只有 43%。团队在复盘会上争论不休：有人说"市场还没准备好"，有人说"功能不够强"，有人说"定价有问题"。

用户输入

user_question: "我们的 AI 写作助手续费率只有 43%，竞品普遍 65-75%。团队对此有分歧，有人说市场不成熟，有人说产品力不够。该从哪里看这个问题？"
context: "B2B SaaS，订阅制，上线 6 个月"

执行流程

  1. 问题分类：涉及"问题定义模糊"（续费低到底是什么问题？）+ "判断路径混乱"（不同人有不同归因）+ "商业模式审视"（续费模式本身）
  2. 构建调用链：视角修正 → 正见 → 正思维 → 正命
  3. 执行调用：
    • 视角修正：拆解"市场不成熟"这个说法——它把产品问题改写成了时间问题
    • 正见：三层分析——现象层（续费率低）→ 场景层（用户在什么场景下决定不续费）→ 关系层（续费模式天然诱导"让用户持续回来"）
    • 正思维：拆解团队判断链——前提（用户说好就会续费）未验证；情绪（对增长的焦虑驱动了过度功能堆砌）
    • 正命：审视商业模式——续费模式奖励"让用户形成依赖"而非"让用户变强"

输出结果

=== 观照报告 ===

【问题重定义】
原问题："续费率低，市场不成熟"
修正后："产品定位从'让用户变强'滑向了'让用户依赖'，续费模式在加速这一偏移"

【关键偏差】
1. "市场不成熟"掩盖了四个不同可能：价值主张不清/价格不匹配/客户选错/产品方向偏移
2. 团队默认"用户说好就会续费"，未验证"好"与"续费"之间的因果
3. 商业模式天然奖励依赖感，团队被 KPI 推着偏离了初心

【行动建议】
1. 【正见-高优】重新做一次用户深度访谈，区分"使用中满意"和"续费时犹豫"的真实原因
2. 【正命-中优】审视提醒机制和功能层级设计，哪些在帮助用户、哪些在制造依赖
3. 【正语-低优】将"市场不成熟"这个结论翻译成可验证的具体命题

示例 2：增长机制引发用户反噬

场景描述

一款学习 App 靠连续签到和倒计时提醒将 DAU 拉高了 18%，但用户研究访谈中出现越来越多"被绑架""被推着走"的反馈。团队纠结于"数据很好"与"用户不舒服"之间的矛盾。

用户输入

user_question: "我们学习 App 的 DAU 涨了 18%，但用户访谈里越来越多'被绑架'的反馈。增长和用户体验怎么平衡？"
context: "C端教育产品，DAU 50万，Q3 刚上线连续签到+倒计时提醒机制"

执行流程

  1. 问题分类：核心涉及"机制正当性"（正业）+ "努力方向"（正精进）+ "注意力质量"（正念）
  2. 构建调用链：正业 → 正精进 → 正念
  3. 执行调用：
    • 正业：四重检查——价值检查（去掉刺激还剩什么？）、代价检查（隐性成本：用户信任）、情绪检查（焦虑/损失厌恶）、退出权检查（用户能体面暂停吗？）
    • 正精进：归零思考——如果今天第一次设计这套机制，还会这样设计吗？
    • 正念：注意力校准——团队是否只盯着 DAU 曲线，忽略了用户情绪的渐进变化？

输出结果

=== 观照报告 ===

【问题重定义】
原问题："增长和用户体验怎么平衡"
修正后："团队设计了一套更难退出的关系，而非更有价值的产品。数据在变好，用户与产品的关系在变坏。"

【关键偏差】
1. 正业：机制主要激发的是焦虑和损失厌恶，不是价值感和成就感
2. 正精进：团队默认"DAU 上涨=方向正确"，未区分"坚持"和"延长偏差"
3. 正念：注意力全部被 DAU 曲线吸引，忽略了渐进累积的负面情绪

【行动建议】
1. 【正业-高优】弱化"连续天数"威胁，改为用户自定目标；增加"休息模式"
2. 【正业-中优】给提醒和签到机制保留体面退出权
3. 【正念-持续】建立"仪表盘之外"的用户情绪追踪，不只看曲线

常见编排陷阱

陷阱 1：强制走完全链

  • 不是每个问题都需要走完全部 8 个 Skill
  • 编排器应根据问题类型智能裁剪，局部问题只调用相关章节
  • 过度编排会让用户觉得流程太重，反而降低使用意愿

陷阱 2：跳过前提检查直接做方案

  • 团队最常见的错误是"方法还在就直接用"
  • 正见放在最前是有原因的——方向不正，速度就是风险
  • 编排器应确保至少做过一次前提检查或视角修正后再进入具体分析

陷阱 3：只关注单一维度

  • 一个"数据好看但感觉不对劲"的问题，可能同时涉及正业（机制正当性）、正命（商业模式偏差）、正念（注意力被数据吸引忽略关系）
  • 编排器应具备多维度识别能力，不遗漏关键修正维度

陷阱 4：编排器产出内容

  • 编排器本身不产出分析内容，只负责路由和聚合
  • 内容质量由各子 Skill 保证，编排器负责调用顺序和上下文传递
  • 如果编排器自己开始分析，就失去了模块化的优势

Skill 间上下文传递规则

上游 Skill传递给下游的上下文
前提检查失效前提清单、新情境假设
视角修正修正后的多视角描述、被挑战的默认假设
正见三层分析结果、修正后的问题陈述
正思维判断链拆解结果、薄弱环节标识
正语清洗后的清晰版本、语言问题标识
正业四重检查报告、机制正当性判断
正命收入影响地图、激励偏差识别
正精进归零分析结果、停止/继续/调整建议
正念注意力审计报告、判断模式识别

报告模板

=== 观照报告 ===

【问题背景】
{用户原始问题描述}

【调用链】
{按顺序列出的 Skill 调用}

【各维度发现】
{每个被调用 Skill 的核心发现，1-2 句}

【问题重定义】
原问题：{用户原始问题}
修正后：{基于观照分析的问题重定义}

【关键偏差】
1. {偏差1} — 来自 {Skill名}
2. {偏差2} — 来自 {Skill名}
3. {偏差3} — 来自 {Skill名}

【行动建议】
1. 【{Skill名}-{优先级}】{具体可执行的行动}
2. 【{Skill名}-{优先级}】{具体可执行的行动}
3. 【{Skill名}-{优先级}】{具体可执行的行动}

Keep looking

Skills are one crate of 328,083. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.