EONYX recipes: practical workflows

Features are nice, but it is more interesting to see them at work. A few practical scenarios: how to phrase the task and which EONYX techniques to turn on. The prompts are deliberately plain.

1 Working with code

Three common tasks in interactive mode: understand someone else’s code, fix a test and carefully rewrite a module.

1.1 Understand unfamiliar code

Start with a plan so the agent explores first instead of jumping into edits:

/plan
figure out how authorization works in this repository,
and put together a short map: where the entry point is, where sessions are stored

In plan mode only reading is available, so the agent walks over the code safely (grep, read, glob) and proposes a plan or a summary. Heavy exploration can be delegated to a subagent so it does not clutter the context:

via task: find every place where the Store interface is called and return a list

1.2 Fix a failing test

Let the agent run commands and make edits — the simplest way is headless with --yolo:

eonyx run --yolo "run go test ./... , find the cause of the failure and fix it without touching the public API"

Or in the TUI: allow the tools you need and ask. It helps to show the output first:

! go test ./...
fix the failure above with a minimal change

A command run via ! is recorded into the conversation, so the model sees the real test output.

1.3 Refactor a module

Fork the session as a save point, then drive the edits iteratively:

/fork
move config parsing out of main.go into a separate config package,
preserve the behavior, update the imports and run go build ./...

If something goes wrong, you can return to the original session from the list (Ctrl+S). Auto-formatting can be attached as a hook so you do not have to ask every time:

"hooks": { "edit": { "after": "gofmt -w ." }, "write": { "after": "gofmt -w ." } }

2 Automating routine work

Repeated operations are worth setting up once — as a skill, a hook or a pipe in a script.

2.1 Prepare a release

Collect the checklist as a skill so you do not have to repeat it:

---
name: release
description: Release checklist. Use when asked to prepare a release, ship it, or cut a tag.
---
1. git_status — the tree is clean, the branch is main.
2. go test ./... and go vet ./... — green.
3. Propose the next tag from git describe --tags; do NOT push without confirmation.

After that “prepare a release” is enough — the agent loads the skill and follows the steps. The ban on pushing without confirmation can be duplicated with a guardrail hook on the bash tool — that is how the agent invokes git push (the git_commit tool only commits).

2.2 A one-off task in a script

EONYX is easy to embed in a pipe: the result goes to stdout, everything auxiliary to stderr.

# generate a draft README from the code
eonyx run "write a README for this repository, short and to the point" > README.draft.md

# explain an error from the log (the argument takes priority over stdin,
# so the prompt and the log are fed to stdin as a single stream)
{ echo "explain the cause of the error and suggest a fix:"; cat error.log; } | eonyx run

For machine parsing — --json and jq:

eonyx run --yolo --json "run the linter and fix the warnings" | jq -r 'select(.type=="result").text'

3 Summary