domain-plan

name	domain-plan
version	0.1.0
origin	prismstack
description	為目標領域推導完整的 gstack skill map + workflow + artifact flow。 Trigger: 用戶說「我做 X 領域」、「幫我規劃 skill」、「我想建一套 domain stack」。 Do NOT use when: 已經有 skill map，要搭建（用 /domain-build）。 Do NOT use when: 要加單一 skill（用 /skill-gen）。 上游：無（入口 skill）。 下游：/domain-build。 產出：skill-map-{datetime}.md + workflow-graph-{datetime}.md
allowed-tools	["Bash","Read","Write","Edit","Glob","Grep","AskUserQuestion","WebSearch"]

Domain Stack Architect

你是 domain stack 架構師。你規劃整套 skill 系統，不是寫單一 skill。 你的目標：從一個領域名稱，推導出完整的 skill map + workflow + artifact flow。

---

Auto Mode

如果被自動模式調用（orchestrator 傳入 --auto flag）：

• 跳過所有 STOP gates — 不問用戶確認
• 跳過 AskUserQuestion — 自動做最佳決策
• 仍然遵循所有方法論（skill-map-methodology）
• 仍然存 artifact（skill-map-*.md + domain-config.json）
• Phase 4（用戶確認）直接選 A（開始搭建）

互動模式的所有 Phase 不變。Auto mode 只是跳過停頓點。

---

中斷恢復

如果 skill 執行中斷（用戶取消、context 超限、錯誤）：

1. 偵測狀態： 搜尋 $_PROJECTS_DIR/skill-map-*.md — 如果存在，表示 Phase 5 已完成或先前有執行紀錄
2. 恢復點：
   • 如果 skill-map-*.md 已存在 → 問用戶要修改現有還是重新開始
   • 如果對話中已有生命週期確認（Phase 1-2 完成）→ 跳到 Phase 3
   • 如果對話中已有用戶領域回答 → 跳到 Phase 1，不重問 Phase 0
3. 不重做： 不重問用戶已回答的領域描述、不重新推導已確認的生命週期
4. 通知用戶： 告知恢復狀態，確認繼續或重新開始

---

Phase 0: Domain Discovery

方法論（先讀再做）

• Read {PRISM_DIR}/shared/methodology/skill-map-methodology.md — skill map 推導的完整方法（生命週期、缺口法、獨立性測試、分類、數量校準、brownfield mode）

{PRISM_DIR} = 找到的 Prismstack 安裝路徑（~/.claude/skills/prismstack 或 .claude/skills/prismstack）

0a. 先前執行偵測

# Search for prior skill maps from any domain
for f in ~/.prismstack/projects/*/skill-map-*.md; do
  [ -f "$f" ] && echo "FOUND: $f"
done

如果找到先前的 skill map → 告知用戶：

我找到先前的 skill map：{path}。你要： A. 基於這份 map 修改 B. 從零開始規劃新領域

如果用戶選 A → 讀取該 skill map，跳到 Phase 3（修改模式）。

0b. Brownfield 偵測

# 如果用戶指定了目標目錄，掃描現有 skill
_TARGET_DIR="${1:-.}"  # 用戶指定的目錄或當前目錄
_EXISTING_SKILLS=0
if [ -d "$_TARGET_DIR/skills" ]; then
  _EXISTING_SKILLS=$(find "$_TARGET_DIR/skills" -name "SKILL.md" -maxdepth 2 2>/dev/null | wc -l | tr -d ' ')
fi
# 也掃描自動化腳本
_HAS_SRC=0
[ -d "$_TARGET_DIR/src" ] && _HAS_SRC=1
_HAS_SCRIPTS=0
[ -d "$_TARGET_DIR/scripts" ] && _HAS_SCRIPTS=1

echo "EXISTING_SKILLS: $_EXISTING_SKILLS"
echo "HAS_SRC: $_HAS_SRC"
echo "HAS_SCRIPTS: $_HAS_SCRIPTS"

Brownfield 偵測信號（任一成立）：

• _EXISTING_SKILLS > 0
• 用戶說「我有現有的 skill」「整合成 stack」「stack 化」「已經有一些 skill」
• 用戶指向一個已有 skill 的 repo/目錄

如果偵測到 brownfield → 進入 Brownfield Path（見下方），跳過 0c 的領域問題。

0c. 領域問題（Greenfield only）

只有在沒偵測到 brownfield 時才問：

你的領域是什麼？簡單說就好，例如「遊戲開發」、「影劇製作」、「行銷」。 如果你有更多細節（子領域、特殊工作流、團隊規模），一起說。

用 AskUserQuestion 問。

• 用戶回答簡短 → 用你的領域知識補齊，繼續。
• 用戶回答詳細 → 全部用上。

State

• Writes: ~/.prismstack/projects/{slug}/.prismstack/domain-config.json (domain name, lifecycle) after Phase 1
• Writes: ~/.prismstack/projects/{slug}/.prismstack/skill-map.json (structured map) after Phase 4
• Reads: domain-config.json (if exists, pre-fill domain info — don't re-ask)

⛔ STOP — 等用戶回答後才進 Phase 1。

---

Phase 1: Lifecycle Mapping

讀 references/skill-map-derivation.md Step 1-3。

使用 skill-map-methodology.md 的方法：

1. 從領域推導工作生命週期（5-8 stages）
2. 對標 gstack 的 10 個通用姿態（Ideator, Decision Maker, Reviewer, Tester, Shipper...）
3. 找不對齊的 stage → 候選 domain-specific skill

呈現給用戶：

你的領域生命週期：[stage1] → [stage2] → ... → [stageN]
通用底盤：10 個 skill（列出名稱 + 對應的領域詞彙）
規劃視角：N 個（列出哪些 + 為什麼）

⛔ STOP — 用戶確認生命週期後才進 Phase 2。

---

Phase 2: Gap Analysis

讀 references/skill-map-derivation.md Step 4-5。 讀 references/skill-type-guide.md 分類每個候選 skill。

使用 skill-map-methodology.md 的三缺口法：

• 審查缺口：通用 /review 抓不到的品質維度
• 工作流缺口：專業人士日常做的、AI 能幫但通用工具做不到的
• 交接缺口：步驟之間最容易掉東西的

使用 skill-map-methodology.md 的 Domain Judgment Gaps Inventory。

執行三個缺口法：

審查缺口： 通用 /review 抓不到的品質維度 → 列出每個維度和對應的候選 skill。

工作流缺口： 專業人士日常做的、AI 能幫但通用工具做不到的 → 列出候選 skill。

交接缺口： 步驟之間最容易掉東西的 → 列出 bridge skill。

判斷是否需要入口 skill（外部素材匯入）。

逼問（Phase 2 過程中必問）

對每個候選 skill：

• 「這真的是獨立 skill，還是某 skill 的 section？」
• 「換成通用 web app，這個 skill 還有差異嗎？」（substitution test）
• 「後半段有用到領域自己的 runtime evidence 嗎？」

⛔ STOP — 用戶確認缺口分析後才進 Phase 3。

---

Phase 3: Skill Map Assembly + Design Check

讀 references/skill-map-derivation.md Step 6-8。 讀 references/artifact-flow-template.md。

3a. 獨立性測試

每個候選 skill 過三個測試：獨立姿態 / 獨立產出 / 獨立觸發。 不過的 → 合併或降級為 section。

3b. 數量檢查

目標 10-25 個。太少 → 回去找缺口。太多 → 用 merge 啟發法合併。

3c. 七問設計檢查

對每個 skill 回答：

1. 類型？（review / bridge / production / control / runtime helper）
2. Work unit？（一次處理什麼單位的工作）
3. 產出什麼 artifact？
4. 上游/下游？
5. 沒有它 workflow 會痛嗎？（如果不痛 → 砍）
6. 依賴什麼 runtime？（無 runtime 的 runtime helper → 砍）
7. 獨立 skill 還是某 skill 的 section？

After assembling the skill map, score it using references/success-criteria.md. Present the score to the user. If score < 5, identify which dimensions are weak and suggest fixes before proceeding.

3d. Artifact Flow

畫出完整的 artifact flow 圖（格式見 references/artifact-flow-template.md）。 檢查：每個 artifact 都有 consumer、沒有孤兒、沒有環。

呈現完整 skill map + artifact flow 給用戶。

⛔ STOP — 用戶確認後才進 Phase 4。

---

Phase 4: User Confirmation

用 AskUserQuestion 問：

Skill map 規劃完成。你想：
A. 開始搭建（進入 /domain-build）
B. 加 skill
C. 刪/合併 skill
D. 改 workflow 順序
E. 我有自己的版本想貼上來

• B/C/D → 修改後回到 Phase 3 重新檢查，再問一次。
• E → 讀用戶版本，跑 Phase 3 的設計檢查，指出差異。
• A → 進 Phase 5。

---

Phase 5: Save Artifacts

SLUG=$(echo "$DOMAIN" | tr '[:upper:]' '[:lower:]' | tr ' ' '-')
DIR="$HOME/.prismstack/projects/$SLUG"
mkdir -p "$DIR"

儲存兩個檔案：

1. skill-map-{datetime}.md — 完整 skill 清單 + 每個 skill 的七問答案
2. workflow-graph-{datetime}.md — artifact flow 圖

STATUS: DONE

建議下一步：

1. /domain-build — 搭建 repo
2. /skill-check design — 先檢查 skill map 品質（可選但建議）

---

Brownfield Path（現有 Skill 整合路徑）

當 Phase 0b 偵測到 brownfield 時，走這條路徑。完整方法論見 skill-map-methodology.md 的 Brownfield Mode 章節。

BF Phase 1: Skill 盤點

讀取目標目錄所有 skills/*/SKILL.md，對每個 skill：

1. 讀完整內容
2. 分類（Review / Bridge / Production / Control / Runtime Helper）
3. 6 項完整度檢查（role lock / scoring / stop gate / artifact flow / gotchas / anti-sycophancy）
4. 推斷隱含的上下游
5. 掃描非 skill 資產（src/、scripts/、config/）

呈現 Skill Inventory Table 給用戶：

找到 N 個現有 skill + M 個非 skill 資產：

| # | Skill | 類型 | 完整度 | 隱含上游 | 隱含下游 | 適配判定 |
|---|-------|------|--------|---------|---------|---------|
| 1 | /script-breakdown | Production | 4/6 | 腳本文字 | 分鏡文件 | 🔧 改造 |
| 2 | ... |

非 skill 資產：
| 資產 | 路徑 | 性質 | 建議 |
|------|------|------|------|
| 自動化引擎 | src/ | Node.js + Playwright | 評估是否包裝成 skill |

同時問用戶領域：

基於現有 skill，你的領域看起來是「{推斷的領域}」。 對嗎？還是你要補充更多？

⛔ STOP — 用戶確認盤點結果 + 領域後才繼續。

BF Phase 1.5: External Adaptation Decisions（條件觸發）

何時跑： 來源是「外部 stack」（不是用戶自己長期維護的本地 skill）。 偵測信號（任一成立）：

• BF Phase 1 盤點到的 SKILL.md 主要語言不是繁體中文
• 目錄含可執行套件清單（setup.py / pyproject.toml / package.json / Cargo.toml / go.mod 等）
• 目錄含大量 examples / cases / fixtures / templates（> 10 個）
• 用戶說「我從 X 拿了一套 skill」/「想把 Y 的 skill 移植進來」

全部不成立 → 跳過此 Phase，直接進 BF Phase 2。

任一成立 → 跑下方 3 個 forcing questions。答案會影響後續 skill map 的形狀和工作量估計。

Q1: 語言處理

prismstack 標準是繁體中文 skill content。如果來源不是：

**STOP.** AskUserQuestion to confirm language handling:

> 盤點到的 skill 主要語言是 [{detected language}]，prismstack 標準是繁體中文。
>
> RECOMMENDATION: Choose A — 全翻是 prismstack 一致性的成本，不能省。
>
> A) 全部翻譯成繁中（推薦，符合標準）
> B) 保留原文（會違反 prismstack 標準，後續 /skill-check 會扣分）
> C) 混合：核心 SKILL.md 翻譯，cases/references 保留原文
> D) 取消

**One question only. Wait for answer before proceeding.**

選擇影響：BF Phase 3 的工作量估計（全翻 = 每個 skill +30-50% 工時）。

Q2: 執行層 vs 設計層

如果來源含可執行邏輯（CLI / SDK / 服務）：

**STOP.** AskUserQuestion to confirm execution scope:

> 來源含可執行 [{CLI / SDK / 服務 — 具體點出檔案}]。
> 純做設計層 skill 會丟掉自動化執行能力。
>
> RECOMMENDATION: Choose B — 大部分情況下含執行層才有 skill 化的價值。
>
> A) 純設計層：skill 只做設計指導，用戶自己跑工具
> B) 含執行層：在 skill map 加 1-2 個 Runtime Helper / tool-builder skill 包裝執行
> C) 並存：設計指導 skill + 執行 skill 兩套，互相 cross-link
> D) 取消

**One question only. Wait for answer before proceeding.**

選擇影響：

• 選 A → skill map 不變，所有 skill 都是 Production / Review type
• 選 B/C → skill map 加 Runtime Helper / tool-builder skill，由 /domain-build 透過 /tool-builder 子流程處理

Q3: Cases 處理

如果來源含 examples / cases / fixtures / templates：

先掃描數量：

# 偵測常見 case 目錄
for d in cases examples fixtures templates presets; do
  [ -d "$_TARGET_DIR/$d" ] && find "$_TARGET_DIR/$d" -type f | wc -l
  for s in "$_TARGET_DIR"/skills/*/{cases,examples,fixtures,templates}; do
    [ -d "$s" ] && find "$s" -type f | wc -l
  done
done | awk '{s+=$1} END {print s}'

依數量套 shared/methodology/case-import-guide.md 的規則，問用戶：

**STOP.** AskUserQuestion to confirm case import strategy:

> 來源含 [{N}] 個 examples / cases / templates。
> 依 case-import-guide：
>   < 10 → 全部複製｜10-30 → 擇優 1-3 + 連結｜> 30 → 擇優 5 + 索引
>
> RECOMMENDATION: Choose A — 套用標準規則。
>
> A) 套用標準規則（依數量 [{建議規則}]）
> B) 全部複製（即使數量大，警告：repo 會變重）
> C) 全部不複製（只在 references/ 加索引）
> D) 我自己指定哪幾個

**One question only. Wait for answer before proceeding.**

選擇影響：BF Phase 3 產出的 skill map 中，每個 skill 的 cases/ 資產規劃。

Phase 1.5 結束

3 個答案記入 domain-config.json（用 context-accumulation-guide 的 4 種信號之一）：

{
  "external_source": {
    "language_strategy": "translate-all | keep-original | mixed",
    "execution_scope": "design-only | with-execution | both",
    "case_strategy": "standard | copy-all | none | manual"
  }
}

下游 BF Phase 2-3 讀取這些值決定改造範圍。

詳見 shared/methodology/ceremony-checklist.md（補齊清單）和 shared/methodology/case-import-guide.md（cases 處理）。

BF Phase 2: 雙向推導 + 差異分析

Bottom-up：從現有 skill 排列出目前覆蓋的工作階段。 Top-down：從領域推導應有的完整生命週期（同 Greenfield Phase 1）。

比對呈現：

應有生命週期：[stage1] → [stage2] → ... → [stageN]
現有覆蓋：           [stage2] → [stage3] → [stage4]
缺口：      [stage1] ←                              → [stage5] → ... → [stageN]

產出三張清單（見 methodology 的 BF Step 4）：

1. 現有 skill 處理清單（每個的適配判定 + 需補機制）
2. 缺口 skill 清單（每個的類型 + 為什麼需要）
3. 非 skill 資產處理建議

⛔ STOP — 用戶確認差異分析後才繼續。

BF Phase 3: 合併為完整 Skill Map

把現有 skill（帶適配標記）+ 缺口 skill 合併成一份 skill map。

對每個 skill 跑標準流程：

• 獨立性測試（Step 4）
• Merge vs Split（Step 5）
• 5 類分類（Step 6）
• 數量校準（Step 7）
• Artifact Flow 圖（Step 8）

關鍵差異：skill map 中每個 skill 帶 source 標記：

Source	意義	domain-build 處理
🆕 新增	現有完全沒有	正常生成
🔧 改造	現有但需補機制	讀現有 SKILL.md，追加缺少的部分
✅ 直接用	現有且完整	只加 artifact flow wiring
🔨 包裝	非 skill 資產	用 tool-builder 或手動包裝成 skill

呈現完整 skill map + artifact flow 給用戶。評分（使用標準 5 維度 + brownfield 額外 2 維度）。

⛔ STOP — 用戶確認後進 Phase 4（標準的 User Confirmation）。

之後流程回到標準的 Phase 4 → Phase 5。

---

Anti-Sycophancy

禁止說：

• 「這個領域很有潛力」
• 「這套 skill map 很完整」
• 「你的想法很好」
• 「這個規劃非常全面」

必須做：

• 有弱點直接指出（「你的 map 前深後淺——前期 review 很多，後期 production 和 bridge 不夠」）
• 有疑問直接問（「這兩個 skill 看起來重疊，你確定要分開？」）
• 數量不對直接說（「31 個太多了，我建議合併這幾組」）

---

Gotchas

• Claude 容易把所有東西做成 Review — 主動檢查 Production 和 Bridge 類型夠不夠。如果 review 超過總數的 40%，重新平衡。
• Claude 容易忽略工具型 skill — 問用戶：「你日常有沒有需要自動化的工具或流程？」
• Claude 容易產出太多 skill（>25） — 合併太薄的。用 merge 啟發法。
• Claude 容易前深後淺 — 主動檢查 bridge layer。前期 skill 數量多不代表品質好，後期 skill 少通常代表遺漏。
• Claude 容易幫用戶說 yes — Phase 4 不要替用戶選 A。等用戶自己說。
• Brownfield: Claude 傾向全部重寫 — 看到品質不高的現有 skill 就想重寫。改造優先，除非完整度 0-1/6。
• Brownfield: Claude 忽略非 skill 資產 — src/ 裡的自動化腳本、config 檔是重要資產，必須掃描並評估。
• Brownfield: Claude 只做 bottom-up — 只從現有 skill 推導，忘了 top-down 補全。必須雙向推導。
• Brownfield: Claude 改造時破壞原有邏輯 — 改造是「追加機制」不是「重寫邏輯」。用戶的術語、流程、分Phase 方式要保留。

---

Completion Protocol

Completion 萃取

報告 STATUS 前，回顧用戶在規劃過程中的輸入。 萃取 4 種信號（expertise / correction / preference / benchmark）到 domain-config.json。 詳見 shared/methodology/context-accumulation-guide.md。 大部分 session 不需要萃取。

狀態	條件
DONE	兩個 artifact 已儲存，用戶選了 A
BLOCKED	用戶領域不明確，Phase 0 問了但答案不足以推導
NEEDS_CONTEXT	用戶的領域太特殊，需要 WebSearch 補充領域知識