To Spec

---
name: to-spec
description: 把目前的對話轉成規格說明並發佈到專案 Issue 追蹤器——不訪談，只綜合你已經討論過的內容。
disable-model-invocation: true
---

這個技能取用目前對話的上下文與程式碼庫理解，產出一份規格說明。**不要**訪談使用者——只要綜合你已經知道的內容。

Issue 追蹤器與分診標籤詞彙應該已經提供給你——如果沒有，執行 `/setup-matt-pocock-skills`。

## 流程

1. 探索 repo 以了解程式碼庫目前的狀態，如果你還沒做的話。在整份規格說明中，使用專案的領域詞彙表詞彙，並尊重你接觸區域的任何 ADR。

2. 勾勒出你將測試該功能的接縫。既有接縫應優先於新接縫。使用盡可能最高的接縫。如果需要新接縫，在你能達到的最高點提出它們。整個程式碼庫的接縫越少越好——理想數量是一個。

與使用者確認這些接縫符合他們的期望。

3. 使用下方範本撰寫規格說明，然後發佈到專案 Issue 追蹤器。套用 `ready-for-agent` 分診標籤——不需要額外的分診。

<spec-template>

## 問題陳述

使用者正面臨的問題，從使用者的視角出發。

## 解決方案

問題的解決方案，從使用者的視角出發。

## 使用者故事

一份**很長**、編號的使用者故事清單。每個使用者故事的格式應為：

1. 作為 <actor>，我想要 <feature>，以便 <benefit>

<user-story-example>
1. 作為行動銀行客戶，我想要查看帳戶餘額，以便對我的支出做出更明智的決策
</user-story-example>

這份使用者故事清單應該極其詳盡，涵蓋功能的各個面向。

## 實作決策

已作實作決策的清單。可以包含：

- 將被建置／修改的模組
- 那些將被修改的模組的介面
- 來自開發者的技術釐清
- 架構決策
- Schema 變更
- API 合約
- 特定的互動

**不要**包含具體的檔案路徑或程式碼片段。它們很可能很快就過時。

例外：如果原型產出了一個比散文更能精確編碼決策的片段（狀態機、reducer、schema、型別形狀），就把它內嵌在相關決策中，並簡短註明它來自原型。只保留富含決策的部分——不是可運作的示範，只是重要的片段。

## 測試決策

已作測試決策的清單。包含：

- 說明什麼構成好的測試（只測試外部行為，不測試實作細節）
- 哪些模組將被測試
- 測試的既有先例（也就是程式碼庫中類似型別的測試）

## 超出範圍

這份規格說明超出範圍之事的描述。

## 補充說明

關於此功能的任何補充說明。

</spec-template>