Skip to content

feat: add KindBundle capability for Plugin system (Phase 0) - #259

Open
liyangbing wants to merge 1 commit into
mainfrom
feature/plugin-bundle-phase0
Open

feat: add KindBundle capability for Plugin system (Phase 0)#259
liyangbing wants to merge 1 commit into
mainfrom
feature/plugin-bundle-phase0

Conversation

@liyangbing

@liyangbing liyangbing commented Aug 23, 2026

Copy link
Copy Markdown
Collaborator

What & why
Add KindBundle — a new capability kind that packages skills (and in later phases: server tools, client UI, hooks) as a single deployable plugin unit. This is Phase 0 of the Plugin platform architecture, enabling FDEs to install a skill-based plugin with one command and have it inject behavior into any bound Agent.

How
Bundle skills are stored inline in canonical_spec.bundle.skills[] at install time (CLI reads markdown files from disk, embeds content). At runtime, resolveBundleCapability extracts them as ResolvedSystemPrompt entries in append mode — same path as KindSystemPrompt, no new injection mechanism needed.

The install endpoint (POST .../capabilities/plugins/install) uses the existing ImportCapability store path. No new DB tables or migrations — bundle is just another value in the capability.type column.

Trade-offs:

Chose inline skill storage over filesystem references so the resolver stays stateless (no disk I/O at prompt time)
Renderer output for bundles is informational only (resolver reads canonical_spec directly) — matches the pattern used by KindSystemPrompt
Verification
go build ./... clean
go vet ./... clean
go test ./... — 73 packages pass (only pre-existing TestTruncate failure on main)
Manual smoke: install plugin via API → bind to Agent → new conversation shows customer-service persona (confirmed via server logs: system_prompt_count:1, bundle_name:@internal/customer-service-skin)
Notes for reviewers

fde-platform-architecture.md
(the full Plugin platform design doc) is deliberately excluded from this PR — will be submitted separately
Phase 1 (server tools via shared Node.js MCP process) and Phase 2 (client UI) are follow-ups; this PR only enables skill injection
The existing KindPlugin (Claude Code --plugin-dir zips) is unchanged; KindBundle is a separate concept

Introduce a new capability kind 'bundle' that packages skills (and in
later phases: server tools, client UI, hooks) as a single deployable
plugin unit. This is Phase 0 of the Plugin platform architecture.

Changes:
- canonical: add KindBundle constant, BundleSpec struct with inline
  skills, Validate/UnmarshalJSON branches, ErrInvalidBundle sentinel
- render: all 4 targets (ClaudeCode/OpenCode/Codex/Pi) support KindBundle
- agentdaemon: resolveBundleCapability extracts inline skills and injects
  them as append-mode system prompts
- store: normalizeCapabilityType and validateImportSpecPreCommit accept
  'bundle'
- dev routes: POST .../capabilities/plugins/install endpoint for CLI
- dev routes: isListedCapabilityType includes 'bundle' so bundles appear
  in workspace capability listings
- CLI: 'parsar plugin add/list/remove' subcommands that read a local
  plugin directory manifest, embed skill content, and call the server API
- frontend: add Plugin tab to capability type filter, CapabilityTypeBadge
  handles 'bundle' type
- examples: customer-service-skin demo plugin (skill-only, changes Agent
  persona to professional customer service style)

Verified end-to-end: install plugin via API -> bind to Agent -> new
conversation shows customer-service persona in responses (system prompt
injection confirmed in server logs).
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant