القائمة
啟動實作流程（Lane 制：每個類型同時最多 1 個 agent）。Backend / Frontend / Pipeline 各自 1 個 engineer，加 1 個 QA、1 個 UI Designer，共最多 5 個 background agent。觸發關鍵字："implement", "實作", "開發"。
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
處理 Google Chat AI Agent 後端的待處理訊息。執行一次會拉 /api/claude/pending、逐則判斷並產生回覆、依 auto_mode 決定直接送出或進 approve queue。使用者說「處理 chat」「回覆 chat」「process chat」「chat drafts」時自動啟用。
從 Google Chat space 的歷史訊息萃取 5 類 context（產品 / 我的角色 / 術語 / pinned 決策 / 人物關係）。執行一次會拉 mining queue、對每個 space 跑 LLM 列點、把 candidate 寫進 backend 等 user approve。使用者說「mine space」「整理 space facts」「space mining」「mine fedflow-team space」「挖掘 space 事實」時自動啟用。
為已完成的專案新增需求變更（Change Request）。spec-writer 評估影響範圍 → 建立 CR 文件 + 新 Sprint milestone → 走原本的 tech-lead → engineer + qa → verify 流程。觸發關鍵字："change", "新需求", "需求變更", "CR", "後續功能", "新增功能"。
啟動 QA 撰寫 BDD step definitions。根據 Gherkin .feature 場景撰寫 playwright-bdd step definitions，與 engineer 同時進行，不需等實作完成。觸發關鍵字："qa", "測試", "test", "e2e", "bdd"。
從 .specflow/state.json 讀取 SpecFlow 流程進度，重建狀態後繼續執行。在 /clear context 之後、或重開 session 時用來接續工作。觸發關鍵字："resume", "繼續", "接續"。
啟動完整的 specflow 專案流程。使用者只需與 spec agent 對話確認需求和架構，之後 tech-lead → (engineer + qa 並行) → verify → release 全部自動背景執行。觸發關鍵字："start", "開始", "啟動專案", "新專案"。
استنادا إلى تصنيف SOC المهني
| name | specflow:implement |
| description | 啟動實作流程（Lane 制：每個類型同時最多 1 個 agent）。Backend / Frontend / Pipeline 各自 1 個 engineer，加 1 個 QA、1 個 UI Designer，共最多 5 個 background agent。觸發關鍵字："implement", "實作", "開發"。 |
| user-invocable | true |
| allowed-tools | Read, Write, Edit, Grep, Glob, Bash, Agent |
| argument-hint | [feature issue 編號，或 all] |
核心規則：每個 lane 同時最多 1 個 agent，agent 在 lane 內 loop 認領 issue。 避免 worktree 衝突、token 暴增、merge race condition。
| Lane | Agent | Issue 條件 |
|---|---|---|
| backend | engineer | feature,backend 或 bug,backend，open 且未 assigned |
| frontend | engineer | feature,frontend 或 bug,frontend |
| pipeline | engineer | feature,pipeline 或 bug,pipeline |
| qa | qa-engineer | qa，當前 sprint |
| ui | ui-designer | design，當前 sprint |
$ARGUMENTS 指定 issue 編號，從該 issue 的 lane label 自動判斷類型，啟動 1 個對應 agent 處理該 issue。
SPRINT="{current_sprint}"
# Engineer：三個 lane 各最多 1 個（只啟動有 issue 的）
for LANE in backend frontend pipeline; do
COUNT=$(gh issue list --milestone "$SPRINT" --label "$LANE" --state open --json number --jq 'length')
if [ "$COUNT" -gt 0 ]; then
bash .claude/scripts/state.sh agent-add "engineer-$LANE" 0 null "" "running"
# Agent(subagent_type="engineer", run_in_background=true, isolation="worktree",
# prompt="lane=$LANE, sprint=$SPRINT, 循序清空 lane 全部 open issues")
fi
done
# QA：1 個（撰寫 step definitions）
Agent(subagent_type="qa-engineer", run_in_background=true, isolation="worktree",
prompt="sprint=$SPRINT")
# UI Designer：1 個（只在有 design issue 時）
DESIGN=$(gh issue list --milestone "$SPRINT" --label "design" --state open --json number --jq 'length')
[ "$DESIGN" -gt 0 ] && Agent(
subagent_type="ui-designer", run_in_background=true, isolation="worktree",
prompt="sprint=$SPRINT"
)
最多 5 個 background agent：backend / frontend / pipeline / qa / ui-designer。
每當 engineer 或 QA 發 PR，code-review agent 在背景啟動審查（sonnet model，唯讀，無 lane 限制可同時多個）：
Agent(subagent_type="code-review", run_in_background=true)
input: PR #{pr_number}, Issue #{issue_number}
needs-revision label，該 lane 的下一輪 loop 會優先處理（同 lane engineer 不會搶兩個 worktree）blocked，需人工介入所有 lane drain 完畢 + 所有 PR merge → specflow:start Phase 4.9 infra 確認 → Phase 5 BDD 測試