dsh plugin naming: package, display name and entry id

A dsh plugin can carry four different names before anyone installs it, and only one of them is the identity users actually depend on. The package name anchors installation, the display name carries presentation, the Hub entry id points at a listing, and the command name is what people type every day. Getting that mapping right before release is far cheaper than repairing it afterward.

Why the dsh plugin package name is the only real identity

The package name is the one name you cannot quietly change, because every install command and dependency edge points at it.

A display name can be edited on a listing page in a minute, and a slug can often be redirected. The package name lives in lockfiles, CI scripts, container images and colleagues' shell history, so changing it means coordinating all of those places. That asymmetry is why the naming decision starts here rather than in a design document.

Scopes are not a separate naming system; they are part of the package name and they signal ownership. A personal author might publish under @name/plugin, while a team uses an organization scope so related plugins look like a family. A scope reduces collisions, but it does not create trust on its own; it only tells a reader who published the package.

The practical rule is to choose a functional word, add the scope, and stop. Two or three words that describe the capability age better than clever abbreviations, and lowercase hyphenated names survive every package manager and URL. If the name needs a paragraph of explanation, the plugin probably needs a clearer purpose.

A name also encodes a promise about scope. If the package says memory, users expect a general memory layer rather than a single-project cache, and the implementation has to meet that expectation. Naming after the first narrow use case tends to trap the plugin in it.

How a DeepSeek Harness plugin name maps to the entry id

The four names form a chain of derivation, and each link costs more to change than the one before it.

The table is less a hierarchy of importance than a record of where each name is consumed. The entry id is generated by the Hub at registration and should remain traceable to the package; if the two drift apart, a reader following a URL may land on a listing whose install command points somewhere else. That disconnect is invisible until someone tries to install the wrong thing.

Command names deserve separate attention because they are what people memorize. A plugin can have a beautiful display name and still frustrate users if the binary is an unguessable abbreviation. Pick a command that echoes the package's functional word, keep it stable, and state the full mapping in the listing description.

When the mapping is consistent, a user can move from search result to detail page to install command without guessing. When it is inconsistent, every step becomes a small experiment, and support questions begin with "which one is the real package". Consistency is cheap before release and expensive afterward.

Registration is the point where a package becomes an entry, and it is worth checking how the generated id relates to the package before publishing. Start from the DSH Plugin Hub entry and follow it back to the repository, then forward again to the install command. If either direction requires a jump the reader cannot make, the mapping needs work.

The DSH plugin display name is presentation, not proof

A display name is allowed to be friendly, but it should never be the only place where the package identity is visible.

Display names can include spaces, capitals and words that would be illegal in a package name. That freedom helps search and explains purpose in a list of similar plugins. It also means two plugins can share a display name while pointing at completely different packages, so the listing must keep the package name and repository close at hand.

A good display name tells a browsing user what the plugin does and roughly where it belongs. "Memory for long sessions" is more useful than "memx2", even when the package name stays short. The display name should not promise official backing or a compatibility level that the package does not have.

Localization belongs here too. Teams that publish several DSH plugins can translate display names per locale while the package name stays identical, which keeps installation stable across regions. If only the display name is translated, links and support notes still resolve to the same package.

Search behavior is the practical reason to care. A display name that repeats the functional word helps people find the plugin, while a poetic name depends on the description and tags to do that work. The name should support discovery without pretending to be a ranking strategy.

Where the dsh plugin slug still matters

The slug is the least authoritative name and the one most likely to break a link somebody saved.

A slug usually comes from the package name after the scope is dropped, which makes it readable but not necessarily unique. Two authors can publish different packages whose slugs collide, and the market has to disambiguate them in the URL. That ambiguity is why the slug should never be used as the installation identity.

Slugs matter most for documentation and bookmarks. An old tutorial that links to a slug will keep sending readers to whatever now occupies that address, even if the package behind it changed. When a rename is unavoidable, a redirect or a forwarding entry preserves more goodwill than a new announcement.

What renaming a DeepSeek Harness plugin really costs

A rename is a migration project disguised as a text edit, and the bill arrives in broken installs and stale documentation.

The first cost is compatibility, because old lockfiles keep asking for a package that may no longer exist. The second is documentation, since every tutorial, CI template and onboarding note that mentions the old command becomes wrong at the same moment. The third is trust, because users who hit an install error rarely read the changelog before assuming the project is dead.

A clean rename keeps the old path alive long enough for people to move. That means publishing a forwarding release, updating the human-facing surfaces, and giving the change a visible window instead of a silent cutover. The sequence below is the minimum that avoids leaving users stranded.

1. Keep the old package published as a migration release that points to the new name.
2. Update the display name, description and support notes before the switch.
3. Redirect the old slug or leave a forwarding entry where the Hub allows it.
4. Rewrite install commands in README files, CI templates and onboarding docs.
5. Announce a support window and the date the old package stops receiving fixes.
6. Verify that both commands resolve to a working version during the overlap.
7. Record the mapping in the changelog so future maintainers can trace the history.

The expensive part is rarely the publishing step; it is the long tail of references that nobody remembers. A rename that looks complete in the repository can still break a colleague's script six months later. Treat the old name as a supported interface until the announced date, then remove it deliberately.

A dsh plugin naming decision you can defend later

The test of a name is whether a stranger can install the right package, find its listing and read its command without asking you.

That test forces the decision away from taste and toward evidence. If the package name is unique, the display name is readable, the entry id resolves back to the package and the command appears in the docs, the mapping holds. If any of those steps requires an explanation, the name is doing less work than it should.

Names also accumulate history, and a mapping that was obvious to the original author may be opaque to the next maintainer. Writing the four names into the repository notes, along with the reason for the choice, costs almost nothing. It also makes a future rename a planned operation rather than an emergency.

A useful habit is to write the mapping down before the first release and review it at every major version. Packages rarely need new names, but descriptions and commands drift as features change. The review keeps the four surfaces aligned without forcing a disruptive rename.

The best naming decision is the boring one: stable package, readable display, traceable entry, memorable command. It will not win a design award, but it lets people install the plugin, cite it and script against it without a glossary. That is the whole point of separating identity from presentation.

Sources: your first plugin, DSH Plugin Hub plugin entry, npm @deepseek-ai/dsh.