Idea Coach

核心用法

Idea Coach 是一款面向开发者和技术创作者的结构化创意管理工具。用户通过 /idea 命令快速捕获灵感、问题或挑战，系统会自动分配ID并记录元数据。支持多维度分类（类型、领域、能量消耗、紧迫度、重要性），并根据重要性自动设定评审周期——从关键创意的每日审视到搁置项目的季度回顾。

工具的核心工作流围绕"捕获→探索→开发→交付/完成"的状态流转设计，内置批判性评审机制：AI会在评审环节提出尖锐问题，建议放弃缺乏可行性的想法，避免创意囤积。GitHub集成是其差异化能力，支持关联现有仓库、一键创建新仓库、同步为GitHub Issue，实现从灵感火花到代码仓库的无缝衔接。

显著优点

1. 结构化抑制创意腐败：通过强制分类和定期评审，解决开发者常见的"收藏夹吃灰"问题
2. GitOps原生设计：与gh CLI深度集成，符合现代开发者的工具链习惯
3. 决策辅助而非单纯记录：AI主动建议放弃低价值想法，降低机会成本
4. 评审周期自动化：基于重要性×能量矩阵的智能提醒，减少认知负担
5. 数据便携性：本地JSON存储，无供应商锁定

潜在局限

• 依赖gh CLI认证，GitHub Enterprise用户可能需要额外配置
• 缺乏团队协作功能，纯个人生产力工具
• 评审质量取决于底层模型，对复杂商业判断可能过于简化
• 无内置同步机制，多设备使用需自行解决数据同步

适合人群

独立开发者、技术博主、开源项目维护者、以及任何面临"想法太多、时间太少"困境的技术创作者。特别适合习惯命令行工作流、已将GitHub作为核心工作平台的用户。

常规风险

• 数据丢失风险：本地JSON文件需自行备份
• GitHub权限风险：idea_ship等命令需要repo创建权限，误操作可能导致仓库污染
• AI决策依赖：自动建议放弃的想法可能误判潜在价值，需保持人工最终决策权
• 隐私考量：创意内容若同步至GitHub Issue将转为公开或半公开状态

核心功能

Idea Coach 是一款面向开发者与创意工作者的本地化管理工具，核心定位是「想法的批判性陪练」。用户通过 /idea 命令快速捕获灵感、问题或挑战，系统自动为其分配类型（💡 idea / 🔧 problem / 🎯 challenge），并支持按重要性（critical / important / nice-to-have）与精力投入（high / medium / low）多维标记。

该工具独创「评审周期」机制：重要性越高、精力投入越大的想法，评审频率越密集（从每日到每季度），倒逼用户定期审视灵感价值，避免囤积。所有想法状态遵循明确的流转链路：captured → exploring → developing → shipped/done，同时支持 parked（搁置）与 dropped（主动放弃）状态，鼓励用户及时止损。

GitHub 集成是核心亮点。通过本地已认证的 gh CLI 代理，用户可直接将想法转化为仓库（/idea_ship）或关联现有仓库（/idea_link），并同步为 GitHub Issue（/idea_sync），实现「灵感 → 代码 → 协作」的无缝衔接。

显著优点

1. 零依赖，轻量安全：纯 Python 标准库实现，无第三方包，无网络请求代码，所有 GitHub 操作均通过系统 gh CLI 代理，大幅降低攻击面。
2. 隐私优先：数据完全本地存储（~/.openclaw/idea-coach/ideas.json），无云端同步、无遥测，用户拥有绝对控制权。
3. 反囤积设计：通过强制评审周期与 dropped 状态，系统性地对抗「灵感通胀」，提升执行转化率。
4. CLI 原生体验：命令结构直观（/idea_list --due、/idea_stats），适合习惯终端工作流的开发者。

潜在局限

• 功能单一：专注个人灵感管理，不支持团队协作、多设备同步或复杂任务依赖。
• GitHub 生态绑定：深度依赖 gh CLI，非 GitHub 用户或需额外配置；GitLab、Gitee 等平台无原生支持。
• T3 来源风险：由个人开发者（moinsen-dev）维护，MIT 协议开源，长期维护与更新频率依赖社区。
• 无可视化界面：纯 CLI 交互，非技术用户或需适应成本。

适合人群

• 多项目并行的独立开发者，需系统化管理「副业灵感」。
• 追求「少即是多」的极简主义者，希望定期清理无效想法。
• GitHub 重度用户，期望将 Issue 与本地灵感库打通。

常规风险

• 数据丢失风险：本地 JSON 存储，无自动备份机制，用户需自行维护备份策略。
• gh CLI 环境依赖：若系统未安装或未认证 gh，GitHub 相关功能将完全失效。
• 子进程安全：虽当前实现有超时保护，但未来扩展若放松 subprocess 调用限制，需警惕命令注入。