ECC for devin desktop

[AnshumanPadhi]

ECC for Devin: a native .devin-plugin/ distribution channel

The idea

Package ECC as a Devin CLI / Devin Desktop plugin, giving Devin users the
same coordinated engineering system ECC provides for Claude Code:

plan -> test -> implement -> review -> verify -> remember -> improve

Today ECC ships first-class installers for Claude Code, Codex, and Kimi Code.
Devin CLI has matured its own extensibility surface — plugins, hooks, skills,
rules, and custom subagents — that maps almost 1:1 onto ECC's components. That
makes Devin the lowest-effort, highest-parity harness ECC could add next.

Why it's feasible now

Devin's plugin format is a repo/folder containing:

my-plugin/
├── .devin-plugin/plugin.json   # manifest (name, requiredPlugins, etc.)
├── AGENTS.md                   # always-on rule
├── rules/                      # triggered rules (frontmatter-driven)
├── agents/                     # custom subagent profiles
├── hooks.json                  # lifecycle hooks
├── .mcp.json                   # MCP servers
└── skills/<name>/SKILL.md      # ordinary skills — no new format

ECC's content maps directly:

ECC component	Devin native surface
skills/ (292 skills)	Plugin skills/ — same SKILL.md format, exposed as /ecc:<skill>
agents/ (68 agents)	Plugin agents/<name>.md custom subagents
rules/ (common + per-language packs)	Plugin rules/ with trigger frontmatter + always-on AGENTS.md
Hooks	Plugin hooks.json + project-level .devin/hooks.v1.json (Claude-compatible JSON)
mcp-configs/	Plugin .mcp.json / manifest mcpServers
Commands (94 shims)	Thin skills — in Devin, skills are the slash-command surface
Install scopes / profiles	Plugins install user-level (cloud-synced) or --local; repos pin requirements via .devin/config.json

Bonus: Devin already reads Claude formats

Devin falls back to .claude-plugin/plugin.json if no .devin-plugin/
manifest exists, honors Claude plugins' .mcp.json, and imports .claude/
commands, subagents, and hooks plus CLAUDE.md/.cursor/rules/
automatically. So a dual-manifest repo (.devin-plugin/ + .claude-plugin/)
could serve both harnesses from one codebase.

Known limitations to design around

1. Plugin hooks fail open today — security guardrails (secrets scanning,
   protected files) must ship as documented project-level
   .devin/hooks.v1.json snippets, not plugin hooks.
2. Plugin subagents are local-only (CLI + Desktop); they don't load in
   Devin cloud sessions.
3. Project config is a restricted subset in Devin (permissions,
   mcpServers, read_config_from, hooks only) — model/provider settings
   stay user-owned, matching ECC's existing Kimi adapter story.
4. Plugin installs are user-level and sync via Devin Cloud (requires sign-in);
   repo-level pinning goes through requiredPlugins in .devin/config.json.

Proposal

1. Add a .devin-plugin/plugin.json manifest to this repo (or a devin/
   subfolder plugin, if we prefer a curated subset à la agent-sort).
2. Auto-generate the plugin's skills/ + agents/ from ECC's existing
   components at release time, so there's one source of truth.
3. Ship a docs/DEVIN-GUIDE.md mirroring the Codex/Kimi guides, including the
   recommended project-level hook snippets.
4. Update the platform-support matrix with the Devin column and its caveats
   (fail-open hooks, local-only subagents).

Install experience would simply be:

devin plugins install affaan-m/ECC
# or locally while developing
devin plugins install --local ./ECC

Happy to draft the manifest + generation script if there's interest.

[chenhz01]

The component table is mostly right; two rows are where I'd expect it to break.

Commands-as-thin-skills: ECC commands carry argument frontmatter. If Devin's slash surface doesn't preserve argument passing, 94 shims silently degrade to no-ops rather than erroring.

Hooks: "Claude-compatible JSON" is the risky claim. ECC's session persistence depends on Stop carrying transcript_path; if Devin's event names or payload differ, memory and continuous-learning die silently.

So I'd write the conformance test before the adapter:

for each hook event in hooks/hooks.json: assert Devin emits it with transcript_path
for each command: assert args survive the skill shim

Happy to PR the conformance test first — it decides whether the rest is safe.