agentleFS
MicrosoftKnown publishermicrosoft/amplifier-client-macos/AGENTS.md

amplifier-client-macos

AGENTS.md0 starsChanged todayMITView on GitHub

This codebase is yours: what it's for and how it's built are your call, and you'll keep building on it. Read docs/VISION.md, contracts/README.md, docs/compatibility.md and docs/contract-assessment.md before changing product behavior. Use docs/architecture.md and docs/ux-contract.md for implementation detail. Amplifier is the app; Tempo is its optional companion. Keep implemented behavior and future workspace/device capabilities clearly separated. Run meaningful core/native checks for behavioral changes and release-tool tests for packaging/publication changes. Native acceptance requires macOS; fixtures do not establish focus, notifications, signing or…

  • Where files are headingNew AGENTS.md files have more rules about keeping secrets out of the code, and fewer about code style.

    Of the AGENTS.md files we read, the 31,439 first seen in the last six months, against the older ones: the kind of rule that gained most share, and the kind that lost most. About files like this in general, not this one, and an estimate, since a kind is a pattern in the words.

The file

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

5 rules. About 0 are common, 3 are distinctive, and 2 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.

  • 2

    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. Very specific:

    Read docs/VISION.md, contracts/README.md, docs/compatibility.md and docs/contract-assessment.md before changing product behavior.

    line 5
  2. Distinctive:

    Run meaningful core/native checks for behavioral changes and release-tool tests for packaging/publication changes.

    line 10
  3. Distinctive:

    Use reserved example domains and synthetic fixtures.

    line 18
  4. Distinctive:

    Use pull requests and the canonical repository ruleset.

    line 22
  5. Very specific:

    Keep MP/MR clause IDs stable and link work to the applicable promise and observable failure.

    line 27

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

Working on Amplifier for Mac

This codebase is yours: what it's for and how it's built are your call, and you'll keep building on it.

Read docs/VISION.md, contracts/README.md, docs/compatibility.md and docs/contract-assessment.md before changing product behavior. Use docs/architecture.md and docs/ux-contract.md for implementation detail. Amplifier is the app; Tempo is its optional companion. Keep implemented behavior and future workspace/device capabilities clearly separated.

Run meaningful core/native checks for behavioral changes and release-tool tests for packaging/publication changes. Native acceptance requires macOS; fixtures do not establish focus, notifications, signing or update behavior. Use isolated, synthetic host state for integration tests. Never restart or modify a user's shared host to test this client.

This is public source. Do not include personal paths, machine names, account identifiers, private chat content, screenshots, credentials or diagnostic dumps. Use reserved example domains and synthetic fixtures. Preserve required license, security, support and artwork attribution. Commit identity may use GitHub's noreply address. Keep build outputs and signing materials outside Git.

Use pull requests and the canonical repository ruleset. Never bypass checks by weakening protection or force-pushing main. Release only through the signed workflow and its qualification gate. Clean owned temporary test resources after preserving useful nonsecret evidence; do not touch another task's resources.

Keep MP/MR clause IDs stable and link work to the applicable promise and observable failure. Shared DC/CX/CS rules stay in Unified; do not copy them into a platform contract. Record reviewed revisions, affected consumers, compatibility and evidence for shared changes. A new Windows client needs its own OS implementation and qualification; Mac results do not establish Windows parity. Keep DRAFT proposals, RATIFIED direction, implementation observations and actual release/adoption distinct.

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.