daniel.w
/
opencode-workflow
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
opencode-workflow/design-idea/VIBE_KANBAN_INTEGRATION_PLA...

440 lines
13 KiB
Markdown
Raw Normal View History

add AGENTS
2026-04-08 23:53:15 +00:00
# Vibe-Kanban 工作流程 - 技能整合規劃
**版本**: 3.0
**日期**: 2025-01-15
**狀態**: 實施階段
---
## 執行摘要
本規劃整合多個現有技能，建立完整的軟體開發工作流程。
**總計**: 11 個現有技能 + 5 個新建技能
**Agent**: 8 個核心 Agent + 1 個主控協調器
**階段**: 12 個工作流程階段
---
## 現有技能整合清單
### 核心技能（直接使用）
| Skill | 來源 | 用途 | 整合階段 |
|-------|------|------|---------|
| `brainstorming` | skills | PM 需求探索 | Stage 1 |
| `plan-ceo-review` | gstack | CEO 商業價值審核 | Stage 2 |
| `write-a-prd` | skills | PRD 撰寫（含訪談） | Stage 3 |
| `grill-me` | skills | **深度驗證閘門** | Stage 3.5 |
| `prd-to-plan` | skills | 實作計畫產出 | Stage 8 |
| `design-an-interface` | skills | API 介面設計 | Stage 4 |
| `tdd` | skills | 測試驅動開發 | Stage 9 |
| `qa` | skills | QA 測試驗收 | Stage 10 |
| `review` | gstack | PR 代碼審核 | Stage 11 |
| `land-and-deploy` | gstack | 部署流程 | Stage 12 |
| `cso` | gstack | 安全審核 | Stage 7/11 |
| `codex` | gstack | 多 AI 代碼審核 | Stage 11 |
### 新增技能（需實作）
| Skill | 用途 | 優先級 |
|-------|------|--------|
| `vibe-kanban` | **主控協調器** | P0 |
| `be-api-design` | OpenAPI 規格產出 | P1 |
| `go-backend-dev` | **Golang 後端實作** | P1 |
| `dba-schema` | 資料庫 Schema 設計 | P1 |
| `ux-prototype` | UX 原型設計 | P2 |
---
## Agent 角色定義
| # | Agent | 角色 | 主要技能 |
|---|-------|------|---------|
| 1 | **Orchestrator** | 主控協調器 | `vibe-kanban` |
| 2 | **PM Agent** | 產品經理 | `brainstorming`, `write-a-prd` |
| 3 | **CEO Reviewer** | 商業決策者 | `plan-ceo-review` |
| 4 | **Backend Agent** | Golang 後端工程師 | `be-api-design`, `go-backend-dev`, `design-an-interface`, `tdd` |
| 5 | **DBA Agent** | 資料庫工程師 | `dba-schema` |
| 6 | **UX Agent** | 使用者體驗設計師 | `ux-prototype` |
| 7 | **QA Agent** | 品質保證工程師 | `qa` |
| 8 | **DevOps Agent** | 運維工程師 | `land-and-deploy` |
| 9 | **Design Reviewer** | 設計審核者 | `design-review` |
| 10 | **Security Reviewer** | 安全審核者 | `cso` |
| 11 | **Code Reviewer** | 代碼審核者 | `review`, `codex` |
---
## 完整工作流程（含 Grill-Me 整合）
```
┌─────────────────────────────────────────────────────────────────────────────┐
│ VIBE-KANBAN + GRILL-ME 工作流程 │
└─────────────────────────────────────────────────────────────────────────────┘
Stage 1: Brainstorming (PM Agent)
├── Skill: brainstorming
├── 輸入: 使用者想法
├── 輸出: docs/brainstorm/{date}-{feature}.md
└── 下一步: CEO Review
Stage 2: CEO Review (CEO Reviewer)
├── Skill: plan-ceo-review
├── 輸入: Brainstorm 文件
├── 輸出: docs/ceo-review/{date}-{feature}.md
└── 下一步: PRD 撰寫
Stage 3: PRD 撰寫 (PM Agent)
├── Skill: write-a-prd
├── 輸入: CEO Review 結果
├── 輸出: docs/prd/{date}-{feature}.md (初版)
└── 下一步: 深度驗證 (可選)
Stage 3.5: 深度驗證 ⭐ GRILL-ME 整合點
├── Skill: grill-me
├── 觸發條件: 使用者選擇 "進行深度驗證"
├── 輸入: PRD 初版
├── 驗證項目:
│ ├── 每個功能性需求的完整性
│ ├── 使用者故事的邊界情況
│ ├── 非功能性需求的遺漏
│ ├── 驗收標準的可測試性
│ └── 潛在風險和依賴
├── 輸出: 強化後的 PRD
└── 下一步: API Design
Stage 4: API Design (Backend Agent)
├── Skill: be-api-design + design-an-interface
├── 輸入: PRD
├── 輸出: docs/api/{date}-{feature}.yaml
└── 下一步: DB Schema (平行)
Stage 5: DB Schema (DBA Agent)
├── Skill: dba-schema
├── 輸入: API 規格
├── 輸出: docs/db/{date}-{feature}.sql
└── 下一步: UX Prototype (平行)
Stage 6: UX Prototype (UX Agent)
├── Skill: ux-prototype
├── 輸入: PRD + API + DB
├── 輸出: docs/design/{date}-{feature}/
└── 下一步: Design Review
Stage 7: Design Review (Design Reviewer)
├── Skill: design-review
├── 輸入: 所有設計文件
├── 輸出: docs/design/review-report.md
├── 決策點:
│ ├── ✅ 通過 → Task Breakdown
│ └── ❌ 退回 → PRD 修改
└── 下一步: Task Breakdown
Stage 8: Task Breakdown (Orchestrator)
├── Skill: prd-to-plan
├── 輸入: 所有設計文件
├── 輸出: ./plans/{feature}.md
└── 下一步: 實作 (平行)
Stage 9: Implementation (Backend + Frontend Agents)
├── Backend Skill: go-backend-dev + tdd
├── Frontend Skill: (現有技能或手動)
├── 輸入: 實作計畫
├── 輸出: 程式碼
└── 下一步: QA
Stage 10: QA (QA Agent)
├── Skill: qa
├── 輸入: 程式碼 + 驗收標準
├── 輸出: .gstack/qa-reports/qa-report.md
├── 決策點:
│ ├── ✅ 通過 → PR Review
│ └── ❌ 失敗 → 退回 Task Breakdown
└── 下一步: PR Review
Stage 11: PR Review (Code Reviewer)
├── Skill: review + codex
├── 輸入: PR
├── 輸出: PR 審核報告
├── 決策點:
│ ├── ✅ 通過 → Deploy
│ └── ❌ 失敗 → 退回 Task Breakdown
└── 下一步: Deploy
Stage 12: Deploy (DevOps Agent)
├── Skill: land-and-deploy
├── 輸入: 已核准 PR
├── 輸出: .gstack/deploy-reports/deploy-report.md
└── 🎉 完成
```
---
## Grill-Me 深度驗證詳細設計
### 觸發機制
在每個關鍵階段後，Orchestrator 會詢問：
```
╔══════════════════════════════════════════════════════════════╗
║ 🔥 深度驗證機會 ║
╠══════════════════════════════════════════════════════════════╣
║ ║
║ 當前階段: PRD 撰寫 ║
║ 狀態: ✅ 初版已完成 ║
║ ║
║ 是否需要進行深度驗證 (grill-me)？ ║
║ 這將透過密集訪談壓力測試計畫的完整性。 ║
║ ║
║ [A] 是 - 進行深度驗證 (推薦用於關鍵功能) ║
║ [B] 否 - 直接進入下一階段 ║
║ ║
╚══════════════════════════════════════════════════════════════╝
```
### 驗證檢查清單
#### Stage 3.5 - PRD 深度驗證
```yaml
驗證項目:
功能性需求:
- "每個 FR 是否有明確的驗收標準？"
- "使用者故事是否覆蓋所有使用者角色？"
- "是否有遺漏的邊界情況？"
非功能性需求:
- "效能需求是否具體可量測？"
- "安全性需求是否完整？"
- "可用性和可靠性是否考量？"
技術可行性:
- "現有技術棧是否支援？"
- "是否有外部依賴風險？"
- "擴展性是否考量？"
業務邏輯:
- "所有業務規則是否明確？"
- "錯誤處理流程是否定義？"
- "狀態轉換是否清晰？"
```
### 整合流程圖
```mermaid
graph TD
A[Stage 3: PRD 初版] --> B{深度驗證?}
B -->|是| C[Stage 3.5: grill-me]
B -->|否| D[Stage 4: API Design]
C --> C1[問題 1: 需求完整性]
C1 --> C2[問題 2: 邊界情況]
C2 --> C3[問題 3: 風險評估]
C3 --> C4[...更多問題]
C4 --> E[強化 PRD]
E --> D
D --> F[後續階段]
```
---
## 各階段交付文件
| 階段 | Agent | 主要技能 | 輔助技能 | 交付文件 |
|------|-------|---------|---------|---------|
| 1 | PM | brainstorming | - | `docs/brainstorm/{date}-{feature}.md` |
| 2 | CEO Reviewer | plan-ceo-review | - | `docs/ceo-review/{date}-{feature}.md` |
| 3 | PM | write-a-prd | - | `docs/prd/{date}-{feature}.md` (初版) |
| 3.5 | PM | **grill-me** | - | `docs/prd/{date}-{feature}.md` (強化版) |
| 4 | Backend | be-api-design | design-an-interface | `docs/api/{date}-{feature}.yaml` |
| 5 | DBA | dba-schema | - | `docs/db/{date}-{feature}.sql` |
| 6 | UX | ux-prototype | - | `docs/design/{date}-{feature}/` |
| 7 | Design Reviewer | design-review | cso | `docs/design/review-report.md` |
| 8 | Orchestrator | prd-to-plan | dispatching-parallel-agents | `./plans/{feature}.md` |
| 9 | Backend | go-backend-dev | tdd | `internal/`, `cmd/`, `pkg/` |
| 10 | QA | qa | - | `.gstack/qa-reports/qa-report.md` |
| 11 | Code Reviewer | review | codex | PR 審核報告 |
| 12 | DevOps | land-and-deploy | - | `.gstack/deploy-reports/deploy-report.md` |
---
## 技能依賴關係
```yaml
技能依賴:
brainstorming:
輸入: 使用者想法
輸出: brainstorm.md
plan-ceo-review:
輸入: brainstorm.md
輸出: ceo-review.md
write-a-prd:
輸入: ceo-review.md
輸出: prd.md (初版)
grill-me: # 可選
輸入: prd.md (初版)
輸出: prd.md (強化版)
依賴: write-a-prd
be-api-design:
輸入: prd.md
輸出: api-spec.yaml
輔助: design-an-interface
dba-schema:
輸入: api-spec.yaml
輸出: schema.sql
ux-prototype:
輸入: prd.md, api-spec.yaml, schema.sql
輸出: design/
design-review:
輸入: design/
輸出: review-report.md
prd-to-plan:
輸入: prd.md, api-spec.yaml, design/
輸出: ./plans/{feature}.md
go-backend-dev:
輸入: ./plans/{feature}.md
輸出: 程式碼
輔助: tdd
qa:
輸入: 程式碼, prd.md (驗收標準)
輸出: qa-report.md
review:
輸入: PR
輸出: pr-review.md
輔助: codex
land-and-deploy:
輸入: pr-review.md (已核准)
輸出: deploy-report.md
```
---
## Golang 後端特定規則（go-backend-dev）
### 架構風格
```yaml
預設架構: Clean Architecture (適合中型專案)
專案結構:
cmd/api/main.go # 進入點
internal/
domain/ # Entities, Value Objects
usecase/ # Business Logic
interface/
http/ # Handlers
repository/ # Repository interfaces
infrastructure/ # DB, Cache implementations
pkg/
logger/ # Zap
errors/ # 自定義錯誤
validator/ # go-playground/validator
api/openapi.yaml
migrations/
test/
```
### 編碼規範
```yaml
命名:
Package: 小寫單數 (user, not users)
Interface: 方法名 + 'er' (Reader, Writer)
Exported: PascalCase
Internal: camelCase
錯誤處理:
- Always check errors
- Error strings lowercase
- Use fmt.Errorf with %w
API 設計:
RESTful: /api/v1/{resource}
狀態碼: 200, 201, 400, 401, 404, 422, 500
測試:
- Unit tests >= 80% 覆蓋率
- Integration tests for critical paths
- Use testify + mockery
```
---
## 實作優先順序
### Phase 1: 核心框架 (Week 1)
| 優先級 | Skill | 複雜度 | 說明 |
|-------|-------|--------|------|
| P0 | vibe-kanban | 高 | 主控協調器，整合所有技能 |
| P0 | grill-me 整合 | 中 | 設計深度驗證流程 |
### Phase 2: 設計階段技能 (Week 2)
| 優先級 | Skill | 複雜度 | 說明 |
|-------|-------|--------|------|
| P1 | be-api-design | 中 | OpenAPI 規格產出 |
| P1 | go-backend-dev | 高 | **Golang 後端實作** |
| P1 | dba-schema | 中 | 資料庫設計 |
### Phase 3: 整合測試 (Week 3)
- 整合所有現有技能
- 端到端流程測試
- 退回機制測試
### Phase 4: 優化 (Week 4)
- 效能優化
- 文件完善
- 使用指南
---
## 附錄
### A. 技術棧建議
**Golang 後端**:
- 框架: Gin 或 Echo
- ORM: GORM 或 sqlx
- 配置: Viper
- 日誌: Zap
- 驗證: go-playground/validator
- 測試: testify + mockery
- 文件: swag (Swagger)
**資料庫**:
- 主要: PostgreSQL
- 快取: Redis
- 遷移: golang-migrate/migrate
**部署**:
- 容器: Docker
- CI/CD: GitHub Actions
### B. 參考資源
1. [Uber Go Style Guide](https://github.com/uber-go/guide)
2. [golang-standards/project-layout](https://github.com/golang-standards/project-layout)
3. [Go Clean Architecture](https://github.com/bxcodec/go-clean-arch)
4. [A Philosophy of Software Design](https://web.stanford.edu/~ouster/cgi-bin/book.php) (for grill-me 概念)
---
**下一步**: 開始實作 `vibe-kanban` 主控技能？