Meta Edit

meta-edit

Languages: English · 日本語 · 简体中文

An MCP server that replaces a coding agent's single Edit tool with twenty-one kind-specific edit tools. Each tool carries — in its own description — the testing obligations for that kind of change. The 16 impl tools additionally carry a required target: "prod" | "test" flag so test edits are visible inside their kind's audit surface. Every declaration also carries a required provenance field (the epistemic source of the edit: user_confirmed / accepted_artifact / direct_observation / inference / speculation) and a required execution_state field (normal / repeating_failure / recovery) so the audit log captures both the certainty and the session context of every edit.

For the long-form explanation, with applications beyond editing, see the project page.

The idea

CLAUDE.md, Skills, system prompts, and review checklists are all texts the model might re-read. They drift out of attention as the conversation grows. By the time the agent calls Edit, those instructions have effectively expired.

One surface is different. The schema and description of the tool the agent is about to call are loaded at every invocation, immediately before the call. They are the only place where an instruction is guaranteed to be in front of the model at the moment of action.

meta-edit puts obligations there. A single generic Edit is too coarse — you cannot write "produce a boundary test when changing < to <=" on it without also misfiring on a typo fix. So we split: Edit becomes twenty-one edits, one per kind of change. The agent must pick a kind before it can edit. Picking the kind is the reasoning step.

The conceptual ancestor is SQLite's testing strategy — boundary values, MC/DC condition coverage, anomaly testing, per-change checklists — translated from C-library quality discipline into application-level edit categories.

The twenty-one tools

edit_cosmetic                 edit_boundary_condition
edit_boolean_condition        edit_state_transition
edit_db_schema                edit_data_migration
edit_api_contract             edit_serialization
edit_error_handling           edit_retry_timeout
edit_concurrency              edit_external_side_effect
edit_cache_invalidation       edit_permission_logic
edit_dependency_config        edit_policy_change
edit_progress
edit_observation
edit_proposal
edit_decision
edit_explanation

Each description specifies: when to use it, when not to use it, which tests must accompany the edit, and when to stop and ask the user. The 16 impl tools (everything except the 5 workflow-axis kinds) carry a required target: "prod" | "test" flag — prod/test pairs land as two declarations of the same tool, both in the same commit.

v0.5.0: the previous edit_test_only_change and edit_refactor_only slots are gone. Test edits flow through the kind-specific impl tool with target: "test". edit_cosmetic replaces edit_refactor_only with a much narrower vocabulary (whitespace / comments / formatter output only); renames, extracts, and dead-code removal route to stop-and-ask instead of a generic refactor catch-all.

What we've observed

When no kind cleanly fits a requested change, the agent stops and asks instead of forcing the change through the nearest tool. We have observed this at ~80% context utilisation — exactly the regime where CLAUDE.md normally loses its grip. The transcript that led to the workflow tool The 5 workflow-axis kinds (edit_progress / edit_observation / edit_proposal / edit_decision / edit_explanation) are on the project page.

Install

Claude Code plugin marketplace

This repo is a single-plugin marketplace.

/plugin marketplace add hiniachi/meta-edit
/plugin install meta-edit@meta-edit

That auto-registers the MCP server (twenty-one edit_* tools) and the two safety hooks (deny-raw-edit, deny-bash-write-bypass). The plugin runs prebuilt JavaScript shipped under dist/; Node 20+ is the only runtime requirement — no Bun, no npm install, no build step.

To pull a newer marketplace version after a release: