plan-backlog

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

plan-backlog

Mục tiêu: biến BR/UR/FR đã approved thành backlog thật (Epic/Feature/User Story có ID,

parent_*

, đúng template). User Story là đơn vị thực thi cuối cùng trong spec-kit này — skill này chỉ dẫn dắt việc phân rã tới User Story, không nói về việc chia nhỏ hơn nữa.

Tiêu chí phân rã từng cấp — dùng để quyết định một ý tưởng nên là Epic, Feature, hay User Story:

Cấp	Trả lời câu hỏi	Quy mô điển hình	`parent_*` bắt buộc	Ai review
Epic	Mục tiêu kinh doanh lớn nào (từ 1 BR) đang được hiện thực hoá? 1 Epic ≈ 1 mảng giá trị lớn, ứng với 1 container triển khai ( `source_container` )	Nhiều Feature, thường ~5-20 Feature	`docs_requirements` (BR liên quan)	Product owner / tech lead
Feature	Epic này gồm những nhóm chức năng con nào?	Vài User Story	`parent_epic` , `docs_requirements` (UR liên quan)	Product owner
User Story	Persona cụ thể nào (từ UR) cần làm gì, để được lợi ích gì? Đủ nhỏ để 1 người triển khai xong trong 1 lần thay đổi mạch lạc, phải có Acceptance Criteria	Vài giờ đến vài ngày	`parent_feature` , `docs_requirements` (FR liên quan)	Dev nhận User Story / tech lead

Nếu 1 Epic vượt xa mức ~20 Feature, đó là dấu hiệu đang gộp nhiều mảng giá trị khác nhau vào 1 Epic — đề xuất user tách thành nhiều Epic nhỏ hơn, cùng trỏ

docs_requirements

về cùng 1 BR, thay vì giữ 1 Epic khổng lồ.

User Story đủ nhỏ/đủ rõ là thế nào? đảm bảo Acceptance Criteria đủ rõ, đủ trường hợp để sau này phân task và định nghĩa test dễ dàng. Dùng 2 dấu hiệu sau để quyết định có cần tách User Story tiếp không:

1 User Story = 1 hành vi cụ thể, triển khai được trong 1 lần thay đổi mạch lạc. Mô tả phải nối nhiều hành vi bằng "và"/"rồi" → tách thành nhiều User Story.
Phải hình dung được cụ thể input/output hoặc kết quả mong đợi cho từng Acceptance Criteria ngay lúc tạo — không hình dung được nghĩa là User Story còn mơ hồ hoặc còn quá lớn, hỏi lại user hoặc tách tiếp trước khi tạo. Liệt kê cả edge case/trường hợp lỗi quan trọng, không chỉ happy path.

目标：将已获批的BR/UR/FR转化为正式的backlog（带有ID、

parent_*

字段、符合模板的Epic/Feature/User Story）。User Story是本spec-kit中的最终执行单元——本Skill仅指导拆解至User Story层面，不涉及进一步拆分。

各层级拆解标准——用于判断一个想法应归为Epic、Feature还是User Story：

层级	回答的问题	典型规模	必填 `parent_*` 字段	审核人
Epic	正在落地的重大业务目标是什么（来自1份BR）？1个Epic≈1个大价值模块，对应1个部署容器（ `source_container` ）	包含多个Feature，通常约5-20个Feature	`docs_requirements` （关联的BR）	产品负责人/技术负责人
Feature	该Epic包含哪些子功能组？	包含若干User Story	`parent_epic` 、 `docs_requirements` （关联的UR）	产品负责人
User Story	具体的用户角色（来自UR）需要做什么，以获得什么收益？足够小，能由1人在一次连贯的变更中完成，必须包含验收标准（Acceptance Criteria）	数小时至数天	`parent_feature` 、 `docs_requirements` （关联的FR）	承接User Story的开发人员/技术负责人

若一个Epic包含的Feature远超20个，说明该Epic合并了多个不同的价值模块——建议用户拆分为多个小Epic，共同指向同一份BR，而非保留一个庞大的Epic。

**User Story足够小/清晰的标准是什么？**需确保验收标准足够明确、覆盖足够场景，以便后续拆分任务和定义测试用例。可通过以下两个信号判断是否需要进一步拆分User Story：

1个User Story=1个具体行为，可在一次连贯变更中完成。若描述中用「和」/「然后」连接多个行为→拆分为多个User Story。
在创建时必须能明确想象出每个验收标准的具体输入/输出或预期结果——若无法想象，说明User Story仍模糊或过大，需向用户确认或继续拆分后再创建。需列出重要的边缘场景/错误情况，而非仅覆盖正常流程。

Điều kiện tiên quyết

前置条件

Template cần cho Epic/Feature/User Story/OQ đi kèm sẵn trong thư mục

templates/

cạnh chính

SKILL.md

này — không cần cài/copy gì thêm để có chúng:

Tài liệu	Template đi kèm skill
`docs/spec-kit-conventions.md`	`templates/spec-kit-conventions.md`
`docs/backlog/epics/EPIC-*.md`	`templates/EPIC-template.md`
`docs/backlog/features/.../FEAT-*.md`	`templates/FEAT-template.md`
`docs/backlog/user-stories/.../US-*.md`	`templates/US-template.md`
`docs/meetings/open-questions/OQ-*.md`	`templates/OQ-template.md`
`docs/meetings/notes/MEET-*.md`	`templates/MEET-template.md`

Quy tắc chọn nguồn template — áp dụng ở mọi bước "Quy trình" bên dưới cần tạo file mới: ưu tiên

docs/backlog/{epics,features,user-stories}/*-template.md

tương ứng nếu dự án đã có sẵn; chỉ dùng bản

templates/<tên>-template.md

đi kèm skill này khi dự án chưa có — lúc đó tự tạo thư mục con tương ứng rồi copy nguyên trạng bản đi kèm skill vào đúng vị trí trước khi tạo Epic/Feature/US thật. Không tự bịa cấu trúc/tên field khác ngoài 2 nguồn này.

docs/glossary/glossary.md

và

docs/system-overview/c4-container.md

cần đã tồn tại (tạo từ Bước trước, xem skill

setup-context

c4-model

) — 2 file này không phải template, không tự scaffold được, phải chạy đúng thứ tự Bước A trước Bước B nếu chưa có.

docs/spec-kit-conventions.md

dùng đúng quy tắc chọn nguồn ở trên: kiểm tồn tại chưa trước khi làm bất kỳ việc gì bên dưới, nếu chưa có thì copy nguyên trạng từ

templates/spec-kit-conventions.md

. Quy tắc cốt lõi đã được nhắc lại trực tiếp trong các mục dưới đây, và đầy đủ hơn ở

docs/spec-kit-conventions.md

— bảng prefix/ID, vòng đời

status

, glossary-link, ma trận lan truyền thay đổi.

Epic/Feature/User Story/OQ所需的模板已预先存放在本

SKILL.md

旁的

templates/

目录中——无需额外安装/复制即可使用：

文档	Skill附带的模板
`docs/spec-kit-conventions.md`	`templates/spec-kit-conventions.md`
`docs/backlog/epics/EPIC-*.md`	`templates/EPIC-template.md`
`docs/backlog/features/.../FEAT-*.md`	`templates/FEAT-template.md`
`docs/backlog/user-stories/.../US-*.md`	`templates/US-template.md`
`docs/meetings/open-questions/OQ-*.md`	`templates/OQ-template.md`
`docs/meetings/notes/MEET-*.md`	`templates/MEET-template.md`

模板选择规则——适用于以下「流程」步骤中所有需要创建新文件的场景：优先使用项目中已存在的

docs/backlog/{epics,features,user-stories}/*-template.md

对应模板；仅当项目尚未拥有对应模板时，才使用本Skill附带的

templates/<name>-template.md

——此时需先创建对应子目录，再将Skill附带的模板原样复制到正确位置，之后再创建正式的Epic/Feature/US。不得自行修改这两类模板之外的结构/字段名称。

docs/glossary/glossary.md

和

docs/system-overview/c4-container.md

必须已存在（来自上一步，参考Skill

setup-context

c4-model

）——这两个文件不是模板，无法自动生成，若尚未存在必须严格按步骤顺序完成前置操作。

docs/spec-kit-conventions.md

需遵循上述模板选择规则：在执行以下任何操作前先检查是否已存在，若不存在则从

templates/spec-kit-conventions.md

原样复制。核心规则已在以下章节中重申，完整内容可查看

docs/spec-kit-conventions.md

——包括前缀/ID规则、

status

生命周期、术语链接、变更传递矩阵。

Nguyên tắc khi chạy skill này

执行本Skill的原则

BR/UR/FR nguồn còn sơ sài/chưa đủ chi tiết để phân rã → brainstorm rồi hỏi lại, đừng hỏi lại kiểu "bạn nói rõ hơn được không?". Dựa vào ngữ cảnh đã có (nội dung BR/UR/FR, C4 container, glossary, các Epic/Feature/US đã tạo trong cùng phiên), chủ động đề xuất 2-4 khả năng cụ thể (ví dụ: "Epic này có thể chia thành nhóm chức năng A, B, C — đúng không, hay còn thiếu nhóm nào?", "US này có cần xử lý edge case X không?") rồi hỏi user xác nhận/chọn/sửa. Đây KHÔNG phải ngoại lệ cho việc "không tự suy đoán" ở các mục dưới — mọi khả năng brainstorm ra chỉ là câu hỏi gợi ý, CHỈ ghi vào Epic/Feature/US sau khi user xác nhận rõ ràng. Nếu sau khi brainstorm mà user vẫn chưa quyết được, dừng lại hỏi thẳng, không tự chọn 1 phương án rồi ghi vào tài liệu.
Đi từ trên xuống: xác nhận Epic trước, rồi mới hỏi Feature bên trong Epic đó, rồi User Story bên trong Feature. Không nhảy cấp, không hỏi dồn tất cả cùng lúc.
Mỗi cấp phải trỏ đúng
```
parent_*
```
theo bảng tiêu chí ở trên, và về đúng BR/UR/FR nguồn.
Epic cần điền
```
source_container
```
(mã container, cột "Mã" trong
```
docs/system-overview/c4-container.md
```
) — không tự đặt mã container mới ở bước này; để trống (
```
null
```
) nếu chỉ có 1 container cho toàn hệ thống.
Epic nằm phẳng trong
```
docs/backlog/epics/
```
. Feature/User Story nằm trong subfolder theo Epic sở hữu (tránh 1 thư mục phẳng chứa hàng nghìn file khi backlog lớn):
```
docs/backlog/{features,user-stories}/{EPIC-ID}_{slug-epic}/{PREFIX}-xxx_{slug}.md
```
, trong đó
```
{EPIC-ID}_{slug-epic}
```
trùng đúng tên file Epic sở hữu (bỏ đuôi
```
.md
```
). Tạo subfolder này khi tạo Feature đầu tiên của Epic đó.
Mọi User Story mới tạo qua skill này bắt buộc có Acceptance Criteria dạng Given/When/Then (đủ rõ, bao phủ edge case quan trọng) và "Context cho Agent" — không tạo US thiếu các mục này, hỏi lại user nếu họ chỉ đưa ý tưởng chung chung. (US tạo trước khi
```
US-template.md
```
có các mục này có thể chưa đủ — không bắt buộc bổ sung ngược, chỉ áp dụng cho US mới.)
"AC phải phủ edge case" (trên) và "không tự bịa nội dung" (nguyên tắc chung của kit) có thể đụng nhau trên cùng 1 dòng AC — ví dụ hành vi lỗi cụ thể, ngưỡng số, thứ tự ưu tiên khi xung đột mà user chưa xác nhận chi tiết. Khi gặp trường hợp này, KHÔNG tự chọn ngầm giữa 3 lối tắt (bịa chi tiết cụ thể / bỏ trống dòng AC / chỉ ghi vào "Ghi chú kỹ thuật" mà không tạo OQ): brainstorm 1 đề xuất cụ thể (xem nguyên tắc brainstorm-rồi-hỏi ở trên), viết vào dòng AC kèm nhãn
```
[Agent đề xuất — cần PO xác nhận]
```
, và nếu edge case này đủ quan trọng để không thể bắt đầu Bước C mà chưa rõ → tạo
```
OQ-*
```
+ set
```
blocked_by_open_questions
```
trên US đó (theo
```
docs/spec-kit-conventions.md
```
mục 2, nguyên tắc chung #4), không chỉ ghi chú suông rồi bỏ qua.
User Story phải đủ nhỏ theo 2 dấu hiệu ở trên; nếu user mô tả một User Story không đạt, đề xuất tách thành nhiều User Story.
Tất cả tạo mới ở
```
status: draft
```
. Không tự set
```
approved
```
— đó là quyết định của team khi review/khi việc thực sự xong.
Nếu một item phụ thuộc vào điều chưa rõ, không tự đoán — tạo file mới từ
```
docs/meetings/open-questions/OQ-template.md
```
và set
```
status: blocked
```
kèm
```
blocked_by_open_questions
```
trên item đó.
Nếu một Feature/US chỉ thực hiện được sau khi Feature/US khác xong (phụ thuộc thứ tự, không phải chờ quyết định) → ghi ID đó vào field
```
depends_on
```
của item, KHÔNG dùng
```
status: blocked
```
/
```
blocked_by_open_questions
```
cho trường hợp này. Không bắt đầu thực hiện một item khi
```
depends_on
```
còn ID chưa
```
status: approved
```
.
Khi viết nội dung Epic/Feature/US, thuật ngữ đã có trong
```
docs/glossary/glossary.md
```
→ gắn link Markdown tới đúng mục ở lần xuất hiện đầu tiên trong tài liệu (xem
```
docs/spec-kit-conventions.md
```
mục 3).

原始BR/UR/FR仍不完善/细节不足无法拆解→先头脑风暴再确认，不要直接问「你能说清楚点吗？」。基于已有上下文（BR/UR/FR内容、C4容器、术语表、本次会话中已创建的Epic/Feature/US），主动提出2-4个具体方案（例如：「该Epic可拆分为A、B、C功能组——是否正确，或是否遗漏了其他组？」「这个US是否需要处理X边缘场景？」），再请用户确认/选择/修改。这不属于以下「不得自行臆断」原则的例外——所有头脑风暴出的方案仅为提示性问题，仅在用户明确确认后才可写入Epic/Feature/US。若头脑风暴后用户仍无法决定，应停止操作直接询问，不得自行选择方案写入文档。
自上而下：先确认Epic，再询问该Epic下的Feature，最后询问Feature下的User Story。不得跨层级操作，不得一次性询问所有内容。
每个层级必须按上述标准填写正确的
```
parent_*
```
字段，并关联对应的原始BR/UR/FR。
Epic需填写
```
source_container
```
（容器代码，对应
```
docs/system-overview/c4-container.md
```
中的「代码」列）——此步骤不得自行设置新的容器代码；若整个系统仅包含1个容器，则留空（
```
null
```
）。
Epic直接存放在
```
docs/backlog/epics/
```
目录下。Feature/User Story需存放在所属Epic对应的子目录中（避免单个目录在backlog庞大时包含数千个文件）：
```
docs/backlog/{features,user-stories}/{EPIC-ID}_{slug-epic}/{PREFIX}-xxx_{slug}.md
```
，其中
```
{EPIC-ID}_{slug-epic}
```
与所属Epic的文件名完全一致（去掉
```
.md
```
后缀）。在创建Epic的第一个Feature时创建该子目录。
通过本Skill新创建的所有User Story必须包含Given/When/Then格式的验收标准（明确清晰，覆盖重要边缘场景）以及「Agent上下文」——不得创建缺少这些内容的US，若用户仅提供笼统想法需向其确认补充。（在
```
US-template.md
```
添加这些字段之前创建的US可能不完整——无需回溯补充，仅适用于新创建的US。）
「验收标准需覆盖边缘场景」（上文）与「不得自行编造内容」（套件核心原则）可能在同一条验收标准中冲突——例如用户尚未明确确认的具体错误行为、数值阈值、冲突时的优先级等。遇到此类情况，不得自行选择以下三种捷径（编造具体细节/留空验收标准行/仅写入「技术备注」而不创建OQ）：头脑风暴提出一个具体建议（参考上文头脑风暴后确认的原则），写入验收标准行并添加标签
```
[Agent提议——需PO确认]
```
，若该边缘场景重要到无法进入下一阶段则需创建
```
OQ-*
```
文件，并在US上设置
```
blocked_by_open_questions
```
（遵循
```
docs/spec-kit-conventions.md
```
第2章核心原则#4），不得仅写入备注后忽略。
User Story需符合上述两个「足够小」的标准；若用户描述的User Story不达标，建议拆分为多个User Story。
所有新创建的内容初始状态为
```
status: draft
```
。不得自行设置为
```
approved
```
——这是团队在审核/完成实际工作后的决策。
若某条目依赖于尚未明确的内容，不得自行臆断——从
```
docs/meetings/open-questions/OQ-template.md
```
创建新文件，并在该条目上设置
```
status: blocked
```
及
```
blocked_by_open_questions
```
。
若某Feature/US需在其他Feature/US完成后才能执行（依赖顺序，而非等待决策）→将对应ID写入该条目的
```
depends_on
```
字段，不得使用
```
status: blocked
```
/
```
blocked_by_open_questions
```
处理此类情况。当
```
depends_on
```
中的ID仍处于非
```
status: approved
```
状态时，不得开始执行该条目。
编写Epic/Feature/US内容时，若术语已存在于
```
docs/glossary/glossary.md
```
中→在文档中首次出现时添加Markdown链接指向对应条目（参考
```
docs/spec-kit-conventions.md
```
第3章）。

Quy trình

流程

Xác nhận
```
docs/business-requirement
```
,
```
docs/user-requirement
```
,
```
docs/functional-requirement
```
liên quan đã
```
status: approved
```
, và
```
docs/system-overview/c4-container.md
```
đã tồn tại (không bắt buộc
```
status: approved
```
, nhưng phải có bảng "Danh sách container" để tra
```
source_container
```
ở bước 2). Nếu thiếu điều nào, dừng lại và nhắc user hoàn thiện trước.
Hỏi Epic: "Mục tiêu kinh doanh lớn nào từ BR-xxx đang cần hiện thực hoá?" (điền
```
docs_requirements: [BR-xxx, ...]
```
— có thể nhiều BR nếu Epic hiện thực hoá mục tiêu chung của nhiều BR) → đối chiếu mục tiêu đó với cột "Trách nhiệm" trong
```
docs/system-overview/c4-container.md
```
để tìm container khớp, rồi lấy đúng "Mã" của container đó cho
```
source_container
```
. Nếu mục tiêu khớp trách nhiệm của nhiều container vì chúng cùng phục vụ 1 mảng giá trị lớn duy nhất (ví dụ container UI + API của cùng 1 luồng nghiệp vụ full-stack) → không tách Epic chỉ vì lý do này — chọn container chủ/đại diện (thường là container người dùng tương tác chính) làm
```
source_container
```
, Feature/US bên dưới phản ánh đầy đủ mọi container thực sự tham gia qua "Context cho Agent". Chỉ tách thành nhiều Epic khi Epic thực sự gộp nhiều mảng giá trị kinh doanh khác nhau (khác cả mục tiêu/persona được phục vụ, không chỉ khác container), mỗi Epic 1
```
source_container
```
. Nếu không container nào khớp, hoặc bảng container chưa có mã/chưa đủ rõ để quyết định — đây không phải việc để tự suy đoán ở bước này: dừng lại, hỏi trực tiếp user muốn đặt mã/tên container nào (hoặc nhờ user/team bổ sung
```
docs/system-overview/c4-container.md
```
trước) rồi mới tiếp tục tạo
```
docs/backlog/epics/EPIC-xxx_<slug>.md
```
.
Hỏi Feature (cho từng Epic vừa tạo): "Epic này gồm những nhóm chức năng con nào?" — nếu user chỉ trả lời chung chung, brainstorm 2-4 nhóm chức năng cụ thể dựa trên Mục tiêu của Epic + UR/FR nguồn rồi hỏi lại (xem nguyên tắc ở trên) → tạo
```
docs/backlog/features/{EPIC-ID}_{slug-epic}/FEAT-xxx_<slug>.md
```
cho mỗi Feature (subfolder trùng tên file Epic sở hữu),
```
parent_epic
```
+
```
docs_requirements
```
(UR liên quan) tương ứng. Nếu số Feature sắp vượt ~20, dừng lại nhắc user cân nhắc tách Epic (xem tiêu chí phân rã ở trên) trước khi tạo thêm.
Hỏi User Story (cho từng Feature): "Ai (persona từ UR) cần làm gì, để được lợi ích gì? Given/When/Then là gì?" — nếu user chỉ trả lời chung chung, brainstorm hành vi/edge case cụ thể dựa trên FR nguồn + Feature cha rồi hỏi lại → tạo
```
docs/backlog/user-stories/{EPIC-ID}_{slug-epic}/US-xxx_<slug>.md
```
(cùng Epic với Feature cha), điền
```
docs_requirements: [FR-xxx, ...]
```
và "Context cho Agent" (trỏ tới FR + system overview liên quan). Hỏi tiếp: "Còn edge case/trường hợp lỗi nào cần thêm vào Acceptance Criteria không?" → bổ sung ngay vào phần Acceptance Criteria — nếu không trả lời được cụ thể, coi đây là dấu hiệu User Story chưa đủ rõ/nhỏ (xem tiêu chí "User Story đủ nhỏ/đủ rõ" ở trên), hỏi lại hoặc tách tiếp trước khi tạo file.
Với mỗi Feature/User Story vừa tạo, hỏi user: "Có phụ thuộc item nào khác cần xong trước không?" → nếu có, điền ID vào
```
depends_on
```
.
Cập nhật ngược: liệt kê Feature vào phần "Phạm vi" của Epic, US vào "User stories thuộc feature này" của Feature. Trước khi coi bước này xong: liệt kê ra từng file Epic/ Feature/US đã tạo/sửa trong phiên — không dừng ở mức "đã kiểm cả 3 cấp", vì khi 1 cấp có nhiều file (ví dụ 9 User Story), kiểm "cả cấp US" một cách chung chung vẫn có thể chỉ thực sự kiểm 1-2 file đầu rồi bỏ sót các file còn lại (lỗi thật đã xảy ra: 0/9 User Story có link glossary thật, dù skill này đã có bước kiểm cả 3 cấp từ trước). Đọc lại thủ công không đủ tin cậy cho bước này (lỗi thật đã tái diễn ở 1 lượt eval khác, 16/19 file, dù đã biết trước rủi ro): liệt kê toàn bộ thuật ngữ có trong
```
docs/glossary/glossary.md
```
, dùng công cụ tìm chuỗi sẵn có (search/grep) quét từng file trong danh sách trên theo từng thuật ngữ đó, thay vì chỉ đọc mắt — với file nào phát hiện thiếu, kiểm lại đúng lần xuất hiện đầu tiên trong thân bài có link chưa (xem nguyên tắc ở trên,
```
docs/spec-kit-conventions.md
```
mục 3). Nếu file đó đã
status: approved
(ví dụ đang groom lại 1 item cũ) khi phát hiện thiếu link — đưa lại về
```
draft
```
trước khi sửa (xem
```
docs/spec-kit-conventions.md
```
mục 1), không sửa thẳng nội dung mà giữ nguyên
```
approved
```
.
Trước khi kết thúc phiên, quét lại toàn bộ Acceptance Criteria/business rule vừa viết trong phiên (không chỉ chi tiết user đã hỏi tường minh) — tìm mọi chi tiết cụ thể mà user chưa xác nhận trực tiếp, cả định lượng (số/ngưỡng, thứ tự ưu tiên khi xung đột) lẫn định tính (hành vi lỗi cụ thể, business rule diễn đạt chắc chắn dù chỉ là suy đoán — không chỉ quét chi tiết có số). Với mỗi chi tiết như vậy, áp dụng đúng quy tắc "AC phải phủ edge case đụng không tự bịa nội dung" ở trên (nhãn
```
[Agent đề xuất — cần PO xác nhận]
```
+ tạo OQ nếu đủ quan trọng) — không chỉ áp dụng cho chi tiết đã được hỏi tường minh trong hội thoại rồi bỏ qua các chi tiết tương tự khác. Đối chiếu AC với business rule đã chốt ở FR nguồn: với mỗi Acceptance Criteria vừa viết, kiểm xem nội dung có mâu thuẫn với business rule đã ghi trong FR mà US đó trỏ tới (
```
docs_requirements
```
) không — ví dụ FR đã chốt "không tự động gán kỹ thuật viên" nhưng 1 AC lại giả định hệ thống tự gán. Đây là lỗi khác với việc thiếu edge case hay fabricate chi tiết mới: AC đi ngược lại 1 rule đã có sẵn, nguy hiểm hơn vì đọc qua vẫn "có vẻ hợp lý" nếu không chủ động lật lại FR nguồn để so — không suy luận từ trí nhớ nội dung FR lúc viết AC, đọc lại FR gốc để đối chiếu từng AC. Phạm vi quét bao gồm cả tầng C4 mà backlog vừa tham chiếu tới (
```
c4-container.md
```
,
```
c4-component-*.md
```
,
```
container-interface.md
```
,
```
entity-interface.md
```
nếu tồn tại, trong
```
source_container
```
/
```
Context cho Agent
```
của Epic/US vừa tạo) — xác minh bước "liệt kê rồi chờ user xác nhận" của
```
c4-model
```
thực sự đã xảy ra (có phản hồi thật của user trong mục "Xác nhận với user" của file Component/Container và trong mục ghi giả định cần xác nhận của
entity-interface.md
nếu file này tồn tại — tên/số mục theo đúng template hiện tại, không cứng theo số cụ thể ở đây, không chỉ khẳng định suông), và mọi mã CIC được US tham chiếu đều có mặt trong bảng tổng hợp CIC; nếu phát hiện component/CIC/giả định entity nào chưa từng được xác nhận, xử lý như 1 chi tiết chưa xác nhận ở trên, không im lặng dùng tiếp. Đây là giới hạn cố hữu, không phải checklist làm 1 lần là triệt để: cùng 1 lượt suy luận vừa viết vừa tự rà dễ chỉ nhớ lại đúng những chỗ nó tự thấy "cần chú ý" lúc viết, bỏ sót chi tiết nó không nhớ là đã tự thêm vào. Nếu khả thi, chạy bước này như 1 lượt riêng, đọc lại toàn bộ tài liệu như người ngoài chưa biết trước phiên viết đã cài gì, thay vì xen kẽ ngay trong lúc viết. Re-verify
priority
theo đúng thuật toán 3 nhánh (xem
```
docs/spec-kit-conventions.md
```
mục 4) thay vì gán theo cảm tính: với từng Feature/US vừa tạo/sửa trong phiên, lần theo
```
docs_requirements
```
tới đúng dòng nhu cầu MoSCoW nguồn (nếu trỏ nguyên 1 UR, chọn dòng khớp nội dung, không lấy đại dòng đầu/dòng cao nhất — xem mục 4), xác định item đó rơi vào đúng 1 trong 3 nhánh
```
depends_on
```
(chặn ai / bị ai chặn / không quan hệ nào), rồi đối chiếu giá trị
```
priority
```
đã gán có khớp nhánh đó không. Đây là lỗi thật đã xảy ra: agent gán
```
priority
```
cảm tính, bỏ qua thuật toán dù đã có sẵn — kiểm tra sai giống hệt kiểu sai của bước glossary-link ở trên (đọc lướt/suy đoán thay vì đối chiếu từng file), nên áp dụng cùng mức nghiêm ngặt: liệt kê từng file Feature/US, không dừng ở mức "đã kiểm cả cấp".

确认关联的
```
docs/business-requirement
```
、
```
docs/user-requirement
```
、
```
docs/functional-requirement
```
已处于
```
status: approved
```
状态，且
```
docs/system-overview/c4-container.md
```
已存在（无需
```
status: approved
```
，但必须包含「容器列表」表格以便在步骤2中查询
```
source_container
```
）。若缺少任何条件，停止操作并提醒用户先完成前置工作。
询问Epic：「BR-xxx中的哪个重大业务目标需要落地？」（填写
```
docs_requirements: [BR-xxx, ...]
```
——若Epic落地多个BR的共同目标，可关联多个BR）→将该目标与
```
docs/system-overview/c4-container.md
```
中的「职责」列匹配，找到对应的容器，取其「代码」填入
```
source_container
```
。若该目标匹配多个容器的职责且这些容器共同服务于同一个大价值模块（例如同一全栈业务流程的UI容器+API容器）→不得仅因容器不同而拆分Epic——选择主/代表容器（通常是用户交互的核心容器）作为
```
source_container
```
，下属的Feature/US通过「Agent上下文」反映所有实际参与的容器。仅当Epic确实合并了多个不同的业务价值模块（服务的目标/用户角色不同，而非仅容器不同）时，才拆分为多个Epic，每个Epic对应一个
```
source_container
```
。若没有匹配的容器，或容器表格的代码/信息不足以决策——此步骤不得自行臆断：停止操作，直接询问用户希望设置哪个容器代码/名称（或请用户/团队先补充
```
docs/system-overview/c4-container.md
```
），之后再创建
```
docs/backlog/epics/EPIC-xxx_<slug>.md
```
。
询问Feature（针对每个刚创建的Epic）：「该Epic包含哪些子功能组？」——若用户仅给出笼统回答，基于Epic目标+原始UR/FR头脑风暴2-4个具体功能组后再次确认（参考上述原则）→为每个Feature创建
```
docs/backlog/features/{EPIC-ID}_{slug-epic}/FEAT-xxx_<slug>.md
```
（子目录与所属Epic的文件名一致），填写对应的
```
parent_epic
```
+
```
docs_requirements
```
（关联的UR）。若Feature数量即将超过20个，停止操作并提醒用户考虑先拆分Epic（参考上文拆解标准）再继续创建。
询问User Story（针对每个Feature）：「谁（来自UR的用户角色）需要做什么，以获得什么收益？Given/When/Then是什么？」——若用户仅给出笼统回答，基于原始FR+父Feature头脑风暴具体行为/边缘场景后再次确认→创建
```
docs/backlog/user-stories/{EPIC-ID}_{slug-epic}/US-xxx_<slug>.md
```
（与父Feature同属一个Epic），填写
```
docs_requirements: [FR-xxx, ...]
```
及「Agent上下文」（关联FR+相关系统概述）。继续询问：「是否还有其他边缘场景/错误情况需要添加到验收标准中？」→直接补充到验收标准部分——若无法给出具体回答，视为该User Story仍不够清晰/细化（参考上文「User Story足够小/清晰」标准），需再次确认或继续拆分后再创建文件。
针对每个刚创建的Feature/User Story，询问用户：「是否依赖其他需要先完成的条目？」→若有，将对应ID填入
```
depends_on
```
。
反向更新：将Feature列表写入Epic的「范围」部分，将US列表写入Feature的「本Feature所属的User Stories」部分。在完成此步骤前：列出本次会话中创建/修改的每个Epic/Feature/US文件——不得仅停留在「已检查所有三层」的层面，因为当某一层包含多个文件（例如9个User Story）时，笼统地「检查整个US层」可能仅实际检查了前1-2个文件而遗漏其余（实际错误案例：9个User Story中0个包含有效的术语链接，尽管本Skill此前已设置了全三层检查步骤）。仅手动阅读不足以保证此步骤的准确性（实际错误案例：19个文件中16个存在问题，尽管已提前知晓风险）：列出
```
docs/glossary/glossary.md
```
中的所有术语，使用内置的字符串搜索工具（search/grep）针对上述列表中的每个文件逐一搜索每个术语，而非仅用肉眼阅读——若发现某文件缺少链接，检查正文中首次出现的术语是否已添加链接（参考上述原则，
```
docs/spec-kit-conventions.md
```
第3章）。若该文件已处于
status: approved
状态（例如正在梳理旧条目），发现缺少链接时需先将状态改回
```
draft
```
再修改（参考
```
docs/spec-kit-conventions.md
```
第1章），不得直接修改内容而保留
```
approved
```
状态。
在会话结束前，重新检查本次会话中编写的所有验收标准/业务规则（不仅限于用户明确询问的细节）——找出所有用户未直接确认的具体细节，包括定量（数值/阈值、冲突时的优先级）和定性（具体错误行为、尽管是臆断但表述确定的业务规则——不仅搜索带数值的细节）。针对每个此类细节，严格遵循上文「验收标准需覆盖边缘场景但不得自行编造内容」的规则（添加
```
[Agent提议——需PO确认]
```
标签，若足够重要则创建OQ）——不得仅对用户明确询问的细节应用该规则而忽略其他类似细节。 将验收标准与原始FR中已确定的业务规则对比：针对每个刚编写的验收标准，检查内容是否与该US关联的FR（
```
docs_requirements
```
）中已记录的业务规则冲突——例如FR已确定「不得自动分配技术人员」但某验收标准假设系统会自动分配。这与缺少边缘场景或编造新细节的错误不同：验收标准违反了已有的规则，若不主动回溯原始FR对比则更容易被忽略，因为表面看起来「合理」——编写验收标准时不要依赖对FR内容的记忆，需重新阅读原始FR逐一对比每个验收标准。 检查范围需涵盖backlog刚引用的C4层级（
```
c4-container.md
```
、
```
c4-component-*.md
```
、
```
container-interface.md
```
、
```
entity-interface.md
```
（若存在），对应刚创建的Epic/US的
```
source_container
```
/「Agent上下文」）——验证
```
c4-model
```
的「列出并等待用户确认」步骤是否实际完成（在Component/Container文件的「与用户确认」部分以及
entity-interface.md
的「需确认的假设」部分（若该文件存在）有用户的真实反馈——需匹配当前模板的对应章节名称，而非固定某一编号，不得笼统断言），且US引用的所有CIC代码均存在于CIC汇总表中；若发现任何未被确认的组件/CIC/实体假设，按上述未确认细节的规则处理，不得继续使用。这是固有限制，并非一次性检查即可彻底解决：同一轮思考中边写边自查容易仅记住自己认为「需要注意」的部分，遗漏自己添加的其他细节。若可行，将此步骤作为独立环节，像外部人员一样重新阅读所有文档，而非在编写过程中穿插进行。按三分支算法重新验证
priority
（参考
```
docs/spec-kit-conventions.md
```
第4章），而非凭感觉赋值：针对本次会话中创建/修改的每个Feature/US，追溯
```
docs_requirements
```
到原始MoSCoW需求的对应行（若关联整个UR，选择匹配内容的行，不得直接取第一行/最高优先级行——参考第4章），确定该条目属于
```
depends_on
```
的三个分支之一（阻塞他人/被他人阻塞/无关联），再对比已赋值的
```
priority
```
是否匹配该分支。这是实际发生过的错误：Agent凭感觉赋值
```
priority
```
，忽略已有的算法——检查错误模式与上述术语链接步骤相同（浏览/臆断而非逐一对比文件），因此需应用同等严格的标准：列出每个Feature/US文件，不得仅停留在「已检查整个层级」的层面。