// Commit all current changes, push to a feature branch, and create a PR. Use when the user asks to commit, push, save progress, or ship changes.
| name | cp |
| description | Commit all current changes, push to a feature branch, and create a PR. Use when the user asks to commit, push, save progress, or ship changes. |
| user_invocable | true |
Commit all current changes, push to a feature branch, and open a pull request. All pre-push checks must pass before pushing.
Run pre-push checks with auto-fix (quiet mode suppresses output on success):
tools/pre-push --fix -q
If this fails, fix the issues and re-run until it passes. Do NOT skip this step — it is the project's only gate against broken code.
Check for changes:
git status
git diff --stat
git log --oneline -5
Stage all changes (including any fixes from step 1):
git add -A
Write a commit message following the project convention:
synq: (lowercase)Commit using a HEREDOC:
git commit -m "$(cat <<'EOF'
synq: <summary>
<optional body>
EOF
)"
Create a feature branch if on main:
If currently on main, create and switch to a descriptive branch:
git checkout -b <branch-name>
Branch naming: use lowercase kebab-case describing the change (e.g.,
add-cte-column-validation, fix-fmt-trailing-comma). No prefixes needed.
Push the branch:
git push -u origin HEAD
Create a PR using gh pr create. For single-commit PRs the
body should be the commit body verbatim — the lead-in + bullets
structure from step 4 is exactly the structure a PR wants. Don't
rewrite it into a single paragraph, don't add section headings,
don't restate the title. The shortcut:
git log -1 --format=%b HEAD | gh pr create --title "<title>" --body-file -
For multi-commit PRs, write the body in the same shape (short lead-in + bullets covering the important changes across commits). One-liners are fine only when the title and diff genuinely speak for themselves.
synq: Report the PR URL to the user.
Quickly commit and push current changes to a feature branch and create a PR, skipping pre-push checks. WARNING: if CI starts failing, use /cp instead.
Debug a SQL formatter bug. Use when the user reports incorrect formatting output — wrong whitespace, misplaced comments, blank lines, etc.
Format SQL files using the syntaqlite formatter. Use when the user wants to format, reformat, or pretty-print SQL code.
Parse SQL and inspect the AST using syntaqlite. Use when the user wants to see the parse tree, debug SQL syntax, or understand how a query is structured.
Validate SQL and report diagnostics using syntaqlite. Use when the user wants to check SQL for errors, lint SQL files, or verify correctness against a schema.
Run tests to verify correctness after code changes. Use when the user asks to run tests, verify changes, or check that things still work. Runs Rust unit tests and integration tests.