To features

Skills shared by soulmachine for improving daily work efficiency with AI Agents (Claude Code, Codex, etc.)

Install

npx -y skills add soulmachine/skills --skill to-features

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

3 stars3 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

Generate FEATURES.md at the repo root by reading CONTEXT.md and docs/adr/, then enumerating the user-facing features the domain implies. Use after /grill-with-docs has settled the domain language and before /to-prd writes per-feature specs. Bridges the product→engineering gap between domain understanding and feature specification — the missing step that mattpocock's chain doesn't cover natively.

SKILL.md

4.2 KB, as published. Nobody here has run it

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).

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.

Process

Read CONTEXT.md for domain vocabulary, actors, and invariants.
Read docs/adr/*.md for architectural commitments that constrain what's buildable.
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.
Surface the list to the user for review:
- Anything missing?
- Should any features be split or merged?
- Are slugs unambiguous?
Write FEATURES.md at the repo root once approved.
(Optional, for local-markdown teams) mkdir -p .scratch/<feature-slug>/issues per pending feature to stub the layout downstream stages will fill.

File format

# 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
- [x] ~~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)

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

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)

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.

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.