Clarify package comparisons in README

Author: tninja

README.org

@@ -28,24 +28,20 @@ An Emacs interface for AI-assisted software development. *The purpose is to prov
 
 - I switch between different CLI-based AI tools in Emacs: Claude Code / OpenAI Codex / Gemini CLI / etc. If you also use different AI tools inside Emacs, but want to keep the same user interface and experience, this package is for you.
 
-- If you are deciding between the main AI coding packages inside Emacs, the most important question is this: do you want one consistent coding workflow across many AI tools, or do you want the deepest integration for one specific agent runtime? The table below focuses on the user-visible differences that matter day to day.
+- If you are choosing between the main AI coding packages in Emacs, ask one question first: do you want the deepest integration for one specific agent runtime, or do you want one Emacs workflow that stays stable even when you change AI tools?
 
-| Feature     | ai-code-interface.el                                                                                                          | claude-code-ide.el                                                                                  | agent-shell                                                                      | eca-emacs                                                                   |
-|-------------+-----------------------------------------------------------------------------------------------------------------------------+----------------------------------------------------------------------------------------------------+---------------------------------------------------------------------------------+------------------------------------------------------------------------------|
-| Switching   | Best when you move between Codex, Claude Code, Gemini CLI, Copilot CLI, and other supported backends without relearning commands | Claude Code only                                                                                   | Many ACP agents, but through one ACP shell model                                 | ECA agents and models inside one ECA workspace                                |
-| Context    | Current file, visible buffers, function or region, saved repo context, prompt files, and @ file completion                                | Active file, selection, project data, diagnostics, and editor-aware mentions                                 | Shell session context, project files, transcripts, screenshots, and clipboard image support | File and range references, repomap, cursor auto-context, and workspace-aware chats |
-| Editor tools | Built-in Emacs MCP tools for project info, imenu, xref, and tree-sitter, plus MCP debug and config helpers                              | Deepest Claude-specific Emacs MCP bridge, including diagnostics and custom Emacs tools exposed to Claude | MCP server configuration is available, but the main focus is the ACP shell session        | MCP-aware chat settings and tool-call handling, but centered on the ECA server      |
-| Actions     | Task-first actions such as change code, implement TODO, explain, ask, refactor, and prompt workflows                                | Claude-first IDE prompting, mentions, and editor-aware operations                                       | Shell-first agent interaction; coding style depends on the ACP agent you connect       | Chat-first coding, context injection, and rewrite flows                             |
-| Dev loop    | Built-in TDD cycle, diff review, Magit helpers, and refactoring actions                                                              | Strong Claude-specific ediff flow with diagnostics-aware review                                          | Strong queue, transcript, model-switching, and container-friendly shell workflow       | Strong approvals, rewrite diff, timelines, and saved chats                          |
-| Sessions    | Multi-session per backend support / git worktree support                                                                         | Multiple Claude sessions per project                                                                  | Multiple ACP shells with queueing and transcripts                                   | Multiple chats per workspace with agent and model switching                     |
-| Visibility    | Review-oriented commands, prompt files, and backend-aware session buffers                                                      | Session list, debug buffer, resume flow, and IDE diff controls                                            | Queue view, transcripts, screenshots, and shell-level visibility                         | Tool-call approvals, expandable blocks, timeline view, and chat state indicators       |
-| Best fit     | You want one Emacs UX across many AI coding tools                                                                             | You want the deepest Claude Code integration in Emacs                                                | You want ACP-native shells and transcript-heavy workflows                           | You want a polished server-backed chat workspace                               |
+- *ai-code-interface.el* is built for the second case. Its real advantage is not just backend coverage. Its main advantage is *workflow portability*: the same menu, context gathering, prompt flow, refactoring commands, TDD helpers, review workflow, prompt files, and Emacs MCP tools continue to work while the backend changes underneath.
 
-- All four packages share the same broad goal: keep AI-assisted coding inside Emacs, preserve project context, and make long-running AI sessions practical. The difference is where they place the center of gravity. =claude-code-ide.el= goes deepest on Claude Code plus MCP-powered editor awareness. =agent-shell= goes deepest on ACP and shell-native agent operations. =eca-emacs= goes deepest on a dedicated server-backed chat UX.
+| Package              | Built around                    | Choose it when |
+|----------------------+---------------------------------+----------------|
+| ai-code-interface.el | One workflow across backends    | You switch AI tools but want one stable Emacs workflow |
+| claude-code-ide.el   | Claude Code inside Emacs        | Claude Code is your main runtime |
+| agent-shell          | ACP shell sessions              | You prefer shell-first agent workflows and transcripts |
+| eca-emacs            | An ECA-centered chat workspace  | You want a polished server-backed chat UX |
 
-- =ai-code-interface.el= is different because its biggest advantage is *one stable coding workflow across many AI backends*. Unlike =claude-code-ide.el=, which is centered on Claude Code, =agent-shell=, which is centered on ACP shells, or =eca-emacs=, which is centered on the ECA server, =ai-code-interface.el= keeps the same menu, context gathering, prompt construction, refactoring actions, TDD helpers, git-oriented review flow, and Emacs MCP tools while the backend changes underneath. In practice, that means switching from Claude Code to Codex, Gemini CLI, Copilot CLI, or another backend does not force you to relearn how you work inside Emacs.
+- All four packages aim to keep AI-assisted development inside Emacs. The difference is what stays fixed. In =claude-code-ide.el=, the center is Claude Code. In =agent-shell=, the center is the ACP shell session. In =eca-emacs=, the center is the ECA workspace. In =ai-code-interface.el=, the center is your *development workflow inside Emacs*.
 
-- That also means this package is a good fit when you do not want to pick a single winner forever. You can keep using specialized backends when they are the right tool for a task, but still drive them from one Emacs-centered interface focused on code changes, review, and iterative development instead of one vendor-specific chat surface.
+- That distinction matters if you do not want to commit to a single winner forever. You can use Claude Code for one task, Codex for another, Gemini CLI for a third, and still keep the same habits inside Emacs: the same entry points, the same context model, and the same review-oriented development flow. You are changing the backend, not changing how you work.
 
 - Screenshot