agentleFS
Sign inStart free
nowledge-conowledge-co/con-terminal/skills/terminal-agent-improvement-loop/SKILL.md

terminal-agent-improvement-loop

Skill651 starsChanged 7 days agoMITView on GitHub

Run a benchmark-driven improvement loop for Con's terminal agent. Use when iterating on pane awareness, SSH/tmux behavior, coding-cli flows, benchmark scoring, or progress tracking across many runs.

The file

We split this skill into the rules it gives an agent

11 rules. About 0 are common, 9 are distinctive, and 2 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈9

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 2

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Use this skill when improving Con as a terminal-native agent, not just fixing a one-off bug.

    line 8
  2. Distinctive:

    Run the benchmark on an idle tab:

    line 19
  3. Very specific:

    Use strict suites to protect the floor and operator suites to judge real workflows.

    line 38
  4. Distinctive:

    Prefer operator profiles that start a fresh conversation and have bounded step timeouts.

    line 39
  5. Distinctive:

    Prefer typed control-plane improvements over prompt-only fixes.

    line 40
  6. Distinctive:

    Do not overfit to a single benchmark phrase or one host layout.

    line 41
  7. Distinctive:

    Keep unknowns honest when the backend cannot prove more.

    line 42
  8. Distinctive:

    When benchmark infra changes, say whether the product improved or the measurement improved.

    line 43
  9. Distinctive:

    Keep iteration notes concise and comparable across runs.

    line 44
  10. Very specific:

    Keep docs/impl/terminal-agent-improvement-log.md useful to a human reader.

    line 45
  11. Distinctive:

    If you use the LLM judge, feed it the raw record and transcript, not only the generated report.

    line 46

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Terminal Agent Improvement Loop

Use this skill when improving Con as a terminal-native agent, not just fixing a one-off bug.

Primary references:

  • benchmarks/terminal-agent/README.md
  • docs/impl/terminal-agent-benchmark.md
  • docs/impl/terminal-agent-improvement-loop.md

Workflow

  1. Choose the smallest operator profile that matches the problem.
  2. Run the benchmark on an idle tab:
    • python3 benchmarks/terminal-agent/run.py --profile operator-local-codex-devloop --suite operator
    • for repeated clean iterations, prefer python3 benchmarks/terminal-agent/iterate.py ...
  3. Score the resulting run with the matching rubric:
    • python3 benchmarks/terminal-agent/score.py --profile ... --record ... --score ...
    • or ask the built-in agent to judge the raw record and transcript first: python3 benchmarks/terminal-agent/judge_llm.py --profile ... --record ... --socket /tmp/con.sock
    • then turn that judge artifact into a normal scorecard: python3 benchmarks/terminal-agent/score.py --profile ... --record ... --judge-file ...
  4. Record one short summary, a few lessons, and a few next-focus bullets in the score record.
  5. Append the scorecard to the tracked improvement log:
    • python3 benchmarks/terminal-agent/log_iteration.py --scorecard ... --change "..."
  6. Make one focused product change.
  7. Re-run the same operator profile.
  8. Generate a report when you need to inspect trend:
    • python3 benchmarks/terminal-agent/report.py

Rules

  • Use strict suites to protect the floor and operator suites to judge real workflows.
  • Prefer operator profiles that start a fresh conversation and have bounded step timeouts.
  • Prefer typed control-plane improvements over prompt-only fixes.
  • Do not overfit to a single benchmark phrase or one host layout.
  • Keep unknowns honest when the backend cannot prove more.
  • When benchmark infra changes, say whether the product improved or the measurement improved.
  • Keep iteration notes concise and comparable across runs.
  • Keep docs/impl/terminal-agent-improvement-log.md useful to a human reader; it should explain what changed, not just repeat the numeric score.
  • If you use the LLM judge, feed it the raw record and transcript, not only the generated report. The report is a summary, not primary evidence.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

Check your setup, free