Create a GitHub pull request from the current branch, assemble its title and description from the branch’s commits, and connect it to the relevant Jira tickets. The workflow also runs the required PR check and records the new PR URL on each ticket.
Create a GitHub PR for the current branch. Use when the user asks to create a PR, send a PR, or invokes /pr.
Run score Not tested
See how to installReview the instructions the agent will receive before you install.
Create a GitHub PR for the current branch, transition the linked Jira tickets to review, and record the PR URL on those tickets.
The base branch is master in liferay/liferay-portal and master-private in liferay/liferay-portal-ee. Use the base branch of the repository that a remote of this checkout points at (check git remote --verbose).
Below, ${BASE_BRANCH} stands for that base branch, and <repository> stands for that repository without its organization, such as liferay-portal.
At least one commit adds tests. When none do, ask the user for a rationale and refuse to proceed without one. The only exceptions are PRs with no code changes (e.g., language key updates or markdown changes).
The current branch is a development branch, not ${BASE_BRANCH} or any other protected branch.
The pr-check skill must pass. Skip only when ${ARGUMENTS} contains --skip-pr-check. A skip requires a reason: take it from the text following the flag when present, otherwise prompt the user for one. The reason is recorded in the PR Check section, which is written for a skip rather than omitted. When ${ARGUMENTS} contains --skip-pr-reviewer, pass the flag and the text following it to pr-check, which skips only its PR Reviewer validation.
The current Git branch must contain the commits ready to ship.
A branch may span more than one ticket. Resolve the ticket set — every ticket the PR touches.
The ticket key follows the pattern LPD-12345, LCD-12345, LRCI-1234, and similar forms (uppercase letters, hyphen, digits).
Collect every distinct ticket key from the subjects of the branch's commits relative to ${BASE_BRANCH}. Each subject is prefixed with its ticket (LPD-12345 <subject>); extract every distinct key, in commit order (oldest first). When no commit carries a ticket, prompt the user for one.
The target repository defaults to <fork-owner>/<repository>. When ${ARGUMENTS} names a different org/repo, use that; when it matches an alias below, expand the alias; otherwise, ask the user to choose <fork-owner> from the teams below, leaving out any team that has no fork of <repository>:
liferay-acliferay-appsecliferay-bpmliferay-commerceliferay-content-managementliferay-core-infraliferay-database-infraliferay-devtoolsliferay-frontendliferay-headlessliferay-page-managementliferay-platform-experienceliferay-searchliferay-site-managementWhen the pr-check run reports that the branch sits on the forward target and ${ARGUMENTS} names no repository, use the forward target instead of asking.
The following short aliases resolve to a target repository:
brian → brianchandotcom/<repository>The PR head is <github-username>:<branch-name> (the GitHub username is read from the user's origin remote URL — for example, git@github.com:brianchandotcom/liferay-portal.git yields brianchandotcom), and the base is ${BASE_BRANCH}.
Push the current branch to the user's remote when it has not been pushed yet or when new local commits exist.
The title is concise (under 72 characters) and prefixed with the key of the first ticket in the set:
LPD-83847 Fix OutOfMemoryError during batch engine import
The body follows this format, with one browse link per ticket in the set:
https://liferay.atlassian.net/browse/TICKET-ID-1
https://liferay.atlassian.net/browse/TICKET-ID-2
## What Is Being Fixed
Explain the problem or bug that motivated the change — what was going wrong or what was missing.
## How It Is Being Fixed
Explain the approach taken across all commits. Describe the key changes and the reasoning behind the approach. Write in plain prose rather than bullet points.
## Why Are There No Tests?
This optional section is only included when the commits do not add any tests. It should contain the rationale provided by the user.
## PR Check
<pr-check Results Summary>
<!-- pr-check {"result": "<state>", "sha": "<tested-SHA>"} -->
The PR Check section is the Results Summary block emitted by the pr-check skill that ran as the precondition — the overall state line, the tested SHA, the table of validations, and every note appended below it, since any row can carry a note, a PASS included — pasted verbatim, followed by a hidden marker. The marker is 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 NOT VERIFIED rows records success, and <tested-SHA> is the full 40-character SHA from the Results Summary. The webhook reads the result and sha fields to apply the pr-check commit status to that SHA and the pr-check - <state> label to the PR, so this skill records no status or label itself.
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.
When pr-check was skipped via --skip-pr-check, still write the section, but as a skip rather than a run. Under the same ## PR Check heading, the body is a single **pr-check: SKIPPED** — <reason> line with no table, and the marker payload adds a reason field alongside result (set to skipped) and the PR head SHA. The JSON object keys are alphabetical (reason, result, sha).
**pr-check: SKIPPED** — <reason>
<!-- pr-check {"reason": "<reason>", "result": "skipped", "sha": "<head-SHA>"} -->
The webhook applies the status and label when it processes the pull_request event for the newly opened PR, so no publish step is needed at creation. Use the pr-check-publish skill only to record a later pr-check run on an existing PR.
Use a direct, to-the-point style. Avoid being verbose. Present the proposed title and body to the user before submitting, and proceed once they approve.
Create the pull request 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.
body_file=$(mktemp)
gh pr create \
--base "${BASE_BRANCH}" \
--body-file "${body_file}" \
--head <github-username>:<branch-name> \
--repo <target-org/repo> \
--title "<title>"
rm "${body_file}"
Apply the steps below to every ticket in the ticket set, recording the outcome per ticket and continuing on failure.
For each ticket, fetch it (issue type, status, subtasks) and resolve the target ticket — the one whose status reflects active work and on which the PR URL is recorded:
| Ticket Type | Target |
|---|---|
Bug (10004) | The bug itself |
Task (10002) | Its Technical Task (10153) subtask |
Technical Task (10153) | Itself |
When the target is not already in an in-progress status, transition it first:
| Target Type | Destination | Transition ID |
|---|---|---|
| Bug | In Progress | 61 |
| Technical Task | In Progress | 41 |
Then transition it to review:
| Target Type | Destination | Transition ID |
|---|---|---|
| Bug | In Review | 71 |
| Technical Task | In Peer Review | 31 |
When the review transition fails (for example, because the ticket is already in a later status), still proceed to record the PR URL.
Set the Git Pull Request field (customfield_10201) on the target ticket to the new PR URL.
This handling applies per target ticket, while recording the PR URL above.
When the Git Pull Request field already holds one or more PR URLs, ask the user whether the new PR supersedes the existing one or is added alongside it.
When the user chooses supersede:
Overwrite Git Pull Request with the new PR URL, dropping the previous value.
Add a comment on the previous PR, linking to the new one (for example, Superseded by <new-pr-url>.).
Close the previous PR when possible. When the user lacks permission to close it directly, add a ci:close comment instead, so the CI bot closes it.
When the user chooses add:
Report back to the user with:
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.