Claude Code CLI 初體驗

前言

延續前一篇: Claude Code Desktop 初體驗, 這篇改在 Visual Studio 2026 的終端機, 使用 Claude Code CLI 操作同一個範例專案 20240118_ASPNetCore6Random.

內容包含: 常用的 / 指令, 用 /init 建立 CLAUDE.md, 建立第一個 Skill, 隔天回到原來的 session, permission mode 的選擇, 最後以「VS 2026 改程式, CLI 測試並 commit」作一次實戰演練. 整理如下, 供備忘之用.

說明:

• 標題標示 (Web) 的段落, 是在 claude.ai 網頁版請教的內容; 標示 (CLI) 的段落, 則是在 Claude Code CLI 實際操作的過程.
• 文中功能說明, 已對照官方文件及實機 (Claude Code v2.1.310) 作過校正.

一. 在 Visual Studio 2026 執行 Claude Code CLI

1. 打開 Terminal (檢視/終端)
2. 輸入 claude
3. 啟動後提示有更新, 先輸入 /exit 離開, 再重新執行 claude

二. 常用的 / 指令 (Web)

在 CLI 的輸入框打 /, 就會跳出完整的指令清單. 指令不少, 請 Claude 挑出新手最該先記住的, 依使用情境分組如下:

情境	指令	用途
每天都會用到	/help	列出所有可用指令, 忘記時打它就對了
	/clear	清空目前對話重新開始. 換一個不相關的任務前先清一下, 回應會更準, 也更省 token
	/exit	離開 Claude Code, 回到 PowerShell
	/status	查看目前狀態 (登入帳號, 模型, 版本等)
專案理解	/init	分析整個專案, 產生 CLAUDE.md, 記錄專案的架構, 慣例, 技術棧
	/context	查看目前對話用掉多少上下文 (token), 判斷是不是該 /clear 了
控制行為	/model	切換模型 (例如在 Sonnet / Opus 之間切換)
	/agents	管理子代理 (subagent)
	/permissions	查看 / 調整權限設定
外觀與設定	/theme	改配色主題
	/config	開啟設定

如果只先記三個, 建議是:

1. /init: 對專案跑一次, 一勞永逸讓 Claude 更懂你的 code.
2. /clear: 換不相關的任務時先清一下, 養成習慣.
3. /help: 其他忘了就查.

另外兩個好用的小地方:

• 輸入框打 @ 可以指定檔案 (會跳出檔案清單), 想讓 Claude 專注看某個檔案時, 比讓它自己去猜更準.
• 版控其實不太需要記指令. Claude Code 很懂 Git, 直接用自然語言說「幫我把這次修改 commit, 寫一個清楚的訊息」就可以了.

三. 用 /init 產生 CLAUDE.md (CLI)

執行 /init

在專案目錄執行 /init, Claude 讀過程式碼和 README 後, 在專案根目錄寫出一份 36 行的 CLAUDE.md, 大約花了 33 秒.

● Write(CLAUDE.md)
Wrote 36 lines to CLAUDE.md

I created CLAUDE.md in the repo root. I wrote it from reading the code and README; I didn't build the project or run the tests or commands it lists.

值得一提的是, Claude 主動說明了它「沒有實際建置或執行測試」, 也就是 CLAUDE.md 裡列出的指令還沒被驗證過.

改寫成台灣正體中文

產生的內容是英文, 所以接著請它改寫:

請用台灣正體中文改寫 Claude.md

改寫後有兩點說明:

• 保留英文的部分: 開頭那段 This file provides guidance to Claude Code (claude.ai/code) ... 是 /init 產生的範本開頭 (並非必要格式), 以及指令, 檔名, 類別名稱都維持原樣.
• 修改的內容: Moq 版本的說明改為「README 中提及的安全性議題」, 與 README 原文一致.

commit CLAUDE.md

這時輸入框出現了灰字的建議提示「請幫我 commit CLAUDE.md」, 剛好就是接下來想下的指令. 按 Tab 鍵或向右方向鍵 (→) 就能把建議放進輸入框, 再按 Enter 送出即可.

commit 時 Git 出現了一個提示:

這個檔案目前用的是 LF 換行. 因為 .gitattributes 設定了 text=auto, 下次 Git 改寫這個檔案時會換成 CRLF. 這不影響這次的 commit.

換行統一為 CRLF, 並加上 BOM

既然是在 Windows 環境, 希望換行一律用 CRLF, 而且以後都照這個規則:

因為是在 Windows 環境, 請將 Claude.md 的換行符號統一為 CrLf; 後續任何新增或修改, 一律採該規則. 請列入 Claude.md

Claude 處理後提醒: CLAUDE.md 本身沒有 BOM, 和規則中「原始碼檔案為 UTF-8 (含 BOM)」不一致. 於是再請它加上 BOM 並 commit.

過程中它又發現一個問題: 規則裡舉的轉換範例 sed -i 's/\r*$/\r/' <檔案>, 實際上 Git Bash 的 sed -i 可能會把 CR 去掉. 它建議改用 PowerShell 的寫法, 可以同時確保 CRLF 與 BOM. 同意後, 它更新了 CLAUDE.md 並 commit (e371879):

• 原本的 sed -i 範例改為 PowerShell 寫法, 可同時轉為 CRLF 並保留 UTF-8 BOM.
• 加註「請勿使用 Git Bash 的 sed -i, 它可能會把 CR 去掉」.

下圖是在檔案總管以 VS Code 開啟, 以及改寫完成的 CLAUDE.md:

四. CLAUDE.md 與 SKILL.md 有什麼不同? (Web)

跑完 /init 之後, 專案根目錄多了一份 CLAUDE.md. 接著很自然地想到另一個常聽到的名詞: SKILL.md. 兩者都是給 Claude 看的 Markdown 檔, 到底差在哪裡?

一句話來說: CLAUDE.md 是「專案說明書」, SKILL.md 是「技能說明書」. 前者告訴 Claude 現在在做哪個專案, 後者告訴 Claude 某件特定工作該怎麼做.

CLAUDE.md: 專案的背景知識

CLAUDE.md 記錄的是專案本身: 技術棧, 資料夾結構, 命名慣例, 建置指令, 團隊規矩等. 一個專案通常一份, 放在專案根目錄. 以這次的範例專案來說, /init 產生的就是「這是個樂透 (Lotto) 範例, 用 MSTest 測試, 以 Wrapper 模式包裝 Random」這類專案脈絡.

SKILL.md: 可重複的工作方法

SKILL.md 描述的是一套可重複的做法, 跟特定專案無關. 例如「怎麼產生合格的 Excel 檔」, 「怎麼依公司規範審閱合約」, 「團隊的部署步驟」. 每個 Skill 是一個資料夾, SKILL.md 是它的主檔, 寫明「什麼情況該用」以及「該怎麼做」.

關鍵差別: 何時被讀取

	CLAUDE.md	SKILL.md
載入時機	每次在該專案啟動 Claude Code 都會自動載入	平常只載入簡短描述, 任務符合時才載入完整內容
角色	常駐的背景知識	需要時才拿出來的作業程序

最好記的比喻是: CLAUDE.md 像新人報到時拿到的「公司手冊」, 一進來就該讀熟; SKILL.md 像工具櫃裡一份份的「標準作業程序 (SOP)」, 平常收著, 碰到對應的工作才抽出來照做.

SKILL.md 從哪裡來?

• Claude Code 內建: 例如 /code-review, /debug, /loop.
• 從 claude.ai 帳號同步: Anthropic 提供的文件類 skill, 例如 xlsx, pdf, docx, pptx (需以 claude.ai 帳號登入).
• 團隊或組織提供.
• 自己建立: 放在專案的 .claude/skills/<名稱>/SKILL.md.

在 CLI 輸入 /skills, 就能看到目前載入了哪些 skill 及其來源. 下圖是筆者的環境: 標示「claude.ai sync」的是從帳號同步來的, 標示「project」的 test-and-commit 則是後面自行建立的 (見 六.).

小插曲: Desktop App 的 Settings > Skills 頁面並不會列出 pdf, xlsx 這幾個文件類 skill, 一度以為沒有同步. 在 CLI 用 /skills 確認後, 它們都在, 使用上沒有影響.

五. 什麼是「流程」? 寫一份 SKILL.md (Web)

知道 Skill 是「可重複的工作方法」之後, 還是不太確定什麼樣的事才算「流程」, 於是請 Claude 舉例.

流程, 就是你一直重複交代的事

「流程」就是一組每次都照同樣步驟做的固定工作. 判斷標準很簡單: 如果某件事會「照同一套步驟, 做很多次」, 它就是一個流程, 適合寫成 Skill 讓 Claude 每次自動照辦.

回頭看, 這幾天其實一直在重複同一套動作:

1. 讓 Claude 改一個東西
2. 跑建置和測試 (dotnet build / dotnet test), 確認沒壞
3. 確認通過後, 逐項 commit, commit 訊息用台灣正體中文
4. 不要自動 push, 何時 push 自己決定

這套「改 → 測 → 逐項 commit → 不 push」就是一個流程. 每次都這樣做, 但每次都要重新交代一遍. 寫成 Skill 之後, Claude 就會自動照這套規矩走.

SKILL.md 長什麼樣

以上面的流程為例, SKILL.md 大概長這樣:

---
name: safe-commit-flow
description: 當使用者要求修改程式碼並提交時使用。負責在修改後執行建置與測試，
             確認通過才逐項 commit，commit 訊息用台灣正體中文，且不自動 push。
---

# 安全提交流程

當使用者要求修改程式碼後,請依下列步驟進行:

1. 完成使用者要求的修改。
2. 執行 `dotnet build` 與 `dotnet test`,確認 0 錯誤、測試全數通過。
   若有失敗,先回報重點給使用者,不要繼續 commit。
3. 測試通過後,將這次修改 commit。commit 訊息用台灣正體中文,
   清楚描述這次改了什麼。
4. 一次只 commit 這一項,不要把多項變更混在一起。
5. 不要自動 push,commit 完停下來等使用者決定。

看懂兩個部分就夠了:

• 上面的 description (最關鍵): 決定這個技能「什麼時候會被叫出來」. 當要求符合這段描述 (例如「幫我改這段程式碼並提交」), Claude 就會自動載入這份 SKILL.md 照做. 所以描述要寫清楚「什麼情況用」.
• 下面的步驟: 就是平常口頭交代的那套規矩, 寫成固定清單.

平常這份 SKILL.md 收著不佔資源, 用得上時才抽出來照辦. Skill 的價值就在這裡: 把重複講的規矩, 變成一次設定, 之後自動執行.

其他適合寫成 Skill 的流程

• 報表產生規範: 公司的 RDLC/EMF 報表, 如果每次都有固定的產生與檢查步驟.
• 新增功能的慣例: 例如每寫一個 Controller, 就要配一組單元測試, 命名用 Test_方法_情境_預期.
• 編碼檢查: 踩過 Big5/UTF-8 的坑之後, 可以規定「新增 .cs 檔時一律存成 UTF-8 with BOM」.

什麼時候該動手寫? 建議的做法是: 先讓概念沉澱, 等發現某件事已經跟 Claude 交代第三, 四次時, 就是把它寫成 Skill 的最好時機.

六. 請 CLI 建立第一個 Skill (CLI)

既然「改 → 測 → 逐項 commit → 不 push」已經重複好幾次了, 就直接請 CLI 建立:

幫我把『改程式碼後要先測試、用台灣正體中文逐項 commit、不要 push』這套流程建立成一個 skill

Claude 把它建成專案層級的 skill, 放在 .claude/skills/test-and-commit/SKILL.md, 流程內容如下:

1. 確認檔案格式: 換行為 CRLF, 原始碼為 UTF-8 含 BOM, 不符合時用 PowerShell 轉換.
2. 建置並測試: 執行 dotnet build 與 dotnet test, 有任何失敗就不 commit, 並回報錯誤. 只改文件時可略過測試, 但要說明; 改了 README.md 時, 會提醒同步更新 README.html.
3. 逐項 commit: 依邏輯上獨立的修改分組, 每組只 git add 自己的檔案. 訊息以台灣正體中文撰寫, 沿用本 repo 的 1.. 2.. 條列風格.
4. 不 push: 明確禁止 git push.
5. 回報: 列出測試結果, commit 清單, 並說明尚未 push.

幾個值得注意的地方:

• 觸發方式: 程式碼修改完成, 或說「測試並 commit」, 「收尾」時會自動套用, 也可以直接輸入 /test-and-commit.
• 載入時機: Claude Code 會監看 skill 目錄, 新增或修改 skill 通常在同一個 session 內就會生效. 但因為 .claude/skills/ 是這個 session 中才新建的資料夾, 需要執行 /reload-skills 才會載入 (重新啟動 Claude Code 也可以).
• 例外: SKILL.md 不加 BOM. SKILL.md 開頭的 YAML 設定區塊 (---) 必須在檔案第一行, 前面若有 BOM, 可能導致 skill 無法辨識. Claude 也把這個例外寫進了 skill 的步驟 1.

確認沒問題後, 再請它把 .claude/ 也 commit 進 repo, 讓團隊可以共用. 到這裡, master 上累積了 4 個還沒 push 的 commit:

d0e233a 加入專案 skill: test-and-commit, 定義修改程式碼後的收尾流程 (...)
e371879 修訂 CLAUDE.md: 將 CRLF 轉換範例由 Git Bash 的 sed -i 改為 PowerShell 寫法 (...)
b8c8319 修訂 CLAUDE.md: 1.. 換行符號統一為 CRLF, 並加上 UTF-8 BOM. 2.. (...)
8386c2f 加入 CLAUDE.md, 提供 Claude Code 在此專案中的指引 (...)

七. 隔天如何回到原來的 session (Web)

下班關機, 隔天要怎麼接著昨天的對話繼續? 答案是 claude --resume.

用 /exit 離開時, CLI 會顯示可以回到這個 session 的指令:

Resume this session with:
claude --resume cbfe597d-71a5-4afa-a20d-fe0000b79b9d

如果沒記下 session ID, 直接執行 claude --resume 會開啟 session 清單, 用上 / 下方向鍵選擇即可. 筆者的清單裡同時出現了 Claude Code Desktop 及 CLI 的 session:

八. auto mode 與 permission mode (Web)

CLI 底部常看到 auto mode on (shift+tab to cycle), 這是什麼意思?

什麼是 Auto mode?

Auto mode 讓 Claude 不用每次都停下來問你同意, 就能連續執行動作. 但它不是放任亂做: 每個動作實際執行前, 會有一個獨立的分類器模型先審查, 擋掉超出請求範圍, 目標無法辨識, 或看起來被惡意內容驅動的動作. 它降低的是「每一步都要點同意」的麻煩, 但不保證程式碼正確, 仍需要自己審閱.

四種 permission mode

在 CLI 裡按 Shift+Tab 可以循環切換模式, 順序為 Manual → Accept Edits → Plan → Auto, 底部狀態列會顯示目前的模式 (例如 accept edits on, auto mode on). v2.1.283 起, Auto 是互動式 session 的預設模式.

模式	不經詢問能做什麼	適用情境
Manual (手動)	只有讀取; 改檔, 跑指令都先問你	最謹慎, 處理重要或不熟的專案
Plan (計畫)	只讀不改, 研究並提出計畫但不動原始碼; 可使用 Auto 時也會執行經分類器核准的指令	大改動前先探勘, 先看藍圖
Accept Edits	自動建立 / 修改檔案, 並自動執行工作目錄內的 mkdir, touch, rm, rmdir, mv, cp, sed	信任這個任務, 想連續改多檔又不想一直點同意
Auto (預設)	大部分動作自動執行 (包含 push 到目前 repo), 分類器把關	最放手, 適合會事後統一審閱的迭代

另外還有兩種:

• bypassPermissions: 完全跳過檢查, 風險最高, 官方建議只在隔離的容器或 VM 中使用.
• dontAsk: 不在 Shift+Tab 循環中, 只能以 --permission-mode dontAsk 啟動.

判斷原則一句話: 任務越重要, 越不熟 → 往 Manual 靠; 任務越瑣碎, 越會事後審閱 → 往 Auto 靠. 而且專案在 Git 版控下, 真改壞了也都能還原.

九. 這個專案該用哪個模式? (Web)

針對「改 code → 測試 → 逐項 commit → 不 push」這套習慣, 請 Claude 建議平常該固定用哪個模式. 結論是兩段式用法:

第一段 (規劃): Plan mode

筆者的習慣是改東西前先看清楚要改什麼. Plan mode 只讀不改, 讓 Claude 先研究, 提出計畫供審閱, 看懂, 同意了, 它才往下動手. 這對「謹慎, 要掌控」的風格最合拍.

第二段 (實作): Accept Edits

計畫批准後進入實際改 code. 這階段用 Accept Edits 最順: 它會自動套用檔案編輯, 不用每個 diff 都點一次同意, 而 push 仍會先詢問. 要留意的是, 它也會自動執行工作目錄內的 rm, sed, mv 等檔案指令.

為什麼不直接用 Auto? Auto 適合「事後統一審閱」的大批次迭代. 但筆者的習慣是逐項, 逐步確認, 跟 Auto「先衝, 最後再看」的節奏不太合. 等哪天更熟, 想加速, 再往 Auto 靠也不遲.

「不 push」: 規矩寫進 CLAUDE.md, 強制交給權限規則

這裡有個容易誤會的地方. permission mode 管的是「要不要先問你」: 在 Manual 與 Accept Edits 下, push 會先詢問; 但在 Auto 模式 (也就是預設模式) 下, push 到目前 repo 的任何分支, 預設不會先問你. 所以要分兩層處理.

第一層: 把規矩寫進 CLAUDE.md, 讓 Claude 知道規矩. 例如:

- 修改程式碼後,先執行 build 與 test,通過才 commit。
- commit 用台灣正體中文、逐項提交,一次只提交一項。
- 不要自動 push,commit 後停下來等我決定。

第二層: 用權限規則強制把關. CLAUDE.md 是給 Claude 參考的背景資訊, 不具強制力. 要確實擋住 push, 在專案的 .claude/settings.json 加入權限規則, 讓 push 前一定先詢問:

{
  "permissions": {
    "ask": ["Bash(git push *)"]
  }
}

若要完全禁止, 改用 "deny".

一句話總結: Plan 起手規劃 → 批准後切 Accept Edits 實作 → 規矩寫進 CLAUDE.md, 再用權限規則擋住 push. 模式負責順手, CLAUDE.md 負責說明規矩, 權限規則負責把關.

規則已經在 SKILL.md 了, CLAUDE.md 還要再改嗎?

回頭檢查了一下: 這套規矩其實已經同時落在兩個地方.

• SKILL.md (test-and-commit): 把整套收尾流程寫成完整步驟, 包含格式確認, build + test, 逐項 commit, 不 push, 回報. 這是詳細的執行手冊.
• CLAUDE.md: 在「慣例」段也有對應的核心規則 (UTF-8 含 BOM, CRLF, 台灣正體中文 commit). 這是常駐的專案背景.

所以 commit 流程不用再寫進 CLAUDE.md. 兩份並存也不是重複累贅, 因為載入時機不同, 角色互補:

• CLAUDE.md 像「公司守則」: 每次啟動都讀, 適合放「永遠成立的底線」, 例如原始碼一律 UTF-8 含 BOM, 換行一律 CRLF.
• SKILL.md 像「提交作業的 SOP」: 符合情境才叫出來. 它的 description 寫的是「當程式碼修改完成, 或使用者要求『測試並 commit』『收尾』時使用」, 平常不佔空間.

兩份檔案裡編碼 / CRLF 的規則有部分重疊, 這反而是好事: SKILL.md 不一定每次都被載入, 底線也留在常駐的 CLAUDE.md, 等於多一層保險. 原則是: 「永遠適用的底線」留 CLAUDE.md, 「某情境的操作步驟」放 SKILL.md.

十. 實戰: VS 2026 改程式, CLI 測試並 commit

演練規劃 (Web)

接下來要驗證的, 是 skill 能不能在實戰中被正確觸發. 預計的方式是: 在 VS 2026 改幾行程式, 然後在 CLI 下達「幫我測試並 commit」. 演練步驟如下:

1. 在 VS 2026 改幾行程式: 挑一個安全, 不會改壞邏輯的小改動, 例如補一段 XML 文件註解. 改完記得存檔 (Ctrl+S). 如果 VS 存檔的編碼不符合規則, skill 的步驟 1 應該會抓出來並轉換, 正好順便測到格式檢查.
2. 切到 Claude CLI 下達指令: 在 VS 2026 的終端機輸入「幫我測試並 commit」.
3. 觀察 skill 有沒有被觸發: 預期會依序看到確認檔案格式 → dotnet build / dotnet test → 檢視變更並逐項 commit → 不 push, 回報結果.

權限模式建議用 Accept Edits, 或讓關鍵動作先詢問確認. 以驗證為目的, 慢一點, 看清楚每一步反而好.

判斷演練成不成功的標準:

• ✅ skill 有被自動觸發 (照 SKILL.md 的步驟做, 而不是用一般方式隨意 commit) → 代表 description 寫得夠好
• ✅ commit 是逐項, 台灣正體中文, 而且沒有 push → 代表步驟被正確執行
• ⚠️ 如果沒照 skill 跑 (例如直接 git add -A 一次全 commit, 或訊息不是中文) → 要回頭調整 description 的觸發條件

實際操作 (CLI)

先在 VS 2026 對 LottoController 加上 XML 文件註解:

/// <summary>
/// 提供樂透號碼產生頁面的 MVC 控制器。
/// </summary>
/// <remarks>透過 ILottoService 產生號碼資料，並在 Index 動作中回傳對應檢視。</remarks>
public class LottoController : Controller
{

接著在 CLI 輸入:

幫我測試並 commit

CLI 的回覆:

建置與測試:
- 建置: 成功, 0 個錯誤. 有 2 個警告, 內容是 net6.0 已不受官方支援.
- 測試 (正常執行): 中止, 錯誤是找不到 Microsoft.NETCore.App 6.0.0. 這台電腦只裝了 10.0.13.
- 測試 (改在 .NET 10 上執行): 我另外加上 DOTNET_ROLL_FORWARD=Major 讓測試改用 .NET 10 執行, 結果 2 個全數通過. 這不是在專案指定的 .NET 6 上測的, 所以不算完全符合「測試通過」.

請問要怎麼處理?
1. 接受 .NET 10 上的測試結果, 直接 commit. 這次只改註解, 風險很低. 預計的 commit 訊息為: 為 LottoController 加入 XML 文件註解, 說明控制器用途及與 ILottoService 的關係
2. 先安裝 .NET 6 runtime 再重測. 可從 https://aka.ms/dotnet-core-applaunch?framework=Microsoft.NETCore.App&framework_version=6.0.0&arch=x64&rid=win-x64&os=win10 下載.
3. 把「沒有 .NET 6 時改用 DOTNET_ROLL_FORWARD=Major 測試」寫進 skill 與 CLAUDE.md, 之後遇到同樣狀況就照這個做.

這次只改了註解, 選擇 1, 直接 commit.

接著還是把選項 3 也做了, 讓之後遇到同樣狀況時不用再問:

把 DOTNET_ROLL_FORWARD 的做法寫進 skill 和 CLAUDE.md

• CLAUDE.md: 在「常用指令」區段後加了說明. 本機沒有 .NET 6 runtime 時, 改用 DOTNET_ROLL_FORWARD=Major dotnet test ASPNetCore6Random.sln 執行測試, 並註明這樣測的是較新版 runtime, 不是 .NET 6, 回報時要說明.
• SKILL.md 步驟 2: 測試因找不到 .NET 6 runtime 而中止時, 自動改用 roll-forward 重跑, 結果可作為測試依據; 回報時固定註明「本機無 .NET 6 runtime, 測試以 DOTNET_ROLL_FORWARD=Major 在 .NET <版本> 上執行」.

在 VS 2026 的 Git 記錄可以看到這次新增的兩個 commit:

結論

這次跨過了從「使用工具」到「打造自己的工作流」的門檻: 以自建的 test-and-commit skill, 完成第一次完整的「開發 → 測試 → 提交」實戰演練.

回顧整個演練:

1. 在 VS 2026 對 LottoController 加入 XML 文件註解 (刻意選零風險的小改動).
2. 在 CLI 下達「幫我測試並 commit」, 驗證自建的 skill 能否被正確觸發.
3. skill 依步驟建置與測試: 建置成功但有 net6.0 已不受支援的警告; 本機沒有 .NET 6 runtime, 測試正常執行會中止; 加上 DOTNET_ROLL_FORWARD=Major 改在 .NET 10 上執行, 2 個測試全數通過.
4. Claude 指出這並非在專案指定的 .NET 6 上測試, 嚴格說不算完全符合「測試通過」, 並列出三個選項交由筆者決定.
5. 本次只新增註解, 風險極低, 選擇直接 commit.

三個重點收穫:

一, skill 觸發驗證成功. 自建的 test-and-commit 能在「幫我測試並 commit」時被正確叫出並依步驟執行, 證明 SKILL.md 的 description 寫得夠精準. 這是這次最核心的成果.

二, 流程的真正價值在「遇到意外時的行為」. 測試撞到環境問題時, skill 沒有硬幹, 也沒有亂 commit, 而是停下來把狀況與選項攤開. 工具負責把關, 但關鍵決定仍在使用者手上.

三, 留下一個待處理的環境事實. 本機沒有 .NET 6 runtime, 而專案指定 net6.0, 之後每次測試都會遇到. 目前以 DOTNET_ROLL_FORWARD=Major 繞過, 這個做法已寫進 SKILL.md 與 CLAUDE.md; 若要在 .NET 6 上實測, 需另行安裝 .NET 6 runtime.

參考文件

• [1] (官方文件) Claude Code: Advanced setup
• [2] (官方文件) Claude Code: Permission modes
• [3] (官方文件) Claude Code: Skills
• [4] (官方文件) Claude Code: How Claude remembers your project (CLAUDE.md)
• [5] (官方文件) Claude Code: Manage sessions