ref-cli-design-prior-art

name	ref-cli-design-prior-art
description	Ground dhcli design decisions in the conventions of comparable CLIs — invoke when choosing a noun, verb, flag name, default, or interaction model, or when reviewing one. Requires citing the tool and the specific behavior being followed, and stating the reason when diverging
user-invocable	false

CLI design prior art

dhcli is a resource-oriented CLI competing for muscle memory with kubectl, docker, gh, aws, gcloud, and git. A user who already knows those tools should be able to guess how this one behaves. Every design decision either follows an established convention or deliberately departs from one — and the difference must be visible in the artifact, not just in the author's head.

The rule

When a design decision has an established convention in a comparable tool, follow it, and cite the tool and the specific behavior.

• Cite the behavior, not the vibe. "kubectl delete prompts only under --interactive" is a citation. "kubectl-style" is not — it conveys nothing a reader can check or apply.
• A citation must be verifiable. Name the flag, the subcommand, or the observable behavior, so a reader can confirm it against that tool's documentation or source. An uncheckable citation is worse than none: it borrows authority it has not earned.
• When diverging, say so and give the reason. A departure is a legitimate design choice; an undocumented departure reads as ignorance of the convention and invites someone to "fix" it later.
• Do not invent a convention. If no comparable tool does the thing, that is worth knowing — say the decision is ours and justify it on its own terms. Asserting an unattributed "this is conventional" is folklore (ref-skill-effectiveness Anti-patterns checklist).

What is in scope

Noun and verb naming, flag naming and short forms, argument-versus-flag choices, default values, confirmation and interactivity behavior, output-format conventions, and exit-code semantics.

Where the decisions live

This skill holds the rule. The decisions and their rationale live in docs/design/CLI_TOOL_WRAPPING.md — that is the document to read for what was already decided and why, and the document to extend when a new decision is made.

Canonical citations already in the codebase:

• Resource-first noun-verb tree (docs/design/CLI_TOOL_WRAPPING.md) — follows kubectl, docker, gh, aws, gcloud, all of which put the resource before the action. Type-first (community … / enterprise …) was considered and rejected; the rejection is recorded with its reason.
• Code rides flags, not a noun (docs/design/CLI_TOOL_WRAPPING.md) — follows kubectl apply -f, which takes a file without introducing a file noun.
• Destructive confirmation is opt-in (ref-cli-tool-wrapping Destructive verbs with a defaultable target) — follows kubectl delete, which prompts only when --interactive is passed; the default is no prompt.

Verifying a citation

Check the tool's own documentation or source rather than recalling from memory — flag names and defaults change between releases, and a half-remembered flag is exactly the uncheckable citation this rule exists to prevent. Record what you verified against, so a later reader knows the claim was checked and not assumed.