Pr

Create a PR

Create a draft PR from the current branch's changes. Follow the repo's conventions for branch name and commit title. The PR description should be based on the implementation plan and the changes summary, but kept short and to the point — not overly long or detailed.

Preconditions

• The branch you want to PR is already committed.
• The branch is already pushed to origin (the caller is expected to do this; the agent's workflow handles it before invoking the skill).

Steps

1. Check the branch. If you're already on a relevant feature branch (i.e. not the repo's default branch), reuse it. Don't create a new one on top.

2. Open the PR with gh pr create --draft. Title should follow the repo's commit convention. If the repo uses conventional commits (check recent history with git log --oneline -10), use the format <type>(<scope>): <subject> where type is fix, feat, chore, refactor, docs, test, etc. Do not include AI-attribution labels like [bot], [claude], or [ai] in the title. Body should be a 1–3 sentence summary plus a "Testing" line if relevant — followed by the full implementation plan inside a hidden HTML comment so reviewers can read it without leaving GitHub but it doesn't bloat the visible description:

   gh pr create --draft \
     --title "<commit subject>" \
     --body "$(cat <<'EOF'
   <1–3 sentence summary>
   
   ## Testing
   <what you ran, or "none — see note">
   
   Closes #<issue-number>
   
   <!--
   ## Plan
   <full plan, multi-line is fine; this comment is invisible in
    GitHub's rendered PR view but can be inspected via "View source"
    or by checking out the PR locally>
   -->
   EOF
   )"
   

   The heredoc is important — it preserves multi-line plans, special characters, and quotes without escaping headaches.

3. Print the PR URL as the final line of your reply.

CI status will be monitored via webhook events — when a check_suite or workflow_run event arrives with conclusion: success, the agent will load mark-pr-ready to promote the draft.

Notes

• This skill creates a draft PR by design. A separate review/iterate step should mark it ready-for-review once self-review and CI pass. This is handled automatically via webhook events for CI completion.
• Don't include diagrams, lengthy "context" sections, or duplicated information that's already on the issue. The reader can follow the link.
• If the caller specifically wants the plan attached as a git note instead of an HTML comment (BYK/dotskills' original design), use:

  git notes add -F - HEAD <<'EOF'
  <full plan>
  EOF
  git push origin refs/notes/commits
  

  Without the explicit git push refs/notes/commits, the note exists only in the local clone.

Adapted from BYK/dotskills (Apache-2.0). Where the original used git notes as the primary attachment mechanism, this version uses an HTML comment in the PR body for reviewer visibility, with git notes documented as an alternative.