docs: replace quick-flow explainer with quick-dev, remove stale Quick Spec refs
Quick Flow was an umbrella for quick-spec + quick-dev. Quick Spec is gone and the new preview was promoted to bmad-quick-dev, so the explainer should be about quick-dev directly. Replaces quick-flow.md with the original quick-dev-new-preview.md content (renamed), including the diagram reference. zh-cn uses the original hand-written Chinese translation. Also removes stale Quick Spec references from agents.md. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
This commit is contained in:
Alex Verkhovsky
parent
3c8d865457
commit
43c59f0cff
|
|
@ -148,7 +148,7 @@ your-project/
|
|||
| ----------------- | ----------------------------- |
|
||||
| **Index/Landing** | `core-concepts/index.md` |
|
||||
| **Concept** | `what-are-agents.md` |
|
||||
| **Feature** | `quick-flow.md` |
|
||||
| **Feature** | `quick-dev.md` |
|
||||
| **Philosophy** | `why-solutioning-matters.md` |
|
||||
| **FAQ** | `established-projects-faq.md` |
|
||||
|
||||
|
|
|
|||
|
|
@ -0,0 +1,73 @@
|
|||
---
|
||||
title: "Quick Dev"
|
||||
description: Reduce human-in-the-loop friction without giving up the checkpoints that protect output quality
|
||||
sidebar:
|
||||
order: 2
|
||||
---
|
||||
|
||||
`bmad-quick-dev` reduces Quick Flow ceremony: intent in, code changes out, with fewer human-in-the-loop turns without sacrificing quality.
|
||||
|
||||
It lets the model run longer between checkpoints, then brings the human back only when the task cannot safely continue without human judgment or when it is time to review the end result.
|
||||
|
||||
|
||||
|
||||
## Why This Exists
|
||||
|
||||
Human-in-the-loop turns are necessary and expensive.
|
||||
|
||||
Current LLMs still fail in predictable ways: they misread intent, fill gaps with confident guesses, drift into unrelated work, and generate noisy review output. At the same time, constant human intervention limits development velocity. Human attention is the bottleneck.
|
||||
|
||||
`bmad-quick-dev` rebalances that tradeoff. It trusts the model to run unsupervised for longer stretches, but only after the workflow has created a strong enough boundary to make that safe.
|
||||
|
||||
## The Core Design
|
||||
|
||||
### 1. Compress intent first
|
||||
|
||||
The workflow starts by having the human and the model compress the request into one coherent goal. The input can begin as a rough expression of intent, but before the workflow runs autonomously it has to become small enough, clear enough, and contradiction-free enough to execute.
|
||||
|
||||
Intent can come in many forms: a couple of phrases, a bug tracker link, output from plan mode, text copied from a chat session, or even a story number from BMAD's own `epics.md`. In that last case, the workflow will not understand BMAD story-tracking semantics, but it can still take the story itself and run with it.
|
||||
|
||||
This workflow does not eliminate human control. It relocates it to a small number of high-value moments:
|
||||
|
||||
- **Intent clarification** - turning a messy request into one coherent goal without hidden contradictions
|
||||
- **Spec approval** - confirming that the frozen understanding is the right thing to build
|
||||
- **Review of the final product** - the primary checkpoint, where the human decides whether the result is acceptable at the end
|
||||
|
||||
### 2. Route to the smallest safe path
|
||||
|
||||
Once the goal is clear, the workflow decides whether this is a true one-shot change or whether it needs the fuller path. Small, zero-blast-radius changes can go straight to implementation. Everything else goes through planning so the model has a stronger boundary before it runs longer on its own.
|
||||
|
||||
### 3. Run longer with less supervision
|
||||
|
||||
After that routing decision, the model can carry more of the work on its own. On the fuller path, the approved spec becomes the boundary the model executes against with less supervision, which is the whole point of the design.
|
||||
|
||||
### 4. Diagnose failure at the right layer
|
||||
|
||||
If the implementation is wrong because the intent was wrong, patching the code is the wrong fix. If the code is wrong because the spec was weak, patching the diff is also the wrong fix. The workflow is designed to diagnose where the failure entered the system, go back to that layer, and regenerate from there.
|
||||
|
||||
Review findings are used to decide whether the problem came from intent, spec generation, or local implementation. Only truly local problems get patched locally.
|
||||
|
||||
### 5. Bring the human back only when needed
|
||||
|
||||
The intent interview is human-in-the-loop, but it is not the same kind of interruption as a recurring checkpoint. The workflow tries to keep those recurring checkpoints to a minimum. After the initial shaping of intent, the human mainly comes back when the workflow cannot safely continue without judgment and at the end, when it is time to review the result.
|
||||
|
||||
- **Intent-gap resolution** - stepping back in when review proves the workflow could not safely infer what was meant
|
||||
|
||||
Everything else is a candidate for longer autonomous execution. That tradeoff is deliberate. Older patterns spend more human attention on continuous supervision. Quick Dev spends more trust on the model, but saves human attention for the moments where human reasoning has the highest leverage.
|
||||
|
||||
## Why the Review System Matters
|
||||
|
||||
The review phase is not just there to find bugs. It is there to route correction without destroying momentum.
|
||||
|
||||
This workflow works best on a platform that can spawn subagents, or at least invoke another LLM through the command line and wait for a result. If your platform does not support that natively, you can add a skill to do it. Context-free subagents are a cornerstone of the review design.
|
||||
|
||||
Agentic reviews often go wrong in two ways:
|
||||
|
||||
- They generate too many findings, forcing the human to sift through noise.
|
||||
- They derail the current change by surfacing unrelated issues and turning every run into an ad hoc cleanup project.
|
||||
|
||||
Quick Dev addresses both by treating review as triage.
|
||||
|
||||
Some findings belong to the current change. Some do not. If a finding is incidental rather than causally tied to the current work, the workflow can defer it instead of forcing the human to handle it immediately. That keeps the run focused and prevents random tangents from consuming the budget of attention.
|
||||
|
||||
That triage will sometimes be imperfect. That is acceptable. It is usually better to misjudge some findings than to flood the human with thousands of low-value review comments. The system is optimizing for signal quality, not exhaustive recall.
|
||||
|
|
@ -1,75 +0,0 @@
|
|||
---
|
||||
title: "Quick Flow"
|
||||
description: Fast-track for small changes - skip the full methodology
|
||||
sidebar:
|
||||
order: 1
|
||||
---
|
||||
|
||||
Skip the ceremony. Quick Flow takes you from intent to working code in a single workflow — no Product Brief, no PRD, no Architecture doc.
|
||||
|
||||
## When to Use It
|
||||
|
||||
- Bug fixes and patches
|
||||
- Refactoring existing code
|
||||
- Small, well-understood features
|
||||
- Prototyping and spikes
|
||||
- Single-agent work where one developer can hold the full scope
|
||||
|
||||
## When NOT to Use It
|
||||
|
||||
- New products or platforms that need stakeholder alignment
|
||||
- Major features spanning multiple components or teams
|
||||
- Work that requires architectural decisions (database schema, API contracts, service boundaries)
|
||||
- Anything where requirements are unclear or contested
|
||||
|
||||
:::caution[Scope Creep]
|
||||
If you start a Quick Flow and realize the scope is bigger than expected, `bmad-quick-dev` will detect this and offer to escalate. You can switch to a full PRD workflow at any point without losing your work.
|
||||
:::
|
||||
|
||||
## How It Works
|
||||
|
||||
Run `bmad-quick-dev` and the workflow handles everything — clarifying intent, planning, implementing, reviewing, and presenting results.
|
||||
|
||||
### 1. Clarify intent
|
||||
|
||||
You describe what you want. The workflow compresses your request into one coherent goal — small enough, clear enough, and contradiction-free enough to execute safely. Intent can come from many sources: a few phrases, a bug tracker link, plan mode output, chat session text, or even a story number from your epics.
|
||||
|
||||
### 2. Route to the smallest safe path
|
||||
|
||||
Once the goal is clear, the workflow decides whether this is a true one-shot change or needs the fuller path. Small, zero-blast-radius changes go straight to implementation. Everything else goes through planning so the model has a stronger boundary before running autonomously.
|
||||
|
||||
### 3. Plan and implement
|
||||
|
||||
On the planning path, the workflow produces a complete tech-spec with ordered implementation tasks, acceptance criteria in Given/When/Then format, and testing strategy. After you approve the spec, it becomes the boundary the model executes against with less supervision.
|
||||
|
||||
### 4. Review and present
|
||||
|
||||
After implementation, the workflow runs a self-check audit and adversarial code review of the diff. Review acts as triage — findings tied to the current change are addressed, while incidental findings are deferred to keep the run focused. Results are presented for your sign-off.
|
||||
|
||||
### Human-in-the-loop checkpoints
|
||||
|
||||
The workflow relocates human control to a small number of high-value moments:
|
||||
|
||||
- **Intent clarification** — turning a messy request into one coherent goal
|
||||
- **Spec approval** — confirming the frozen understanding is the right thing to build
|
||||
- **Final review** — deciding whether the result is acceptable
|
||||
|
||||
Between these checkpoints, the model runs longer with less supervision. This is deliberate — it trades continuous supervision for focused human attention at moments with the highest leverage.
|
||||
|
||||
## What Quick Flow Skips
|
||||
|
||||
The full BMad Method produces a Product Brief, PRD, Architecture doc, and Epic/Story breakdown before any code is written. Quick Flow replaces all of that with a single tech-spec. This works because Quick Flow targets changes where:
|
||||
|
||||
- The product direction is already established
|
||||
- Architecture decisions are already made
|
||||
- A single developer can reason about the full scope
|
||||
- Requirements fit in one conversation
|
||||
|
||||
## Escalating to Full BMad Method
|
||||
|
||||
Quick Flow includes built-in guardrails for scope detection. When you run `bmad-quick-dev`, it evaluates signals like multi-component mentions, system-level language, and uncertainty about approach. If it detects the work is bigger than a quick flow:
|
||||
|
||||
- **Light escalation** — Recommends creating a plan before implementation
|
||||
- **Heavy escalation** — Recommends switching to the full BMad Method PRD process
|
||||
|
||||
You can also escalate manually at any time. Your tech-spec work carries forward — it becomes input for the broader planning process rather than being discarded.
|
||||
|
|
@ -115,7 +115,7 @@ No planning artifacts are produced -- that's the point of this approach.
|
|||
|
||||
## When to Upgrade to Formal Planning
|
||||
|
||||
Consider using [Quick Flow](../explanation/quick-flow.md) or the full BMad Method when:
|
||||
Consider using [Quick Dev](../explanation/quick-dev.md) or the full BMad Method when:
|
||||
|
||||
- The change affects multiple systems or requires coordinated updates across many files
|
||||
- You are unsure about the scope and need a spec to think it through
|
||||
|
|
|
|||
|
|
@ -23,7 +23,7 @@ This page lists the default BMM (Agile suite) agents that install with BMad Meth
|
|||
| Scrum Master (Bob) | `bmad-sm` | `SP`, `CS`, `ER`, `CC` | Sprint Planning, Create Story, Epic Retrospective, Correct Course |
|
||||
| Developer (Amelia) | `bmad-dev` | `DS`, `CR` | Dev Story, Code Review |
|
||||
| QA Engineer (Quinn) | `bmad-qa` | `QA` | Automate (generate tests for existing features) |
|
||||
| Quick Flow Solo Dev (Barry) | `bmad-master` | `QS`, `QD`, `CR` | Quick Spec, Quick Dev, Code Review |
|
||||
| Quick Flow Solo Dev (Barry) | `bmad-master` | `QD`, `CR` | Quick Dev, Code Review |
|
||||
| UX Designer (Sally) | `bmad-ux-designer` | `CU` | Create UX Design |
|
||||
| Technical Writer (Paige) | `bmad-tech-writer` | `DP`, `WD`, `US`, `MG`, `VD`, `EC` | Document Project, Write Document, Update Standards, Mermaid Generate, Validate Doc, Explain Concept |
|
||||
|
||||
|
|
@ -35,7 +35,7 @@ Agent menu triggers use two different invocation types. Knowing which type a tri
|
|||
|
||||
Most triggers load a structured workflow file. Type the trigger code and the agent starts the workflow, prompting you for input at each step.
|
||||
|
||||
Examples: `CP` (Create PRD), `DS` (Dev Story), `CA` (Create Architecture), `QS` (Quick Spec)
|
||||
Examples: `CP` (Create PRD), `DS` (Dev Story), `CA` (Create Architecture), `QD` (Quick Dev)
|
||||
|
||||
### Conversational triggers (arguments required)
|
||||
|
||||
|
|
|
|||
|
|
@ -148,7 +148,7 @@ your-project/
|
|||
| ----------------- | ----------------------------- |
|
||||
| **Index/Landing** | `core-concepts/index.md` |
|
||||
| **Concept** | `what-are-agents.md` |
|
||||
| **Feature** | `quick-flow.md` |
|
||||
| **Feature** | `quick-dev.md` |
|
||||
| **Philosophy** | `why-solutioning-matters.md` |
|
||||
| **FAQ** | `established-projects-faq.md` |
|
||||
|
||||
|
|
|
|||
|
|
@ -0,0 +1,73 @@
|
|||
---
|
||||
title: "快速开发"
|
||||
description: 在不牺牲输出质量检查点的情况下减少人机交互的摩擦
|
||||
sidebar:
|
||||
order: 2
|
||||
---
|
||||
|
||||
`bmad-quick-dev` 减少快速流程的仪式感：输入意图，输出代码变更，减少人机交互轮次，同时不牺牲质量。
|
||||
|
||||
它让模型在检查点之间运行更长时间，只有在任务无法在没有人类判断的情况下安全继续时，或者需要审查最终结果时，才会让人类介入。
|
||||
|
||||
|
||||
|
||||
## 为什么需要这个功能
|
||||
|
||||
人机交互轮次既必要又昂贵。
|
||||
|
||||
当前的 LLM 仍然会以可预测的方式失败：它们误读意图、用自信的猜测填补空白、偏离到不相关的工作中，并生成嘈杂的审查输出。与此同时，持续的人工干预限制了开发速度。人类注意力是瓶颈。
|
||||
|
||||
`bmad-quick-dev` 重新平衡了这种权衡。它信任模型在更长的时间段内无监督运行，但前提是工作流已经创建了足够强的边界来确保安全。
|
||||
|
||||
## 核心设计
|
||||
|
||||
### 1. 首先压缩意图
|
||||
|
||||
工作流首先让人类和模型将请求压缩成一个连贯的目标。输入可以从粗略的意图表达开始，但在工作流自主运行之前，它必须变得足够小、足够清晰、没有矛盾。
|
||||
|
||||
意图可以以多种形式出现：几句话、一个错误追踪器链接、计划模式的输出、从聊天会话复制的文本，甚至来自 BMAD 自己的 `epics.md` 的故事编号。在最后一种情况下，工作流不会理解 BMAD 故事跟踪语义，但它仍然可以获取故事本身并继续执行。
|
||||
|
||||
这个工作流并不会消除人类的控制。它将其重新定位到少数几个高价值时刻：
|
||||
|
||||
- **意图澄清** - 将混乱的请求转化为一个没有隐藏矛盾的连贯目标
|
||||
- **规范审批** - 确认冻结的理解是正确要构建的东西
|
||||
- **最终产品审查** - 主要检查点，人类在最后决定结果是否可接受
|
||||
|
||||
### 2. 路由到最小安全路径
|
||||
|
||||
一旦目标清晰，工作流就会决定这是一个真正的单次变更还是需要更完整的路径。小的、零爆炸半径的变更可以直接进入实现。其他所有内容都需要经过规划，这样模型在独自运行更长时间之前就有更强的边界。
|
||||
|
||||
### 3. 以更少的监督运行更长时间
|
||||
|
||||
在那个路由决策之后，模型可以自己承担更多工作。在更完整的路径上，批准的规范成为模型在较少监督下执行的边界，这正是设计的全部意义。
|
||||
|
||||
### 4. 在正确的层诊断失败
|
||||
|
||||
如果实现是错误的，因为意图是错误的，修补代码是错误的修复。如果代码是错误的，因为规范太弱，修补差异也是错误的修复。工作流旨在诊断失败从系统的哪个层面进入，回到那个层面，并从那里重新生成。
|
||||
|
||||
审查发现用于确定问题来自意图、规范生成还是本地实现。只有真正的本地问题才会在本地修补。
|
||||
|
||||
### 5. 只在需要时让人类回来
|
||||
|
||||
意图访谈是人机交互，但它不是与重复检查点相同类型的中断。工作流试图将那些重复检查点保持在最低限度。在初始意图塑造之后，人类主要在工作流无法在没有判断的情况下安全继续时，以及在最后需要审查结果时才回来。
|
||||
|
||||
- **意图差距解决** - 当审查证明工作流无法安全推断出原本意图时重新介入
|
||||
|
||||
其他一切都是更长自主执行的候选。这种权衡是经过深思熟虑的。旧模式在持续监督上花费更多的人类注意力。快速开发在模型上投入更多信任，但将人类注意力保留在人类推理具有最高杠杆作用的时刻。
|
||||
|
||||
## 为什么审查系统很重要
|
||||
|
||||
审查阶段不仅仅是为了发现错误。它是为了在不破坏动力的情况下路由修正。
|
||||
|
||||
这个工作流在能够生成子智能体的平台上效果最好，或者至少可以通过命令行调用另一个 LLM 并等待结果。如果你的平台本身不支持这一点，你可以添加一个技能来做。无上下文子智能体是审查设计的基石。
|
||||
|
||||
智能体审查经常以两种方式出错：
|
||||
|
||||
- 它们生成太多发现，迫使人类在噪音中筛选
|
||||
- 它们通过提出不相关的问题并使每次运行变成临时清理项目来使当前变更脱轨
|
||||
|
||||
快速开发通过将审查视为分诊来解决这两个问题。
|
||||
|
||||
一些发现属于当前变更。一些不属于。如果一个发现是附带的而不是与当前工作有因果关系，工作流可以推迟它，而不是强迫人类立即处理它。这使运行保持专注，并防止随机的分支话题消耗注意力的预算。
|
||||
|
||||
那个分诊有时会不完美。这是可以接受的。通常，误判一些发现比用成千上万个低价值的审查评论淹没人类要好。系统正在优化信号质量，而不是详尽的召回率。
|
||||
|
|
@ -1,93 +0,0 @@
|
|||
---
|
||||
title: "快速流程"
|
||||
description: 小型变更的快速通道 - 跳过完整方法论
|
||||
sidebar:
|
||||
order: 1
|
||||
---
|
||||
|
||||
跳过繁琐流程。快速流程通过单个工作流将你从意图带到可运行的代码 — 无需产品简报、无需 PRD、无需架构文档。
|
||||
|
||||
## 何时使用
|
||||
|
||||
- Bug 修复和补丁
|
||||
- 重构现有代码
|
||||
- 小型、易于理解的功能
|
||||
- 原型设计和探索性开发
|
||||
- 单智能体工作，一名开发者可以掌控完整范围
|
||||
|
||||
## 何时不使用
|
||||
|
||||
- 需要利益相关者对齐的新产品或平台
|
||||
- 跨越多个组件或团队的主要功能
|
||||
- 需要架构决策的工作（数据库架构、API 契约、服务边界）
|
||||
- 需求不明确或有争议的任何工作
|
||||
|
||||
:::caution[Scope Creep]
|
||||
如果你启动快速流程后发现范围超出预期，`bmad-quick-dev` 会检测到并提供升级选项。你可以在任何时间切换到完整的 PRD 工作流程，而不会丢失你的工作。
|
||||
:::
|
||||
|
||||
## 工作原理
|
||||
|
||||
运行 `bmad-quick-dev`，工作流会处理一切 — 澄清意图、规划、实现、审查和呈现结果。
|
||||
|
||||
### 1. 澄清意图
|
||||
|
||||
你描述想要什么。工作流将你的请求压缩成一个连贯的目标 — 足够小、足够清晰、没有矛盾，可以安全执行。意图可以来自多种来源：几句话、一个错误追踪器链接、计划模式输出、聊天会话文本，甚至来自你的史诗的故事编号。
|
||||
|
||||
### 2. 路由到最小安全路径
|
||||
|
||||
一旦目标清晰，工作流就会决定这是一个真正的单次变更还是需要更完整的路径。小的、零爆炸半径的变更可以直接进入实现。其他所有内容都需要经过规划，这样模型在自主运行之前就有更强的边界。
|
||||
|
||||
### 3. 规划和实现
|
||||
|
||||
在规划路径上，工作流生成完整的技术规范，包含有序的实现任务、Given/When/Then 格式的验收标准和测试策略。你批准规范后，它成为模型在较少监督下执行的边界。
|
||||
|
||||
### 4. 审查和呈现
|
||||
|
||||
实现后，工作流运行自检审计和差异的对抗性代码审查。审查充当分诊 — 与当前变更相关的发现会被处理，附带的发现会被推迟以保持运行专注。结果呈现供你确认。
|
||||
|
||||
### 人机交互检查点
|
||||
|
||||
工作流将人类控制重新定位到少数几个高价值时刻：
|
||||
|
||||
- **意图澄清** — 将混乱的请求转化为一个连贯的目标
|
||||
- **规范审批** — 确认冻结的理解是正确要构建的东西
|
||||
- **最终审查** — 决定结果是否可接受
|
||||
|
||||
在这些检查点之间，模型以更少的监督运行更长时间。这是经过深思熟虑的 — 它用持续监督换取在最高杠杆时刻的集中人类注意力。
|
||||
|
||||
## 快速流程跳过的内容
|
||||
|
||||
完整的 BMad 方法在编写任何代码之前会生成产品简报、PRD、架构文档和 Epic/Story 分解。Quick Flow 用单个技术规范替代所有这些。这之所以有效，是因为 Quick Flow 针对以下变更：
|
||||
|
||||
- 产品方向已确立
|
||||
- 架构决策已做出
|
||||
- 单个开发者可以推理完整范围
|
||||
- 需求可以在一次对话中涵盖
|
||||
|
||||
## 升级到完整 BMad 方法
|
||||
|
||||
快速流程包含内置的范围检测护栏。当你运行 `bmad-quick-dev` 时，它会评估多组件提及、系统级语言和方法不确定性等信号。如果检测到工作超出快速流程范围：
|
||||
|
||||
- **轻度升级** — 建议在实现前创建计划
|
||||
- **重度升级** — 建议切换到完整的 BMad 方法 PRD 流程
|
||||
|
||||
你也可以随时手动升级。你的技术规范工作会继续推进 — 它将成为更广泛规划过程的输入，而不是被丢弃。
|
||||
|
||||
---
|
||||
## 术语说明
|
||||
|
||||
- **Quick Flow**：快速流程。BMad 方法中用于小型变更的简化工作流程，跳过完整的产品规划和架构文档阶段。
|
||||
- **PRD**：Product Requirements Document，产品需求文档。详细描述产品功能、需求和验收标准的文档。
|
||||
- **Product Brief**：产品简报。概述产品愿景、目标和范围的高层文档。
|
||||
- **Architecture doc**：架构文档。描述系统架构、组件设计和技术决策的文档。
|
||||
- **Epic/Story**：史诗/故事。敏捷开发中的工作单元，Epic 是大型功能集合，Story 是具体用户故事。
|
||||
- **agent**：智能体。在人工智能与编程文档中，指具备自主决策或执行能力的单元。
|
||||
- **Scope Creep**：范围蔓延。项目范围在开发过程中逐渐扩大，超出原始计划的现象。
|
||||
- **tech-spec**：技术规范。详细描述技术实现方案、任务分解和验收标准的文档。
|
||||
- **Given/When/Then**：一种行为驱动开发（BDD）的测试场景描述格式，用于定义验收标准。
|
||||
- **adversarial review**：对抗性审查。一种代码审查方法，模拟攻击者视角以发现潜在问题和漏洞。
|
||||
- **stakeholder**：利益相关者。对项目有利益或影响的个人或组织。
|
||||
- **API contracts**：API 契约。定义 API 接口规范、请求/响应格式和行为约定的文档。
|
||||
- **service boundaries**：服务边界。定义服务职责范围和边界的架构概念。
|
||||
- **spikes**：探索性开发。用于探索技术可行性或解决方案的短期研究活动。
|
||||
|
|
@ -115,7 +115,7 @@ DEV 智能体也适用于探索不熟悉的代码。在新的聊天中加载它
|
|||
|
||||
## 何时升级到正式规划
|
||||
|
||||
在以下情况下考虑使用 [Quick Flow](../explanation/quick-flow.md) 或完整的 BMad Method：
|
||||
在以下情况下考虑使用 [Quick Dev](../explanation/quick-dev.md) 或完整的 BMad Method：
|
||||
|
||||
- 更改影响多个系统或需要在许多文件中进行协调更新
|
||||
- 你不确定范围，需要规范来理清思路
|
||||
|
|
|
|||
|
|
@ -23,7 +23,7 @@ sidebar:
|
|||
| Scrum Master (Bob) | `SP`, `CS`, `ER`, `CC` | 冲刺规划、创建用户故事、史诗回顾、纠正方向 |
|
||||
| Developer (Amelia) | `DS`, `CR` | 开发用户故事、代码评审 |
|
||||
| QA Engineer (Quinn) | `QA` | 自动化（为现有功能生成测试） |
|
||||
| Quick Flow Solo Dev (Barry) | `QS`, `QD`, `CR` | 快速规格、快速开发、代码评审 |
|
||||
| Quick Flow Solo Dev (Barry) | `QD`, `CR` | 快速开发、代码评审 |
|
||||
| UX Designer (Sally) | `CU` | 创建 UX 设计 |
|
||||
| Technical Writer (Paige) | `DP`, `WD`, `US`, `MG`, `VD`, `EC` | 文档化项目、撰写文档、更新标准、Mermaid 生成、验证文档、解释概念 |
|
||||
|
||||
|
|
|
|||
Loading…
Reference in New Issue