feat: auto-generate README repository table and software tools section

[bcastets-robotiq]

Summary

• Restructure profile/README.md with a prominent link to the docs site, and two auto-generated sections between marker comments: Repositories (pulled from the GitHub API) and Software tools (imported from robotiq/robotiq.github.io's docs/intro.mdx).
• Add scripts/update-readme.mjs, which regenerates both sections and fails loudly (refuses to write) if the docs site's expected markers are missing or the org's repo list comes back empty — instead of silently publishing broken/partial content.
• Add .github/workflows/update-readme.yml, running daily (and on demand), which opens a PR only when content actually changed and auto-merges it.

Note

The auto-merge step needs a README_BOT_PAT repo secret (fine-grained PAT scoped to this repo, Contents + Pull requests: write) — see the comment at the top of update-readme.yml for why a second bot identity is required. Until that secret is added, the workflow will open PRs but fail at the approve/merge step.

Test plan

• Ran scripts/update-readme.mjs locally against the live GitHub API and the live docs site — verified output.
• Verified the script fails safely (no partial writes) when a marker is missing, confirmed against a real upstream rename that happened mid-development.
• Add README_BOT_PAT secret and trigger the workflow manually (workflow_dispatch) to confirm the PR/auto-merge flow end-to-end.

🤖 Generated with Claude Code

[mbegin-robotiq]

Suggestion: a small unit test suite, wired in as a required check

Four of the review comments on this PR are the same shape — pure-logic bugs that ship silently because nothing verifies the script's output:

• a $& in a repo description splicing README text into itself (L135)
• a half-written README when a marker pair is missing (L158)
• relative doc links other than ](drivers/ resolving to 404s (L97)
• upstream intro.mdx format drift

None of these need the network, the GitHub API or the filesystem to catch. A handful of assertions would cover all four:

Test	Catches
a description containing $& round-trips literally	L135
missing SOFTWARE-TOOLS marker leaves the README unchanged	L158
](img/, ](./drivers/, ](/docs/drivers/ → absolute, or throw	L97
fixture intro.mdx → expected section	upstream drift
running twice produces identical output	idempotence

node:test + node:assert, no dependencies, one committed fixture — roughly 60 lines.

The prerequisite is a small refactor: writeBetweenMarkers and the fetch helpers currently mix I/O with logic, so none of it is reachable from a test. Splitting out pure replaceBetweenMarkers(text, key, content) and buildRepoTable(repos) — taking plain data, returning strings — with main() as the only thing touching the network and disk, makes the tests trivial to write. That refactor also fixes the atomicity problem in the L158 comment for free.

Why it's worth more than the bugs it catches: it gives this repo the required status check it's currently missing. Wire the suite into prToMain as a required check and gh pr merge --auto becomes meaningful — the daily PR waits on the tests, and a broken README sits as an open failing PR instead of landing on the org's public page. That's precisely the safety property build-and-test provides on the docs site, and the reason that workflow's comment can argue merging without a human is safe. Right now this PR inherits the argument without the mechanism.

It also covers the failure mode this script is most exposed to: intro.mdx is generated in another repo and can change shape without warning. The marker checks catch a rename; they don't catch a table gaining a column or a link shape changing.

Happy to write the suite and the refactor as a follow-up PR if useful.