Agent experience testing

Your next user
is an agent.

It will read your docs. Try your commands. Find its own way through your product.

AJX lets you see that first attempt—and turn the confusing parts into a better experience.

One prompt installs the CLI and the skill. You bring the product.

A small task. An interesting journey.Fictional example
!
The quick start has a wrong turn.

The documented --out flag fails. A help lookup reveals the supported --output flag.

Pick a stop. Follow the evidence.

→ A real task⑂ A fresh perspective! Observable friction↗ A better next attempt

A familiar responsibility

Let your product
speak for itself.

Your docs, commands, and error messages are an interface. An agent has to understand them well enough to get something done.

AJX records what happens when a fresh worker tries. You get the result and the route it took to get there.

Your words become its directions.

A quick start, a flag description, an example. Small ambiguities can become long detours.

Your feedback shapes its next move.

A useful error points forward. A silent command leaves the agent guessing whether to wait or retry.

A finished task is only part of the story.

The agent may recover from a rough experience. The journey shows what success alone can hide.

From a first impression to a useful finding

A little direction
goes a long way.

You set the task and the boundaries. AJX helps you observe the experience without having to reconstruct it afterward.

  1. 1

    Give it something to do.

    Choose a real user task and a way to verify success. Set the harness, model, environment, and access.

    “Export 100 records as CSV.”
  2. 2

    See where the work goes.

    Run a fresh worker. Follow its progress in the local console, then inspect the events and artifacts.

    A fork. A failed flag. A recovery.
  3. 3

    Give your team a place to start.

    Open the product asks. Each connects an observed problem to a proposed change and a success check.

    Fix the example. Try the task again.

When the product leaves questions unanswered

You’ve got some
explaining to do.

Start with what your team can improve. Switch between these fictional attempts to see how the asks change with the product version and run conditions.

Demo Export CLIFictional example
What your team can improve

3 product asks

✓ Task verified
01Roadblock

Make the quick-start export command executable.

The documented --out flag failed. Command help showed --output, which worked.

Product change

Use the supported --output flag in the quick start, with a copyable CSV example.

Evidence and success check +

The first attempt failed and required a help lookup before retrying.

Verify the fix: Run the documented command in a fresh workspace; it must produce a 100-row CSV.

E-003 → E-004 → E-005 Follow the journey ↗
02Wait

Expose progress while a CSV export is running.

Only start and completion messages appeared during the 47-second export.

Product change

Emit bounded progress on stderr and a final structured completion result.

Evidence and success check +

The agent could not distinguish productive work from a stalled command.

Verify the fix: Run a delayed export; progress must remain separate from CSV stdout.

E-005 → E-006 Follow the journey ↗
03Fork

Explain when to choose export instead of dump.

Both commands were described as writing records; the required CSV path was unclear.

Product change

State the output formats and intended use of both commands in top-level help.

Evidence and success check +

The agent had to choose without a selection signal.

Verify the fix: A user reading only top-level help can identify the CSV command.

E-001 → E-002 Follow the journey ↗

One product. More than one perspective.

A good experience
should travel well.

After the first attempt, try the same task across harnesses, models, and environments. Keep the evidence together so your team can compare what changes.

CodexClaude CodeKiro CLI

Choose the conditions.

Use local or Docker environments and choose the skills available to the worker. Keep the task, permissions, and success criteria explicit.

Make it part of CI.

Run saved tests without a person at the keyboard. Apply acceptance rules and collect JSON and JUnit results with ajx ci.

Your product’s turn

Make the first step
feel like second nature.

Open your project in a skill-capable agent and paste this prompt. Your agent handles AJX installation, checks the setup, and helps you choose a first task.

  • ✓
    Bring a project.

    A CLI, SDK, API, or tool you want agents to use.

  • ✓
    Have a worker ready.

    macOS or Linux, with Codex, Claude Code, or Kiro CLI installed and signed in.

  • ✓
    Review the plan before it runs.

    Check the task, success criteria, workspace access, and expected model costs.

Paste this into your agent
Install the latest stable AJX CLI and skill by following
https://raw.githubusercontent.com/royosherove/ajx/main/docs/AGENT-QUICKSTART.md
Then load the installed AJX skill.

I want to use AJX to test jq.
Starting point: https://jqlang.org/manual/
Task: Filter a sample JSON inventory to in-stock items and export their names and prices as CSV.

Prepare any tools, generated sample data, and local test server needed in a temporary workspace.
Use the AJX skill to run one trial with a fresh agent, verify the result, and show me the report and journey.
Try an example. No project needed.CLI + skill installed together
Prefer a terminal? Install the CLI + skill yourself.
bash -o pipefail -c 'curl -fsSL https://github.com/royosherove/ajx/releases/latest/download/install.sh | bash' && export PATH="$HOME/.local/bin:$PATH"

macOS or Linux. The installer includes the skill. Your agent can read it directly; start a fresh session if the host needs one to discover /ajx. No GitHub login required.

Existing skill? Get the complete replacement command.

Installs the native CLI + Agent Skill together.
No Go toolchain or GitHub login required.

A good agent experience
is built on purpose.

Give your next user a good start ↗