KeenKind plugin development

Plugins provide local tools callable by the model. They run independently and exchange tool definitions, arguments, and structured results through the public plugin protocol.

Start with the built-in Keenkind Plugin Development Skill. It generates a manifest, Go entry point, and test examples for the current version.

Directory structure

xin.example.text-tools/
  keenkind.plugin.json
  bin/
    text-tools.exe

A minimal manifest:

{
  "schemaVersion": 1,
  "id": "xin.example.text-tools",
  "name": "Text Tools",
  "version": "1.0.0",
  "runtime": {
    "type": "stdio",
    "commands": {
      "windows": "bin/text-tools.exe",
      "darwin": "bin/text-tools"
    }
  },
  "permissions": [],
  "resources": {
    "skills": []
  }
}

Array fields must be arrays rather than null. Use a reverse-domain ID and keep it stable after release. Executables must be inside the plugin directory.

Define tools

Each tool needs:

• A unique, stable name.
• A user-facing title.
• A concise, clear purpose.
• A strict input schema.
• Structured success results.
• Readable errors indicating whether retrying is appropriate.

Show tool titles in the interface rather than host-generated routing names.

Use the Go SDK

The SDK connects to KeenKind, registers tools, receives calls, and returns results. Business logic should handle validated arguments and respect cancellation.

1. Register only tools permitted by the manifest.
2. Return a complete result for each call rather than only logging.
3. Report progress and support cancellation for long tasks.
4. Identify targets and impact before modifying files.
5. Release files, processes, and connections on exit.

Use package names and examples from the Keenkind Plugin Development Skill bundled with the current client to avoid outdated interfaces.

Install and debug

1. Build the appropriate Windows or macOS executable.
2. Place the complete directory in ~/.keenkind/<environment>/plugins.
3. Open Settings > Extensions > Plugins and refresh.
4. Check name, version, permissions, and tools.
5. Use Plugin debugging for diagnostics and logs.
6. Test read-only tools in Ask for approval mode before testing modifying tools.

Plugin debugging does not expose the app’s full developer tools.

Release checks

• Windows and macOS entry points exist and are executable.
• Manifest JSON is valid and array fields do not contain null in place of arrays.
• Tool names and input fields remain backward compatible.
• No keys, user data, or developer-machine absolute paths are included.
• Failures, cancellations, and repeated calls have defined outcomes.
• Requested permissions match actual behavior.