用途：Solutionize 用于在动手写代码前，与人类伙伴共同确定正确方案。它面向一个具体 issue（例如“在 API 日志上加下拉筛选：全部/成功/失败”），关注取舍、用户体验、PR 大小与可评审性以及运维现实。
主要能力与规则：调用该技能后必须立即切换到 Cursor Plan 模式（若代理无法切换则请用户切换），执行期间不得停留在 Agent 模式。从调用起直到第 4 步 sketch 技能结束，严格禁止实现：不得修改应用代码、测试、配置或资源，不得提交，不得因问题看起来小而擅自实现，即使伙伴把 issue 表述为直接构建请求也不行。实现应放在该工作流之后的单独后续中进行。
工作流：按顺序执行 spike、approach、interview、sketch 四步，各步的实质内容与章节形态定义在同目录的 skills/<name>/SKILL.md。spike 就绪后调用 CreatePlan，参数 name 为简短可读的 issue 标题，overview 与 name 相同，plan 为 ## 1 - Spike 加 synopsis 正文；随后停止，等待伙伴在聊天中明确确认继续。确认后执行 approach，把 ## 2 - Approach 追加到同一份 brainstorming .plan.md，再次等待确认。然后执行 interview，追加 ## 3 - Interview，再次等待确认。最后 sketch 调用 CreatePlan 新建一份 .plan.md（不要编辑 brainstorming 计划），name 为同一标题加 Sketch: 前缀，plan 为 ## Sketch 加该技能的分阶段输出，todos 按 ### Phase N - … 每行一条、顺序一致。CreatePlan 会把 *.plan.md 写到 ~/.cursor/plans/。
风格与限制：计划中不加元评论，不叙述技能步骤编号，不解释文件/行数估算含义；直接陈述事实、选项与数字。用 you 和 we 直接称呼伙伴。引用格式不要混用 ** 与反引号，例如写 reference.ex，不要写 reference.ex。粗略数值用数字范围（如 3-4 个文件、80-140 行），不用波浪号。段落要短、多空行，单段不超过 3 句。写完某一步后不要在聊天中复述；聊天只用于继续确认等明确交接，所有问题写进计划文件。背景设定为 Surge 这家做电话 API（短信与语音）的小创业公司，强调简洁清晰，其次可靠与长久，聚焦实际边界情况与关键错误，偏好显而易见、可读的方案。资料未提供该技能的安装命令、收费或平台支持信息。