用 ruv-swarm 将 AI Swarm 与 GitHub Projects 双向同步：Project Board Sync 实战指南

将一组自治 AI Agent（Swarm）与 GitHub Projects 看板打通，是让智能体任务走向“可视化、可追踪、可协作”的关键一步。本指南以仓库中 Project Board Sync 命令定义 为骨架，完整覆盖从看板初始化、状态双向映射、实时同步、自动化卡片流转，到冲刺管理、报表分析与故障排查的全部操作，帮助你在 AI 多智能体工作流中落地一套“智能体干活、看板说话”的团队协作体系。读完你将掌握完整的 ruv-swarm github board-* 命令族用法、.github/board-sync.yml 映射配置模型，以及如何借助 gh CLI 实现真正的端到端同步。

一、命令定位：这份文档在仓库里扮演什么角色

在 ruflo（claude-flow v3）仓库中，Project Board Sync 是一份标准的 Claude Code 命令定义文件，仓库内以多种形态存在：

• 命令本体：.claude/commands/github/project-board-sync.md，即本文依据的核心文档；
• 对应 Agent 化定义：.claude/agents/github/project-board-sync.md，说明同一能力既可作命令触发，也可作为具名 Agent 参与 swarm 协作；
• 插件分发形态：plugin/commands/github/project-board-sync.md，随插件目录发布；
• v3 打包形态：v3/@claude-flow/cli/.claude/commands/github/project-board-sync.md 及 v3/@claude-flow/mcp/.claude/commands/github/project-board-sync.md。

它归属于仓库的 github 命令族（见 .claude/commands/github/README.md），与 github-swarm.md、swarm-issue.md、multi-repo-swarm.md、workflow-automation.md、sync-coordinator.md 等协同工作。其中 swarm-issue 处理“Issue → 任务”，multi-repo-swarm 负责跨仓库联邦，而本命令聚焦“任务 ↔ 看板卡片”的可视化同步。文档末尾的 “See also” 也明确指向这两个兄弟命令，说明它们共同构成一套完整的智能体仓库工作流。

说明：以下命令统一通过 npx ruv-swarm 入口调用（ruv-swarm 即仓库所描述的多智能体 swarm 编排工具链），对 GitHub Projects 的底层读写则借助官方 gh CLI 完成。仓库对 swarm 编排的整体定位可参考根目录 package.json 中对 “agent orchestration … swarms” 的描述及 README.md。

二、看板初始化：三步把 Swarm 接上 GitHub Projects

1. 用 gh CLI 获取 Project ID

GitHub Projects v2 的所有读写都基于 Project ID 而非名称，因此第一步是用 gh 定位目标项目：

# 列出当前用户的项目并筛选出名为 "Development Board" 的那个
PROJECT_ID=$(gh project list --owner @me --format json | \
  jq -r '.projects[] | select(.title == "Development Board") | .id')

要点说明：

• --owner @me 表示操作当前登录账号的 Projects；若要操作组织级项目，可替换为 --owner <org-name>；
• --format json 配合 jq 可以稳定提取 id 字段，避免解析人读文本格式带来的脆弱性；
• 若项目属于某个仓库而非个人，还可使用 gh project list --owner <owner> --repo <repo> 缩小范围。

2. 初始化 swarm 与项目的连接

npx ruv-swarm github board-init \
  --project-id "$PROJECT_ID" \
  --sync-mode "bidirectional" \
  --create-views "swarm-status,agent-workload,priority"

各参数作用：

参数	取值示例	说明
--project-id	上一步得到的 ID	绑定的 GitHub Projects 项目
--sync-mode	bidirectional / one-way	bidirectional 表示 swarm 内部任务状态与看板卡片双向同步；单向模式则以一端为准
--create-views	swarm-status,agent-workload,priority	逗号分隔的预建视图名称，初始化时自动生成三类典型视图（详见“视图配置”一节）

3. 为项目创建 swarm 追踪字段

GitHub Projects 的字段（Fields）用于承载卡片的状态、负责人、优先级等元数据。用 gh 创建单选项字段供 swarm 状态使用：

gh project field-create $PROJECT_ID --owner @me \
  --name "Swarm Status" \
  --data-type "SINGLE_SELECT" \
  --single-select-options "pending,in_progress,completed"

SINGLE_SELECT 之外，Projects v2 还支持 TEXT、NUMBER、DATE、ITERATION 等字段类型——文档后续“映射配置”一节中的自定义字段 Agent Count（number）、ETA（date）即对应后两种，可在初始化阶段一并规划。

三、任务同步：状态映射与双向同步

初始化完成后，核心操作是将 swarm 内部的任务状态持续同步到看板卡片：

npx ruv-swarm github board-sync \
  --map-status '{
    "todo": "To Do",
    "in_progress": "In Progress",
    "review": "Review",
    "done": "Done"
  }' \
  --auto-move-cards \
  --update-metadata

参数解读：

• --map-status：JSON 形式的状态映射表。key 是 swarm 内部任务状态（如 todo/in_progress/review/done），value 是 GitHub 看板列名。这里的“列名”应与看板实际列一致，也可以对应到 Projects 的自定义 Status 字段选项；
• --auto-move-cards：任务状态变化后自动移动卡片到对应列，无需人工干预；
• --update-metadata：同步时顺带刷新卡片的字段元数据（优先级、负责人、标签等）。

状态映射是双向同步的“翻译层”：swarm 侧状态推进会写回卡片列，而看板上人工拖拽引起的列变化同样会被捕获并更新 swarm 侧任务状态。为保证映射收敛，文档在“最佳实践”中特别强调要做“双向同步校验”（Bidirectional sync validation）并预先定义冲突解决策略。

四、实时更新：Webhook 驱动与批量策略

npx ruv-swarm github board-realtime \
  --webhook-endpoint "https://api.example.com/github-sync" \
  --update-frequency "immediate" \
  --batch-updates false

• --webhook-endpoint：接收 GitHub webhook 推送的回调地址。当看板上发生卡片移动、字段变更时，GitHub 通过 webhook 通知该端点，驱动增量同步而非轮询；
• --update-frequency：immediate（事件即达即同步）或其他间隔值。当 webhook 链路暂时不可用时，可回退为定时同步；
• --batch-updates：false 表示逐事件即时处理；置为 true 则把短时间窗口内的多个事件合并为一次批量写操作，以降低 GitHub API 请求频率、规避 rate limit（这也是 故障排查 一节中反复出现的考量点）。

需要说明的是，自建 webhook 端点通常要求公网可达；若环境不具备，文档提供了折中方案——用定时任务 + 增量拉取替代推送，即后续 “board-diagnose” 中的 --test-sync 自检能力。

五、Board 映射配置：一份文件管住状态、Agent 与字段

实时同步的智能程度取决于映射配置。将如下内容写入仓库 .github/board-sync.yml：

# .github/board-sync.yml
version: 1
project:
  name: "AI Development Board"
  number: 1

mapping:
  # Map swarm task status to board columns
  status:
    pending: "Backlog"
    assigned: "Ready"
    in_progress: "In Progress"
    review: "Review"
    completed: "Done"
    blocked: "Blocked"

  # Map agent types to labels
  agents:
    coder: "🔧 Development"
    tester: "🧪 Testing"
    analyst: "📊 Analysis"
    designer: "🎨 Design"
    architect: "🏗️ Architecture"

  # Map priority to project fields
  priority:
    critical: "🔴 Critical"
    high: "🟡 High"
    medium: "🟢 Medium"
    low: "⚪ Low"

  # Custom fields
  fields:
    - name: "Agent Count"
      type: number
      source: task.agents.length
    - name: "Complexity"
      type: select
      source: task.complexity
    - name: "ETA"
      type: date
      source: task.estimatedCompletion

逐段解读：

配置块	职责	说明
project	目标项目标识	name + number 定位 Projects v2 项目（number 即项目 URL 中的编号），也可在初始化时改用 --project-id 精确绑定
mapping.status	任务状态 → 看板列	覆盖 swarm 全生命周期状态：pending（待办）、assigned（已指派）、in_progress、review（评审）、completed、blocked（受阻）
mapping.agents	Agent 类型 → 标签	把执行任务的智能体角色映射为卡片标签，便于按角色筛选与统计负载；仓库插件体系中的 coder/tester/analyst/architect 等 Agent 定义可见于 .claude/agents/github 及各插件 agents 目录
mapping.priority	优先级 → 字段选项	与项目 Priority 字段的选项对应
mapping.fields	自定义字段计算源	三类来源表达式最值得关注：task.agents.length 表示取任务所关联 Agent 列表的长度（数值型）；task.complexity 取任务复杂度枚举；task.estimatedCompletion 取预估完成时间（日期型），供路线图视图做时间轴排序

这份配置与第二节中 gh project field-create 创建的项目字段一一呼应：优先建议在初始化阶段先用 gh CLI 建好对应字段与选项，再让 board-sync.yml 中的映射去消费它们，避免字段不存在导致写失败。

六、视图配置：Board / Table / Roadmap 三种视图模型

在 .github/board-sync.yml 同级或初始化时指定的视图清单中，可自定义三类视图：

// Custom board views
{
  "views": [
    {
      "name": "Swarm Overview",
      "type": "board",
      "groupBy": "status",
      "filters": ["is:open"],
      "sort": "priority:desc"
    },
    {
      "name": "Agent Workload",
      "type": "table",
      "groupBy": "assignedAgent",
      "columns": ["title", "status", "priority", "eta"],
      "sort": "eta:asc"
    },
    {
      "name": "Sprint Progress",
      "type": "roadmap",
      "dateField": "eta",
      "groupBy": "milestone"
    }
  ]
}

• type: board：看板视图，groupBy: status 按状态分列，filters: ["is:open"] 沿用 GitHub Issue 的搜索过滤语法，sort: "priority:desc" 让高优卡片置顶；
• type: table：表格视图，columns 显式声明展示列，assignedAgent 分组可直观看到每个 Agent 手上的卡片数，配合 eta:asc 把最早到期项排最前，形成“Agent 工作负载”视图；
• type: roadmap：路线图视图，dateField: eta 指定时间字段，groupBy: milestone 按里程碑聚合，用于冲刺/发布节奏管理。

board-init --create-views "swarm-status,agent-workload,priority" 中的三个名字正是这三种形态的预设实例，实际项目可按需增删。

七、自动化能力：指派、进度与智能移卡

1. Auto-Assignment：按负载均衡自动指派

npx ruv-swarm github board-auto-assign \
  --strategy "load-balanced" \
  --consider "expertise,workload,availability" \
  --update-cards

• --strategy load-balanced：以各 Agent 当前卡片数为依据均衡分配；
• --consider expertise,workload,availability：评分维度，优先匹配专长（对应 agents 目录中各专职 Agent 定义）、兼顾负载与可用性；
• --update-cards：指派后同步写回卡片 Assignees。

2. Progress Tracking：可视化进度

npx ruv-swarm github board-progress \
  --show "burndown,velocity,cycle-time" \
  --time-period "sprint" \
  --export-metrics

按冲刺周期计算燃尽曲线、迭代速率与周期时长，--export-metrics 导出结构化指标，供后续报表与看板部件消费。

3. Smart Card Movement：规则驱动的状态迁移

npx ruv-swarm github board-smart-move \
  --rules '{
    "auto-progress": "when:all-subtasks-done",
    "auto-review": "when:tests-pass",
    "auto-done": "when:pr-merged"
  }'

规则引擎逐条判定触发条件：子任务全部完成 → 卡片进入 In Progress；测试通过 → 进入 Review；PR 合并 → 标记 Done。这正是把“Agent 干活结果”翻译成“看板状态事实”的自动化落点，可与仓库的自动化能力体系（参见 workflow-automation.md）组合使用。

八、看板命令族：导入、批量、模板

从 Issue 创建卡片

# Convert issues to project cards using gh CLI
# List issues with label
ISSUES=$(gh issue list --label "enhancement" --json number,title,body)

# Add issues to project
echo "$ISSUES" | jq -r '.[].number' | while read -r issue; do
  gh project item-add $PROJECT_ID --owner @me --url "https://github.com/$GITHUB_REPOSITORY/issues/$issue"
done

# Process with swarm
npx ruv-swarm github board-import-issues \
  --issues "$ISSUES" \
  --add-to-column "Backlog" \
  --parse-checklist \
  --assign-agents

• 先用 gh issue list 按标签筛选待导入 Issue（$GITHUB_REPOSITORY 为 CI 中常见的 owner/repo 环境变量）；
• gh project item-add --url ... 把 Issue 逐个加入项目（Projects v2 中 Item 与 Issue 是一对一的引用关系，故用 URL 即可关联）；
• 最后交给 swarm 做增强处理：--parse-checklist 将 Issue 的 checklist 拆成子任务，--assign-agents 按负载自动指派 Agent。Issue 深度处理的可复用做法可参考 issue-triage.md 与 swarm-issue.md。

批量操作与模板建卡

# Bulk card operations
npx ruv-swarm github board-bulk \
  --filter "status:blocked" \
  --action "add-label:needs-attention" \
  --notify-assignees

# Create cards from templates
npx ruv-swarm github board-template \
  --template "feature-development" \
  --variables '{
    "feature": "User Authentication",
    "priority": "high",
    "agents": ["architect", "coder", "tester"]
  }' \
  --create-subtasks

• board-bulk：按过滤条件圈定卡片集合，执行统一动作（如打标签），并可选通知 Assignees。适合“所有 blocked 卡片一键标记”这类治理操作；
• board-template：用参数化模板批量建卡。模板声明了 feature/priority/agents 等变量，--create-subtasks 同时按模板创建子任务卡片，且 agents 数组会驱动后续的自动指派——一个“功能卡片”可由此自动长成一棵含架构、编码、测试分工的任务树。

九、进阶同步：多看板、跨组织与外部工具

# Sync across multiple boards
npx ruv-swarm github multi-board-sync \
  --boards "Development,QA,Release" \
  --sync-rules '{
    "Development->QA": "when:ready-for-test",
    "QA->Release": "when:tests-pass"
  }'

# Sync boards across organizations
npx ruv-swarm github cross-org-sync \
  --source "org1/Project-A" \
  --target "org2/Project-B" \
  --field-mapping "custom" \
  --conflict-resolution "source-wins"

# Sync with external tools
npx ruv-swarm github board-integrate \
  --tool "jira" \
  --mapping "bidirectional" \
  --sync-frequency "5m" \
  --transform-rules "custom"

• 多看板同步：在阶段化交付管线（Development → QA → Release）中，用 sync-rules 声明跨看板的流转条件，等价于把状态机从“单板内列”提升到“多板间列”；
• 跨组织同步：以 org/项目名 为地址，支持自定义字段映射，冲突时按 source-wins（源端优先）等策略裁决。跨组织/跨仓库协作在 ruflo 生态中对应联邦能力，仓库为多仓库场景单独维护了 multi-repo-swarm.md 与 sync-coordinator 相关定义，可在更大规模的联邦协作中组合使用；
• 外部工具集成：board-integrate 打通 Jira 等第三方看板，双向映射 + 定时（5m）+ 自定义转换规则，适合既有工具链迁移期双写过渡。

十、可视化、报表与看板分析

基于 gh CLI 数据源生成分析

# Fetch project data
PROJECT_DATA=$(gh project item-list $PROJECT_ID --owner @me --format json)

# Get issue metrics
ISSUE_METRICS=$(echo "$PROJECT_DATA" | jq -r '.items[] | select(.content.type == "Issue")' | \
  while read -r item; do
    ISSUE_NUM=$(echo "$item" | jq -r '.content.number')
    gh issue view $ISSUE_NUM --json createdAt,closedAt,labels,assignees
  done)

# Generate analytics with swarm
npx ruv-swarm github board-analytics \
  --project-data "$PROJECT_DATA" \
  --issue-metrics "$ISSUE_METRICS" \
  --metrics "throughput,cycle-time,wip" \
  --group-by "agent,priority,type" \
  --time-range "30d" \
  --export "dashboard"

先拉取项目内全部 Item，再对 Issue 类型逐条补充 createdAt/closedAt/labels/assignees 元数据，构成指标计算的两级数据源；board-analytics 据此计算吞吐率、周期时长、在制品数量，并按 Agent/优先级/类型多维度分组，--export dashboard 导出为后续自定义仪表盘可消费的数据。

自定义仪表盘与报告

{
  "dashboard": {
    "widgets": [
      {
        "type": "chart",
        "title": "Task Completion Rate",
        "data": "completed-per-day",
        "visualization": "line"
      },
      {
        "type": "gauge",
        "title": "Sprint Progress",
        "data": "sprint-completion",
        "target": 100
      },
      {
        "type": "heatmap",
        "title": "Agent Activity",
        "data": "agent-tasks-per-day"
      }
    ]
  }
}

部件类型与数据源一览：

type	适用场景	数据源示例
chart	趋势分析（折线/柱状）	completed-per-day 每日完成量
gauge	目标达成率	sprint-completion 配合 target: 100
heatmap	密度分布	agent-tasks-per-day 观察各 Agent 活跃度

# Generate reports
npx ruv-swarm github board-report \
  --type "sprint-summary" \
  --format "markdown" \
  --include "velocity,burndown,blockers" \
  --distribute "slack,email"

board-report 把仪表盘数据进一步沉淀为 Markdown 冲刺总结，并分发到 Slack/邮件等渠道，形成“看板 → 数据 → 报告 → 团队”的闭环。

十一、与 Sprint / 里程碑 / 发布流程的整合

# Manage sprints with swarms
npx ruv-swarm github sprint-manage \
  --sprint "Sprint 23" \
  --auto-populate \
  --capacity-planning \
  --track-velocity

# Track milestone progress
npx ruv-swarm github milestone-track \
  --milestone "v2.0 Release" \
  --update-board \
  --show-dependencies \
  --predict-completion

# Plan releases using board data
npx ruv-swarm github release-plan-board \
  --analyze-velocity \
  --estimate-completion \
  --identify-risks \
  --optimize-scope

• sprint-manage：自动回填冲刺内容、做容量规划并跟踪速率；--auto-populate 会把当前 Backlog 中满足条件的任务批量拉入冲刺；
• milestone-track：跟踪里程碑进度并回写看板，--show-dependencies 呈现任务依赖，--predict-completion 基于历史速率预测完成时间——这是打通“看板数据 → 智能预测”的典型场景；
• release-plan-board：直接以看板数据做发布规划，用速度分析推算交付日期、识别风险并给出范围裁剪建议，与仓库的 release-manager.md、release-swarm.md 配合可覆盖发布全流程。

十二、团队协作：分派、站会与评审

# Distribute work among team
npx ruv-swarm github board-distribute \
  --strategy "skills-based" \
  --balance-workload \
  --respect-preferences \
  --notify-assignments

# Generate standup reports
npx ruv-swarm github standup-report \
  --team "frontend" \
  --include "yesterday,today,blockers" \
  --format "slack" \
  --schedule "daily-9am"

# Coordinate reviews via board
npx ruv-swarm github review-coordinate \
  --board "Code Review" \
  --assign-reviewers \
  --track-feedback \
  --ensure-coverage

• board-distribute：按技能（skills-based）而非简单轮转做分工，同时兼顾负载均衡与个人偏好；
• standup-report：把 Agent 的任务进展自动整理为“昨天/今天/阻塞”三段式站会摘要，按 Slack 格式定时（daily-9am）推送；
• review-coordinate：开辟专门的 Code Review 看板，负责分配评审人、跟踪反馈并保证覆盖率。

十三、最佳实践

1. 看板组织

• 清晰定义列语义：Backlog / Ready / In Progress / Review / Done / Blocked 这类状态必须与 board-sync.yml 的 status 映射严格一一对应，避免“同名不同义”；
• 一致的标签体系：Agent 标签、优先级标签命名统一，让 board-auto-assign、board-bulk --filter 的筛选可预期；
• 定期看板整理（grooming）：及时清理僵尸卡片、合并重复任务、修正错误状态；
• 沉淀自动化规则：把重复性人工操作（如 blocked 标记、评审转派）固化为 board-smart-move 规则或定时命令。

2. 数据完整性

• 双向同步校验：周期性对账 swarm 任务表与 GitHub 卡片，发现单向丢失立即补偿；
• 冲突解决策略：双向同步必然面临同一字段两端同时修改，需预先约定策略（如跨组织同步中的 source-wins）；
• 审计轨迹：保留状态迁移与字段变更记录，便于回溯“谁在何时移动了什么”；
• 定期备份：利用 board-recover --backup-id 对应的时间点备份能力做全量/增量备份。

3. 团队落地

• 编写培训材料，让成员理解“Agent 自动移卡”背后的状态机规则；
• 定义清晰且少数的工作流，避免多种流程并存造成混乱；
• 定期评审看板使用情况并建立反馈闭环，持续优化映射与自动化规则。

十四、故障排查与数据恢复

同步问题诊断

npx ruv-swarm github board-diagnose \
  --check "permissions,webhooks,rate-limits" \
  --test-sync \
  --show-conflicts

三项检查分别对应用户痛点：

• permissions：gh 令牌是否具备项目读写、webhook 订阅所需 scope（Projects v2 需 project scope，个人令牌需在 GitHub 设置中显式授权）；
• webhooks：验证 webhook 是否已注册、secret 是否匹配、回调端点是否可达；
• rate-limits：gh api rate_limit 类问题通常由高频同步触发——这正是文档提供 board-realtime --batch-updates true 的原因；
• --test-sync：跑一次最小同步往返，快速定位故障发生在读侧还是写侧；
• --show-conflicts：列出当前存在冲突的卡片与字段，供人工裁决。

性能优化

npx ruv-swarm github board-optimize \
  --analyze-size \
  --archive-completed \
  --index-fields \
  --cache-views

看板膨胀会拖慢同步与渲染。依次做：分析卡片规模 → 归档已完成 → 为高频筛选字段建立索引 → 缓存常用视图结果。这与“实时更新”一节中批量写、定时同步是同一套反放大思路。

数据恢复

npx ruv-swarm github board-recover \
  --backup-id "2024-01-15" \
  --restore-cards \
  --preserve-current \
  --merge-conflicts

指定历史备份时间点恢复卡片；--preserve-current 保留恢复点之后的新改动，最终通过冲突合并而非整板回滚的方式完成恢复，最大限度减少数据丢失窗口。

十五、按方法论套用的看板模板

• 敏捷/Scrum 看板：--methodology scrum 声明迭代节奏（--sprint-length 2w）、仪式活动（planning/review/retro）与指标（velocity/burndown），与十一节的 sprint-manage 直接衔接；
• 看板/Kanban 看板：通过 --wip-limits 为各列设置在制品上限（如 In Progress 5、Review 3），--cycle-time-tracking 开环时长追踪，--continuous-flow 走持续流动而非固定迭代；
• 研究项目看板：把工作拆成 ideation,research,experiment,analysis,publish 五阶段管线，--track-citations 追踪引用，--collaborate-external 支持外部协作者。

三种模板分别对应团队最常见的三种协作形态：固定节奏交付、流动式持续改进、开放型探索研究，可覆盖绝大多数使用场景。

十六、指标与 KPI

流程性能指标

npx ruv-swarm github board-kpis \
  --metrics '[
    "average-cycle-time",
    "throughput-per-sprint",
    "blocked-time-percentage",
    "first-time-pass-rate"
  ]' \
  --dashboard-url

四类核心指标的治理含义：

• average-cycle-time：平均周期时长，衡量端到端交付速度；
• throughput-per-sprint：单冲刺吞吐量，评估产能基线；
• blocked-time-percentage：阻塞时间占比，暴露流程瓶颈与依赖问题；
• first-time-pass-rate：一次通过率，反映任务定义质量与 Agent 完成度。

配合 --dashboard-url 将 KPI 挂到共享仪表盘，作为团队例会的数据基准。

团队维度指标

npx ruv-swarm github team-metrics \
  --board "Development" \
  --per-member \
  --include "velocity,quality,collaboration" \
  --anonymous-option

按成员输出 velocity/quality/collaboration 多维度指标；--anonymous-option 支持匿名化，避免指标被误用于个人考核而破坏数据真实性。此类指标应与仓库 verification/CAPABILITIES.md、verification/results.md 中沉淀的验证理念一致：任何指标都要可复现、可解释，而不是孤立数字。

结语

Project Board Sync 提供了一条把“AI Swarm 在仓库里干活”与“团队在看板上管理”缝合起来的主路径：用 gh CLI 做 Projects v2 的底层读写，用 board-sync.yml 定义状态/Agent/优先级/自定义字段的翻译层，再用 board-init / board-sync / board-realtime / board-smart-move 等命令族把同步从一次性导入推进到实时双向，最终以 board-analytics / board-report / board-kpis 沉淀为团队可消费的决策数据。

对于想把这个能力部署到自身环境的读者，建议按以下顺序落地：先在本地验证 gh 令牌与 Projects v2 权限 → 运行 board-init 建连接 → 提交一份最小化的 .github/board-sync.yml（仅 status 映射）→ 观察一次 board-sync 往返是否正确 → 再逐步放开 board-realtime、自动指派与智能移卡规则。把状态机先跑稳，再谈自动化与智能，是这套体系落地最稳妥的路径。

相关命令与完整定义可在仓库中继续深挖：Project Board Sync 命令、Agent 化版本、插件分发版本，以及兄弟命令 swarm-issue.md、multi-repo-swarm.md、workflow-automation.md。