Make Pr

• If changes are still uncommitted and the user wants a PR, branch first, then commit.
• Prefer a single clean commit unless the user asks for a different history shape.

1. Check whether this PR also needs a change file.

• Do not assume every PR needs one.
• Before opening the PR, decide whether the change is user-facing enough to require release notes in packages/*/.changes.
• If a change file is needed or likely needed, use the make-change-file skill instead of re-deriving that workflow here.

1. Draft the PR body with minimal structure.

• Start with 1-2 short introductory paragraphs.
• After the intro, include clear bullets describing:
  • the feature and/or issue addressed
  • key behavior/API changes
  • expected impact
• If the change is extensive, expand to up to 3-4 paragraphs and include background context with related links.

1. Add required usage examples for feature work.

• If the PR introduces a new feature, include a comprehensive usage snippet.
• If it replaces or improves an older approach, include before/after examples.

1. Exclude redundant sections.

• Do not include Validation, Testing, or other process sections that are already implicit in PR workflow.
• Do not add boilerplate sections that do not help review.

1. Create the PR.

• Save the body to a temporary file and run:

gh pr create --base main --head <branch> --title "<title>" --body-file <file>

• If gh pr create fails, leave the branch pushed when possible and give the user a ready-to-open compare URL plus the prepared title/body details.

Body Template

Use this as a base and fill with concrete repo-specific details:

<One or two short intro paragraphs explaining the change and why it matters.>

- <Feature/issue addressed>
- <What changed in behavior or API>
- <Why this is needed now>

<Optional additional context paragraph(s), up to 3-4 total for large changes, including links to related PRs/issues.>

```ts
// New feature usage example
```

```ts
// Before
```

```ts
// After
```