OpenGIS 技能插件开发与使用：在 DeepSeek Harness 里按需加载 GIS 知识 – 我才是银古

1. The form of OpenGIS knowledge: a long link

OpenGIS here refers to the GIS technology stack with open source tools as the backbone, rather than a single standard or product. It contains not a tool but a long link from data to map. A typical open source GIS workflow spans these stages:

stage	Represents tools/libraries	Typical tasks
Data I/O and format conversion	GDAL/OGR、PDAL	Shapefile ↔ GeoJSON, raster clipping, point cloud conversion
Spatial analysis and geometric operations	GRASS GIS、JTS、NetTopologySuite、Shapely、GeoPandas	Buffer, overlay, spatial relationship, projection transformation
coordinate reference system	PROJ	EPSG query, datum transformation, reprojection
spatial database	PostGIS	Spatial index, spatial SQL, raster
Service release	GeoServer、MapServer、QGIS Server	WMS/WFS/WMTS/OGC API
Web visualization	CesiumJS、OpenLayers、Leaflet、Mapbox GL JS、deck.gl	2D/3D maps, vector tiles, large-scale point rendering
Desktop/server development	GeoTools、Mapsui、SharpMap、PyQGIS、qgis_process	Secondary development, batch processing, desktop map

Each piece deserves a manual. For an Agent, the correct form is not to merge all manuals into one, but to:

A tool (or a set of strongly related tools) and a skill：gdal、geoserver、postgis、openlayers……
An indexing skill connects the entire process(For example opengis-all): Tell the model how to arrange the stages and which skill to load at each step;
Skill text + reference materials: The main text is responsible for how to choose, how to use, and where the pitfalls are.reference/*.md Responsible for command quick check, API list, parameter details;
Use relative links between skills：../geoserver/SKILL.md、reference/vector-tools.mdconnect the knowledge points into a picture.

There are three constraints behind this form:

Catalogs are cheaper: The model only relies on name + description routing, and the description must be written as When to use me;
Text as needed: A GIS task usually involves only two or three tools, and it is not necessary to put the details of the entire link into context;
References must be resolvable: GIS knowledge is networked (GDAL will mention PROJ, GeoServer will mention PostGIS), and relative links + resource roots allow cross-skill jumps to be established.

This is why it is suitable to be made into a DSH plug-in: the plug-in only provides knowledge directory and on-demand loading, without registering tools or grabbing context; the tool chain itself is still executed by the model through common tools such as bash and file systems.

2. DSH’s three-layer model: profile, bundle, plug-in

DSH starts profile. profile is located at $DSH_HOME/profiles/itself an npm project:package.json Record dependencies and ordering dsh.profile.bundlessame level cordis.patch.yml Save user’s own configuration overrides.

On startup, the configuration tree is stacked in the following order:

dsh.profile.bundles The patch layer of each bundle in the list (in order of the list);
profile own cordis.patch.yml；
$DSH_HOME/cordis.patch.yml(home level);
Startup parameters --patch Specified overlay.

in bundle is an “installable patch layer”: an npm package passes package.json of dsh.bundle.patch Declare one or more patch files. The patch file is a top-level YAML array,insert Appends plugin lines to the root or specified group; without insert of items id Overwrite fields of existing rows (e.g. disabled、config），config It’s an overall replacement rather than a deep merge. Unknown id will warn and skip.

- insert:
    - id: gis-skills
      name: '@your-scope/opengis-skill-pack'

In the plug-in line (entry),id is a stable row identifier,name Is the module to be loaded, which can be a package identifier, absolute path or file URL; relative paths are resolved according to the directory where the patch file is located.config Pass the configuration to the plugin,disabled for deactivation.

plug-inis the Cordis module loaded by line: export nameoptional inject and apply(ctx)。inject Declare dependent services, and Cordis will wait for these services to be ready before executing them. apply；apply Things registered in it (services, listeners, tools, skill providers) are owned by the calling fiber, and will be automatically cleaned when the plug-in is uninstalled. The startup strategy of DSH is: only alert and continue if optional rows fail to load, and terminate startup only if required rows fail. This has direct implications for plugin authors:A skill plug-in failure usually does not bring down the entire host, but its skills will be silently absent.so the error message must be sufficiently diagnosable.

There are usually two types of relationships between bundles and plug-ins:

Same package concurrently: The patch of the bundle inserts itself into the package main The entrance is the plug-in implementation. Suitable for projects where “the package itself is the capability”.
Pure patch vector:bundle is only responsible for wiring, and patch inserts another dependent package. DSH’s official badge skill bundle is in this form: its own entrance is only export {}the patch line points to another package that provides the skill.

The former is simple, while the latter allows one capability package to be reused by multiple combinations. Which one to choose depends on whether you want the “installation unit” and “implementation unit” to be consistent.

In terms of compatibility, bundles or plug-ins are engines.dsh The DSH version range declared in will be withinBefore installationandOn startupCheck; no engines.dsh return for inspection peerDependencies DSH package scope in . Unsatisfied bundles will be skipped and diagnostics will be recorded; when an exception is really needed, the profile’s compatibility.json It is possible to grant exemptions by “exact package version + exact runtime version”, but this is an explicit confirmation of risk and should not become the norm.

3. Minimal OpenGIS skill plug-in: package list and bundle wiring

The minimum directory structure of an OpenGIS skills plug-in (assets are divided into directories by skills, and each skill can bring its own reference materials):

opengis-skill-pack/
├─ package.json
├─ cordis.patch.yml
├─ lib/index.js
├─ assets/gdal/SKILL.md
├─ assets/gdal/reference/vector-tools.md
├─ assets/geoserver/SKILL.md
├─ assets/openlayers/SKILL.md
├─ locale/en.json
├─ locale/zh.json
└─ icon.svg

package.json The key fields are as follows:

{
  "name": "@your-scope/opengis-skill-pack",
  "version": "0.1.0",
  "type": "module",
  "main": "lib/index.js",
  "exports": {
    ".": "./lib/index.js",
    "./cordis.patch.yml": "./cordis.patch.yml",
    "./locale/*.json": "./locale/*.json",
    "./icon": "./icon.svg",
    "./package.json": "./package.json"
  },
  "icon": "./icon.svg",
  "engines": {
    "dsh": ">=0.2.0 <0.3.0",
    "node": ">=22"
  },
  "dsh": {
    "manifestVersion": 1,
    "bundle": { "patch": "./cordis.patch.yml" }
  },
  "files": [
    "lib",
    "assets",
    "cordis.patch.yml",
    "locale/*.json",
    "icon.svg",
    "README.md"
  ]
}

Explained item by item:

type + main: The plug-in is an ESM module, and the entrance is exported. name/inject/apply。
exports: In addition to the main entrance, patches, locales, and icons must also be parsed; DSH will follow Node exports when reading plug-in display information.
engines.dsh: Declares the compatible DSH version range;engines.node Constrain the development/runtime environment. If the plug-in imports the host package, the corresponding package should also be written into peerDependencies。
dsh.bundle.patch: Declares the patch file of the bundle, which can be a string or a list of files to be applied in order.
dsh.manifestVersion: Optional manifest format version, currently 1; If not declared, the relevant verification will be treated as undeclared.
files:npm releases whitelist. Only the files that are really needed for runtime are placed, and the development scripts and test directories are not included in the installation package.

cordis.patch.yml There is only one insert item:

- insert:
    - id: gis-skills
      name: '@your-scope/opengis-skill-pack'

locale/*.json Provide plug-in page display copy, the field is meta.title and meta.description；icon.svg It is the plug-in page icon. The two are not “icing on the cake”: without them, the plug-in only has the package name and default illustration on the plug-in page, and it is not easy to confirm which package is installed when troubleshooting.

{
  "meta": {
    "title": "OpenGIS Skills",
    "description": "An OpenGIS knowledge pack loaded on demand."
  }
}

Finally, there is the plug-in entry:

// lib/index.js
export const name = "opengis-skill-pack";
export const inject = ["skills"];

export function apply(ctx) {
  // 在这里注册技能提供方，下一节展开
  ctx.skills.registerProvider(() => provider);
}

inject: ["skills"] is the only hard dependency here. The default Web/Desktop profile has the skills registry and skill Tool; if you are running in a self-built profile, you need to confirm that there is @deepseek-ai/dsh-skill(registry) with @deepseek-ai/dsh-tool-skill(Directories & Tools). Without the registry, this line will always wait for service, and the skills will naturally not appear.

4. Registration skills: OpenGIS provider protocol and on-demand loading

DSH’s skill subsystem is layered:

@deepseek-ai/dsh-skill Provides a registry, merges skills from multiple sources into one directory, and is responsible for duplicate name determination, verification and on-demand loading;
@deepseek-ai/dsh-skill-filesystem is a built-in provider, discovered from the project/user directory SKILL.md；
@deepseek-ai/dsh-tool-skill It is the consumer, rendering the directory to the model and providing skill Tools and users /name call.

Our plug-ins are “another provider”. The provider has only two actions:

list() Return directory item (candidate): name, description, calling strategy, source, rank, resource root directory and other metadata;
get(candidate, { signal }) Return the loading result (definition): text and resource root directory.

import { readFile } from "node:fs/promises";
import { fileURLToPath } from "node:url";
// readSkillCatalog() / parseSkillFile() 是示例包内的本地工具函数，负责扫描资产与解析 frontmatter

export const name = "opengis-skill-pack";
export const inject = ["skills"];

export function apply(ctx) {
  const root = fileURLToPath(new URL("../assets/", import.meta.url));
  const skills = readSkillCatalog(root);            // 只解析 frontmatter
  const byName = new Map(skills.map((s) => [s.name, s]));
  const candidates = skills.map((skill) => ({
    name: skill.name,
    description: skill.description,
    invocation: { modelInvocable: true, userInvocable: true },
    provider: "opengis",
    source: "opengis-skill-pack",
    rank: 600,
    path: skill.path,
    locator: skill.path,
    resourceBase: { kind: "directory", path: skill.directory.replaceAll("\\", "/") }
  }));

  ctx.skills.registerProvider(() => ({
    name: "opengis",
    list: () => Promise.resolve(candidates),
    async get(candidate, { signal }) {
      const skill = byName.get(candidate.name);
      if (skill === undefined) throw new Error("unknown skill: " + candidate.name);
      const raw = await readFile(skill.path, { encoding: "utf8", signal });
      const parsed = parseSkillFile(raw, skill.path);  // name + description + 正文
      if (parsed.name !== candidate.name) {
        throw new Error(skill.path + " 的 name 与目录项不一致");
      }
      return {
        name: parsed.name,
        description: parsed.description,
        content: parsed.content,
        resourceBase: candidate.resourceBase,
        provider: "opengis",
        source: "opengis-skill-pack"
      };
    }
  }));
}

There are several protocol constraints worth explaining behind this code.

1) The fields of candidate and definition are asymmetric.

candidate carries rank、source、provider、locatorused for host determination and source tracking; definition does not take rank——Once a skill is loaded, it will no longer participate in priority comparison. Candidate must not contain text, otherwise the directory will become a full text index, and on-demand loading will be meaningless. Writing these two items into the test is more reliable than writing them in comments.

2) Loading always reads the current file.

Registry does not cache definition every time get All require the current text from the provider. The advantage is: after changing the skill text, the next time you load it will be the new content, and there is no need to clear the cache. The cost is one I/O each time it is loaded, which can be ignored for dozens of KB of Markdown.signal to be transmitted transparently readFileotherwise the canceled request will still read the entire file.

3) Name drift needs to fail explicitly.

The file may have been modified between discovery and loading. if get The resolved name is inconsistent with the candidate, and an error must be thrown; the host will therefore invalidate the directory cache and rediscover it, instead of handing the incorrectly named content to the model.

4) Rank and duplicate name ruling.

The registry determines duplicate names within the same scope layer in ascending order of rank, provider registration order, and provider internal order; closer layers will obscure farther layers. The roots of the built-in file system providers are sorted 100–500, and the built-in skills included in the package are 600. A packaged OpenGIS knowledge base usually uses 600: the skill with the same name (lower rank) in the user project will cover it first, which is in line with the intuition of “local coverage built-in”. If you want your skills to take priority, you need a lower rank, but be aware that this will change the outcome of the host directory.

5) Call the policy to decide who can see it.

modelInvocable Control whether it enters the model directory and whether it can pass skill Tool loading;userInvocable Control whether users can use /name call. Both can be combined independently. Not all skills are suitable for exposure to the model – a process that is only manually triggered by the user can be set to modelInvocable: false。

6) The directory only has a name and description.

What the model sees is persistent Directory, each skill only has a name and a standardized description. The description is truncated to 500 characters by default (can be configured by the consumer);whenToUsesources, and providers will not appear in the directory. This directly determines that the plug-in author should put all routing information into the description: if it is written vaguely, the skill will not be selected. At the same time, there is no upper limit on the size of the loaded text, and the resources are only “guidelines” rather than attachments – the text must clearly tell the model “when to read which reference file” instead of assuming that the tool will automatically expand it.

GIS skills are especially important for description quality:gdal The description should not say “GDAL is a geospatial data processing library”, but should say “Use when converting, reprojecting, mosaicking or analyzing raster/vector data via CLI”;gdal(command line),gdal-api(Programming interface),qgis-process(QGIS Batch Processing) If the descriptions of the three skills all read “processing GIS data”, the models would be indistinguishable. The description is of a routing protocol, not an introduction.

7) Failure of the provider will not cause the host to collapse, but will cause the skills to be absent.

The registry isolates provider discovery failures: failed providers are skipped, and consumers try to keep the last available directory. In turn, malformed candidates will quickly fail the validation phase. So the provider has to do two things:apply Complete asset verification (bad assets will fail early),list Only return candidates in memory (fast); leave disk reading and parsing to get。

8) Directory invalidation is explicit.

The registry has no TTL. The supplier factory can get it invalidate()actively invalidate the directory when assets change; static package assets are usually not needed, just reload the plug-in or open a new session. This is why “reloading and opening a new session after upgrading the plug-in” is not a redundant step.

cost account

This OpenGIS skills package has more than 30 skills and more than 500,000 characters of Markdown. If you only put name + description into the directory, it will take about 8,000 characters and 2,000 tokens; the text will be left until it is hit and then loaded. Catalogs persist in context, so description length is a hard cost: the more skills and longer descriptions, you pay for the catalog every round. This is why the first design goal of the OpenGIS knowledge-based plug-in is not “to write more comprehensively”, but “to make indexing more cheap”.

5. Use: Installation, activation and one GIS task

Install

Sidebar for Web/Desktopplug-inThe page is the main entrance.add pluginFour types of specs are accepted:

npm package name (can have version, label or alias);
Git warehouse address;
tarball；
Local absolute path.

Before installation, the host will first parse the spec (the package name is queried in the registry, and the local path is read package.json), confirm whether it is a package, whether there is a bundle patch, and check the DSH version compatibility before pnpm is actually executed; no dsh.bundle.patch The normal dependency will be rejected because it is not a plugin. The installation action itself is to execute pnpm in the profile directory; when the build script is blocked by pnpm, the page will ask for separate approval. Successful installation does not mean successful activation. The page will give “Enable now” after the installation is completed, or it will remain installed but closed.

The CLI path is the same set of operations:

dsh plugin --profile web add @your-scope/opengis-skill-pack

It forwards the parameters to pnpm in the profile directory.desktop profile is exclusive to Electron applications, and the CLI will reject plugins that manage it; the desktop has a built-in command runtime to do the same thing.

When developing locally, directly putlocal absolute pathIt is most convenient to add the profile: it references the source code directory, rebuilds the code after modification and takes effect according to the reloading strategy, and does not need to be released every time. For formal distribution, use the npm package and version number.

Enable and take effect

The bundle switch in the plug-in page changes the order of profiles. dsh.profile.bundles List: Closing it only deselects it and does not uninstall dependencies; reopening it will append it to the end of the list and may change the layer priority. The switches of a single plug-in line are written to the profile cordis.patch.yml of disabled Overwriting does not tamper with the bundle’s own patches.

The way it takes effect depends on the profile:

enable dsh-hmr profile (which is the default for shipped web templates) will reassemble the configuration tree and reload affected plugins;
Profiles without HMR need to restart the process;
Skill catalogs are assembled at session step boundaries. If there is no watcher, it will not be called. invalidate() static provider ofNew sessionIt is the most reliable refresh method; after upgrading the package, you should also reload and open a new session.

within session

After enabling and opening a new session, the model will receive a persistent directory before the first request ( + ), listing the name and truncated description of each skill. after:

For models skill Tools, load skills with precise names; users can also enter directly in the input box /nameinject the same instruction into the current step;
The loading result is a paragraph including resource guides and . When the resource root is a directory, the model will see “Base directory for this skill: “, and are told that relative paths are to be resolved based on it;
The text is entered into the history as tool results, and subsequent steps will continue to be carried until compression; modification of the text will not overwrite the results that have already been generated;
If the name is invalid, the skill does not exist or is not available for model invocation, the tool will return an explicit error (invalid skill name / unknown or no longer available / not available for model invocation).

So there are actually only three steps to “using” the plug-in: install, enable, and open a new session; the rest is the work of the model and directory protocol.

A GIS task

User input: put data/roads.shp Convert to GeoJSON, and existing/pipes.shp Do an intersection check, publish it to WMS, and then superimpose the base image on the web page.

There are usually only a few relevant entries in the directory:gdal(Format conversion and command line),jts or postgis(spatial relationship),geoserver(service release),openlayers(Web page overlay). Models select them as described and use skill load:

load gdalget ogr2ogr Description of commands and parameters;
load jts or postgismake intersection judgment based on the spatial predicate examples in the text;
load geoserverpublish layer and style according to the text;
load openlayersget the access writing method of WMS layers and basemaps.

in the text ../geoserver/SKILL.md and reference/vector-tools.md They are all parsed relative to the Base directory of the loaded results; read the reference material if you need details. Throughout this process, the text of the remaining twenty-odd skills does not enter the context – this is the meaning of being distributed in whole packages and loaded by skills.

troubleshooting

Phenomenon	What to check first
The package cannot be seen on the plug-in page	Do you have the package? `dsh.bundle.patch`;Whether the installed bundle is a bundle; whether the spec is rejected by inspect
bundle is enabled but directory is not	Whether the plug-in line is really insert;provider `apply` Whether to report an error (optional line only reports an alarm if it fails); does profile have a skills registry and `skill` tool
Skill directory is empty	`inject: ["skills"]` Whether the service is ready; whether it is still in the old session; whether it has been skipped by the compatibility check
Tool reports invalid skill name	call `skill` The passed name is not legal kebab-case
A certain skill is not in the catalog	frontmatter `name` Illegal, inconsistent with the catalog entry, or asset parsing failed
The skill with the same name is not its own version	Rank and layer priority: skills in the project/user directory may override packaged skills
Relative resource not found	`resourceBase` Whether it is an absolute path and whether forward slashes are uniform; the resource file is a “guideline” and the model must read it by itself.
Changes to the text did not take effect	Whether the provider reloads/new session; directory digest does not read the text, the results of the old tool will not change
After installation, start the vacancy reporting service	`inject` The declared service does not exist in the profile; entry will wait or fail.

There are two direct ways to debug the combined configuration:dsh --dump-config Print the final plugin tree,dsh --dump-config-schema Print the configuration schema of each plug-in. The plug-in page and host log will give the reasons for bundle skipping, compatibility rejection, and apply failure.

6. Development packages: verification, testing and release

Although the OpenGIS skill plug-in is a “knowledge package”, it must be released and checked. It is recommended to cover at least:

Package manifest verification：dsh.bundle.patch Point to the real file;exports Each target is parsable;engines The scope is legal;files Contains the assets required for operation, but does not include development scripts and test directories.
bundle patch structure verification: Check line by line whether there is an enabled insert line pointing to this package. Don’t use “string contains” – commented out lines will also hit.
Display metadata verification: locale file name is a legal language id,meta.title/description Non-empty; the icon exists, the size is within the limit, and the content is like SVG.
Skill asset verification: each /SKILL.md It can be parsed, the name is unique and kebab-case; all relative links can be parsed and do not cross the boundary; the text file has no cross-platform pollution such as BOM/CR.
GIS content verification: Command examples and parameters cannot be automatically executed reliably. At least code block syntax checks, command spelling checks and version markings must be performed; cross-skill references and reference files must all be parsable.
Skill Catalog Test: Do not start DSH, use a minimal ctx Stub registers the provider, asserts directory fields, load fields, cancels signals, unknown skill errors, directory items without text, and definition without rank.

let provider;
const ctx = {
  skills: {
    registerProvider(create) {
      provider = create({ signal: new AbortController().signal, invalidate() {} });
    }
  }
};
apply(ctx);

const candidates = await provider.list({ signal: new AbortController().signal });
assert.equal(candidates.length, skills.length);
assert.equal(Object.hasOwn(candidates[0], "content"), false);

Further up is the release of access control and CI:npm pack --dry-run Confirm the files actually entered into the tarball; run the same set of verification and tests on both Linux and Windows platforms (issues such as path delimiters, CRLF, and BOM are only exposed on the other platform); CI actions are fixed to submit SHA to avoid the build chain itself becoming a gap in the supply chain. DSH version compatibility recommendations are made into a matrix:engines.dsh Declare that you have verified that the CI covers at least boundary versions.

7. Knowledge Snapshot: Make OpenGIS knowledge available offline and verifiable

A common choice for OpenGIS skill plug-ins is: pull it from the upstream at runtime, or distribute the snapshot with the package. The reasons for distributing with a package are practical: no network, Git, or authentication is required to run; installation results are reproducible; the knowledge version is tied to the package version; and upgrades are an explicit action. The price is that the knowledge will not be automatically up to date and a synchronization pipeline needs to be maintained.

Synchronization is not cp -r：

Bytes can be reproduced: The checkout of the same commit may be CRLF on Windows and LF on Linux. The text is unified and standardized into LF (the binary containing NUL is retained as it is), the verification is issued and then the CR byte in the text is rejected in reverse.
proven source: Manifest records upstream commits, but only accepts input if “the source directory itself is the Git checkout root”. Otherwise, a copy nested in another warehouse will record the outer warehouse HEAD as the upstream, and all subsequent verifications based on it will “correctly verify a wrong premise”.
Completeness Checklist: Each file has a SHA-256, and the key is the POSIX path relative to the asset root; plus the schema version, hash algorithm, skill list, and commit. In this way, release verification does not rely on upstream checkout, and can also detect that files have been manually modified, missing, or entrained.
Documents are generated from data: Information such as skill quantity and skill table are generated from assets, and HTML comment tags are used to define the generation area; the validator compares the generated results to avoid “documents and assets have different stories”.

The list prevents hand slipping and drifting, not malicious tampering – it cannot detect when the assets and the list are modified at the same time; to upgrade to anti-tampering, a signature or an external trusted source is required. In addition, when redistributing upstream knowledge with the package, the license and signature must be recorded, and LICENSE/NOTICE must be carried with the package; “reproducibility” must ultimately prove not only the bytes, but also the right to redistribute.

8. List of pitfalls

Phenomenon	root cause	line of defense
The plug-in page cannot be seen	lack `dsh.bundle.patch`or pretend to be a common dependency	Manifest verification + inspect
The skill directory is empty after enabling it	Provider apply failure is treated as an optional row warning	apply period asset verification, error path, startup log
The description in the directory is truncated	The default limit for consumers is 500 characters.	Keep descriptions short and put details in the main text
Front desk can `/name`the model cannot be seen	`modelInvocable: false`	Explicitly call strategies and test by combination
The skill with the same name is overwritten	rank / layer priority	Explicitly select rank and test the scenario with the same name
Resource links are broken on Windows	resourceBase with backslash	Unify forward slash + test assertion
Modified text does not take effect	definition is not cached but old results are still there; static provider has no watcher	Reload/new session; content changes do not change directory digest
After upgrading, the skills are still the same	Packages are static file snapshots	Reload + new session
Installation refused	`engines.dsh` Incompatible; build script not approved	Declare compatibility scope; follow prompts to approve scripts or authorize exemptions
Loading report unknown	Inconsistent name/disabled/provider skipped	Verify name and check plug-in logs
Skills are cut too finely	One command line tool, one skill, directory expansion	Segment by tool/task link, and use index skills to string processes
The description is like an encyclopedia, but the model is not selected.	Just write what it is, not when to use it	Use Use when… to write trigger conditions and task boundaries
Cross-skill reference broken link	Skill rename/move,`../x/SKILL.md` Invalid	Link verification + testing before publishing

9. Boundaries and trade-offs

Knowledge-based plug-ins do not provide tools. It does not register tools, does not inject system prompt segments, does not write session state, and only contributes entries to the skills directory. In this way, it can be freely combined with tool plug-ins instead of preempting each other’s context.
Domain knowledge does not equal execution ability. The plug-in only answers how to do it and does not execute GDAL/GeoServer; the actual command execution, environment preparation and data access are still responsible for the general tools and user environment.
Zero internal host dependencies. Only Node built-in modules are used, and there is only one connection between the plug-in and the host. ctx.skills an interface. The price is that you can’t get it BUNDLED_SKILL_RANK Such constants and types need to be maintained by yourself (and locked with checksum testing); the benefit is that the area that needs to be adapted when the host is upgraded is very small.
List is fast, get is slow. apply When parsing assets into directories,list Only the memory array is returned; disk reading is left to get. If the number of skills reaches several thousand, additional indexing and invalidation strategies will be required.
No TTL and watcher. The static OpenGIS knowledge package is refreshed with reload/new session, which is simple and reliable; scenarios that require hot update should contact the provider. invalidate()or directly use dsh-skill-filesystem That kind of provider with a watcher.
Directory capabilities have boundaries. The model only sees the name and truncated description,whenToUse Will not appear; there is no upper size limit for skill text; resources will not be read automatically. These constraints determine that knowledge must be organized into “short descriptions + hierarchical reference documents”.

Conclusion

Handing over the long link of OpenGIS to Agent is superficially a prompt word project, but in essence it is software engineering: the bundle is responsible for wiring and starting and stopping, Cordis is responsible for the life cycle, the skills registry is responsible for cataloging and on-demand loading, the provider is responsible for assets and references, and verification and testing are responsible for ensuring that this knowledge will not be quietly broken during upgrades, cross-platforms, and multi-person collaboration. Only by keeping these five layers well can an OpenGIS skills package truly become a DSH plug-in that can be installed, enabled, troubleshooted, and upgraded.

Project address:

Source link