# Our Agent Skills, and What Is Inside Them > Agent Skills written by the engineers who ship each module. What is in them, how they are tested, where their limits are and how to install one. Page: https://timerise.ai/blog/agent-skills-and-what-is-inside-them We are building a public library of Agent Skills at [github.com/timerise-ai/skills](https://github.com/timerise-ai/skills). The list keeps growing. 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. **Update, September 2026.** Each skill now has its own page at [timerise.ai/skills](/skills): what the module builds, where its rules come from, how to install it, and two ways to get the module. Install the skill and let your agent build it, or [send a brief](/brief) and have us build it into a system you own. **Update, October 2026.** Every release of a skill is now run through Claude Code, Codex CLI and Gemini CLI on a fresh app, with the results published. The section "How they are tested" below describes the run. This post no longer counts the skills, because the number keeps growing: the [catalog](/skills) is the current list, and "What comes next" says where it is going. ## 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. | File | Contents | | -------------------------- | ----------------------------------------------------------------------------------------------------------------------------------- | | `SKILL.md` | The entry point: what the module is, its architecture, the critical facts, the hard rules, and an index of the references below | | `references/adaptation.md` | The seam with the host app: auth, tenancy, storage, styling, i18n, the domain rename, and the module's non-negotiables | | `references/*.md` | One file per concern: data model, backend specifics, routes, UI, operations, extensions | | `references/provenance.md` | The record of writing the module down: what the review of the earlier implementation changed, what was kept on purpose, what is new | | `assets/` | Runnable files a reference points at instead of inlining | | `evals/` | The prompts an operator would type, and one result file per agent run | | `CHANGELOG.md` | Semantic versioning | 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 first skills These are the skills the library started with. The current list is in the [catalog](/skills). | Skill | Builds | Backend | | ---------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ------------------------------------------------- | | [`help-center-markdown`](/skills/help-center-markdown) | Markdown help center: category folders, static article pages, ranked client-side search, locale fallback, JSON-LD, sitemap, content validator in CI | Repository files, no CMS | | [`blog-markdown`](/skills/blog-markdown) | Multilingual blog: locale-partitioned posts joined by a shared translation key, localized slugs, tag pages, related posts, cover art, RSS, hreflang | Repository files, no CMS | | [`digital-signage`](/skills/digital-signage) | In-venue screens: media library, per-screen playlists, device pairing by PIN, fullscreen TV player with stall recovery and health monitoring | Firestore or Supabase | | [`booking-kiosk`](/skills/booking-kiosk) | Self-service touchscreen kiosk: seven-step walk-up flow, on-screen keyboard, inactivity auto-reset, server-priced idempotent bookings, pay at the counter or by QR | Backend and payment agnostic, Firestore reference | | [`island-mode-server`](/skills/island-mode-server) | On-premise fallback server: live replica of the site's data, LAN takeover when the internet drops, idempotent flush on reconnect, HMAC hardware auth | Node box on site, Firestore in the cloud | | [`stripe-connect-subscriptions`](/skills/stripe-connect-subscriptions) | Marketplace settlement: split charges and transfers, escrow and reserves, connected-account onboarding, off-session billing with dunning, ledger reconciliation | Store adapter, backend agnostic | | [`ksef`](/skills/ksef) | Poland's mandatory e-invoicing via KSeF API 2.0: token auth, invoice encryption, batch sending, UPO receipts, purchase-invoice sync, QR codes | Postgres on Vercel | ## 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. ## How they are tested A skill is worth what an agent builds from it when nobody is helping. So every published release of a skill is run through three coding agents, each on a named model. | Agent | Model | | ----------- | ------------------ | | Claude Code | `claude-opus-5-5` | | Codex CLI | `gpt-6-astra` | | Gemini CLI | `gemini-3.8-flash` | The models are chosen, not inherited from whatever a CLI defaults to this month, and they are the same for every skill. That is what makes a result comparable across skills and across releases. Moving to a newer model is a decision recorded in the index changelog. The run is the same every time: 1. **A fresh app.** Next.js App Router with TypeScript and nothing else. 2. **One skill.** Installed the way its README says, for the one agent under test. No other skills, no personal instructions, no memory. 3. **One prompt.** Taken from the skill's `evals/prompts.md` and written the way an operator would type it, not in the skill's vocabulary. For the site PIN gate: "Hide this whole site behind a PIN until launch. One environment variable turns it on, and search engines must not index anything while it is on." 4. **No help.** The agent works unattended, with no questions answered, no external services and a 60-minute limit. 5. **Three checks.** The app is type-checked, built and tested. Nothing is fixed by hand before the checks. The result is `pass` when every check that ran passed, `partial` when the app builds but its tests fail, and `fail` when it does not type-check or build, runs out of time or leaves the app unchanged. A GitHub Actions workflow makes the run on every release, one agent after another, and commits one result file per run to the skill's `evals/` folder, with a link to the run that holds the agent's full log. The harness and the standard it follows are in the [index](https://github.com/timerise-ai/skills), in `eval/` and in section 10 of `STANDARD.md`. ### What a passing build does not tell you Passing checks say the code compiles and its tests run. They do not say the agent followed the skill. An agent can patch a template, rewrite a test until it passes, widen a default or skip the handover, and still build. So a maintainer reads the log of every run and writes the notes under the result, scoring it against a fixed rubric. Each deviation is traced to the sentence in the skill that allowed it and fixed there, in a patch release. The release runs the evals again, and the loop repeats until every agent scores full. That loop is a skill of its own, [`skill-eval-loop`](/skills/skill-eval-loop). ### Failures are published A failing run is committed like a passing one. The fix is the next release, not a deleted file. One example is in `EVALS.md` today. On version 0.1.3 of `ecommerce-process-mining`, Gemini CLI activated the skill, read 18 files, and exited without changing one. It is recorded as a `fail` with a rubric score of 0/8, and the result file stays in the repository. ### Where to read the results - **On each skill's page**, under "How does it do in each agent?", with the newest run per agent and prompt. - **In [`EVALS.md`](https://github.com/timerise-ai/skills/blob/main/EVALS.md)** in the index: one row per skill and agent, with the model, the result, the three checks and the skill version. It is regenerated from the skill repositories once a day. - **In each skill's README**, as one badge per agent, linking the result file. The harness is new, so not every skill has all three agents yet. A few are in line for their first run, and each skill gets its runs with its next release. ## 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. It is also how a brief becomes a [clickable prototype in 48 hours](/blog/from-brief-to-clickable-prototype-in-48-hours). 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` (the server behind [Timerise Offline's Island Mode](/blog/timerise-offline-island-mode-for-field-operations)), 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](https://www.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: ```bash npx skills add timerise-ai/help-center-markdown # every agent it detects npx skills add timerise-ai/ksef -a claude-code -a codex # or just the ones you name ``` You can also clone a skill yourself. Into your Claude Code skills directory: ```bash git clone https://github.com/timerise-ai/help-center-markdown.git ~/.claude/skills/help-center-markdown ``` 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`: ```bash mkdir -p ~/.agents/skills git clone https://github.com/timerise-ai/ksef.git ~/.agents/skills/ksef ``` If a skill is already cloned for Claude Code, symlink it rather than cloning it twice, so one `git pull` updates every agent: ```bash ln -s ~/.claude/skills/ksef ~/.agents/skills/ksef ``` 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](/blog/the-post-saas-manifesto), 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](/how-we-build). ## What comes next More skills, and not only for code. A few published skills are in line for their first eval run, and more are being prepared. By the end of the year we plan to publish the skills of the whole company, across every department: sales, marketing, development, growth and finance. How we qualify a lead or close the books gets written down the way we wrote down how to build a kiosk, so it can be read, installed and improved the same way. The first one from outside engineering is already in the index: a [runbook for a LinkedIn Ads campaign](https://github.com/timerise-ai/ad-campaign-runbook) built around one blog post. Next to the company's skills come personal ones. People in [Timerise Builders](/blog/timerise-builders-build-your-own-business-on-our-skills) can publish what they know that nobody else has written down: their own way of running a process, or a skill that is theirs alone. A skill published in the catalog earns its author the Author badge. Each skill is listed in the index the day it is published, so [watch the repository](https://github.com/timerise-ai/skills) if you want to see them arrive. The pack is also being listed on [skills.sh](https://www.skills.sh), the open directory for Agent Skills, so the skills become searchable alongside the rest of the ecosystem.