利害關係人流程演練
沒有人寫下的需求，會在不是作者的人嘗試執行該事項時浮現：安裝服務的操作人員、搜尋資料的科學家、設定儲存庫的同事、凌晨三點閱讀日誌的維護者。流程演練可以在變更規格制定之前，先在紙上以具名的人物角色和具體的流程進行一次。其產出不是設計：而是給擁有者的問題、差距，以及規格和測試可以使用的驗收範例。
兩個借用的習慣，在此致謝：一是像 MIT 授權的 Feature Forge 技能 (jeffallan) 那樣，戴上兩種帽子進行訪談：產品帽（使用者價值、目標、成功）和開發者帽（可行性、安全性、邊界情況）；二是將模擬的利害關係人所「說」的內容標記為比真實利害關係人所說的內容可信度較低，如同 melodic-software 的需求引導技能所做的那樣。
輸入
在演練前與使用者確定以下事項，並將其寫在輸出的頂端：
- 人物角色 (Persona)。 他們是誰、他們想從此流程中得到什麼、他們知道什麼和不知道什麼、他們的機器上有什麼、以及他們永遠不會讀什麼。偏好使用機構中真實人物的角色，而非原型；當你可以詢問時，偏好使用真實人物的答案，而非你的猜測。
- 流程 (Process)。 他們試圖要做的事情，從他們的第一步到他們認為完成的那一刻。範例：在伺服器上安裝爬蟲；在索引中找到上週的測量值；作為外部集合新增一個新的檔案格式；啟動一個新的儲存庫以使用代理進行開發；在夜間執行後讀取爬蟲日誌。
- 現有資源 (What exists)。 人物角色會遇到的文件、程式碼、指令和頁面，以便演練測試的是現實，而非計畫。應以人物角色的方式閱讀它們：按照他們會找到的順序，跳過他們會跳過的內容。
演練
一次一步地進行流程，穿著人物角色的鞋子。對於每個步驟，寫下：
- 他們做什麼，具體來說：輸入的指令、開啟的頁面、讀取的文件、詢問的人。
- 他們需要知道什麼在此時此刻，以及現有資源是否告訴了他們。
- 實際上會出什麼問題：無聲的失敗、誤導的訊息、沒有預設值的選擇、需要他們不具備權限的步驟、沒有回饋的等待。
- 他們會問擁有者什麼問題，如果他們可以的話，用他們自己的話語。
然後在整個演練中戴上兩次帽子：戴上產品帽時，詢問人物角色想要什麼以及流程是否提供了它、對他們來說「完成」的樣貌是什麼、他們會抱怨什麼；戴上開發者帽時，詢問什麼是不可行的、不安全的、在規模化時速度緩慢的、或在步驟順序中脆弱的。
當演練進行到文件未涵蓋的點時，不要自己發明答案：將其記錄為一個問題，如果你必須假設某件事才能繼續，請說明並將演練的其餘部分標記為奠基於該假設之上。
當一個步驟揭示出更普遍的問題時（五個為什麼）：一個令人困惑的訊息是一個步驟；「這個工具在執行之前從不說它會做什麼」是一個需求。
輸出
將演練結果寫入專案的設計筆記（如果有的話，例如 design/walkthroughs/<人物角色>-<流程>.md），否則寫入 docs/walkthroughs/，並在回覆中提供一個簡短摘要。範本：
# 演練：<人物角色> <執行流程>
人物角色：<身份、目標、知識、環境>。可信度：<模擬 | 基於與 ... 的訪談>。
現有資源：<已讀取的文件、程式碼、指令>。
## 步驟
1. **<步驟>。** 做：<...>。需要知道：<...>。出錯：<...>。會問：「<...>」。
## 產品帽
<他們想要什麼、對他們來說「完成」是什麼、他們會抱怨什麼>
## 開發者帽
<不可行、不安全、緩慢、脆弱>
## 給擁有者的問題
- <問題，用人物角色的話語，並附上源自哪個步驟>
## 差距
- <不存在的需求、行為或文件；需要它的步驟>
## 驗收範例
- 當 <具體情況> 時，那麼 <可觀察到的結果>。 （準備好用於規格場景或測試）
規則
- 說明哪些部分是模擬的。代理進行的演練可以找出一個細心的同事會發現的差距；它不知道真實人物角色重視什麼。如果存在真實的利害關係人，請將問題交給他們，並更新可信度行。
- 保持角色扮演。如果你知道系統如何運作，人物角色並不知道；寫下他們所看到的，而不是你所知道的。
- 具體勝於籠統。「操作人員執行
modama-crawler crawl並在兩小時內什麼都沒看到」是一個發現；「可以改善回饋機制」則不是。 - 問題、差距和範例是交付物。不要在此處設計修復方案；由擁有者決定什麼成為需求。
- 考慮一個全新的視角：對於一個已存在的工具，一個只被賦予人物角色、流程和面向使用者的文件，並被指示執行該工具的次級代理，可以找出作者所無法知道的知識。這是本外掛中的
hallway-test技能；當演練變成「讓我們試試看」時，請使用它。