DSHGuide

Contents / Chapter 9

Chapter 9 — Creator Mode: From User to Extender

8 min read · 1,710 words · 12 sections

What You Will Learn

  • What Creator mode is and is not;
  • What it adds beyond Standard;
  • When to use it, and when not to;
  • A complete plugin-building loop;
  • How non-programmers can participate;
  • How to avoid breaking DSH.

9.1 What Creator Mode Is

Creator mode is an Agent Preset in DSH. Its internal id is cordis.[3]

It is not:

  • Another model;
  • Another runtime;
  • Another app;
  • "Standard but smarter."

It is:

A working mode that adds runtime inspection, plugin management, and plugin/Preset authoring guidance on top of the standard task tools.

It shares with Standard:

  • The same Agent loop;
  • The same model;
  • The same sandbox and permission system;
  • Most task tools.

Only the composition differs.

9.2 What It Adds

Usually three groups.

1. Runtime inspection

It can inspect the real, current:

  • Service methods;
  • Config schemas;
  • Tool schemas;
  • Skill list;
  • UI slots and theme tokens.

This removes guessing: you do not have to infer APIs from source code.

2. Plugin management

It can:

  • List installed Bundles;
  • Install, enable, disable, and remove;
  • Change the profile's plugin selection;
  • Read installation results and warnings.

These changes persist in the profile, affect all Sessions, and survive restarts.

3. Authoring guidance

Creator mounts authoring Skills that explain:

  • How to write a Cordis plugin;
  • How to write a Bundle patch;
  • How to create or override a Preset;
  • How to verify that the plugin actually loaded.

It provides templates and references on demand.

9.3 When to Use It

Use it for:

  • Adding a tool to DSH;
  • Adding a UI panel or button;
  • Building a custom mode;
  • Debugging why a plugin did not load;
  • Packaging a workflow as a plugin.

Do not use it for:

  • Everyday coding;
  • Routine file work;
  • Just asking for research;
  • Anything that does not extend DSH.

Why not? The extra tools and Skills consume context, and plugin installation is a high-risk operation.

9.4 Security Boundary: A High-Trust Mode

Creator can do things Standard cannot because:

  • Installing a plugin executes code in the Host process;
  • Profile changes affect every Session;
  • Plugins may read files, access the network, and run commands;
  • That code runs outside the workspace sandbox.

Therefore:

  • Plugin management usually requires full access or per-call approval;
  • Do not give an untrusted plugin full access;
  • Test in a scratch profile/workspace first;
  • Back up important configuration;
  • Make sure you can disable or roll back.

Creator mode is not a "safe mode." It is a high-trust extension mode.

9.5 A Complete "Build a Plugin" Loop

This flow does not require you to write code, but it does require you to describe the goal and verify the result.

Step 1: Describe the capability

Do not start with "write me a plugin." Start with:

I want to add this capability to DSH:
- What it does;
- Where it is used (chat / button / panel / tool);
- Inputs;
- Outputs;
- How to verify success;
- What it should not do.

Step 2: Ask it to inspect first

Do not write code yet.
Use runtime inspection to determine:
1. Which layer this belongs to (Host plugin / Preset plugin / pure config);
2. The available Service / Slot / Tool APIs;
3. Whether a new Bundle is needed;
4. Whether a template exists.
List the conclusions and risks.

Step 3: Build the smallest version

Build a minimal working version.
No extra features, no variants.
Give me the file list, installation steps, and verification steps.

Step 4: Install and verify

Install it into the current profile.
After installation, tell me:
- The installation result (applied / warnings);
- Which tools, Skills, or UI were added;
- How to verify;
- How to uninstall.

Step 5: Fix and iterate

Fix only the observed problems. Do not keep adding features.

Step 6: Close out

Give me:
- Plugin location;
- Install/uninstall steps;
- What was verified;
- What was not verified;
- Known limitations.

9.6 How Non-Programmers Can Participate

You do not have to write the code, but you should:

  1. Describe the goal: user, scenario, inputs, outputs;
  2. Review the result: did it do more than asked? Are permissions too broad?
  3. Accept: run your scenario; give specific feedback.

Ask for:

Do not just tell me "done".
Give me:
- Which files changed;
- Which capabilities were added;
- How I can verify manually;
- How to roll back if it fails.

9.7 Case Study: Turning the GetNote CLI into a DSH Plugin

The previous sections described the method. This section walks through a real project: the GetNote Toolbox.

The direct motivation was simple: when we started, the official @getnote/dsh-plugin did not support DSH Desktop.[2] Desktop is the entry point most people use every day, so we needed a version that actually worked in a local Desktop profile.

This was not an attempt to replace the official plugin. It was meant to fill the Desktop gap. That is also why the project focuses on the Desktop local bundle, locale/icon display, CLI discovery, and visibility in Plugin Manager.

The goal was not to copy another plugin's tool list. It was to turn the local getnote CLI into a set of Host tools that an Agent can use reliably. The source is public:

https://github.com/leether/getnote-toolbox

The source is public, and the package is published on npm as @leether/getnote-toolbox.[1]

Install the npm bundle through DSH Plugin Manager, or link the source locally while developing.

Step 1: Audit capabilities before writing tools

Start with the CLI's --help, inputs and outputs, side effects, authentication, and version differences. Then decide which capabilities deserve to become tools:

  • High-frequency operations that need structured arguments or safety guards become Tools;
  • Low-frequency, complex, fast-changing, or judgement-heavy operations stay with the CLI or a Skill;
  • Reversible operations should exist in pairs, such as add and remove;
  • Never add a generic run_command or arbitrary HTTP passthrough.

The project ended up with 15 tools covering search, save, read, update, delete, tags, knowledge bases, and quotas. Fifteen was not the goal. Every tool had to answer a concrete question: which contract, guard, or normalization does it add?

Step 2: Turn "it runs" into a contract

The difficult part was not the spawn call. It was the details:

  • Treat 19-digit note IDs as strings so JSON numbers cannot silently lose precision;
  • Some older CLIs ignore limit, so the plugin truncates the parsed result itself;
  • Deleting a note requires an explicit confirm: true; tag deletion requires a tag ID;
  • Arguments go to spawn as an array, never through a shell;
  • Timeouts, output-size limits, and expired logins produce actionable errors;
  • A Config schema exposes binaryPath, timeoutMs, and related fields;
  • A bundled Skill tells the Agent when to use which tool.

Only at that point does the plugin stop being a command wrapper and become a usable interface for a model.

Step 3: Unit-test with a fake CLI, accept with the real one

The test suite does not touch a real account. A fake CLI covers ID precision, nested responses, the old-CLI -y fallback, tag re-reads, and knowledge-base add/remove across 28 tests.

Then run a read-only smoke test against the real CLI. Real output can contain note excerpts, so:

  • Never paste that output into an issue, chat, or commit;
  • Use synthetic IDs in tests;
  • For write tests, create a test note first and clean it up afterwards.

Step 4: Do the privacy and publication review before going public

This is the most important part of the case study. Working code is not the same as code that is safe to publish.

Before publication, we handled:

  • Eval reports: evals/results/ contained account-specific note IDs, titles, and comparisons; it must not enter the public repository;
  • Internal drafts: upstream issue/PR notes under contrib/ contained local paths and operating plans; they were excluded;
  • Git history: the old history used a personal email; the public repository starts a fresh history with a noreply author;
  • Package name: a local username scope was replaced with a public identity scope;
  • Environment details: lines such as "this machine is already linked to a profile" were removed;
  • Sensitive-data scan: check for keys, tokens, emails, absolute paths, .env files, long numeric IDs, and eval output;
  • File inventory: keep only reviewed source, tests, licenses, and public documentation.

The rule is simple:

Review first, publish second. Do not publish and delete afterwards.

Result and boundaries

The plugin is now a public source project with 15 tools and 28 tests, licensed under MIT. It also has clear boundaries:

  • It uses the same getnote_* tool names as the official @getnote/dsh-plugin, so the two cannot be installed together;
  • CLI version affects IDs, limit, and confirmation flags; pin binaryPath and verify the version;
  • The npx fallback downloads the latest CLI; use a pinned local binary if supply-chain risk matters;
  • It is not a universal GetNote plugin; many low-frequency capabilities still belong to the CLI or a domain Skill.

What is reusable here is not the number 15. It is the four-step loop: audit capabilities, design contracts, test with a fake CLI, and review privacy before publishing.

Further reading: the Cognition article “From CLI to DSH Plugin: A Decision Guide for Better Agent Work” is published at cognition.html.

9.8 Common Misconceptions

  • "Creator is an advanced Standard." No; it is an extension mode.
  • "Installing a plugin is just config." No; it may execute code.
  • "It works immediately." Not always; a reload or restart may be needed.
  • "A Preset can be a sandbox." No.
  • "Let the Agent edit profile files directly." No; use Plugin Manager.
  • "Build everything at once." Start minimal, then iterate.

Try It

  1. Create a Creator task;
  2. Do not install anything;
  3. Ask it to list the available runtime inspection capabilities;
  4. Ask: "If I want to add a read-only tool, which layer should it live in, and why?"
  5. Read the answer; do not execute.

Summary

  • Creator is the cordis Preset, not a model or runtime.
  • It adds runtime inspection, plugin management, and authoring guidance.
  • Use it to extend DSH, not for daily work.
  • Plugin code runs in the Host; have a trust and rollback plan.
  • Start minimal, verify, then iterate.
  • Real-world case: audit capabilities and contracts, review privacy, then publish.

References

  1. GetNote Toolbox repository
  2. Official GetNote DSH plugin
  3. DeepSeek Harness plugin development

All links are public sources; product behavior may change between versions.

↑