agentleFS
luckyfoxdesignluckyfoxdesign/llm-settings-template/AGENTS.md

llm-settings-template

AGENTS.md0 starsChanged 39 days agoMITView on GitHub

dev/[project-name]/ stores agent context/tasks/docs. Code repos app/, landing/, and nginx/ are gitignored; search explicit repo paths and use task paths like app/src/.... Use only the workflow requested by the user. Ordinary fixes do not require creating a backlog task. A task is done only when every Done When item has evidence; tests/build/types/analyzers and applicable gates pass; no confirmed blocker/high remains; the diff fits Change Budget; and the final implementation snapshot has a recorded review. Reuse unchanged review evidence; changed behavior…

  • Pipes a download into a shell
  • Reads credentials
  • Deletes or force-pushes
  • Commits and pushes
  • 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,700 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.

  • In this repository5 other files it gives its agents.

The file

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

7 rules. About 0 are common, 2 are distinctive, and 5 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈2

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 5

    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:

    Never run rm -rf, git push --force, git reset --hard, chmod 777, sudo rm, or curl/wget ...

    line 8
  2. Very specific:

    Never hardcode, print, or log secrets.

    line 13
  3. Distinctive:

    Use least-privilege containers: no privileged/host network, publish only required ports, prefer non-root images and maintained dependencies.

    line 15
  4. Very specific:

    Start SSH read-only (ps, logs, git log).

    line 16
  5. Very specific:

    Before deploy, run docs/runbook-prod.md checks and inspect the outgoing diff for secrets/debug leftovers.

    line 17
  6. Distinctive:

    Use only the workflow requested by the user.

    line 21
  7. Very specific:

    Read PROJECT_MAP.md before scanning.

    line 56

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

[project-name] Workspace — Agent Instructions

dev/[project-name]/ stores agent context/tasks/docs. Code repos app/, landing/, and nginx/ are gitignored; search explicit repo paths and use task paths like app/src/....

Local Permissions

  • Skip private paths entirely: .env*, key material, credential/token files, .ssh/, .aws/, .kube/, .gnupg/, .npmrc, .netrc, and auth files. Only .env.example containing placeholders is exempt. Do not follow symlinks while scanning.
  • Never run rm -rf, git push --force, git reset --hard, chmod 777, sudo rm, or curl/wget ... | bash.
  • For dangling Docker layers use only docker image prune -f --filter "dangling=true"; never prune systems/volumes or remove named volumes unless explicitly requested.

Security

  • Never hardcode, print, or log secrets. Keep them only in untracked .env; document placeholders in .env.example. Never use echo $SECRET, env, printenv, or docker compose config; validate with config --quiet.
  • Validate external input at boundaries; use parameterized queries; never interpolate user data into shell commands or HTML.
  • Use least-privilege containers: no privileged/host network, publish only required ports, prefer non-root images and maintained dependencies.
  • Start SSH read-only (ps, logs, git log). Firewall, sshd_config, TLS, users, and server .env require explicit scope. Never weaken nginx HTTPS/security/rate limits as a side effect.
  • Before deploy, run docs/runbook-prod.md checks and inspect the outgoing diff for secrets/debug leftovers.

Task Workflows

Use only the workflow requested by the user. Ordinary fixes do not require creating a backlog task.

<a id="create-task-equivalent"></a>

  • /create-task / $create-task: read the create procedure.

<a id="start-task-equivalent"></a>

  • /start-task / $start-task: read the start procedure.

<a id="review-task-equivalent"></a>

  • /review-task / $review-task: read the review procedure.

<a id="complete-task-equivalent"></a>

  • /complete-task / $complete-task: read the complete procedure.

Stop Rule

A task is done only when every Done When item has evidence; tests/build/types/analyzers and applicable gates pass; no confirmed blocker/high remains; the diff fits Change Budget; and the final implementation snapshot has a recorded review. Reuse unchanged review evidence; changed behavior or external evidence permits a focused follow-up.

Docs

Workspace docs/ is product documentation; rules live in docs/folder-rules.md; docs/wip/ is gitignored. Repo-local <repo>/docs/ is archived reference only.

Workspace Scripts

  • scripts/verify.sh — strict executable gate for workspace tasks.
  • scripts/new-task.sh, scripts/task-branch.sh, scripts/check-staged-paths.sh, scripts/new-done-record.sh — deterministic lifecycle mechanics used above.
  • scripts/build-done-index.py, scripts/build-code-index.py — generated done/code indexes.
  • Validators warn where supported; the gate is strict. scripts/check-no-flow-duplication.sh checks workflow ownership in instruction files only.

Context

Read PROJECT_MAP.md before scanning. Code runtime, dependency work, and repo gates run in Docker; workspace Python/shell helpers and Git run on the host. Respect the user's current scope and existing authorization.

LLM Memory

Auto-memory is keyed to dev/[project-name]/. Tag new facts with app, landing, nginx, or workspace unless workspace-wide.

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.