TTechSpecs

指令用途

/wayfinder 用於規劃超過單一代理工作階段可容納的大型工作。它會將大型工作拆分成多個 issue tracker 上的共享決策 tickets，逐一解決，直到整個路徑清楚。

這就像有一個專案經理在幫你規劃大型專案，將它拆分成可管理的步驟。

運作流程

  1. 定義目標：明確大型工作的最終目標。
  2. 識別決策點：找出需要做出決策的關鍵點。
  3. 建立共享決策 tickets：為每個決策點建立一個 ticket。
  4. 逐一解決：按照優先級逐一解決 tickets。
  5. 更新計畫：根據解決結果更新整體計畫。
  6. 重複直到路徑清楚：直到所有必要的決策都已做出，執行路徑清楚。

實戰對話範例

範例一：大型專案規劃

  • You: 
    /wayfinder
  • AI:

    讓我們一起規劃這個大型專案。

    第一個問題：這個專案的目標是什麼？請具體描述。

    • You:

    我們要建立一個新的電商平台，從零開始。

    AI: 好的。這是一個大型專案。讓我識別關鍵決策點。

    識別到的決策點：

    1. 技術堆疊選擇：

      • 前端框架：React、Vue、Angular？
      • 後端框架：Node.js、Python、Java、Go？
      • 資料庫：SQL、NoSQL？

    2. 架構設計：

      • 單體式還是微服務？
      • 如何處理擴展性？

    3. 功能優先級：

      • 哪些功能是 MVP（最小可行產品）？
      • 哪些功能可以後續加入？

    4. 部署策略：

      • 自建還是使用雲端服務？
      • 如何處理 CI/CD？

    共享決策 tickets 已建立：

    Ticket #50：選擇技術堆疊

    • 描述：決定前端、後端、資料庫的技術選擇
    • 阻塞邊：無

    Ticket #51：設計系統架構

    • 描述：決定單體式或微服務，以及擴展策略
    • 阻塞邊：#50

    Ticket #52：確定功能優先級

    • 描述：決定 MVP 功能和後續功能
    • 阻塞邊：#51

    Ticket #53：規劃部署策略

    • 描述：決定部署方式（自建或雲端）和 CI/CD 流程
    • 阻塞邊：#51

    接下來的步驟：

    我建議先解決 Ticket #50（選擇技術堆疊）。

    要開始嗎？或者你想先看某個 ticket 的詳細內容？

範例二：系統重構

  • You: 
    /wayfinder
  • AI:

    讓我們一起規劃這個系統重構。

    第一個問題：為什麼要重構？目前的問題是什麼？

    • You:

    目前的單體應用太大，難以維護和擴展。

    AI: 好的。讓我識別關鍵決策點。

    識別到的決策點：

    1. 重構目標：

      • 拆分為微服務？
      • 還是模組化單體？

    2. 服務邊界：

      • 如何劃分服務邊界？
      • 每個服務的職責是什麼？

    3. 資料庫策略：

      • 共享資料庫還是每個服務獨立資料庫？
      • 如何處理跨服務查詢？

    4. 遷移策略：

      • 漸進式遷移還是大爆炸重構？
      • 如何保證系統穩定性？

    共享決策 tickets 已建立：

    Ticket #60：決定重構目標

    • 描述：決定是微服務還是模組化單體
    • 阻塞邊：無

    Ticket #61：劃分服務邊界

    • 描述：決定服務的劃分方式和職責
    • 阻塞邊：#60

    Ticket #62：選擇資料庫策略

    • 描述：決定資料庫共享或獨立策略
    • 阻塞邊：#61

    Ticket #63：規劃遷移策略

    • 描述：決定漸進式或大爆炸重構
    • 阻塞邊：#62

    接下來的步驟：

    我建議先解決 Ticket #60（決定重構目標）。

    要開始嗎？

範例三：逐步解決 Tickets

  • You: 
    /wayfinder --ticket=50
  • AI:

    正在解決 Ticket #50…

    Ticket #50：選擇技術堆疊

    描述：決定前端、後端、資料庫的技術選擇

    第一個問題：前端的技術選擇是什麼？

    • You:

    我們想用 React。

    AI: 好的。React 是一個不錯的選擇。讓我記錄這個決策。

    決策已記錄：前端框架 = React

    第二個問題：後端的技術選擇是什麼？

    • You:

    我們有團隊熟悉 Node.js，所以選 Node.js。

    AI: 好的。Node.js 是一個不錯的選擇。讓我記錄這個決策。

    決策已記錄：後端框架 = Node.js

    第三個問題：資料庫的技術選擇是什麼？

    • You:

    我們選 PostgreSQL，因為它是關聯式資料庫，適合交易型應用。

    AI: 好的。PostgreSQL 是一個不錯的選擇。讓我記錄這個決策。

    決策已記錄：資料庫 = PostgreSQL

    Ticket #50 已解決 ✅

    Ticket 狀態已更新：closed

    接下來的步驟：

    現在可以解決 Ticket #51（設計系統架構）了。

    要繼續嗎？

Ticket 狀態機

[New Ticket]
    |
    v
[Triage -> 識別決策點]
    |
    v
[In Progress -> 解決決策]
    |
    +---> [需要更多資訊] -> [追問] -> [更新 Ticket] -> [In Progress]
    |
    +---> [決策已做出] -> [記錄決策] -> [Review]
    |
    +---> [Review] -> [Approved] -> [Closed]
    |
    +---> [Review] -> [Needs Revision] -> [In Progress]

輸出檔案

檔案會自動建立到以下位置：

docs/
└── wayfinder/
    └── 2026-08-02-ecommerce-platform/
        ├── ticket-50.md
        ├── ticket-51.md
        ├── ticket-52.md
        └── ticket-53.md

每個 ticket 檔案包含：

# Ticket #50: 選擇技術堆疊

## 阻塞邊
無

## 描述
決定前端、後端、資料庫的技術選擇

## 決策
- 前端框架：React
- 後端框架：Node.js
- 資料庫：PostgreSQL

## 理由
- React：生態豐富、學習資源多
- Node.js：團隊熟悉、適合後端 API
- PostgreSQL：關聯式資料庫、適合交易型應用

## 狀態
closed

何時使用

  • 大型專案需要拆分為多個決策點
  • 需要明確的執行路徑
  • 需要追蹤決策進度
  • 需要讓團隊成員清楚知道哪些決策還沒做出

何時不應該使用

  • 小型任務
  • 已經有明確的執行路徑
  • 不需要做出重要決策

與其他技能的區別

技能 目的 適用場景
/wayfinder 規劃大型工作 大型專案、系統重構
/to-tickets 拆分為 tickets 規格已定義、任務明確
/implement 實作 tickets tickets 已定義、需要實作