Communitygithub.com

navikt/grillmester

成本感知的 GitHub Copilot 工作流程,用於清晰、有邊界且獨立審查的軟體變更。

grillmester 是什麼?

此技能旨在協助團隊在公共部門的背景下制定、品質確保及追蹤目標。它專注於將草案從活動轉化為可觀察的結果,而非虛構基準線、目標值或測量數據。支援的平台包括 GitHub Copilot 以及其他基於文件的協作工具,並透過動態發現目標上下文、提供公式化指南、對所有草案進行「lint」檢查,以及建立追蹤節奏來運作。核心用途是幫助團隊避免常見陷阱,例如混淆活動與結果、缺少基準線或測量計畫。此技能強調問責制,並要求在使用者確認前,先顯示完整的草案和計畫的欄位變更,然後再修改任何目標文件。總體而言,它促進了清晰、數據驅動且以使用者為中心的目標設定,這對於公共部門的治理至關重要。

相容平台~Claude Code~Codex CLI~Cursor
npx skills add navikt/grillmester

在你喜歡的 AI 中提問

開啟一個已預先載入此 Agent Skill 的新對話。

說明文件

公共部門的 OKR 與目標工作

協助團隊制定、品質確保及追蹤目標。將草案從活動轉化為可觀察的結果,但不要虛構基準線、目標值或測量數據。範例請參閱 eksempler.md。

發現目標上下文

不要假設季度節奏、OKR 格式、目標文件、追蹤器或專案欄位。

  1. 閱讀任務書及相關消費者擁有的指示與文件。
  2. 找出團隊已記錄的目標期間、術語、已採納的目標、負責人、資料來源及追蹤節奏。
  3. 如果某個儲存庫、文件或專案僅由議題範本、連結或遠端名稱暗示,則將其視為候選對象,並要求確認。
  4. 一次只問一個缺失的事實性問題。最低上下文是期望的結果、目標受眾、期間、決策負責人及可用的測量基礎。

區分已採納的目標、工作草案及你自己的建議。

公式化指南

  • 目標是結果,而非產出。一個交付物是可能的手段,而非目標本身。
  • 在公共部門,預設使用使用者與社會價值,而非收入。
  • 保持目標數量低。1–3 個抱負,每個帶有 2–3 個關鍵結果,是一個有用的經驗法則,而非政策。
  • 抱負是定性的;關鍵結果描述了一個可衡量的結果。
  • 要求提供基準線和目標值。如果其中一個不存在,則將其標記為未定。
  • 釐清如何以及多久可以以合理的資料品質來衡量結果。
  • 區分日常營運與改進抱負。服務品質的可衡量改善可以是一個真正的結果。
  • 根據消費者的語言規則,調整挪威語或英語的術語。

範例:

  • 好的起點:「完成流程而無需聯絡我們的使用者比例從 62% 提高到 75%。」
  • 活動:「推出新的申請對話。」問問這個交付物旨在促成什麼可觀察的改變。

對所有草案進行 Lint

根據相關規則呈現發現,並提出具體的改寫建議:

檢查項目說明
偽裝的活動對使用者或社會來說,會有什麼不同?
缺少基準線或目標目前的水準、期望的水準及來源是什麼?
缺少測量計劃如何、在哪裡以及多久測量一次結果?
目標太多可以選擇捨棄哪些目標以創造焦點?
混入日常營運這是一個持續的承諾還是一項改進?
缺少價值連結支援了哪種使用者或社會價值?
代理指標該數字是否真正衡量了價值,以及它可能產生哪些副作用?

不要透過虛構一個看似合理的數字來「改善」目標。使用明確的佔位符和問題。

追蹤節奏

遵循團隊已記錄的節奏。如果不存在,則提供此通用節奏作為建議:

時間點活動
期間開始制定目標、基準線、測量計劃及所有權
定期關注信號和學習,而不僅僅是交付狀態
中期評估預測並調整努力或假設
期間結束總結結果、資料品質和學習心得

追蹤器可以將工作連結到目標,但追蹤器活動本身並不記錄目標達成情況。如果團隊實際使用專案和欄位,則動態發現它們。不要假設目標將成為欄位選項,或者欄位名稱可以自動更改。

持久變更

在您修改目標文件、議題、PR 或專案元資料之前:

  1. 顯示準確的儲存庫、文件或專案
  2. 顯示完整的草案和計劃的欄位變更
  3. 請求明確批准

如果正確的目標位置未知,請提問。不要預設建立新的目標文件。

邊界

總是

  • 同時對自己的建議進行 lint。
  • 區分結果、交付物和日常營運。
  • 標記缺少的數據、基準線和決策。

先提問

  • 撰寫或發布目標。
  • 建立議題或拉取請求。
  • 修改追蹤器或專案元資料。

從不

  • 在沒有數據的情況下對目標達成情況評分。
  • 虛構基準線、目標值、負責人或測量計劃。
  • 將完成的任務數量視為效果的證據。

相關技能