Skip to content

/maigo:take-issue

開始命令時先讀 skills/model-dispatch 並消費 --model-profile <path>；執行角色前依宿主能力解析派工，無 subagents 時依序執行。

接住 /maigo:triage-issue 判定 READY 之後斷掉的那一段——把 issue 接進真正的實作。

使用

/maigo:take-issue <issue 編號或 URL>
/maigo:take-issue --worktree <issue 編號或 URL>   # 在獨立的 worktree（`<repo>/.worktrees/<topic>`）裡跑整趟流程

--worktree（opt-in，預設不開）

帶這個旗標時，在 🐱 樂奈開始之前，orchestrator 親自跑：

git fetch <remote>
root="$(git worktree list --porcelain | head -1 | sed 's/^worktree //')"
git -C "$root" check-ignore -q .worktrees/probe || echo "not ignored — see pre-flight check below"
python3 "${CLAUDE_PLUGIN_ROOT}/scripts/worktree_path.py" --topic "<issue 標題>" --cwd "$root"
git worktree add -b <branch> <path> <remote>/<default-branch>

<remote> 判定：先試 upstream，否則退回 origin。之後每個 delegate 的 prompt 都要帶上這個 path 當 cwd（見 skills/teammate-flow 的 cwd 交辦紀律）。

收尾（🟣 立希全綠、commit 已落地）時印出這個 worktree 的路徑與 branch，明講 「留在原地，等 PR merge 後可用 /maigo:repo-audit 看到清理建議」——不在這裡 自動移除。細節、.maigo/ 歸屬規則見 skills/git-workflow/references/worktree-automation.md。

流程

1. 前置抓料（orchestrator 親跑，不開新 agent）

gh issue view <n> --json title,body,labels,comments

若曾跑過 /maigo:triage-issue，.maigo/ 底下可能有這條 issue 的 triage 產物：呼叫 python3 "${CLAUDE_PLUGIN_ROOT}/scripts/artifact_path.py" triage-rubric --url <issue url> --repo <owner/name> --topic "Triage rubric: <title> (#<n>)" 取得這條 issue 的候選路徑，依序退路讀取：path:（.maigo/issue/<id>/rubric.md，巢狀正典路徑） 那行指的檔案存在就讀；不存在則退到 flat_exists:（.maigo/triage-rubric-<id>.md，分目錄前扁平 檔，只可讀）；再不存在才退到 legacy_exists:（.maigo/triage-rubric.md，舊固定檔名，只可讀）。 三層都讀不到也不擋，就當沒有先前 triage 產物繼續。把 issue body + comments 整理成需求敘述：acceptance criteria 從 body 與 maintainer 在 comments 的 補充萃取，帶著這份 issue context 進下一步。

邊界：issue 明顯不是 READY 形狀（缺重現步驟、需求空泛、單純提問）→ 停下建議先跑 /maigo:triage-issue，不硬做。

2. Teammate flow

依 skills/teammate-flow 走完整流程——🐱 樂奈探索（帶著步驟 1 的 issue context，「看完了。相關的在這三個檔案。」）→ 🩵 燈寫 plan（必須引用 issue 編號與萃取出的 acceptance criteria，「……讓我先理清楚它想 做什麼。」）→ 使用者確認 → 🎀 愛音實作 → 🟡 爽世完整 9 項 review → 🟣 立希驗證。流程細節 不在此重抄。

3. 收尾

🟣 立希全綠後，依 skills/git-workflow / skills/commit-message 草擬 commit 訊息（body 帶 issue 參照，如 Fixes #<n> 或 repo 既有慣例）並直接落地—— 不 push、不開 PR。完成後提示可接 /maigo:describe-pr 產 PR title/description。

4. Work Board 回寫

依 skills/work-board 的 upsert 合約 更新 .maigo/board.md：

  • 開工時：🐛 issue 行標 IN_PROGRESS，旁註 branch 名，留在 🎯 下一件（rank P5——半成品排在 「卡住的／球被打回／一步就結束／等你審」之後，因為它沒卡住任何人）
  • 收尾若已開 PR 或使用者提供 PR 編號：新增 / 更新 🔀 你的 PR 行到 ⏳ 等別人 等 review，issue 行旁註 linked PR

回寫時必須保留原 checkbox 與 🧠 標記；maigo 自己處理的項目不自動勾 checkbox。

失敗處理

依 skills/failure-handling。

Orchestrator 守則

  • 旁白：開場、收場、卡關節點由 🌙 Doloris / 🌑 Mortis 旁白，依 skills/narration。
  • 對話：對話本體（旁白節點以外）的互動節奏與用詞，依 skills/orchestrator-voice。
  • 步驟 1 orchestrator 親自跑、不開新 agent；步驟 2 依 teammate-flow 的 model-dispatch 結果啟動角色，有 subagents 時委派，沒有時依序在主線執行。
  • 不硬做、不寫 GitHub：issue 不是 READY 就建議 /maigo:triage-issue；commit 驗證綠了就落地，push / 開 PR 交使用者或 /maigo:describe-pr。

→ 跟 /maigo:triage-issue / /maigo:go 的差異、場景對照：Commands reference