Plan with the main agent, hand implementation to a separate worker, then
return to the main agent for review.
New here? Paste this to your agent
Open Claude Code or Codex in any directory, paste the block below, and let
the agent install Elves and explain how it works. Shell install steps are optional if
you prefer them: see Install Elves.
Install Elves for whichever coding agents I have on this machine (Claude Code and/or Codex), then explain how Elves works. Do not start an implementation run unless I ask.
1. Detect availability:
- Claude Code: `claude` on PATH and/or `~/.claude`
- Codex: `codex` on PATH and/or `~/.codex`
Install only for hosts that are actually present. If both exist, install both.
2. Install from a temporary clone of https://github.com/aigorahub/elves.git:
ELVES_TMP="$(mktemp -d)"
git clone https://github.com/aigorahub/elves.git "$ELVES_TMP/elves"
python3 "$ELVES_TMP/elves/scripts/sync_installed_skills.py" --apply --target <claude|codex|all>
rm -rf "$ELVES_TMP"
Use target `claude`, `codex`, or `all` to match what you detected.
3. Validate each install you performed:
python3 ~/.claude/skills/elves/scripts/install_doctor.py --startup
python3 ~/.codex/skills/elves/scripts/install_doctor.py --startup
4. In plain language, explain:
- Elves is a skill for Claude Code or Codex (those are the supported main drivers).
- I own the plan and whether to merge. The driver plans/reviews/lands; a separate worker implements.
- Default: same subscription, lower-effort native worker. Outcome is usually a landable PR; merge only if I authorize it.
- Optional workers (Grok Build, Devin, OpenCode, …) are not required. Native works with no extra keys.
- Grok Build is an optional *worker*, not a supported main driver for the Elves skill itself.
5. Stop after install + orientation. Offer one short first-run starter prompt I can paste later (chat-to-work: landable PR, do not merge).
Hosts. Supported main drivers are Claude Code and
Codex only. Grok Build, Devin, and OpenCode can be optional workers
after Elves is installed on a supported host — they are not where you install the Elves
skill.
How a run works
Elves keeps the agent that understands your intent available for planning
and review. A separate worker handles implementation. The planning agent can stay quiet
while the worker commits progress.
Plan. Agree on the outcome, constraints, acceptance criteria,
and risky areas with Claude Code or Codex.
Work. Elves recommends a worker, gives it one complete packet,
and shows its live output or provides an exact follow command before the driver
parks.
Review. The main driver checks the whole change, pays closer
attention to the risks named in the plan, fixes real gaps, and prepares the PR.
The worker never decides to merge. It may commit and push only on its
assigned feature branch when the run grants that narrow permission. PR review, protected
refs, release work, and merge stay with the driver and the user.
Install Elves
Install from a temporary clone. The sync helper updates the main skill and preserves
user-owned Claude Code aliases.
Start with the outcome and the landing choice. You do not need to name
internal Elves phases or write a launch script.
Open a terminal and change to the repository you want Elves to modify.
Start Claude Code with claude, or open the repository in Codex. Codex CLI
users can start it with codex.
Paste one of the prompts below into that agent conversation.
Finish the work but do not merge
Implement this plan while I am offline. Review the completed work and leave the PR
ready for me, but do not merge it.
Finish the work and merge when it is ready
Implement this plan, review and revise the completed work, then land the PR with a
regular merge commit when all serious issues are resolved.
Both requests use the same planning, implementation, proof, and review path. The second
request also grants the driver merge authority after final readiness. Worker completion
alone is never enough.
If the plan is still in your head
Describe the change in ordinary language. Elves will help turn it into a durable plan
before launching the worker. Name the parts that need caution and the evidence that would
convince you the result is complete.
Choose a worker
Elves checks the current host and available tools without making a model call. It shows
one recommendation and asks at most one useful preference question.
Situation
Usual choice
Why
Claude Code or Codex only
Same model, lower effort
Keeps the exact observed model identity on the subscription
already in use while leaving the stronger live driver available for review.
Grok Build is available and allowed
grok-4.5 at high
Composer 2.5 is retired. Elves prefers grok-4.5 when
the live catalog returns it and requests Grok's highest supported effort.
The implementation is genuinely complex
Explicit live-catalog model
Pin another catalog member only when the authenticated catalog
returns that exact identifier (not retired Composer).
Devin CLI is installed and configured
devin-cli with
swe-1-7-lightning
Provides another persistent worker when Devin is the available
subscription or the selected fallback.
“Inherit” means the exact same model, with only effort lowered: GPT-5.6
xhigh/extra-high/ultra → GPT-5.6 medium;
GPT-4.8 Max/UltraCode → GPT-4.8 medium; Fable 5
max/ultra → Fable 5 low. If Fable explicitly
routes to Opus, Elves names the cross-model route as claude-opus-4-8 at
medium. Unlisted native routes remain plan-matched. The live driver is not
downgraded. Devin CLI and other configured adapters remain optional routes, not required setup.
Grok provider availability is independent from goal support: proven headless
/goal is an enhancement, and a compatible one-packet prompt is the recorded
fallback. Permitted Grok workers use grok-4.5 at explicit high
when the live catalog offers it. Composer 2.5 is retired and is never selected.
Machine-check a cold handoff when needed
Elves v2.9 adds optional explicit handoff v1 for coordinators that need deterministic
state transfer to a separate worker. Declaring it binds fresh-start or resume state,
acceptance ownership, the current branch and commit, and a matching bounded Markdown or
JSON packet capsule. The ordinary path stays advisory when the schema is absent. This is
cold-handoff evidence, not prewalk continuity; see the
schema and acceptance contract.
Use exact-session prewalk when qualified
Prewalk lets one native worker orient on a guide model or effort, create a bounded TODO,
make the first real task edit, and then resume the same session in the same
worktree on the execution route. The packet is sent once; the later input is only
Continue.. Starting a new worker with a summary is a normal cold handoff, not
prewalk, and Elves never cold-falls back after an edit.
# Read-only: inspects installed help/version and makes no model call.
python3 "$ELVES_SKILL_ROOT/scripts/cobbler_agents.py" \
native-worker prewalk-capabilities --host codex --json
# Use --host claude for Claude Code or --host grok for Grok Build.
The preference defaults to safe auto, while direct launch defaults to
off for compatibility. Help output proves only that exact-resume and route
flags are advertised. Actual prewalk stays off until the exact installed host version has
behavioral evidence for session, worktree, and stream continuity, route change, no packet
replay, and honest instruction fidelity. The current persisted-instruction transport
activates only for proven retained_safe; pruned and
turn_scoped remain future delivery states. required fails before
launch if proof is absent; no paid canary runs implicitly.
Grok prewalk has an additional maintainer-owned launch gate. A recorded
grok_prewalk_qualification_canary must be supplied together with
--probe-grok, which binds it to the version and build commit reported by the
installed binary. Even valid retained_safe evidence cannot open
launch_ready by itself. While that gate is closed, auto reports
grok_prewalk_unqualified:launch_feature_gate_closed with actual mode
off, and required fails before launch.
Use the optional open-source Grok worker
Install from the official Grok Build
source, then authenticate once. The first grok launch opens the browser
login flow.
curl -fsSL https://x.ai/cli/install.sh | bash
grok
ELVES_HOST=claude # Use codex when Codex is the live driver.
python3 "$ELVES_SKILL_ROOT/scripts/cobbler_agents.py" route-worker --json \
--host "$ELVES_HOST" --execution-reasoning medium --review-risk high \
--provider grok --allow-grok --probe-grok
The capability check uses the narrow OAuth projection. Its /goal status
probe is independent of catalog lookup and model inference, but proves command resolution
only. Goal mode additionally requires an authenticated objective canary to reach terminal
state and return the requested session identity. Without that evidence, Elves keeps the
qualified provider and records the compatible one-packet fallback.
The optional evidence input is a bounded, mode-safe JSON canary artifact tied to the exact
installed build, canonical session, /goal prompt digest, successful exit, and
matching end event. Invalid or incomplete evidence keeps goal mode off. See the
open-source
Grok worker reference for the artifact schema.
Unattended Grok launch: Elves uses --always-approve alone.
Grok Build 0.2.101 treats --permission-mode auto as an override, so combining
the two can cancel the first tool turn. Elves also treats a structural cancelled,
refused, errored, or max-turn terminal event as failure even when Grok exits zero.
Cache handoff is not promised. A separate session may receive provider
cache hits, but Elves cannot export the live driver's active conversation memory or model
state and inject it into another process.
Parallel lanes (Parallelves)
Parallelves runs several worker lanes at once, each in its own worktree on its own
branch, within one run. Serial stays the default. The worker.parallel
preference is off unless you set it to auto, and even
auto only recommends lanes when a deterministic width test passes. Nothing
launches lanes automatically; the driver composes each lane as its own supervised
session and records a concrete reason whenever lanes are declined. See the
Parallelves
contract for the full rules.
Watch the work
Before the driver parks, it should display the worker's live output or give
you an exact command to follow the log. You can watch the worker without asking the
driver to narrate routine progress.
Set the active installed skill root first. Keep the target repository as your working
directory.
# Claude Code
export ELVES_SKILL_ROOT="$HOME/.claude/skills/elves"
# Codex
export ELVES_SKILL_ROOT="$HOME/.codex/skills/elves"
Then run the exact command Elves printed. Native workers use:
If the worker exits cleanly after committing and pushing but omits a valid final report,
run the affected host tests and reconstruct only the independently provable fields:
The worker should also commit meaningful slices. Those commits are a durable progress
readout and give the final reviewer clean points to inspect. The driver wakes on completion,
blocked, or safety events. If the worker exits unexpectedly, the supervisor records the
exit and the driver reconciles the actual branch state.
Review and finish
At the end, the driver reviews the complete branch rather than repeatedly reviewing each
batch. It checks the plan's acceptance criteria, the risky surfaces, relevant tests, and
unresolved GitHub feedback.
Worker confidence actively guides that review on both Claude Code and Codex. A trusted
full-run returns a bounded review block at terminal; a native worker records the same
signal in Confidence: commit trailers. The reviewer deep-checks every
reservation, low-confidence or conflicting area and reports the evidence. Missing signals
keep the full baseline review, while high confidence never removes a gate or review step.
Revisions get narrower checks. The driver should not rerun an unrelated full test suite
after every small fix. It reruns the tests that the revision could reasonably affect,
then performs one final readiness check at the exact branch tip.
If you asked Elves not to merge
The run stops with a reviewed, landable PR. You can inspect it and merge it yourself.
If you authorized landing
The driver clears serious review findings and required checks, confirms the exact PR
head, then uses a regular merge commit. Elves never squashes or rebases this path.
Land a reviewed PR later
In the active Elves conversation, say “land this PR.” If the host maps Elves command
strings, /land-pr or \land-pr starts the same reviewed landing
path. The driver repeats only the checks needed for changes since readiness.
Worktree cleanup after merge
Runs that used a dedicated git worktree reclaim it after the merge. The driver runs
./scripts/preflight.sh --gc-worktrees, which first reports and then, with
--apply, removes only worktrees that are clean, fully merged, and fully
pushed. Anything unmerged, dirty, or not registered as a worktree is listed and left
alone, so parallel work and your own directories are never touched.
Save preferences
Safe convenience choices can be stored once for both hosts in
${XDG_CONFIG_HOME:-~/.config}/elves/config.json. Repository safety rules and
explicit instructions for the current run still take precedence.
python3 "$ELVES_SKILL_ROOT/scripts/cobbler_agents.py" preferences show
python3 "$ELVES_SKILL_ROOT/scripts/cobbler_agents.py" preferences set worker.provider native
python3 "$ELVES_SKILL_ROOT/scripts/cobbler_agents.py" preferences set worker.provider grok
python3 "$ELVES_SKILL_ROOT/scripts/cobbler_agents.py" preferences set worker.prewalk auto
python3 "$ELVES_SKILL_ROOT/scripts/cobbler_agents.py" preferences reset
Credentials, destructive authority, protected-ref authority, approval bypasses, and
merge permission cannot be stored as preferences.
Troubleshooting
I do not see worker output.
Look for the native agent view or exact follow command printed before the driver parks.
If neither was proven, Elves should say that visibility is commit-only instead of
claiming a live stream.
The worker stopped early.
Check the supervised worker status and recent commits. The driver should reconcile the
exact session and branch state, list the remaining tasks, and resume the same worker
when safe.
Grok Build was not selected.
Installation is not permission. Elves also checks authentication, repository policy,
remembered or current-run consent, core installed-binary capabilities, and the
authenticated live model catalog. A failed core check falls back to the native route
and records why. Missing goal support alone uses the one-packet fallback without
disabling an otherwise valid Grok provider.
I opened Grok Build and tried /elves (or Elves appeared in skills).
Unsupported host. Grok Build can discover the Elves skill when Claude
skill compatibility is on (for example after install into
~/.claude/skills/elves), but Grok is not a supported main
driver. Do not stage or run Elves from inside Grok as the orchestrator. Open
Claude Code or Codex, install Elves there if needed,
and start the run from that host. Use Grok as an optional worker only after
the supported host permits it. The skill should refuse Grok-as-host orchestration and
redirect you.
A source-checkout command works but the installed skill command does not.
Use the helper under the active installed skill root and keep the target repository as
the working directory. Run the install doctor for that host to find a stale or shadowed
project-local install.