spike(framework): prove AIDD works in Zed through a host tool

Open
#300 1 comment 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
45/100
Issue type
Documentation
Clarity
Mostly clear
Activity status
Active
Tech stack
javascript, typescript
Domain
cli, documentation, tooling

Research direction

Start with cli/src/domain/models/tool-ids.ts, cli/src/application/use-cases/framework/strategies/tool-contracts.ts, and plugins/aidd-context/hooks/update_memory.js to understand existing host integration. Choose one Zed execution mode, install AIDD in a real Zed workspace, and record discovery, invocation, limitations, versions, and the tested environment; update the compatibility table and installation guidance with only verified claims.

Written by the indexing model from the issue text.

Description

Problem

Zed is not in the compatibility table, so users cannot tell which AIDD capabilities they can use or how to install them.

Zed supports compatible instruction files and the Agent Skills format, but this does not establish out-of-the-box compatibility with the entire framework. The supported execution mode and remaining limitations must be explicit.

In particular, Zed Agent selects the first matching project instruction file, rather than automatically combining AGENTS.md, CLAUDE.md, and GEMINI.md. Its documented priority is .rules, .cursorrules, .windsurfrules, .clinerules, .github/copilot-instructions.md, AGENT.md, AGENTS.md, CLAUDE.md, then GEMINI.md. See Zed Instructions.

Scope

  • Add a Zed row to the compatibility table.
  • Add its install steps alongside the other tools.
  • Qualify the execution mode and supported capabilities instead of claiming full parity from file discovery alone.

Acceptance criteria

  • Zed appears in the compatibility table with its install path and execution mode.
  • The claim is verified, not assumed: install into a real Zed workspace and confirm the skills load.
  • Record the tested Zed version, OS, AIDD version, and limitations; distinguish native Zed Agent support from external-agent or terminal usage.

To investigate (à voir): AIDD versus native Zed Agent

Assessment based on official documentation and source inspected on 2026-09-08, including Zed stable v1.18.1, and AIDD next at 25f08379303592e05f8d894099399f4166036e60.

No runtime test in Zed has been performed. “Documented” below describes a Zed capability, not a validated AIDD integration. “No equivalent identified” means no appropriate public contract was found in the reviewed documentation and source, not that an implementation is impossible. The gaps are investigation items, not an approved commitment to implement full parity within this issue.

What AIDD provides Zed equivalent, or lack of one Status and what remains to investigate
Project instructions and coding rules Native project instruction files, with first-match priority; personal instructions in ~/.config/zed/AGENTS.md. Documented, integration to test. Check which file wins in a multi-tool repository; .cursorrules can shadow AGENTS.md. Instructions
Skills with references, scripts, and assets Skills in ~/.agents/skills/<skill>/ or <worktree>/.agents/skills/<skill>/; skill directories must be direct children of the root. Documented, packaging to adapt/test. Preserve resources, normalize names, and verify discovery plus actual resource use. The 50 inspected AIDD skills fit the individual name/description bounds. Skills
Skill invocation and workflows that call other skills Zed supports explicit skill invocation and model-driven selection. Partial mapping. Verify references such as /aidd-dev:02-implement after publication; loading a skill does not prove that cross-skill invocation works. Do not assume host-specific permission metadata is enforced. Skills
CLI installation, updates, and removal across supported hosts Standard skill directories exist, but AIDD has no Zed host contract. AIDD integration missing. Reuse suitable flat-packaging primitives, not the entire Codex contract. Test ownership of shared .agents/skills/ files when Codex and Zed coexist. AIDD host IDs, packaging
Project memory index and automatic session-start synchronization Zed can read instructions and files. Automatic expansion of referenced memory files and an equivalent session-start integration are not established. Partial, automation unproven. AIDD's update_memory.js has no zed target and depends on SessionStart. An explicit refresh could be a documented fallback, not equivalent automatic behavior. Memory implementation
Isolated execution and checking through the executor and checker roles Native spawn_agent exists, with label, message, and optional session_id. Sub-agents supported; role mapping missing. No automatic discovery of AIDD agent definitions established. Verify role instructions, isolation, and actual tool restrictions. A prompt-only restriction is not necessarily enforced permission control. Stable tool contract, AIDD architecture
Lifecycle hooks such as SessionStart, PostToolUse, and Stop The task hook documented in Zed is create_worktree; it serves a different lifecycle. No appropriate public equivalent identified. Do not claim compatibility for AIDD hooks.json or replace automatic guarantees with a manually invoked task without stating the downgrade. Task hooks
AIDD usage telemetry and attribution to sessions/tasks No verified native Zed event and consumption source mapped to AIDD. Not supported by the current AIDD integration. Establish lifecycle events, counters, and task attribution before claiming support. Zed's own diagnostics or token display are not an AIDD/OTel export contract. AIDD telemetry hooks
MCP-backed integrations Native MCP Tools and Prompts, local/remote servers, configuration under context_servers. Documented, configuration mapping to test. Do not assume automatic import of another host's .mcp.json or complete MCP feature parity. Preserve existing configuration and secrets. MCP
Development and VCS workflows using files, shell commands, and permissions Native file/search/edit/terminal tools, profiles, approvals, and sandboxing. Documented, workflows to test. Adapt host-specific tool expectations. Git metadata stays non-writable while sandboxed, even with broad filesystem write grants; commit workflows need an explicitly authorized execution path. Tools, Git sandbox restrictions
Local quality guardrails through pre-commit checks, separate from AI lifecycle hooks Git hooks can operate independently of the editor when the chosen commit path runs them. Zed also has tool permissions. Path to validate, not lifecycle parity. Test actual pre-commit execution and keep CI validation. Neither pre-commit nor approval prompts replace session/tool-event observation. Tool permissions
Generation of skills, rules, agents, commands, and hooks for supported hosts Zed documents some corresponding native surfaces, but not all AIDD contracts. AIDD generator support missing. Update detection/writing references only for proven surfaces; explicitly report unsupported ones instead of generating fictional Zed formats.

Execution modes must remain separate

Mode Configuration owner Implication for this issue
Native Zed Agent Zed owns skills, instructions, tools, and profiles. Use the capability matrix above; native AIDD integration remains partial and untested.
External agent through ACP, e.g. Claude or Codex The external process generally owns runtime and native configuration; Zed provides the ACP interface. Test each adapter/version. ACP availability does not prove preservation of every AIDD plugin, hook, or permission.
CLI in a Terminal Thread The CLI retains its native skills, instructions, and configuration. Candidate for reusing an existing AIDD host installation; not evidence of native Zed Agent support.

Sources: External Agents, Terminal Threads.

Follow-up validation (à voir)

  • Choose and record the execution mode being qualified; avoid a blanket “Zed: supported” claim.
  • Test skill discovery in a trusted workspace, resource/script access, reload, and invocation of another skill.
  • Test instruction priority and distinguish automatic memory inclusion from explicit file reads.
  • Validate executor/checker handoffs, isolation, and permissions before advertising those workflows.
  • Validate one actual MCP integration and the intended Git/pre-commit execution path.
  • Check Codex/Zed coexistence for shared skills, updates, and removal.
  • Keep lifecycle hooks and telemetry explicitly unsupported/unverified until evidence establishes a compatible integration.
  • If native CLI integration and full workflow parity are desired, define that larger scope separately rather than silently expanding this documentation issue.
Dominant language
TypeScript
Stars
481
Forks
45
Avg merge
14h 36m
Merged PRs (30d)
110

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from ai-driven-dev/framework

All issues in ai-driven-dev/framework

Similar issues

More TypeScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.