Back to Details

to-features

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

to-features

to-features

Generate 
FEATURES.md
at the repo root by reading 
CONTEXT.md
and the ADRs under 
docs/adr/
, then enumerating the user-facing features the domain implies. Pairs with 
/grill-with-docs
(upstream, produces CONTEXT.md/ADRs) and 
/to-prd
(downstream, takes one feature → PRD).
通过读取
CONTEXT.md
和
docs/adr/
下的ADR文件，在仓库根目录生成
FEATURES.md
，然后枚举该领域所包含的面向用户的功能。它与上游的
/grill-with-docs
（生成CONTEXT.md/ADRs）和下游的
/to-prd
（将单个功能转换为PRD）配合使用。

When to invoke

调用时机

  • After 
    /grill-with-docs
    has produced or refined 
    CONTEXT.md
    .
  • Before 
    /to-prd
    runs on any individual feature.
  • If 
    FEATURES.md
    already exists, treat this as a refinement — propose additions or strikethroughs based on the latest 
    CONTEXT.md
    and ADRs. Never overwrite shipped (strikethrough) features.
  • 在
    /grill-with-docs
    生成或完善
    CONTEXT.md
    之后。
  • 在对任何单个功能运行
    /to-prd
    之前。
  • 如果
    FEATURES.md
    已存在，则将此操作视为完善——根据最新的
    CONTEXT.md
    和ADRs建议新增内容或添加删除线。绝不要覆盖已发布（带删除线）的功能。

Process

流程

  1. Read 
    CONTEXT.md
     for domain vocabulary, actors, and invariants.
  2. Read 
    docs/adr/*.md
     for architectural commitments that constrain what's buildable.
  3. Enumerate user-facing features the domain implies:
    • One feature per line, kebab-case slug + one-line description.
    • Start with the actor: 
      user-can-…
      , 
      admin-can-…
      , 
      guest-can-…
      .
    • User-facing, not internal — "User can reset password" not "Add bcrypt hashing."
    • Don't include implementation details — those land in PRDs downstream.
  4. Surface the list to the user for review:
    • Anything missing?
    • Should any features be split or merged?
    • Are slugs unambiguous?
  5. Write 
    FEATURES.md
     at the repo root once approved.
  6. (Optional, for local-markdown teams) 
    mkdir -p .scratch/<feature-slug>/issues
    per pending feature to stub the layout downstream stages will fill.
  1. 读取
    CONTEXT.md
    ，获取领域词汇、角色和不变量。
  2. 读取
    docs/adr/*.md
    ，了解限制可构建内容的架构承诺。
  3. 枚举领域包含的面向用户的功能：
    • 每行一个功能，采用短横线命名格式（kebab-case）+ 一行描述。
    • 以角色开头：
      user-can-…
      、
      admin-can-…
      、
      guest-can-…
      。
    • 面向用户，而非内部功能——例如写“用户可重置密码”而非“添加bcrypt哈希处理”。
    • 不要包含实现细节——这些会在下游的PRD中体现。
  4. 将列表呈现给用户审核：
    • 是否有遗漏？
    • 是否有功能需要拆分或合并？
    • 命名是否清晰无歧义？
  5. 审核通过后，在仓库根目录写入
    FEATURES.md
    。
  6. （可选，适用于使用本地Markdown的团队）为每个待处理功能创建
    mkdir -p .scratch/<feature-slug>/issues
    目录，为下游阶段的布局创建占位。

File format

文件格式

markdown
undefined
markdown
undefined

Features

Features

<!-- One feature per line. Strike through completed features; don't delete. -->
  • user-can-sign-up — A user can create an account with email + password
  • user-can-log-in — A user can sign in to their account
  • user-can-reset-password — A user can reset a forgotten password (shipped: #42)
  • user-can-post-photo — A user can upload and share a photo
<!-- One feature per line. Strike through completed features; don't delete. -->
  • user-can-sign-up — A user can create an account with email + password
  • user-can-log-in — A user can sign in to their account
  • user-can-reset-password — A user can reset a forgotten password (shipped: #42)
  • user-can-post-photo — A user can upload and share a photo

Out of scope (rejected)

Out of scope (rejected)

  • user-can-stream-video — Rejected for v1 (see 
    .out-of-scope/video-streaming.md
    )
undefined
  • user-can-stream-video — Rejected for v1 (see 
    .out-of-scope/video-streaming.md
    )
undefined

Discipline: when you finish a feature, strike it through (don't delete)

规范：功能完成后添加删除线（不要删除）

When a feature ships, mark its line in 
FEATURES.md
with strikethrough + a shipped reference (issue number, PR, or tracker ID). Never delete the line. Strikethrough preserves:
  • Institutional memory — what HAS shipped, not just what's pending.
  • Traceability — link from 
    FEATURES.md
    to the issue/PR that completed it.
  • Drift resistance — you can't quietly drop a feature; dropping requires explicitly marking it out of scope (and writing the reason to 
    .out-of-scope/
    ).
Transformation on ship:
- [ ] user-can-reset-password — A user can reset a forgotten password
                              ↓
- [x] ~~user-can-reset-password~~ — ~~A user can reset a forgotten password~~ (shipped: #42)
当功能发布时，在
FEATURES.md
中为该功能的行添加删除线，并附上发布参考（问题编号、PR或跟踪器ID）。绝不要删除该行。删除线可以保留：
  • 机构记忆——已发布的内容，而非仅待处理内容。
  • 可追溯性——从
    FEATURES.md
    链接到完成该功能的问题/PR。
  • 防止偏离——不能悄悄移除功能；移除需要明确标记为超出范围（并将原因写入
    .out-of-scope/
    目录）。
发布时的格式转换：
- [ ] user-can-reset-password — A user can reset a forgotten password
                              ↓
- [x] ~~user-can-reset-password~~ — ~~A user can reset a forgotten password~~ (shipped: #42)

Why this skill exists

该技能存在的原因

mattpocock's chain (
/to-prd
, 
/to-issues
, 
/triage
) is engineering-side — it assumes features come from product thinking that lives outside the toolchain. swe-workflow needs an explicit bridge between domain understanding (the output of 
/grill-with-docs
) and per-feature specification (the input of 
/to-prd
). That bridge is feature enumeration.
This skill is engineering-adjacent: it reads engineering artifacts (
CONTEXT.md
, ADRs), but its output (
FEATURES.md
) is in user-facing language. It's the deliberate seam where product reasoning enters the chain.
mattpocock的工作流（
/to-prd
、
/to-issues
、
/triage
）偏向工程侧——它假设功能来自工具链之外的产品思考。swe-workflow需要一个明确的环节，衔接领域理解（
/grill-with-docs
的输出）和单个功能的规格说明（
/to-prd
的输入）。这个环节就是功能枚举。
该技能与工程相关：它读取工程制品（
CONTEXT.md
、ADRs），但输出（
FEATURES.md
）使用面向用户的语言。这是产品思维进入工作流的刻意衔接点。

When to skip

何时跳过

If your team handles feature enumeration in an external tool — Linear projects, Notion, Productboard, a shared spreadsheet, anything — skip 
/to-features
and use the external source of truth. Pass features directly to 
/to-prd
. This skill exists to fill the seam for teams without an existing product backlog convention, or for solo developers who'd rather keep feature tracking in the repo.
如果你的团队使用外部工具处理功能枚举——比如Linear项目、Notion、Productboard、共享电子表格等——则跳过
/to-features
，使用外部的可信数据源。直接将功能传递给
/to-prd
。该技能的存在是为了填补那些没有现有产品待办事项规范的团队，或更愿意在仓库中跟踪功能的独立开发者的空白。