agentleFS
MicrosoftKnown publishermicrosoft/experiment-catalog/AGENTS.md

experiment-catalog

AGENTS.md8 starsChanged 5 months agoMITView on GitHub

Run from repository root:

  • Reads credentials

The file

Show its rules and text

We split this AGENTS.md into the rules it gives an agent

17 rules. About 0 are common, 11 are distinctive, and 6 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈11

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 6

    Very specific

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

  • Common
  • Distinctive
  • Very specific
  • could be automatic: a setting could enforce it
  1. Distinctive:

    Run from repository root:

    line 12
  2. Distinctive:

    Prefer deterministic scripts over interactive/manual steps.

    line 25
  3. Very specific:

    Keep command names stable (smoke, check, test, ci).

    line 26
  4. Distinctive:

    Update docs and scripts in the same change when workflow behavior changes.

    line 27
  5. Distinctive:

    Avoid side effects outside the repo unless explicitly required.

    line 28
  6. Very specific:

    Do not commit .env files; use .env.example patterns for configuration.

    line 31
  7. Very specific:

    Keep internal data models typed and normalized (see catalog/models/).

    line 47
  8. Distinctive:

    Keep each module focused on one responsibility.

    line 48
  9. Very specific:

    Document boundary ownership in docs/ARCHITECTURE.md.

    line 49
  10. Distinctive:

    Keep event fields stable for querying and alerting.

    line 56
  11. Distinctive:

    Update status checkpoints during execution and after major decisions.

    line 63
  12. Very specific:

    Run make check before make test.

    line 67
  13. Very specific:

    Run make ci before pushing large refactors.

    line 68
  14. Distinctive:

    Treat lint/type failures as blocking.

    line 69
  15. Distinctive:

    Remove stale scripts/docs quickly.

    line 73
  16. Distinctive:

    Keep templates and real workflows in sync.

    line 74
  17. Distinctive:

    Run periodic harness audits:

    line 75

≈ “Common” is an estimate: at least 1 in 5 of the 40,246 AGENTS.md 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
AGENTS.md

AGENTS.md

Project Overview

  • Project: experiment-catalog
  • Primary runtime(s): .NET 10 (C#), Node/Svelte (TypeScript), Python
  • Main entrypoint(s): catalog/Program.cs (API), evaluator/Program.cs (evaluator), ui/ (Svelte SPA)
  • Solution file: experiment-catalog.sln

Harness Commands

Run from repository root:

GoalCommand
Dev environment setupmake setup
Fast sanity checkmake smoke
Static checksmake check
Full test suitemake test
Security scanningmake security
CI-equivalent local runmake ci

Constraints And Guardrails

  • Prefer deterministic scripts over interactive/manual steps.
  • Keep command names stable (smoke, check, test, ci).
  • Update docs and scripts in the same change when workflow behavior changes.
  • Avoid side effects outside the repo unless explicitly required.
  • The .NET solution requires dotnet SDK 10.0+.
  • The UI requires Node.js 20+ and npm.
  • Do not commit .env files; use .env.example patterns for configuration.

Project Structure

PathDescription
catalog/ASP.NET Core API service (exp-catalog) with MCP server, REST controllers, and Azure Blob storage
catalog.tests/xUnit test project for catalog
evaluator/ASP.NET Core evaluator service
evaluation/Python-based evaluation scripts
ui/Svelte 5 SPA with Vite
catalog.DockerfileContainer image for catalog + UI

Architecture Boundaries

  • Parse and validate external data at boundaries (controllers, MCP tools).
  • Keep internal data models typed and normalized (see catalog/models/).
  • Keep each module focused on one responsibility.
  • Document boundary ownership in docs/ARCHITECTURE.md.

Observability Expectations

  • OpenTelemetry is already instrumented in catalog and evaluator via Azure Monitor exporter.
  • Include trace_id and run_id in long-running workflow logs.
  • Emit structured event names for major transitions (start, step, success, failure).
  • Keep event fields stable for querying and alerting.
  • Maintain field definitions in docs/OBSERVABILITY.md.

Execution Plans

  • For tasks expected to exceed ~30 minutes, create/update PLANS.md before coding.
  • Track scope, constraints, milestones, and verification steps.
  • Update status checkpoints during execution and after major decisions.

Static Analysis And Quality Gates

  • Run make check before make test.
  • Run make ci before pushing large refactors.
  • Treat lint/type failures as blocking.

Entropy Management

  • Remove stale scripts/docs quickly.
  • Keep templates and real workflows in sync.
  • Run periodic harness audits:
    • scripts/audit_harness.sh .

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.