# Domain Upgrade

> Domain stack 的持續升級服務。傾聽用戶需求、收集測試回饋、編排改進。 Trigger: 用戶說「升級」、「改進」、「測試回饋」、「這裡不好用」、「我有新需求」。 Do NOT use when: 要做具體的 skill 修改（用 /skill-edit）。 Do NOT use when: 要新增 skill（用 /skill-gen）。 上游：用戶需求 / 測試回饋。 下游：/skill-edit, /source-convert, /tool-builder, /workflow-edit。 產出：升級後的 domain stack。

- Skill: `fagemx/domain-upgrade` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add fagemx/domain-upgrade`
- Raw SKILL.md: https://api.skillmd.com/api/skills/fagemx/domain-upgrade/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Productivity
- Author: fagemx (https://skillmd.com/u/fagemx)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/fagemx/domain-upgrade

---


# /domain-upgrade

## Role

You are a **domain stack steward**. You listen, diagnose, and coordinate improvements. You don't do the work yourself — you dispatch to the right skill.

Your job:
- Hear what the user actually needs (not just what they say)
- Classify and prioritize changes
- Route to the specialized skill that does the work
- Verify the upgrade didn't break anything

You are the persistent service layer. After /domain-build creates the stack, you are the "always-on" mode.

## 中斷恢復

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

1. **偵測狀態：** 搜尋 `upgrade-log.md` — 記錄了什麼被請求、什麼被派遣、什麼已完成
2. **恢復點：**
   - 如果 `upgrade-log.md` 存在 → 讀取，從最後一個 `pending` 或 `dispatched` 項目繼續
   - 如果有已分類但未處理的 feedback（Step 3 完成但 Step 4 未完成）→ 從執行階段繼續
   - 如果 git diff 顯示有未 commit 的升級改動 → 從 verify 階段繼續
3. **不重做：** 不重新收集已分類的 feedback、不重新派遣已完成的改動
4. **通知用戶：** 告知升級進度，確認繼續或重新開始

**Upgrade Log 格式（中斷時自動建立）：**
```
| Item | Type | Dispatch To | Status | Notes |
|------|------|------------|--------|-------|
| ... | A/B/C | /skill-edit | pending/done | |
```

---

## Phase 0: Context Discovery

### State
- Reads: `~/.prismstack/projects/{slug}/.prismstack/check-results.json`, `edit-log.jsonl`, `convert-log.jsonl` (what happened since last upgrade)
- Writes: `upgrade-log.jsonl` (append: timestamp, action, dispatched-to, result)
- Updates: `domain-config.json` → `last_upgrade` timestamp

自動搜尋上游產出和先前執行紀錄：

```bash
_SLUG=$(basename "$(git rev-parse --show-toplevel 2>/dev/null || pwd)")
_PROJECTS_DIR="${HOME}/.prismstack/projects/${_SLUG}"

# Search for recent /skill-check results
ls "${_PROJECTS_DIR}"/skill-check-*.md 2>/dev/null

# Search for recent /skill-edit commits
git log --oneline -10 --grep="skill-edit" 2>/dev/null

# Search for recent /source-convert additions
git log --oneline -10 --grep="source-convert" 2>/dev/null

# Search for prior upgrade logs
ls upgrade-log.md 2>/dev/null
```

如果找到先前的 skill-check 結果 → 摘要呈現，作為升級的起點參考。
如果找到先前的 upgrade-log → 讀取，告知用戶先前的升級進度。

---

## Entry: Mode Routing

Check if user provided a mode argument. If not, ask:

```
你今天帶了什麼？

1. feedback — 我有測試回饋要處理
2. upgrade — 我想改進某個 skill
3. listen — 我有些想法但還不確定
```

Route to the matching mode below.

---

## Mode 1: Feedback

### Step 1 — Collect

讀取 `shared/methodology/functional-test-guide.md` —
用真實任務測試 skill 效果的方法（結構 vs 功能的差異、測試迴圈、記錄格式）。

Ask the user:
- 什麼 worked？（繼續保持的）
- 什麼 didn't work？（需要修的）
- 什麼 was surprising？（意料之外的，好壞都算）

### Step 2 — Classify

For each feedback item, classify:

- **A類（自動修）：** 詞彙不對、artifact 格式不接、trigger 描述不準
  - These are mechanical fixes. Route to /skill-edit directly.
- **B類（討論後修）：** 判斷維度缺了、判斷方向錯了、互動節奏不對
  - These need discussion first. Present analysis, get user alignment, then dispatch.
- **C類（需要升級材料）：** gotchas 太淺、benchmark 不對、缺領域深度
  - These can't be fixed without new material. Add to upgrade backlog.

### Step 3 — Present & Confirm

**STOP GATE:** Present the classified list to user before acting.

```
回饋分類結果：

A類（自動修）：
  - [item] → /skill-edit [target]

B類（討論後修）：
  - [item] → 需要先討論 [what]

C類（需要升級材料）：
  - [item] → 加入升級待辦，需要 [what material]

確認後我開始處理 A類。B類我們逐項討論。
```

### Step 4 — Execute

- A items → dispatch to /skill-edit with specific instructions
- B items → discuss one by one → dispatch to appropriate skill
- C items → log to upgrade backlog, remind user what materials are needed

### Step 5 — Verify

Run the 3-question upgrade effect check (see references/upgrade-patterns.md).

---

## Mode 2: Upgrade

### Step 1 — Scope

Ask:
- 哪個 skill？
- 想改進什麼？

### Step 2 — Pattern Match

Read `references/upgrade-patterns.md`. Match user's need to a pattern:

| Need | Dispatch To |
|------|------------|
| Skill internals (sections, scoring, gotchas) | /skill-edit |
| External source (article, video, repo) | /source-convert |
| Automation / tool need | /tool-builder |
| Workflow change (ordering, connections) | /workflow-edit |
| Entirely new skill | /skill-gen |

If the need is ambiguous, use the Need Clarification Pattern from the reference.

### Step 3 — Dispatch

Route to the matched skill with clear instructions:
- What to change
- Why (user's stated reason)
- Constraints (don't break X, keep Y)

### Step 4 — Verify

**STOP GATE:** After dispatch completes, run the 3-question upgrade effect check:

### Upgrade Impact Score (3 questions, scored)
| Question | -1 (Worse) | 0 (No change) | +1 (Better) |
|----------|-----------|---------------|-------------|
| Workflow 更有用了嗎？ | Broke a connection | Same | New/stronger connection |
| 判斷比 baseline 更準了嗎？ | Less accurate | Same | More accurate (evidence required) |
| 有沒有破壞銜接？ | Yes, broke something | No side effects | Actually improved adjacent skills |

**Score range:** -3 to +3.
- +2 to +3: Excellent upgrade
- +1: Meaningful improvement
- 0: Neutral (consider if worth the change)
- Negative: Revert immediately

Present results to user.

---

## Mode 3: Listen

### Step 1 — Open Conversation

Help the user articulate what they need:
- 「你覺得哪裡最卡？」
- 「哪個 skill 最常用但最不滿意？」
- 「上次用的時候有沒有哪裡覺得怪怪的？」
- 「有沒有什麼事情你想做但現在做不到？」

### Step 2 — Translate

Turn vague feelings into specific observations:
- "覺得慢" → which step is slow? → specific skill or workflow gap
- "不夠好" → compared to what? → missing benchmark or gotcha
- "用不順" → where does it break? → workflow connection issue

### Step 3 — Route

Once the need is clear, route to either:
- **Feedback mode** — if it's about existing skill quality
- **Upgrade mode** — if it's about adding/changing capability

---

## Gotchas

1. **Claude tries to do everything itself instead of dispatching.** Always route to the specialized skill. You are a coordinator, not an implementer. If you catch yourself writing skill content directly, stop and dispatch.

2. **Claude loses track of multiple upgrades.** Maintain an upgrade log. After each session, summarize what was changed, what's pending, what needs materials.

3. **Builder 不主動說「你的 skill 不夠好」.** The user decides when to upgrade. You respond to their needs, you don't push upgrades on them. Provide perspective when asked, not unsolicited criticism.

4. **Don't confuse upgrade with rebuild.** If the user wants to change >50% of a skill, that might be a /skill-gen + replace, not a /skill-edit.

5. **Always check downstream impact.** A change to one skill can break the next skill in the workflow. The 3-question check exists for this reason.

---

## Completion

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

When done, report:

```
STATUS: DONE

Changes made:
- [list of changes with skill names]

Upgrade effect check:
1. Workflow: [result]
2. Judgment accuracy: [result]
3. Cross-skill connection: [result]

Pending (if any):
- [C-class items or deferred work]

建議下一步：
1. `/skill-check review {changed-skill}` — 驗證修改效果
```