majordomus product list

Every feature, narrowed by any filter, with the surfaces derived for each

Usage

majordomus product list [OPTIONS]

Arguments

argument	value	default	description
--repo	<PATH>	—	Start the search for the repository root here (default: the current directory) (accepted by every subcommand)
--discovery	vcs \| filesystem	vcs	How declarative files are enumerated (accepted by every subcommand) `vcs` — Tracked files, through the version-control index (the layer's contract) `filesystem` — A walk of the work tree with the same glob semantics; untracked files included
--strict	flag	—	Refuse to proceed when any file of the layer carries an error diagnostic (accepted by every subcommand)
--share	<DIR>	—	The tool distribution's share directory (kinds.yaml, schemas/); default: $MAJORDOMUS_SHARE, then the repository's own share/, then the one beside the executable (accepted by every subcommand)
--format	text \| json	text	Output shape (accepted by every subcommand) `text` — Lines for a person `json` — One JSON document, deterministic
--featured	flag	—	Only the features the homepage shows (accepted by every subcommand)
--all	flag	—	Include drafts and deprecated features, not only the stable ones (accepted by every subcommand)
--area	<AREA>	—	Only features serving this operational area of the why catalogue (accepted by every subcommand)
--module	<MODULE>	—	Only features made of this capability module (accepted by every subcommand)
--names-command	<NAMES_COMMAND>	—	Only features made of this shell command (accepted by every subcommand)
--surface	<SURFACE>	—	Only features exposed through this surface: cli, api, mcp, cockpit or docs (accepted by every subcommand)
-q, --query	<QUERY>	—	Case-insensitive text over identities, titles, headlines, summaries, tags and bodies (accepted by every subcommand)

Examples

Every stable feature, in presentation order

Drafts are excluded unless `--all` is given; `--featured` narrows to the features the homepage shows. The filters are the facets the model derives — an area, a module, a command, a surface — so a module added to the executable is a filter without anything being registered.
```
$ majordomus product list
```
Verified by the example tests: exits 0; prints SLUG, fixture-feature.
The same, as the shape the API and MCP answer with

One domain model behind every projection: this document is what `GET /api/v1/product/features` returns and what the `majordomus_features` tool answers, with the counts, the fingerprint and the surfaces of every feature.
```
$ majordomus product list --format json
```
Verified by the example tests: exits 0; prints one JSON document carrying /counts/features, /features/0/surfaces, /fingerprint.

Where this comes from

Declared once in apps/majordomus-cli/src/cli.rs: clap for the structure, typed Rust metadata beside it for the examples. This page, majordomus product list --help, docs/generated/cli.md and docs/generated/cli.json are projections of that one declaration.

The whole command line on one page: the registry's command-line page. The task lifecycle (init, start, finish, doctor, ...) belongs to the shell tool, a different program: Commands and its specification.