Menu
Update the title and body of one or more pull requests.
Instalar com Codex ou Claude Copie este prompt, cole no Codex, Claude ou outro assistente e deixe que ele revise a página da skill e instale para você.
Baseado na classificação ocupacional SOC
Use OpenClaw's exec tool to inspect orgs, sources, and run bounded read-only SQL through the OneQuery CLI directly.
Production-ready CSS transition snippets for web apps. Use when adding or reviewing UI motion for badges, dropdowns, modals, panel/page reveals, card resizes, number pop-ins, text/icon swaps, success checks, avatar-group hovers, and validation shakes. Supports namespaced commands: transitions reveal (list catalog), transitions review (audit project fit), and transitions apply (install the best-fit snippet with hooks and reduced-motion handling).
SEO & GEO (Generative Engine Optimization) for websites. Analyze keywords, generate schema markup, optimize for AI search engines (ChatGPT, Perplexity, Gemini, Copilot, Claude) and traditional search (Google, Bing). Use when user wants to improve search visibility, search optimization, search ranking, AI visibility, ChatGPT ranking, Google AI Overview, indexing, JSON-LD, meta tags, or keyword research.
Generate or replace OneQuery blog thumbnail images and article diagram images for apps/landing. Use when Codex needs to create blog list thumbnails, social share thumbnails, in-article architecture diagrams, update blog imageSrc references, follow the OneQuery diagram design system, or use the bundled assets/diagram-design-system.png visual reference.
Babysit a GitHub pull request after creation by continuously polling review comments, CI checks/workflow runs, and mergeability state until the PR is merged/closed or user help is required. Diagnose failures, retry likely flaky failures up to 3 times, auto-fix/push branch-related issues when appropriate, and keep watching open PRs so fresh review feedback is surfaced promptly. Use when the user asks Codex to monitor a PR, watch CI, handle review comments, or keep an eye on failures and feedback on an open PR.
Breaking changes
| name | onequery-pr-body |
| description | Update the title and body of one or more pull requests. |
When this skill is invoked, the PR(s) to update may be specified explicitly, but in the common case, the PR(s) to update will be inferred from the branch / commit that the user is currently working on. For ordinary Git usage (i.e., not Sapling as discussed below), you may have to use a combination of git branch and gh pr view <branch> --repo wordbricks/onequery --json number --jq '.number' to determine the PR associated with the current branch / commit.
When invoked, use gh to edit the pull request body and title to reflect the contents of the specified PR. Make sure to check the existing pull request body to see if there is key information that should be preserved. For example, NEVER remove an image in the existing pull request body, as the author may have no way to recover it if you remove it.
It is critically important to explain why the change is being made. If the current conversation in which this skill is invoked has discussed the motivation, be sure to capture this in the pull request body.
The body should also explain what changed, but this should appear after the why.
Limit discussion to the net change of the commit. It is generally frowned upon to discuss changes that were attempted but later undone in the course of the development of the pull request. When rewriting the pull request body, you may need to eliminate details such as these when they are no longer appropriate / of interest to future readers.
Avoid references to absolute paths on my local disk. When talking about a path that is within the repository, simply use the repo-relative path.
It is generally helpful to discuss how the change was verified. That said, it is unnecessary to mention things that CI checks automatically, e.g., do not include "ran just fmt" as part of the test plan. Though identifying the new tests that were purposely introduced to verify the new behavior introduced by the pull request is often appropriate.
Make use of Markdown to format the pull request professionally. Ensure "code things" appear in single backticks when referenced inline. Fenced code blocks are useful when referencing code or showing a shell transcript. Also, make use of GitHub permalinks when citing existing pieces of code that are relevant to the change.
Make sure to reference any relevant pull requests or issues, though there should be no need to reference the pull request in its own PR body.
Sometimes a pull request is composed of a stack of commits that build on one another. In these cases, the PR body should reflect the net change introduced by the stack as a whole, rather than the individual commits that make up the stack.
Similarly, sometimes a user may be using a tool like Sapling to leverage stacked pull requests, in which case the base of the PR may be the a branch that is the head of another PR in the stack rather than main. In this case, be sure to discuss only the net change between the base and head of the PR that is being opened against that stacked base, rather than the changes relative to main.
