style(sdlc): 依 STE100 擬人台灣感規則改寫語感
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
This commit is contained in:
@@ -14,15 +14,15 @@ description: SDLC analysis stage. Gate on model capability tags, pick a plan fro
|
||||
## 流程
|
||||
|
||||
1. **模型能力檢查**:依 `jsc-cli:models` 的能力標籤確認目前模型具備「分析」能力。不適合就阻擋流程,並告知使用者建議改用的模型。
|
||||
2. 經由 `jsc-gitea:wiki` 讀取 `PLAN_CONTENTS` 的**未分析**計畫(名稱 + HASH),並讀取 `ANALYZE_CONTENTS` 的既有分析。
|
||||
2. 經由 `jsc-gitea:wiki` 讀取 `PLAN_CONTENTS` 的**未分析**計畫(名稱與 HASH),並讀取 `ANALYZE_CONTENTS` 的既有分析。
|
||||
3. 依 `jsc-ask:ask` 規則讓使用者選擇:**補充既有分析**或**分析新計畫**。每個選項標明影響範圍。
|
||||
4. 搭配**現況**,依 `jsc-ask:ask` 決策樹逐條分析計畫頁的使用者故事,直到補全所有疑慮;只要還沒達成共識就繼續詢問。現況定義:
|
||||
1. 工作目錄的所有檔案。
|
||||
2. **盡量複用既有方法或端點**:
|
||||
- 優先查 `REPO_{HASH}` 盤點頁。若功能與端點不存在,或紀錄的 commit sha 與目前不同,就重新盤點。
|
||||
- 重新盤點**必須以 sub agent 執行**:分析該存取庫的功能與端點,加上目前 commit sha,套用 `templates/repo-page.md` 寫回 `REPO_{HASH}`,並依 `templates/repo-contents.md` 更新 `REPO_CONTENTS`。
|
||||
- 對候選的複用目標,先確認檔案路徑與方法名稱,再分析其邏輯是否符合需求。
|
||||
5. 執行**工作分解結構(WBS)**:把使用者故事拆成工作包,每個工作包給編號(`WP-01`、`WP-02`…)並標明相依關係。
|
||||
- 對候選的複用目標,先確認檔案路徑與方法名稱,再分析邏輯是否符合需求。
|
||||
5. 執行**工作分解結構(WBS)**:把使用者故事拆成工作包,每個工作包給編號(`WP-01`、`WP-02` 依序遞增)並標明相依關係。
|
||||
6. 以**關鍵路徑法(CPM)**估算每個工作包的工時與天數,標出關鍵路徑。
|
||||
7. 以**測試驅動開發(TDD)**把每個工作包拆解成多個待辦事項,格式 `[ ]`(未完成)/ `[x]`(完成),每項為一個垂直切片(一個接縫、一個測試、一個最小實作);接縫與反模式見 `references/tdd.md`。
|
||||
8. 套用 `templates/analyze-page.md` 產生或更新分析頁,經由 `jsc-gitea:wiki` 寫回。
|
||||
|
||||
@@ -12,7 +12,7 @@ description: SDLC implementation stage. Gate on model capability tags, claim a r
|
||||
|
||||
1. **模型能力檢查**:依 `jsc-cli:models` 的能力標籤確認目前模型具備「實作」能力。不適合就阻擋流程,並告知使用者建議改用的模型。
|
||||
2. **產生工作證**:格式 `TICKET_{session id 前 8 碼}_{yyyyMMddHHmmss}`,並嘗試將目前 session 重新命名為工作證名稱(CLI 不支援時略過)。
|
||||
3. 經由 `jsc-gitea:wiki` 讀取 `ANALYZE_CONTENTS`,列出未完成的:計畫名稱 + HASH + 工作包編號 + 未完成項目數量。可選的工作包必須同時滿足:**未完成、無相依(或相依都已完成)、無工作證**。
|
||||
3. 經由 `jsc-gitea:wiki` 讀取 `ANALYZE_CONTENTS`,列出未完成的:計畫名稱、HASH、工作包編號、未完成項目數量。可選的工作包必須同時滿足:**未完成、無相依(或相依都已完成)、無工作證**。
|
||||
4. 依 `jsc-ask:ask` 規則讓使用者選擇要實作的工作包(選項標明未完成項目數與預估工時)。把工作證寫入分析頁該工作包的「工作證」欄位並寫回 wiki,**成功標上工作證才可以進入下一步**。
|
||||
5. 列出該工作包所有未完成項目,**逐項實作**:
|
||||
- 依 TDD 循環:先紅後綠、一次一片;規則與反模式見 `references/tdd.md`(重構留給審查階段)。
|
||||
|
||||
@@ -14,13 +14,13 @@ description: SDLC planning stage. Gate on model capability tags, pick or create
|
||||
## 流程
|
||||
|
||||
1. **模型能力檢查**:依 `jsc-cli:models` 的能力標籤確認目前模型具備「規劃」能力。不適合就阻擋流程,並告知使用者建議改用的模型。
|
||||
2. 經由 `jsc-gitea:wiki` 讀取 `PLAN_CONTENTS`,列出**未分析**的計畫名稱 + HASH。
|
||||
2. 經由 `jsc-gitea:wiki` 讀取 `PLAN_CONTENTS`,列出**未分析**的計畫名稱與 HASH。
|
||||
3. 依 `jsc-ask:ask` 規則讓使用者選擇:**補充既有計畫**(列出未分析計畫為選項)或**新建計畫**。每個選項標明影響範圍。
|
||||
4. 依 `jsc-ask:ask` 決策樹詢問,補全以下三項直到沒有疑慮;只要還沒達成共識就繼續詢問:
|
||||
- 計畫目標:要解決什麼問題、成功的判斷標準。
|
||||
- 計畫範圍:包含什麼、排除什麼、涉及哪些存取庫。
|
||||
- 可行性:系統架構與資料來源是否支撐目標。
|
||||
5. 由共識產生**使用者故事**(身為…我想要…以便…),逐條列出。
|
||||
5. 由共識產生**使用者故事**(身為⋯⋯我想要⋯⋯以便⋯⋯),逐條列出。
|
||||
6. 套用 `templates/plan-page.md` 產生或更新計畫頁,經由 `jsc-gitea:wiki` 寫回。
|
||||
7. 若是新的計畫頁,套用 `templates/plan-contents.md` 的條目格式,將其加入 `PLAN_CONTENTS`(狀態=未分析)。
|
||||
|
||||
|
||||
Reference in New Issue
Block a user