Repository navigation
Merged
Conversation
…69) A review of one package takes about a dozen answers plus five merges, which is why contributors' packages queue. Option B of #69 removes the two actions that carry no judgement once the facts are on the issue: the plan approval at CHECK-IN #1 and the merge of the per-issue PR into dev. /review-issue [n] --unattended posts the plan on the issue, implements it, opens the PR against dev, waits for its checks and merges with --merge only when an R-CMD-check run passed, no other check failed and every required item is checked. A preflight sends the run back to attended mode when the workflow file is missing on dev or the session has no merge rights. Anything short of a clean merge falls back to the attended handover with the reasons named. The unattended path is an explicit branch in the SKILL.md bodies, at the point of action. No stop was removed: a PII or history finding stops the run, the PII item is checked only against a human record, descriptions are never written by the run, and the evidence rule decides every required item. /create-next-issue --unattended still creates one issue and stops; the flag turns its one question into a stop and names the unattended command in the handover. The issue number is now written [issue-number] in the commands, because $ARGUMENTS can carry the flag. docs/guardrails.md records how the three layers hold in both modes, recovery.md gains failure mode 12 for a run that ended without a merge. Assisted-by: Claude claude-fable-5-1
…r release (#55) The three items of #55 that were accepted on 2026-10-01. /create-release gets a Step 0 preflight with the checks of /add-doi Step 1 and a remedy for each: branch, clean tree, desc, usethis and washr installed, the washr floor, the organization profile. Before, the later skill was the stricter one and the release skill listed its prerequisites as prose. NEWS.md becomes a maintained file. /review-issue Step 4 adds one bullet per review area under the development heading, and /create-release Step 3 renames that heading instead of rebuilding the section from the PR list. The old path stays for reviews that predate the practice. After a release, dev gets the development version: use_dev_version(), then update_citation(build = FALSE) so the citation files follow and the version line of the check script stays green on dev. The step sits after the last dev sync of the release flow, in add-doi Step 9, which /create-release Step 5 runs. The triage comment placed it after the first sync, in create-release Step 4. A test showed that a bump there makes the later DOI sync a merge with a conflict in CITATION.cff, on every release, because the DOI commit on main and the version bump on dev change adjacent lines. Release posts get an outline under references/templates/ and no skill, as the triage comment recommends. Assisted-by: Claude claude-fable-5-1
washr 1.2.0 made every function report in three fixed line kinds and return what it wrote, added update_dictionary() and check_publication_readiness(), and moved the organisation values into DESCRIPTION. That is what a driver needs, and openwashdata/washr#115 specifies the driver: a skill in this plugin, next to the review skills, so authors and reviewers install one plugin (decision J in openwashdata/washr#111). skills/washr/SKILL.md runs the washr functions through Rscript in the order of the vignette, reads their output, and drafts the prose no function can write (variable descriptions, roxygen titles, README text) for the person to confirm. Its rules sit in the skill body: the person's drafts are the source of truth, every edit is proposed with a reason, data files are never modified, hand written sections are never overwritten without asking, work from summaries and never from raw rows, no LLM key is a prerequisite, no scripts, local only. It ends with a fix loop against check_publication_readiness() and hands over to the review and release skills. references/ holds the writing conventions taken from the washr vignette and templates, the checklists and the guidebook: variable descriptions with units and allowed values, keywords and coverage, README sections, the pkgdown site. The review standard stays in the checklists and is referenced by path. No controlled WASH vocabulary exists in any of the sources, and the reference says so instead of adding one. Every command in the skill was run in order on a scratch package built from one CSV, with washr 1.1.1.9000 (the 1.2.0 development version), including the multi dataset loop. The package ended with no failing readiness item and a clean R CMD check. The skill is registered in the marketplace manifest, the README, the guidebook and CLAUDE.md. VERSION, the manifest versions and NEWS.md are left for the 1.7.0 integration. Refs #88, openwashdata/washr#115, openwashdata/washr#83, openwashdata/washr#103 Assisted-by: Claude claude-fable-5-1
The three sections were frozen in v1.5.0 (#66) to wait for washr::check_publication_readiness() (openwashdata/washr#82), which washr 1.2.0 ships. Two implementations of the same checks in two repositories would drift, so the script now calls washr once and prints its rows. What stays here is pkgreview's own knowledge: which rows become report lines, at which tier and under which text, and whether a row washr cannot decide prints NOT RUN or nothing (the WASHR_LINES table). The data-quality checks, the dictionary lines of the data area, the PII scan, and the history scan are untouched. Both expected reports and the nine cases are byte identical before and after, on both organization profiles and on the deprecated --analytics path, so no checklist item and no scorecard mapping changes. washr is now a dependency of the script. It stops with a message when washr is missing, lacks the function, or is a release below WASHR_FLOOR, and on a directory without DESCRIPTION and NAMESPACE. The history fixture gains an empty NAMESPACE for that reason, and the gate workflow installs washr from CRAN. Assisted-by: Claude claude-fable-5-1
The check script calls washr::check_publication_readiness(), which is new in washr 1.2.0, so 1.2.0 is the lowest version the standard supports from 1.7.0 on. WASHR_FLOOR carries the value; the copies in the two organization profiles, the standards file, the /add-doi prerequisites, and the README follow, and the compatibility table gains the 1.7.0 row. The two literals in skills/create-release/SKILL.md are left for the integration step, because the release practice branch rewrites that preflight (#55). Assisted-by: Claude claude-fable-5-1
Part 2 of the spike was blocked on washr::update_dictionary() (openwashdata/washr#13). Rerun against the washr 1.2.0 development build: extra columns and descriptions survive an unchanged rerun and a data change, and fill_dictionary() is no longer exported. The roadmap entry of the spike names the result, so the schema extension items (#38, #39) are no longer read as blocked. Assisted-by: Claude claude-fable-5-1
# Conflicts: # CLAUDE.md
washr 1.2.0 writes .zenodo.json with the citation files. Zenodo reads the file from the release tag for the resource type, the community, the creators and the license, so /create-release has to carry it in the release commit and /add-doi in its two commits. Without this the file stays untracked and a release is still filed as Software in no community. The floor wording of both preflights follows 1.2.0. Refs openwashdata/washr#56, #87 Assisted-by: Claude claude-fable-5-1
CRAN serves washr 1.1.0 until 1.2.0 is released there, which is below
the floor of 1.2.0 that the check script and the drift check need. The
gate and drift workflows now install openwashdata/washr@dev with pak,
so this branch can land on dev before the CRAN release. Both go back
to install.packages("washr") once CRAN serves the floor.
The drift note now names the installed washr, and the NEWS section and
the reconciliation note say where washr comes from.
Refs #87
Assisted-by: Claude claude-fable-5-1
pkgreview 1.7.0: check script from washr, washr skill, unattended mode, release practice
… guide The guidebook keeps the chapters only pkgreview owns: the PII and sensitivity check, the publication floor and what review looks like. The scaffold, dictionary and publication chapters become one pointer paragraph each to the guide at openwashdata/fair-publishing, which owns the build instructions, so no two documents carry the same steps (openwashdata/washr#85). README and NEWS follow. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_0154SimLT4PMoMfR91HPbiy9
docs(guidebook): point the build chapters at the FAIR Data Publishing guide
Reverts 74b90f1. CRAN published washr 1.2.0 on 2026-10-28, so the gate and drift workflows go back to install.packages("washr"). The NEWS line for 1.7.0 says so. Assisted-by: Claude Fable 5.1 Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_0154SimKTqEsiqCGKw7ryivs
Assisted-by: Claude Fable 5.1 Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_0154SimKTqEsiqCGKw7ryivs
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Closes #87
Closes #88
Closes #55
Closes #37
Test plan