| name | prepare-pr |
| description | Self-review the current branch and assemble everything needed to open a GitHub PR for flutter_ilib — conventional commit/PR title, filled-in PR template, and test/analyze/format evidence. Delegates the conversion-specific review to the `review-changes` skill. Outputs the PR content to chat for the user to paste — it does NOT run gh/push. Use when wrapping up a change and preparing a PR. Triggers: "create a PR", "prepare pull request", "review my changes before PR", "open a PR", "self-review this branch". |
Prepare a pull request
Take the current branch from "code written" to "ready to open a PR": a focused
self-review, then the exact PR metadata this repo expects. This skill does not
push, commit, or run gh pr create. Its only output is the PR content —
title, filled template, and evidence — written to chat for the user to copy.
Ask first
- Scope — is this one logical change? If the diff mixes unrelated concerns
(a conversion + an unrelated refactor), suggest splitting before proceeding.
Procedure
1. Identify the current branch and the base branch
Do not hardcode the base — the integration branch changes over time (the old
migration/ilib-js-to-dart is being retired). Determine both, then confirm the
base with the user:
git fetch origin
git branch --show-current
git remote show origin | grep 'HEAD branch'
Pick the base the PR should target (repo default unless the user says otherwise),
then read the diff against it — know what each hunk does and why:
BASE=origin/<base-branch>
git status
git diff --stat $(git merge-base HEAD "$BASE")..HEAD
git log --oneline $(git merge-base HEAD "$BASE")..HEAD
2. Self-review
Run the review-changes skill on the diff — it covers the conversion-specific
gates (expected-value integrity, test placement, locale scope, calendar base-class
rules, test hygiene, exports, docs) and reports findings with file:line. Resolve
any must-fix findings before continuing. For deeper correctness/security depth,
also run /code-review or the security-review skill.
3. Gather the required evidence
The PR template checklist maps to concrete commands — run them and capture the
result so the checklist reflects reality, not hope:
dart format .
flutter analyze
./execute_test.sh
Also verify the example app still works if the change touches public API or
formatting output (PR template item 2).
4. Draft the commit / PR title
Conventional Commits, per doc/development.md
§ Commit Message Format:
type(scope): description
- Detail 1
- Detail 2
fixes: #issue
Types: feat, fix, refactor, test, docs, chore. Scope is the area
(locale, datefmt, calendar, numfmt, …). The PR title follows the same form.
Write the title and body in English — this repo's commit messages, PR
template, and docs are all English. Keep any surrounding explanation to the user
in the conversation language.
5. Fill in the PR template
.github/PULL_REQUEST_TEMPLATE.md is authoritative — mirror its exact structure:
### Checklist
The following lists affects Pub Points on pub.dev when the package is published.
* [x] Passed all tests.
* [x] Passed `flutter analyze` with no issues.
* [x] Verified that the example app works.
* [x] Executed the `dart format` command.
* [x] Added the API description if necessary.
* [x] Updated CHANGELOG.md for user-facing changes.
### Description
<what changed and why; test results; any new locale data added>
Only tick a box you actually verified in step 3. If the example app was not
re-verified because the change can't affect it, say so in the Description rather
than ticking blindly.
Description line width — wrap the Description prose at ~100 columns (soft
wrap; don't split code, URLs, or inline code spans). This is the repo
preference for readable diffs in the commit/PR body — it is independent of the
page_width: 80 used by dart format for source code.
6. Output the PR content to chat
Write the following into the chat so the user can copy it into GitHub themselves.
The title and body must be in English (repo convention); the surrounding
explanation can be in the conversation language.
- Base branch — the base identified and confirmed in step 1.
- Title — the conventional-commit line from step 4.
- Body — the filled-in PR template from step 5.
- Evidence — the format/analyze/test results from step 3, so the user can see
which checklist boxes are truthfully ticked.
Do not run git push, git commit, or gh pr create. Creating the PR is the
user's action. If the user later asks you to open it, that is a separate,
explicit request.
Critical rules
- This skill never creates the PR. No
gh pr create, no git push, no
git commit — output the content to chat and stop. Opening the PR is the user's
job (or a separate explicit request).
- Never tick a checklist box you didn't verify.
- Never hardcode the base branch — detect it (step 1) and confirm with the user;
the integration branch changes over time.
Checklist
