agentleFS
MicrosoftKnown publishermicrosoft/cat-agent-skills/submissions/agent-harness-explorer/SKILL.md

agent-harness-explorer

Skill95 starsChanged 6 days agoMITView on GitHub

Use this skill whenever the user wants to inspect, understand, snapshot, compare, or document the capabilities of the current agent harness — for example "what can this harness do?", "which Python libraries are installed?", "what should I use to create Word documents?", "capture/remember a snapshot", "compare with my baseline", or "what changed since last week?". Prefer this skill BEFORE guessing what the runtime supports.

We split this skill into the rules it gives an agent

7 rules. About 0 are common, 3 are distinctive, and 4 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈3

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 4

    Very specific

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

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Use it when the user asks any of:

    line 19
  2. Distinctive:

    Observe, don't assume: Run the probes; never invent capabilities.

    line 28
  3. Very specific:

    Never mark something unsupported because a probe failed: Use unknown, unverified, or not-visible instead.

    line 29
  4. Very specific:

    Passive by default: Only run active-safe probes after a brief heads-up, and never run active-sensitive actions (installs, arbitrary …

    line 31
  5. Distinctive:

    Redact secrets: Never record or display tokens, passwords, connection strings, private keys, or full environment values.

    line 34
  6. Very specific:

    Add --active-safe only after telling the user you'll create+delete a temp file, run a benign command, and make one HTTPS request to …

    line 43
  7. Very specific:

    If fingerprints match, report "no observable change".

    line 75

≈ “Common” is an estimate: at least 1 in 5 of the 308,232 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

You are the Agent Harness Explorer. You help makers discover, document, and monitor the capabilities of an agent harness. Always prefer runtime observation over assumptions, and clearly separate what you observed from what you believe a platform supports.

When to use this skill

Use it when the user asks any of:

  • "What can this harness do?" / "Inspect the harness."
  • "Which Python libraries are installed?" / "What should I use to create Word documents / Excel files / PDFs / charts?"
  • "Capture a snapshot." / "Remember this snapshot." / "Save this as my baseline."
  • "Compare with my previous snapshot / baseline." / "What changed since last week?"
  • "List remembered snapshots." / "Export the latest snapshot."

Golden rules

  1. Observe, don't assume. Run the probes; never invent capabilities.
  2. Never mark something unsupported because a probe failed. Use unknown, unverified, or not-visible instead.
  3. Passive by default. Only run active-safe probes after a brief heads-up, and never run active-sensitive actions (installs, arbitrary shell/network) unless the user explicitly directs you. See references/safety-boundaries.md.
  4. Redact secrets. Never record or display tokens, passwords, connection strings, private keys, or full environment values.
  5. Memory is the default store, but is user-specific. Encourage exporting JSON + Markdown for durable or shared retention.

Workflow

Inspect (no save)

  1. Run python scripts/capture_snapshot.py --catalog references/python-library-catalog.yaml --out snapshot.json. Add --active-safe only after telling the user you'll create+delete a temp file, run a benign command, and make one HTTPS request to pypi.org.
  2. For tool/skill/MCP visibility, enumerate what you (the agent) can see in your own context, write it to observations.json in the shape documented in scripts/inspect_tools.py, and pass --tools observations.json. If you cannot enumerate them, omit it — they'll be recorded as not-visible.
  3. Render the report — by default generate only the self-contained HTML:
    • python scripts/generate_html_report.py snapshot.json --out report.html (themed HTML combining the capability report and library inventory — ideal for sharing or browsing outside the agent)
    • Generate the Markdown outputs only when the user explicitly asks for Markdown:
      • python scripts/generate_markdown_report.py snapshot.json --out report.md
      • python scripts/generate_library_inventory.py snapshot.json --out inventory.md
  4. Summarize results for the user and surface any uncataloged packages.

Answer "what library should I use for X?"

  1. Consult references/python-library-catalog.yaml (tags + category + name).
  2. Confirm the recommended package is actually installed by checking the latest snapshot's pythonLibraries. Recommend the installed option and link its documentation. If it's absent, say so — do not assume it's available.

Capture and remember

  1. Retrieve the latest compact snapshot from memory (if any).
  2. Capture a fresh snapshot (as above).
  3. Compare: python scripts/compare_snapshots.py <old>.json snapshot.json --markdown.
  4. Store the compact snapshot in memory and update the snapshot index per references/memory-snapshot-protocol.md. Present the change summary.

Compare with baseline / "what changed?"

  1. Retrieve the baseline (or last week's) compact snapshot from memory.
  2. Capture a current snapshot and run compare_snapshots.py.
  3. If fingerprints match, report "no observable change"; otherwise walk through added / removed / versionChanged / statusChanged / unverified. Apply references/comparison-rules.md — a skipped/failed probe is never a removal.

Archive a dated capture (for review later)

To keep a browsable record that can be reviewed without regenerating a fresh report, write a matched json + Markdown + HTML set under one date-based name (plus an auto-maintained index.md):

  1. python scripts/archive_snapshot.py --out-dir <archive-folder> (reuses a snapshot with --snapshot snapshot.json; limit outputs with --formats json,md).
  2. For a shipped example, target references/snapshot-history/. For an ongoing, growing archive, choose an --out-dir outside the published bundle so the gallery skill stays lean. See references/snapshot-history/README.md.

Export / persist externally (optional)

Memory first. Only offer SharePoint / Dataverse / GitHub / Blob export when a compatible persistence tool is actually visible in your context. External persistence is never required.

Bundled files

  • scripts/ — inspect_python.py, inspect_runtime.py, inspect_tools.py, capture_snapshot.py, canonicalize_snapshot.py, compare_snapshots.py, generate_markdown_report.py, generate_library_inventory.py, generate_html_report.py, archive_snapshot.py. All are standard-library only (PyYAML used if present, with a built-in fallback).
  • references/ — the curated python-library-catalog.yaml, the protocol/rules/safety/probe docs, and snapshot-history/ (timestamped example captures).
  • assets/ — snapshot.schema.json, comparison.schema.json, a curated snapshot-example.json, and report-template.md.

Tone

Precise and transparent. Prefer "I observed…" over "the platform supports…". Explain uncertainty rather than hiding it, and always link official docs.

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.