[larnsce]

Addresses #99

This PR stays open until washr 1.3.0 is released. The new add-doi step calls washr::data_availability_statement(), which exists from washr 1.3.0, and the floor moves to 1.3.0 in the same PR.

Changes

• skills/add-doi/SKILL.md
  • Step 7: the Zenodo record review confirms what washr 1.3.0 writes into .zenodo.json (resource type Dataset, the website link in the description, the repository as isSupplementTo and the website as isDocumentedBy, write_zenodo_json(): link the package website in the Zenodo description and related identifiers washr#154) instead of asking for them by hand. It says that the GitHub integration only requests the community and names the request inbox (https://zenodo.org/communities/[community]/requests) where a curator accepts it.
  • New Step 9: asks for the opening words of the statement, offers the default "The data", and runs washr::data_availability_statement() on main (data_availability_statement(): draft the citation and data availability text for the article that uses a data package washr#155). It runs before the dev sync, because after the development version is set the text would name an unreleased version. The dev sync becomes Step 10.
  • Prerequisites and Step 1: washr 1.3.0 or newer.
• skills/create-release/SKILL.md: follows the renumbering (add-doi steps 2 to 10, Step 10 for the development version) and names the new step.
• Floor 1.3.0 throughout: WASHR_FLOOR, the check script fallback, both org profiles, the /washr, /add-doi and /create-release preflights, the standards file, the orgs README, the README requirements and compatibility table (new 1.9.0 row).
• NEWS.md: a pkgreview 1.9.0 section. VERSION and the plugin versions are not bumped; that happens at the release after washr 1.3.0.

Deviations from the issue text are recorded on #99: the new step sits before the dev sync, not at the end, and the /washr preflight follows the shared floor.

Decisions (approved)

1. The floor bump to 1.3.0 is in this PR.
2. The skill asks for the subject of the statement each run and offers the default "The data".
3. washr 1.3.0 is not on CRAN, so the gate and drift workflows keep installing washr from the dev branch on GitHub. Switching them back to install.packages("washr") is a follow-up once CRAN serves 1.3.0.

Checks

Run locally against washr dev at 34620d8 (version 1.2.2.9000, with openwashdata/washr#157 merged):

• scripts/lint.sh: clean.
• bash fixtures/run_gate.sh: both expected reports match, 19 FAIL and 1 FLAG lines as in the scorecard. The check script accepts a development build of washr below the floor.
• bash fixtures/run_cases.sh: all cases ok.
• Rscript scripts/washr_drift.R: every named washr call is exported, including data_availability_statement. It exits 1 with "FLOOR: installed washr 1.2.2.9000 is below the recorded floor 1.3.0", which is expected until washr dev carries version 1.3.0. The drift workflow runs on pushes to dev and main, not on pull requests, so it shows this only after a merge; another reason to merge after the washr release.

[larnsce]

Added #101 to this PR: /create-release Step 2 now sets the DESCRIPTION Date to the release day next to the version (with a NEWS bullet in 1.9.0).

[larnsce]

Added #103 to this PR (c.f. the commit 'the version follows the data'): /add-doi Step 10 only syncs dev with main and no longer sets x.y.z.9000; /create-release drops its development version note; the standards file gains the versioning rule (major, minor, patch, none). The /review-issue part of #103 (a data-changing review PR sets the development version) is not in this PR and stays open on #103.