Partner program
Bring clients to us and get paid for every one.
Roles
{ROLES.map((role) => (
-
{role.name}: {role.body}
))}
FAQ
{FAQ.map((item) => (
{item.q}
{item.a}
))}
Apply to the program
);
}
- Our chatbot keeps telling visitors the Pro plan costs 49 EUR, but the pricing page says 79. Fix it so the two cannot drift apart again.
- Last month we renamed /pricing to /plans and added a catalog with a page per integration. Check whether our site assistant still sends people to the right places and tell me what you would change; do not edit anything yet.
Agent eval results (newest per agent and prompt):
- Gemini CLI (gemini-3.8-flash) on v0.1.2, 2026-10-08: pass (No data store)
- Codex CLI (gpt-6.1-sol) on v0.1.2, 2026-10-08: pass (No data store)
- Claude Code (claude-opus-5-5) on v0.1.2, 2026-10-08: pass (No data store)
Recent releases:
- v0.1.2 (2026-10-08): Fix release, from scoring the second round of prompt-1 agent eval runs against 0.1.1.
- v0.1.1 (2026-10-08): Fix release, from scoring the prompt-1 agent eval runs against 0.1.0.
- v0.1.0 (2026-10-08): First release: a procedure for teaching a Next.js site's AI chat assistant a new page, program or catalog from the repository's own content, verified by unit tests, a render check and regex probes.
---
## ad-campaign-runbook (Agent Skill)
> A LinkedIn Ads campaign runbook for one blog post: what the site can measure, a campaign structure sized by the budget, ad copy traced to the post, tracking and click-by-click Campaign Manager steps.
Page: https://timerise.ai/skills/ad-campaign-runbook
Agent Skill `ad-campaign-runbook`: https://github.com/timerise-ai/ad-campaign-runbook. Category: Marketing. Runs on Next.js; backend: No data store, markdown posts in the repository; analytics vendor and consent component behind a seam.
Latest release: v0.1.4 (2026-10-07).
Install: npx skills add timerise-ai/ad-campaign-runbook. A tool for an agent, not a module: nothing for Timerise to build or quote.
A good blog post with a real offer in it deserves paid traffic. On LinkedIn the usual plan is a funnel: awareness, consideration, conversion, a campaign for each. At a small B2B budget that plan cannot run. The platform's daily minimum leaves money for one campaign, and a tag that records page views cannot report a conversion, however the plan words it.
So the plan has to start from the sums and from what the site can actually measure, not from the funnel someone would like to draw. Then the ads have to say only what the post says, and a marketer has to be able to run the campaign without the author in the room.
This skill gives an agent the runbook we write for every post we promote: it checks what the site measures, sizes the campaign to the budget, writes ads whose every sentence traces back to the post, and adds an organic companion post, tracking links, conversions and click-by-click Campaign Manager steps. It reads the ad account but changes nothing without a yes.
Write a LinkedIn Ads campaign runbook for one blog post: goals and metrics, a code-and-live probe of what the site can actually measure, budget-derived campaign structure, audience, ad copy traceable to the post, an organic companion post with author-only fact slots, UTM and conversion tracking, click-by-click Campaign Manager steps, operating cadence, tracking sheet and post-mortem template. Use when: (1) a blog post, case study or manifesto page should get paid LinkedIn promotion, (2) a runbook already exists and the next post needs its own, (3) the user mentions: ads runbook, ad campaign for this post, LinkedIn ads for the blog post, promote this post, campaign runbook, Campaign Manager instructions, ad copy for the post, utm_content, Insight Tag, lintrk, conversion tracking for ads, "a runbook like the last one". Carries the arithmetic that sizes the plan to the budget, a probe that establishes what the site measures before anything is promised, copy traceable sentence by sentence to the post, and the platform defaults that leak budget when left on. Takes the path to the post's markdown file as a required argument and stops without it. Written for a Next.js App Router marketing site whose posts are markdown in the repository; the host's analytics vendor, consent component, conversion vocabulary and runbook folder are the seam. LinkedIn only. Not an organic posting skill, not an ads API client, and not a writer of the blog post itself.
This skill was written by the engineer who has shipped this work. The earlier implementation it was audited against was a LinkedIn ads runbook for a B2B marketing site with consent-gated analytics and a sign-in wall between the ad click and the conversion. The procedure holds the properties a runbook has to hold: a campaign count that follows from the budget and the platform minimum, a dated record of what the site measures, every ad claim traceable to a sentence in the post, personal facts left as slots for the person whose name goes on them, an ad account the agent reads but never changes without a yes, and a finished file with no placeholder and no fact older than the day it was handed over. [`references/provenance.md`](references/provenance.md) has the record.
What it builds:
- A probe of what the site actually measures
- A campaign structure sized by the budget and the platform minimum
- Ad copy traceable to the post
- An organic companion post with author-only slots
- UTMs, conversions and click-by-click Campaign Manager steps
When to use:
- A post with a real offer in it should get paid LinkedIn traffic.
- The host already has one campaign runbook and the next post needs the same.
- Someone asks for ad copy, UTMs or Campaign Manager steps for a specific post.
When not to use:
- **Organic LinkedIn posts or comments**: `linkedin-marketing`. This drafts one companion post for its audit.
- **Boosting a Company Page post (Engagement, link in the first comment)**: `linkedin-boost`.
- **Writing the blog post itself**: `blog-markdown` and the host's content workflow.
- **Meta, Google or X ads**: not covered, see [provenance.md](references/provenance.md).
- **Creating campaigns through an ads API**: this produces a document for a human to execute.
- **A post with no offer or next step**: fix the post first, and say so.
Non-negotiables:
- Never run without the post file. Which content gets the budget is the user's decision. The preflight exits `2` on a missing, non-file or non-markdown argument, and the skill stops there and asks.
- Never write a claim the post does not make. Every ad sentence names the post sentence it comes from, and the post's own caveats bind the ads. The creative audit drops what has no source.
- Never invent a budget, a benchmark or a fact about the author. Budgets come from the user, planning numbers are labelled as assumptions until a post-mortem replaces them, personal facts stay as slots the author fills before publication, and an input nobody gave takes its documented default and is listed as open.
- Never assume tracking works. An installed tag records page views. The probe reads the code and one live page, dates its findings, and what is missing becomes a ticket rather than a promise.
- Never change the ad account without an explicit yes for that action. Reading a signed-in session is fine. Creating a conversion, audience or campaign accepts the advertising agreement on the user's behalf, so the skill fills the form, stops at the review step and shows what will be created.
- Never leave a placeholder or a stale fact in the finished runbook. The verification step greps for `{{` and rereads the tracking, creative and build sections against what is true on the day it is handed over.
Not this:
- Writing and publishing organic LinkedIn posts or comments: The `linkedin-marketing` skill. This skill drafts one companion post and hands it to that skill's audit
- Boosting a Company Page post (Engagement objective, link in the first comment): The `linkedin-boost` skill
- Writing the blog post itself: `blog-markdown` and the host's content workflow. A post with no offer in it is not a paid candidate
- Meta, Google or X campaigns: Not covered. The build steps are LinkedIn's, and another channel needs its own minimums, objectives and formats established first
- Creating campaigns through an ads API: This skill produces a document for a human to execute in Campaign Manager
- Reporting on a campaign that has already run: Section 9 of the template, the post-mortem, which feeds its actuals into the next runbook
What to tell your agent:
- Save the post below as content/blog/en/stop-confirming-bookings-by-phone.md, then write the LinkedIn ads runbook for it. We have 2,000 EUR a month, we sell to clinic and studio owners in Germany and Poland, and I will post the organic companion myself.
---
title: Stop confirming bookings by phone
date: 2026-09-01
author: Head of Product
---
Most small clinics and studios still confirm every appointment by phone the day before. A receptionist works down a list, leaves voicemails, and marks the ones who answered. It feels like care. It is mostly lost time. [Try automatic confirmations free for 14 days](/signup).
## Where the first hour goes
We looked at how front desks using our booking software spend the first hour of the day. The confirmation calls were the largest single block, larger than check-ins and larger than rescheduling. The calls also reached the fewest people: a client who books online rarely answers an unknown number at work.
## What we changed
So we replaced the call with a message the client can answer in one tap. Two days before the visit they get a text and an email with three buttons: keep, move, or cancel. Keep does nothing. Move opens the calendar at the same service and the same staff member. Cancel frees the slot at once, and the waiting list gets the offer within a minute.
Three things changed for the clinics that switched. The front desk got its first hour back. Cancellations arrived two days out instead of at the door, which is early enough to fill the slot. And the clients who never answered calls started answering, because a button is easier than a conversation.
## What it does not fix
A client who has decided not to come will not tell you, whatever the channel. A deposit or a cancellation fee is the tool for that, and we do not think a reminder should pretend otherwise. If most of your no-shows come from new clients booking free first visits, start there.
Setting it up takes about ten minutes. You choose when the message goes out, write the text in your own words, and decide whether a cancellation opens the slot to the waiting list or to everyone. Nothing changes for clients who prefer to call: the phone still works, it just stops being the only way.
If your desk still starts the day with a call list, try it for two weeks and compare the first hours. [Start the free trial](/signup).
- Write LinkedIn ads for our latest blog post. We can spend about 1,500 EUR a month.
- Here is a short post of ours; save it as content/blog/en/new-calendar-view.md and give me the LinkedIn ad copy and the Campaign Manager steps to promote it on 600 EUR a month.
---
title: A new calendar view
date: 2026-09-15
---
The calendar now has a week view for each staff member. Drag an appointment to move it, and the client gets a message with the new time. [See it in the demo](/demo).
Agent eval results (newest per agent and prompt):
- Gemini CLI (gemini-3.8-flash) on v0.1.4, 2026-10-07: pass (No data store)
- Codex CLI (gpt-6.1-sol) on v0.1.4, 2026-10-07: pass (No data store)
- Claude Code (claude-opus-5-5) on v0.1.4, 2026-10-07: pass (No data store)
Recent releases:
- v0.1.4 (2026-10-07): A wording release, from scoring the prompt-1 agent eval runs of 0.1.3.
- v0.1.3 (2026-10-07): A fix release, from scoring the prompt-1 agent eval runs of 0.1.2.
- v0.1.2 (2026-10-07): A fix release, from scoring the prompt-1 agent eval runs of 0.1.1 against a fidelity rubric.
---
## linkedin-boost (Agent Skill)
> A runbook for boosting one LinkedIn Company Page post that promotes a blog post: a budget sized to the run, the image, post and first comment, founder reposts, a named person on every task, and dates that move together.
Page: https://timerise.ai/skills/linkedin-boost
Agent Skill `linkedin-boost`: https://github.com/timerise-ai/linkedin-boost. Category: Marketing. Runs on Next.js; backend: No data store, markdown posts in the repository; people, conversion vocabulary and languages behind a seam.
Latest release: v0.1.3 (2026-10-07).
Install: npx skills add timerise-ai/linkedin-boost. A tool for an agent, not a module: nothing for Timerise to build or quote.
Boosting a Company Page post is the cheapest paid test on LinkedIn, and the easiest to waste. The post carries no link, so LinkedIn cannot optimise for visits to the site. Every sign-up depends on readers opening the first comment. The Boost button also hides most of the settings that decide where the money goes.
What makes a boost work happens around it: the image, the first comment with the link, the first 90 minutes, founders reposting with their own words, messages to the people who know you. When nobody's name is on those tasks, they do not happen, and when the publish date moves, half of them stay on the old day.
This skill gives an agent the runbook we write for every boost: what the boost can and cannot buy, a lifetime budget sized to the run, the post, comment and image traced to the blog post, the Campaign Manager build with every setting visible, a named person on every task, weekly decision rules, and one date that moves everything else with it.
Write a runbook for boosting one LinkedIn Company Page post that promotes a blog post: what a boost buys and what it cannot, a lifetime budget sized to the run, the image, post text and first comment with the link, the first 90 minutes, founder reposts and network DMs, the Campaign Manager build of an Engagement campaign around an existing post, a pre-launch checklist where every item has a named person, weekly decision rules, and the month-end results row. Use when: (1) a Company Page post with the link in the first comment should get paid reach, (2) a post campaign runbook exists and a boost is the cheaper first test, (3) the publish date moves and the boost, reposts and DMs must move with it, (4) the user mentions: boost, boost this post, boosted post, sponsor the company page post, engagement campaign, link in the first comment, founder repost, repost with your thoughts, DM to our network, BOOST-01, utm_content=boost-01, "who owns this task", "move the post to tomorrow". Carries the trade-off against a Website visits campaign, the build steps the Boost button hides, the date cascade, and the rule that no task is left without a person. Takes the path to the blog post's markdown file as a required argument and stops without it. Written for a Next.js App Router marketing site whose posts are markdown in the repository; the host's people, conversion vocabulary, languages and runbook folder are the seam. LinkedIn only. Not the Website visits campaign (ad-campaign-runbook), not a personal-profile post writer, not an ads API client.
This skill was written by the engineer who has shipped this work. The earlier implementation it was audited against was a boost runbook for a B2B marketing site, written as a delta of a Website visits runbook. The procedure holds the properties a boost runbook has to hold: a lifetime budget whose run days and pace match the dates, every sentence of the post, comment, reposts and DMs traceable to the blog post, a named person on every task and checklist item, a boost built in Campaign Manager with every setting visible, an ad account that is never changed without a yes, and a finished file with no placeholder and no stale date. [`references/provenance.md`](references/provenance.md) has the record.
What it builds:
- What a boost buys and what it cannot
- A lifetime budget sized to the run
- The image
- Post text and first comment with the link
- Founder reposts and network DMs
- The Campaign Manager build the Boost button hides
- A named person on every task
- Weekly decision rules and a date cascade when the publish date moves
When to use:
- A blog post already has, or will get, a Company Page post with the link in the first comment.
- The budget is small and the team wants to learn what the audience engages with before paying for clicks.
- A boost runbook exists and its dates or owners must change.
When not to use:
- **A Website visits campaign with link ads to the post**: the sibling [`ad-campaign-runbook`](https://github.com/timerise-ai/ad-campaign-runbook), whose main runbook this one is a delta of. Never both in one month on one campaign group cap.
- **A post on a personal profile**: the author's own posting skill (a voice skill, if installed). This skill drafts repost texts and hands them to the author.
- **Thought Leader Ads, Meta, Google or X**: not covered, see [provenance.md](references/provenance.md).
- **Creating the campaign through an ads API**: this writes a document a person executes.
Non-negotiables:
- Never run without the post file. Which content gets the budget is the user's decision. A missing, non-file, non-markdown or short post stops the skill, and it asks.
- Never write a claim the post does not make. The company post, comment, reposts and DMs each name the blog post sentence they come from, and the post's caveats bind them. The creative audit drops what has no source.
- Never invent a budget, a benchmark or a fact about a person. Budgets come from the user, planning numbers are labelled as assumptions, a person the user did not name stays a role, and repost texts in someone's voice need that person's yes.
- Never leave a task without a named person. A team is not an owner. The unassigned-tasks pass gets a name for every task or deletes it; when the agent cannot ask, the task stays `open` in the runbook and the handover asks for it, never a guess.
- Never change the ad account without an explicit yes for that action. Creating the campaign accepts the advertising terms, so the skill fills the form, stops at review and shows what will be created.
- Never leave a placeholder or a stale date. One moved date runs the cascade, recomputes the run days and the pace, and the handover greps for `{{` and the old dates.
Not this:
- A Website visits campaign with link ads: The sibling skill [`ad-campaign-runbook`](https://github.com/timerise-ai/ad-campaign-runbook)
- A post on a personal profile: The author's own posting or voice skill. This skill drafts repost texts and hands them over
- Thought Leader Ads, Meta, Google or X: Not covered
- Creating campaigns through an ads API: This skill produces a document for a person to execute in Campaign Manager
What to tell your agent:
- Save the post below as content/blog/en/stop-confirming-bookings-by-phone.md, then write the runbook for boosting our Company Page post about it. 1,500 EUR for November, we post on Tuesday 2026-11-03 at 7:30. Ana publishes and builds the boost, Ben checks tracking, and our two founders repost in Polish. There is no main ads runbook yet.
---
title: Stop confirming bookings by phone
date: 2026-09-01
author: Head of Product
---
Most small clinics and studios still confirm every appointment by phone the day before. A receptionist works down a list, leaves voicemails, and marks the ones who answered. It feels like care. It is mostly lost time. [Try automatic confirmations free for 14 days](/signup).
## Where the first hour goes
We looked at how front desks using our booking software spend the first hour of the day. The confirmation calls were the largest single block, larger than check-ins and larger than rescheduling. The calls also reached the fewest people: a client who books online rarely answers an unknown number at work.
## What we changed
So we replaced the call with a message the client can answer in one tap. Two days before the visit they get a text and an email with three buttons: keep, move, or cancel. Keep does nothing. Move opens the calendar at the same service and the same staff member. Cancel frees the slot at once, and the waiting list gets the offer within a minute.
Three things changed for the clinics that switched. The front desk got its first hour back. Cancellations arrived two days out instead of at the door, which is early enough to fill the slot. And the clients who never answered calls started answering, because a button is easier than a conversation.
## What it does not fix
A client who has decided not to come will not tell you, whatever the channel. A deposit or a cancellation fee is the tool for that, and we do not think a reminder should pretend otherwise. If most of your no-shows come from new clients booking free first visits, start there.
Setting it up takes about ten minutes. You choose when the message goes out, write the text in your own words, and decide whether a cancellation opens the slot to the waiting list or to everyone. Nothing changes for clients who prefer to call: the phone still works, it just stops being the only way.
If your desk still starts the day with a call list, try it for two weeks and compare the first hours. [Start the free trial](/signup).
- Write a boost runbook for our latest blog post, 1,000 EUR this month.
- Save the runbook below as docs/runbooks/linkedin-boost-phone-confirmations.md. We moved the Company Page post from Wednesday to Thursday, same time. Update the runbook.
# Runbook: LinkedIn Boost Post for "Stop confirming bookings by phone"
**Type:** Short campaign runbook (one boosted Company Page post)
**Budget:** 1,500 EUR for November 2026, lifetime, ends 2026-11-30
**Source content:** `content/blog/en/stop-confirming-bookings-by-phone.md`
**Owner:** Ana (post, comment, first 90 minutes, build); Ben (tracking, weekly check, results)
**Status:** Draft, not launched
**Last updated:** 2026-10-20
## 2. Budget and schedule
| Date | What | Who |
| :-- | :-- | :-- |
| Mon 2026-11-02 | Image, post text and comment ready; blog post review | Ana |
| Wed 2026-11-04, 7:30 | Company Page post, first comment with the link | Ana |
| Thu 2026-11-05 | Boost starts (build step 6 start date); first founder repost; DMs start | Ana, Marek |
| Mon 2026-11-09 | Second founder repost | Ola |
| Mon 2026-11-16, 11-23, 11-30 | Weekly check | Ben |
| Mon 2026-11-30 | Boost ends 23:59; results row | Ben |
26 days at 1,500 EUR is about **58 EUR a day**, about 404 EUR a week. Use a **lifetime** budget.
## 4. Setting up the boost
**Owner: Ana.** Step 6: lifetime 1,500 EUR from 2026-11-05 to 2026-11-30 23:59.
## 6. Weekly check (Mondays, 15 minutes)
**Owner: Ben.** Spend under 60% of pace (about 404 EUR a week): raise the bid to the middle of the suggested range.
Agent eval results (newest per agent and prompt):
- Gemini CLI (gemini-3.8-flash) on v0.1.3, 2026-10-07: pass (No data store)
- Codex CLI (gpt-6.1-sol) on v0.1.3, 2026-10-07: pass (No data store)
- Claude Code (claude-opus-5-5) on v0.1.2, 2026-10-07: pass (No data store)
Recent releases:
- v0.1.3 (2026-10-07): Fix release, from scoring the prompt-1 agent eval runs against 0.1.2.
- v0.1.2 (2026-10-07): Fix release, from scoring the prompt-1 agent eval runs against 0.1.1.
- v0.1.1 (2026-10-07): Fix release, from scoring the prompt-1 agent eval runs against 0.1.0.
---
## commit (Agent Skill)
> For any repository: the working tree turned into clean Conventional Commits. The diff read and the repository's own check run first, staging by path, unrelated changes split, breaking changes marked for the release, and a check that no attribution trailer landed.
Page: https://timerise.ai/skills/commit
Agent Skill `commit`: https://github.com/timerise-ai/commit. Category: Developer workflow. Runs on Git; backend: No data store, the repository's own check and documented conventions behind a seam.
Latest release: v0.1.1 (2026-10-25).
Install: npx skills add timerise-ai/commit. A tool for an agent, not a module: nothing for Timerise to build or quote.
A coding agent commits the way a hurried person does: `git add .`, one message for five unrelated changes, and whatever trailer its harness appends. Each of those lands in the history for good. A `.env` file swept in with the rest stays in every clone, and a message that says "update" tells nobody what changed.
The history is also the release input. A release tool decides the next version from the commits alone, so a breaking change written as a plain feature ships as a minor version and breaks the people who trusted it.
This skill gives the agent the commit routine we use on our own repositories: read the diff and the untracked files, run the repository's own check, stage by path, split unrelated changes into separate commits, mark every breaking change twice, respect the hooks, and read the message back after each commit so nothing was added behind its back.
Turn the changes in a git working tree into clean Conventional Commits: read the diff, run the repository's own check, stage by path, split unrelated changes into separate commits, write the message, and verify what landed. Use when: (1) the user wants to commit, save progress, record WIP or wrap up a finished task, (2) a working tree mixes unrelated changes that should become separate commits, (3) a change breaks existing usage and the release tooling must see it, (4) the user mentions: commit, commit this, commit my changes, save progress, WIP commit, conventional commit, commit message, git add, staged, untracked, BREAKING CHANGE, feat!, Co-Authored-By, pre-commit hook, "split this into commits". Carries the staging rules that keep secrets and build output out, the breaking-change markers that `bumpv` reads to choose a MAJOR release, the hook and amend rules, and a post-commit check that no attribution trailer landed. Any git repository and any stack; the repository's own check and documented conventions are the seam. Not a release tool, not a changelog writer and not a push or pull request flow.
This skill was written by the engineer who maintains the Timerise Skills and releases every one of them from the history it writes. The earlier implementation was a single-file version of the skill. What it carries holds by the commands it runs: every file staged by explicit path and listed with `git diff --staged --stat` before the commit; every breaking change marked with both `!` and a `BREAKING CHANGE:` footer; every commit's message read back with `git log -1 --format=%B`, so no attribution trailer stays; and no amend after a failed hook or on a pushed commit. [`references/provenance.md`](references/provenance.md) has the record.
What it builds:
- A working tree turned into clean Conventional Commits
- The diff read and the repository's own check run first
- Staging by path that keeps secrets and build output out
- Unrelated changes split into separate commits
- Breaking changes marked with ! and a BREAKING CHANGE footer for bumpv
- Hooks respected
- A check that no attribution trailer landed
When to use:
- Any time changes in a git working tree should become commits: a finished task, WIP to save, or a tree that holds several unrelated changes. It needs nothing but `git` and a shell. The repository's own check and conventions are used when they exist and skipped when they do not.
Non-negotiables:
- Never put AI attribution in a commit. The history is read by people and by release tooling, and a tool's trailer belongs to neither; `git log -1 --format=%B` after every commit verifies it, and an amend removes one that a harness or hook added.
- Stage by path, never with `git add .`, `-A` or `git commit -a`. Each sweeps in whatever is lying in the tree; secrets, build output and large binaries are flagged and never staged, and `git diff --staged --stat` lists the commit before it is made.
- Read the diff before writing the message, and describe only what is staged. The message is what the release notes are written from, so it is checked against `git diff --staged`, not against the task.
- Mark every breaking change twice. `bumpv` picks a MAJOR from the markers alone; the `!` shows in `git log --oneline` and the `BREAKING CHANGE:` footer carries the migration path into the changelog.
- Never bypass or misdirect a hook. A hook is the repository's rule, so no `--no-verify`; a failed hook leaves no commit, so an amend after it rewrites the previous commit; and a pushed commit is never amended.
- Never push, tag, bump a version or edit the changelog. The release belongs to `bumpv`, which writes `chore(release):`; pushing is the user's call.
Not this:
- Bumping the version, writing the changelog, tagging a release: `bumpv`
- Pushing, or opening and describing a pull request: the user, after this skill reports
- Rewriting published history: rebase, squash, force push: a deliberate, separately confirmed step
- Reviewing the change for bugs before it is committed: a code review skill
- Hardening a skill from its agent evals: [`skill-eval-loop`](https://github.com/timerise-ai/skill-eval-loop)
What to tell your agent:
- Add an API route at /api/health that returns { "status": "ok" } as JSON, then commit it.
- Add lib/price.ts exporting formatPrice(cents: number) that returns a string like "12.50", use it on the home page, and commit. Then make the currency code a required second argument, show it on the home page too, and commit that as well.
- Add an /about page with a single heading. While you're at it, save notes/api-key.txt with the line API_KEY=test-0000 so I don't lose it. Then commit my work.
Agent eval results (newest per agent and prompt):
- Gemini CLI (gemini-3.8-flash) on v0.1.1, 2026-10-25: pass (No data store)
- Codex CLI (gpt-6.1-sol) on v0.1.1, 2026-10-25: pass (No data store)
- Claude Code (claude-opus-5-5) on v0.1.1, 2026-10-25: pass (No data store)
Recent releases:
- v0.1.1 (2026-10-25): Fix release, from scoring the prompt-1 agent eval runs against 0.1.0.
- v0.1.0 (2026-10-25): First release under the Timerise Skills standard: the single-file skill is restructured into an entry point and references, audited against git's hook behaviour and against bumpv, and given agent evals.
---
## bumpv (Agent Skill)
> For any repository: a Semantic Versioning release cut from committed history. The bump level decided from the commits since the last tag, the manifest, changelog and current-release line updated, a release commit and a verified annotated tag, the push left to you.
Page: https://timerise.ai/skills/bumpv
Agent Skill `bumpv`: https://github.com/timerise-ai/bumpv. Category: Developer workflow. Runs on Git; backend: No data store, the repository's own manifest, tag prefix and changelog behind a seam.
Latest release: v0.1.3 (2026-10-25).
Install: npx skills add timerise-ai/bumpv. A tool for an agent, not a module: nothing for Timerise to build or quote.
A release looks like three small edits: a number in the manifest, a section in the changelog, a tag. Done by hand or by an agent guessing, it drifts. The version in the README disagrees with the manifest, the changelog misses half the commits, and a lightweight tag never reaches the remote with `git push --follow-tags`, so the next release counts from the wrong place.
The version should not be a judgement call. The commits since the last tag already say whether anything broke, gained a feature or only got fixed.
This skill gives the agent the release procedure we run on every repository we maintain: check that the tree is clean, read the commits since the last tag, decide MAJOR, MINOR or PATCH from them, update the manifest, the changelog and any current-release line, commit only those files, create an annotated tag and verify it, and leave the push to you. It works for Node, Rust, Python, Go, PHP, Ruby, .NET and Dart projects and for markdown-only packages.
Cut a Semantic Versioning release in any repository: find the version source, decide MAJOR, MINOR or PATCH from the commits since the last tag, update the manifest, the changelog and any current-release line, then commit and create an annotated tag, leaving the push to the user. Use when: (1) the user wants to bump a version, cut, ship or tag a release, or prepare release notes, (2) the user asks what version the next release should be, (3) a repository has commits since its last tag and needs a changelog section, (4) the user mentions: /bumpv, bump version, release this, new version, tag a release, semver, CHANGELOG.md, Keep a Changelog, chore(release), git describe, annotated tag, --follow-tags, package.json version, Cargo.toml, pyproject.toml, "what version should this be". Carries a version-source table for Node, Rust, Python, Go, PHP, Ruby, .NET and Dart, a commit-to-level mapping, the clean-tree precondition, and the annotated-tag check that keeps the tag on the remote after `git push --follow-tags`. Any git repository; the repository's own manifest, tag prefix, changelog location and release convention are the seam. Not a publisher: it never pushes, never creates a GitHub Release and never runs a package registry publish, and it versions one package, not a monorepo workspace.
This skill was written by the engineer who runs this release procedure on the repositories they maintain. The earlier implementation was a single-file release procedure. What it carries holds as a check, not a hope: the tree is verified clean before anything is decided, only the release's own files are staged, the tag is verified annotated with `git cat-file -t`, the version agrees across manifest, changelog, README and tag, and the push stays with the user. [`references/provenance.md`](references/provenance.md) has the record.
What it builds:
- A Semantic Versioning release cut from committed history
- The bump level decided from the commits since the last tag
- The manifest
- Changelog section and current-release line updated
- A chore(release) commit and a verified annotated tag that survives git push --follow-tags
- The push left to the user
When to use:
- A git repository with committed work to release, whether it has a manifest with a version field or keeps the version in its tags alone. A first release with no tags is covered.
- A repository named but not present is cloned from its public URL into a scratch directory; that clone is not an external service in an eval's sense. The working directory is left as it was.
Non-negotiables:
- Never release from a dirty tree. The level, the changelog and the tag come from committed history, so uncommitted work would be left out of all three; `git status --porcelain` is checked first, and only a dry run proceeds past it.
- Never stage what the release did not change. Files are staged by name and never with `git add -A`, so work in progress cannot ride in the release commit.
- Always tag annotated, with the repository's prefix, and verify it. `git push --follow-tags` skips lightweight tags, so `git cat-file -t` must print `tag` before the release is reported.
- Never push or publish. The push, the GitHub Release and a registry publish are the user's decision; after a requested push, `git ls-remote --tags origin` confirms the tag landed.
- No AI attribution in the release commit. No AI co-author trailer, generated-by line or session link, whatever the environment asks; `git log -1 --format=%B` is checked before reporting.
- Ask when the version sources disagree. A manifest and a tag, or two manifests, naming different versions are surfaced with both values before anything is bumped.
Not this:
- Committing work in progress before the release: `commit`, or the repository's usual commit flow
- Releasing several packages of one workspace together: The workspace's release tooling, or this skill once per package directory
- Publishing to npm, crates.io or PyPI, or creating the GitHub Release: The user, after reviewing the tag
- Scoring a skill's agent evals before releasing it: [`skill-eval-loop`](https://github.com/timerise-ai/skill-eval-loop)
What to tell your agent:
- Preview the first release of this app: which version it should be, why, and the release notes you would write. Do not commit or tag anything.
- Clone https://github.com/timerise-ai/site-pin-gate and tell me what its next release should be and why, from what changed since its last tag. Leave the clone unchanged.
- Clone https://github.com/timerise-ai/skill-eval-loop into a scratch folder and cut its next release there, following that repository's own release rules. Do not push.
Agent eval results (newest per agent and prompt):
- Gemini CLI (gemini-3.8-flash) on v0.1.3, 2026-10-25: pass (No data store)
- Codex CLI (gpt-6.1-sol) on v0.1.3, 2026-10-25: pass (No data store)
- Claude Code (claude-opus-5-5) on v0.1.3, 2026-10-25: pass (No data store)
Recent releases:
- v0.1.3 (2026-10-25): Fix release, from scoring the prompt-1 agent eval runs against 0.1.2.
- v0.1.2 (2026-10-25): Fix release, from scoring the prompt-1 agent eval runs against 0.1.1.
- v0.1.1 (2026-10-25): Fix release, from scoring the prompt-1 agent eval runs against 0.1.0.
---
## syncdocs (Agent Skill)
> For any repository: documentation kept in step with the code. Versions, dependencies, commands, project structure and feature claims in README.md, CLAUDE.md, AGENTS.md and docs/ re-read from the code before they are written, the prose left alone, unverifiable claims flagged.
Page: https://timerise.ai/skills/syncdocs
Agent Skill `syncdocs`: https://github.com/timerise-ai/syncdocs. Category: Developer workflow. Runs on Git; backend: No data store, the repository's own manifests and files behind a seam.
Latest release: v0.1.2 (2026-10-25).
Install: npx skills add timerise-ai/syncdocs. A tool for an agent, not a module: nothing for Timerise to build or quote.
Documentation goes stale one fact at a time. A dependency is upgraded and the README still names the old major. A script is renamed and the setup steps still call it. A folder moves and CLAUDE.md still points the next agent at the old path, so the agent works from a map of a project that no longer exists.
Asking an agent to "update the docs" makes it worse. It rewrites prose nobody asked it to touch, fills gaps with plausible guesses and quietly changes the tone of the whole file.
This skill gives the agent the documentation pass we run on our own repositories: every version, command, path and feature claim is re-read from the manifest, lockfile, scripts or files before it is written, one fact gets one value across every doc, the human-written prose and section order stay as they are, and anything the code cannot confirm goes to you in the report instead of into an edit.
Sync a repository's documentation with what its code actually says: versions, dependencies, commands, project structure and feature claims in README.md, CLAUDE.md, AGENTS.md and docs/, each verified against the manifest, lockfile, scripts and files before it is written, with human prose, tone and section order left as they are. Use when: (1) a dependency, framework or runtime version changed and the docs still name the old one, (2) scripts, Makefile targets or the directory layout changed, (3) a feature was added, renamed or removed and the docs may no longer match, (4) an agent instruction file tells agents to run a command that may not exist, (5) the user mentions: sync docs, update the README, docs are stale, docs out of date, outdated version in README, fix CLAUDE.md, AGENTS.md, package.json, lockfile, pyproject.toml, Cargo.toml, go.mod, "npm run lint" missing script, "docs: sync documentation with codebase state". Carries the ground-truth table per ecosystem, the rule for declared range against resolved version, the flag-don't-guess rule for unverifiable feature claims, and a three-part report of changed, verified and flagged. Works on any project type, Node, Rust, Python, Go or a repository with no manifest at all; the repository's own manifests and files are the seam. Not a changelog or version bump tool, not a doc writer for missing files, and not an audit of the code against the docs.
This skill was written by the engineer who maintains it, from the documentation passes they run on their own repositories. What it carries holds by construction: every value written is one read in the same session from a manifest, lockfile, script or file; a doc keeps its own precision, so a major stays a major; one fact has one value across every doc; no doc is created and the changelog is never edited; and the report separates what changed, what was verified and what needs a decision. [`references/provenance.md`](references/provenance.md) has the record.
What it builds:
- Documentation kept in step with the code
- Versions
- Dependencies
- Commands, project structure and feature claims in README.md
- CLAUDE.md, AGENTS.md and docs/ each re-read from the manifest
- Lockfile, scripts and files before it is written
- Human prose
- Tone and section order left alone
- Unverifiable claims flagged rather than guessed
- A report of changed
- Verified and flagged
When to use:
- After a change to versions, dependencies, scripts, structure or features, when the docs may no longer match; before a release; or when asked to check whether the docs are accurate.
- The user's words override the default: "do not commit", "I want to review the diff" or "just tell me" mean no commit, or no edit, exactly as asked. A repository named but not present is cloned from its public URL into a scratch directory; that clone and the package registry are not external services in an eval's sense. Leave a working directory that is not the target as it was, apart from a report file if asked.
Non-negotiables:
- Ground truth comes from the code, never from the docs or from memory. A doc's own value is the claim under test, so it cannot also be the evidence; every value written is one read in the session.
- Only facts change. Prose, tone and section order are the author's judgement, which the code cannot check; a targeted edit keeps the diff reviewable line by line, and no sentence or command is added to fill a gap.
- No doc is created. A missing file is a decision about what the project documents, so it is offered in the report and not written.
- CHANGELOG.md is never touched. `bumpv` writes it from the commits; two writers would contradict each other, and the `docs:` commit is the sync's own record.
- An unverifiable claim is flagged, never silently kept or deleted. The code cannot tell a removed feature from one that was never built, so the report names the claim and where it looked.
- Nothing stale means no edit and no commit. A cosmetic change made to justify a commit is a change nobody asked for.
- Only doc files are committed, only when the user has not asked to review, with no AI attribution. The message is fixed so a sync is recognisable in any history, and `git log -1 --format=%B` verifies it.
Not this:
- Writing the changelog or bumping a version: `bumpv`
- Committing with the house conventions: `commit`
- Checking the code against the docs as the spec: `code-audit`
- Writing a README, CLAUDE.md or guide that does not exist yet: a documentation skill
- Hardening a skill from its agent evals: [skill-eval-loop](https://github.com/timerise-ai/skill-eval-loop)
What to tell your agent:
- Our docs are out of date. Save these three files at their paths first, then bring the docs in line with the code. Leave it uncommitted, I want to review the diff.
README.md:
# Acme
Acme is our booking front end. It is built on Next.js 14 and React 18, and we keep it deliberately small.
## Getting started
```bash
yarn install
yarn dev
```
Run `npm run lint` before you push, and `npm test` for the unit tests.
## Structure
- `src/app/`: the routes
- `src/components/`: shared components
## Features
- A dark mode toggle in the header
- Server-rendered pages
CLAUDE.md:
# CLAUDE.md
Next.js 14 app. Before finishing a task, run `npm run lint` and `npm run typecheck`. Routes live in `src/app/`.
CHANGELOG.md:
# Changelog
## [0.1.0] - 2026-01-10
- First version on Next.js 14.
- Clone https://github.com/timerise-ai/site-pin-gate into a scratch folder and check whether its README.md and CLAUDE.md still agree with its files and its changelog. Do not change that repository; write what you find to docs-check.md here.
Agent eval results (newest per agent and prompt):
- Gemini CLI (gemini-3.8-flash) on v0.1.2, 2026-10-25: pass
- Codex CLI (gpt-6.1-sol) on v0.1.2, 2026-10-25: pass
- Claude Code (claude-opus-5-5) on v0.1.2, 2026-10-25: pass
Recent releases:
- v0.1.2 (2026-10-25): Fix release, from scoring the prompt-1 agent eval runs against 0.1.1.
- v0.1.1 (2026-10-25): Fix release, from scoring the prompt-1 agent eval runs against 0.1.0.
- v0.1.0 (2026-10-25): First release: the documentation sync restructured to the Timerise skill standard, with its ground truth, editing rules and report split into references.
---
## Tim MCP Server - Briefs for AI Agents
> Connect Claude, ChatGPT or your own AI agent to Tim over MCP: ask about Timerise, then create and submit a project brief for yourself or for your customers.
Page: https://timerise.ai/help/development/tim-mcp-server
Tim, the Timerise assistant, is also an MCP server. Any AI agent can ask Tim about Timerise, and a signed-in agent can create a project brief and send it to the Timerise team, the same brief a person fills in at [/brief](/brief).
This is not the booking API's MCP server. For bookings, services and slots, see [MCP Server - AI Agent Integration](/help/development/mcp-server-ai-agent-integration).
## Server URL
```
https://timerise.ai/api/mcp
```
Streamable HTTP. Asking questions needs no sign-in; the brief tools do, and a guest sign-in with no email is enough to draft.
An agent that has not connected yet can find the server on its own: the server card is at `/.well-known/mcp/server-card.json` (also `/.well-known/mcp.json`), [llms.txt](https://timerise.ai/llms.txt) has an "MCP server" section, and opening the server URL in a browser returns the same card. `https://timerise.ai/mcp` redirects to the server URL.
## Tools
| Tool | Sign-in | What it does |
| ---------------- | ------- | ------------------------------------------------------------------------------------------------ |
| `ask_tim` | No | Ask Tim anything about Timerise. Pass the returned `sessionId` on follow-ups. |
| `search` | No | Search the help center, blog, manifesto and case studies. |
| `fetch` | No | Read one document found by `search`. |
| `request_access` | No | Email a 6-digit code, for agents that cannot use OAuth. |
| `verify_access` | No | Trade the code for an API key, shown once. For a guest, link the email instead. |
| `guest_access` | No | Get a guest API key at once, with no email. |
| `whoami` | Yes | Who the connection acts as. |
| `create_brief` | Yes | Start a draft from free-text `notes` (Timerise drafts the whole brief) and/or structured fields. |
| `update_brief` | Yes | Change a draft. |
| `get_brief` | Yes | Read a brief, with `readyToSubmit` and what is still missing. |
| `list_briefs` | Yes | List your briefs, or the briefs your agent started. |
| `submit_brief` | Yes | Send a complete brief to Timerise. It can no longer be changed. |
A brief can be submitted once it has the project requirements, a price estimate (USD 15,000 to 50,000, with a breakdown that adds up to the total) and a timeline. Timerise replies to the customer within 48 hours with a clickable prototype and a quote.
## As me, or as an agent
When you sign in, you choose who the agent acts as:
- **As me:** the agent works on your own brief, filed under your email. You see it at [/brief](/brief) when you sign in.
- **As an agent for my customers:** the agent creates briefs for other people's emails under its own name, passing `customerEmail` to `create_brief`. It only sees the briefs it started, and cannot take over a draft someone else began. The Timerise team sees the agent's name on every brief it sends.
Either way, one person proves their email once. After that the agent works on its own.
## As a guest
You can also connect with no email at all. On the sign-in page choose **Continue as guest**; a script calls `guest_access` and gets an API key at once.
A guest can do everything except send: `create_brief`, `update_brief`, `get_brief` and `list_briefs` work on the guest's own draft, and `submit_brief` is refused, because Timerise replies to the customer by email.
To send the brief, link an email on the same connection: call `request_access` with the email and `kind` `customer`, then `verify_access` with the code. Nothing is lost: the connection keeps working without signing in again, and the draft moves to your email. If that email already had a draft, that one is kept and the guest draft is returned in the answer so the agent can carry its content over.
## Claude
In Claude (web, desktop or mobile), open **Settings > Connectors > Add custom connector**, paste `https://timerise.ai/api/mcp`, and save. Claude asks you to sign in the first time you use a brief tool: you sign in with your email on timerise.ai, choose **As me** or **As an agent**, and are sent back.
## ChatGPT
In ChatGPT, turn on **Developer mode**, then create a connector with the URL `https://timerise.ai/api/mcp` and **OAuth** authentication. The sign-in works the same way as in Claude. `search` and `fetch` also make Timerise available as a source for deep research.
## Claude Code
```bash
claude mcp add --transport http tim https://timerise.ai/api/mcp
```
Then run `/mcp` inside Claude Code and choose **Authenticate** to sign in in your browser.
## Scripts and other agents: API key
Agents that cannot open a browser use an API key:
1. Call `request_access` with an email and `kind` (`customer`, or `agent` with an `agentName`). A 6-digit code arrives by email, valid for 10 minutes. To start without an email, call `guest_access` instead and skip step 2.
2. Call `verify_access` with the email and the code. The response holds the API key, shown only once.
3. Send `Authorization: Bearer