Skip to content

Add AGENTS.md for AI-agent contributors#1157

Draft
mcfnord wants to merge 3 commits into
jamulussoftware:releasefrom
mcfnord:add-agents-md
Draft

Add AGENTS.md for AI-agent contributors#1157
mcfnord wants to merge 3 commits into
jamulussoftware:releasefrom
mcfnord:add-agents-md

Conversation

@mcfnord

@mcfnord mcfnord commented Jul 21, 2026

Copy link
Copy Markdown
Contributor

Short description of changes
Adds a top-level AGENTS.md, mirroring the pattern already in progress for the main jamulus repo (see jamulussoftware/jamulus#3793 / #3789). It points agents at the existing README workflow and Style-and-Tone guide, and adds one rule that isn't covered by either: no smart/curly quotes or apostrophes.

Rationale for that rule: a curly /“” pasted into a shell single-quoted string, JSON, a regex, or a code span is not the character the parser expects, and corrupts it silently — this is a real, machine-readable-content risk (unlike e.g. em-dash-vs-hyphen debates, which are purely a human-rendered typography/taste question with no parsing consequence in this repo's kramdown/GFM setup, so deliberately left out).

Context: Fixes an issue? Related issues
No related issue; happy to open a Discussion first if preferred.

Status of this Pull Request
Draft — proposal for discussion, not necessarily ready to merge as-is.

What is missing until this pull request can be merged?
Feedback on scope/wording; whether this should point to a Discussion instead.

Does this need translation?
NO — agent-facing repo doc, not user-facing site content (same category as README.md).

Checklist

  • I've verified that this Pull Request follows the general code principles
  • I waited some time after this Pull Request was opened and all GitHub checks completed without errors.
  • I'm sure that this Pull Request goes to the correct branch

Points agents at the existing README workflow and Style-and-Tone
guide, and adds one rule not covered by either: no smart/curly
quotes or apostrophes, since a curly character silently corrupts
shell single-quoted strings, JSON, regexes, and code spans in a way
plain ASCII never does.

🤖 Generated with Claude Code
@pljones

pljones commented Jul 21, 2026

Copy link
Copy Markdown
Contributor

I'll moan about LLM-generated unnecessary extended characters whenever I see ’em 😁... For source code — and the content of this repo is source code — the ASCII character set is complete enough to represent the entire extended display content used. We support translations via Weblate for languages that require extended character support for accurate and natural representation of text content. For structural and English content, standard ASCII should be preferred with HTML character entities where essential.

I'll moan about LLM-generated unnecessary extended characters whenever I see ’em 😁...  For source
code — and the content of this repo _is_ source code — the ASCII character set is complete enough to
represent the entire extended display content used.  We support translations via Weblate for languages that _require_
extended character support for accurate and natural representation of text content.  For structural and English content,
standard ASCII should be preferred with HTML character entities where _essential_.

Comment thread AGENTS.md Outdated

## Submit

- Target `next-release` if the change needs translation, `release` if not (README's workflow section explains which).

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Unfortunately somethimes this is not true. We probably need to clarify how it actually works...

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Any way to detect when to use one or the other?

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hard to say as it's a case by case basis. Everything on release gets published immediately and merged to next-release. Everything on next release will only get released once we open a PR, tag a release and squash it to release. Maybe let your LLM analyze the issues/PRs to find the correct pattern.

jrd added 2 commits July 23, 2026 19:07
Moves the substantive dash/hyphen/quote/ellipsis guidance into
Style-and-Tone.md (applies to all contributors, not just agents) next
to the existing Units section, which does the same kind of
micro-convention work. AGENTS.md keeps a pointer plus the one rule
that's genuinely agent-specific: check the diff for stray curly
characters near code, since that's an LLM/paste failure mode rather
than a human typing habit.

Unifies the two prior asks in this area: the original "always straight
ASCII" quotes rule (safe wherever the text could be pasted into a
shell/JSON/regex/code span) and the "use en/em dash where typography
calls for it" split from PR jamulussoftware#1159, under one principle -- machine
context stays ASCII, human-read prose gets the correct character.
Per ann0see's review comment on jamulussoftware#1157: there's no reliable file-type
rule for branch targeting. release publishes immediately and is
auto-merged into next-release by CI (.github/workflows/main.yml);
next-release only ships at the next release cutover. Point agents at
checking recent PR precedent instead of a false-confidence heuristic,
and default to the cheaper-to-correct branch when still unsure.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants