Our Agent Skills, and What Is Inside Them

We are building a public library of Agent Skills at github.com/timerise-ai/skills. Seven of them are out so far. Each one is a separate repository that teaches a coding agent to build a single module: a help center, a multilingual blog, in-venue screens, a self-service kiosk, an on-premise fallback server, marketplace payments, Polish e-invoicing. Agent Skills is an open format, so the same folder works in Claude Code, Codex CLI, Gemini CLI and the other agents that read skills.

This post covers what is actually in them, where the rules inside them come from and where their limits are. If you only want to install one, the commands are at the bottom.

What a skill is

A skill is a folder of markdown that an agent reads before it writes code. The agent loads it when a task matches its description, and you can also call it directly. Nothing in it is tied to one vendor. SKILL.md declares a name and a description, everything below it is plain markdown about Next.js, Postgres, Firestore or a vendor's API, and no file calls a model.

It is not a package. Nothing gets installed into your app, and there is no dependency to track or license. The agent reads the skill and writes the module into your repository, in your stack, with your auth, your naming and your design system.

The practical difference is narrow but real. Without the skill, an agent writes a help center that looks right. With the skill, it writes the one our engineers build, including the parts that only make sense once you know what went wrong the first time.

What is inside one

They all share the same layout, so an agent that has read one knows how to read the next.

Only SKILL.md is read up front. The references load on demand, so a task about device pairing does not drag the billing chapter into the context window.

Every skill is versioned on its own line under one release standard: a vX.Y.Z tag, a Keep a Changelog entry and a GitHub release carrying it. The index spells that standard out in STANDARD.md, together with the layout and the writing rules any new skill has to meet.

The skills so far

Where they come from

A skill does not start as a blank document that somebody fills with best practices. It starts with an engineer on our team who has built the same module several times and knows how it has to behave.

Writing it down is a review of its own. The engineer goes back over the earlier implementation they shipped, writes the module the way they would build it today, and states every property it has to hold as something the templates and the tests verify. What that review changed, what was kept on purpose and what is new goes into provenance.md.

None of it is synthetic. No skill was generated by a model from a prompt, and none of them carries code from a customer's project.

That is why some rules look oddly specific. Hash the per-device token before you store it. Send a search summary to the browser, never the whole corpus. Bind an invoice's seller NIP to the authenticating taxpayer. None of those are style preferences. Each one comes from a real deployment, and the record says which one.

Each skill also names a short list of non-negotiables: the rules that travel with the module into any project. Everything else is adaptable, and the skill says which is which.

What they give you

A lesson gets written down once. When a project teaches us something, it becomes a rule in the skill instead of a commit in one repository. Everything we build after that starts with it. Without that loop, the same ground gets covered again on every project.

The module is documented before it is written. The skill is the documentation. When we hand a project over, the developers taking it on get the reasoning behind the code, not only the code.

Less of an estimate is guesswork. A large share of a booking system is work we have already done, in a form the agent can reproduce. What is left to estimate is the logic that actually differs between projects, which is also where the interesting engineering is.

Reviews get shorter. Reviewing generated code is easier when the rules it was meant to follow are written down. Instead of arguing about whether an approach is sound, you check it against a list.

You can read the parts before you commit. The index is public and so is every skill in it. What a Timerise system is made of is inspectable up front, without having to ask us for it.

Installed on your own, a skill gives you the reviewed version. Not a plausible module written from scratch, but the way an engineer who has shipped it many times builds it, with the corrections already in.

What they will not do

Worth knowing before you clone one.

They assume Next.js App Router. The data model and the operational rules travel anywhere. The routing and rendering chapters do not. The exception is island-mode-server, which builds a Node box that sits next to the app rather than inside it.

They are instructions, not a package. Once the agent has written the module, the code is yours. There is no version inside your app to bump, and a later git pull in the skill directory improves the next thing you build, not the thing you already built.

You still review the output. A skill narrows the space of wrong answers a long way. It does not remove the review, and it does not turn a coding agent into an engineer.

You pick the backend. The data layer sits behind an explicit seam, with Firestore, Supabase/Postgres and a custom store adapter described side by side. Choosing and adapting one is your call, not the skill's.

ksef is the odd one out. It wraps someone else's API rather than a UI module, so it starts from the Ministry of Finance specification corrected against field reports, and its record of corrections is the changelog rather than provenance.md.

Installing one

The shortest way is the skills.sh CLI. It resolves the GitHub repository directly and writes the skill into whichever agents you name, with no manual clone and no per-agent path to remember:

You can also clone a skill yourself. Into your Claude Code skills directory:

To scope it to a single project instead, clone it into that project's .claude/skills/ directory. The skill activates on its own when a task matches it, or you can invoke it with its slash command: /help-center-markdown. Update it with git pull in its directory, and read its CHANGELOG.md to see what moved.

Codex CLI, Gemini CLI and other agents

Codex CLI and Gemini CLI read the same layout, including the on-demand loading of references/ that keeps a long skill affordable. Both discover skills in ~/.agents/skills:

If a skill is already cloned for Claude Code, symlink it rather than cloning it twice, so one git pull updates every agent:

Invocation differs: $ksef in Codex, /skills in Gemini CLI. Two things also do not travel on their own. Each host matches a task against a description its own way, so invoke a skill explicitly on a first run instead of assuming it fired. And the non-negotiables in references/adaptation.md are where models diverge most, so check that the ones that matter for your module survived the build.

Why they are public

We do not sell the skills, they are MIT licensed, and none of them contains anything specific to a customer.

Our customers own the code they receive, so it seemed right that the parts it is assembled from are readable without having to ask. Beyond that, a module is more useful shared than kept. Every improvement a project makes goes back into the skill, and that same repository is what anyone else installs.

We wrote about the rest of how we work in How we build.

What comes next

More skills, added as our engineers write down the modules they have shipped. Each one is listed in the index the day it is published, so watch the repository if you want to see them arrive. The pack is also being listed on skills.sh, the open directory for Agent Skills, so the skills become searchable alongside the rest of the ecosystem.