Resources

Documents I actually use

Guides and reference files I wrote for my own work, published so you can use them too. No email, no signup — click and it is yours.

Everything here is licensed under CC BY 4.0

Clean Code Styleguide

How I write code: naming that needs no comment, docstrings that state the contract, same level of abstraction inside a function, and the rules I apply in review. Written for humans first, which is also why an AI agent can follow it.

Markdown (.md) · 227 lines · CC BY 4.0 · 9 KB

DownloadRead it here

Requirements Styleguide

How I write specs: one requirements folder with numbered domain files, an ID on every requirement so a plan, a PR and a test can all cite it, and a changelog rule that keeps the spec from describing something that no longer exists.

Markdown (.md) · 228 lines · CC BY 4.0 · 11 KB

DownloadRead it here

What to do with it

Both are Markdown files, so each works as a document you read and as a skill file an agent reads. Either way, drop it in place and it is done.

  1. Read it. If you only take one rule from the clean code guide, take "code is read far more often than it is written".
  2. Use it as a skill file: rename it to SKILL.md inside a folder named after the skill.
  3. Or paste it into your agent instructions and let the rules apply to every change.
mkdir -p .agents/skills/clean-code .agents/skills/requirements
mv ~/Downloads/clean-code.md .agents/skills/clean-code/SKILL.md
mv ~/Downloads/requirements.md .agents/skills/requirements/SKILL.md

Why a file instead of a blog post

  • A post is written for a reader who will not act on it. A file is written to be applied, quoted, and handed to a tool.
  • You can diff it. When I change my rules, you can see exactly what changed instead of re-reading a page.
  • It is the same text my own agents read before they touch code or a spec, so the document and the practice cannot drift apart.