為目標領域推導完整的 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

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 超限、錯誤）：

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

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 的方法：

從領域推導工作生命週期（5-8 stages）
對標 gstack 的 10 個通用姿態（Ideator, Decision Maker, Reviewer, Tester, Shipper...）
找不對齊的 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 回答：

類型？（review / bridge / production / control / runtime helper）
Work unit？（一次處理什麼單位的工作）
產出什麼 artifact？
上游/下游？
沒有它 workflow 會痛嗎？（如果不痛 → 砍）
依賴什麼 runtime？（無 runtime 的 runtime helper → 砍）
獨立 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"

儲存兩個檔案：

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

STATUS: DONE

建議下一步：

/domain-build — 搭建 repo
/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：

讀完整內容
分類（Review / Bridge / Production / Control / Runtime Helper）
6 項完整度檢查（role lock / scoring / stop gate / artifact flow / gotchas / anti-sycophancy）
推斷隱含的上下游
掃描非 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 2: 雙向推導 + 差異分析

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

比對呈現：

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

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

現有 skill 處理清單（每個的適配判定 + 需補機制）
缺口 skill 清單（每個的類型 + 為什麼需要）
非 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 補充領域知識

domain-plan