Skip to main content
Riktra does not run these for you. It is the context source; the scheduling lives wherever your agents already run. That is deliberate. A company that already has an agent runner should not need a second one, and a company that does not is better served by Claude Code’s /schedule or a cron job than by anything Riktra would build.

​
Recipes

Why it works: the AI has the company’s ranked priorities and your own focus, so “important” means important here rather than important in general. The instruction to say when nothing needs you matters more than it looks — a brief that always finds three things stops being read.
Why it works: unowned areas are invisible until something goes wrong in one. The explicit “do not create anything” keeps this a report rather than a pile of proposals you then have to review.
Why it works: it encodes the distinction the product cares about most. Nothing here can change shared truth on its own — every proposal waits for a human.
Why it works: decisions rot quietly. A decision that expired six months ago is worse than no decision, because people still act on it.
Why it works: it is the highest-value thirty seconds of preparation available, and it is the schedule people keep once they have felt it once.

​
Writing your own

What separates a schedule that gets read from one that gets muted. Start from a question, not a report. “What needs me today?” produces something useful. “Summarise Riktra” produces a wall. Say what to leave out. Agents are agreeable and will fill any space you give them. “At most three”, “no preamble” and “if nothing needs me, say so” are doing real work. Fetch context before reasoning. A schedule that reasons first and retrieves second produces confident answers about the wrong company. Put boot context at the top. Never let a schedule approve anything. Approval is the human’s part. A schedule that approves its own proposals has removed the only check the system has. Compare the revision number. Boot context returns the organization revision, which increments whenever shared context changes. If you cache between runs, that is the number to compare — not a timestamp.