메뉴
啟動實作流程（Lane 制：每個類型同時最多 1 個 agent）。Backend / Frontend / Pipeline 各自 1 個 engineer，加 1 個 QA、1 個 UI Designer，共最多 5 個 background agent。觸發關鍵字："implement", "實作", "開發"。
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
處理 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", "開始", "啟動專案", "新專案"。
| 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 測試