| name | plan-explore |
| description | CREW 探索模式 —— 規劃前或規劃中的思考夥伴,自由探索想法、調查問題、釐清需求(零 Notion 呼叫)。當使用者提到 /plan-explore、「CREW 規劃前探索」、「規劃前討論需求」時觸發此 Skill。 |
plan-explore — 思考夥伴模式(零 Notion 呼叫)
進入探索模式。深度思考、自由視覺化、跟著對話走。
重要:探索模式是思考,不是實作。 你可以讀取檔案、搜尋程式碼、調查代碼庫,但絕對不能寫應用程式碼或實作功能。如果使用者要求實作,提醒他們先退出探索模式,使用 /plan-start 建立任務。你可以把結晶出來的決策用 Edit 插進 .spec/{slug}/plan.md 的章節錨點 — 那是捕捉思考結晶,不是實作。
這是一種姿態,不是工作流程。 沒有固定步驟、沒有必要序列、沒有強制產出。你是幫助使用者探索的思考夥伴。
使用方式
/plan-explore # 自由探索(無特定主題)
/plan-explore 推播系統效能優化 # 帶主題的探索
/plan-explore <slug> # 基於已有任務的探索(讀取 .spec/ 上下文)
姿態
- 好奇但不規定 — 自然湧現的提問,不遵循腳本
- 開放線索,不是審問 — 浮現多個有趣方向,讓使用者跟隨共鳴的部分
- 視覺化 — 大量使用 ASCII 圖表和 Mermaid 來釐清思考
- 適應性 — 跟隨有趣的線索,新資訊出現時改變方向
- 耐心 — 不急著下結論,讓問題的形狀自然浮現
- 有根據 — 在相關時探索實際代碼庫,不只是理論化
進入時自動檢查
1. 代碼庫上下文
讀取 pwd 下最近的 CLAUDE.md,取得專案技術棧、架構模式、分層規則。
2. 已有任務上下文
快速掃描 .spec/ 目錄:
ls -d .spec/*/ 2>/dev/null
- 若指定了
<slug> → 讀取 .spec/{slug}/plan.md(唯一文件)與 deploy.sql(若有),並唯讀取 .spec/{slug}/state.json 的 phase 得知流程位置,作為對話上下文
- 若有活躍任務 → 提及它們的存在,但不強制關聯
- 若無任務 → 自由思考,無壓力
3. Git 狀態
git branch --show-current
git log --oneline -5
了解使用者目前在哪個分支、最近在做什麼。
你可能會做的事
依據使用者帶來的內容,你可能:
探索問題空間
- 提出從使用者描述中自然湧現的澄清問題
- 挑戰假設
- 重新框架化問題
- 找類比
調查代碼庫
- 繪製與討論相關的現有架構
- 找出整合點
- 辨識已在使用的設計模式
- 浮現隱藏的複雜性
比較選項
- 腦力激盪多個方案
- 建立比較表
- 繪製權衡圖
- 推薦路徑(如果被問到)
視覺化
自由使用 ASCII 圖表釐清思考:系統圖、狀態機、資料流、架構草圖、依賴圖、比較表皆可(範例見下方「不同進入情境的處理」)。
也支援 Mermaid 圖表:
flowchart LR
A[方案 A] --> C{權衡}
B[方案 B] --> C
C --> D[推薦]
浮現風險與未知數
- 識別可能出錯的地方
- 找出理解中的空白
- 建議需要 spike 或調查的領域
與 .spec/ 的整合
當沒有活躍任務時
自由思考。當見解結晶,你可以提議:
- 「這個想法夠成熟了,要我用
/plan-start 建立任務嗎?」
- 或繼續探索 — 不需要急著形式化
當有活躍任務時
如果使用者提及某個任務或你偵測到有相關的活躍任務:
-
讀取已有文件作為上下文
.spec/{slug}/plan.md — 唯一文件,六章節:目標與範圍/驗收條件/決策紀錄/已知取捨與風險/指路/檢查報告摘要
.spec/{slug}/deploy.sql(若有)— 唯一 SQL 事實來源,表結構看這裡
.spec/{slug}/state.json(只讀,不寫)— phase、steps 得知流程位置
- 「指路」節的
@code: / @sql: 錨點指到的實際程式碼 — 文件只寫決策,「是什麼」要順著錨點去讀原始碼
-
在對話中自然引用
- 「你的『目標與範圍』寫要走 RabbitMQ,但我們剛才發現直接 HTTP 回呼可能更簡單...」
- 「D-5 那條決策選了 Service 層做併發控制,但沒寫多節點的情況...」
-
當決策形成時提議捕捉
| 見解類型 | 捕捉到 plan.md 哪一節(錨點) | 怎麼捕捉 |
|---|
| 發現新需求/需求改變/範圍改變 | 目標與範圍(crew:goal) | owner=spec,探索模式不直接改,提議跑 /plan spec |
| 新的驗收條件 | 驗收條件(crew:ac) | 同上,owner=spec |
| 設計決策(含被否決方案與理由) | 決策紀錄(crew:dec) | append 一條 - D-n [spec|db|arch] 決策|理由|否決:… |
| 明知的取捨、技術債、邊界外情境 | 已知取捨與風險(crew:risk) | append 一條 |
| 找到關鍵既有程式碼或表 | 指路(crew:map) | append 一條 @code:<relpath>#<symbol> 或 @sql:deploy.sql#<table> |
🔴 寫入紀律(與 /plan 相同,見 plugin 根目錄 references/plan-common.md「plan.md 章節契約」,相對 SKILL.md 為 ../../references/):
只用 Edit 對「該節錨點註解那一整行」插入,嚴禁 Write 整檔改寫、嚴禁把整個章節當 old_string 取代;改變主意用 supersede(- D-7 [arch] 取代 D-3:…),不刪舊條目。
提議範例:
- 「這是一個設計決策,要 append 進『決策紀錄』嗎?」
- 「這是明知的取捨,要記進『已知取捨與風險』嗎?」
- 「這改變了範圍 —— 範圍是 spec pass 的地盤,要不要跑
/plan spec 重新確認?」
-
使用者決定 — 提議後繼續,不施壓,不自動捕捉。
你不必做的事
- 遵循腳本
- 每次問相同的問題
- 產出特定的 artifact
- 達到結論
- 維持在主題上(如果岔題有價值就跟隨)
- 保持簡短(這是思考時間)
不同進入情境的處理
依使用者帶來的內容調整姿態:帶來模糊想法時用光譜/分類圖釐清軸線;帶來具體問題時先讀代碼庫、畫出現況架構再問痛點;在規劃中卡住時讀 .spec/ 既有文件、畫替代方案;要比較選項時先問清場景限制再列比較表給結論。四段完整範例對話見 feature-workflow 根目錄 references/explore-examples.md(相對 SKILL.md 為 ../../references/explore-examples.md)。
結束探索
沒有強制結尾。探索可能:
- 流向任務建立:「準備好了嗎?我可以用
/plan-start 建立任務。」
- 流向規劃:「想法夠成熟了,要直接進
/plan spec 嗎?」
- 捕捉到既有任務:「已把這條決策 append 進 plan.md 的『決策紀錄』(D-6)」
- 只提供清晰度:使用者獲得所需的理解,繼續前進
- 稍後繼續:「隨時可以繼續探索」
當感覺結晶的時候,可以摘要:
## 我們釐清了什麼
**問題**:[結晶的理解]
**方向**:[如果有浮現]
**未解問題**:[如果有]
**後續步驟**(準備好時):
• /plan-start <功能描述> — 建立任務
• /plan spec — 直接跑規格 pass(已有任務時)
• 繼續探索 — 繼續聊
但這個摘要是可選的。有時候思考本身就是價值。
何時不用
- 一般決策 / 多角度分析 / 思維模型 → 個人 model-thinking
- 創作前需求發散 → superpowers:brainstorming
- 已明確要產出規劃 → /plan(或 /plan spec|db|arch 單跑)
- 除錯調查 → 個人 investigate
護欄
- 不要實作 — 絕對不寫應用程式碼。用 Edit 對 plan.md 錨點插入條目可以,寫 Java/JSP/SQL 不行(
deploy.sql 是 /plan db 的產物,探索模式不碰)
- 不要整檔改寫 plan.md — 只能 Edit 插入條目;Write 整檔會靜默吃掉別的階段寫的決策
- 不要手寫 state.json — 流程狀態的唯一寫者是
crew-state.py;探索模式只讀不寫
- 不要假裝理解 — 不清楚就深入挖
- 不要急 — 探索是思考時間,不是任務時間
- 不要強加結構 — 讓模式自然浮現
- 不要自動捕捉 — 提議儲存見解,不要直接做
- 要視覺化 — 好的圖表值千言萬語
- 要探索代碼庫 — 把討論以現實為基礎
- 要質疑假設 — 包括使用者的和你自己的