agentleFS
LambdaTestLambdaTest/rook/.agents/skills/rook/SKILL.md

rook

Skill80 starsChanged 19 days agoApache-2.0View on GitHub

Use rook to test, evaluate, red-team or regression-check an AI agent the user owns, or to interpret saved Rook results. Does not apply to ordinary unit tests, browser automation or web UI checks without an AI agent under test.

1 other project uses a version of this.

Adopted by

Most recently taken up by

  • Other versions1 project uses a version of this.

    Word for word · 0

    None found.

    Edited · 0

    None found.

    Wrote their own version · 1

    1. sector137/crew★ 0same name

    How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.

  • In this repositoryOne other file it gives its agents.

The file

Show its rules and text

We split this skill into the rules it gives an agent

14 rules. About 0 are common, 6 are distinctive, and 8 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈6

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 8

    Very specific

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

  • Common
  • Distinctive
  • Very specific
  1. Very specific:

    Use Rook to derive scenarios, invoke the target and grade the evidence.

    line 10
  2. Very specific:

    Do not read the target's code to describe the agent, or write your own test plan or verdicts, in its place.

    line 20
  3. Very specific:

    Check rook --version and use rook help <command> for the installed CLI's options.

    line 29
  4. Distinctive:

    Use this workflow across compatible releases.

    line 32
  5. Distinctive:

    Use the next command needed by the current state:

    line 44
  6. Very specific:

    Use rook help <command> for flags and scenarios to scope a run with --only, classes, categories or tags.

    line 59
  7. Very specific:

    Before profile add, profile fix, profile test or run, inspect the target's agent.yaml for calls[] entries with write: true.

    line 66
  8. Very specific:

    Verify effects through read-only interfaces.

    line 70
  9. Distinctive:

    Use paid RCA only with user authorization.

    line 76
  10. Very specific:

    Prefer scoped --allow grants.

    line 85
  11. Very specific:

    Check the exit status and discarded/halted fields before claiming completion.

    line 91
  12. Distinctive:

    Read the report by this invocation's run ID, not an old default report.

    line 94
  13. Distinctive:

    Follow verdicts: show Pass, Fail and Unable to Verify separately, quote criterion evidence, identify gaps and compare prior runs only when …

    line 96
  14. Distinctive:

    Verify separately, quote criterion evidence, identify gaps and compare prior runs only when their evidence is available.

    line 97

≈ “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

Test agents with Rook

Use Rook to derive scenarios, invoke the target and grade the evidence. Respect requests to use another tool. For saved-result requests, read the supplied files without starting setup, a new run or paid analysis.

Your role

You are the orchestrator: you choose and run Rook commands, and Rook does the testing work. Discovery is rook explore, test design is rook generate, and invocation and grading are rook run and rook report. When the user asks to explore, understand, plan tests for or test an agent, run the matching command. Do not read the target's code to describe the agent, or write your own test plan or verdicts, in its place. Answer from Rook's agents, scenarios and verdicts. Read the target's source only for a step Rook needs from you, such as a profile's transport and command, or to explain a Rook result. If credits or authorization block the next command, name it and what it needs; manual analysis is not a substitute.

Setup and execution

Check rook --version and use rook help <command> for the installed CLI's options. If Rook is missing, use the installation instructions. Use this workflow across compatible releases; a different version alone is not a reason to stop or change the installation. If a command or output differs, consult its help and release notes before adapting that step. Keep completion and evidence checks intact; do not guess missing fields or retry paid work to probe compatibility. Installation changes still require authorization.

rook doctor
rook status --json
rook plan --json

Use the next command needed by the current state:

NeedCommand
Sign inrook login; in CI, export LT_USERNAME and LT_ACCESS_KEY (no login step)
Select a projectrook project use <id> or rook project create <name>
Discover agentsrook explore . --json
Select an agentrook agent use <id>
Generate scenariosrook generate --json
Create/test a profilerook profile add <name> --from <file> or --command '<argv>'; then rook profile test --goal "<reply-only goal>"
Runrook sync --yes before rook run --json, or rook run --test --json for a local result
Read resultsrook report <run-id> --json

Choose the profile's transport and command from the target's source or the user's invocation details; ask when unknown. See profiles. Use rook help <command> for flags and scenarios to scope a run with --only, classes, categories or tags. When an agent has more than one profile, check the active profile with rook profile or pass rook run --profile <id> to select the intended target.

Authorization and credits

Before profile add, profile fix, profile test or run, inspect the target's agent.yaml for calls[] entries with write: true. Those commands can reach the real agent. Use staging and obtain any missing authorization for its effects; Rook cannot undo them; do not rely on a per-target headless confirmation. Verify effects through read-only interfaces; inspect available read tools before concluding that an effect is unverifiable. Keep secrets as ${VAR} references through rook env set, outside profiles and transcripts.

Announce spending before explore, generate, run, profile add|fix, ask and run|report --rca. profile test invokes the target without Rook model credits. Use paid RCA only with user authorization. Track the user's budget across commands; do not assume the CLI enforces an aggregate task cap. Check its help for available limits. A null balance means unknown. Rook checks the organisation's Agent Assurance plan before any model call or credit spend, whatever the balance. A plan_required or upgrade_plan refusal names the page that lifts it (billing, or onboarding to start a free trial); pass that link to the user instead of retrying. A plan without Rook cloud runs locally: when sync or cloud status is refused, use rook run --test for a local result. See troubleshooting. Prefer scoped --allow grants; use --yes only within the authorized scope. See headless contracts for output, grants and credit accounting.

Report the evidence

Check the exit status and discarded/halted fields before claiming completion. A finished run exits 0 even when scenarios fail; ok: true can also describe a refused run. Parse JSON only when a document exists, otherwise use stderr. Read the report by this invocation's run ID, not an old default report.

Follow verdicts: show Pass, Fail and Unable to Verify separately, quote criterion evidence, identify gaps and compare prior runs only when their evidence is available. Preserve incomplete results and unknown metadata; do not invent evidence or replace Rook's verdict with your own reading of the agent reply.

References

  • CI: complete pipeline and verdict gating.
  • MCP: server discovery, approval and configuration.
  • Troubleshooting: setup failures and version-specific verification limitations.
  • Headless contracts: JSON shapes and saved-file locations.

Project evidence lives under .testmuai/rook/. Credentials and session state live under ~/.testmuai/rook/; do not commit that home directory.

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.