跨平臺功能開發編排器基于 multi-platform-apps 插件的三階段多 Agent 工作流實戰指南【免費下載鏈接】agentsMulti-harness agentic plugin marketplace for Claude Code, Codex, Cursor, OpenCode, GitHub Copilot, and Google Antigravity項目地址: https://gitcode.com/GitHub_Trending/agents24/agents導讀本文剖析 GitHub 推薦項目精選 / agents24 / agents 倉庫中multi-platform-apps插件提供的一等公民能力——multi-platform斜杠命令。它是一個面向一次設計、多端交付的跨平臺功能開發編排器以 API-first 為綱先在架構與 API 契約層對齊再并行推進 Web、iOS、Android、桌面端實現最后完成文檔、測試與優化閉環。讀完本文你將掌握該命令的完整執行協議3 個階段、7 個步驟、2 個強制檢查點、.multi-platform/狀態機工作機制、每個步驟調用的 Agent 職責以及如何將該工作流接入 Claude Code / Codex / Cursor / OpenCode 等多 harness 環境。一、命令定位與使用方式1.1 命令在插件體系中的位置multi-platform命令位于 plugins/multi-platform-apps/commands/multi-platform.md是該插件唯一的命令文件。它與插件目錄下的 6 個專業 Agent 協同工作Agent 文件角色在多平臺工作流中的職責backend-architect.md后端架構師Phase 1 Step 1API 契約與共享數據模型設計ui-ux-designer.mdUI/UX 設計師Phase 1 Step 2跨平臺設計系統與組件規范frontend-developer.md前端工程師Phase 2 Step 4a/4dWeb 與桌面端實現ios-developer.mdiOS 工程師Phase 2 Step 4bSwiftUI 原生實現mobile-developer.md移動端工程師Phase 2 Step 4cKotlin/Compose 實現flutter-expert.mdFlutter 專家可選的統一代碼庫評估方案按倉庫 docs/usage.md 的說明插件安裝后斜杠命令以/plugin-name:command-name [arguments]的命名空間形式調用/multi-platform-apps:multi-platform被歸類在Development Features命令參考中。1.2 參數簽名命令 frontmatter 給出了完整的參數提示argument-hint: feature description [--platforms web,ios,android,desktop] [--shared-code evaluate|kotlin-multiplatform|typescript]三個組成部分feature description功能描述即$ARGUMENTS中位于 flags 之前的部分全文統稱$FEATURE--platforms目標平臺列表默認web,ios,androiddesktop為可選追加平臺--shared-code共享代碼策略可選evaluate評估、kotlin-multiplatform、typescript默認evaluate。典型調用示例/multi-platform-apps:multi-platform real-time order tracking --platforms web,ios,android,desktop --shared-code kotlin-multiplatform1.3 輸出目錄約定整個工作流的全部產物統一落在運行目錄下的.multi-platform/文件夾中編號即執行順序.multi-platform/ ├── 01-api-contracts.md # Step 1 API 契約 ├── 02-design-system.md # Step 2 設計系統 ├── 03-shared-architecture.md# Step 3 共享業務邏輯架構 ├── 04a-web.md # Step 4a Web 實現 ├── 04b-ios.md # Step 4b iOS 實現按需 ├── 04c-android.md # Step 4c Android 實現按需 ├── 04d-desktop.md # Step 4d 桌面端實現按需 ├── 05-api-docs.md # Step 5 API 文檔與測試 ├── 06-testing.md # Step 6 跨平臺一致性測試 ├── 07-optimizations.md # Step 7 平臺級優化 └── state.json # 會話狀態機這一設計背后是文件即記憶的原則每個步驟必須先落盤再進入下一步后續步驟從文件讀取前序產物而不是依賴上下文窗口記憶——保證了長流程中信息不丟失也支持中途斷電后恢復。二、不可違反的行為鐵律命令開篇以 CRITICAL BEHAVIORAL RULES 明示 6 條硬性規則任何違反都視為執行失敗嚴格按順序執行不得跳過、重排或合并步驟先寫文件再繼續每一步必須在.multi-platform/下產出對應文件后才能進入下一步且只能從先前步驟的文件讀取信息在檢查點強制停下到達PHASE CHECKPOINT時必須用 AskUserQuestion 工具給出清晰選項并等待用戶明確批準失敗即停機任一步驟失敗Agent 報錯、測試失敗、依賴缺失必須立即停止向用戶展示錯誤并詢問處理方式不得靜默繼續僅使用本地 Agent所有subagent_type只引用本插件內置 Agent 或general-purpose不允許跨插件依賴禁止自主進入 Plan 模式不得調用 EnterPlanMode——這條命令本身就是計劃直接執行。這 6 條規則把可控性提到了與完成度同等的高度本質是把一次不可逆的大規模開發拆解為可審查、可回滾、可恢復的確定性流水線。三、Pre-flight Checks會話恢復與狀態初始化3.1 已有會話檢查執行前先檢查.multi-platform/state.json是否存在存在且status: in_progress讀取狀態展示當前步驟向用戶二選一Found an in-progress multi-platform development session: Feature: [name from state] Current step: [step from state] 1. Resume from where we left off 2. Start fresh (archives existing session)存在且status: complete詢問是否歸檔后重新開始。這一機制讓中斷的工作流具備真正的可恢復性——所有進度都持久化在state.json而非模型上下文。3.2 狀態機初始化創建.multi-platform/目錄與state.json初始模板如下{ feature: $ARGUMENTS, status: in_progress, platforms: [web, ios, android], shared_code: evaluate, current_step: 1, current_phase: 1, completed_steps: [], files_created: [], started_at: ISO_TIMESTAMP, last_updated: ISO_TIMESTAMP }隨后解析$ARGUMENTS中的--platforms與--shared-code兩個 flag未指定時使用上述默認值并從$ARGUMENTS中提取 flag 之前的文本作為$FEATURE。狀態機的字段演進規律每個步驟完成后current_step遞增Step 3 完成后置為checkpoint-1Step 4 完成后置為checkpoint-2已完成的步驟號追加進completed_steps全部完成后status置為complete并刷新last_updated。checkpoint-*字符串值實際上充當了等待人工批準的暫停標志。四、Phase 1架構與 API 設計Steps 1–3串行Phase 1 的定位是先對齊再動手用一份 API 契約、一份設計系統、一份共享架構文檔鎖定三端或多端實現的事實基礎。Step 1功能需求與 API 契約調用 Task 工具啟動multi-platform-apps-backend-architect對應 backend-architect.md產出 OpenAPI 3.1 規范要求覆蓋使用正確 HTTP 方法與狀態碼的 RESTful 端點復雜數據查詢場景下的 GraphQL schema實時功能所需的 WebSocket 事件帶校驗規則的請求/響應 schema認證與授權要求限流rate limiting與緩存策略錯誤響應格式與錯誤碼。同時要求定義所有平臺共同消費的共享數據模型交付物包括完整 API 規范、共享數據模型、認證流程設計、各平臺集成指南。從 backend-architect.md 的源碼可見該 Agent 的能力矩陣橫跨 REST/GraphQL/gRPC/WebSocket/SSE/Webhook、API 版本化與分頁策略、契約測試Pact 等、SDK 生成其核心行為特征是contract-first清晰定義接口邊界從第一天就內建熔斷、重試、超時等韌性模式——與 Step 1 的要求完全吻合。產出保存為.multi-platform/01-api-contracts.md隨后更新state.jsoncurrent_step置 2Step 1 加入completed_steps。Step 2設計系統與 UI/UX 一致性讀取01-api-contracts.md調用ui-ux-designer對應 ui-ux-designer.md要求交付跨平臺設計系統各平臺組件規范Material Design、iOS HIG、FluentWeb 響應式布局移動優先iOS 原生模式SwiftUI與 Android 原生模式Material You桌面端專項考量鍵盤快捷鍵、窗口管理可訪問性要求WCAG 2.2 Level AA深色/淺色主題規范動畫與轉場指南。從 Agent 源碼看ui-ux-designer.md 具備原子設計方法論、design token 管理、Figma Variables/Style Dictionary、多品牌設計系統治理等能力其行為特征是系統性、可擴展的設計方案而非一次性設計并用研究與測試數據驗證設計決策。注意該 Agent 的 frontmatter 指定了model: sonnet屬于模型分層中的 Tier 3文檔、測試、調試類任務——詳見倉庫 ARCHITECTURE.md 的模型分層表。產出保存為.multi-platform/02-design-system.md。Step 3共享業務邏輯架構同時讀取01-api-contracts.md與02-design-system.md調用general-purposeAgent 完成共享代碼架構設計需定義核心領域模型與實體平臺無關業務規則與校驗邏輯狀態管理模式MVI/Redux/BLoC緩存與離線策略錯誤處理與重試策略平臺特定適配器模式。同時要求考慮共享方案選型移動端用 Kotlin MultiplatformWeb/桌面用 TypeScript。交付物為共享代碼架構文檔、平臺抽象層設計、狀態管理策略、離線/緩存方案與實施指南。產出保存為.multi-platform/03-shared-architecture.mdcurrent_step置為checkpoint-1。五、PHASE CHECKPOINT 1首次人工審查此處必須強制停下向用戶展示三份文檔的核心要點關鍵 API 端點、設計系統組件、共享邏輯方案并給出三選一Architecture and API design complete. Please review: - .multi-platform/01-api-contracts.md - .multi-platform/02-design-system.md - .multi-platform/03-shared-architecture.md 1. Approve — proceed to platform implementation 2. Request changes — tell me what to adjust 3. Pause — save progress and stop here只有用戶選擇選項 1 才能進入 Phase 2選 2 則修訂后重新走檢查點選 3 則更新state.json狀態并停止。這是架構先行理念的人機閉環——在投入并行開發之前先用人類判斷鎖死方向。六、Phase 2并行平臺實現Steps 4a–4d先讀取 Phase 1 的三份產物隨后僅針對state.json中列出的平臺用多個 Task 調用并行發起實現任務。Step 4aWeb 實現React/Next.js調用multi-platform-apps-frontend-developer技術棧約定React 18 與 Next.js 14 App RouterTypeScript 類型安全TanStack Query 做 API 集成Zustand/Redux Toolkit 狀態管理Tailwind CSS 配合設計系統 tokensPWA 能力按需 SSR/SSG 優化Web Vitals 優化LCP 2.5s、FID 100ms。對應 Agent frontend-developer.md 的能力覆蓋 React 19、Next.js 15、RSC、Server Actions、ISR、Core Web Vitals 與無障礙實現其行為特征是用戶體驗與性能同等優先從設計階段就考慮可訪問性。產出存為.multi-platform/04a-web.md。Step 4biOS 實現SwiftUI調用ios-developer約定SwiftUI iOS 17 特性Swift 5.9 與 async/awaitURLSession Combine 集成 APICore Data/SwiftData 持久化平臺特性Face ID、Haptics、Live Activities可測試的 MVVM 架構。對應 Agent ios-developer.md 覆蓋 Swift 6、SwiftUI 5、UIKit 互操作、Core Data/CloudKit、App Store 合規與 ASO行為特征是嚴格遵循 Apple HIG編譯期安全優先。產出存為.multi-platform/04b-ios.md。Step 4cAndroid 實現Kotlin/Compose調用multi-platform-apps-mobile-developer約定Jetpack Compose Material 3Kotlin coroutines 與 FlowRetrofit/Ktor 集成 APIRoom 本地數據庫Hilt 依賴注入Material You 動態主題平臺特性生物認證、widgetsClean Architecture MVI。對應 Agent mobile-developer.md 的能力覆蓋 React Native / Flutter / 原生多路線Step 4c 中它扮演的是 Android 原生專家角色。產出存為.multi-platform/04c-android.md。Step 4d桌面端實現可選Electron/Tauri僅當desktop出現在 platforms 列表時執行仍調用multi-platform-apps-frontend-developer要求 Tauri 2.0 或 Electron并注入 Web 實現產物以最大化復用同時補充原生 OS 集成系統托盤、通知按需文件系統訪問自動更新代碼簽名與公證配置鍵盤快捷鍵與菜單欄多窗口支持。產出存為.multi-platform/04d-desktop.md。全部平臺任務完成后current_step置為checkpoint-2。值得留意的是倉庫還內置了 flutter-expert.md 這一統一代碼庫方案專家Flutter 3.x 覆蓋移動/Web/桌面/嵌入式支持 Material 3 與 Cupertino 雙設計系統當--shared-code評估結論偏向單代碼庫策略時它是 Step 3 架構選型的自然備選。七、PHASE CHECKPOINT 2二次人工審查展示全部平臺實現摘要再次給出批準/變更/暫停三選一未批準不得進入 Phase 3Platform implementations complete. Please review: - .multi-platform/04a-web.md - .multi-platform/04b-ios.md (if applicable) - .multi-platform/04c-android.md (if applicable) - .multi-platform/04d-desktop.md (if applicable) 1. Approve — proceed to integration and validation 2. Request changes — tell me what to adjust 3. Pause — save progress and stop here八、Phase 3集成與驗證Steps 5–7Step 5API 文檔與測試讀取01-api-contracts.md與全部04*.md調用general-purpose技術寫作專家產出交互式 OpenAPI/Swagger 文檔各平臺集成指南各平臺 SDK 示例認證流程圖示限流與配額信息錯誤處理最佳實踐API 版本化策略。并要求用平臺實現實測全部端點。產出存為.multi-platform/05-api-docs.md。Step 6跨平臺測試與功能一致性讀取全部04*.md與05-api-docs.md調用general-purposeQA 工程師驗證功能測試矩陣各平臺行為一致UI 一致性核驗遵循設計系統各平臺性能基準可訪問性測試平臺專用工具網絡韌性測試離線、弱網數據同步校驗平臺特定邊界場景端到端用戶旅程測試。交付功能一致性矩陣、各平臺測試結果、性能基準、發現的平臺偏差與修復建議存為.multi-platform/06-testing.md。Step 7平臺專項優化讀取06-testing.md與全部04*.md調用general-purpose性能工程師按平臺逐項優化Web包體積、懶加載、CDN、SEOiOSApp 體積、啟動時間、內存、電量AndroidAPK 體積、啟動時間、幀率、電量Desktop二進制體積、資源占用、啟動時間API響應時間、緩存、壓縮。要求在維持功能一致性的前提下發揮平臺優勢并記錄優化技術與取舍。產出存為.multi-platform/07-optimizations.mdcurrent_step置為complete。九、完成與驗收標準最后將state.json的status置為complete并刷新last_updated呈現最終摘要。命令內置的 Success Criteria 可作為團隊驗收清單API 契約在實現前已定義并驗證所有平臺達成功能一致差異 5%性能指標滿足各平臺標準可訪問性達標WCAG 2.2 AA 為最低要求跨平臺測試顯示行為一致所有平臺文檔完整適用場景下平臺間代碼復用率 40%。后續動作建議逐平臺審查生成的代碼與文檔 → 運行平臺專用測試套件 → 按平臺創建 PR → 用平臺專用流水線部署 → 上線后監控跨平臺指標。十、設計原理與最佳實踐總結10.1 與倉庫架構規范的呼應從 ARCHITECTURE.md 可以確認本命令遵循倉庫的兩條核心約定一是插件為安裝單元命令/Agent/技能隨插件整體安裝/plugin install multi-platform-apps后即可使用二是源內容可移植命令文件以純 Markdown 編寫由tools/adapters/下的適配器在生成期映射到各 harness 的原生格式如 Codex 的 TOML、OpenCode 的 command 目錄、Copilot 的 commands-as-skills、Antigravity 的插件格式因此本文描述的工作流在多個 harness 中均可運行只是調用語法隨平臺略有差異。10.2 可借鑒的三條工程實踐文件即狀態用state.json 編號 markdown 產物替代上下文記憶使長流程可恢復、可審計、可中斷續跑人機檢查點兩個強制 PHASE CHECKPOINT 把大規模并行開發拆成架構批準 → 實現批準 → 集成驗證三個可逆階段把返工成本前置到最低點契約先行 并行收斂先鎖定 API 契約與設計系統再并行實現多端最后用一致性矩陣與性能優化收口——這正是跨平臺交付減少返工、提高復用的關鍵路徑。10.3 使用前提與限制本命令依賴插件內置的 6 個 Agent 與general-purpose需保證所在 harness 支持 Task/subagent 機制產物目錄.multi-platform/為運行時生成命令本身不修改倉庫內容生成的代碼與文檔由用戶決定如何提交--platforms中列出的平臺會決定 4a–4d 的執行分支--shared-code的三種取值會影響 Step 3 的架構選型方向建議在調用前明確兩者。相關文件速查命令定義 multi-platform.md Agent 組 backend-architect.md、ui-ux-designer.md、frontend-developer.md、ios-developer.md、mobile-developer.md、flutter-expert.md 使用手冊 docs/usage.md 架構規范 ARCHITECTURE.md【免費下載鏈接】agentsMulti-harness agentic plugin marketplace for Claude Code, Codex, Cursor, OpenCode, GitHub Copilot, and Google Antigravity項目地址: https://gitcode.com/GitHub_Trending/agents24/agents創作聲明：本文部分內容由AI輔助生成（AIGC），僅供參考 跨平臺功能開發編排器：基于 multi-platform-apps 插件的三階段多 Agent 工作流實戰指南
跨平臺功能開發編排器基于 multi-platform-apps 插件的三階段多 Agent 工作流實戰指南【免費下載鏈接】agentsMulti-harness agentic plugin marketplace for Claude Code, Codex, Cursor, OpenCode, GitHub Copilot, and Google Antigravity項目地址: https://gitcode.com/GitHub_Trending/agents24/agents導讀本文剖析 GitHub 推薦項目精選 / agents24 / agents 倉庫中multi-platform-apps插件提供的一等公民能力——multi-platform斜杠命令。它是一個面向一次設計、多端交付的跨平臺功能開發編排器以 API-first 為綱先在架構與 API 契約層對齊再并行推進 Web、iOS、Android、桌面端實現最后完成文檔、測試與優化閉環。讀完本文你將掌握該命令的完整執行協議3 個階段、7 個步驟、2 個強制檢查點、.multi-platform/狀態機工作機制、每個步驟調用的 Agent 職責以及如何將該工作流接入 Claude Code / Codex / Cursor / OpenCode 等多 harness 環境。一、命令定位與使用方式1.1 命令在插件體系中的位置multi-platform命令位于 plugins/multi-platform-apps/commands/multi-platform.md是該插件唯一的命令文件。它與插件目錄下的 6 個專業 Agent 協同工作Agent 文件角色在多平臺工作流中的職責backend-architect.md后端架構師Phase 1 Step 1API 契約與共享數據模型設計ui-ux-designer.mdUI/UX 設計師Phase 1 Step 2跨平臺設計系統與組件規范frontend-developer.md前端工程師Phase 2 Step 4a/4dWeb 與桌面端實現ios-developer.mdiOS 工程師Phase 2 Step 4bSwiftUI 原生實現mobile-developer.md移動端工程師Phase 2 Step 4cKotlin/Compose 實現flutter-expert.mdFlutter 專家可選的統一代碼庫評估方案按倉庫 docs/usage.md 的說明插件安裝后斜杠命令以/plugin-name:command-name [arguments]的命名空間形式調用/multi-platform-apps:multi-platform被歸類在Development Features命令參考中。1.2 參數簽名命令 frontmatter 給出了完整的參數提示argument-hint: feature description [--platforms web,ios,android,desktop] [--shared-code evaluate|kotlin-multiplatform|typescript]三個組成部分feature description功能描述即$ARGUMENTS中位于 flags 之前的部分全文統稱$FEATURE--platforms目標平臺列表默認web,ios,androiddesktop為可選追加平臺--shared-code共享代碼策略可選evaluate評估、kotlin-multiplatform、typescript默認evaluate。典型調用示例/multi-platform-apps:multi-platform real-time order tracking --platforms web,ios,android,desktop --shared-code kotlin-multiplatform1.3 輸出目錄約定整個工作流的全部產物統一落在運行目錄下的.multi-platform/文件夾中編號即執行順序.multi-platform/ ├── 01-api-contracts.md # Step 1 API 契約 ├── 02-design-system.md # Step 2 設計系統 ├── 03-shared-architecture.md# Step 3 共享業務邏輯架構 ├── 04a-web.md # Step 4a Web 實現 ├── 04b-ios.md # Step 4b iOS 實現按需 ├── 04c-android.md # Step 4c Android 實現按需 ├── 04d-desktop.md # Step 4d 桌面端實現按需 ├── 05-api-docs.md # Step 5 API 文檔與測試 ├── 06-testing.md # Step 6 跨平臺一致性測試 ├── 07-optimizations.md # Step 7 平臺級優化 └── state.json # 會話狀態機這一設計背后是文件即記憶的原則每個步驟必須先落盤再進入下一步后續步驟從文件讀取前序產物而不是依賴上下文窗口記憶——保證了長流程中信息不丟失也支持中途斷電后恢復。二、不可違反的行為鐵律命令開篇以 CRITICAL BEHAVIORAL RULES 明示 6 條硬性規則任何違反都視為執行失敗嚴格按順序執行不得跳過、重排或合并步驟先寫文件再繼續每一步必須在.multi-platform/下產出對應文件后才能進入下一步且只能從先前步驟的文件讀取信息在檢查點強制停下到達PHASE CHECKPOINT時必須用 AskUserQuestion 工具給出清晰選項并等待用戶明確批準失敗即停機任一步驟失敗Agent 報錯、測試失敗、依賴缺失必須立即停止向用戶展示錯誤并詢問處理方式不得靜默繼續僅使用本地 Agent所有subagent_type只引用本插件內置 Agent 或general-purpose不允許跨插件依賴禁止自主進入 Plan 模式不得調用 EnterPlanMode——這條命令本身就是計劃直接執行。這 6 條規則把可控性提到了與完成度同等的高度本質是把一次不可逆的大規模開發拆解為可審查、可回滾、可恢復的確定性流水線。三、Pre-flight Checks會話恢復與狀態初始化3.1 已有會話檢查執行前先檢查.multi-platform/state.json是否存在存在且status: in_progress讀取狀態展示當前步驟向用戶二選一Found an in-progress multi-platform development session: Feature: [name from state] Current step: [step from state] 1. Resume from where we left off 2. Start fresh (archives existing session)存在且status: complete詢問是否歸檔后重新開始。這一機制讓中斷的工作流具備真正的可恢復性——所有進度都持久化在state.json而非模型上下文。3.2 狀態機初始化創建.multi-platform/目錄與state.json初始模板如下{ feature: $ARGUMENTS, status: in_progress, platforms: [web, ios, android], shared_code: evaluate, current_step: 1, current_phase: 1, completed_steps: [], files_created: [], started_at: ISO_TIMESTAMP, last_updated: ISO_TIMESTAMP }隨后解析$ARGUMENTS中的--platforms與--shared-code兩個 flag未指定時使用上述默認值并從$ARGUMENTS中提取 flag 之前的文本作為$FEATURE。狀態機的字段演進規律每個步驟完成后current_step遞增Step 3 完成后置為checkpoint-1Step 4 完成后置為checkpoint-2已完成的步驟號追加進completed_steps全部完成后status置為complete并刷新last_updated。checkpoint-*字符串值實際上充當了等待人工批準的暫停標志。四、Phase 1架構與 API 設計Steps 1–3串行Phase 1 的定位是先對齊再動手用一份 API 契約、一份設計系統、一份共享架構文檔鎖定三端或多端實現的事實基礎。Step 1功能需求與 API 契約調用 Task 工具啟動multi-platform-apps-backend-architect對應 backend-architect.md產出 OpenAPI 3.1 規范要求覆蓋使用正確 HTTP 方法與狀態碼的 RESTful 端點復雜數據查詢場景下的 GraphQL schema實時功能所需的 WebSocket 事件帶校驗規則的請求/響應 schema認證與授權要求限流rate limiting與緩存策略錯誤響應格式與錯誤碼。同時要求定義所有平臺共同消費的共享數據模型交付物包括完整 API 規范、共享數據模型、認證流程設計、各平臺集成指南。從 backend-architect.md 的源碼可見該 Agent 的能力矩陣橫跨 REST/GraphQL/gRPC/WebSocket/SSE/Webhook、API 版本化與分頁策略、契約測試Pact 等、SDK 生成其核心行為特征是contract-first清晰定義接口邊界從第一天就內建熔斷、重試、超時等韌性模式——與 Step 1 的要求完全吻合。產出保存為.multi-platform/01-api-contracts.md隨后更新state.jsoncurrent_step置 2Step 1 加入completed_steps。Step 2設計系統與 UI/UX 一致性讀取01-api-contracts.md調用ui-ux-designer對應 ui-ux-designer.md要求交付跨平臺設計系統各平臺組件規范Material Design、iOS HIG、FluentWeb 響應式布局移動優先iOS 原生模式SwiftUI與 Android 原生模式Material You桌面端專項考量鍵盤快捷鍵、窗口管理可訪問性要求WCAG 2.2 Level AA深色/淺色主題規范動畫與轉場指南。從 Agent 源碼看ui-ux-designer.md 具備原子設計方法論、design token 管理、Figma Variables/Style Dictionary、多品牌設計系統治理等能力其行為特征是系統性、可擴展的設計方案而非一次性設計并用研究與測試數據驗證設計決策。注意該 Agent 的 frontmatter 指定了model: sonnet屬于模型分層中的 Tier 3文檔、測試、調試類任務——詳見倉庫 ARCHITECTURE.md 的模型分層表。產出保存為.multi-platform/02-design-system.md。Step 3共享業務邏輯架構同時讀取01-api-contracts.md與02-design-system.md調用general-purposeAgent 完成共享代碼架構設計需定義核心領域模型與實體平臺無關業務規則與校驗邏輯狀態管理模式MVI/Redux/BLoC緩存與離線策略錯誤處理與重試策略平臺特定適配器模式。同時要求考慮共享方案選型移動端用 Kotlin MultiplatformWeb/桌面用 TypeScript。交付物為共享代碼架構文檔、平臺抽象層設計、狀態管理策略、離線/緩存方案與實施指南。產出保存為.multi-platform/03-shared-architecture.mdcurrent_step置為checkpoint-1。五、PHASE CHECKPOINT 1首次人工審查此處必須強制停下向用戶展示三份文檔的核心要點關鍵 API 端點、設計系統組件、共享邏輯方案并給出三選一Architecture and API design complete. Please review: - .multi-platform/01-api-contracts.md - .multi-platform/02-design-system.md - .multi-platform/03-shared-architecture.md 1. Approve — proceed to platform implementation 2. Request changes — tell me what to adjust 3. Pause — save progress and stop here只有用戶選擇選項 1 才能進入 Phase 2選 2 則修訂后重新走檢查點選 3 則更新state.json狀態并停止。這是架構先行理念的人機閉環——在投入并行開發之前先用人類判斷鎖死方向。六、Phase 2并行平臺實現Steps 4a–4d先讀取 Phase 1 的三份產物隨后僅針對state.json中列出的平臺用多個 Task 調用并行發起實現任務。Step 4aWeb 實現React/Next.js調用multi-platform-apps-frontend-developer技術棧約定React 18 與 Next.js 14 App RouterTypeScript 類型安全TanStack Query 做 API 集成Zustand/Redux Toolkit 狀態管理Tailwind CSS 配合設計系統 tokensPWA 能力按需 SSR/SSG 優化Web Vitals 優化LCP 2.5s、FID 100ms。對應 Agent frontend-developer.md 的能力覆蓋 React 19、Next.js 15、RSC、Server Actions、ISR、Core Web Vitals 與無障礙實現其行為特征是用戶體驗與性能同等優先從設計階段就考慮可訪問性。產出存為.multi-platform/04a-web.md。Step 4biOS 實現SwiftUI調用ios-developer約定SwiftUI iOS 17 特性Swift 5.9 與 async/awaitURLSession Combine 集成 APICore Data/SwiftData 持久化平臺特性Face ID、Haptics、Live Activities可測試的 MVVM 架構。對應 Agent ios-developer.md 覆蓋 Swift 6、SwiftUI 5、UIKit 互操作、Core Data/CloudKit、App Store 合規與 ASO行為特征是嚴格遵循 Apple HIG編譯期安全優先。產出存為.multi-platform/04b-ios.md。Step 4cAndroid 實現Kotlin/Compose調用multi-platform-apps-mobile-developer約定Jetpack Compose Material 3Kotlin coroutines 與 FlowRetrofit/Ktor 集成 APIRoom 本地數據庫Hilt 依賴注入Material You 動態主題平臺特性生物認證、widgetsClean Architecture MVI。對應 Agent mobile-developer.md 的能力覆蓋 React Native / Flutter / 原生多路線Step 4c 中它扮演的是 Android 原生專家角色。產出存為.multi-platform/04c-android.md。Step 4d桌面端實現可選Electron/Tauri僅當desktop出現在 platforms 列表時執行仍調用multi-platform-apps-frontend-developer要求 Tauri 2.0 或 Electron并注入 Web 實現產物以最大化復用同時補充原生 OS 集成系統托盤、通知按需文件系統訪問自動更新代碼簽名與公證配置鍵盤快捷鍵與菜單欄多窗口支持。產出存為.multi-platform/04d-desktop.md。全部平臺任務完成后current_step置為checkpoint-2。值得留意的是倉庫還內置了 flutter-expert.md 這一統一代碼庫方案專家Flutter 3.x 覆蓋移動/Web/桌面/嵌入式支持 Material 3 與 Cupertino 雙設計系統當--shared-code評估結論偏向單代碼庫策略時它是 Step 3 架構選型的自然備選。七、PHASE CHECKPOINT 2二次人工審查展示全部平臺實現摘要再次給出批準/變更/暫停三選一未批準不得進入 Phase 3Platform implementations complete. Please review: - .multi-platform/04a-web.md - .multi-platform/04b-ios.md (if applicable) - .multi-platform/04c-android.md (if applicable) - .multi-platform/04d-desktop.md (if applicable) 1. Approve — proceed to integration and validation 2. Request changes — tell me what to adjust 3. Pause — save progress and stop here八、Phase 3集成與驗證Steps 5–7Step 5API 文檔與測試讀取01-api-contracts.md與全部04*.md調用general-purpose技術寫作專家產出交互式 OpenAPI/Swagger 文檔各平臺集成指南各平臺 SDK 示例認證流程圖示限流與配額信息錯誤處理最佳實踐API 版本化策略。并要求用平臺實現實測全部端點。產出存為.multi-platform/05-api-docs.md。Step 6跨平臺測試與功能一致性讀取全部04*.md與05-api-docs.md調用general-purposeQA 工程師驗證功能測試矩陣各平臺行為一致UI 一致性核驗遵循設計系統各平臺性能基準可訪問性測試平臺專用工具網絡韌性測試離線、弱網數據同步校驗平臺特定邊界場景端到端用戶旅程測試。交付功能一致性矩陣、各平臺測試結果、性能基準、發現的平臺偏差與修復建議存為.multi-platform/06-testing.md。Step 7平臺專項優化讀取06-testing.md與全部04*.md調用general-purpose性能工程師按平臺逐項優化Web包體積、懶加載、CDN、SEOiOSApp 體積、啟動時間、內存、電量AndroidAPK 體積、啟動時間、幀率、電量Desktop二進制體積、資源占用、啟動時間API響應時間、緩存、壓縮。要求在維持功能一致性的前提下發揮平臺優勢并記錄優化技術與取舍。產出存為.multi-platform/07-optimizations.mdcurrent_step置為complete。九、完成與驗收標準最后將state.json的status置為complete并刷新last_updated呈現最終摘要。命令內置的 Success Criteria 可作為團隊驗收清單API 契約在實現前已定義并驗證所有平臺達成功能一致差異 5%性能指標滿足各平臺標準可訪問性達標WCAG 2.2 AA 為最低要求跨平臺測試顯示行為一致所有平臺文檔完整適用場景下平臺間代碼復用率 40%。后續動作建議逐平臺審查生成的代碼與文檔 → 運行平臺專用測試套件 → 按平臺創建 PR → 用平臺專用流水線部署 → 上線后監控跨平臺指標。十、設計原理與最佳實踐總結10.1 與倉庫架構規范的呼應從 ARCHITECTURE.md 可以確認本命令遵循倉庫的兩條核心約定一是插件為安裝單元命令/Agent/技能隨插件整體安裝/plugin install multi-platform-apps后即可使用二是源內容可移植命令文件以純 Markdown 編寫由tools/adapters/下的適配器在生成期映射到各 harness 的原生格式如 Codex 的 TOML、OpenCode 的 command 目錄、Copilot 的 commands-as-skills、Antigravity 的插件格式因此本文描述的工作流在多個 harness 中均可運行只是調用語法隨平臺略有差異。10.2 可借鑒的三條工程實踐文件即狀態用state.json 編號 markdown 產物替代上下文記憶使長流程可恢復、可審計、可中斷續跑人機檢查點兩個強制 PHASE CHECKPOINT 把大規模并行開發拆成架構批準 → 實現批準 → 集成驗證三個可逆階段把返工成本前置到最低點契約先行 并行收斂先鎖定 API 契約與設計系統再并行實現多端最后用一致性矩陣與性能優化收口——這正是跨平臺交付減少返工、提高復用的關鍵路徑。10.3 使用前提與限制本命令依賴插件內置的 6 個 Agent 與general-purpose需保證所在 harness 支持 Task/subagent 機制產物目錄.multi-platform/為運行時生成命令本身不修改倉庫內容生成的代碼與文檔由用戶決定如何提交--platforms中列出的平臺會決定 4a–4d 的執行分支--shared-code的三種取值會影響 Step 3 的架構選型方向建議在調用前明確兩者。相關文件速查命令定義 multi-platform.md Agent 組 backend-architect.md、ui-ux-designer.md、frontend-developer.md、ios-developer.md、mobile-developer.md、flutter-expert.md 使用手冊 docs/usage.md 架構規范 ARCHITECTURE.md【免費下載鏈接】agentsMulti-harness agentic plugin marketplace for Claude Code, Codex, Cursor, OpenCode, GitHub Copilot, and Google Antigravity項目地址: https://gitcode.com/GitHub_Trending/agents24/agents創作聲明：本文部分內容由AI輔助生成（AIGC），僅供參考