Use when adding new error messages to React, or seeing "unknown error code" warnings.
npx skills add Anshin-Health-Solutions/superpai --skill "commit-push-pr"
Install specific skill from multi-skill repository
# Description
End-to-end workflow for staging specific files, writing a conventional commit with HEREDOC formatting, pushing with tracking, and opening a pull request via the GitHub CLI. Enforces safety rules against git add -A and force pushes.
# SKILL.md
name: commit-push-pr
description: End-to-end workflow for staging specific files, writing a conventional commit with HEREDOC formatting, pushing with tracking, and opening a pull request via the GitHub CLI. Enforces safety rules against git add -A and force pushes.
triggers:
- /commit-push-pr
- /commit
- /push
- /pr
- "create a pull request"
- "commit and push"
- "open a PR"
Commit, Push & PR
Purpose
This skill enforces a disciplined, safe, and auditable path from working changes to an open pull request. It exists because "git add -A && git commit -m 'stuff'" is how secrets get committed and histories become unreadable. Every step here is intentional. The workflow applies to any git repository hosted on GitHub.
Phase 1: Pre-Flight Checks
Before touching git, gather information:
# 1. Understand what changed
git status
# 2. Review the full diff before staging anything
git diff
# 3. Check existing staged content
git diff --cached
# 4. Understand recent commit style to match it
git log --oneline -10
Never skip the diff review. You are responsible for knowing what you are committing. If git status shows unexpected files (e.g., .env, *.key, credentials.json), do not proceed — alert the user immediately.
Phase 2: Stage Specific Files
NEVER use git add -A or git add .. These commands indiscriminately stage everything including:
- Environment files (.env, .env.local, .env.production)
- Compiled artifacts (dist/, build/, .next/)
- Editor configuration (.vscode/settings.json with secrets)
- Test fixtures with real data
- Binary files that bloat history
Instead, stage files by explicit name:
# Stage individual files
git add src/components/UserCard.tsx
git add src/hooks/useAuth.ts
git add tests/UserCard.test.tsx
# Stage a directory when you own every file in it
git add src/features/billing/
# Stage portions of a file interactively (when only some hunks belong in this commit)
git add -p src/utils/api.ts
If you find yourself wanting to stage 20+ files at once, stop. Consider whether this should be multiple commits with distinct purposes.
Phase 3: Write a Conventional Commit
Conventional Commit Format
<type>(<scope>): <short description>
<body — explain WHY, not what>
<footer>
Type prefixes:
| Type | When to Use |
|---|---|
feat |
A new feature visible to users or consumers |
fix |
A bug fix |
refactor |
Code change that neither adds a feature nor fixes a bug |
test |
Adding or modifying tests only |
docs |
Documentation only |
ci |
CI/CD pipeline changes |
chore |
Maintenance, dependency updates, tooling |
perf |
Performance improvement |
build |
Build system or external dependency changes |
Rules for the short description:
- Maximum 72 characters
- Imperative mood: "add feature" not "added feature" or "adds feature"
- No period at the end
- Lowercase after the colon
HEREDOC Commit Command
Always use HEREDOC to preserve exact formatting, blank lines between sections, and the Co-Authored-By trailer:
git commit -m "$(cat <<'EOF'
feat(auth): add OAuth2 PKCE flow for single-page app clients
Replaces the implicit grant flow which is deprecated in OAuth 2.1.
PKCE prevents authorization code interception attacks without
requiring a client secret, making it safe for public clients.
Closes #142
Co-Authored-By: Claude Opus 4.6 <[email protected]>
EOF
)"
The 'EOF' (quoted) delimiter prevents shell variable expansion inside the message. This is correct and intentional.
Co-Authored-By Line
Always include this trailer line as the last line of the commit body:
Co-Authored-By: Claude Opus 4.6 <[email protected]>
This attributes AI assistance in the git history, which is required by many organizations for audit and compliance purposes.
Phase 4: Push with Tracking
First Push of a New Branch
Use -u to set the upstream tracking reference:
git push -u origin feat/oauth-pkce-flow
After this, subsequent pushes on the same branch only need:
git push
Safety Rules for Push
- NEVER use
--forceor-fon shared branches (main, dev, staging) - NEVER use
--force-with-leasewithout explicit user instruction - If the push is rejected because the remote is ahead, investigate with
git log origin/<branch>..HEADbefore pulling - NEVER push directly to main — always push to a feature branch and open a PR
Verify Push Success
# Confirm local and remote are aligned
git log --oneline -5
git log --oneline origin/feat/oauth-pkce-flow -5
Phase 5: Open a Pull Request
Use the GitHub CLI (gh). Never construct pull requests manually through the API unless gh is unavailable.
Pre-PR Checklist
# Verify you are on the correct branch
git branch --show-current
# Ensure the branch is pushed and tracking
git status
# Review what commits will be in the PR
git log main..HEAD --oneline
gh pr create Command
Use a HEREDOC for the body to preserve markdown formatting:
gh pr create \
--title "feat(auth): add OAuth2 PKCE flow for SPA clients" \
--base main \
--head feat/oauth-pkce-flow \
--body "$(cat <<'EOF'
## Summary
- Replaces deprecated implicit grant flow with PKCE (RFC 7636)
- Adds `generateCodeChallenge` and `generateCodeVerifier` utilities
- Updates the auth callback handler to validate the code verifier
- Removes the client secret requirement for public SPA clients
## Test Plan
- [ ] Unit tests pass: `bun test src/auth/`
- [ ] PKCE flow completes end-to-end in the dev environment
- [ ] Existing sessions are not invalidated by this change
- [ ] Token refresh still works after PKCE login
- [ ] Verify no client secret appears in browser network logs
## References
- Closes #142
- RFC 7636: https://datatracker.ietf.org/doc/html/rfc7636
- OAuth 2.1 deprecation note: https://oauth.net/2.1/
Co-Authored-By: Claude Opus 4.6 <[email protected]>
EOF
)"
PR Template Sections (Always Include)
Every PR must have at minimum:
- Summary — bullet list of what changed and why
- Test Plan — checklist of manual and automated verification steps
- References — linked issues, relevant RFCs, documentation
Optional sections when applicable:
- Breaking Changes — if the PR changes any public API or data schema
- Screenshots — for UI changes, before and after
- Migration Steps — if consumers of this code must update their usage
- Rollback Plan — for high-risk changes
Phase 6: Post-PR Steps
# Confirm the PR was created and get its URL
gh pr view --web
# List open PRs to verify
gh pr list
# Check CI status on the PR
gh pr checks
# If CI fails, push additional commits to the same branch — do NOT close and reopen
git add src/auth/pkce.ts
git commit -m "$(cat <<'EOF'
fix(auth): handle missing code_verifier in session storage
Co-Authored-By: Claude Opus 4.6 <[email protected]>
EOF
)"
git push
Output Format
When this skill completes, report:
COMMIT-PUSH-PR COMPLETE
Branch: feat/<name>
Commits: <count> new commit(s)
- <short hash> <subject>
Push: origin/feat/<name> (tracking set)
PR: <GitHub PR URL>
Status: OPEN | DRAFT
CI: PASSING | PENDING | FAILING
Next: Resolve reviewer comments or wait for CI to pass.
Integration Notes
- If a pre-commit hook fails, fix the issue and create a NEW commit — never use
--no-verifyto bypass hooks - If the repository uses signed commits (
gpgorssh), the HEREDOC pattern is fully compatible - For repositories that require draft PRs, add
--draftto thegh pr createcommand - If
ghis not authenticated, rungh auth loginfirst — do not proceed without it - This skill pairs with
/clean-goneto prune stale remote-tracking branches after PRs are merged
# Supported AI Coding Agents
This skill is compatible with the SKILL.md standard and works with all major AI coding agents:
Learn more about the SKILL.md standard and how to use these skills with your preferred AI coding agent.