// 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.
| name | cpfast |
| description | 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. |
| user_invocable | true |
Commit all current changes, push to a feature branch, and open a pull request. Skips pre-push checks for speed — CI will catch issues.
Note: This skips
tools/pre-push. If CI starts failing after using this, switch to/cpwhich runs the full presubmit gate.
Check for changes:
git status
git diff --stat
git log --oneline -5
Stage all changes:
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 3 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.
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.
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.