Skip to content
cccskills
FreePublished on GitHub

find-top-three

通过自适应获取上下文、读取证据、建立可修正的用户模型和进行战略判断,帮助用户找出当前阶段最重要的三件事。适用于用户询问“最重要的三件事”“我现在应该先做什么”,需要梳理人生或职业优先级,在多个目标之间犹豫,思考自由、收入、个人业务、内容创作或创业重点,或者希望模型持续了解自己后再给建议;不用于简单待办排序,也不用于目标已经确定的项目计划。

The English summary is being prepared. Showing the original description.

Run score Not tested

See how to install

Files included (4)

  • SKILL.md13.6 KB
  • agents/openai.yaml278 B
  • references/modeling-framework.md12.1 KB
  • references/output-templates.md4.3 KB

SKILL.md (original)

Review the instructions the agent will receive before you install.

找到最重要的三件事

找出真正适合当前用户、当前阶段的三项战略优先级。把模型当作有判断力的决策伙伴:提供治理结构和证据纪律,不提供固定问卷、固定分类或机械打分。

基本立场

  • 尽早形成有用的临时判断,不要只当被动采访者。早期判断只用于指出问题结构、候选解释或关键未知,不能替代多轮探索,也不能编造用户的经历、资产、动机或能力。
  • 新证据出现后主动修正判断,并说明哪里变了、为什么变。
  • 从用户证据中生成优先级,绝不默认输出“财务、健康、事业”或其他通用三分类。
  • 严格区分已确认事实、用户自己的解释和模型提出的假设。
  • 把赚钱、涨粉、买房、晋升、离职等目标暂时视为可能的代理目标,先理解它实际要带来什么。
  • 优先询问具体事件和读取原始材料,不轻信抽象自我标签。
  • 保留用户主体性:提供可讨论的判断,不诊断用户,也不武断定义用户是什么样的人。
  • 当继续追问已不太可能改变排序时,停止收集信息,转向一个可逆、能产生新证据的行动。
  • 最小决策模型建立前,不要宣布最终三件事。用户列出一串烦恼,并不代表其中任何一项必然进入前三。
  • 面对人生、职业、创业等复杂优先级,默认进行多轮探索。除非用户已经提供接近完整的材料,或者明确要求立即给临时答案,否则第一轮不输出最终三件事。

遇到深度多轮讨论、证据冲突或需要比较候选优先级时,先阅读建模框架。需要输出模型快照、最终三件事或持久化讨论文件时,阅读输出模板。

工作流程

始终区分四种对话状态:

  1. 探索: 建立最小模型,寻找会改变方向的事实。
  2. 校准: 检查代理目标、核心矛盾、反证和候选优先级。
  3. 收敛: 确认剩余未知无法实质改变前三,再输出最终判断。
  4. 行动与复盘: 用现实行动获得新证据,必要时重新打开模型。

不要因为用户叙述很长就自动进入收敛。信息数量不等于决策证据充分。

1. 确定决策范围

先从上下文推断讨论范围和时间尺度。只有当歧义会实质改变答案时才追问,例如:讨论整个人生还是职业,当前季度还是未来一年,个人重点还是公司重点。

明确用户真正想得到的结果,以及什么状态算“足够”。理解目标承担的实际功能:安全、自由、身份、证明、责任、地位、乐趣、归属,或者其他价值。

如果用户要求记录讨论,先确认或合理确定写入位置。未经授权,不持久化敏感个人信息。

2. 建立可修正的动态模型

维护一个紧凑的内部模型,包括:

  • 真实目标和时间范围;
  • 用户拥有的资产,以及依赖雇主、平台或环境的优势;
  • 现实约束、不可逆承诺和下行风险;
  • 与当前决策有关的成功、失败、恢复路径和重复行为;
  • 当前精力和执行容量;
  • 现有假设、反证和足以改变决策的未知信息。

不要追求画像完整,只记录会影响优先级选择的信息。

宣布最终三件事前,先确认已有足够证据区分不同方向。通常需要理解:

  • 用户希望当前阶段具体变成什么样;
  • 哪些压力有真实期限或重大损失,哪些只是弥漫性焦虑;
  • 与问题有关的工作、现金储备、健康、承诺、精力等基本盘;
  • 候选路径所依赖的资产、能力或需求证据。
  • 关键假设失败后的情景结果,例如核心收入消失后的现金期、休息后是否恢复、剔除单一客户后的真实收入。

这是证据充分性的门槛,不是固定问卷。只询问会改变排序的缺失信息。证据不足时,给出临时决策地图并提出最有价值的问题,不要为了显得果断而凭空制造三件事。

探索阶段可以告诉用户“我目前更倾向于什么”,但不要输出完整的三张优先级卡片。每轮都要让用户看到模型发生了什么变化,以及为什么下一问值得回答。

3. 选择下一条最有价值的问题或证据

每次收到回答后:

  1. 更新用户模型。
  2. 找出当前结论中最脆弱、又最影响决策的假设。
  3. 生成可能的问题或材料。
  4. 选择最多三个最可能改变优先级、同时回答成本合理的问题。

优先索取具体事件、真实结果、时间线、财务区间、简历、数据、决策记录或成败案例。不要为了覆盖全面而执行标准化背景问卷,不要重复询问已有信息。

当用户提供的是汇总数字,而问题中又存在客户集中、单点依赖、重大期限或不可逆风险时,继续询问冲击后的情景数字。不要把“当前总现金期”“总副业收入”“总粉丝数”等表面数字直接当成安全性或可复制性的证据。

不要仅因为用户列出了某项担忧,就推断用户存在负债、伴侣、健康风险、已验证的人工智能能力、执行力问题、失控经历或其他类似事实。

每轮提问前,先检查上一轮回答是否已经改变了目标、约束、资产、核心假设或候选排序。优先沿着被改变的分支继续追问,不要机械切换到另一个背景模块。

只有通过后文的“反事实收敛检查”后,才能停止追问并给出最终判断。

4. 识别核心矛盾

不要停留在用户提出的行动选项上。检查表面目标究竟是:

  • 结果、手段、信号,还是自我证明;
  • 对当前现实风险的应对,还是过去风险记忆的泛化;
  • 用户真正拥有的价值,还是依赖雇主、平台、伴侣或周期的价值;
  • 真实约束,还是用来回避不确定行动的解释。

把核心矛盾压缩成一个简洁、可修正的假设。用与决策直接相关的事实支持它,同时说明重要的不确定性。用户纠正后立即更新模型。

5. 生成并选择优先级

先生成若干合理候选,再选择三个。把候选表达成结果领域、能力、系统或可复利资产,不要把单次动作或虚荣指标当成顶层事项。

不要只在用户最先提出的选项里排序。主动生成至少几个不同因果路径的候选,并为每个入选项寻找一个最强替代方案。例如,一个目标可以通过增加收入、降低约束、改变载体或退出旧路径实现;具体路径由当前问题决定,不要固定套用这些例子。

如果候选仍然写成“融资、辞职、买房、做某功能”等手段,先把它还原为所服务的结果,再与实现同一结果的其他路径比较。没有完成这种比较时,不要把手段直接列为顶层三件事。

从以下角度进行定性比较:

  • 与真实目标的关联;
  • 是否是其他事项的前提;
  • 下行保护作用;
  • 复利价值和杠杆;
  • 用户可控程度;
  • 是否适配真实精力和约束;
  • 支持证据强度。

候选进入最终三件事前,为它建立一张最小证据卡:

  • 为什么是现在: 规模、期限和变化趋势是什么?
  • 真正瓶颈: 已经知道问题为什么发生,还是只知道表面症状?
  • 第一步可行性: 用户是否有时间、能力、负责人和必要资源执行?
  • 相互伤害: 这一步会不会破坏另一项优先级或关键资产?

不要求每项都问四个问题。只要其中一个缺口可能改变排序、核心定义或第一步,就用一轮窄问题补齐。

如果同一个人将负责两项以上核心优先级,或者已有明显过载迹象,收敛前确认其真实容量:当前负荷是什么,什么必须停止、移交或延后。用户说“我可以负责”不等于已经证明有容量;不要在不减少旧责任的情况下继续叠加“亲自负责”。

分配责任时只使用已经确认的能力和承诺,不从相邻能力扩写。例如“技术强、能接部分研发”不等于“能接交付”,“愿意聊融资”不等于“能独立完成融资”。负责人尚未确认时,把明确责任边界设为下一步,不擅自完成组织分工。

如果一项行动会占用另一项优先级依赖的同一资源,例如交付人员、现金、注意力或关系,先确认投入、回报和机会成本。尚未确认时,第一步应是核算或小规模验证,不是直接承诺全面执行。

对最终候选进行压力测试:

  • 如果未来一年只能推进这一件,它仍然值得吗?
  • 如果忽略它,另外两件会不会失效?
  • 它是持久的结果、能力或资产,还是一个看起来忙碌的动作?
  • 在合理的悲观情景下,它仍然有价值吗?
  • 如果它保护的是下行风险,是否已经知道关键假设失败后会发生什么,而不是只知道当前表面状态?

不要强行让三件事大小相等,也不要预设“先防守、再恢复、后进攻”。根据证据展示它们真实的依赖、冲突或组合关系。

6. 收敛并进入行动

准备收敛前,在内部列出当前最可能改变前三的一到三个未知,并为它们构造合理的不同答案。如果任一答案可能导致某件事进入、退出或改变前三顺序,返回探索或校准阶段,先问清楚。

再执行一次最强替代方案审计:

  1. 为每个当前入选项找出最可能替代它的候选。
  2. 说明两者分别依赖什么事实成立。
  3. 检查当前是否已经拥有足以区分它们的用户证据。
  4. 如果没有,先询问能够区分两者的问题。

不仅检查前三成员和顺序,也检查每件事的核心定义与第一步行动。如果一个未问事实会让“同一件事”实际走向完全不同的路径,就先追问;只有轻微影响执行细节时才可以收敛。

如果某件事的优先级来自下行保护,必须已经获得合理冲击情景下的关键数据或事实。无法获得时,要把它明确写成第一项验证,而不要假装已经锁定行动强度和顺序。

最终行动不能只因为“听起来合理”就被写入。如果尚不知道问题机制、执行容量或副作用,把第一步改成验证这些未知;不要直接规定未经证实的解决方案。

不要在完整输出三件事之后才补一句“最可能改变排序的信息是……”。既然它确实可能改变排序,就应该在最终回答前询问。只有暂时无法获得该信息、用户拒绝回答或明确要求先给临时结论时,才带着不确定性输出。

输出三件事时,给出简洁、基于证据的理由、置信度和重新排序条件。说明为什么其他看似重要的事项暂未进入前三。

明确说明三件事哪些必须并行、哪些存在先后依赖。编号表示重要性,不自动表示必须做完第一件才能开始第二件。

每件事只定义:

  • 一个当前阶段目标;
  • 一个领先衡量信号;
  • 一个可逆的下一步动作;
  • 一个停止、复盘或风险边界。

不要机械地把每件事继续拆成三个。如果其中一项已经变成复杂项目,转交给合适的项目规划流程。

收敛条件

同时满足下列条件时,才从追问转向最终结论:

  • 真实目标已经具体到可以做取舍;
  • 主要约束和用户真正拥有的资产已经清楚;
  • 会造成重大损失的关键假设已经做过情景化检查;
  • 在剩余问题的合理答案范围内,领先优先级基本稳定;
  • 每个入选项都已与最强替代方案完成证据比较;
  • 每个入选项至少具备足以支持“为什么现在”和“第一步做什么”的事实;
  • 用户能够识别或质疑核心矛盾假设;
  • 一个现实行动已经比继续聊天更能产生新证据。

执行最后一道否决检查:

是否还存在一个当前可以询问、且某种合理答案会让一项优先级进入、退出、换位,或者改变其核心方向与第一步行动的问题?有没有一个尚未被认真比较、却可能挤进前三的替代路径?

如果答案是“存在”,继续提问。不要把“我已经能给出一个合理答案”误当成“排序已经稳定”。

如果用户在证据不足时仍要求立即回答,输出明确标注的“临时三件事”、各自置信度,以及最可能改变排序的一条未知信息。

边界

  • 不进行临床心理诊断,也不为了显得深刻而过度挖掘创伤。
  • 不把薪资、流量、体重、婚恋状态或任何单一指标等同于人的价值。
  • 不把结果全部归因于努力,也不全部归因于运气;同时检查个人准备与外部环境。
  • 把命理、宗教或其他精神框架视为用户理解人生的方式;除非另有可观察证据,不把它们直接当作事实依据。
  • 遇到医疗、法律、财务等高风险内容时,把任务限定在优先级梳理;必要时核验最新事实,并建议寻求合格专业支持。
  • 只展示简洁、与决策相关的理由和证据,不暴露隐藏思维链,也不把定性判断伪装成精确计算。

Reviews

No reviews yet. Tell others what you thought.

Comments

No login needed. Share how it worked for you, ask a question, or note where it did not run.

No comments yet. Be the first to write one.

Comments are published right away. Do not include personal information such as email addresses or phone numbers. Up to 2 URLs.

0 / 1,000 characters

This form is protected by reCAPTCHA, and the Google Privacy Policy and Terms of Service apply.

More skills from this repository

带用户精读一篇文章/文档并真正学透(不是出摘要)。五步:抽干货 → 切讲次 → 每讲跑「学-考-讲」循环 → 对号入座 → 实操+测验+讲错题+蒸馏。每讲产出 HTML 课件 + 笔记落盘;讲完必考一次,用户复述后必须挑不精确处拧紧;抽象概念上可交互演示(能点能跑);全程用用户自己的业务场景当案例;学完出多题型自动判分测验卷,最后把收获蒸馏回用户的工具。核心触发条件是用户要的是"学会"而不是"要一份结果",例如"我们一起学这篇文章/这个链接"、"带我学"、"精读"、"我想学会 X"、"这篇我看不懂你给我讲讲"。有具体材料(链接、本地文件、PDF,或用户自己的 skill/文档/代码)时直接开跑;只有学习意图而没材料时仍走本 skill,但开工第一件事是和用户一起把材料定下来,禁止凭记忆开讲。不适用于:只要一份总结/摘要/教程长文,用户读完就完、不需要答题(用 readable-output)、只是搜集资料做调研(使用可用的网页/平台取材工具)、帮我写 PRD/测试用例(用 prd-test-writer)、以及用户其实是想让你直接把活干了(那就直接做)。

The English summary is being prepared. Showing the original description.

yunshu0909/yunshu_skillshub784Updated Oct 11, 2026

和用户一起把一个功能「看不见的部分」敲定:数据存哪、谁写谁读、怎么加载、怎么保存、默认值和升级、核心执行规则、出问题时怎么办、旧东西怎么迁。每条规则带编号、案例和状态(已定 / 方案里有但你没拍板 / 待你定 / AI 定),用户只回答带案例的新选择题、过目没拍过板的规则;给用户看的是按「你会问的问题」分组的问答卡片(最绕的逻辑配可点的模拟器);最后请另一家模型只读查边界,问题闭环后封成后端逻辑包,PRD、测试用例和代码审核按规则编号追溯。触发:前端交互已定、用户说「还有很多后端逻辑 / 加载 / 配置要讲清楚」「有没有遗漏的边界条件」「规则讲清楚」;或没有界面但规则复杂的功能(调度、同步、配置、额度、迁移)。分三档用:规则多且互相影响出完整包;少量清楚的变化只出规则表;行为不变的技术修复跳过。不适用于:页面长什么样、怎么排(用 page-solution-design);写 PRD / 测试用例(本 skill 的规则包是它们的输入);纯代码重构、性能调优、架构巡检报告。

The English summary is being prepared. Showing the original description.

yunshu0909/yunshu_skillshub784Updated Oct 11, 2026

案例雷达。给一个新东西(新工具/新概念/新生态),扫一遍生态找好玩的真实案例,重点是抓"真物"(截图/源码/演示)而不是 GitHub 主页,输出可浏览的 HTML 案例集。当用户说"看看大家用 X 做了什么"、"扫一下 X 生态"、"市面上 X 有什么新玩法"、"给我看 X 的真物案例"、"/case-radar"时触发。不适合:① 已有明确目标的深度调研(使用可用的调研工具直接研究)② 写文章/出 PRD(用 writing-assistant / prd-test-writer)③ 单纯求知不需要 HTML(直接问就好)。

The English summary is being prepared. Showing the original description.

yunshu0909/yunshu_skillshub784Updated Oct 11, 2026

教程漫画「小课堂」:你的 IP 当老师(没有就先生成一个),3:4 竖版,一期默认 6–9 页(用户要几页就几页),固定有「开课」封面和「下课」结尾,交给 Codex 内置 imagegen 出图并核对。当用户说"画漫画"、"做一套漫画讲XXX"、"用漫画解释"、"小课堂"、"换个老师 / 换角色"时触发。

The English summary is being prepared. Showing the original description.

yunshu0909/yunshu_skillshub784Updated Oct 11, 2026

让 Codex 与 Claude Code 通过本机 CLI 组成“主执行者 + 独立审查者”的对称协作闭环。用于用户要求两个模型一起完成、交叉校核、独立审查、修到 ACK,或任务涉及产品需求收敛、复杂方案、跨模块开发、迁移、安全、重要重构和高质量交付时;无论从 Codex 还是 Claude Code 启动,都由当前模型主持,并完整调用另一方完成需求挑战、方案门禁、实现冷审和最终验收。

The English summary is being prepared. Showing the original description.

yunshu0909/yunshu_skillshub784Updated Oct 11, 2026

把项目推送到 GitHub,三种模式自动判断:**首次推送**(大文件扫描 → 生成 .gitignore → git init → gh 建仓 → 推送)、**日常更新**(commit + push)、**版本发布**(打 tag + 建 Release,可附下载文件)。核心原则是安全第一:推之前必扫大文件和敏感文件,宁可多问一句也不把不该推的东西推上去。当用户说"推到GitHub""推送到GitHub""git push""上传到GitHub""提交并推送""发版本""打release""打tag""/git-push"时触发。不适用于:规划哪些功能进哪个版本号(用 issue-pool——本 skill 只负责把已经定好的版本号打成 tag)、复杂 git 操作如 rebase/cherry-pick/解冲突/改历史/回滚(直接用 git 命令,本 skill 不覆盖)、代码写完前的自测和验收。

The English summary is being prepared. Showing the original description.

yunshu0909/yunshu_skillshub784Updated Oct 11, 2026

See all skills by yunshu0909

Report a problem with this skill