My Kiro Workflow

開發用

My Dev Config

一些相關的搭配：

• cmux 用於多任務的處理
  • 結合 git worktree 同步進行任務
  • 開啟 Browser 瀏覽抓取資訊或是看 PR 等
  • 開啟 AI 寫的 md file 瀏覽計畫
  • 通知 AI 已經完成，尚未閱讀等資訊
• rtk & cavemen
  • 用於減少 Agent 的輸入 & 輸出
• npx skills
  • 管理 Skill 讓它可以在不同的位置進行安裝
• sandbox
  • 安全不怕弄壞
  • 不需要擔心環境變數或是個人資料外洩
  • 不需要人審核
  • ralph loop

核心的想法

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

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

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

當計畫完成後，Supervisor 可以透過調用 Subagent 並行的執行任務，並進行 Review。

每個 Subagent 處理的任務複雜度不同，可以定義不同 Agent 不同的 Model。

對於計畫會請 AI 盡可能同步的進行處理，例如 A 和 B 之間沒有相互的關係，那麼他就可以同步派不同的 Subagent 一起處理，加快速度。

每個 Agent 在空的 Context 進行 Review 時，才能更客觀的決定品質的好壞。

Ralph loop

┌──────────────────────────────────────────────────────┐
│                   Ralph Loop (outer)                 │
│  ┌────────────────────────────────────────────────┐  │
│  │  AI SDK Tool Loop (inner)                      │  │
│  │  LLM ↔ tools ↔ LLM ↔ tools ... until done      │  │
│  └────────────────────────────────────────────────┘  │
│                         ↓                            │
│  verifyCompletion: "Is the TASK actually complete?"  │
│                         ↓                            │
│       No? → Inject feedback → Run another iteration  │
│       Yes? → Return final result                     │
└──────────────────────────────────────────────────────┘

https://ghuntley.com/ralph/

while :; do cat PROMPT.md | claude-code ; done

Sandbox

• 環境處理較麻煩
• 可能一些 library 需要額外處理
• 一些 Auth 也要額外處理
• 如果是要跑個人設定的 Config 需要額外處理

Hooks

透過 Hook 避免 LLM 的不穩定和不確定，像是透過 hook 要求 LLM 改寫指令、明確的禁止哪些檔案不能碰不能寫。

也可以用來提醒 Agent 該做的事或是當 Agent 完成時提醒你。

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

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

LLM 很聰明，但也很不聽從規則，很有個性和自己的想法，所以需要透過 hook 限制它，讓它只能照著你的想法執行，不讓他有漏洞可以鑽。

讓 Codebase 適合 Agent

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

使用 Agent 開發的心得

• 要確保自身瞭解 Agent 所作的更動、範圍、Scope 等
  • 在完成後 Review AI 的更動，AI 有時很冗長有時又可能有地方 miss 沒動到
  • 透過 Skill 叫 AI Review 自己是否有理解(See also: verify-user-comprehension)
  • 不管 Code 是誰寫的，都得對 Code 負責
• PR Review 一直很難，現在更難了
  • 產 Code 變很快，需要花更久的時間進行 Review
  • 測試和耐心很重要
• 不要將你覺得重要的思考交給 AI
  • 與 AI 進行討論
  • 和不同的 Model 進行討論
  • 查證、驗證結果
• Agent 會過度優化、過度測試且思考太多
  • 太早擔心架構、效能等問題
  • 部分情形在 User Flow 中不會發生
  • 寫太多實作的測試而非結果
• AI 急於開始，先和 AI 對齊

團隊的自動化

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

Harness = Agent - Model

Jira 自動化委派開發

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

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 進行修復。

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 進行修改。

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 感覺都沒有再更新，許多新的設定問他他都說不知道。

我覺得在 AI 時代重要的事

QA & Reviewer 比以往更加重要

1. 大多數的產品都是交給人使用(不排除有要交給 Agent 的或是將 API 作為產品的)，只有在實際操作的時候，才能感受到產品的使用，這是 AI 所欠缺的。
2. Code 改變的 Scope 和頻率比以前快很多，測試比以往更重要。
3. 穩定且可靠的產品才是目前與其它快速生成(Vibe)的產品有所不同，工程師應該要更重視產品的穩定和可靠性。
4. 目前 Code 的品質、設計仍然需要人進行把控，所以軟體的相關知識仍然重要，除非你只是想要快速的 Vibe 出個 Demo 等。

確定性的檢查要更多

LLM 的產出是不確定，為了管控好整個品質，加入更多的確定性，例如 Unit Test、 E2E Test、 Lint、 Code 靜態分析工具等。

PR & Code

1. 避免團隊的負擔，控制好 PR 的大小
2. 不要發自己還不理解沒讀懂的 PR
3. 可以將實作交給 AI，但要自己思考整體的架構、規劃、Interface etc.

Subnotes

• Jira 驅動
• Pattern Check
• PR Check
• Code Module