name	pr-template
description	Create or update a GitHub PR using the repo's pull_request_template.md format. Use when creating a new PR or updating an existing PR body.
user-invocable	true

Create or update a GitHub PR following the repo's pull request template.

Read the template from .github/pull_request_template.md and use it as the exact structure for the PR body.

Run git diff main...HEAD (or git diff HEAD~1 if already on main) to understand the changes
Infer the PR type(s) from the diff and check the applicable boxes
Fill in all sections — keep each answer concise (1-3 sentences or bullet points)
If creating a new PR:
- Check if already on a non-main branch; if on main, ask the user for a branch name
- Push the branch if not yet pushed: git push -u origin <branch>
- Create the PR: gh pr create --title "<title>" --body "<body>"
If updating an existing PR:
- Get the current PR number: gh pr view --json number -q '.number'
- Update the body: gh pr edit <number> --body "<body>"

Use conventional commit format: <type>(<scope>): <short description>
Types: feat, fix, docs, ci, refactor, chore, test, perf
Scopes (optional): a project name (e.g. california-housing), ci, docker
Keep under 70 characters
Examples: feat(california-housing): add xgboost_train pipeline, fix(docker): install s3fs for fsspec S3 access

What changed? — What the code does differently now. Be concrete.
Why? — The motivation: bug, new example/project, cleanup, requirement.
How did you test it? — Commands run (uv sync, local python -m run, docker build), or a Michelangelo sandbox run.
Potential risks — Anything that could break for someone installing/running this example. Default to "None" for docs/chore changes.
Breaking Changes — Check applicable boxes: API (public functions/classes), dependency changes (michelangelo version pin, new required extra), Docker/image changes, pipeline/project config changes (pipeline.yaml/project.yaml schema, required env vars). Check "No breaking changes" if none apply. If any breaking change is checked, use BREAKING CHANGE: footer or ! suffix in the commit.
Migration guide — Required if any breaking change box is checked. Describe step-by-step upgrade instructions with before/after examples. Delete section if no breaking changes.
Release notes — Only notable if it's a new example/project, a changed dependency pin, or a new required env var. Otherwise "N/A".
Documentation Changes — Note which README(s) were updated (root, per-project, or per-pipeline) or "N/A".

name	pr-template
description	Create or update a GitHub PR using the repo's pull_request_template.md format. Use when creating a new PR or updating an existing PR body.
user-invocable	true

Create or update a GitHub PR following the repo's pull request template.

Read the template from .github/pull_request_template.md and use it as the exact structure for the PR body.

Run git diff main...HEAD (or git diff HEAD~1 if already on main) to understand the changes
Infer the PR type(s) from the diff and check the applicable boxes
Fill in all sections — keep each answer concise (1-3 sentences or bullet points)
If creating a new PR:
- Check if already on a non-main branch; if on main, ask the user for a branch name
- Push the branch if not yet pushed: git push -u origin <branch>
- Create the PR: gh pr create --title "<title>" --body "<body>"
If updating an existing PR:
- Get the current PR number: gh pr view --json number -q '.number'
- Update the body: gh pr edit <number> --body "<body>"

Use conventional commit format: <type>(<scope>): <short description>
Types: feat, fix, docs, ci, refactor, chore, test, perf
Scopes (optional): a project name (e.g. california-housing), ci, docker
Keep under 70 characters
Examples: feat(california-housing): add xgboost_train pipeline, fix(docker): install s3fs for fsspec S3 access

What changed? — What the code does differently now. Be concrete.
Why? — The motivation: bug, new example/project, cleanup, requirement.
How did you test it? — Commands run (uv sync, local python -m run, docker build), or a Michelangelo sandbox run.
Potential risks — Anything that could break for someone installing/running this example. Default to "None" for docs/chore changes.
Breaking Changes — Check applicable boxes: API (public functions/classes), dependency changes (michelangelo version pin, new required extra), Docker/image changes, pipeline/project config changes (pipeline.yaml/project.yaml schema, required env vars). Check "No breaking changes" if none apply. If any breaking change is checked, use BREAKING CHANGE: footer or ! suffix in the commit.
Migration guide — Required if any breaking change box is checked. Describe step-by-step upgrade instructions with before/after examples. Delete section if no breaking changes.
Release notes — Only notable if it's a new example/project, a changed dependency pin, or a new required env var. Otherwise "N/A".
Documentation Changes — Note which README(s) were updated (root, per-project, or per-pipeline) or "N/A".

pr-template