How an entry is written, checked and kept current

The information model

Outcome

What you have at the end. If it cannot be stated in one sentence, the entry is too broad.

Use it when / Skip it when

The fit test. Skip-when lines are required, because knowing when not to use a method is part of the method.

Before you start

Prerequisites: data, access, permissions and people you need first.

Steps and checkpoints

Three to nine steps. Every step ends with a checkpoint you can verify before moving on.

Works in

Environments with full or partial support and a note. Environments that are not listed were not tested.

Effort

Setup minutes (once) and minutes per run. Estimates from the reviewer's run, not guarantees.

What can go wrong

Safety notes, each tagged with a risk type: accuracy, privacy, security, cost, rights or effect on people.

Review record

State, version, last review date and revision history. Review due is computed against the catalogue date.

Review states

Reviewed

Steps were re-run end to end at the recorded review.

Needs review

Published, but something it depends on changes quickly; re-run before relying on it.

Draft

Not published. Drafts are validated but kept out of the site.

An entry is marked review due when its last review is more than 180 days before the catalogue date (1 Mar 2026, a fixed demo date). The build computes this; nobody sets it by hand, and the visitor's clock is never used.

Environments

Environments are kinds of tool, not brands, so entries stay true as products change.

• Chat assistant (Chat)
• Model API and scripts (API)
• Coding agent in a repository (Agent)
• Spreadsheet (Sheet)
• Local model on your machine (Local)
• No-code automation (Flow)

What demo means here

Every entry in this build has "demo": true and the build refuses entries without it. The procedures are written carefully and are meant to be sound, but they were written to prove the format: they are not an exhaustive catalogue, not endorsed by any vendor, and their review dates and version histories are sample records rather than a real editorial log. Worked examples use fictional inputs.

Adding an entry

1. Create a draft: python3 tools/new_skill.py my-skill-id "Title of the skill". It writes data/skills/my-skill-id.json with the next free code and the state draft.
2. Fill in every field. Run python3 build.py --check; it lists every problem with the file and field.
3. Run the steps end to end yourself. Then set the state to reviewed, add reviewed_on and a history entry.
4. Run python3 build.py and python3 tools/audit.py before publishing.

What works now, and what does not yet