pr-create
The pr-create skill automates GitHub pull request creation by checking for existing PR descriptions or generating new ones, running optional pre-flight checks like linting and tests based on repository contribution guidelines, pushing unpushed commits, and creating a draft PR using the gh CLI with the finalized description saved to .local/pr-body.md. Use this when a user requests creating or opening a pull request.
git clone --depth 1 https://github.com/strands-agents/harness-sdk /tmp/pr-create && cp -r /tmp/pr-create/.agents/skills/pr-create ~/.claude/skills/pr-createSKILL.md
# GitHub PR Create Skill ## Process ### 1. Get the PR Description - Check for `.local/pr-body.md`. If it exists, re-read it fresh and sanity-check that its content matches the current branch's changes (e.g. the description references files, features, or issues consistent with the current diff). If it looks stale or unrelated to the current changes, warn the user and offer to regenerate it. - Else if the user already generated a PR description earlier in the conversation, use that. - Otherwise, fall back to the `pr-writer` skill to generate the title and body. ### 2. Pre-flight Checks Check for `CONTRIBUTING.md` (at the repo root or in `docs/`) and `.github/PULL_REQUEST_TEMPLATE.md`. Scan them for any recommended steps before opening a PR — common examples: - Running a linter or formatter (e.g. `npm run lint`, `cargo fmt`) - Running tests (e.g. `npm test`, `pytest`) - Building the project - Updating documentation or changelogs If you find any such steps, **list them and ask the user which ones they'd like you to run**. Run whichever the user approves. If any step fails, show the output and ask how to proceed before continuing. If neither file exists or they contain no actionable pre-PR steps, skip this and move on. ### 3. Push the Branch (if needed) Check whether the current branch has an upstream tracking branch with all commits pushed. If not, push before creating the PR. If the push fails, show the error and stop. ### 4. Create the PR Ensure the final PR body is written to `.local/pr-body.md` (create `.local/` if needed), overwriting any earlier draft. Then create the PR: ```bash gh pr create \ --title "<title>" \ --body-file .local/pr-body.md \ --draft ``` - Default to `--draft`. Only omit it if the user explicitly asks for a non-draft PR. - Do NOT pass `--repo` — let `gh` infer the upstream from the git remotes so the PR targets the correct upstream repository. ## Rules - If `gh` is not authenticated or the command fails, show the error and stop.
Assess a published or in-progress documentation page for quality, accuracy, and voice compliance. Use before rewriting a page, during periodic health checks, when community signals point to confusion, or when comparing against competitor docs. Also triggers on "audit this page", "assess the docs", "what's wrong with this page", "check docs quality", "review this doc page".
Identify documentation gaps and prioritize the docs backlog. Use when planning a docs improvement sprint, after signals surface repeated friction, when new SDK features ship without docs, or for periodic health assessment. Also triggers on "plan docs work", "what docs need writing", "prioritize the backlog", "docs health check", "what should we document next".
Review documentation drafts for voice consistency, structure, and terminology before PR submission. Use after completing a draft, when checking if docs are ready to ship, or automatically after docs-writer produces output. Also triggers on "review this draft", "check my docs", "is this ready to ship", "review before merging".
Draft or rewrite Strands Agents documentation pages. Use when writing new doc pages, rewriting pages that failed audit, drafting sections for existing pages, or writing blog posts and release notes about Strands. Also triggers on "write a doc", "draft a page", "rewrite the quickstart", "add a tutorial for X", "document this feature".
Local preview of the strands-agents/devtools `/strands review` agent. Body is the upstream Task Reviewer SOP verbatim — do not paraphrase. Use when the user types `/strands-review`, asks for a "strands review" of a PR, or wants to anticipate what the remote `/strands review` GitHub Action will flag. Findings are close but not identical to the remote agent. Strongly prefer running this skill in a fresh-context subagent rather than inline — the SOP is long and reviewer judgment is more reliable when it isn't entangled with the parent conversation's prior context.
Fetches PR review feedback and inline comments, categorizes them, and presents options to the user. Use when the user asks to get, read, address, or fix review comments on a pull request.
Generates pull request titles and descriptions. Use when the user asks to create, open, write, draft, or generate a PR, pull request, or merge request description.