Frequently asked questions

It organizes code and folders around features, the business capabilities of a product, rather than technical layers like components, services or utils. Each feature lives in its own self-contained folder with everything it needs. It is similar to domain-driven design but more recursive and more structured, and it complements other architectures such as hexagonal architecture. Read the full explanation.

Create a features folder anywhere in your source code (it can be in a subdirectory). Inside it, create a folder named after the business feature, in snake_case, camelCase or kebab-case. The feature is detected automatically and displayed in the web interface. You can also flag any folder with feature: true in its README front matter.

Create a README.md in the feature folder and describe its purpose, functionality and relevant technical details. The first line of text after the title is used as the short description.

Add an owner property to the front matter of the feature README.md:

---
owner: backend-team
---

In the feature directory, create a __docs__/decisions/ or .docs/decisions/ folder and add a Markdown file with a descriptive name such as use-typescript.md. Structure it with a title, status (proposed, accepted, rejected, deprecated, superseded), context, decision and consequences. The template is inspired by MADR.

Run your tests with coverage enabled, for example npx jest --coverage, so the report lands in a coverage or .coverage folder. The CLI looks in the scanned folder, the current directory and the --project-dir. Use --coverage-dir for any other location. LCOV and Cobertura formats are supported.

Right now the CLI counts the TODOs in the code of each feature. It does not detect other kinds of technical debt such as code smells or performance issues yet. Suggestions are welcome.

Run features codeowners ./src, optionally with --project-dir ./ for paths relative to the project root, or add --generate-codeowners to serve, build or check. The file gets a managed section between markers; anything outside them is preserved. See the example.

The Linux binary was built with a newer GLIBC than your system has. Options, from most to least recommended:

1. Use the statically linked musl build: npm install -g @features-cli/feature-cli-linux-x64-musl (or -arm64-musl).
2. Build from source: cargo install features-cli.
3. Use npx features-cli@latest, which selects the right binary.
4. Upgrade to Ubuntu 24.04, Debian 13, Fedora 39 or later.