Below is my example of a well structured Readme file for a code base maintained in an organisation. The ordering isn't that important but the information is. Linking out to other things can be ok although in my experience I believe things directly related to the code should live next to the code, including documentation.
A short paragraph on what FooBar does. Be concise as possible.
Who owns FooBar or which team owns it? and/or Who knows the most about it? (link to contributors) or This code is unmaintained and looking for ownership.
Could be a badge image with last run status. Maybe even a short description of the pipeline or a link to the Pipeline as Code.
How is this code deployed to all shared environments? If this repo includes DB changes, how do we manage and deploy migrations?
What other systems does this code depend on? Diagram(s) are great here. (esp C4 model)
Link to ADRs. Helpful adr-tools.
What are the future (long and/or short term) goals of this code base? eg. Is this a monolith which we are modernising or breaking apart?
How to set up a local environment or what has to be configured correctly.
How to run the tests locally.
Are there any (prefered automated) coding standards this repo uses?
Where do I go to get non prod / staging / production Logs? Oncall Information / Who supports the running of this application? How can someone get in touch with them?
Links to other documents on standard runbooks. eg. Rolling the db password. Debugging common issues. etc.
If you want to change something in this repo, what should you do?
This can be optional but sometimes it's nice to have a list of Alumni that have participated to writing and maintaining this code base. Shows care and pride in what you do.