如何調教 Claude Code：Status Line、CLAUDE.md、自訂 Skill 配置筆記・亮點創研 LuMakes

Claude Code 是我目前主要的開發工具，用了一段時間之後發現，預設的狀態其實只發揮了它一半的能力。透過 Status Line、CLAUDE.md 專案指令跟自訂 Skill，可以把整個開發體驗拉到完全不同的層次。這篇會是一個長期更新的筆記，把我覺得值得分享的設定跟技巧陸續整理進來。

先看我目前的 Claude Code 長什麼樣子：底部三行即時顯示模型、專案分支、Session / Weekly 剩餘用量跟上下文窗口。圓點圖示一目瞭然，Weekly 超量還會自動變紅色警告。這只是其中一個設定，後面會一個一個拆開來聊。

Status Line：即時掌握使用狀態

Claude Code 底部有一條狀態列叫 Status Line，預設是關的。開啟之後，它會定期把當前狀態以 JSON 格式丟給你指定的腳本，腳本處理完輸出文字，就會顯示在畫面底部。

整個設定分三步：寫腳本、給權限、改設定檔。

建立腳本

先在 ~/.claude/ 底下建立一個 statusline.sh：

~/.claude/statusline.sh

#!/usr/bin/env bash
input=$(cat)

RESET="\033[0m"
RED="\033[31m"
DIM="\033[2m"
GREEN="\033[32m"

# Helper: print absolute reset time (e.g. "14:30")
format_reset() {
  date -r "$1" "+%H:%M" 2>/dev/null || date -d "@$1" "+%H:%M" 2>/dev/null
}

# Session bar: green ▄ = remaining, dim ▄ = used
session_bar() {
  local remain=$1 total=$2 bar="" i
  for (( i=0; i<total; i++ )); do
    if [ "$i" -lt "$remain" ]; then
      bar="${bar}${GREEN}▄${RESET}"
    else
      bar="${bar}${DIM}▄${RESET}"
    fi
  done
  printf "%s" "$bar"
}

# Weekly bar: green ▄ = remaining, │ = pace line, dim ▄ = used
# Over-pace: ▄ between remain and │ turns red
weekly_bar() {
  local remain=$1 pace=$2 total=$3 bar="" i
  local over=0
  [ "$remain" -lt "$pace" ] && over=1
  for (( i=0; i<total; i++ )); do
    if [ "$i" -eq "$pace" ]; then
      [ "$over" -eq 1 ] && bar="${bar}${RED}│${RESET}" || bar="${bar}│"
    elif [ "$i" -lt "$remain" ]; then
      bar="${bar}${GREEN}▄${RESET}"
    else
      if [ "$over" -eq 1 ] && [ "$i" -lt "$pace" ]; then
        bar="${bar}${RED}▄${RESET}"
      else
        bar="${bar}${DIM}▄${RESET}"
      fi
    fi
  done
  printf "%s" "$bar"
}

# Data extraction
model=$(echo "$input" | jq -r '.model.display_name // empty')
cwd=$(echo "$input" | jq -r '.cwd // empty')
branch=$(git --git-dir="$cwd/.git" --work-tree="$cwd" branch --show-current 2>/dev/null)
[ -n "$cwd" ] && project=$(basename "$cwd")

five_pct=$(echo "$input" | jq -r '.rate_limits.five_hour.used_percentage // empty')
five_rst=$(echo "$input" | jq -r '.rate_limits.five_hour.resets_at // empty')
week_pct=$(echo "$input" | jq -r '.rate_limits.seven_day.used_percentage // empty')
week_rst=$(echo "$input" | jq -r '.rate_limits.seven_day.resets_at // empty')
ctx_pct=$(echo "$input" | jq -r '.context_window.used_percentage // empty')
BAR_W=10

# Line 1: Model | Folder(branch)
line1=""
[ -n "$model" ] && line1="$model"
if [ -n "$project" ]; then
  proj="$project"
  [ -n "$branch" ] && proj="$proj($branch)"
  [ -n "$line1" ] && line1="$line1 | $proj" || line1="$proj"
fi

# Line 2: Session ▄▄▄▄▄▄▄▄▄▄ 54% left (14:30) · ctx 12%
line2=""
if [ -n "$five_pct" ]; then
  pct_int=$(printf '%.0f' "$five_pct")
  remain=$(( 100 - pct_int ))
  [ "$remain" -lt 0 ] && remain=0
  remain_count=$(( (remain * BAR_W + 50) / 100 ))
  [ "$remain_count" -gt "$BAR_W" ] && remain_count=$BAR_W
  bar=$(session_bar "$remain_count" "$BAR_W")
  reset_str=""
  [ -n "$five_rst" ] && reset_str=" ($(format_reset "$five_rst"))"
  line2=$(printf "Session: %s %d%% left%s" "$bar" "$remain" "$reset_str")
  if [ -n "$ctx_pct" ]; then
    ctx_int=$(printf '%.0f' "$ctx_pct")
    line2="$line2 · ctx ${ctx_int}%"
  fi
fi

# Line 3: Weekly ▄▄│▄▄▄▄▄▄▄▄ 21% left (5/7)
line3=""
if [ -n "$week_pct" ]; then
  week_pct_int=$(printf '%.0f' "$week_pct")
  week_remain=$(( 100 - week_pct_int ))
  [ "$week_remain" -lt 0 ] && week_remain=0
  remain_count=$(( (week_remain * BAR_W + 50) / 100 ))
  [ "$remain_count" -gt "$BAR_W" ] && remain_count=$BAR_W
  now=$(date +%s)
  if [ -n "$week_rst" ]; then
    window_start=$(( week_rst - 7 * 86400 ))
    elapsed=$(( now - window_start ))
    window_len=$(( week_rst - window_start ))
    [ "$window_len" -gt 0 ] && time_pct=$(( elapsed * 100 / window_len )) || time_pct=0
    day_in_window=$(( elapsed / 86400 + 1 ))
    [ "$day_in_window" -gt 7 ] && day_in_window=7
    [ "$day_in_window" -lt 1 ] && day_in_window=1
  else
    dow=$(date +%u)
    time_pct=$(( (dow - 1) * 100 / 7 ))
    day_in_window=$dow
  fi
  [ "$time_pct" -lt 0 ] && time_pct=0
  [ "$time_pct" -gt 100 ] && time_pct=100
  pace_remain=$(( 100 - time_pct ))
  pace_pos=$(( (pace_remain * BAR_W + 50) / 100 ))
  [ "$pace_pos" -ge "$BAR_W" ] && pace_pos=$(( BAR_W - 1 ))
  [ "$pace_pos" -lt 0 ] && pace_pos=0
  bar=$(weekly_bar "$remain_count" "$pace_pos" $(( BAR_W + 1 )))
  line3=$(printf "Weekly:  %s %d%% left (%d/7)" "$bar" "$week_remain" "$day_in_window")
fi

# Output
output=""
append() { [ -n "$output" ] && output="$output\n$1" || output="$1"; }
[ -n "$line1" ] && append "$line1"
[ -n "$line2" ] && append "$line2"
[ -n "$line3" ] && append "$line3"
[ -n "$output" ] && printf "%b" "$output"

進度條用半高方塊 ▄，只佔下半行，上下不會黏在一起。綠色 ▄ 代表剩餘、淡色 ▄ 代表已用、│ 是每日平均配速線。這個腳本輸出三行：

第一行：模型名稱、專案資料夾跟 Git 分支
第二行：Session 剩餘用量，進度條從左到右由剩餘（綠色）到已用（淡色），括號內是下次重置的時間點，最後附上上下文窗口使用率
第三行：Weekly 剩餘用量，進度條中間有一條配速線（│）標示每日平均預算的位置。正常情況下已用不會超過 │；一旦超過，超出的 ▄ 跟 │ 會變紅色，一眼就知道超速了

如果你覺得哪邊不夠好或想加新欄位，直接把腳本貼給 Claude Code 說「幫我改」就行了，它看得懂整個結構。

啟用設定

給腳本執行權限，然後在 ~/.claude/settings.json 加上設定：

chmod +x ~/.claude/statusline.sh

~/.claude/settings.json

{
  "statusLine": {
    "type": "command",
    "command": "bash ~/.claude/statusline.sh",
    "padding": 0
  }
}

padding 設成 0 讓狀態列更緊湊。設定完重啟 Claude Code 就會生效。

懶人指令

如果你不想手動建檔，直接把下面這段貼進 Claude Code，它會幫你一次搞定：

幫我設定 Claude Code Status Line。建立 ~/.claude/statusline.sh 並在 ~/.claude/settings.json 加上 statusLine 設定。

需求：
- 第一行：模型名稱 | 資料夾(分支)
- 第二行：Session 剩餘用量，用半高方塊 ▄ 畫進度條（綠色=剩餘在左，dim淡色=已用在右），括號內顯示下次重置時間點（HH:MM 格式），最後附上 ctx 上下文窗口使用百分比
- 第三行：Weekly 剩餘用量，同樣用半高方塊 ▄ 畫進度條，中間加一條 │ 配速線標示每日平均預算位置，用量超過配速線時超出的 ▄ 跟 │ 變紅色，括號內顯示目前第幾天（如 4/7）

CLAUDE.md：讓 AI 讀懂你的專案

CLAUDE.md 是 Claude Code 最核心的客製化機制。它是一個放在專案裡的 Markdown 檔案，每次啟動 session 都會自動載入，等於是你預先寫好的一份「專案說明書」——技術棧、程式碼風格、地雷清單，全部寫在這裡面，Claude 就不會每次都從零開始猜。

沒有它會怎樣

沒有 CLAUDE.md 的話，每次開新 session 都要重新跟 Claude 解釋一次專案脈絡。比如「我們用 Tailwind v4 不是 v3」「commit message 要用英文」「不要加 emoji」這些，講一次兩次還好，講十次就很煩。更麻煩的是，Claude 可能會用舊版的 API 寫法、把檔案建到錯的地方、或是生出跟專案風格完全不搭的程式碼。CLAUDE.md 就是為了解決這個問題——寫一次，每次都自動套用。

層級結構

CLAUDE.md 不只能放在專案根目錄，它支援多層結構，從全域到局部都能覆蓋：

層級	路徑	用途
全域	`~/.claude/CLAUDE.md`	個人偏好，適用所有專案
專案	`./CLAUDE.md`	團隊共用規則，commit 到 git
局部	`./CLAUDE.local.md`	個人的專案設定，加進 .gitignore

Claude 啟動時會從工作目錄往上走，把每一層的 CLAUDE.md 都載入。越具體的層級越後面讀取，所以局部規則可以覆寫全域規則。子目錄的 CLAUDE.md 則是在 Claude 讀取該目錄檔案時才會動態載入，不會一開始就全部吃進去。

我會放什麼進去

以我自己的專案為例，CLAUDE.md 裡面大概會涵蓋這些：

技術棧：框架版本、樣式方案、UI 元件庫，讓 Claude 生成的程式碼跟專案一致
常用指令：npm run dev、npm run build 這類，Claude 需要跑指令的時候不用猜
專案結構：哪個資料夾放什麼，避免 Claude 把檔案建到錯的地方
寫作風格：如果專案有內容產出（像我的文章區），口吻、用詞、格式規範都可以定義
Commit 規範：prefix 用什麼、語言用英文還是中文、要不要加 Co-Authored-By
地雷清單：容易搞混的設定、特殊的樣式行為、不能動的檔案

CLAUDE.md（節錄）

## 技術棧

- **框架**：Astro 5（SSG）+ React（互動元件）
- **樣式**：Tailwind CSS v4（透過 @tailwindcss/vite 整合）
- **部署**：Cloudflare Pages

## 注意事項

- toolbox 頁面的 inline code 樣式是程式碼風格（灰底紅字），
  其他頁面是 highlight 風格（主題色底線）
- H2 區塊會被 JS 拆成獨立卡片，每個 H2 是一張卡片
- 圖片品質設定為 90（astro.config.mjs）

寫好 CLAUDE.md 的關鍵

好的 CLAUDE.md 像是你知道自己明天會失憶時留給自己的筆記，而不是寫給新人的入職文件。

只寫 Claude 容易搞錯的事：不用把整份技術文件貼進去，重點是那些 Claude 猜不到或容易搞混的部分。Claude 一次大約只能可靠地執行 150-200 條指令，系統提示已佔約 50 條，你加的每一條都在跟其他指令競爭注意力，每個 CLAUDE.md 盡量控制在 200 行以內
規則要具體可驗證：「寫好一點」沒用，「用『跟』不用『與』，不用 emoji」才有用
適時更新：專案在演進，CLAUDE.md 也要跟著改，過時的規則比沒有規則更危險。我的經驗法則是：每次發現自己糾正 Claude 同一件事兩次，就該把它寫進 CLAUDE.md
善用 import：如果規則太多，可以用 @path/to/file 語法引入其他檔案，或是把細節拆到 .claude/rules/ 目錄下，還能用 paths frontmatter 限定特定檔案路徑才載入

CLAUDE.md 裡的 HTML 註解（<!— —>）會在載入前被移除，所以你可以放給人看的備註而不會消耗 token。

提示詞的日常技巧

CLAUDE.md 處理的是「不變的背景知識」，真正每天在對話裡決定效率的是提示詞品質。同樣一個需求，寫得好跟寫得爛，差距可能是 10 分鐘跟兩小時。整理幾個我自己實際有效的原則。

先思考，再輸入

大多數人拿到 Claude Code 後第一件事就是開始打字，但這往往是最大的錯誤。正確的做法是先進入規劃模式（Plan Mode），想清楚架構跟實作方向後再開始。花 5 分鐘規劃，可以省下後續數小時的除錯時間。

具體優於模糊

模糊的指令會讓 Claude 有太多自由發揮的空間，產出的結果通常不是你想要的。比較以下兩種提示詞的差異：

❌ 幫我建立一個身份驗證系統

✅ 使用現有的 User Model 建立 Email/Password 驗證，
   將 Session 儲存在 Redis 中並設定 24 小時過期，
   新增 Middleware 保護 /api/protected 底下的所有路由

說明為什麼，不只是做什麼

當你給 Claude 解釋指令背後的原因時，它的執行效果會明顯更好。例如「使用 TypeScript strict mode」是可以的，但「使用 TypeScript strict mode，因為我們遇過隱式 any 類型導致的線上 bug」更好。原因能幫助 Claude 在你沒預料到的情況下做出更好的判斷。

告訴它不要做什麼

Claude 有過度設計的傾向，特別容易產生額外的檔案跟不必要的抽象層。如果你要的是簡單的實作，明確告訴它：「保持簡單，不要加我沒要求的抽象層，盡量用一個檔案完成。」

管理上下文視窗

模型的上下文品質大約在使用 30% 左右就會開始下降，而不是 100%。幾個實用的做法：

一個對話只處理一個任務：不要在同一個對話裡又建功能又重構資料庫
善用外部記憶：讓 Claude 把計畫跟進度寫到實際檔案裡（例如 SCRATCHPAD.md），這些內容會跨對話保留
適時清除重來：如果對話已經偏離或累積太多無關內容，直接 /clear 重新開始，比硬撐著繼續更好

卡住時換個方式

如果解釋了三遍 Claude 還是不理解，再解釋也沒用。這時應該：

清除對話，用全新的上下文重試
把複雜任務拆成更小的步驟
自己寫一個最小範例，讓 Claude 照著模式去做
換個角度重新描述問題

輸出源自於輸入。如果輸出結果不好，問題幾乎都在輸入端。

精選 Skill：一個指令搞定重複工作

Skill 是 Claude Code 的自訂指令系統。你把一套完整的指令寫成 Markdown 檔案，之後只要在對話中打 /skill-name 就能一鍵觸發。比起每次都要跟 Claude 解釋一遍「幫我 commit 然後 push」「幫我檢查剛才改的程式碼」，Skill 把這些溝通成本壓縮成一行指令。

什麼時候該包成 Skill

不是所有操作都適合包成 Skill。在介紹具體的 Skill 之前，先聊一下我的判斷標準：

重複頻率高：每天或每幾天就會做一次的操作
步驟固定：每次的流程幾乎一樣，不太需要因情境調整
溝通成本高：如果不用 Skill，每次都要打一大段指令跟 Claude 解釋

反過來說，如果某個操作每次的做法都不太一樣、需要很多判斷跟討論，那直接跟 Claude 對話反而更有效率，硬包成 Skill 只會綁手綁腳。

怎麼建立一個 Skill

每個 Skill 就是一個 Markdown 檔案，放在 ~/.claude/skills/{skill-name}/SKILL.md（全域）或 .claude/skills/{skill-name}/SKILL.md（專案層級）。檔案用 frontmatter 定義名稱跟描述，正文就是給 Claude 的指令。

~/.claude/skills/my-skill/SKILL.md

---
name: my-skill
description: 這個 skill 做什麼的一句話描述
---

# Skill 標題

## Instructions

你想要 Claude 執行的步驟...

Skill 還支援一些進階功能：用 $ARGUMENTS 接收參數（像 /fix-issue 123）、用 !`command` 在載入時動態注入 shell 指令的輸出、用 context: fork 在獨立的 subagent 裡執行避免污染主對話。不過大部分情境下，基本的結構就很夠用了。

Skill 有兩種觸發方式：手動輸入 /skill-name，或是讓 Claude 根據 description 自動判斷要不要觸發。如果你的 Skill 有副作用（像 commit、deploy），建議在 frontmatter 加上 disable-model-invocation: true，避免 Claude 自作主張。

開發類

/commit-generate：自動產生 commit 並推送

這是我用最頻繁的 Skill。改完程式碼之後直接打 /commit-generate，它會自動讀取 staged changes、判斷 commit type（feat / fix / refactor 等）、產生英文 commit message，然後直接 push 到 remote。

整個流程不用自己想 commit message、不用手動 push，特別適合那種改了一小段就想快速提交的節奏。

~/.claude/skills/commit-generate/SKILL.md（節錄）

## Instructions

1. **Read staged changes**
   - Run `git status` to check the current state
   - Run `git diff --cached` to see staged changes

2. **Generate commit message following these rules**
   - feat: New features or functionality
   - fix: Bug fixes or issue resolution
   - refactor: Code refactoring (no functionality change)
   - Write message in English, use present tense
   - Focus on WHAT and WHY, not HOW

3. **Create the commit and push to remote**

/simplify：寫完之後的第二雙眼睛

寫完一段比較複雜的邏輯之後，用 /simplify 讓 Claude 回頭審查剛才改過的程式碼。它會同時開三個 agent 掃描，檢查有沒有可以重用的邏輯、有沒有多餘的抽象、效能上有沒有明顯的問題，然後直接修正。

自己寫的時候容易陷入局部思維，讓 Claude 用全局視角掃一遍，常常能抓到一些自己沒注意到的地方。這個 Skill 是 Claude Code 內建的，不需要自己寫。

/frontend-design：生成有設計感的前端介面

需要快速做出一個頁面或元件的時候，/frontend-design 可以直接生成有設計感的前端程式碼。比起直接跟 Claude 說「幫我做一個登入頁面」，這個 Skill 內建了一套設計原則跟品質標準，產出的結果會更有質感，不會是那種一看就知道是 AI 生的 generic 風格。這個是透過 Plugin 安裝的，在 settings 裡面啟用就能用。

Awesome DESIGN.md：讓 AI 生出像樣的 UI

這個嚴格來說不是 Skill，但搭配 /frontend-design 一起用效果很好。

Awesome DESIGN.md 是一個社群整理的設計系統文件集合，裡面收錄了 58 個知名網站的 DESIGN.md——包括 Linear、Vercel、Stripe、Notion 這些設計水準公認很高的產品。

DESIGN.md 的概念很簡單：用 Markdown 把一個網站的設計系統寫成 AI 看得懂的格式，涵蓋色彩、字體、元件樣式、間距系統、響應式斷點等九個面向。你只要把某個網站的 DESIGN.md 丟進專案根目錄，然後跟 Claude 說「照這個風格做」，它就能生出跟那個設計系統一致的 UI，而不是每次都給你一個 generic 的預設風格。

我自己比較常參考的是 Linear 跟 Vercel 的 DESIGN.md，乾淨俐落的設計語言很適合開發工具類的介面。

/batch：大規模平行修改

當你需要對整個 codebase 做大範圍的修改（像是把所有元件從一個框架遷移到另一個），/batch 會用 git worktree 開出多個獨立的工作環境，平行處理不同的檔案。這個 Skill 適合那種「改動範圍大但每個檔案的改法類似」的情境，像是重命名、API 遷移、或是批量加上 TypeScript 型別。

文件類

/codeck：把資料夾變成一份簡報

如果你有一堆筆記、文件、數據或圖片，想快速整理成一份有結構的簡報，Codeck 可以幫你一鍵搞定。它會分析你指定資料夾裡的素材，自動產生一個完整的 HTML 簡報檔案，支援鍵盤導航、全螢幕、講者備註計時器，甚至還能匯出 PDF 跟 PPTX。

安裝方式：

npx skills add hiyeshu/codeck

裝完之後整個流程是這樣的：先打 /codeck 讓它分析素材，接著用 /codeck-outline 整理大綱，/codeck-design 產生視覺設計，最後用 /codeck-export 匯出成品。每一步都是獨立的 Skill，你可以在任何一步停下來手動調整。

比較特別的是它的設計邏輯不是套模板，而是根據你的內容結構去「對應」視覺形式——比如論證有三層，它就會用三段式的視覺節奏來呈現。產出的簡報比一般 AI 生成的投影片有質感不少。

找更多 Skill

上面介紹的只是冰山一角。社群已經有不少人在整理跟分享好用的 Skill，如果你想找靈感或是直接裝來用，可以看看這些資源：

資源	說明
Awesome Claude Code	社群維護的精選清單，涵蓋 Skill、Hook、Plugin 跟教學
Awesome Claude Skills	專門收錄 Skill 的策展清單
Claude Code Plugins Marketplace	社群市集，有評分跟安裝數，方便挑選

大部分社群 Skill 的安裝方式就是把檔案複製到 ~/.claude/skills/ 底下，結構跟前面介紹的一樣。挑選的時候建議先看一下 SKILL.md 的內容，確認指令邏輯符合你的需求再裝。

官方多帳號切換：用 CLAUDE_CONFIG_DIR

如果你跟我一樣訂了兩組 Claude 帳號——主力一個、備用一個，週用量爆掉的時候要無縫接上——現在我會建議直接用官方支援的 CLAUDE_CONFIG_DIR，不要再只靠切換 settings.json。

CLAUDE_CONFIG_DIR 的作用是指定 Claude Code 要讀哪一個設定目錄。預設是 ~/.claude，但你可以替備用帳號開一個獨立目錄，例如 ~/.claude-back。這樣設定檔、登入狀態、session history、plugin 都會跟主帳號分開，不需要登出主帳號，也不用手動改 JSON。

最簡單的做法是在 ~/.zshrc 加一個 alias function：

~/.zshrc

claude-back() {
  mkdir -p "$HOME/.claude-back"
  CLAUDE_CONFIG_DIR="$HOME/.claude-back" claude "$@"
}

存檔後重載 shell：

source ~/.zshrc

之後要開備用帳號就執行：

claude-back

第一次進入這個設定區時，在 Claude Code 裡跑 /login，登入你的備用帳號。之後 claude 還是走原本的 ~/.claude，claude-back 則固定走 ~/.claude-back。

如果你想把兩組帳號都明確命名，也可以寫成這樣：

claude-main() {
  CLAUDE_CONFIG_DIR="$HOME/.claude" claude "$@"
}

claude-back() {
  mkdir -p "$HOME/.claude-back"
  CLAUDE_CONFIG_DIR="$HOME/.claude-back" claude "$@"
}

如果你前面設定過 Status Line，備用帳號的 ~/.claude-back/settings.json 也可以沿用同一支腳本，例如 "command": "bash ~/.claude/statusline.sh"。這樣腳本放一份就好，兩組帳號各自保留自己的設定跟登入狀態。

Claude Code 環境變數文件

Amphetamine：放著跑也不會中斷

嚴格來說這不是 Claude Code 的功能，但它補上了一個很容易被忽略的環節——電腦休眠。

Claude Code 有時候會跑一些非常耗時的任務，像是大範圍重構、整個 codebase 的批次修改、跑完整的測試跟建構，動輒十幾二十分鐘起跳。你可能會趁這個空檔去開會、吃飯，甚至先去睡一下，但 Mac 一旦進入休眠，Claude Code 也會跟著停下來，回來只能從斷點接著跑，任務的連續性就斷掉了。

Amphetamine 就是解決這件事的小工具。點一下讓 Mac 保持喚醒、再點一下就關閉防休眠，開跟關都很穩定，我用了好一陣子沒遇過失靈的狀況。它也支援 Raycast 的插件整合，我自己習慣綁一個 hotkey，要開始跑長任務前一秒切開、任務跑完順手切回，完全不用打開 App 介面。

免費 App Store

如何調教 Claude Code：Status Line、CLAUDE.md、自訂 Skill 配置筆記

Status Line：即時掌握使用狀態

建立腳本

啟用設定

懶人指令

CLAUDE.md：讓 AI 讀懂你的專案

沒有它會怎樣

層級結構

我會放什麼進去

寫好 CLAUDE.md 的關鍵

提示詞的日常技巧

先思考，再輸入

具體優於模糊

說明為什麼，不只是做什麼

告訴它不要做什麼

管理上下文視窗

卡住時換個方式

精選 Skill：一個指令搞定重複工作

什麼時候該包成 Skill

怎麼建立一個 Skill

開發類

/commit-generate：自動產生 commit 並推送

/simplify：寫完之後的第二雙眼睛

/frontend-design：生成有設計感的前端介面

Awesome DESIGN.md：讓 AI 生出像樣的 UI

/batch：大規模平行修改

文件類

/codeck：把資料夾變成一份簡報

找更多 Skill

官方多帳號切換：用 CLAUDE_CONFIG_DIR

Amphetamine：放著跑也不會中斷

♡ 你可能會喜歡 ♡

我的輸入效率工具組合：AI 語音輸入、中文輸入法跟 Raycast 剪貼簿

OrbStack：Apple Silicon 原生的 Docker Desktop 替代方案

三次重寫才搞懂：個人網站從建站到雙語管理的完整流程