用途：为软件开发项目提供以 Markdown 为核心的规划方法论，适用于启动新项目、编写实施计划、优化架构。核心主张是把大部分时间与 token 花在规划上，因为模型在推理一份能装入上下文窗口的详细计划时表现更好。
主要能力与判定标准：一份可用的计划需满足——自包含（全新智能体无需向人提问即可开工）、依赖感知（非平凡任务标明阻塞与被阻塞关系，可分解为 beads 图）、有理由（每个架构选择和非显而易见的特性至少一句话说明「为什么」）、经强推理模型至少 4 轮评审达到稳态（最近一轮只产生边际修订）、已转为保持依赖图的 beads，使实施智能体可用 br ready --json 领取就绪任务。未达标情形包括：非平凡项目少于约 1,500 行（规格不足）、超过约 10,000 行且无分解、实施中途仍在问「这该做什么」、beads 之间没有依赖边。
使用方式：流程为初始规划（GPT Pro / Opus 4.7 网页版）→ 迭代细化（GPT Pro Extended Reasoning，4-5 轮至稳态）→ 可选多模型混合（Gemini 3.1 Pro Deep Think、Grok4 Heavy、Opus 4.7，GPT Pro 终审）→ 转为 beads（Claude Code + Opus 4.7）→ 打磨 beads（6 轮以上至稳态）。关键提示词包括计划评审与整合修订两类，文中给出原文。每轮评审之间需做四项验证：自包含检查、依赖图检查（有无环、孤儿任务）、理由检查（抽 5 个架构决策）、稳态检查（对比相邻两轮差异）。规划决策须接地：库/框架选择查当前文档，现有代码库主张需用 grep、git log 或 codebase-archaeology 核实，性能与成本数字需引用或基准，工具引用需确认当前契约。
适用场景：非平凡的软件项目、需要多智能体并行实施、架构需要前置论证的场合。限制与不适用情形：小而局部的改动（一个 bug、一个文件、约 200 行以内）、纯研究或探索未知代码库、架构已由规范或移植目标决定、紧急事件与热修复等硬截止场景。常见错误包括过早开始实现、只做单轮评审、未使用 GPT Pro Extended Reasoning、骨架先行编码、丢失上下文。参考文档列有 PROMPTS.md、EXAMPLES.md、FAQ.md。