Framing problems before building
Skill jackleeson-beep/skill/.cursor/skills/framing-problems-before-building
Cursor skills and harness-oriented workflows for project intake, problem framing, and AI-ready task decomposition.
npx -y skills add jackleeson-beep/skill --skill framing-problems-before-buildingAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 2 stars2 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
在用户问题还没想清楚、需求模糊、直接想让 Cursor 或 agent 开始实现时，先用固定流程澄清目标、现状、约束、成功标准与未知项，并判断当前处于想法、问题、方案还是实现阶段。适用于用户讨论 agent 工作流、harness、skill、约束、方法论、需求拆解或方案收敛时，帮助决定下一步是继续澄清、写计划、设计 harness，还是沉淀为 Cursor Skill。
SKILL.md
7.6 KB, as published. Nobody here has run it
先定义问题，再开始构建
这个 skill 用来处理一种高频情况：用户拿到 Cursor 后直接开始“乱问”，但其实问题本身还没有定义清楚。
目标不是立刻给实现，而是先把问题收敛成一个能被可靠执行的任务。
与 Harness / Skill 的分工
- Harness：负责强制流程、阶段切换、状态保存、校验、重试、阻止越级执行。
- Skill：负责提供分析方法、提问框架、输出模板和判断标准。
- 本 skill：专注于“先定义问题，再决定是否进入方案或实现”这一步。
如果某个团队总会反复遇到“问题没定义清楚就开做”的情况，说明可以考虑把本 skill 的流程进一步下沉到 harness，做成强制入口。
核心原则
- 先判断阶段，再决定动作。不要在“问题阶段”直接跳到“实现阶段”。
- 先收敛问题，再讨论方案。如果目标都不清楚，不要产出代码方案。
- 明确未知项。不替用户偷偷补全关键前提。
- 约束先于实现。先写清不能做什么、必须满足什么。
- 成功标准必须可检验。避免“做得更好”“更智能”这类空目标。
四阶段模型
先判断用户当前处于哪一阶段：
- 想法阶段
- 只有方向、感受、抱怨或灵感
- 还说不清具体问题是什么
- 问题阶段
- 已经知道“哪里不对”，但还没收敛成明确任务
- 常见表现是目标、约束、成功标准不完整
- 方案阶段
- 已经能比较方案、讨论架构、拆步骤
- 可以开始写计划，但还不一定该写代码
- 实现阶段
- 任务边界明确
- 可以编码、验证、评审、交付
如果判断为 想法阶段 或 问题阶段，默认不要直接进入实现建议。
固定流程（必走）
按下面顺序执行，不要跳步。
第 1 步：用一句话重述用户真正想解决的问题
输出一个工作定义：
- 用户表面上在问什么
- 用户真正卡住的是什么
- 为什么这个问题值得解决
如果一句话都说不顺，说明问题还没定义好。
第 2 步：判断当前阶段
从四阶段模型中选一个，并给出一句理由：
- 为什么还只是想法
- 为什么已经进入问题
- 为什么已经足以讨论方案
- 为什么可以直接实现
第 3 步：抽取五个关键字段
必须逐项填写；缺失就明确标记“未知”。
- 目标
- 最终想达成什么
- 现状
- 现在发生了什么，已有条件是什么
- 约束
- 时间、技术、流程、资源、质量、安全、团队边界
- 成功标准
- 什么结果算完成，最好可验证
- 未知项
- 当前还不确定、需要确认、不能假设的部分
第 4 步：识别用户是否在混淆三类内容
检查用户有没有把下面三类东西混在一起：
- 问题定义
- 解决方案
- 实现细节
如果混淆了，要拆开说清：
- 现在已经明确的是哪一层
- 还没明确的是哪一层
- 不应该提前进入的是哪一层
第 5 步：判断约束应该放在哪一层
把已有约束分到下面三类：
- 放在 harness
- 必须被强制执行
- 依赖运行时状态
- 涉及校验、重试、分支、权限、阶段门禁
- 放在 skill
- 属于可复用的方法论
- 是提问框架、判断规则、输出模板、检查清单
- 只保留为当前上下文
- 一次性背景
- 变化快
- 尚未稳定，不值得沉淀
第 6 步：决定下一步，不提前跳级
只能从下面四类里选一个主建议：
- 继续澄清问题
- 进入方案设计
- 进入实现
- 沉淀为可复用 skill / harness
如果主要问题还没定义清楚，不要建议“直接开始做”。
输出格式
默认用这个结构：
## 当前判断
- 当前阶段：[想法阶段 / 问题阶段 / 方案阶段 / 实现阶段]
- 一句话定义：[用一句话重述真正的问题]
## 五字段收敛
- 目标：[一句话]
- 现状：[一句话或两句话]
- 约束：[要点列表]
- 成功标准：[可验证结果]
- 未知项：[仍需确认的内容]
## 分层建议
- 放到 harness：[内容]
- 放到 skill：[内容]
- 仅保留在当前上下文：[内容]
## 下一步
- 建议动作：[继续澄清问题 / 进入方案设计 / 进入实现 / 沉淀为 skill 或 harness]
- 理由：[为什么]
追问规则
当信息不足时，优先追问最关键的缺口，不要一次抛太多开放问题。
优先级顺序：
- 先问目标
- 再问成功标准
- 再问约束
- 最后问实现偏好
避免这类低质量推进：
- “我先给你写个方案吧”
- “我大概理解了”
- “可以先做一个 MVP”
除非目标、边界和成功标准已经足够明确。
什么时候建议做成 Harness
当出现以下情况时，明确建议考虑 harness：
- 每次都要走同一套阶段门禁
- 不能允许 agent 直接跳到实现
- 需要强制校验输入完整性
- 需要状态跟踪、重试或审批
- 团队希望把流程标准化，而不是靠临场发挥
什么时候建议只做成 Skill
当出现以下情况时，优先建议 skill：
- 主要缺的是思考方法，而不是执行控制
- 用户问题高度模糊，需要稳定的收敛框架
- 输出格式和分析步骤可以复用
- 不依赖复杂状态机或外部系统
例子
输入
“我在想 harness 和 skill 能不能结合起来。很多工程师拿到 Cursor 就一顿乱问，最后自己要解决什么问题也不清楚。我想把这件事变得更可控。”
输出
## 当前判断
- 当前阶段：问题阶段
- 一句话定义：用户想解决的是“工程师在使用 Cursor 时，经常在问题尚未定义清楚时就进入执行，导致 agent 输出发散和低效”。
## 五字段收敛
- 目标：让 agent 在进入方案或实现前，先把问题定义收敛清楚。
- 现状：用户已经观察到高频混乱场景，但还没有固定的收敛流程。
- 约束：
- 需要适配 Cursor 使用场景
- 不能让流程过于重
- 最好能沉淀成可复用资产
- 成功标准：用户能先得到结构化问题定义，再决定是否进入方案、实现或沉淀为 skill / harness。
- 未知项：
- 这个流程是否只给个人用，还是给团队统一用
- 是否需要系统级强制门禁
## 分层建议
- 放到 harness：
- 禁止在信息缺失时直接进入实现
- 记录阶段状态
- 对输入完整性做校验
- 放到 skill：
- 四阶段模型
- 五字段收敛法
- 输出模板
- 仅保留在当前上下文：
- 当前团队的具体使用习惯
## 下一步
- 建议动作：沉淀为 skill，并视复用频率再升级为 harness
- 理由：当前最缺的是稳定的问题收敛方法，先用 skill 验证最小流程更合适。
自检清单
- 有没有先判断阶段，而不是直接给方案
- 有没有写出一句话问题定义
- 五字段是否完整
- 未知项是否被显式写出
- 是否区分了 harness、skill、上下文三层
- 下一步建议是否没有越级