Think about project instructions as a signalling exercise.
What are the things your agent needs to know in order to prevent an incident? Often times, the difference can be one stupid line, like telling your agent where the backups live, and what that means to prod.
That one line could have prevented three of the CEO vibe coding catastrophes this year. All the same problem.
Think about an AGENTS.md like coding comments, but consolidated. Not the what, the why. Once you start getting into things that can be easily inferred by the structure of your repo, you're wasting your time and tokens.
Coding standards and practices are important.
What if any evidence is required on an issue or PR.
The fact that you want fucking mermaid charts for any major design change on your feature requests, because... they're super helpful.
A skill should handle: This is a tool specific tool or practice for a situation that's outside of your distribution, and the best practice for working through it.
In both cases, try to keep them clean, legible and concise, using the fewest words possible, and the least amount of computational logic you can muster.
Saying something like, We love uncle bob on our coding team, and strictly adhere to the principles of decoupling, SOLID, and self documenting code. CRAP everything at mid tolerances to reduce cyclomatic complexity. belongs in your AGENTS.md and is much easier than spending 10,000 tokens explaining the same concepts.
That's called a pre-computed prior.
Something the machine knows, but may not know to apply to the current project or repo.
Precomputed priors are fun because a prior is a prior is a prior, regardless of the domain it comes from.
Write this app like an early Stephen King novel will produce a change in your coding and documentation style. Maybe not a good one, but you get the idea.
In fact, you can test how well a model does at generalization by evaluating whether it narrates, or produces a tangible difference in the output by doing that.
Typically, Claude and Astra will integrate that kind of thing deeply, while Grok will write in the same coding style while giving you world-class comment narration.
Grok is more entertaining, but its bias for "correctness" is a huge problem for creative thinking on coding tasks, and I worry about whether it overfits in real world situations because of that.
But the point is that you can usually stack priors across a related domain, as long as you're careful not to create ambiguity when you do it.
An example of a skill would be: This is how you use the cookie ledger API. The purpose of the tool is to track your progress in cookies and assorted treats. Here's the API spec. Here are some common pitfalls.
If your agent is using a complex phone system or interacting with an SDD tool, or anything that's bigger than a breadbox, that's when you create a skill.