Status: deferred from v0.8.0 plugin upgrade.
Plugin: continue (plugins/continue_plugin.go)
Capability cell: AGENTS, currently ----
Context
Continue's "custom agents" exist but in a config-shape, not a file-shape:
- Location:
~/.continue/agents/*.yaml (user-global) or .continue/agents/*.yaml (project)
- Format: full YAML config composing models + rules + tools + system prompt
- Reference: https://docs.continue.dev/reference
This is a non-trivial mismatch with the canonical model where model.Agent is markdown + frontmatter (mirrors Claude/Cursor/Gemini/Copilot). A real translator needs to:
- Synthesize a YAML config from the canonical Agent's markdown body, description, and frontmatter
- Decide how to bind models / rules / tools (defaults from project + frontmatter overrides)
- Handle the inverse direction in the importer
v0.8.0 left this at ---- because the translator is mid-sized and benefits from a thoughtful design pass rather than a fast port.
What to implement
- Design the canonical → Continue agent config mapping:
Agent.Description → Continue's description
Agent.Document.Body → Continue's prompt or instructions
- Frontmatter fields (model, temperature, etc.) → Continue's
models[] + defaultModel
Agent.Tools (wildcards or explicit) → Continue's tools[] config
- Emit
.continue/agents/<n>.yaml in plugins/continue_plugin.go's Plan().
- Update
Capabilities().Agents from SupportUnsupported → SupportDegraded (the translation loses some structure) or SupportNative if a clean mapping is found.
- Importer parity: extend
internal/importer/continue.go to read .continue/agents/*.yaml back into model.Agent. The reverse mapping should round-trip — at minimum body + description + name.
Acceptance criteria
prism capabilities shows continue AGENTS = degr. or native.
- A canonical agent projects to a working Continue agent config.
- Round-trip test: agent fixture survives init → compile → check.
Open design questions
- How to handle Continue-specific tooling (rules + models + MCP composition) when the canonical agent doesn't carry those?
- Should the YAML be lockfile-tracked, or treated as a user-editable file (like
.continue/permissions.yaml)?
Status: deferred from v0.8.0 plugin upgrade.
Plugin: continue (
plugins/continue_plugin.go)Capability cell: AGENTS, currently
----Context
Continue's "custom agents" exist but in a config-shape, not a file-shape:
~/.continue/agents/*.yaml(user-global) or.continue/agents/*.yaml(project)This is a non-trivial mismatch with the canonical model where
model.Agentis markdown + frontmatter (mirrors Claude/Cursor/Gemini/Copilot). A real translator needs to:v0.8.0 left this at
----because the translator is mid-sized and benefits from a thoughtful design pass rather than a fast port.What to implement
Agent.Description→ Continue'sdescriptionAgent.Document.Body→ Continue'spromptorinstructionsmodels[]+defaultModelAgent.Tools(wildcards or explicit) → Continue'stools[]config.continue/agents/<n>.yamlinplugins/continue_plugin.go'sPlan().Capabilities().AgentsfromSupportUnsupported→SupportDegraded(the translation loses some structure) orSupportNativeif a clean mapping is found.internal/importer/continue.goto read.continue/agents/*.yamlback intomodel.Agent. The reverse mapping should round-trip — at minimum body + description + name.Acceptance criteria
prism capabilitiesshows continue AGENTS =degr.ornative.Open design questions
.continue/permissions.yaml)?