Idea: plugin-namespaced slash commands (/plugin:command)

[maskshell]

Problem

Slash-command names are one flat namespace: the grammar is ^[a-z][a-z0-9_-]*$ (see packages/interaction/commands). Two consequences for plugin-style capability bundles:

1. No structural ownership. Two plugins that both ship a deploy command collide with no domain qualifier available; who wins is decided by layer order / scoped shadowing, and neither author can prevent the collision by design.
2. No ecosystem parity. Claude Code plugins address their commands as /{plugin-id}:{command} (the colon is the structural separator; each plugin skill also gets a generated /plugin:skill command). Ports of such plugins to the DeepSeek Harness must flatten or kebab-mangle their names, losing both the addressing convention and the collision guard.

The current workaround is a kebab convention (/solidforge-arm-tools): unambiguous addressing is sacrificed (the prefix boundary is not mechanically parseable — is it solidforge + arm-tools or solidforge-arm + tools?), and it remains convention-only, so nothing stops a second plugin from registering /solidforge-arm-tools.

Proposed direction

1. Grammar (PR): allow one optional namespace: segment — [a-z][a-z0-9_-]*(?::[a-z][a-z0-9_-]*)? — in both the registration validation and parseCommand(). Patch + RFC: https://github.com/maskshell/solidforge-dsh/tree/main/docs/upstream (ready-to-apply; 58/58 tests green against 47f9438).
2. Ownership policy (follow-up RFC, this issue): make the namespace structural so the prefix actually prevents collisions — e.g. a registry-level prefix→owner claim where the first plugin registering a namespace: name claims the prefix, and a different package registering the same prefix fails loudly. Details open for discussion (claim attribution, prefix granularity, migration for existing flat names).
3. Explicitly out of scope: namespacing skill names (skill.list / /name injection layers) and subagent names — those are separate surfaces with their own grammars.

Why this matters

This proposal comes from a real port (SolidForge for Claude Code → DeepSeek Harness, https://github.com/maskshell/solidforge-dsh): the port's five skills, role agents, and commands all need domain-qualified addressing to behave like the upstream plugin. The grammar PR is the minimal enabling change; the ownership policy is what turns the prefix from a convention into a guarantee.

[maskshell]

@tianyicui

[maskshell]

Update (2026-08-14): the ecosystem fallback is SHIPPED and on npm

The plugin route described in this proposal is now fully built, live-verified, and published — no upstream change required:

• Package: @maskshell/solidforge (MIT; GitHub: maskshell/solidforge-dsh, topic dsh-plugin).
• What it does (mounted through a profile's user patch layer, sessions of ANY preset):
  • registers the five SolidForge skills into the HOST skill layer (/ menu + model catalog);
  • expands whitespace-bounded /solidforge:<name> colon tokens (full names or abbreviations) at the agent/pre-step boundary into the rendered <skill_content> — the same gesture boundary dsh-tool-skill uses for /name, byte-compatible markup;
  • optionally adds an additive solidforge:discipline system-prompt section (config: {persona: true}).
  • The same package mounted as a preset row registers /solidforge, /arm-tools, /solidforge-status commands.
• Live verification (real GUI, playwright): PTC-preset sessions execute colon gestures with deterministic injection; the discipline section answers the abbreviation map in one step; a solidforge-preset session resolves the preset-row commands.

Two loader contracts discovered along the way, which may be useful upstream signal for the extension surface:

1. inject is the service bridge for patch-layer plugins. A patch-layer insert entry whose plugin declares no inject runs in a context that sees NONE of the app's services (probed: systemPrompt/skills/commands/tools/subprocess/agents all undefined). Declaring inject: ['skills', 'systemPrompt'] makes those services visible and registration works. This was surprising and cost significant debugging; documenting it would help plugin authors.
2. The patch-layer context cannot see commands/tools/subprocess even with inject (they live in preset scopes), so commands/gates plugins must mount as preset rows instead. Consistent with the presets model, but not discoverable from the patch-layer docs.

The grammar proposal itself is unchanged and still stands: colon command names as a first-class grammar feature plus a prefix-ownership policy would let the same addressing work natively for any plugin. The ready-to-apply patch lives at docs/upstream/namespaced-command-names.patch in the repo (58/58 tests green against upstream 47f9438).

[maskshell]

Update 2 (2026-08-22): release complete — npm, GitHub Release, license corrected

• npm: @maskshell/solidforge@0.1.2 is live (latest), license Apache-2.0 with LICENSE + NOTICE shipped in the tarball. History: 0.1.0 shipped with a wrong MIT declaration (caught by human review); 0.1.1 rebuilt the packument after the new-scope first-publish lag; 0.1.2 fixed the license.
• GitHub Release: v0.1.2.
• Discipline follow-through: the wrong-license publish prompted a deterministic release gate now in the repo's CI (scripts/check-release-metadata.py: name/license/files/README/workflow-posture consistency) plus a frozen release checklist (docs/release-checklist.md) — the two-axis discipline applied to publishing itself.
• The loader-contract findings from the previous update are recorded in the repo (test/verification.md) as extension-surface feedback.

The grammar proposal remains open upstream: colon command names as a first-class grammar feature, patch at docs/upstream/namespaced-command-names.patch.

[maskshell]

Update 3 (2026-08-23): UI-decoration companion patch (colon token split)

Live testing exposed the presentation half of the same root cause: the user-message renderer (projectUserText in packages/client/ui-conversation/src/client/chat/MessageItem.tsx) scans plain tokens with /(^|\s)(\/[\w-]+|…)/gu — \w- excludes :, so a sent /solidforge:psv say hi renders as a /solidforge ref-chip plus stray :psv say hi text (visually split; the stored message and the host-side injection are unaffected — cosmetic, but confusing).

Patch: include : in the token class — /solidforge:psv becomes ONE chip; the existing trailing-punctuation strip already handles a terminal colon. One-line regex change + a unit test (one chip, remainder plain) at:
https://github.com/maskshell/solidforge-dsh/blob/main/docs/upstream/colon-token-decoration.patch

This pairs with the grammar proposal: grammar (host admission) + decoration (client presentation) are the two halves of first-class colon tokens.