Background
Darnit today ships three CLI surfaces (darnit audit, darnit run, darnit serve) plus an MCP server. The intended product path is skills invoking darnit serve via MCP; the CLI is for development and testing. This intent lives in maintainer heads (and in RFC-0001) but is not written down anywhere a user would find it.
Problem
A new user opens darnit --help and sees three top-level commands with no signal about which is the front door. They will pick audit or run and never touch serve, which is the actual product path.
Proposal
Add a "How to use darnit" section (README or a short docs page) that:
- Names skills-via-
darnit serve as the product path, with a pointer to the darnit-audit skill.
- Frames
darnit audit / darnit run as debug/dev tools with limited orchestration.
- Points to RFC-0001 for the direction of travel.
Alternative: defer until RFC-0001 Stage 1 (harness driver) lands, which will make this structural. Filing now so it is tracked either way.
Related
- RFC-0001 (Darnit Core Rearchitecture):
docs/rfcs/0001-core-rearchitecture.md
- Architecture review that surfaced this (Aug 2026)
Background
Darnit today ships three CLI surfaces (
darnit audit,darnit run,darnit serve) plus an MCP server. The intended product path is skills invokingdarnit servevia MCP; the CLI is for development and testing. This intent lives in maintainer heads (and in RFC-0001) but is not written down anywhere a user would find it.Problem
A new user opens
darnit --helpand sees three top-level commands with no signal about which is the front door. They will pickauditorrunand never touchserve, which is the actual product path.Proposal
Add a "How to use darnit" section (README or a short docs page) that:
darnit serveas the product path, with a pointer to thedarnit-auditskill.darnit audit/darnit runas debug/dev tools with limited orchestration.Alternative: defer until RFC-0001 Stage 1 (harness driver) lands, which will make this structural. Filing now so it is tracked either way.
Related
docs/rfcs/0001-core-rearchitecture.md