OpenFn · lmac-1 · Sep 25, 2026 · Sep 25, 2026 · Sep 25, 2026 · Sep 25, 2026
diff --git a/.agents/skills/release-review/SKILL.md b/.agents/skills/release-review/SKILL.md
@@ -31,8 +31,8 @@ same way; docs changes always go in a PR on the docs repo.
    `git tag --sort=-creatordate --format='%(creatordate:short) %(refname:short)'`.
    Read every entry released in the period. Skip the Unreleased section.
    Lightning often lists a release's changes under its `-pre` heading, such as
-   `2.18.2-pre`, and leaves the final `2.18.2` empty, so read the `-pre`
-   entries too and report them under the final version.
+   `2.18.2-pre`, and leaves the final `2.18.2` empty, so read the `-pre` entries
+   too and report them under the final version.
 2. **Rewrite each entry as a change a user would notice**: a new feature, a
    renamed button, a new CLI flag, a changed default, a removed option. Drop
    internal changes like refactors, dependency bumps, and tests. Open the linked

diff --git a/.agents/skills/translate/SKILL.md b/.agents/skills/translate/SKILL.md
@@ -11,22 +11,21 @@ disable-model-invocation: true
 # Translate
 
 Translate English docs into Spanish (`es`) and French (`fr`). The English is
-always the source of truth. Translations are generated files that live in
-this repo. Save each one at the same path as the English page, under
+always the source of truth. Translations are generated files that live in this
+repo. Save each one at the same path as the English page, under
 `i18n/<locale>/docusaurus-plugin-content-docs/current/`. For example,
 `docs/build/triggers.md` goes to
-`i18n/es/docusaurus-plugin-content-docs/current/build/triggers.md`.
-Docusaurus ignores a file anywhere else without an error, and the page stays
-English.
+`i18n/es/docusaurus-plugin-content-docs/current/build/triggers.md`. Docusaurus
+ignores a file anywhere else without an error, and the page stays English.
 
-The sidebar headings come from `sidebars-main.js`, not from the pages. If it
-has new or renamed entries, run
+The sidebar headings come from `sidebars-main.js`, not from the pages. If it has
+new or renamed entries, run
 `yarn docusaurus write-translations --locale <locale>`. This adds them to
-`i18n/<locale>/docusaurus-plugin-content-docs/current.json` in English and
-keeps the ones already translated. Translate the new ones.
+`i18n/<locale>/docusaurus-plugin-content-docs/current.json` in English and keeps
+the ones already translated. Translate the new ones.
 
-Never translate the generated adaptor pages, the job library, the old v1
-docs, or articles and blog posts.
+Never translate the generated adaptor pages, the job library, the old v1 docs,
+or articles and blog posts.
 
 ## Before you start
 
@@ -38,9 +37,9 @@ Check these three things. If any fails, stop and ask.
 - `glossary.yml` and `translation-rules.yml` are valid YAML.
 
 Translate the English page exactly as it is on disk, so the hash you record
-matches what you translated. Do not reformat it; English changes belong in
-their own PR. After writing the translation, run
-`yarn prettier --write <files>` on only the files you changed under `i18n/`.
+matches what you translated. Do not reformat it; English changes belong in their
+own PR. After writing the translation, run `yarn prettier --write <files>` on
+only the files you changed under `i18n/`.
 
 ## Front matter
 
@@ -57,33 +56,32 @@ The hash is the content hash of the English file, from
 merges: a hash pointing at a commit made on a branch dangles as soon as the
 branch is squashed onto main. A content hash is the same wherever the file
 lives, and it answers the only question the field exists to answer: is the
-English still the version this was translated from? To compare, hash the
-current English file and check it against the recorded value.
+English still the version this was translated from? To compare, hash the current
+English file and check it against the recorded value.
 
 `translation_review_status` can be `machine`, `needs-review`, or
-`human-reviewed`. Only a human ever sets `human-reviewed`, and when they do
-they also add `translation_reviewer` and `translation_review_date`.
+`human-reviewed`. Only a human ever sets `human-reviewed`, and when they do they
+also add `translation_reviewer` and `translation_review_date`.
 
 ## Decide what to do with each page
 
 - **No translation yet.** Translate the whole page.
-- **The hash matches the current English file.** Skip it, whatever its
-  status. The English has not changed since it was translated. The one
-  exception: if `glossary.yml` or `translation-rules.yml` was committed more
-  recently than the translation (compare `git log -1 --format=%ct -- <file>`),
-  treat a `machine` page as if the hash no longer matches, so it picks up the
-  new rules.
-- **The hash no longer matches, and the status is `machine`, `needs-review`,
-  or missing.** Translate the whole page again, but keep any fenced blocks
-  (see below) exactly as they were.
-- **The hash no longer matches, and the status is `human-reviewed`.** Leave
-  the file out of the translation PR. Instead, open a separate PR for the
-  named reviewer that changes only the affected parts. Recover the English the
+- **The hash matches the current English file.** Skip it, whatever its status.
+  The English has not changed since it was translated. The one exception: if
+  `glossary.yml` or `translation-rules.yml` was committed more recently than the
+  translation (compare `git log -1 --format=%ct -- <file>`), treat a `machine`
+  page as if the hash no longer matches, so it picks up the new rules.
+- **The hash no longer matches, and the status is `machine`, `needs-review`, or
+  missing.** Translate the whole page again, but keep any fenced blocks (see
+  below) exactly as they were.
+- **The hash no longer matches, and the status is `human-reviewed`.** Leave the
+  file out of the translation PR. Instead, open a separate PR for the named
+  reviewer that changes only the affected parts. Recover the English the
   reviewer saw with `git cat-file -p <recorded hash>`, diff it against the
   current English, and translate only what changed. In the same PR, set
-  `translation_source_hash` to the current English hash and leave the status
-  as `human-reviewed`: the reviewer merging it approves it. If the old version
-  is no longer in the repo, say so and offer a full retranslation in that PR
+  `translation_source_hash` to the current English hash and leave the status as
+  `human-reviewed`: the reviewer merging it approves it. If the old version is
+  no longer in the repo, say so and offer a full retranslation in that PR
   instead.
 
 ## Fenced blocks
@@ -92,51 +90,52 @@ A human can wrap part of a translation like this:
 
 ```markdown
 <!-- do-not-retranslate -->
+
 Text a reviewer has corrected by hand.
 <!-- /do-not-retranslate -->
 ```
 
 Copy those blocks into the new translation exactly, in the same place. If the
-English they correspond to has been deleted, keep the block anyway and ask
-what to do with it.
+English they correspond to has been deleted, keep the block anyway and ask what
+to do with it.
 
 ## How to translate
 
 - Words in `glossary.yml` stay in English. For ordinary words that are also
-  product terms, like "run" or "step", keep the English only when the word
-  means the OpenFn thing.
+  product terms, like "run" or "step", keep the English only when the word means
+  the OpenFn thing.
 - Follow any rules for the locale in `translation-rules.yml`. By default,
   Spanish uses "tú" and French uses "vous".
 - Copy code blocks and inline code exactly. You may translate comments inside
   code.
 - Keep the names of things in the app, like buttons, menus, tabs, and field
   labels, exactly as they are in the English. The app is English only, so a
   translated button name points the reader at a button that does not exist.
-- Keep the same structure: same headings at the same levels, same lists,
-  same callouts, same components.
-- Keep internal links as they are in the English. Do not add `/es/` or
-  `/fr/`; Docusaurus adds the locale when it builds the page.
-- The one exception: a relative link like `../deploy/portability.md` breaks
-  if the page it points to has no translation yet. Write it as the page's
-  full address instead, like `/documentation/deploy/portability`. If the
-  target page sets a `slug` in its front matter, the address is
-  `/documentation` plus the slug: `slug: /api-tokens` gives
-  `/documentation/api-tokens`, not the folder path.
-- Give translated headings the original English anchor so existing links
-  still work.
+- Keep the same structure: same headings at the same levels, same lists, same
+  callouts, same components.
+- Keep internal links as they are in the English. Do not add `/es/` or `/fr/`;
+  Docusaurus adds the locale when it builds the page.
+- The one exception: a relative link like `../deploy/portability.md` breaks if
+  the page it points to has no translation yet. Write it as the page's full
+  address instead, like `/documentation/deploy/portability`. If the target page
+  sets a `slug` in its front matter, the address is `/documentation` plus the
+  slug: `slug: /api-tokens` gives `/documentation/api-tokens`, not the folder
+  path.
+- Give translated headings the original English anchor so existing links still
+  work.
 
 ## Before you commit
 
-Check that the fixed glossary terms (the ones without `product_noun: true`,
-such as OpenFn, Lightning, adaptor, webhook) appear as many times as in the
-English. Product nouns like "run" and "step" are allowed to differ, since
-their ordinary-English uses get translated. Before counting, join each file
-into one line with single spaces: Prettier wraps prose at 80 columns, and
-English and Spanish wrap at different points, so a multi-word term like "work
-order" can sit across a line break in one file and not the other. Check the
-code blocks are identical. Check the counts of headings, code blocks,
-callouts, images, and tables match. Check the front matter is complete. Check
-every fenced block survived. Then build the site and make sure it passes:
+Check that the fixed glossary terms (the ones without `product_noun: true`, such
+as OpenFn, Lightning, adaptor, webhook) appear as many times as in the English.
+Product nouns like "run" and "step" are allowed to differ, since their
+ordinary-English uses get translated. Before counting, join each file into one
+line with single spaces: Prettier wraps prose at 80 columns, and English and
+Spanish wrap at different points, so a multi-word term like "work order" can sit
+across a line break in one file and not the other. Check the code blocks are
+identical. Check the counts of headings, code blocks, callouts, images, and
+tables match. Check the front matter is complete. Check every fenced block
+survived. Then build the site and make sure it passes:
 
 ```bash
 yarn generate-library
@@ -145,11 +144,11 @@ yarn build
 ```
 
 Build the whole site, not just your locale. `yarn build --locale <locale>`
-builds the locale at the site root, so every correct `/es/...` link shows up
-as broken.
+builds the locale at the site root, so every correct `/es/...` link shows up as
+broken.
 
 Open one PR per locale, separate from the English PR. Translated files do not
-count toward the 20-file limit, because a locale's translations are reviewed
-as a set. In the PR description, say which tool and model translated the
-pages. If you spot a problem in the English while translating, note it for
-the next English pass; do not fix it here.
+count toward the 20-file limit, because a locale's translations are reviewed as
+a set. In the PR description, say which tool and model translated the pages. If
+you spot a problem in the English while translating, note it for the next
+English pass; do not fix it here.
diff --git a/.git-blame-ignore-revs b/.git-blame-ignore-revs
@@ -0,0 +1,2 @@
+# Prettier reformat of the whole project
+f5bf343eabd5fe6896f4945bc17887b6a3763183
diff --git a/README.md b/README.md
@@ -119,14 +119,15 @@ Builds to `main` will automatically be deployed to
 [docs.openfn.org](https://docs.openfn.org). This branch is protected, but we
 welcome pull requests!
 
-
 ### To add help sections to all adaptor files:
+
 ```bash
 yarn run add-help-sections
 # or
 node scripts/add-help-section.js
 ```
 
 ### For new adaptor files:
-When creating new adaptor documentation files, make sure to run `npm run add-help-sections` to add the standard help section.
 
+When creating new adaptor documentation files, make sure to run
+`npm run add-help-sections` to add the standard help section.
diff --git a/adaptors/asana.md b/adaptors/asana.md
@@ -4,25 +4,45 @@ title: Asana Adaptor
 
 ## About Asana
 
-[Asana](https://app.asana.com/) is a web-based project management tool that helps teams organize, plan, collaborate, and execute tasks. 
+[Asana](https://app.asana.com/) is a web-based project management tool that
+helps teams organize, plan, collaborate, and execute tasks.
 
 ## Integration Options
 
 Asana supports 2 primary integration options:
 
-1. Rest API: Asana has an available REST API that enables external services like OpenFn to pull data from Asana, or push data from external apps to Asana. This option is suited for scheduled, bulk syncs or workflows that must update data in Asana with external information. See [functions](/adaptors/packages/asana-docs) for more on how to use this adaptor to work with the API.
+1. Rest API: Asana has an available REST API that enables external services like
+   OpenFn to pull data from Asana, or push data from external apps to Asana.
+   This option is suited for scheduled, bulk syncs or workflows that must update
+   data in Asana with external information. See
+   [functions](/adaptors/packages/asana-docs) for more on how to use this
+   adaptor to work with the API.
 
-2. Webhook: Asana also has a [Webhook or Data Forwarding](https://developers.asana.com/docs/webhooks-guide) to push data from Asana to external systems. This option is suited for real-time, event-based data integration. Check out the Asana [developer documentation](/adaptors/packages/asana-docs) to learn how to set up a webhook to push data to OpenFn.
+2. Webhook: Asana also has a
+   [Webhook or Data Forwarding](https://developers.asana.com/docs/webhooks-guide)
+   to push data from Asana to external systems. This option is suited for
+   real-time, event-based data integration. Check out the Asana
+   [developer documentation](/adaptors/packages/asana-docs) to learn how to set
+   up a webhook to push data to OpenFn.
 
 ## Authentication
 
-See [Asana docs](https://developers.asana.com/docs/authentication) for the latest on supported authentication methods. 
+See [Asana docs](https://developers.asana.com/docs/authentication) for the
+latest on supported authentication methods.
 
-When integrating with Asana via OpenFn, there is one primary authentication method that is supported: **Personal Access Token (PAT)**. You can generate a personal access token from the Asana [developer console](https://developers.asana.com/docs/personal-access-token).
+When integrating with Asana via OpenFn, there is one primary authentication
+method that is supported: **Personal Access Token (PAT)**. You can generate a
+personal access token from the Asana
+[developer console](https://developers.asana.com/docs/personal-access-token).
 
-See this adaptor's [Configuration docs](/adaptors/packages/asana-configuration-schema) for more on the required authentication parameters.
+See this adaptor's
+[Configuration docs](/adaptors/packages/asana-configuration-schema) for more on
+the required authentication parameters.
 
-See platform docs on [managing credentials](/documentation/manage-projects/manage-credentials) for how to configure a credential in OpenFn. If working locally or if using a Raw JSON credential type, then your configuration will look something like this:
+See platform docs on
+[managing credentials](/documentation/manage-projects/manage-credentials) for
+how to configure a credential in OpenFn. If working locally or if using a Raw
+JSON credential type, then your configuration will look something like this:
 
 ```
 {
@@ -37,10 +57,16 @@ See platform docs on [managing credentials](/documentation/manage-projects/manag
 
 ### Implementation Examples
 
-1. The Wildlife Conservation Society (WCS) - KoboToolBox -> GoogleSheets -> Asana sync: [https://openfn.github.io/ConSoSci/asana/](https://openfn.github.io/ConSoSci/asana/)
+1. The Wildlife Conservation Society (WCS) - KoboToolBox -> GoogleSheets ->
+   Asana sync:
+   [https://openfn.github.io/ConSoSci/asana/](https://openfn.github.io/ConSoSci/asana/)
 
 ### I've noticed a problem with this Adaptor, or something is out of date, what can I do?
 
-Thanks for asking! We are a fully Open Source Digital Public Good, and we welcome contributions from our community. Check out our [Adaptors Wiki](https://github.com/OpenFn/adaptors/blob/main/wiki/index.md) for more information on how you can update Adaptors!
+Thanks for asking! We are a fully Open Source Digital Public Good, and we
+welcome contributions from our community. Check out our
+[Adaptors Wiki](https://github.com/OpenFn/adaptors/blob/main/wiki/index.md) for
+more information on how you can update Adaptors!
 
-Or, you can always reach out to the Community through our [Community Forum here](https://community.openfn.org/).
+Or, you can always reach out to the Community through our
+[Community Forum here](https://community.openfn.org/).
Original file line number	Diff line number	Diff line change
		@@ -0,0 +1,2 @@
		# Prettier reformat of the whole project
		f5bf343eabd5fe6896f4945bc17887b6a3763183