[RFC / Feature Proposal] Built-in Extension Guardrails and Native Meta-Skill for Safe Skill and Plugin Authoring

[NitishKashyapR]

As DeepSeek Harness (dsh) expands its plugin and skill ecosystem, both human developers and autonomous AI agents frequently install, modify, or author extensions. However, small, common configuration mistakes—such as listing a Cordis plugin in package.json's dsh.profile.bundles or declaring { required: true } on a tool's child schema—result in fatal runtime panics during the boot phase (dsh-app-boot), completely bricking the harness.

We propose:

1. Bundling a Native Meta-Skill (dsh-skill-and-plugin-authoring) so the model running inside DSH understands how to safely self-extend, write plugins, and add skills without crashing the bootloader.
2. Adding a Pre-flight Validation Command (dsh doctor / dsh plugin check) to detect and report schema and bundle misconfigurations before attempting to boot.

PROBLEM STATEMENT AND FAILURE MODES

When an LLM or user attempts to add a new tool or plugin to DSH, they repeatedly run into three silent pitfalls that cause bootloader crashes:

1. The Bundle vs. Plugin Ambiguity
   What happens: Developers or AI assistants add installed packages (such as @deepseek-ai/dsh-subagent-codex or custom tool plugins) to package.json under dsh.profile.bundles.
   Fatal Error:
   Error: dsh: profile bundle "@deepseek-ai/dsh-subagent-codex" declares no dsh.bundle in its package.json
   Root Cause: dsh.profile.bundles is strictly for layered overlay bundles declaring dsh.bundle.patch, whereas regular plugins belong exclusively in cordis.patch.yml.

2. Strict JSON Schema Rejection Panics
   What happens: Community plugins and LLM-generated tools often use informal schema conventions like { type: "string", required: true } or object additionalProperties.
   Fatal Error:
   JsonSchemaError: unsupported JSON schema: schema.properties.hits.required is not supported on type "array"...
   Root Cause: assertSupportedJsonSchema strictly requires required to only be an array on type: "object" (required: ["prop1"]). When violated, Cordis crashes with an unrecoverable AggregateError.

3. Duplicate Entry ID Conflicts
   What happens: When community overlays re-declare plugins already mounted by base bundles (such as dsh-context, workflow, goal), Cordis throws:
   TypeError: duplicate loader entry id:

PROPOSED SOLUTION: NATIVE META-SKILL AND LINTING ENGINE

To turn DSH into a truly self-extending, resilient runtime, we designed and tested a reference meta-skill that instructs the harness agent on safe extension practices.

Proposed Integration: dsh-skill-and-plugin-authoring (SKILL.md)

Skill Frontmatter:
name: dsh-skill-and-plugin-authoring
description: Strict safety protocols, boilerplate templates, and verification guidelines for authoring, installing, and configuring DSH Skills and Cordis Plugins without breaking the harness.
invocation:
modelInvocable: true
userInvocable: true

Core Rules Included in the Skill:

1. Skill vs. Plugin Decision Tree:

• Use a Skill (Zero Risk) for procedural workflows, prompt templates, and domain guidelines. Place in .dsh/skills//SKILL.md or ~/.dsh/skills//SKILL.md.
• Use a Plugin (Moderate Risk) only when introducing new executable tools on ctx.tools, subagent providers, or custom UI modules.

2. The Golden Rules of DSH Plugins:

• Never add non-bundle plugins to package.json bundles: Only packages with "dsh": { "bundle": { "patch": "..." } } belong in dsh.profile.bundles. All other plugins must be registered via cordis.patch.yml under - insert:.
• Strict Schema Constraints: required must ALWAYS be an array on the parent type: "object" node (required: ["field1"]). additionalProperties must be a boolean (true/false), not a schema object.
• No Duplicate IDs: Verify whether an entry ID is already provided by @deepseek-ai/dsh-base.

3. Mandatory Pre-Flight Verification:
   Always verify profile validity before starting the web server:

• dsh --profile --dump-config
• dsh --profile --help

PROPOSED CLI ENHANCEMENT: dsh doctor / dsh plugin check

In addition to the skill, adding an automated pre-flight checker in the CLI:

Command: dsh plugin check --profile web
Output:
[DSH Validator] Checking profile: web (~/.dsh/profiles/web)
[OK] Profile package.json bundles validated (no orphaned plugins).
[OK] cordis.patch.yml syntax and unique entry IDs verified.
[OK] All registered tool schemas conform to assertSupportedJsonSchema.
[OK] dsh --profile web --dump-config composed cleanly.
Status: SAFE TO BOOT

IMPACT AND WHY DEEPSEEK HARNESS SHOULD ADOPT THIS

1. Autonomous Self-Extension: With this meta-skill bundled out of the box, when a user asks DSH to "create a tool for searching Jira" or "install the wiki plugin", the model automatically consults the skill and produces crash-proof code and configuration.
2. Dramatically Lower Onboarding Friction: Eliminates the primary source of harness startup crashes for users experimenting with community plugins.
3. Zero Runtime Overhead: The skill is purely markdown instructions loaded on-demand by dsh-skill-filesystem, requiring zero extra dependencies or memory footprint.

REFERENCE IMPLEMENTATION

A fully functional reference of the skill and validation script has been tested on DSH 0.1.1-rc.2:

• Skill File: ~/.dsh/skills/dsh-skill-and-plugin-authoring/SKILL.md
• Pre-flight Validator: ~/.dsh/skills/dsh-skill-and-plugin-authoring/scripts/validate-dsh-extension.mjs

[Rehanguards]

Great RFC! When handling dynamic plugin/skill installations, evaluating capabilities before execution is critical. We found that pairing AST pattern checks with a deterministic pre-execution policy engine at the proxy layer prevents rogue tool calls without relying on LLM-level safety prompts. How are you planning to handle scope verification for unverified third-party skills?