Problem
Both README usage examples pin the action to the mutable main branch (README.md:38 and README.md:92, uses: dceoy/opencode-action@main), even though the repo cuts versioned releases (v0.0.1 … v0.2.4) and CI actively maintains a floating v0 major tag via the github-major-version-tag job (.github/workflows/ci.yml:41-47).
Evidence
gh release list → releases through v0.2.4 (latest).
gh api repos/dceoy/opencode-action/git/ref/tags/v0 → 3093e53…, the commit of the latest release — i.e. the v0 tag is correctly synced on every release.
AGENTS.md itself instructs: "Keep third-party actions pinned by full commit SHA when practical."
Impact
Consumers copying the README track every unreviewed commit on main — including behavior overhauls like the recent review-output changes (#9–#11) — instead of released versions. It also makes the release/major-tag automation the repo maintains effectively pointless, and is inconsistent with the repo's own pinning guidance.
Suggested fix
Change both examples to uses: dceoy/opencode-action@v0, and add a short note that users can pin to an exact release tag (e.g. @v0.2.4) or commit SHA for stricter supply-chain control.
Validation
Run a consumer workflow with uses: dceoy/opencode-action@v0 and confirm it resolves to the latest release commit; run .agents/skills/local-qa/scripts/qa.sh for docs formatting.
Problem
Both README usage examples pin the action to the mutable
mainbranch (README.md:38andREADME.md:92,uses: dceoy/opencode-action@main), even though the repo cuts versioned releases (v0.0.1 … v0.2.4) and CI actively maintains a floatingv0major tag via thegithub-major-version-tagjob (.github/workflows/ci.yml:41-47).Evidence
gh release list→ releases throughv0.2.4(latest).gh api repos/dceoy/opencode-action/git/ref/tags/v0→3093e53…, the commit of the latest release — i.e. thev0tag is correctly synced on every release.AGENTS.mditself instructs: "Keep third-party actions pinned by full commit SHA when practical."Impact
Consumers copying the README track every unreviewed commit on
main— including behavior overhauls like the recent review-output changes (#9–#11) — instead of released versions. It also makes the release/major-tag automation the repo maintains effectively pointless, and is inconsistent with the repo's own pinning guidance.Suggested fix
Change both examples to
uses: dceoy/opencode-action@v0, and add a short note that users can pin to an exact release tag (e.g.@v0.2.4) or commit SHA for stricter supply-chain control.Validation
Run a consumer workflow with
uses: dceoy/opencode-action@v0and confirm it resolves to the latest release commit; run.agents/skills/local-qa/scripts/qa.shfor docs formatting.