Skip to content

Commit 7a67371

Browse files
author
薛華慶, james.hsueh
committed
feat: support codex
1 parent f2ea52e commit 7a67371

File tree

11 files changed

+1323
-75
lines changed

11 files changed

+1323
-75
lines changed

‎.codex/commands/sdd-arch.md‎

Lines changed: 139 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,139 @@
1+
---
2+
description: Phase 2 - 分析 Gherkin 規格，設計高階架構（資料模型與服務介面），輸出到 docs/features/{feature_name}/
3+
---
4+
5+
# SDD Phase 2: 架構設計
6+
7+
**角色：** 系統架構師
8+
**輸入：** Gherkin 規格檔案 {{prompt}}
9+
**輸出：** `docs/features/{feature_name}/architecture.md`
10+
11+
## 核心原則
12+
13+
- **語言無關**：根據專案上下文自動適應
14+
- **專案感知**：掃描技術棧、架構模式、命名慣例
15+
- **架構一致**：遵循專案既有設計
16+
- **高階設計**：定義資料模型與服務介面，不含實作細節
17+
18+
## 執行步驟
19+
20+
### 1. 分析專案上下文
21+
22+
掃描專案以判斷：
23+
- **技術棧**：檢查 `package.json`、`go.mod`、`requirements.txt` 等
24+
- **架構模式**：識別目錄結構（`controllers/`、`services/`、`repositories/` 等）
25+
- **命名慣例**：分析既有程式碼風格（camelCase、snake_case 等）
26+
27+
優先順序：Prompt 指定 > 專案既有架構 > 語言最佳實踐
28+
29+
### 2. 提取功能名稱
30+
31+
從 Gherkin 檔案路徑或 Feature 名稱提取，轉換為專案命名慣例
32+
33+
### 3. 設計架構
34+
35+
- **名詞 → 資料模型**：識別實體、欄位、列舉
36+
- **動詞 → 服務介面**：定義方法簽名、參數、回傳值
37+
- **架構決策**：說明設計理由與整合方式
38+
39+
## 輸出文件結構
40+
41+
```markdown
42+
# {功能名稱} - 架構設計
43+
44+
> 來源：features/{feature_name}.feature
45+
> 建立日期：{日期}
46+
47+
## 1. 專案上下文
48+
49+
- 程式語言：{language}
50+
- 框架：{framework}
51+
- 架構模式：{pattern}
52+
- 命名慣例：{convention}
53+
54+
## 2. 功能概述
55+
56+
{簡述功能及核心需求}
57+
58+
## 3. 資料模型
59+
60+
### 3.1 列舉/常數
61+
62+
#### {EnumName}
63+
來源："{Gherkin 語句}" (第 X 行)
64+
65+
| 值 | 說明 |
66+
|---|---|
67+
| {VALUE} | {說明} |
68+
69+
### 3.2 核心實體
70+
71+
#### {EntityName}
72+
來源："{Gherkin 語句}" (第 X 行)
73+
74+
| 欄位 | 型別 | 必填 | 說明 |
75+
|---|---|---|---|
76+
| {field} | {type} | ✅/- | {說明} |
77+
78+
## 4. 服務介面
79+
80+
### {ServiceName}
81+
82+
職責：{服務職責}
83+
84+
#### {methodName}()
85+
來源："{Gherkin 語句}" (第 X-Y 行)
86+
87+
**簽名：** `{signature}`
88+
89+
**參數：**
90+
| 參數 | 型別 | 說明 |
91+
|---|---|---|
92+
| {param} | {type} | {說明} |
93+
94+
**回傳：** {returnType}
95+
96+
**業務規則：**
97+
1. {規則 1}
98+
2. {規則 2}
99+
100+
## 5. 架構決策
101+
102+
- 為何選擇此架構模式：{理由}
103+
- 資料模型設計理由：{理由}
104+
- 整合方式：{與現有系統的整合}
105+
106+
## 6. 情境對應
107+
108+
| 情境 | 行數 | 資料模型 | 服務方法 |
109+
|---|---|---|---|
110+
| {情境} | {行號} | {Model} | {method()} |
111+
112+
## 7. 檔案結構
113+
114+
```
115+
src/
116+
├── {模型目錄}/{FeatureName}Model.{ext}
117+
├── {服務目錄}/{FeatureName}Service.{ext}
118+
└── tests/{FeatureName}.test.{ext}
119+
```
120+
```
121+
122+
## 品質檢查
123+
124+
- [ ] 已掃描專案上下文（技術棧、架構、命名）
125+
- [ ] 所有名詞已轉為資料模型
126+
- [ ] 所有動詞已轉為服務介面
127+
- [ ] 每個元素註明 Gherkin 來源行數
128+
- [ ] 包含架構決策說明
129+
- [ ] 全文使用繁體中文
130+
- [ ] 檔案儲存至 `docs/features/{feature_name}/architecture.md`
131+
132+
## 執行流程
133+
134+
1. 掃描專案（技術棧、架構、命名慣例）
135+
2. 讀取 Gherkin 檔案
136+
3. 提取名詞（實體）與動詞（行為）
137+
4. 生成架構文件（遵循專案上下文）
138+
5. 儲存至 `docs/features/{feature_name}/architecture.md`
139+
6. 回報技術棧與架構決策

‎.codex/commands/sdd-auto.md‎

Lines changed: 152 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,152 @@
1+
---
2+
description: 自動執行完整 SDD 工作流程 (4 Phases)
3+
---
4+
5+
# SDD 自動模式
6+
7+
**需求：** {{prompt}}
8+
9+
**目標：** 自動執行 Phase 1-4，從需求到驗證完成，無需手動介入
10+
11+
**核心理念：** 規格 → 架構 → 實作 → 驗證（語言無關，專案感知）
12+
13+
## 開始前：掃描專案
14+
15+
```bash
16+
# 技術棧
17+
ls -la | grep -E "package.json|requirements.txt|go.mod|pom.xml"
18+
19+
# 目錄結構
20+
find . -type d -maxdepth 3 | grep -E "src|models|services" | head -10
21+
22+
# 程式碼樣本
23+
find . -name "*.ts" -o -name "*.py" -o -name "*.go" | head -5
24+
```
25+
26+
**判斷優先順序：** Prompt 指定 > 專案上下文 > 詢問使用者 > 預設 TypeScript
27+
28+
## Phase 1: 規格（PM）
29+
30+
**角色：** PM - 只談業務規則，不談技術
31+
**輸出：** `features/{feature_name}.feature`
32+
33+
**動作：**
34+
1. 分析需求找出業務規則和邊界情況
35+
2. 用 Gherkin 撰寫情境（Given-When-Then）
36+
3. 必須包含：正常路徑、邊界、錯誤處理
37+
38+
```gherkin
39+
Feature: {功能名稱}
40+
Scenario: {情境}
41+
Given {前置條件}
42+
When {動作}
43+
Then {預期結果}
44+
```
45+
46+
## Phase 2: 架構（架構師）
47+
48+
**角色：** 架構師 - 高階設計，語言無關
49+
**輸出：** `docs/features/{feature_name}/architecture.md` (繁中)
50+
51+
**動作：**
52+
1. 掃描專案上下文（技術棧、架構、命名慣例）
53+
2. 讀取 Phase 1 的 Gherkin
54+
3. 名詞 → 資料模型；動詞 → 服務介面
55+
4. 生成繁體中文 Markdown 架構文件
56+
57+
**文件結構：**
58+
```markdown
59+
# {功能} - 架構設計
60+
61+
## 1. 專案上下文
62+
- 語言/框架/架構模式/命名慣例
63+
64+
## 2. 功能概述
65+
66+
## 3. 資料模型
67+
- 列舉/常數
68+
- 核心實體（欄位、型別、說明）
69+
70+
## 4. 服務介面
71+
- 方法簽名（語言無關描述）
72+
- 業務規則
73+
74+
## 5. 架構決策
75+
- 選擇此架構的理由
76+
77+
## 6. 情境對應
78+
| 情境 | 模型 | 方法 |
79+
80+
## 7. 檔案結構規劃
81+
```
82+
83+
## Phase 3: 實作（工程師）
84+
85+
**角色：** 工程師 - 依架構實作程式碼
86+
**輸出：** 實作檔案（依 architecture.md 定義位置）
87+
88+
**動作：**
89+
1. 讀取 Gherkin + architecture.md
90+
2. 依架構文件實作資料模型與服務
91+
3. 每個 Gherkin 情境對應程式碼邏輯分支
92+
4. 檔案存至 architecture.md 指定位置
93+
94+
**情境對應：** Given→輸入 / When→執行 / Then→驗證
95+
96+
## Phase 4: 驗證（QA）
97+
98+
**角色：** QA - 驗證架構與情境符合性
99+
**輸出：** `docs/features/{feature_name}/conclusion.md`
100+
101+
**動作：**
102+
1. 讀取 Gherkin + architecture.md + 實作
103+
2. 驗證架構符合性（模型、介面、檔案位置）
104+
3. 驗證每個 Gherkin 情境（Given→When→Then）
105+
4. 生成結論至 `docs/features/{feature_name}/conclusion.md`
106+
107+
**報告格式：**
108+
```markdown
109+
# {功能} - 驗證結論
110+
111+
## 1. 架構符合性
112+
| 元件 | 定義 | 實作 | 狀態 |
113+
114+
## 2. 情境驗證
115+
### {情境} (第 X 行)
116+
- Given/When/Then → ✅/❌
117+
118+
## 3. 摘要
119+
- 架構：{通過}/{總數}
120+
- 情境：{通過}/{總數}
121+
- **狀態：** ✅ 完成 / ❌ 需修正
122+
123+
## 4. 失敗回饋（如有）
124+
```
125+
126+
## 執行流程
127+
128+
1. 掃描專案上下文
129+
2. Phase 1 → `features/{feature}.feature`
130+
3. Phase 2 → `docs/features/{feature}/architecture.md`
131+
4. Phase 3 → 實作檔案（依 architecture.md）
132+
5. Phase 4 → `docs/features/{feature}/conclusion.md`
133+
6. 失敗時返回 Phase 3 重試
134+
135+
**輸出結構：**
136+
```
137+
project_root/
138+
├── features/{feature}.feature
139+
├── docs/features/{feature}/
140+
│ ├── architecture.md
141+
│ └── conclusion.md
142+
└── {專案目錄}/
143+
├── {模型檔案}
144+
└── {服務檔案}
145+
```
146+
147+
**重要：**
148+
- Phase 2 輸出繁體中文 Markdown（語言無關）
149+
- Phase 3 遵循專案技術棧與架構
150+
- 每個 Phase 必須完成才進入下一個
151+
152+
開始執行 Phase 1。

0 commit comments

Comments
 (0)