本 SOP 唯一允許調用工具產生、修改或刪除的 artifact，只能來自下述 SOP 中明確標注 CREATE、WRITE、UPDATE、DELETE 或 impact matrix CLI 的步驟；其餘 READ、SEARCH、REASONING 觀察到的路徑只可作為分析依據，不得被順手建立、寫入、更新或刪除。
-
解析 arguments
1.1 在 CWD SEARCH **/arguments.yml 檔案，找不到則 STOP 並對使用者輸出「我在 CWD 底下找不到 **/arguments.yml 檔案，你是否已經執行過 /aibdd-kickoff 了？」。
1.2 EXECUTE command 以 resolver 綁定本 SOP 引用的變數並對使用者輸出 resolver stdout（每行一筆 KEY=value），resolver 非 0 退出時 STOP 並對使用者輸出其 stderr；resolver 輸出含 <<NNN-plan-slug>> 借位者由 $PLAN_PACKAGE_SLUG 解析，${FEATURE_SPECS_DIR} 另含 <<NN-functional-module>> 借位由各 .feature 所屬 package 的 NN-<slug> 解析。
python3 .claude/skills/aibdd-core/scripts/cli/resolve_args.py <<'EOF'
CURRENT_PLAN_PACKAGE=${CURRENT_PLAN_PACKAGE}
FEATURE_SPECS_DIR=${FEATURE_SPECS_DIR}
IMPACT_MATRIX_YML=${IMPACT_MATRIX_YML}
PLAN_PACKAGES_DIR=${PLAN_PACKAGES_DIR}
PLAN_REPORTS_DIR=${PLAN_REPORTS_DIR}
PLAN_SPEC=${PLAN_SPEC}
PROJECT_SPEC_LANGUAGE=${PROJECT_SPEC_LANGUAGE}
TRUTH_BOUNDARY_ROOT=${TRUTH_BOUNDARY_ROOT}
EOF
-
解析本批次 plan package: 對話歷史已指名具體 NNN-<slug>（例：flows-specify 剛處理完那個 package、使用者點名 ${PLAN_PACKAGES_DIR}/NNN-<slug>、或「繼續做 NNN 那個 package」這類指涉），且 ASSERT ${PLAN_PACKAGES_DIR}/NNN-<slug>/ 存在於 CWD，則設 $PLAN_PACKAGE_SLUG 為該 NNN-<slug>，否則對使用者輸出 ${PLAN_PACKAGES_DIR}/*/ 全部候選 folder 並直接詢問（不使用 /clarify）要做哪一個 plan package、設 $PLAN_PACKAGE_SLUG 為其 slug，STOP 待使用者回答，候選僅一個甚至為空也必須釐清。
-
查 worklist: EXECUTE command 以 read --owner aibdd-rules-specify --impact-status pending 讀出 ${IMPACT_MATRIX_YML} 屬本 owner 的 pending impact 作為 $WORKLIST 並對使用者輸出，CLI 用法詳見 aibdd-core::references/impact-matrix/cli-usage.md；$WORKLIST 各 impact 的 quotes 為本批次本 owner 要落成 atomic rule 的需求句，其中 spec 為空的 impact 為待配對既有 .feature 的全新 rule 工作、帶 inconsistent .feature spec 的 impact 為待重新對齊 rule 的既有 .feature。
-
載入 package 範疇: READ ${PLAN_REPORTS_DIR}/function-packaging.md 取各 function package 的 flagged-reason（added／related）與 rationale 作為 $PLAN_SCOPE。
-
載入分析基準
5.1 設 $WORKLIST_QUOTES 為 $WORKLIST 各 impact 的 quotes 聯集，每句標註其來源 impact id，為本批次本 owner 要落成 atomic rule 的需求句。
5.2 READ ${PLAN_SPEC} 全文作為本批次列舉 atomic rule 的主要真相來源；依據 $WORKLIST_QUOTES 在 ${PLAN_SPEC} 全文 REASONING 每個 quote 跨段落相關的完整需求上下文作為 $QUOTE_SEGMENTS。並設 $BATCH_NO 為其需求描述段最新批次號。
-
鎖定待補 rule 的 feature
6.1 SEARCH $PLAN_SCOPE 各 function package 之 ${FEATURE_SPECS_DIR} 下現存的 .feature，依各檔 Feature: 業務意圖與 $WORKLIST_QUOTES REASONING 配對，設 $RULE_TARGETS 為每個被本批次 quotes 命中且仍存在的 .feature，每筆為 { feature_path, impact_id, quotes }，其 quotes 為命中該檔的需求句子集；對映不到任一現存 .feature 的 quotes 蒐集成 $SOURCE_GAPS。
6.2 若 $SOURCE_GAPS 非空 則一次性 DELEGATE /clarify 批次問清全部、附各項來源 quote 作 anchor，參考 aibdd-core::references/ssot/spec.template.md 的澄清紀錄填寫規則把拍板結論 WRITE 進 ${PLAN_SPEC} 批次 $BATCH_NO、owner aibdd-rules-specify 的澄清區塊，再依結論重新配對 $RULE_TARGETS，重複至 $SOURCE_GAPS 清空。
-
列舉 atomic rules
7.1 對 $RULE_TARGETS 每個 target 嚴格遵照 aibdd-rules-specify/rules/atomic-rule-granularity.md 全部約束，依該 target 的 quotes 對應的 $QUOTE_SEGMENTS REASONING 該 .feature 的 atomic rules 作為該 target 的 $RULES，並確認該 target 每個 segment 都已被 $RULES 完整涵蓋；推論中一旦缺少定案所需的重要資訊（含該規則檔規定必問的同一 .feature 混多 operation、以及主詞／條件／語氣從 $QUOTE_SEGMENTS 推不出者）蒐集成 $ASK_BATCH；本步只推理不寫檔。
7.2 若 $ASK_BATCH 非空 則一次性 DELEGATE /clarify 批次問清，附各項來源 quote 與對應 .feature 作 anchor，參考 aibdd-core::references/ssot/spec.template.md 的澄清紀錄填寫規則把拍板結論 WRITE 進 ${PLAN_SPEC} 批次 $BATCH_NO、owner aibdd-rules-specify 的澄清區塊，再依結論回 7.1 重新推論對應 $RULES，重複至 $ASK_BATCH 清空。
7.3 對收斂後各 target 的 $RULES DELEGATE /analyze-and-clarify 稽核，交辦上下文說清楚：稽核對象為 plan package $PLAN_PACKAGE_SLUG 需求批次 $BATCH_NO 的推論結果；推論目的為依各 target 的 $QUOTE_SEGMENTS 列舉該 .feature 的 atomic rules，且每個 segment 都要被 $RULES 完整涵蓋；稽核基準為 aibdd-rules-specify/rules/atomic-rule-granularity.md；待稽核結果為連同所屬 target 的 $RULES 完整內容（附內容本身，非路徑）。
7.4 依 /analyze-and-clarify 回報的 violations 處置：fixable 就地重推對應 $RULES；to-clarify 併入 $ASK_BATCH 回 7.2 批次問清、記澄清區後重推；本輪 violations 尚有 to-clarify 未獲使用者回答前不得重新 DELEGATE /analyze-and-clarify，待全數處置完畢才回 7.3 重新稽核，重複至 violations 回空。
-
WRITE rules: 對 $RULE_TARGETS 每個 target 參考 aibdd-rules-specify/assets/templates/atomic-rule-format.template.feature 把收斂後的 $RULES 依模板縮排與區塊結構 UPDATE 進其 feature_path；保留既有檔頭（# 註解列、@ignore、Feature: 標題），不得新增 Background／Scenario／Examples／表格或 Step，同一檔內既存的同一 Rule: 主句不重複寫入。
-
回寫 rule impact
9.1 READ aibdd-core::references/impact-matrix/cli-usage.md，取得通用規則、資料模型、status 語意與各 verb 應用 command。
9.2 對 $RULE_TARGETS 每個 target，設其 feature_path 相對 ${TRUTH_BOUNDARY_ROOT} 路徑為 spec_path、其 impact_id 為 impact_id；若該 impact 尚無此 spec 則 EXECUTE command add-spec --id <impact_id> --spec <spec_path> --status consistent，否則 EXECUTE command transit-status --id <impact_id> --spec <spec_path> --status consistent；若 command 失敗則依其 violations 修正後重試直到成功。
9.3 結案完成的 impact: EXECUTE command 以 read --owner aibdd-rules-specify --impact-status pending 取回本 owner 仍 pending 的 impact，對其中 specs 非空且全部 spec 皆為 consistent 的每個 impact EXECUTE command transit-status --id <impact_id> --status resolved；若 command 失敗則依其 violations 修正後重試直到成功。
-
回報結果: 對使用者輸出（可使用不同詞彙但維持語意）「OK，/aibdd-rules-specify 已為 flows-specify 觸動的每個 .feature 依本 owner 的需求 quotes 列舉並收斂 atomic rules，疑慮已就地修正或交澄清，impact matrix 已同步。下面逐一列出本批次補上 rule 的 .feature 與 resolve 的 impact：<逐一列出>。接著請執行 /aibdd-spec-by-example，為每條 atomic rule 補上可跑的 Example。」
