Submit Pr From Current Changes

Prerequisites

Before attempting to push or open a PR, verify that the necessary tools are available:

• Check that gh CLI is installed and authenticated (gh auth status). If not available, stop and ask the user to install and authenticate GitHub CLI first.
• If the workflow uses MCP tools for GitHub operations, verify the MCP server is accessible.

Procedure

1. Read contribution rules. Read CONTRIBUTING.md and any package-level instructions (e.g. packages/*/AGENTS.md) relevant to the changed files.
2. Inspect the diff. Review changed files, scope, and impact. Understand what the change does before writing anything.
3. Inspect repo conventions. Check recent branch names (git branch -r --sort=-committerdate | head -20), recent commit messages (git log --oneline -20), and the PR template.
4. Pre-submission health checks (run all before creating the PR):
   • Unified theme: All changes should serve one purpose. If unrelated changes are mixed in, ask the user to split or confirm.
   • Commit hygiene: Every new commit must follow the repo's conventional commit style. Squash or reword if needed.
   • Author identity: Verify git config user.name and git config user.email are set and the email looks real (not empty, not noreply unless intentional). Warn the user if not.
   • No leftover artifacts: Check for debug logs, .only in tests, conflict markers, or temp files in the diff.
   • Lint and build: Run lint/build for the affected area. Record results honestly.
5. Warn if the PR looks too hasty. If any of these are true, pause and warn the user before proceeding:
   • Large diff with no description of intent provided
   • Changes touch core lib or extension (where vibe coding is prohibited per CONTRIBUTING.md)
   • Multiple unrelated concerns in one diff
   • No validation has been run at all
   • Remind the user: "This project does not accept low-quality or AI-generated PRs without meaningful human review. Please review your changes carefully."
6. Branch. Check the current branch first:
   • If already on a non-main feature branch with a valid name (matching type/topic convention), reuse it.
   • If the branch name does not follow repo conventions (e.g. missing prefix, unclear topic), ask the user whether to rename or create a new one.
   • If on main or a default branch, create a new branch from it with a short kebab-case name: prefix (fix/, feat/, docs/, refactor/, chore/) + concrete topic words.
7. Stage and commit. Stage only the intended files. Use type(scope): subject format. Keep the subject specific and compact.
8. Push. Push with -u origin HEAD.
9. Open PR. Use gh pr create with the full PR template structure. Fill in "What" and "Type" sections based on the actual diff. Leave all "Testing" and "Requirements" checkboxes unchecked.
10. Report results. Tell the user: branch name, commit hash, PR link, and what validation actually ran (with pass/fail).

Post-Submission Reminder

After successfully opening the PR, ALWAYS give a brief reminder in the user's language. Keep it concise and natural, but make sure it clearly tells the user:

1. They need to test the changes themselves in the browser.
2. They need to go to the PR page and check the Testing and Requirements checkboxes only after verifying each item.
3. The PR will not enter review until those checkboxes are checked.
4. The project does not accept autonomously AI-generated PRs, so they should only check the AI declaration if it is truthful.

Branch Naming

• Prefer short kebab-case names with a repo-consistent prefix such as fix/, feat/, docs/, refactor/, or chore/.
• Match the change type first, then the smallest useful topic.
• Prefer concrete topic words over issue text dumps.

Commit Style

• Use the repository's prevailing commit style (conventional commits).
• Use type(scope): subject when scope is clear from the changed area.
• Keep the subject specific and compact.
• If multiple commits exist on the branch, each one must independently follow conventions.

Validation Strategy

• Default to enough validation to defend the PR, not the absolute minimum.
• Prefer area-specific build, lint, or test commands when they exist.
• Escalate to broader validation when the diff crosses packages, changes shared code, or affects release behavior.
• Never claim checks that did not actually run.
• You MAY note what you ran and the results below the Testing section in the PR body, but do NOT check the template checkboxes.

Decision Points

• No local changes → stop, say so.
• gh CLI not available → stop, ask user to install it.
• Unrelated files mixed → stage only the intended subset or ask whether the work should be split.
• If the repo has area-specific instructions, read them before naming the branch or writing the PR.
• Change is small but high-risk → prefer broader validation.
• Change is narrowly scoped and low-risk → run the most relevant checks, not arbitrary unrelated ones.
• Template has declarations you cannot truthfully check → leave unchecked, tell the user why.

Completion Checks

• The branch exists remotely and tracks upstream.
• The commit message(s) match repo style.
• All commit authors have proper name and email configured.
• The PR title matches the commit intent.
• The PR body follows the template structure completely.
• All "Requirements" and "Testing" checkboxes are unchecked (- [ ]) in the PR body. Double-check: if any - [x] appears in these sections, it is a violation — fix it before submitting.
• The reported validation is accurate — nothing fabricated.
• The post-submission reminder was delivered in the user's language, concisely and accurately.