Put what lasts on your readers' days.

A plug-in is a folder. This is Harbour Almanac's, the example that uses every part of contract 1:

Four commands of one tool take the folder to the publishing portal, in this order:

Start the quickstart, or download kanboombo-plugin.mjs: one file for Node 24, nothing to install. This is what the almanac puts on a day:

How Kanboombo runs it

Nothing runs until a person approves one exact version of your code, its digest. A record is a value (numbers on a date), an event (scheduled, happened or cancelled) or an item (a dated title with an https link), dated as your source dates it.

Is a plug-in right for this?

You will always be short of time, and so are your readers. Build a plug-in when it saves them a trip they make again and again, to a public source, for a dated fact they act on. If you are that source, or know it well, build it. It carries dated records from the body that publishes them, under terms that let them be kept and shown with the holder's name. It carries one holder's data (two publishers are two plug-ins), from up to 16 sources into up to 64 series.

It is not for personal data, opinion or rankings, things with no date, a source behind a login, key or form, or live data: it runs at most 24 times a day. Before you build, know who publishes the data and whether its terms let it be kept (Data rights), that each file is at a public https address under 20 MB, what each record's date means, the source's zone and rhythm, who should read it, and what the file looks like when it breaks.

Use your agent

init writes the road to the store as AGENTS.md, also a skill: SKILL.md. check --json and preview --json answer in codes.

Where to go next

Examples

• •
  Harbour Almanac: The kitchen-sink example: one plug-in that uses every part of contract 1 on an invented harbour, file by file, so you can copy the part you need.
• •
  DOP Economy: The real one: the Banco Central de la República Dominicana's reference rate for the dollar, read from its own workbook with no dependency, every business day.

The folder

• •
  plugin.json: plugin.json, decided in order, then every field from Kanboombo's own schema, every limit, and what changed in contract 1. Unknown keys are refused.
• •
  fetch.mjs: fetch.mjs reads the run context and your downloaded files, prints one record a line, and stops loudly when a file is not what it knows.
• •
  fixtures/: Copies of your sources and what they must give, so check runs your plug-in as the Server will, offline. preview draws the days; probe tries real sources.

How it works

• •
  How plug-ins run: Each minute the Server asks which plug-ins are due, downloads what their manifests declare, runs each fetcher with no network, and writes the run whole.
• •
  Records: What your fetcher prints, one JSON object a line: values, events and items. Their keys and dates, every rule a run is held to, and how each change is kept.
• •
  Dates and time zones: Your plug-in's today is the date in its manifest's zone, and a record's date is never converted. The mistakes everyone makes once, and how to avoid them.
• •
  How records look: How the app draws your records on a reader's day, and the words you choose: names in their language, plain figures, a change with no colour, events first.

Publish

• •
  Publish: From a plug-in that passes check to one in the Plug-in Store, through kanboombo://publish: by you in the portal, or by your agent with the tool.
• •
  Review and listing: What you give beside your code: five example days, three negative cases, each source's terms, release notes, five attestations, and the listing readers see.
• •
  Versions and updates: A person approves one exact version of your code, named by its digest. What the digest covers, the states of a plug-in, what an update may change, how one ends.
• •
  Data rights and audiences: Whose data it is, the name readers see beside it, its terms and whether Kanboombo may keep it; and who may read your plug-in. One holder per plug-in.
• •
  Guidelines: The rules every plug-in in the Plug-in Store follows, in numbered sections a reviewer can cite: purpose, quality, naming, safety, privacy, data and commerce.
• •
  Developer Agreement: What you agree to when your organization publishes calendar plug-ins in the Kanboombo Plug-in Store. Version 1, in plain language.

Reference

• •
  CLI: Every command of the plug-in tool and its options, generated from the tool itself. One file for Node 24, with no dependencies and no install.
• •
  Submission errors: Every problem a check can find, by its code: what it means and what to do. The same words the tool, the portal and the Server use, from one catalog.

Every page is Markdown too: add .md to its address, or read llms.txt and llms-full.txt.