kickoff

kickoff skill 概览

kickoff 能做什么

kickoff skill 可以把一个粗略想法，或收件箱里的随手记录，整理成一份用于 Project Management 的结构化 Project Note。它不是一次性生成一大段内容，而是采用两步流程：先做 planning pass，经过审阅后再进入 execution pass。相比泛泛的“帮我规划这个项目”提示词，kickoff 在需要更清晰交接、减少上下文漂移时更实用。

kickoff 最适合谁

这个 kickoff skill 很适合已经有想法笔记习惯的用户，尤其是会把内容先放进 00_Inbox/ 这类收件箱式文件夹的人。如果你想用一套可重复的方法，把零散想法提升为可执行的项目文档，它会很合适。对运营、创始人、独立开发者和产品搭建者来说，kickoff 特别适合作为一种轻量的项目启动仪式，而不必先上完整的 PM 工具。

为什么用户会选择 kickoff

kickoff 的核心差异在于 orchestration。它不只是帮你起草一次笔记，而是明确把 planning 和 execution 分开，并在两者之间要求确认。这道 review gate 在你很在意范围、命名、结构或语言时尤其有价值，因为你可以在最终 Project Note 生成前先把方向校准好。

安装 kickoff 前要知道什么

从仓库内容看，这个 skill 只有一个 SKILL.md，没有 helper scripts、rule packs 或 resource files。好处是 kickoff 很容易检查和理解；但相应地，输出质量会更依赖你的输入，也取决于你的运行环境是否支持这个 skill 所描述的 multi-agent flow。如果你要的是零审阅、一次出稿的生成器，那么 kickoff 可能会显得比实际需要更讲流程。

如何使用 kickoff skill

安装 kickoff 时先看什么

安装 kickoff 时，先从仓库添加这个 skill，然后优先阅读 EN/.agents/skills/kickoff/SKILL.md，因为完整流程、角色定义和语言规则都写在这个文件里。这个 skill 路径下没有额外的 README.md、metadata.json 或 helper 文件夹，所以它的几乎所有行为都由这一个文件定义。正式依赖它之前，先确认你的 agent 环境支持通过 task-style tool 调用 subagent。

kickoff 需要什么输入

kickoff usage 支持三种起点：

• 文件路径，例如 00_Inbox/MyIdea.md
• 内联文本，例如“Build a habit tracker app”
• 不提供输入；这种情况下，skill 会去列出 00_Inbox/，让你自己选择

高质量输入通常会包含：问题、目标用户、预期结果、约束条件，以及任何 deadline 或交付格式。
弱输入示例：“make this into a project.”
更强的输入示例：/kickoff Build a habit tracker app for iOS freelancers; MVP in 3 weeks; needs reminders, streaks, and CSV export; keep scope solo-developer friendly.

一套实用的 kickoff 工作流

一套稳定可复用的 kickoff guide 如下：

1. 用笔记路径或简短 brief 调用 /kickoff。
2. 让 planning agent 先产出一个 plan file。
3. 在批准前先审阅这个 plan。
4. 先修正范围、命名、假设和遗漏的约束，再确认继续。
5. 让 execution agent 仅根据这个 plan file 生成最终的 Project Note。

这里“只把 plan file 交给下一步”是 kickoff 最关键的设计选择。它能减少原始长对话里的信息被意外带入，但也意味着：plan 里漏掉的内容，最终输出里通常也会漏掉。所以 review 不是走形式，而是决定结果质量的关键环节。

能提升输出质量的提示词写法

如果你是把 kickoff 用在 Project Management 上，提示词最好具体到足以塑造一份项目说明，而不只是泛泛 brainstorm。比较有效的结构是：

• source：这个想法从哪里来
• objective：怎样才算成功
• scope：哪些是必须做，哪些可以后放
• constraints：时间、工具、预算、团队规模
• deliverable：你希望得到什么文档或项目产物

示例：
/kickoff 00_Inbox/ClientPortal.md

然后在 review 阶段补充修正，例如：

• “Use English for the project note.”
• “Scope MVP to authentication, dashboard, and billing history only.”
• “Target a 2-person team and a 6-week timeline.”

还要注意它的内置语言规则：kickoff 应该匹配用户输入或 inbox 文件内容所使用的语言。

kickoff skill 常见问题

kickoff 比普通 planning prompt 更好吗？

通常是更好的，前提是你需要一个经过审阅、分阶段推进的流程。普通 prompt 生成项目计划可能更快，但 kickoff 会在 planning 和最终 note 生成之间加入一个有意设置的检查点。如果范围或结构上的错误会在后续带来较高代价，这一步就非常值得。

kickoff 对新手友好吗？

友好，前提是你已经足够了解自己的想法，并能把它描述清楚。这个 kickoff skill 本身很容易检查，因为所有内容都在一个 SKILL.md 里。对新手来说，难点通常不在安装，而在于是否能给 planning agent 足够的上下文，让它产出一个扎实的 plan file。

什么情况下 kickoff 不适合？

如果你需要深度任务自动化、系统集成，或依赖脚本强制执行严格模板，那就不太适合用 kickoff。这个仓库没有 helper code、validation logic 或外部资源。另外，如果你根本不想要 review 步骤，只需要快速一轮生成一份笔记，kickoff 也不算理想选择。

kickoff 依赖 OrbitOS 的文件夹布局吗？

部分依赖。这个 skill 在未提供输入时会明确引用 00_Inbox/，因此它最适合放在采用类似约定的笔记系统中。你当然也可以用内联文本或直接文件路径来运行 kickoff，但它的默认发现流程确实假设这类 inbox 结构是存在的。

如何改进 kickoff skill

给 kickoff 提供更丰富的项目信息

想更快提升 kickoff 的结果，最有效的方法就是把决策上下文提前塞进输入里。建议至少包含：

• target user
• problem statement
• constraints
• timeline
• success criteria
• known dependencies

这样 planning agent 才更容易产出一个 execution agent 能稳定展开的 plan file。如果你的首条提示缺少这些信息，最后得到的 Project Note 往往就会比较泛。

把 plan review 当成交接文档来审

不要把 plan review 当成可有可无的步骤。因为 execution agent 只会读取 plan file，所以你要重点检查：是否有遗漏的假设、模糊的里程碑，以及不清晰的范围边界。一个很实用的判断标准是：如果一个人类同事拿到这份 plan 都无法继续执行，那么第二阶段大概率也做不好。

留意 kickoff 的常见失败模式

kickoff usage 的主要失败场景其实很可预测：

• 想法过于模糊
• inbox note 太嘈杂或缺乏结构
• 缺少约束条件
• 语言预期不明确
• 用户过快批准 plan

一个实用修正办法，是在 kickoff 之前先把杂乱笔记做一次标准化：补上标题、一句话目标、目标受众，以及一份简短的“must include”列表。

第一版输出后继续迭代

如果最终的 Project Note 已经接近可用，但还不能直接拿来用，改进 kickoff 的更好方式通常不是只去修最终文档，而是回头改 plan。你可以要求更窄的范围、更清晰的里程碑，或换一种项目结构，然后从 planning 阶段重新跑一遍。对这个 skill 来说，一个更好的中间结构，通常比一开始写得更长的提示词更重要。