backlog-status

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

backlog-status

Không có "Điều kiện tiên quyết" riêng — skill này chỉ đọc frontmatter đã có, không tạo/scaffold file nào (kể cả

docs/spec-kit-conventions.md

— đọc nếu đã có trong dự án; nếu chưa có, đọc trực tiếp bản đi kèm skill tại

templates/spec-kit-conventions.md

thay vì tự tạo file mới, đúng tinh thần read-only của skill này). Quy tắc

status

blocked

parent_*

depends_on

dùng ở dưới được tóm tắt đầy đủ hơn ở đó.

Skill chỉ đọc (read-only) — không sửa file nào. Mục tiêu: tổng hợp nhanh trạng thái backlog + quan hệ cha-con giữa các cấp, từ frontmatter, vì kit này không duy trì file dashboard/index riêng (tránh trùng lặp nội dung đã có trong frontmatter, tránh dữ liệu cũ do quên cập nhật). Mục "Phạm vi"/"User stories thuộc feature này" trong từng file Epic/Feature là bản tóm tắt cho người đọc, có thể bị quên cập nhật khi tạo item mới thủ công (không qua skill

plan-backlog

) — skill này KHÔNG dựa vào các mục đó, chỉ dựa vào field

parent_*

(

parent_epic

parent_feature

— quan hệ cha-con trong backlog) và

docs_requirements

(liên kết tới BR/UR/FR), nguồn duy nhất, luôn đúng vì mỗi file backlog bắt buộc có các field này.

Epic nằm phẳng trong

docs/backlog/epics/

; Feature/User Story nằm trong subfolder theo Epic sở hữu (

docs/backlog/{features,user-stories}/{EPIC-ID}_{slug}/...

) — khi quét các thư mục này, đọc đệ quy qua mọi subfolder (không chỉ cấp ngay bên dưới), vẫn loại trừ mọi

*-template.md

. Subfolder chỉ là tổ chức vật lý, không thay đổi cách xác định quan hệ cha-con (vẫn dựa vào

parent_*

, không suy ra Epic sở hữu từ tên subfolder).

无特殊“前置条件”——此skill仅读取已有的frontmatter，不会创建/生成任何文件（包括

docs/spec-kit-conventions.md

——若项目中已存在则读取；若不存在，则直接读取skill附带的

templates/spec-kit-conventions.md

版本，而非自行创建新文件，符合此skill的只读特性）。下文使用的

status

blocked

parent_*

depends_on

规则在该文档中有更完整的概述。

此skill仅为只读（read-only）——不会修改任何文件。目标：快速汇总backlog状态 + 各层级间的父子关系，数据来源为frontmatter，因为此套件不维护单独的仪表盘/索引文件（避免与frontmatter中已有的内容重复，防止因忘记更新导致数据过时）。每个Epic/Feature文件中的“范围”/“属于此Feature的User Stories”部分是为读者准备的摘要，手动创建新条目时（未通过

plan-backlog

skill）可能会忘记更新——此skill不依赖这些部分，仅依赖

parent_*

字段（

parent_epic

、

parent_feature

——backlog中的父子关系）和

docs_requirements

（关联到BR/UR/FR），这是唯一的、始终准确的来源，因为每个backlog文件都必须包含这些字段。

Epic直接存放在

docs/backlog/epics/

目录下；Feature/User Story存放在所属Epic对应的子目录中（

docs/backlog/{features,user-stories}/{EPIC-ID}_{slug}/...

）——扫描这些目录时，会递归遍历所有子目录（不仅是直接下级），但会排除所有

*-template.md

文件。子目录仅为物理组织方式，不会改变父子关系的判定逻辑（仍基于

parent_*

字段，不会从子目录名称推断所属Epic）。

Quy trình

流程

Backlog hiện có: đọc frontmatter mọi file trong
```
docs/backlog/{epics,features,user-stories}/
```
(đệ quy qua subfolder theo Epic, trừ các
```
*-template.md
```
). "Backlog" là mọi item
```
status: draft
```
và không
```
blocked
```
(chưa
```
approved
```
nghĩa là chưa xong). Nhóm theo loại (Epic/Feature/US) rồi theo
```
status
```
:
- ```
blocked
```
  → liệt kê riêng, kèm
```
blocked_by_open_questions
```
  để user biết đang chờ OQ nào.
- ```
draft
```
  → liệt kê theo nhóm (đây là phần có thể bắt đầu thực hiện), sắp xếp theo field
```
priority
```
  trên Feature/US (
```
P0
```
  trước,
```
P3
```
  sau cùng,
```
null
```
  xếp cuối) — đúng thứ tự xử lý backlog. Epic không có
```
priority
```
  , giữ nguyên nhóm.
- Với mỗi item còn ID trong
```
depends_on
```
  mà ID đó chưa
```
status: approved
```
  → đánh dấu riêng "chưa thể bắt đầu (chờ <ID> xong)" cạnh item đó, dù
```
status
```
  hiện tại là
```
draft
```
  .
- Không liệt kê item đã
```
status: approved
```
  /
```
deprecated
```
  — không còn tính là backlog đang mở.
- ```
blocked
```
  không cascade từ con lên cha (xem
```
docs/spec-kit-conventions.md
```
  mục 2, nguyên tắc chung #4): 1 Feature/Epic
```
draft
```
  có toàn bộ US/Feature con đang
```
blocked
```
  vẫn liệt kê ở nhóm
```
draft
```
  như bình thường (không tự chuyển nhóm
```
blocked
```
  ) — nhưng ghi kèm 1 ghi chú riêng "toàn bộ con đang blocked, chưa có việc nào làm được ngay" để user không hiểu nhầm là còn việc thực hiện được.
Cây phân cấp Epic → Feature → User Story: đọc frontmatter mọi file trong
```
docs/backlog/{epics,features,user-stories}/
```
(đệ quy qua subfolder theo Epic, trừ
```
*-template.md
```
), dựng cây từ
```
parent_epic
```
(Feature),
```
parent_feature
```
(User Story). Đọc thêm frontmatter (chỉ để lấy
```
id
```
) của
```
docs/business-requirement/
```
,
```
docs/user-requirement/
```
,
```
docs/functional-requirement/
```
(trừ
```
*-template.md
```
) để verify các field
```
parent_*
```
trỏ sang BR/UR/FR dưới đây có tồn tại thật:
- Với 1 Epic cụ thể được hỏi tới, hoặc toàn bộ backlog nếu user không chỉ định: in cây thụt lề theo cấp, mỗi node kèm ID + tên +
```
status
```
  (ví dụ
```
EPIC-001 (draft) — Quản lý Task cá nhân
```
  → thụt lề
```
FEAT-001 (draft) — CRUD Task
```
  → thụt lề tiếp
```
US-001 (approved) — ...
```
  ).
- Phát hiện liên kết gãy: nếu 1 file có
```
parent_*
```
  /
```
docs_requirements
```
  trỏ tới ID không tồn tại (đã bị xoá/đổi tên/gõ sai) — bao gồm
```
parent_epic
```
  /
```
parent_feature
```
  (trong
```
docs/backlog
```
  ) lẫn
```
docs_requirements
```
  trên Epic/Feature/US (mảng, bắt buộc ≥1 ID — kiểm tra từng ID trong mảng theo đúng prefix:
```
BR-*
```
  tra trong
```
docs/business-requirement/
```
  ,
```
UR-*
```
  tra trong
```
docs/user-requirement/
```
  ,
```
FR-*
```
  tra trong
```
docs/functional-requirement/
```
  ) — liệt kê riêng phần "Liên kết gãy" — không bỏ qua âm thầm.
- Phát hiện item mồ côi ở đúng cấp của nó: item không match được vào cây (parent không tồn tại, dù ở tầng backlog hay trỏ ngược lên BR/UR/FR) → liệt kê ở "Liên kết gãy" cùng mục trên, không tự đoán nên gắn vào đâu.
- Nếu node có
```
depends_on
```
  khác rỗng, ghi kèm ngay sau status, ví dụ
```
US-007 (draft, chờ US-004) — ...
```
  khi US-004 chưa
```
approved
```
  .
Trình bày kết quả dạng bảng/cây/gạch đầu dòng ngắn gọn, không diễn giải dài dòng. Nếu user chỉ hỏi 1 trong 2 phần (backlog hoặc cây phân cấp), chỉ trả lời phần đó.

当前Backlog：读取
```
docs/backlog/{epics,features,user-stories}/
```
目录下所有文件的frontmatter（按Epic递归遍历子目录，排除
```
*-template.md
```
）。“Backlog”指所有
```
status: draft
```
且未被
```
blocked
```
的条目（未
```
approved
```
表示尚未完成）。按类型（Epic/Feature/US）分组，再按
```
status
```
分组：
- ```
blocked
```
  → 单独列出，并附带
```
blocked_by_open_questions
```
  字段，让用户了解正在等待哪些未解决问题（OQ）。
- ```
draft
```
  → 分组列出（这是可开始执行的部分），按Feature/US的
```
priority
```
  字段排序（
```
P0
```
  优先，
```
P3
```
  最后，
```
null
```
  排在末尾）——符合backlog的处理顺序。Epic没有
```
priority
```
  字段，保持原分组。
- 若条目
```
depends_on
```
  中包含的ID对应的条目尚未
```
status: approved
```
  → 即使当前条目
```
status
```
  为
```
draft
```
  ，也需单独标记“无法开始（等待<ID>完成）”。
- 不列出已
```
status: approved
```
  /
```
deprecated
```
  的条目——不再属于待处理的backlog。
- ```
blocked
```
  状态不会从子条目向上级条目传递（参考
```
docs/spec-kit-conventions.md
```
  第2节，通用规则#4）：一个
```
draft
```
  状态的Feature/Epic，即使其所有子US/Feature都处于
```
blocked
```
  状态，仍会正常列在
```
draft
```
  分组中（不会自动转为
```
blocked
```
  分组）——但需附加单独备注“所有子条目均已blocked，暂无可立即执行的工作”，避免用户误解为仍有可执行任务。
Epic → Feature → User Story层级树：读取
```
docs/backlog/{epics,features,user-stories}/
```
目录下所有文件的frontmatter（按Epic递归遍历子目录，排除
```
*-template.md
```
），通过
```
parent_epic
```
（Feature）、
```
parent_feature
```
（User Story）构建层级树。额外读取
```
docs/business-requirement/
```
、
```
docs/user-requirement/
```
、
```
docs/functional-requirement/
```
目录下文件的frontmatter（仅获取
```
id
```
，排除
```
*-template.md
```
），以验证以下
```
parent_*
```
字段指向的BR/UR/FR是否真实存在：
- 若用户询问特定Epic，或未指定则查询整个backlog：按层级缩进输出树状结构，每个节点附带ID + 名称 +
```
status
```
  （例如
```
EPIC-001 (draft) — 个人任务管理
```
  → 缩进
```
FEAT-001 (draft) — CRUD任务
```
  → 继续缩进
```
US-001 (approved) — ...
```
  ）。
- 检测断裂链接：若某个文件的
```
parent_*
```
  /
```
docs_requirements
```
  指向不存在的ID（已删除/重命名/拼写错误）——包括
```
docs/backlog
```
  中的
```
parent_epic
```
  /
```
parent_feature
```
  ，以及Epic/Feature/US上的
```
docs_requirements
```
  （数组，必须包含≥1个ID——按前缀逐一验证数组中的每个ID：
```
BR-*
```
  在
```
docs/business-requirement/
```
  中查询，
```
UR-*
```
  在
```
docs/user-requirement/
```
  中查询，
```
FR-*
```
  在
```
docs/functional-requirement/
```
  中查询）——单独列出“断裂链接”部分，不得忽略。
- 检测孤立条目：无法匹配到层级树中的条目（父级不存在，无论是backlog层级还是指向BR/UR/FR）——与上述“断裂链接”部分一同列出，不得自行推断归属位置。
- 若节点的
```
depends_on
```
  不为空，需在status后附带标注，例如当US-004尚未
```
approved
```
  时，显示
```
US-007 (draft, 等待US-004) — ...
```
  。
以简洁的表格/树状结构/项目符号列表展示结果，无需冗长解释。若用户仅询问其中一部分（backlog或层级树），仅回答对应部分。