Dev Workflow - Ouroboros + Superpowers 통합
트리거별 시작점
| 트리거 | 시작 | 끝 | 용도 |
|---|
| "우로보로스", "ouroboros" | Phase 1 | Phase 2 | 스펙만 정리 |
| "슈퍼파워", "superpowers" |
Phase 3 | Phase 5 | 계획+실행 (스펙 있을 때) |
| "스펙부터", "풀플로우", "전체" | Phase 1 | Phase 5 | 처음부터 끝까지 |
전체 플로우
CODEBLOCK0
Phase 1: 소크라테스 인터뷰 (Ouroboros)
목표: 숨겨진 가정을 노출하고 모호성을 제거
규칙
- - 한 번에 질문 하나만
- "~하면 되죠?"가 아닌 "~는 무엇인가요?" (존재론적 질문)
- 객관식 선호, 필요시 주관식
- 최소 3-5개 질문으로 핵심 파악
질문 프레임워크
- 1. 본질 (Essence): "이것의 본질은 무엇인가요?"
- 근본 원인 (Root Cause): "이게 근본 원인인가요, 증상인가요?"
- 전제 조건 (Prerequisites): "이를 위해 먼저 존재해야 하는 것은?"
- 숨겨진 가정 (Hidden Assumptions): "우리가 당연시하는 가정은?"
모호성 점수 (Ambiguity Score)
인터뷰가 끝나면 내부적으로 평가:
- - 목표 명확성 (Goal): 40%
- 제약 조건 명확성 (Constraints): 30%
- 성공 기준 명확성 (Success Criteria): 30%
Ambiguity ≤ 0.2 일 때만 다음 단계로 진행.
(80% 이상 명확해야 스펙 작성 가능)
Phase 2: 스펙 결정화 (Seed)
인터뷰 결과를 불변 스펙으로 결정화:
CODEBLOCK1
저장 위치: docs/specs/YYYY-MM-DD-<topic>.md
Phase 3: 구현 계획 (Plan)
스펙을 바이트 사이즈 태스크로 분해:
태스크 원칙
- - 각 태스크는 2-5분 분량
- TDD: 테스트 작성 → 실패 확인 → 구현 → 통과 확인 → 커밋
- 정확한 파일 경로와 코드 포함
- DRY, YAGNI 준수
계획 구조
CODEBLOCK2
저장 위치: docs/plans/YYYY-MM-DD-<topic>.md
Phase 4: 실행 (Execute)
두 가지 모드 제공:
A. 서브에이전트 모드 (권장)
태스크당 새 서브에이전트 파견:
- 1. 구현 서브에이전트 → 태스크 실행
- 스펙 리뷰 서브에이전트 → 스펙 준수 확인
- 코드 품질 리뷰 서브에이전트 → 품질 확인
- 다음 태스크로
B. 인라인 모드
현재 세션에서 직접 실행:
- - 3-5개 태스크마다 체크포인트
- 사용자 확인 후 진행
Phase 5: 검증 (Evaluate)
3단계 검증:
- 1. 기계적 검증: 테스트 통과, 린트 통과, 빌드 성공
- 의미론적 검증: 스펙의 성공 기준 충족 여부
- 합의 검증: 사용자 확인
빠른 시작
사용자가 개발 요청을 하면:
CODEBLOCK3
단축 모드
간단한 작업은 풀 프로세스가 과할 수 있음.
단축 조건:
- - 단일 파일 수정
- 명확한 요구사항 (모호성 낮음)
- 사용자가 "빨리" 또는 "간단히" 요청
단축 시:
- - 질문 1-2개로 축소
- 스펙 없이 바로 계획
- 계획도 간소화 가능
참고 자료
원본 저장소:
- -
ouroboros-ref/ - Ouroboros 원본 - INLINECODE3 - Superpowers 원본
에이전트 역할 (Ouroboros)
- - Socratic Interviewer: 질문만 함, 구현 약속 금지
- Ontologist: 본질/근본원인/전제조건/가정 분석
- Seed Architect: 대화를 스펙으로 결정화
- Evaluator: 3단계 검증
스킬 (Superpowers)
- - brainstorming: 디자인 도출
- writing-plans: 바이트 사이즈 계획
- subagent-driven-development: 서브에이전트 실행
- test-driven-development: RED-GREEN-REFACTOR
- systematic-debugging: 체계적 디버깅
开发工作流 - Ouroboros + Superpowers 集成
触发器对应的起始点
| 触发器 | 起始 | 结束 | 用途 |
|---|
| 우로보로스, ouroboros | 阶段 1 | 阶段 2 | 仅整理规格 |
| 슈퍼파워, superpowers |
阶段 3 | 阶段 5 | 计划+执行（已有规格时） |
| 스펙부터, 풀플로우, 전체 | 阶段 1 | 阶段 5 | 从头到尾 |
完整流程
[阶段 1-2: Ouroboros] [阶段 3-5: Superpowers]
提问 → 规格 计划 → 执行 → 验证
阶段 1: 苏格拉底式访谈 (Ouroboros)
目标: 暴露隐藏假设，消除模糊性
规则
- - 一次只提一个问题
- 不使用是不是这样？，而是问这是什么？（本体论问题）
- 优先选择题，必要时使用开放题
- 至少 3-5 个问题以把握核心
问题框架
- 1. 本质 (Essence): 这个东西的本质是什么？
- 根本原因 (Root Cause): 这是根本原因，还是症状？
- 前提条件 (Prerequisites): 为此，必须先存在什么？
- 隐藏假设 (Hidden Assumptions): 我们视为理所当然的假设是什么？
模糊性评分 (Ambiguity Score)
访谈结束后，内部评估：
- - 目标清晰度 (Goal): 40%
- 约束条件清晰度 (Constraints): 30%
- 成功标准清晰度 (Success Criteria): 30%
仅当 Ambiguity ≤ 0.2 时，才进入下一阶段。
（清晰度达到 80% 以上，才能编写规格）
阶段 2: 规格固化 (Seed)
将访谈结果固化为不可变规格：
markdown
[功能名] 规格
目标
[用一句话定义]
范围
包含
排除 (YAGNI)
核心组件
- 1. [组件]: [职责]
- ...
数据流
[输入] → [处理] → [输出]
成功标准
约束条件
未决问题（如有）
保存位置: docs/specs/YYYY-MM-DD-.md
阶段 3: 实现计划 (Plan)
将规格分解为字节级任务：
任务原则
- - 每个任务 2-5 分钟工作量
- TDD: 编写测试 → 确认失败 → 实现 → 确认通过 → 提交
- 包含准确的文件路径和代码
- 遵循 DRY、YAGNI
计划结构
markdown
[功能名] 实现计划
目标: [一句话]
架构: [2-3 句话]
任务 1: [组件名]
文件:
- - 创建: path/to/file.ts
- 测试: tests/path/to/test.ts
- - [ ] 步骤 1: 编写会失败的测试
- [ ] 步骤 2: 运行测试，确认失败
- [ ] 步骤 3: 最小化实现
- [ ] 步骤 4: 确认测试通过
- [ ] 步骤 5: 提交
保存位置: docs/plans/YYYY-MM-DD-.md
阶段 4: 执行 (Execute)
提供两种模式：
A. 子代理模式（推荐）
每个任务派遣新的子代理：
- 1. 实现子代理 → 执行任务
- 规格审查子代理 → 确认符合规格
- 代码质量审查子代理 → 确认质量
- 进入下一个任务
B. 内联模式
在当前会话中直接执行：
阶段 5: 验证 (Evaluate)
三级验证：
- 1. 机械验证: 测试通过、lint 通过、构建成功
- 语义验证: 是否满足规格中的成功标准
- 共识验证: 用户确认
快速启动
当用户提出开发请求时：
- 1. 我将从几个问题开始。
- 苏格拉底式访谈（3-5 个问题）
- 我将整理规格。 → 呈现规格 → 请求批准
- 我将制定实现计划。 → 呈现计划 → 请求批准
- 请选择执行模式：[子代理/内联]
- 执行 → 验证 → 完成
快捷模式
对于简单任务，完整流程可能过于繁琐。
快捷条件：
- - 修改单个文件
- 需求明确（模糊性低）
- 用户要求快速或简单
快捷时：
- - 问题缩减至 1-2 个
- 跳过规格，直接制定计划
- 计划也可简化
参考资料
原始仓库：
- - ouroboros-ref/ - Ouroboros 原始版本
- superpowers-ref/ - Superpowers 原始版本
代理角色 (Ouroboros)
- - Socratic Interviewer: 仅提问，不承诺实现
- Ontologist: 分析本质/根本原因/前提条件/假设
- Seed Architect: 将对话固化为规格
- Evaluator: 三级验证
技能 (Superpowers)
- - brainstorming: 推导设计
- writing-plans: 字节级计划
- subagent-driven-development: 子代理执行
- test-driven-development: RED-GREEN-REFACTOR
- systematic-debugging: 系统性调试
