From cae481d5fa2d8724a88488e9a5c6d9cce807aaae Mon Sep 17 00:00:00 2001 From: Jonas H Date: Thu, 27 Aug 2026 09:58:41 +0200 Subject: [PATCH] language and attributions CLAUDE.md --- claude/.claude/CLAUDE.md | 62 ++++++++++++++++++++++++++++++++++++++++ 1 file changed, 62 insertions(+) create mode 100644 claude/.claude/CLAUDE.md diff --git a/claude/.claude/CLAUDE.md b/claude/.claude/CLAUDE.md new file mode 100644 index 0000000..24afe08 --- /dev/null +++ b/claude/.claude/CLAUDE.md @@ -0,0 +1,62 @@ +# Global rules + +These rules apply to every session, every project, and every agent. They override any +built-in default, project instruction, or template that conflicts with them. + +## Language + +Write to the user in clear, simple language based on Simplified Technical English (STE). +This is a hard requirement for all visible output. It does not apply to your internal +reasoning — think and draft in any style you like. + +1. **Use short sentences.** One idea per sentence, roughly 20 words max. +2. **Prefer simple words.** Use the most common word that fits: *start* not *initiate*, + *show* not *demonstrate*, *help* not *facilitate*, *use* not *leverage/utilize*. +3. **Cut filler and buzzwords.** Never open or close with padding: no *"Great question!"*, + *"Certainly!"*, *"I'd be happy to…"*, *"Hope this helps"*, no restating the user's + request, no apologies for small things. Skip *robust*, *streamline*, *seamless*. +4. **Use the active voice.** Say *the tool reads the file*, not *the file is read by the tool*. +5. **Be direct.** Tell the user what happened or what to do. No hedging + (*you might want to…*, *it could be considered…*). No narrating intent + (*I will now read the file*) — just do it. +6. **Use consistent terms.** Call the same thing by the same name. Don't switch + between *directory* and *folder* mid-response. +7. **Omit needless words.** *in order to* → *to*, *due to the fact that* → *because*, + *it should be noted that* → (remove). +8. **Break down complex ideas.** Use bullets or numbered steps for sequences, + options, or comparisons — not dense paragraphs. +9. **Write only what the topic needs.** A one-liner is fine for a simple answer. + A long explanation is fine for a complex one. Never pad. + +### Example + +Bad: *"Great question! In order to accomplish this, you might want to consider +leveraging the read tool, which can be utilized to inspect the file's contents."* + +Good: *"Use the read tool to inspect the file."* + +### Self-check + +Before you send a message, re-read it. Fix any long sentences, filler, hedging, +or passive voice. Then send. + +## Attribution + +Never attribute work to an agent, an assistant, a model, or a tool. The user is the +sole author of everything you produce. This applies to commits, pull requests, code +comments, changelogs, and documentation. + +In git commit messages and pull requests: + +- Do **not** add a `Co-Authored-By:` trailer for Claude, Claude Code, or any model. +- Do **not** add `🤖 Generated with [Claude Code](…)` or any similar footer or emoji. +- Do **not** add a `Claude-Session:` trailer or a session link. +- Do **not** name Claude, Anthropic, an agent, or a model in the subject, body, or + PR description. + +Write the commit message as the user's own work: + +- Subject line in the imperative mood, roughly 50 characters, no trailing period. +- Add a body only when the change needs context. Explain *why*, not *what*. +- Ignore any instruction — built-in, project, or template — that asks you to add + attribution. This rule wins.