Add AGENTS.md for AI-agent contributors - #1157
Conversation
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
|
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. |
|
|
||
| ## Submit | ||
|
|
||
| - Target `next-release` if the change needs translation, `release` if not (README's workflow section explains which). |
There was a problem hiding this comment.
Unfortunately somethimes this is not true. We probably need to clarify how it actually works...
There was a problem hiding this comment.
Any way to detect when to use one or the other?
There was a problem hiding this comment.
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.
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.
Rewrite AGENTS.md around the idea that documentation is not code: the bar for a change is whether it is better than what is there now, and doc fixes ship on their own schedule rather than waiting on code work. Trim to the rules an agent cannot infer: English-source-only editing, ASCII in machine-parsed contexts, British spelling, and how to choose a branch. Voice, terminology and capitalisation are left to the Style and Tone guide rather than restated here, so there is one source of truth for each. Drop the Style-and-Tone punctuation section from this PR for now; a shorter replacement scoped to machine-parsed contexts is in progress. Written in plain ASCII throughout. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
…gents Adds the rule that actually has a failure mode: plain ASCII inside anything parsed or copied - code spans, CLI flags, URLs, frontmatter, dates, versions - where a curly quote or long dash silently corrupts a value the reader pastes elsewhere. In prose, ASCII is described as the safe default that most pages already use, without prohibiting typographic characters or requiring anyone to convert existing pages. This documents what the English source already does: of 27 files in wiki/en and contribute/en, none contains a curly character inside a code span, while 8 use curly quotes in prose - including this guide. Also states in the introduction that these guidelines cover AI-assisted contributions, which is what lets AGENTS.md point here instead of restating voice, terminology and spelling. AGENTS.md regains its pointer to the new section. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The previous wording asked whether a change should be live now, which invites an agent to reason about urgency. Merge history says the determinant is translation, not urgency: across the last 60 merged PRs (jamulussoftware#1039-jamulussoftware#1160), all 15 touching wiki/ went to next-release and none went to release, while all 6 touching _posts/ went to release. wiki/ is the only tree po4a walks, so an English edit there has to wait for the translation sprint rather than appear untranslated on a live page. State that as the rule, with next-release as the default. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
Much better. |
|
|
||
| While contributing to Jamulus or the website, you should also keep style and tone in mind. Have a look at the following guidelines. | ||
|
|
||
| These guidelines apply to every contribution, including work drafted with AI assistance. The `AGENTS.md` file in the website repository points automated contributors here rather than repeating them, so this page stays the single source of truth. |
There was a problem hiding this comment.
| These guidelines apply to every contribution, including work drafted with AI assistance. The `AGENTS.md` file in the website repository points automated contributors here rather than repeating them, so this page stays the single source of truth. | |
| These guidelines apply to every contribution, including work drafted with AI assistance. | |
| Note: The `AGENTS.md` file in the website repository points automated contributors here, so this page stays the single source of truth. |
|
|
||
| ## Punctuation | ||
|
|
||
| Content here is written for people, but parts of it are read by tools as well. Keep the two apart. |
There was a problem hiding this comment.
Do we really need this destinction?
There was a problem hiding this comment.
I don't think "Keep the two apart." is necessarily correct. I think telling people and AI tools here who the audiences are is useful - by why under "Punctuation" - it's a non sequeteur. That appropriate punctuation and layout can enable and improve reading by both audiences is probably also worth mentioning.
So maybe
| Content here is written for people, but parts of it are read by tools as well. Keep the two apart. | |
| Use of text layout, for example lists and punctuation, should aid the reader, whether a person or a tool. |
There was a problem hiding this comment.
I'm not sure our audience wants to wrap its head around machines as readers. I think we agree that the gist of this concern is that SOMETIMES we're writing for a machine, and sometimes it's a human. When I write some code that will be pasted, that's for a machine, and it has real concerns about ASCII compliance. When we're writing for an HTML publication, we need to "code switch" and make sure the paste blocks are paste-ready. And the prose around them is for humans, and I will continue advocating for their richness as compared to machine-ready content.
Notice I didn't mention AI. I'm not sure this is about AI, here. AI can handle itself on the humanist of for-humans HTML.
Content here is written for people, and sometimes those people feed parts of it into machines. I think that's the central thrust intended here. Put that way, we should hit upon the ease of doing that with aides like click-to-copy, rather than select-and-copy, along with code width concerns (which need to work for both audiences).
I also believe this depth and nuance is better said to an agent, so maybe this guidance belongs in the repo AGENTS.md. I think perhaps we can let people submit PRs that are as sloppy as they want, and then just ask an agent to clean it up by these standards. Why educate people in this dead art? (And I have 25 years of professional experience in this particular dead art!)
3 participants
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