engine-implementation-executor

An implementation agent for applying an already-reviewed Rust code-change plan. It edits only the approved scope and verifies the result using the project's specified checks.

In plain words
What is it for?
It applies the reviewed plan, checks the worktree and requested boundaries, runs verification, and reports the resulting changes and judgement calls.
Why use it?
It separates implementation from planning and review, reducing accidental changes outside the agreed work.

Agent for Claude Code

Install

Getting it into your agent

One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.

agentmods
npx agentmods add agents/phase-rs/phase/engine-implementation-executor
Clone the repo
git clone --depth 1 https://github.com/phase-rs/phase

Made for: Claude Code.

Per session 68 Only the description is in the session, so the agent can decide to use it. The body loads when it is invoked.
When invoked 5,398 The whole file, excluding the scripts and references it only reads on demand.
Security scan A 0 findings. Scan, not verified.
Origin original No closer match found in the catalogue.
Token cost

What it costs to keep this loaded

Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.

ModelPer sessionOnce invoked
Fable 5 $0.00068 $0.05398
Opus 5 $0.00034 $0.02699
Sonnet 5 $0.00014 $0.01080
Haiku 4.5 $0.00007 $0.00540

Measured yesterday against content hash 4b97eeeeb1fa, method: parsed. Prices are Anthropic first-party input rates as of 2026-08-30, from the pricing page.

Security

Grade A, and why

engine-implementation-executor scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured yesterday.

A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.

Nothing flagged

None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.

.claude/agents/engine-implementation-executor.md · 278 lines

How it starts

The opening of the file, as written. The whole thing — 278 lines — stays where its author put it; the contents beside it link to each section on GitHub.

Engine Implementation Executor

You are either the implementation/fix arm or the fresh measurement-only arm of the /engine-implementer pipeline. The plan has already passed /review-engine-plan to clean. You do not plan, review, stage, or commit. Checkpoints and final acceptance belong to the orchestrator skill.

Input

The orchestrator gives you:

  1. Mode: implementation/fix or measurement-only.
  2. The reviewed plan (every section: Pattern Coverage, Building Blocks, Logic Placement, Rust Idioms, Nom Compliance, Extension vs Creation, Analogous Trace, step-by-step file changes).
  3. BASE_SHA; for implementation/fix, named START_SHA and IMPLEMENTATION_WORKTREE; for measurement-only, immutable CANDIDATE_SHA and the named IMPLEMENTATION_WORKTREE too.
  4. Frozen in-/out-of-bounds scope paths as a duplicate-free LC_ALL=C sort -z NUL-delimited representation and its SHA256; for measurement-only, clean detached base/candidate projection worktrees.
  5. For an implementation/fix round, any reviewer findings as constraints.

Mode is a hard boundary:

  • implementation/fix: First verify and report IMPLEMENTATION_WORKTREE as clean with HEAD == START_SHA and no staged entries. The initial executor has START_SHA == BASE_SHA; every fix executor has the prior reviewed CANDIDATE_SHA as START_SHA, never a moving head. After surgical edits, report only PREPARATORY checks and the required end-of-edit stable-HEAD check (HEAD == START_SHA, no executor staging, exact authorized unstaged delta). Do not create a candidate commit or a completion claim.
  • measurement-only: Make no source edits, formatting edits, or commits. Answer one question: does this change move parser output? First confirm the supplied base/candidate worktrees are detached, clean, and at their expected SHAs. Run scripts/engine-source-hash.sh in each. If the hashes match and nothing in Cargo.toml, .cargo/config.toml, rust-toolchain.toml, or scripts/engine-source-hash.sh changed between the two, there is no parse-affecting change and you are done. Otherwise build the tooling on each side, generate card data from each against the same pinned data root, run the comparator, and report what actually differs. If you cannot complete the measurement, say so plainly and do not claim parser evidence.

Read the full file on GitHub · 278 lines

Changes

What this file has done since we first saw it

Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.

  1. yesterday First seen · 278 lines · 68 tokens per session scan A 4b97eeeeb1fa

Subscribe to this mod's changes

engine-implementation-executor is an agent published in the GitHub repository phase-rs/phase (259 stars, last pushed yesterday), licensed Apache-2.0. It adds 68 tokens to every session and 5,398 once invoked, about $0.0003 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-30.

Related

Other agents, from other repositories

git-workflow

Hermes CN 的需求与 bug 修复通常同时横跨 Desktop 与 Core 两个仓库。正式动手写代码前,两个仓库都必须先过这道预检,不要直接在 main 上改:.

Eynzof/Hermes-CN-Desktop · 0 tokens

game-developer

Game development expert. Unity, Godot, Phaser. Mechanics, Optimization, Multiplayer.

DDS-Solutions/AI-TadPole-OS · 21 tokens

pr-reviewer

STRICT internal pre-PR reviewer — the final gate BEFORE a PR is opened, so CodeRabbit finds fewer bugs. A generalist, diff-scoped critic that runs the repo's REAL tools, traces cross-file blast radius, verifies every finding, and applies React 19 / TS / Tauri 2 + Rust invariant checks. Use right before git push /…

saeedkolivand/ai-job-hunter-app · 119 tokens

frontend-reviewer

Primary reviewer for the React renderer AND the Next.js landing site — UI components, routes/pages, UI state, design-system compliance, accessibility, and localization. Use for changes under apps/desktop/src/renderer/, components/, pages/, apps/landing/. Does NOT activate for ATS scoring, AI providers, Rust services…

saeedkolivand/ai-job-hunter-app · 80 tokens

project-steward

WRITE-access sole owner of documentation, the knowledge base, ADRs, the lessons log, and release process. The ONLY agent allowed to write/archive/dedupe lessons and maintain ADRs/project docs. Use for /update-docs, /prepare-release, and as the final step of the implement-workflow to sync docs/knowledge and persist…

saeedkolivand/ai-job-hunter-app · 75 tokens

tauri-security-reviewer

The project's cross-cutting SECURITY AUTHORITY — desktop, application, backend, AI, data, abuse-prevention, and supply-chain security. Use (as Primary for security-config, as the standard Secondary on any risk-bearing change) for capabilities/, tauri.conf.json, permissions/, updater/plugins, net/, credentials/…

saeedkolivand/ai-job-hunter-app · 117 tokens