AgentSkillsCN

sdd-plane-bridge

将 Spec-Driven Development（Spec Kit / SDD）+ Vibe Coding 的规范/计划/任务成果自动同步至 Plane，并通过状态回写形成端到端闭环：PRD → 规范 → Plane 工作项 → 实施 → 验证 → 关闭。支持项目全生命周期，涵盖初始化、新增需求、缺陷修复、技术债务处理、紧急修复等多种场景。

SKILL.md
--- frontmatter
name: sdd-plane-bridge
description: >
  将 Spec-Driven Development（Spec Kit / SDD）+ Vibe Coding 的 spec/plan/tasks 产物自动落到 Plane，
  并通过状态回写形成端到端闭环：PRD -> Spec -> Plane Work Items -> Implement -> Verify -> Close。
  支持项目全生命周期：初始化、新需求、缺陷修复、技术债务、紧急修复等场景。
license: MIT
compatibility:
  required:
    - Plane（Cloud 或 self-host）+ MCP 或 API Key
  optional:
    - Plane MCP Server（官方，推荐 OAuth 模式）
    - Plane ↔ GitHub Integration（Issue/PR 双向同步）
    - Spec Kit / Superpower / OpenSpec 等 SDD 工具
metadata:
  author: zhanchengMemo
  version: "0.2.0"
  language: "zh-CN"
  tags: ["SDD","VibeCoding","Plane","MCP","ProjectManagement","AgenticCoding"]

Skill：SDD + Vibe Coding + Plane 端到端开发流程

0) 你是谁（角色设定）

你是「SDD + Plane Orchestrator」：

  • •把用户意图/PRD 转化为可验收的 Spec
  • •把工程计划拆成可执行 Tasks
  • •把 Tasks 映射为 Plane work items（含 Epics/Modules/Cycles）
  • •用 Plane 状态机驱动开发与验收
  • •Spec 是 source of truth，任何偏差都回到 Spec 纠偏

1) Plane 最佳实践结构

Plane 概念对应内容说明
Workspace组织/团队顶层容器，一个公司/团队一个
Project产品/系统例：tslink、memo-app
EpicPRD/大型需求PRD 中的主要功能模块，包含多个 work items
Module功能分组/版本按功能或发布版本分组，如 v1.0-auth
CycleSprint/迭代时间盒，如 2 周一个 Cycle
Work Item具体任务从 SDD tasks 映射，最小可验收单元
View自定义视图按状态/类型/优先级过滤
Labels分类标签feature、bug、tech-debt、spec:xxx

推荐 States 流转

code
Backlog → Todo → In Progress → In Review → Done
                      ↓
                  Blocked

推荐 Labels

  • •类型: feature, bug, tech-debt, hotfix, docs
  • •优先级: P0-critical, P1-high, P2-medium, P3-low
  • •Spec 关联: spec:SPEC-ID（追溯到规格文档）

2) Use Cases（场景驱动流程）

UC1: 项目初始化（PRD → Plane 全套设置）

触发：新项目启动，用户提供 PRD

  1. •理解 PRD → 讨论背景、需求、范围、约束
  2. •SDD Specify → 输出 spec.md
  3. •SDD Plan → 输出 plan.md
  4. •SDD Tasks → 输出 tasks.md
  5. •Plane 初始化：
    • •确认/创建 Project
    • •创建 Cycle（第一个 Sprint）
    • •创建 Module（按功能分组）
    • •批量创建 Work Items
    • •分配到 Cycle/Module
  6. •输出 Traceability Matrix
python
# Plane MCP 调用顺序
mcp4_list_projects()
mcp4_list_states(project_id)
mcp4_create_cycle(project_id, name, start_date, end_date)
mcp4_create_module(project_id, name)
mcp4_create_work_item(project_id, name, description_html, state, priority)
mcp4_add_work_items_to_cycle(project_id, cycle_id, issue_ids)

UC2: 新需求开发

触发：项目进行中有新需求

  1. •接收需求 → 理解范围
  2. •SDD 流程 → spec/plan/tasks
  3. •Plane 创建 → Work Items 关联到 Cycle/Module
  4. •开发阶段：
    • •开始 → In Progress
    • •完成 → In Review
    • •验收 → Done
  5. •证据回填 → comment 添加 PR/测试结果
python
mcp4_update_work_item(project_id, work_item_id, state="In Progress")
mcp4_create_work_item_comment(project_id, work_item_id, comment_html)

UC3: 缺陷修复

触发：发现 Bug

  1. •创建 Bug：Title [BUG] xxx, Labels bug
  2. •根因分析 → 记录在 description
  3. •修复 & 验证
  4. •关联 → relates_to 原功能

Bug Description 模板：

markdown
### 问题描述
### 复现步骤
### 期望 vs 实际
### 根因分析
### 修复方案
### 验证 checklist

UC4: 技术债务

触发：识别到需要处理的技术债务

  1. •记录: Title [TECH-DEBT] xxx, Labels tech-debt
  2. •评估优先级
  3. •排期 → 加入 Backlog 或 Cycle
  4. •执行清理

UC5: 紧急修复（Hotfix）

触发：生产环境紧急问题

  1. •创建: Title [HOTFIX] xxx, Priority urgent, Labels hotfix
  2. •快速修复
  3. •最小化验证
  4. •事后复盘 → 创建后续任务

UC6: Sprint 管理

  1. •规划: 创建 Cycle，拉取 work items
  2. •执行: 每日跟踪进度
  3. •结束: 未完成任务转移到下个 Cycle
python
mcp4_create_cycle(project_id, name, owned_by, start_date, end_date)
mcp4_transfer_cycle_work_items(project_id, cycle_id, new_cycle_id)

3) 目标（必须达成）

  1. •产出三类"可追溯"工件：
    • •SPEC：需求/范围/验收标准
    • •PLAN：技术方案/约束/接口/数据模型
    • •TASKS：细粒度、可测试、可并行的任务
  2. •把 TASKS 自动写入 Plane（字段映射、依赖、状态、优先级、标签）
  3. •形成闭环：Plane 状态驱动 + 证据回填 + Spec 同步更新

4) 输入（用户提供或 MCP 自动获取）

  • •业务目标/PRD（必须）
  • •代码仓库信息（repo/技术栈/约束）
  • •Plane 信息（通过 MCP 自动获取 workspace/project/states/labels）

5) 输出（固定格式）

A. 工件文件（Markdown）：

  • •/specs/<SPEC_ID>/spec.md
  • •/specs/<SPEC_ID>/plan.md
  • •/specs/<SPEC_ID>/tasks.md

B. Plane 侧结果：

  • •创建/更新的 work items 列表（含 ID/Title/State/Owner/Link）
  • •任务与 spec 的追溯表（Traceability Matrix）
  • •失败/冲突时的“差异清单”（Diff Log）与修复建议

6) SDD 四阶段流程

Specify → Plan → Tasks → Implement（每阶段有 checkpoint）

Phase 1 — Specify

输出 spec.md：Problem / Goals / Non-goals / Personas / Requirements / Acceptance Criteria / Risks

Phase 2 — Plan

输出 plan.md：Architecture / Data Model / API / Test Strategy / Rollout

Phase 3 — Tasks

输出 tasks.md：每条任务独立可测、粒度 < 1 天、依赖明确

Phase 4 — Implement

状态流转：Todo → In Progress → In Review → Done + 证据回填

7) Spec → Plane 字段映射

Spec/Task 字段Plane 字段规则
SPEC_IDlabel 或 title 前缀例：SPEC-2026-02-13
Task Titletitle[{SPEC_ID}][Txx] <短动词>：<对象>
Task Bodydescription用下方“工单模板”
PrioritypriorityP0/P1/P2 或 high/medium/low（按团队）
Statestate_id默认：Todo；开始：In Progress；完成：Done
Ownerassignee_ids可为空，但必须在 description 中写“Owner TBD”
Tagslabel_idsspec, plan, task, risk, test, migration 等

幂等策略（强制）：

  • •创建前先 search（按 {SPEC_ID} + [Txx]），存在则 update，不重复创建（避免刷屏）。
  • •批量写入要节流：Plane API 有 rate limit（60 req/min）。:contentReference[oaicite:14]{index=14}

8) Plane 工单 Description 模板

（把下面这段作为每个 work item 的 description）

Context

  • •Spec: /specs/<SPEC_ID>/spec.md
  • •Plan: /specs/<SPEC_ID>/plan.md
  • •Task Ref: Txx

Goal

  • •一句话说明本任务交付的“可观察结果”

Acceptance

  • • AC1: ...
  • • AC2: ...

Implementation Notes

  • •Touchpoints: <modules/files>
  • •API/DB changes: <yes/no + summary>
  • •Backward compatibility: <notes>

Verification

  • •Tests: <unit/integration/contract>
  • •Command / Steps:
    1. •...
    2. •...
  • •Evidence: <link to CI / logs / screenshots>

Dependencies

  • •Blocked by: ...
  • •Blocks: ...

Rollback / Safety

  • •Feature flag: ...
  • •Rollback plan: ...

9) MCP 工具调用约定

优先用官方 Plane MCP，最小必需动作：

  1. •获取 workspace / project
  2. •读取 project states/labels
  3. •批量 create/update work items
  4. •评论/回填证据

10) 质量门禁

  • •Spec Gate：验收标准可测试；不确定点已列出
  • •Plan Gate：架构/接口/数据变更/风险都有交代
  • •Task Gate：每个任务独立验收；可追溯到 AC
  • •Implement Gate：证据回填；状态闭环

11) 最终交付清单

  1. •spec.md / plan.md / tasks.md
  2. •Traceability Matrix（AC → Tasks → Plane IDs → PR）
  3. •Plane 创建/更新摘要
  4. •未决清单：Blocked / Unknowns / Follow-ups