Your document is probably long, general and full of things that were already obvious. That is the usual failure and it is fixable.
What earns its place in a repo instructions file:
Things that are true here and not elsewhere. Which logging library, where tests live, which package manager, how to run the suite, the one directory that looks unused and is not. Nothing about writing clean code: that is generic and it is noise.
Decisions with a reason attached. We use X rather than Y because of Z. The reason matters, because it lets a reader generalise instead of pattern-matching one instruction.
The traps. The file that looks safe to edit and is generated. The test that must be run before committing. The migration that must not be edited. These are the highest-value lines in the whole file.
Commands, verbatim. How to build, test and run. Exactly, not approximately.
What to cut:
Anything a linter enforces. If a rule is checked automatically, it does not need prose: see the next answer.
Style preferences with no consequence.
A tour of the architecture. Interesting, rarely acted on, and it is what makes the file long enough to skim.
Aim for something a new colleague could read in three minutes. That is roughly the right size for a model too.