For Claude Code you can maybe save context by putting the commit message formatting in a skill, so only the front matter goes into context at startup and the details only when the skill fires.
My agent.md to improve LLM-assisted code quality
181–190 of 200 posts
Re: My agent.md to improve LLM-assisted code quality
#182A bunch of these should be enforce with linting, that way people who still hand-craft code get the same kind of feedback, e.g. Always use {}, even on a one-line "if" statement. & Keep function names short. Less than 30 characters. Then this one really is a pattern that creates a lot of churn: - Add a small, to the point, comment to explain what the block does and why . Use examples when possible. Propose ASCII drawin…
The cost of custom linters has like any other code dropped through the floor. I'm sprinkling all kinds of linters over my latest projects. It seems some people are still sleeping on this, expecting great code from the agents. They're fast and deterministic and I run them in git pre-commit.
> They're fast and deterministic and I run them in git pre-commit.
Isnt that too late? I would want the agent to stumble into this as early as possible in the agentic loop, eg at the same time as compiler.
Re: My agent.md to improve LLM-assisted code quality
#183Just this one line in AGENTS.md has given better results to reduce if not eliminate verbosity and grandeur. **Always use ASD-STE100 Simplified Technical English Disclaimer: I saw this listed in some other HN post that I can' locate right away.
This will produce quite verbose prose. STE100 is good for specs and explanations but it works best with a glossary or terms. will burn tokens.
This has not been my experience at all. I have been using this skill[0] for several weeks and when I ask it to rewrite existing AI slop docstrings to use this convention they are nearly always 10-20% smaller, plus easier to read and mostly free from the traditional "tells" of AI writing.
Re: My agent.md to improve LLM-assisted code quality
#184These I especially like:
>"- Avoid superlatives and praise. Stop telling me I am absolutely right. Give me the cold hard truth."
>"Rule 5: Use the imperative mood in the subject line (e.g., "Fix bug," "Add feature," not "Fixed" or "Adds"). Test formula: It must complete the sentence: "If applied, this commit will [your subject line here]".
>"- Strictly adhere to the layered boundary hierarchy: each layer may only communicate with its immediate neighbor directly below it. Never "punch holes" through layers (e.g., controllers or UI components must never directly call database queries, raw hardware drivers, or low-level network clients; always route through the intermediate service/abstraction layer)"
Not crossing hierarchical/abstraction layers is very important for truly disciplined Software Engineering... at least in all Object-Oriented programming languages / languages that support Encapsulation, and possibly other languages/paradigms as well...
Anyway, lots of good things in this prompt!
Re: My agent.md to improve LLM-assisted code quality
#185Just this one line in AGENTS.md has given better results to reduce if not eliminate verbosity and grandeur. **Always use ASD-STE100 Simplified Technical English Disclaimer: I saw this listed in some other HN post that I can' locate right away.
This is probably the skill you remembered: https://github.com/AminBlg/SimpleEnglish
I have been using it for a few weeks, and it significantly improves the quality of the docstrings and code comments, as well as the readability of spec docs.
I have also added a few key bullet points to my AGENTS.md and have found the results to be very effective and generating plans and code that looks like something I would have written:
-----------
## planning, design and spec docs
- the highest design goal is simplicity -- in our systems and our mental model -- even if if means edge cases are unaddressed and could potentially fail
- please practice "ya ain't gunna need it" (YAGNI) do not add unnecessary guardrails
- do not plan to add caching, many layers of unnecessary abstraction or other premature optimizations
- look for places where adding or clarifying an invariant would simplify the code or the overall system
please specifically try to avoid:
- redundant calculations or duplicated work
- duplicated conditionals or state-machine logic
- storing state that can be derived from other state, which could drift and become out of sync over time
- leaky abstractions across layers of the application
- multi-line comments explaining a variable name or a single statement. well chosen names and design should makes these unnecessary, as the code is self-documentingRe: My agent.md to improve LLM-assisted code quality
#186Earlier quoted context omitted.
I've come recently across arxiv 2604.20911 which claims "do" rules persist much better then "don't" rules.
Alright, what you'd put instead of "Don't add any code comments anywhere"? I agree with the general guidance, but it's a general one and not applicable for everything. Some things cannot be expressed in a "do" way rather than "don't".
"Do write comment-less code" ?
Re: My agent.md to improve LLM-assisted code quality
#187Earlier quoted context omitted.
I forbid my agents from adding any comments. I review the code and add comments manually. If I can't understand something despite having the context then I throw away the code instead of having an LLM generate comments to explain what it did. This way the code stays readable/debuggable by humans.
How do you stop LLMs from making comments? In my experience, LLMs treat requirements for code output as suggestions
In my experience, Claude adds loads of comments, but Codex (GPT-5.5) never adds any.
Re: My agent.md to improve LLM-assisted code quality
#188[flagged]
Re: My agent.md to improve LLM-assisted code quality
#189Earlier quoted context omitted.
If you don’t trust the code to write a decent comment, why trust it write good code? Of course, ensuring compilation or other checks can verify some code, which it can’t do for comments. But comments still serve the same purpose as human comments.
If I understand correctly, it’s not that the LLM can’t write a good comment, it’s that you want to be able to interpret and understand the generated code without comments - and in that process end up writing comments yourself.
I don’t get that argument. Most of the time by the end of the session the comments from the agent encode tricky details that I told the agent to write down so it stops making “simplifying” assumptions. Thus comments at the end of a couple days of agent-only coding, when I start to actually read and edit the prose, contain the details which aren’t possible to know from reading the local code. It may help that my last couple sessions before I start reading the code myself are variations on telling the agent to self-review and improve the comments in specific ways, so the comments left are only those the agent thought remain meaningful at clarifying unexpected interactions between the local code and other code that needs to be referenced to understand it.
Re: My agent.md to improve LLM-assisted code quality
#190Has anyone had success telling a LLM to essentially code golf, with the compromise that names should still be descriptive (so no hard minification).
The idea is to first make the code less verbose, LLMs tend to do that. But the other idea is to save tokens. I.e. make it easy for the LLM, not for a human reader.
And when it is time for a human to actually read the code, if it is too much, as a second pass, transform the code to make it more readable while keeping the structure.