把想法逐层拆成可执行工单并管理看板：从…

当需要把一份意图（想法、简报、PRD、intent.md）拆解为编码代理可直接实现的工单树，并管理其发布、就绪、分配与状态时使用。

适用场景

解决思路

1. 激活时先解析配置：运行 `uv run {project-root}/_bmad/scripts/resolve_config.py --project-root {project-root} --key core.output_folder --key modules.bmm.active_initiative`；若脚本不存在，说明此处未配置 BMad，先安装 `bmad`（`npx skills add bmad-code-org/BMAD-METHOD --skill bmad`）再运行该技能完成 setup，然后重跑命令。工单草稿写在 `{active_initiative}/` 下的 `tickets.root`；若未设置，则提议创建 initiative 文件夹或 backlog 文件夹，并记录到 `_bmad/custom/config.user.toml` 的 `[modules.bmm]` 下的 `active_initiative`。
2. 读取存储配置：`uv run {skill-root}/scripts/read_toml.py --file {project-root}/_bmad/custom/ticketing-store-config.toml -k tickets`，获取存储指引、访问方式以及类型与状态映射，并把每个值中的 `{output_folder}` 替换掉；若缺失或不可读，按 `{skill-root}/references/store-setup.md` 处理而不是继续。
3. 解析定制项：`uv run {project-root}/_bmad/scripts/resolve_customization.py --skill {skill-root} --project-root {project-root} -k workflow.activation_steps_prepend -k workflow.activation_steps_append -k workflow.persistent_facts -k workflow.on_complete`。
4. 执行 `{workflow.activation_steps_prepend}`；把 `{workflow.persistent_facts}`（由 `bmad-customize` 设置）当作本次会话的基础上下文——以 `file:` 开头的条目是 `{project-root}` 下的路径或 glob，需要加载，其余按原文作为事实——并结合上下文中已有内容：已注册的 MCP 服务器与 CLI，以及从 AGENTS.md、CLAUDE.md 等注入的内容。已知信息直接使用，不要重复询问。
5. 执行 `{workflow.activation_steps_append}`；当请求的操作结束时，执行 `{workflow.on_complete}`。
6. 路由前先根据用户所说与上下文判断请求规模，并说明你走哪条路径及原因；用户可覆盖，覆盖记为一条 `Decision:` 行。Standalone：单个 bug 或 story 进入 `backlog/`，无容器、无规格问题、单工单检查。Small epic：initiative 下的 epic 信封，规格问题只问一次且易于拒绝，2 到 6 个条目，不使用学习代码库的子代理；`validate.md` 中对草稿的检查仍要运行。Full inception：走 `slice.md` 中的 epic 路径。Initiative：按 `slice.md` 编写并拆分为 epic。由 `bmad-spec` 交付的 spec 文件夹即 epic 的需求来源：`covers` 引用其 `CAP-N` id，规格问题已由它回答。
7. 按路由表读取对应参考文件：initiative 启动/编写并拆成 epic、epic 拆成 story 或重新切片、拉取条目 → `{skill-root}/references/slice.md`；编写或细化单个工单 → `{skill-root}/references/ticket.md`；发布、启动、移动、分配、阻塞、关闭、丢弃工单，查询就绪/下一个、工单或树的状态、取消树 → `{skill-root}/references/board.md`；校验工单、集合或树 → `{skill-root}/references/validate.md`；估算 epic 或 story、重新估算、记录实际值、校准刻度 → `{skill-root}/references/estimate.md`；设置、重配或切换存储 → `{skill-root}/references/store-setup.md`。把达成一致的工作保存进工单树；未来的 epic 保持为信封，直到被选中做 inception。
8. 自主模式：当用户要求你自行思考而不对话时，仍适用同样的指引、自审与子代理。缺口变成 Notes 中的开放问题，选择变成标注的假设，绝不静默猜测。`validate.md` 中对草稿的检查始终运行。发布前先问一次还要运行哪些校验（除非已说明），并且仍要获得发布许可（除非用户已说可以发布）。
9. 按需加载定制项：用 `uv run {project-root}/_bmad/scripts/resolve_customization.py --skill {skill-root} --project-root {project-root} -k workflow.<key>`（可重复 `-k`）解析键，而不是打开 `customize.toml`；模板直接打开。键包括：`slice_to_epics`（如何提议 epic 边界）、`container_definition`（容器在其层级说什么、什么留待 inception）、`slice_to_tickets`（如何把 epic 切成会话大小的实现步骤）、`ordering`（哪些工单开启和关闭父级）、`acceptance_criteria`（验收标准怎么写）、`scoring`（风险与严重度刻度）、`estimation`（开关、点数刻度、评分表与 T 恤尺码映射）、`prose`（工单文字风格）、`checks`（校验检查，按范围各一个数组：`checks.ticket`、`.set`、`.tree`、`.dependencies`（缺失前置）、`.closure`）、`refinement`（细化的含义、完整验收标准写在哪里）、`publication`（工单何时发布：随拉取逐个发布，还是在 inception 时发布整个拆解——在 tracker 上这是默认）、`initiative_template`、`epic_template`、`story_template`、`spike_template`、`bug_template`（各类型的模板文件）。
10. 按需加载存储操作：`uv run {skill-root}/scripts/read_toml.py --file {project-root}/_bmad/custom/ticketing-store-config.toml -k verbs.<name>`（可重复 `-k`），然后照所写的动词执行。动词包括：`setup`（连接工具、创建映射所命名的内容）、`write`（创建或修改工单——正文、状态、负责人、父级、阻塞、字段）、`query`（单个工单、容器的子项、搜索、就绪项）。工单如何引用文档由激活时读取的 `reference` 全局项决定。某个动词需要的字段为空且无法推断时：本次运行使用用户告诉你的值，并提议按 `{skill-root}/references/store-setup.md` 记录它。
11. 维护工单树结构：工单以 markdown 文件存放在 `tickets.root` 下，每个工单都在其文件中起草、细化、规划与实现。默认树即存储（git 支持，仓库起始模板）。配置 tracker 时它是远端：`write` 把工单推给它，`query` 读回，tracker 知道但树中没有的工单在首次 `query` 时生成其文件。
12. 容器是文件夹 `<type>-<slug>/`，内含同名工单文件、其 `tickets.toml`、其 spec 及其子项。叶子是其父文件夹中的文件 `<type>-<slug>.md`，在条目被拉取时写入，或放在 `backlog/` 中无父级。其 frontmatter `id` 即条目的 `id`，是只分配一次、永不复用的整数，也是它在仓库存储上的唯一名称：在其 epic 内为 `3`，从另一个 epic 看为 `2.3`（epic 的 `id` 在 initiative 的 `tickets.toml` 中）。文件或文件夹名不带数字；标题变更会重命名文件。tracker 在发布时添加 `tracker_id` 与 `remote`。`tickets.toml` 中表的顺序即构建顺序，`id` 不是。当 initiative 有 epic 时，每个叶子都在某个 epic 下。新工单从其类型模板开始。每个叶子文件以 `## Plan` 结尾，这是编码代理的区域：`pull` 写入空标题，ticketing 从不填充它，其下内容不会发送给 tracker。其他技能的产物放在工单旁边，以工单命名。叶子文件一旦存在即为真相：条目保持 `id`、`type`、`title`、`after`、`hitl` 最新（`after` 变更要同时写入两处），其余字段在拉取后不再维护。用户指定的工单——`1.2`、tracker id、文件名、标题中的词——通过 `tickets.py find <dir> <ref>` 解析为唯一工单。
13. 处理叶子状态字段：叶子最多携带两个状态字段。`status` 属于构建：bmad-build 与 bmad-build-auto 在工作时写入 `draft`、`ready-for-dev`、`in-progress`、`in-review`、`done` 或 `blocked`，没有 `status` 的文件表示尚未开始构建。ticketing 只在用户要求时写入它：`dropped`，或人工处理该工单并要求时。`tracker_status` 只存在于 tracker 存储上：是 tracker 当前状态的 BMad 用词（`backlog`、`in-progress`、`review`、`done`、`dropped`），由 `query` 写在 `tracker_id` 与 `remote` 旁边，从不发送。工单的 state（`next` 与 `status` 按其分组，`write` 按 `[tickets.status].<state>` 发送给 tracker）为：无文件的条目是 `planned`；否则若有 `tracker_status` 用它；否则由 `status` 推导：无、`draft` 或 `ready-for-dev` 为 `backlog`；`in-progress` 或 `blocked` 为 `in-progress`；`in-review` 为 `review`；`done` 与 `dropped` 即自身。tracker 的状态绝不能驱动构建路由（卡片在板上被移到 In Progress 后再拉取，仍按 planned 处理），构建自身步骤也无需访问 tracker。容器的 `status` 由 ticketing 管理：在其下工作开始前缺失，之后为 `in-progress`、`done` 或 `dropped`。
14. 把读多写少的工作放进子代理：学习代码库、打开参考、从存储读取树、校验检查、网络搜索。若运行环境阻止子代理，说明并改为内联继续。

适用边界 · 注意事项

• 未安装或未配置 BMad 时无法直接使用（需先运行 `bmad` 技能的 setup 并安装 `bmad`）。
• 缺少或不可读 `ticketing-store-config.toml` 时不能继续，需先按 `store-setup.md` 完成存储设置。
• 运行环境阻止子代理时，部分读多写少的任务无法按推荐方式执行（需改为内联）。