Install any skill in seconds. Free to start, no credit card required.
Get Started Free →liferay/pr-check-publish
Comment a pr-check run on an existing GitHub PR with a marker the webhook parses to apply the commit status and label. Use after rerunning pr-check on an open PR.
Passed 16 of 22 test cases with the skill, and 9 of 22 without it.
and 9 more in the full report
9 fixed8 passed either way5 still failing1 broke
Tokens, turns and time describe resource use, not a dollar price.
This benchmark measured an earlier version of the skill.
A newer attempt on gemini-3.8-flash on 10/21/2026 did not produce a publishable comparison (not comparable). The snapshot above is the previously measured run.
One of 8 test cases the skill fixed. Same model, same prompt, with and without the skill.
Publish my session's pr-check results to pull request issue 77123 using the URL format https://github.com/liferay/liferay-portal/issues/77123.
| Checked | Without skill | With skill |
|---|---|---|
| Rejects URLs that do not match the GitHub pull request format | Missed | Passed |
| Requests a pull request URL conforming to https://github.com/<target-org>/liferay-portal/pull/<number> | Missed | Passed |
The instructions your model reads when the skill loads.
Post the pr-check Results Summary as a comment on an existing GitHub PR, ending the comment with a hidden marker. The webhook parses that marker and applies the pr-check commit status to the tested SHA and the pr-check - <state> label to the PR — this skill never writes the status or label itself, so it works the same whether or not the user has write access on the target repository.
Newly created PRs do not need this skill: the pr skill writes the same Results Summary and marker into the PR description at creation, and the webhook reads it from there. Reach for this skill only to record a later run — for example after pushing more commits and rerunning pr-check on an open PR — where the description no longer reflects the current head.
${ARGUMENTS} carries a PR URL of the form https://github.com/<target-org>/<repository>/pull/<number>, where <repository> is liferay-portal or liferay-portal-ee. The webhook applies the status and label to a pull request in either. When missing or malformed, abort and ask the user for the URL.
Use the Results Summary block emitted by the pr-check run in the current session — the overall state line, the tested SHA, the table of validations, and every note appended below it. Any row can carry a note, a PASS included, so carry them all verbatim. When no Results Summary is available (pr-check has not run this session), abort and ask the user to run pr-check first; this skill records a run, it does not perform one.
The tested SHA must be the current head of the pull request:
gh pr view \
--jq .headRefOid \
--json headRefOid \
"<pr-url>"
A session can hold runs of several branches, so use the Results Summary whose tested SHA is that head. When none matches, abort without posting and name the head SHA and every tested SHA. Posting a run of any other commit would record its status on a commit that the pull request does not show.
Post a fresh comment on each run rather than editing a prior one, so the PR keeps a chronological record. The comment body is the Results Summary verbatim, a blank line, then the marker — an HTML comment, invisible in rendered Markdown, whose payload is a JSON object of the form <!-- pr-check {"result": "<state>", "sha": "<tested-SHA>"} -->, where <state> is success when the overall state is PASS and failure when it is FAIL, so a run carrying NO COVERAGE or NOT VERIFIED rows records success, and <tested-SHA> is the full 40-character SHA from the Results Summary:
**pr-check: PASS** — tested on `<tested-SHA>`
| Validation | Result |
| --- | --- |
| Source Format | PASS |
| Full Portal Build | PASS |
test cases passed, vs 9 / 22 without
More skills from the same source and nearby in the registry, with their headline benchmark lift.