Record a later `pr-check` Results Summary on an existing GitHub pull request. The skill adds a marker that a webhook reads to apply the tested commit’s status and a matching PR label; it does not run checks or set either value itself.
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.
Run score Not tested
See how to installReview the instructions the agent will receive before you install.
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 |
| Java Unit Tests | PASS |
<!-- pr-check {"result": "success", "sha": "<tested-SHA>"} -->
When build/test-plan/result.json exists and its head is the tested SHA, add a Test plan: <count> run, <passed> passed. line between the Results Summary block and the marker. Leave it out otherwise. Put a blank line before and after it. <count> is the number of entries in tests. <passed> is the number of those entries whose result is passed.
Post the body with --body-file, or with --body from a quoted-heredoc variable; either keeps the marker's literal ! off the command line, where it could otherwise trigger history expansion and corrupt the marker. Use mktemp for the file so it stays out of the working tree, and remove it afterward.
comment_file=$(mktemp)
gh pr comment \
--body-file "${comment_file}" \
"<pr-url>"
rm "${comment_file}"
When the comment fails to post, surface the error — without it the webhook has nothing to parse, so the status and label will not appear.
Report back to the user with:
pr-check commit status and pr-check - <state> label are applied by the webhook once it processes the comment, and so may lag the comment by a moment.No reviews yet. Tell others what you thought.
No login needed. Share how it worked for you, ask a question, or note where it did not run.
No comments yet. Be the first to write one.
Use this skill to format Liferay source files according to the project’s conventions. It describes the formatter workflows for modules and committed changes, how to handle Go and shell files, and which generated files to leave untouched.
Use this skill to file a bug in the LPD Jira project from a description or fix commit. It gathers reproduction steps and expected versus actual behavior, applies required project fields, and returns the created ticket key and link.
Use this skill to create a Task ticket in the LPD Jira project from a description or commit. It gathers missing details, selects a matching component, formats the description with acceptance criteria when applicable, and returns the ticket key and link.
Format Markdown files for Liferay repositories by aligning front matter, heading capitalization, shell examples, and prose with the project’s style rules. Use it to clean up or copy-edit a document and receive a summary of the changes.
Analyzes a Liferay Poshi `.testcase`, checks feasibility and existing coverage, then routes each test to Playwright, Jest, JUnit unit, or Java integration tests. It creates a migration plan and can implement the approved changes using repository patterns.
Plan and carry out a reduction of a Liferay component’s Poshi test suite by identifying overlapping tests and combining their unique assertions. The skill inventories matching test files, preserves tests with special setup or properties, and commits each planned rename or merge separately.