Skip to main content

Scheduled tasks

A scheduled task is a prompt you save once and Kinn runs on a schedule — every day, or every week on a day you pick, at a local time in your timezone. When you sit down, the answer is already waiting.

That sounds like a convenience feature. It isn't, quite. The real problem it solves is that you can't ask about something you don't know happened. Kinn is excellent at answering questions, but it can only answer the ones you think to ask. If a complaint starts building on Thursday and you don't think to look until the following Wednesday, Kinn never had a chance to help. A standing weekly sweep closes that gap — it asks the question whether or not you remembered to.

Setting one up​

You need the Editor role or higher.

  1. In the sidebar, find Scheduled tasks and select New.
  2. Give it a Name — this is what you'll see in the sidebar, so make it scannable ("Monday bug sweep", not "Task 1").
  3. Write the Prompt. This is the whole craft; see below.
  4. Choose a Frequency — Daily or Weekly. Weekly asks for a Weekday.
  5. Set the Local time and Timezone. Kinn handles daylight-saving shifts for you, so 9:00 stays 9:00.

Then use Run now before you trust it. A scheduled prompt that reads well and returns something useless is the normal outcome of a first draft, and you don't want to discover that next Monday.

Writing a prompt that works unattended​

An interactive query is the opening move in a conversation — you can follow up when the answer comes back thin. A scheduled prompt gets no follow-up. It has to land on its own.

Each run starts completely fresh. This is the big one. A run has no memory of previous runs, so anything phrased as "what's changed since last time?" has no meaning. Always give an explicit, relative window:

Over the last 7 days, what issues were reported across all connected sources?

Never use fixed dates. "Since September 1st" is correct once and slowly becomes wrong forever.

Ask for a specific shape. Left open, you'll get a readable essay you have to mine. Name the structure you want:

Group them by theme. For each theme give the number of mentions, which platforms it appeared on, and one representative quote. Put anything appearing on more than one platform at the top.

Say what "nothing happened" looks like. Without this, a quiet week produces a page of prose making ordinary noise sound significant:

If nothing notable came up, say so in one line instead of padding the summary.

Keep one job per task. A prompt asking for bugs and sentiment and competitors returns a shallow answer on all three. Two or three focused tasks beat one sprawling one, and you can put them on different schedules.

Give the standing context. The run can't ask you what version you're on:

We're on the 2.x line and ship patches roughly every two weeks. Ignore issues that were already being reported before the current patch.

tip

An advanced pattern: ask the task to save a note when it finds something significant. Notes are durable product memory, so a finding from one run can inform later answers — including your own ad-hoc questions in chat. See Notes & memory.

A worked example​

Everything above, combined:

Over the last 7 days, find everything reported as broken or not working across all connected sources.

Group the reports by theme. For each theme, give the number of mentions, the platforms it appeared on, and one representative quote with a link. Sort so that anything appearing on more than one platform comes first.

We ship patches roughly every two weeks — focus on issues that look new rather than long-standing complaints. If nothing notable came up this week, say so in one line.

Reading the results​

Each task has its own page with the latest result and a Run history below it. Select any past run to read it.

Runs finish in one of a few states:

  • Succeeded — the result is there.
  • Failed — Kinn couldn't complete the run. Try Run now to see if it was transient.
  • Skipped — the run didn't happen, with a reason. Most often the previous run was still going; a task only ever has one run active at a time. Runs are also skipped if the product's subscription is inactive, or if the person who created the task no longer has access to the product.

Pause stops a task without deleting it, which is what you want for a task tied to a release cycle. Resume starts it again from the next occurrence.

Good candidates​

  • Monday bug sweep — the weekly triage list, ready before you open Kinn. See Triage bugs across platforms.
  • Daily flare-up watch — anything spiking in the last 24 hours, so a bad day gets caught the same day.
  • Post-release watch — a daily task during the week after a patch, paused between releases.
  • Weekly feature-request digest — what people asked for, ranked, so the backlog conversation starts from evidence.
  • Weekly summary for a stakeholder update — the recurring slide you always end up assembling by hand.

Limits worth knowing​

  • Daily or weekly only. No hourly, monthly, or custom cadences.
  • One run at a time per task. If a run is still going when the next is due, that occurrence is skipped rather than queued.
  • Results live in Kinn. There's no email, Slack, or webhook delivery — you read them on the task's page.
  • Tasks are private to whoever created them. Other people on your account don't see your scheduled tasks or their run history, and deleting a task deletes its history with it.
  • Usage counts against the product, same as a chat conversation. A daily deep-research task is not free.

Next​