如何將可運作的 AI 任務變成可重複使用的 Skill
將一次性的提示轉換為可重複使用的 SKILL.md。區分動態輸入與標準規則、測試邊界情況，並與團隊分享此工作流程。
當你有一份可用的 GitHub 週報後，你大概會希望下一份也遵循相同規則：依合併日期篩選、保留來源連結，並讓缺少的脈絡保持可見。把這些規則保存下來，會比每週複製一段冗長的對話更容易重複使用與審查。
在 Leina 中，你可以將已驗證的工作流程打包成一個 Skill——一個遵循開放 Agent Skills 規格的結構化 SKILL.md 檔案。不必每個星期一重新說明團隊的報告標準，只要提供目前的 repository、日期、時區，以及任務所需的任何目的地。
以你已經檢查過的報告作為起點。GitHub-to-Notion 逐步操作說明 示範如何準備與審查一份報告。
將變動的輸入與標準規則分開
一個可靠的 Skill 會區分本次執行的輸入與可重複使用的規則。
| 本次執行的輸入 | 儲存在 SKILL.md 中的規則 |
|---|---|
| 目標 repository 或 repository 清單 | 精確的篩選規則（merged timestamp 與 closed date） |
| 報告期間與時區 | 來源引用要求（包含 PR 連結與作者） |
| Notion 目的地頁面 URL，用於寫入 | 證據規則（將缺少的脈絡標示為未記錄） |
| 目標受眾／詳細程度 | 寫入指示（遵守要求的範圍並檢查現有內容） |
認證資訊與存取權杖絕不應放在 Skill 檔案中。Leina 透過已授權的 Connections 管理存取；Skill 只定義代理程式應如何使用你環境中可用的工具。
結構化你的 SKILL.md 檔案
SKILL.md 檔案包含 YAML frontmatter 與 Markdown 指示。這個入門範例可供你依可用工具調整與測試；它尚未在你的帳號上執行過。
---
name: weekly-pr-report
description: "為指定的儲存庫與時間範圍準備一份可連結來源的每週 GitHub 提取要求報告，並可選擇性地授權寫入 Notion。用於工程狀態報告，而非程式碼審查或個人產能評分。"
---
# 每週 PR 報告
範例指示，供調整並使用代理程式環境中可用的工具進行評估。本檔案不會安裝連接器或授予帳戶存取權。
## 輸入
從要求中解析儲存庫清單、含時區的報告時間範圍，以及預定讀者。若缺少會改變報告的範圍，請主動詢問。若需寫入 Notion，也請解析確切的頁面、報告標題，以及使用者想要附加或取代。
使用目前環境所提供的已授權 GitHub 讀取。若這些操作無法使用，請回報缺少的能力。絕不虛構連接器動作 ID 或擷取的記錄。
## 選取與摘要
- 納入合併時間戳落在要求時間範圍內的已合併 PR。將已關閉但未合併的記錄與已合併的工作區分開來。
- 僅在要求時納入另立的目前開啟 PR 快照，並標示擷取時間。不要將目前狀態呈現為歷史狀態。
- 在支援的情況下，擷取範圍內的所有結果頁面。揭露無法取得的記錄、遭截斷的結果或失敗的查詢；不完整的查詢不等於零結果的查詢。
- 保留 PR URL、編號、標題、作者、狀態及相關時間戳。根據 PR 描述與工具可取得的變更進行摘要。
- 僅在證據支持時描述影響、部署、阻礙因素及後續動作負責人。不要預設將作者視為後續動作負責人。
- 傳回選取的範圍、報告章節、來源連結及未解決的問題。使詳細程度符合預定讀者。
## 選用的 Notion 寫入
草稿要求會傳回草稿。僅在使用者已授權具體目的地與操作時才寫入；保留現有授權，而非要求反覆確認。
附加前先檢查報告標題。若報告已存在且未授權取代，請傳回其位置並詢問如何繼續。保留不相關的內容。
寫入後，若支援則讀回該章節並傳回其位置。若寫入結果不確定，請在重試前檢查目標。若無法驗證，請回報該限制，而非聲稱寫入已確認。下載相同的 weekly-pr-report SKILL.md，為你團隊的欄位進行自訂。
檔案中有三個選擇值得保留：
- 聚焦的描述： 它說明此 Skill 何時有用。探索與呼叫取決於代理程式環境。
- 明確的選取規則： 合併時間決定哪些 PR 屬於已完成工作區段。
- 定義的寫入範圍： 指示要求代理程式檢查現有內容並遵守要求的操作。它們引導行為；權限則強制執行存取。
在推出前測試邊界情況
在與團隊分享此 Skill 之前，讓它針對不同的週次或 repository 執行，並將其輸出與來源記錄進行比較。試試這些情況：
| 測試情境 | 預期的代理程式行為 |
|---|---|
| 0 個合併 PR 的平靜一週 | 在完整查詢後回報為零；不捏造重點，也不拉入較舊的 PR。 |
| 在期間外 1 分鐘合併的 PR | 從已合併區段中排除。 |
| 已關閉但未合併的 PR | 從已合併工作中排除。 |
| 沒有描述的 PR（例如「bump version」） | 摘要原始變更，並明確將影響標示為未記錄。 |
| Notion 中已存在目標標題 | 檢查現有區段並遵循已授權的操作；若未授權取代，則詢問如何進行。 |
| 無法存取的 repository 或頁面 | 清楚回報缺少的權限，而不是假裝該 repo 是空的。 |
如果代理程式在第二次執行時重複使用舊日期，請確認日期範圍沒有被硬編碼在指示中。如果它捏造客戶影響，請收緊摘要規則。
與團隊分享並自動化
在檢查第二次執行後，請依照你的 Skill 套件安裝指示，或你的代理程式環境支援的匯入機制操作。僅下載檔案並不會安裝它。請參閱 Use Skills With Leina 了解目錄工作流程。
- 互動式使用： 團隊成員可以在聊天中自然地呼叫它： 「@Leina run weekly-pr-report for backend/api covering September 28 through October 4, 2026, in America/Los_Angeles. Return a draft here.」
- 權限： 每位團隊成員都需要使用 GitHub 連線的權限，以及在儲存報告時使用 Notion 連線的權限。請在 Connections 中檢查那些帳號。
- 排程執行： 要求一個週期性任務，並提供其時區、報告期間與交付位置。驗證 Leina 設定的排程，並審查其第一次排程輸出。儲存 Skill 並不會建立排程。
分享已檢查的檔案，並附上其所需的 Apps、範例報告，以及版本或修訂日期。當團隊變更報告規則時，請更新該檔案並再檢查一次執行。