Codex review: keeping this open for maintainer follow-up; there is still a little grit to resolve. _Reviewed August 27, 2026, 8:02 PM ET / August 28, 2026, 00:02 UTC._

Codex review: keeping this open for maintainer follow-up; there is still a little grit to resolve. _Reviewed August 27, 2026, 8:02 PM ET / August 28, 2026, 00:02 UTC._

**Summary**
Keep open for maintainer product direction. Current main groups root help visually and provides a limited `skill` publishing group, but the requested consolidation of install/discovery/management commands is not implemented; as a collaborator-authored public CLI contract decision, it should not be auto-closed.

Reproducibility: not applicable. This issue requests a new public CLI hierarchy rather than reporting a failing current behavior.

**Ways to help us reproduce this**
- Add a screenshot or short recording showing the behavior.
- Add expected vs actual behavior.
- Share version, platform, channel/provider, and relevant config details.

**Maintainer decision needed**
| Question | Recommendation |
|---|---|
| Should ClawHub add a consolidated skills command family while retaining the documented root skill commands as compatibility aliases, and which operations belong in that group? | **Add grouped commands with compatibility aliases:** Expose the selected skill operations under a consistent skills group while retaining existing root entry points and documenting their compatibility status. |

Why: The request changes a public, scriptable CLI contract; current documentation expressly preserves some root names for compatibility, so a mechanical refactor cannot safely choose the migration policy.

**Next step**
A maintainer must select the public command hierarchy and compatibility guarantee before an implementation can be safely scoped.

Review details

Best possible solution:

Define one coherent skill command family—preferably with nested commands and retained root aliases—then update help, CLI documentation, and artifact tests as one compatibility-preserving change.

Do we have a high-confidence way to reproduce the issue?

Not applicable: this issue requests a new public CLI hierarchy rather than reporting a failing current behavior.

Is this the best way to solve the issue?

Unclear: nested commands with retained aliases are the lowest-risk technical shape, but maintainers must first choose the permanent hierarchy and compatibility policy.

AGENTS.md: found and applied where relevant.

Remaining risk / open question:

- Changing or removing documented root commands can break existing shell scripts and CI unless compatibility aliases and upgrade behavior are explicitly chosen.

Codex review notes: model internal, reasoning high; reviewed against [f2fdea416fcb](https://github.com/openclaw/clawhub/commit/f2fdea416fcb2da1bfd634dd48e20d643461871e).

Label changes

Label justifications:

- `P3`: This is a command-organization proposal without evidence of broken established behavior or an urgent workflow failure.
- `impact:ux-friction`: The current split command surface can make skill operations less discoverable, but users can still perform those operations.

Evidence reviewed

What I checked:

- **Current command registration:** Current main registers search, install, update, uninstall, list, pin, unpin, explore, and inspect directly on the root program; it does not expose them as subcommands of the skill group. ([`packages/clawhub/src/cli.ts:281`](https://github.com/openclaw/clawhub/blob/f2fdea416fcb/packages/clawhub/src/cli.ts#L281), [f2fdea416fcb](https://github.com/openclaw/clawhub/commit/f2fdea416fcb))
- **Existing partial grouping:** The current singular skill group contains publishing and ownership-related commands, while root help labels separate commands into Skills and Publishing categories; this is presentation grouping, not the requested command consolidation. ([`packages/clawhub/src/cli.ts:493`](https://github.com/openclaw/clawhub/blob/f2fdea416fcb/packages/clawhub/src/cli.ts#L493), [f2fdea416fcb](https://github.com/openclaw/clawhub/commit/f2fdea416fcb))
- **Documented compatibility contract:** The CLI reference explicitly keeps `star` and `unstar` as root command names for compatibility and documents `publish` as a legacy alias, so moving commands can affect existing scripts. ([`docs/cli.md:99`](https://github.com/openclaw/clawhub/blob/f2fdea416fcb/docs/cli.md#L99), [f2fdea416fcb](https://github.com/openclaw/clawhub/commit/f2fdea416fcb))
- **Published artifact coverage:** Artifact tests verify grouped help output and `clawhub skill` help, but do not establish nested equivalents for the existing root install/discovery commands. ([`packages/clawhub/test-artifact/cli.artifact.test.ts:482`](https://github.com/openclaw/clawhub/blob/f2fdea416fcb/packages/clawhub/test-artifact/cli.artifact.test.ts#L482), [f2fdea416fcb](https://github.com/openclaw/clawhub/commit/f2fdea416fcb))
- **Current CLI provenance:** Available blame attributes the current command registrations and skill group to the shallow-history boundary commit by Yiğit ERDOĞAN; the checkout does not provide earlier path history for a stronger feature-owner trail. ([`packages/clawhub/src/cli.ts:281`](https://github.com/openclaw/clawhub/blob/8b31a7e6e1a5/packages/clawhub/src/cli.ts#L281), [8b31a7e6e1a5](https://github.com/openclaw/clawhub/commit/8b31a7e6e1a5))
- **Vision fit:** VISION.md says skills and plugins remain important building blocks that ClawHub should help users and publishers find, release, inspect, and maintain; it does not select a CLI hierarchy. ([`VISION.md:34`](https://github.com/openclaw/clawhub/blob/f2fdea416fcb/VISION.md#L34), [f2fdea416fcb](https://github.com/openclaw/clawhub/commit/f2fdea416fcb))

Likely related people:

- **Yiğit ERDOĞAN:** Available blame attributes the current root skill command registrations and the existing `skill` group to this commit, although the checkout's shallow history prevents a fuller ownership trail. (role: current CLI source author in available history; confidence: medium; commits: [8b31a7e6e1a5](https://github.com/openclaw/clawhub/commit/8b31a7e6e1a5bad837af7af2e9de3ae6d7b50605); files: `packages/clawhub/src/cli.ts`)

How this review workflow works

- ClawSweeper keeps one durable marker-backed review comment per issue or PR.
- Re-runs edit this comment so the latest verdict, findings, and automation markers stay together instead of adding duplicate bot comments.
- A fresh review can be triggered by eligible `@clawsweeper re-review` comments, exact-item GitHub events, scheduled/background review runs, or manual workflow dispatch.
- PR/issue authors and users with repository write access can comment `@clawsweeper re-review` or `@clawsweeper re-run` on an open PR or issue to request a fresh review only.
- Maintainers can also comment `@clawsweeper review` to request a fresh review only.
- Fresh-review commands do not start repair, autofix, rebase, CI repair, or automerge.
- Maintainer-only repair and merge flows require explicit commands such as `@clawsweeper autofix`, `@clawsweeper automerge`, `@clawsweeper fix ci`, or `@clawsweeper address review`.
- Maintainers can comment `@clawsweeper explain` to ask for more context, or `@clawsweeper stop` to stop active automation.

_Originally posted by @clawsweeper[bot] in https://github.com/openclaw/clawhub/issues/2317#issuecomment-4491398079_