Publish the current repository change as a ready-for-review GitHub pull request against the requested base, or the repository's remote default branch when none is named. Always use this skill for an actual PR publication, including requests to create, open, raise, publish, or reuse a pull request, put work up for review, or make and share a GitHub review link. Complete the needed commit, base synchronization, and branch publication, but stop before merge.
The English summary is being prepared. Showing the original description.
Run score Not tested
See how to installReview the instructions the agent will receive before you install.
Turn the current request's change into one ready-for-review pull request against the named base, or the remote's advertised default branch when none is named. Complete the necessary local Git work instead of requiring other skills to be installed.
Preserve unrelated work while committing the request's changes as logical Conventional Commits. Keep credentials and other sensitive files out of the history, honor repository checks, and move work on a detached or protected checkout to a suitably named branch.
Base the branch on the fetched target and publish it without overwriting unexpected remote work. Reuse an existing pull request for the same head and base; when the change is already represented on that remote base, report the state instead of duplicating it.
Create the pull request ready for review with a title and body describing the actual change. Leave merging, required reviews, and release decisions outside this skill's authority.
Write for a reviewer without the conversation history: explain the problem, concrete before-and-after behavior, why it changed, and what verification establishes. Scale the explanation to the change; a typo fix needs only a brief description and relevant validation. Include mechanisms, a diagram for complex flows, actual alternatives and trade-offs, affected users or integrations, and specific unresolved judgments when they help assess the change. Keep the whole change understandable beyond those highlighted judgments; omit empty sections and invented alternatives or questions.
For screen changes, capture the actual base and head at matching viewport, data, and state, or reuse evidence verified to match those revisions. Embed before-and-after screenshots side by side in the body, with a short explanation of the difference and its reason. Identify the revisions, screen and capture conditions, including unavoidable differences. Add actual interaction video when still images cannot explain the important behavior. Separate observed results from source inference and unverified states; a prototype is not runtime evidence. When updating an existing PR, bring its explanation and evidence into line with the final change, replacing outdated visual claims.
Before uploading, inspect screenshots and videos for credentials, personal
data, and private information. Use safe seeded data or redact those details
throughout the media, keeping comparison conditions and the relevant change
visible. Upload only the inspected, safe media as GitHub attachments, using a
supported mechanism in the current environment. For GitHub CLI, check attachment support: gh pr create and
gh pr edit accept repeatable --attach on supported versions and rewrite
matching local image references in --body-file to uploaded URLs. A Markdown
table can place the two images side by side. Keep review captures outside
repository history; no separate image host is needed.
If baseline execution, capture, or upload is unavailable, state the exact limit and present only the evidence obtained. Inspect the resulting remote body and attachments before reporting them as available to reviewers; a local path is not a published image. A partial upload may still create the PR: inspect and repair that PR instead of duplicating it. Carry successful attachment URLs from the remote body into its replacement, and replace unusable local references with an honest limitation if recovery fails.
Finish when the remote pull request exists in ready state and the user has its URL, base, head branch, and any checks or evidence that remain outstanding.
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.
Audit and establish current agent context for the technologies that define a project's stack. Use when setting up a project for agent work, after selecting or adding a framework, library, developer tool, or hosted service, or when entering an existing project whose agent context has not been audited.
The English summary is being prepared. Showing the original description.
Revise active `docs/specs/SLUG/` specs so they match what has shipped since they were written. Use when earlier work has landed and queued specs may now rest on stale assumptions, acceptance criteria, constraints, terms, or prototypes, or when implementation reports a spec as stale before changing source. Takes one or more spec folders, or every folder under `docs/specs/` when none is named. Do not use to shape a new spec from a problem and direction, which belongs to `shape-idea`, or to reconcile durable project context and retire shipped folders, which belongs to `maintain-project-context`.
The English summary is being prepared. Showing the original description.
Build a complete dummy-data HTML prototype or a temporary comparison of up to three alternatives for a specific user situation. Use to settle a screen-based product before implementation or resolve a visual or interaction decision during shaping or prototype review. Do not use for production implementation or CLI, terminal, or voice interfaces.
The English summary is being prepared. Showing the original description.
Create Git commits for the current request's in-scope changes as logical Conventional Commits. Always use this skill for an actual Git commit operation, including requests to commit or amend changes, save work in repository history, stage and record selected files, or group staged or unstaged changes into commits. Use it even when the request describes recording changes without saying "commit"; it performs the commit rather than only suggesting a message, and it does not push.
The English summary is being prepared. Showing the original description.
Interview the user to define or revise the app's overall product direction, then preserve the confirmed meaning in root PRODUCT.md. Always use for a new app direction or any app-wide change to users, usage situations, problem, promised change, core loop, durable boundaries, experience principles, success signals, assumptions, or unknowns, even when PRODUCT.md is not named. Start from an existing definition or a rough app direction. Do not use for blank-page idea discovery, architecture, or shaping or specifying one feature or work unit.
The English summary is being prepared. Showing the original description.
Render an explanation as a diagram, comparison, trace with real values, or annotated code. Use when the user asks to have a concept, decision, flow, or code explained, or says they do not follow.
The English summary is being prepared. Showing the original description.