Escalation
Use when team conflicts cannot be resolved, major product pivots are needed, or escalation chain must be activatedFrom its SKILL.md
npx -y skills add kctw-dev/shikigami --skill escalationAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 1 stars1 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
SKILL.md
3.5 KB, as published. Nobody here has run it
Escalation — 衝突升級仲裁
1. 概述
Escalation 是衝突升級仲裁 Skill，定義團隊內部無法解決問題時的升級路徑。
當團隊角色之間出現僵局、技術或需求爭議無法在同層級收斂時，透過明確的升級鏈逐步向上尋求仲裁，確保問題不會因無人拍板而阻塞開發進度。
目標：以最小升級範圍、最快速度解除阻塞，同時保留團隊自治的彈性。
2. 升級路徑
技術問題 → Architect subagent
品質問題 → QA Engineer subagent
安全問題 → Security Engineer subagent
部署問題 → SRE Engineer subagent
需求問題 → Product Owner subagent
以上都解決不了 → Stakeholder subagent
3. 升級原則
- 先在同層級嘗試解決：例如 QA 發現安全問題 → 先轉 Security Engineer，不直接升級 Stakeholder。
- 只有升級鏈走完且仍無法解決，才升級到 Stakeholder：每個問題必須先經過對應領域的角色處理，確認無法解決後才能往上升級。
- 升級時必須附帶：問題描述、已嘗試的方案、推薦的選項。缺少任何一項則退回補齊後再升級。
4. Stakeholder 觸發條件
Stakeholder 僅在以下情況介入，其餘一律由團隊自行解決：
- 產品方向重大轉向：涉及產品定位、目標用戶或核心價值主張的根本性變更。
- 團隊內部升級鏈走完仍無法解決的僵局：所有相關角色已參與討論，仍無法達成共識。
- 涉及外部商業承諾的變更：影響已對外承諾的交付時程、功能範圍或合約條款。
5. Stakeholder 決策風格
- 快速決策，不糾結細節：聚焦核心問題，不深入技術實作層面。
- 偏好「先做再迭代」：在資訊不完美的情況下，傾向先選擇一個方向推進，後續再根據回饋調整。
- 回覆格式：直接結論 + 一句話理由。不做冗長分析，給出明確指令讓團隊立即執行。
6. 升級格式
升級報告標準格式見 references/escalation-format.md。
7. 自治原則
團隊自治是預設模式，升級是例外：
- 日常開發免升級：功能代碼撰寫、簡單 Bug 修復、文件小幅更新、測試執行——主 Agent 自行完成，無需觸發任何角色。
- 角色間協調免升級：角色之間的正常協作與意見交換，不視為衝突，無需升級。
- 「沉默即同意」：被知會（Informed）但未回應的決策，團隊可自行推進，不因等待回應而阻塞。
8. 升級流程步驟
以下步驟必須逐項完成，不可跳過：
- 識別問題所屬領域（技術 / 品質 / 安全 / 部署 / 需求）
- 派遣對應領域的 Subagent 嘗試解決
- 若該角色無法解決，檢查是否有其他相關角色可協助（同層級橫向轉介）
- 同層級所有相關角色都無法解決時，準備升級報告（遵循第 6 節格式）
- 將升級報告提交至 Stakeholder subagent
- Stakeholder 做出決策後，將結論傳達給相關角色並執行
9. Subagent 派遣順序
1. 對應領域角色 → 嘗試在專業領域內解決問題
2. 相關角色協助 → 同層級橫向轉介（例：QA → Security）
3. Stakeholder → 升級鏈走完仍無法解決時，提交升級報告