TL;DR
- Developers in an Ask HN discussion describe both project-local instructions and shared libraries of repeatable agent workflows.
- Their approaches include repositories, symlinks, Claude plugins, human review and behavioural tests.
- Match the arrangement to the work: keep project facts close to the project and give shared procedures a maintained source and update path.
- The examples are contributors’ own accounts. Tests and documentation checks need to cover the dependencies the procedure actually uses.
In plain English
A skill is a reusable procedure an agent can load for a task, often written in Markdown and sometimes accompanied by scripts.
Frontmatter is the short metadata block at the top of a file. It can help a tool identify relevant instructions before loading the whole procedure.
A symlink points to another file or directory, letting several tools use one maintained copy.
An eval tests behaviour on a defined task. A pull request proposes a change for review before it becomes part of the maintained version.
An Ask HN discussion about managing skills files gives a useful picture of how developers are using them. Some keep project instructions in a README or AGENTS.md. Others maintain shared libraries of procedures, distribute them across coding tools and test the behaviour they are meant to produce.
The difference often starts with what the instruction is for. WatchDog describes putting project and environment information in the repository’s documentation. That suits information the agent should already have while working on the project, such as which framework or conventions it uses.
A repeatable procedure can have a different shape. It may describe how to use a particular tool, produce a report or carry out a workflow spanning several systems. Keeping that procedure as a skill gives it a place to be maintained and a way to load it when the task calls for it.
alexhans describes creating skills, keeping them in software repositories and making them available across coding tools through symlinks. Short metadata at the top lets a tool identify a relevant skill before loading the full instructions. The same maintained procedure can then be available in more than one working environment.
The source of a useful skill can be a task the agent has just completed. sinuhe69 describes asking an agent to distil the knowledge from a difficult problem into a skill file, then reviewing it before publishing it. That gives the next run a starting point shaped by the work and the corrections made along the way.
Testing is part of the approach too. alexhans describes evals as checks that their own use cases continue to work, using ordinary assertions where possible. A test might check an expected result or whether a particular action succeeded. That is a more useful way to assess a procedure than judging how polished its instructions sound.
Keeping the library current is a separate job from creating it. theletterf describes a workflow that compares skills against documentation every two weeks and opens pull requests when the contents have drifted. Their repository is also a Claude plugin, and they describe a tool for keeping users’ installed copies up to date across coding tools.
That covers two maintenance needs: someone must correct the shared procedure, and those corrections must reach the places it is used. A single source helps with the first; distribution and version tracking help with the second.
The sceptical replies are useful alongside these examples. avaer questions the value of downloading large collections and suggests that useful skills can be developer macros shared within a team. The practical accounts describe exactly that sort of specificity: procedures for a person or team, changed when a real problem appears and checked against the work they support.
For a small set of project instructions, the existing documentation may be enough. For a shared workflow, I would want one maintained source, a clear way to install updates and a test that checks the result. If the procedure depends on a current path or an external interface, include that dependency in the check; a frozen expected answer can retain the same old assumption as the instructions.
The thread’s useful contribution is the working detail. Skills can preserve a procedure across tasks and tools, while repositories, reviews and tests provide familiar ways to maintain it. Start with work you actually repeat, keep the procedure findable, and make its result something you can check.