Our Claude Code Skills, and What Is Inside Them

We published five Claude Code skills at github.com/timerise-ai/skills. 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, marketplace payments, Polish e-invoicing.

This post covers what is actually in them, where they 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. Claude Code loads it when a task matches its description, and you can also call it directly with its slash command.

It is not a library. 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 we run in production, including the parts that only make sense once you know what went wrong the first time.

What is inside one

All five 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.

The five skills

Where they come from

A skill does not start as a blank document that somebody fills with best practices. It starts as a module in a system that is already running for a customer.

Pulling it out is an audit. We read the original code, find what is wrong with it, and write the corrected version into the skill. Every defect that audit finds goes into provenance.md, next to the rule that now prevents it.

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 is a bug somebody already paid for, and the record says which.

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 bug gets fixed once. When a project hits a defect, the fix becomes a rule in the skill instead of a commit in one repository. The next project never has that bug. Without that loop, a team quietly rebuilds the same mistakes for every client.

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 corrected version. Not a plausible module written from scratch, but the one that survived production, with the defects already engineered out.

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.

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

Clone a skill 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.

Why they are public

We do not sell the skills, 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 modules stabilise in production. Each one is listed in the index the day it is published, so watch the repository if you want to see them arrive.