chunk-pr
SolidAnalyzes a large pull request (or branch, or commit range) and proposes a sequence of smaller, logically-grouped, merge-safe PRs following review best practices — dependency first, one concern per PR, mergeable in order. Suggests a plan; the user approves. On approval, creates chunk branches, cherry-picks commits, pushes, opens draft PRs, and links them to the parent Linear issue. Use when a PR is too big to review, when a branch has accumulated unrelated changes, when reviewers ask "can you split this up?", or when planning how to ship a large feature incrementally.
Install
Quality Score: 83/100
Skill Content
Details
- Author
- mostafa-drz
- Repository
- mostafa-drz/claude-skills
- Created
- 7 months ago
- Last Updated
- yesterday
- Language
- HTML
- License
- MIT
Integrates with
Similar Skills
Semantically similar based on skill content — not just same category
create-pr
Generates a short, narrative GitHub pull request description (≤ 25 lines, hard ceiling 40), pushes the branch, opens the PR as a draft, then runs review-loop (pr-reviewer → implement-suggestion → polish simplify, up to 5 iterations) until every review thread is resolved via fix or reply. Scale down with --no-review, --no-simplify, --quick (light mechanical pass only), or --no-quality (skip the loop). A post-push external-bot feedback loop runs by default (--no-feedback to skip). On a UI diff, injects a preview verification spec by default (--no-preview-spec to skip). With --split, breaks the branch diff into 2–4 focused, dependency-ordered draft PRs after user approval. Escalates judgment-required CI failures via /confidence rather than guessing. Invoke with /create-pr or /create-pr --split.
create-pr
Creates a well-structured pull request with product-focused summary, change highlights, and test steps. Auto-detects base branch, links Linear issues from branch name, and pushes if needed. Use when ready to open a PR or when asking to create a pull request.
pr
Open a pull request for the current branch, or update the one already linked to it — with a title and description written from the actual diff and the repository's own template. Checks first that the branch reads as one coherent change, and asks before opening a pull request that is really two. Never merges, never force-pushes, never commits on your behalf.