docs: audit per-action READMEs for inputs/outputs parity with action.yaml

[devantler]

🤖 Generated by the Daily AI Assistant

Part of #181.

Problem

CONTRIBUTING.md ships an explicit README template that every per-action README.md is expected to follow:

## Inputs

| Name | Description | Required | Default |
|------|-------------|----------|---------|

## Outputs

| Name | Description |
|------|-------------|

But the per-action READMEs were authored at different times against an evolving template, and there is no automated check that:

1. Every input declared in action.yaml appears in the README's ## Inputs table with matching required + default columns.
2. Every output declared in action.yaml appears in the README's ## Outputs table.

Four actions declare outputs in action.yaml (setup-agent-skills → installed-skills; setup-go-toolchain → go-version; update-agent-skills → changed, updated-skills; upsert-issue → issue-number). Whether each of those is documented matching what's exposed is currently unknown. Same for inputs across all 15 actions. Silent drift is likely — when a new input is added (e.g. setup-agent-skills gaining agents: for multi-agent installs), the README can lag the action.yaml.

Proposed direction

Two-step audit, both in one focused PR:

1. Manual parity audit — read each action's action.yaml and README.md side by side; correct any drift (missing input/output rows, wrong defaults, wrong required flag, stale descriptions). Keep diffs tight — this is a documentation pass, not a refactor.

2. Optional, evaluate during the PR: add a lightweight CI guard so future drift is caught — e.g. a check-readme-parity job that diffs yq-extracted input/output names against grep-extracted README table rows for each action. If the guard adds material complexity for marginal gain, leave it out and capture as a follow-up issue rather than blocking the audit on tooling.

Acceptance criteria

• Every action's README.md has an ## Inputs table that lists every input declared in its action.yaml, with matching required and default columns.
• Every action with outputs: in its action.yaml (setup-agent-skills, setup-go-toolchain, update-agent-skills, upsert-issue — verify the list during the PR) has an ## Outputs table that lists each output with a description.
• PR body summarises drift found per action (one bullet each), so the audit's value is legible in the changelog.
• If a CI parity-check job is added, it must be actionlint-clean and pass first try on every action.

Out of scope

• Rewriting per-action READMEs for style; this is a parity audit, not a copy edit.
• Touching the README template in CONTRIBUTING.md (unless the audit reveals a structural issue with the template itself, in which case open a follow-up — don't bundle).
• Cross-repo audits (e.g. checking reusable-workflows workflow_call inputs vs their README) — that's a separate roadmap item if/when warranted.

Labels

documentation.