核心用法
solo-pipeline 是一个工作流编排引擎，用于将多个独立技能串联成自动化管道。用户通过单一命令触发多阶段流程，系统自动处理阶段间的衔接与状态管理。
两种主要模式：
- Research Pipeline：
/pipeline research "idea"→ 自动执行/research→/validate，产出research.md→prd.md - Dev Pipeline：
/pipeline dev "name" "stack"→ 自动执行/scaffold→/setup→/plan→/build，产出完整可运行项目
关键特性：
- 状态持久化：通过
.solo/pipelines/solo-pipeline-{project}.local.md保存进度，支持断点续跑（重新运行命令自动跳过已完成阶段） - 可视化监控：tmux 三窗格仪表盘（工作区、日志 tail、实时状态），或手动
tail -f日志 - 安全熔断：默认 5-15 次迭代上限，防止无限循环
- 取消机制：删除状态文件即可中断管道
显著优点
1. 端到端自动化：从需求研究到可运行代码的一站式自动化，消除手动切换技能的上下文断裂
2. 容错与可恢复：状态文件设计允许任意时刻中断并在之后无缝续跑，适合长耗时任务
3. 透明可观测：结构化日志 + 实时仪表盘，阶段进度、耗时、文件产出一目了然
4. 灵活扩展：基于 Stop hook 的链式架构，理论上可扩展更多自定义管道组合
潜在局限
1. 外部依赖较重：tmux 仪表盘、Claude Code 插件（solo-factory）为可选增强，核心功能在纯环境可能体验降级
2. 状态管理黑盒：用户需理解状态文件机制才能正确取消或排障，学习成本存在
3. 迭代上限刚性：虽然防止死循环，但复杂项目可能在 15 次内无法完成，需手动调整
4. 单点故障风险：Stop hook 若未正确配置，需回退到手动逐个调用技能
适合人群
- 独立开发者/全栈工程师：需要快速将想法转化为可运行原型
- 产品经理/技术负责人：希望自动化需求验证与文档产出流程
- 自动化爱好者：追求 "一个命令走完全流程" 的极简工作流
常规风险
- 文件覆盖：管道可能覆写同名文件（如
prd.md），建议在版本控制下运行 - 资源消耗：长管道可能持续占用 Claude Code 会话，建议配合
--no-dashboard在后台运行 - 状态残留：异常中断可能遗留状态文件，导致下次运行行为异常，需手动清理
.solo/pipelines/目录 - 网络依赖：research 阶段依赖外部搜索，网络不稳定可能导致管道阻塞