My Kiro Workflow

建立：2026-05-20 · 最後編輯：2026-05-25

My Dev Config

一些相關的搭配：

 

核心的想法

透過不同的 Agent 避免 Context Rot 的問題，各個 Agent 進行分工和 Review，使用 MD file 進行彼此的 Agent 訊息蒐集交換，和可觀測 Agent 的輸出。

建立 Plan → Review → Implement → Review Loop → Done 的工作流程。

使用 Agent 開發的時候，最常發生改 A 漏 B，只改 A 卻沒有將相關的東西一起修改，又或者想法改了太多，再讓 Agent 動手前先讓他進行計畫，進行 Review，避免發生這種錯誤。

Hooks

透過 Hook 避免 LLM 的不穩定和不確定，像是透過 hook 要求 LLM 改寫指令、明確的禁止哪些檔案不能碰不能寫。也可以用來提醒 Agent 該做的事或是當 Agent 完成時提醒你。

像是我希望每次載入的時候，Agent 都可以使用 cavement 的 Skill 試著少說廢話，就可以在 AgentSpawn 的時候呼叫某個腳本給 Agent。

或是再每次傳送訊息的時候，透過 UserPromptSubmit 一起將某些資訊給 Agent 等。

一些處理讓 Codebase 適合 Agent

  1. 定期更新團隊的 Agent.md or Steering 開發準則或 Pattern 等
    1. 要思考什麼是 AI 每次都會需要的東西在放入
  2. 建立團隊共用常用的 Skill
  3. Code 切分採用領域的方式，讓 Agent 可以專注於單一的 Domain 中 (See also: The Vertical Codebase)
  4. 統一專有名詞，和 Agent 溝通會更清楚

團隊的自動化

參考 OpenAI Harness 工程 進行相關的自動化。

Harness = Agent - Model

Jira 自動化委派開發

串接 Jira MCP 讓 Agent 可以閱讀 Ticket 上的 Description 或是討論的留言，可以附上 Conference 的 Link，透過 MCP 去閱讀相關的上下文資訊。

Jira 驅動
sequenceDiagram
    participant Cron as ⏰ Cron (每 2h)
    participant Scan as jira-scan
    participant Jira as Jira API
    participant Worker as jira-worker
    participant Kiro as Kiro CLI
    participant GH as GitHub

    Cron->>Scan: 觸發
    Scan->>Jira: 掃描 tickets (REST API)
    Jira-->>Scan: 符合條件的 tickets
    loop 每張 ticket
        Scan->>Worker: workflow_dispatch(ticket_key)
    end
    Worker->>Jira: 轉換狀態 (pickup)
    Worker->>Kiro: 計畫 (bug-planner / feature-planner)
    Kiro-->>Worker: task.md
    Worker->>Kiro: 計畫審查迴圈 (plan-review-loop)
    Kiro-->>Worker: 核准的計畫
    Worker->>Kiro: 實作 (jira-worker agent)
    Kiro-->>Worker: 程式碼變更
    loop 最多 5 次
        Worker->>Kiro: 審查 (review-loop)
        Kiro-->>Worker: 審查結果
        alt 需要修正
            Worker->>Kiro: 修正
        end
    end
    Worker->>GH: 建立/更新 PR
    Worker->>Jira: 通知完成

Codebase 品質檢測 & 修復

團隊會持續的維護專案 Steering ，將 Agent 或開發者常犯的錯誤進行紀錄修正，定期 Scan 專案建立 Issue，再自動化的委派 Agent 進行修復。

Pattern Check
sequenceDiagram
    participant Cron as ⏰ Cron (每週一)
    participant PC as pattern-check
    participant Kiro as Kiro CLI
    participant GH as GitHub
    participant IF as issue-fix

    Cron->>PC: 觸發
    PC->>Kiro: scan (pattern-scanner)
    Kiro-->>PC: pattern catalog
    par 9 shards 平行
        PC->>Kiro: detect (inconsistency-detector)
        Kiro-->>PC: 不一致報告
    end
    PC->>Kiro: validate (pattern-validator)
    Kiro-->>PC: 驗證結果
    PC->>GH: 建立 Issues (+ kiro-fix label)

    Note over GH,IF: Issue 加上 kiro-fix label 觸發
    GH->>IF: labeled event
    IF->>Kiro: issue-triager (問題分類)
    Kiro-->>IF: 分類結果
    IF->>GH: 發佈分類 comment
    IF->>Kiro: issue-fixer (自動修復)
    Kiro-->>IF: 程式碼變更
    IF->>GH: 建立 PR (kiro-fix/issue-N)

PR Review & Fix

由 Agent 或是開發者發送 PR 時，協助進行 Review 或是透過 /kiro 指令要求 Agent 進行修改。

PR Check
sequenceDiagram
    participant Dev as 開發者 / CI
    participant GH as GitHub
    participant Review as pr-review
    participant Kiro as Kiro CLI
    participant Fix as pr-comment

    Dev->>GH: 開啟/更新 PR
    GH->>Review: PR event (opened/synchronize)
    Review->>Review: 取得 PR diff
    Review->>Kiro: pr-reviewer agent
    Kiro-->>Review: 審查意見
    Review->>GH: 發佈 review comment

    Note over GH,Fix: 使用者回覆 /kiro 觸發
    GH->>Fix: issue_comment event
    Fix->>Fix: 取得 comment context + diff
    Fix->>Kiro: pr-comment-fixer agent
    Kiro-->>Fix: 修正後程式碼
    Fix->>GH: Push 到 PR branch
    GH->>Review: synchronize 再次觸發審查

覺得奇怪是坑的地方

  1. 當設定 reference 指定 skill file 或其它檔案的時候，如果 read tool 沒有權限，那麼它是讀不到 reference 內的檔案的，所以內部實作 reference 應該一樣是使用 read tool 達成的，所以 read 的 hook 和 allowedPath 設定都需要注意不能檔住這些檔案。
  2. 沒有 rm 的 tool 看起來都是始用 shell 的 rm 刪除？write tool 不包含 rm，如果有需要刪除的也需要設定好 shell tool。
  3. 使用 subagent 的時候，啟動的 subagent 不會執行 hook 的 AgentSpawn。
  4. Kiro Guide Agent 感覺都沒有再更新，許多新的設定問他他都說不知道。

Subnotes