with one click
pinpoint-commit
// Comprehensive commit-to-PR workflow with intelligent testing, branch management, and CI monitoring
// Comprehensive commit-to-PR workflow with intelligent testing, branch management, and CI monitoring
[HINT] Download the complete skill directory including SKILL.md and all related files
| name | pinpoint-commit |
| description | Comprehensive commit-to-PR workflow with intelligent testing, branch management, and CI monitoring |
Automates the complete commit lifecycle: file review → testing → branching → committing → PR creation → CI monitoring.
Invoke this skill when you're ready to commit and push changes to PinPoint:
This skill provides a guided, 6-phase workflow that handles the entire commit-to-PR process with intelligent decision-making and automation.
Key Features:
Phase Order:
Run this FIRST before file review or testing
Run git status --porcelain and categorize files:
Staged files (ready to commit):
A src/components/IssueList.tsx
M src/lib/filters.ts
Unstaged files (modified but not staged):
M src/server/db/schema.ts
Untracked files (never committed):
?? debug.log
Present summary:
📦 Files ready to commit (staged):
- src/components/IssueList.tsx
- src/lib/filters.ts
⚠️ Unstaged changes (not included):
- src/server/db/schema.ts
❓ Untracked files:
- debug.log
Ask:
Actions:
git add <files> for additional inclusions.gitignore if requested// turbo
Execute: pnpm run preflight
This runs the full validation suite:
If preflight fails: Show error, offer to run pnpm run lint:fix && pnpm run format:fix if it's fixable.
Analyze changed files using git diff --name-only --staged and recommend test suite based on impact.
Decision Matrix:
High Impact Files → Recommend pnpm run e2e:full (~3-5 min):
src/app/(app)/**/page.tsx - Page components (user journeys)src/app/(app)/**/layout.tsx - Layout components (site structure)src/app/(auth)/**/* - Authentication flowssrc/components/issues/* - Core issue UI componentssrc/components/machines/* - Core machine UI componentssrc/server/actions/* - Server actions (data mutations)src/lib/supabase/* - Auth/database clientsupabase/migrations/* - Database schema changesMedium Impact Files → pnpm run smoke (already in preflight):
src/components/ui/* - Reusable UI componentssrc/lib/* - Utility librariessrc/server/db/schema.ts - Schema definitionsLow Impact Files → Skip additional E2E:
docs/**/* - Documentation*.test.ts - Test files*.spec.ts - E2E test files.agent/**/* - Agent skillsscripts/* - Build/dev scriptsPresent recommendation:
Based on your changes to:
- src/app/(app)/issues/page.tsx (page component - HIGH IMPACT)
- src/components/IssueList.tsx (core UI - HIGH IMPACT)
I recommend: pnpm run e2e:full
This will add ~3-5 minutes but ensures user journeys work.
Run full E2E suite? (y/n)
If approved: // turbo
pnpm run e2e:full
Run comprehensive branch validation to ensure clean state:
# Get current branch
BRANCH=$(git rev-parse --abbrev-ref HEAD)
# Check if branch tracks a remote
UPSTREAM=$(git rev-parse --abbrev-ref @{upstream} 2>/dev/null || echo "")
# Get merge base with main
MERGE_BASE=$(git merge-base HEAD main 2>/dev/null || echo "")
MAIN_HEAD=$(git rev-parse main 2>/dev/null || echo "")
Validation checks:
HEAD != mainHEAD is a branch namefeature/*, fix/*, chore/*, docs/*main HEAD (no stale branches)Branch types:
Scenario A: On main
⚠️ You're on main. PinPoint policy: work on feature branches.
I'll create a new branch for you.
→ Jump to 3.3 Create Branch
Scenario B: Detached HEAD
❌ Detached HEAD state. Creating a branch...
→ Jump to 3.3 Create Branch
Scenario C: Stale branch (not based on current main)
⚠️ Branch 'chore/enable-sentry-plugin' is stale (based on old main).
This branch was created from: commit abc123
Current main is at: commit def456
Options:
1. Create new branch from current main (recommended)
2. Rebase onto main (advanced - may have conflicts)
3. Continue anyway (not recommended)
If option 1: → Jump to 3.3 Create Branch
If option 2: Run git rebase main, then continue
If option 3: Warn user, then continue
Scenario D: Misnamed branch
⚠️ Branch 'my-work' doesn't follow naming convention.
Expected: feature/*, fix/*, chore/*, docs/*
Options:
1. Create properly named branch
2. Continue anyway
If option 1: → Jump to 3.3 Create Branch
Scenario E: Valid feature branch
✅ Branch: feature/issue-filter-search
✅ Based on: main (up to date)
✅ Upstream: origin/feature/issue-filter-search
Proceeding...
→ Continue to Phase 4
Scenario F: Valid branch, no upstream
✅ Branch: feature/new-work
✅ Based on: main (up to date)
⚠️ No upstream (will be set on push)
Proceeding...
→ Continue to Phase 4
Analyze changed files to suggest a name:
Changed files: src/components/IssueList.tsx, src/lib/filters.ts
→ Suggest: feature/issue-list-filters
Ask user:
Creating new branch off main.
Suggested: feature/issue-list-filters
Options:
1. Use suggested name
2. Enter custom name
3. Enter GitHub issue # (I'll format as "feature/123-description")
Create:
git checkout -b <branch-name> main
Analyze staged changes using git diff --staged --stat and git diff --staged --name-only to generate a conventional commit message.
Conventional Commits format: <type>(<scope>): <description>
Type Selection (analyze changed files):
feat - New features (new components, new routes, new functionality)fix - Bug fixes (fix typos, fix logic errors, fix crashes)refactor - Code restructuring (extract hooks, extract components, reorganize)chore - Maintenance (dependency updates, config changes, tooling)docs - Documentation only (README, comments, doc files)test - Test additions/changes (new tests, test fixes)style - Formatting only (prettier, lint fixes without logic changes)Scope Selection (primary area of changes):
Look at changed file paths and use:
issues - src/components/issues/, src/app/(app)/issues/machines - src/components/machines/, src/app/(app)/m/auth - src/app/(auth)/, src/lib/supabase/ui - src/components/ui/*db - supabase/migrations/, src/server/db/e2e - e2e/*/agents - .agent/*/Body Generation:
Use git diff --staged --stat output to create bullet points:
Present:
Generated commit message:
feat(issues): Update issues functionality
- Update 3 source file(s)
- Add/update 2 test(s)
Stats: +42/-10 lines
Options:
1. Use this message
2. Edit the message
3. Add "Closes #" reference
If user wants to link an issue:
gh issue list --limit 20 --json number,title
Present recent issues, append Closes #<issue> to commit body.
git commit -m "<title>" -m "<body>"
Check if remote branch exists:
git rev-parse --abbrev-ref @{upstream} 2>/dev/null
If doesn't exist:
git push -u origin <branch-name>
If exists:
git push
gh pr list --head <branch-name> --json number,url,state
If PR exists:
✅ Found PR #123
URL: https://github.com/timothyfroehlich/PinPoint/pull/123
Pushed new commits.
Continue to CI monitoring? (y/n)
If no PR: → Continue to 5.3 Create PR
Generate description:
## Summary
[1-2 sentence overview from commit message]
## Changes
- [Bullet from commit body]
- [Bullet from commit body]
## Testing
- ✅ Unit tests: passing
- ✅ Integration tests: passing
- ✅ E2E tests: [suite run]
## Related Issues
Closes #[issue] (if provided)
## Checklist
- [x] Preflight passed locally
- [x] Tests added/updated
- [ ] CI checks pending...
Ask user:
Generated PR description.
Options:
1. Create PR
2. Edit description
3. Create as DRAFT
Create:
# Regular PR
gh pr create --title "<title>" --body "<description>"
# Draft PR
gh pr create --title "<title>" --body "<description>" --draft
Ask user:
PR #123 created!
URL: https://github.com/timothyfroehlich/PinPoint/pull/123
Get it ready for review? (CI + Copilot + label)
Options:
1. Yes — run ready-to-review flow
2. Skip
Use pinpoint-ready-to-review skill for the full CI → Copilot → label sequence.
The flow below is kept for reference only. Load pinpoint-ready-to-review for the authoritative steps.
Poll GitHub Actions status using gh pr checks <pr-number>:
# Check current status
gh pr checks <pr-number>
# Poll every 30 seconds for up to 10 minutes
# Show status updates to user
Status check output format:
✓ Preflight pass 2m 15s
✓ Build pass 1m 45s
○ E2E Tests pending
× Playwright fail
Parse and present:
⏳ Monitoring CI for PR #123...
[00:30] Checks: 2/4 complete, 2 passed, 0 failed
[01:00] Checks: 3/4 complete, 3 passed, 0 failed
[03:00] Checks: 4/4 complete, 4 passed, 0 failed
✅ All CI checks passed! (3m 0s)
On success:
✅ All checks passed!
Your PR is ready for review.
Next steps:
1. Request review: gh pr review <pr> --request @reviewer
2. View PR: gh pr view <pr> --web
On failure:
❌ CI checks failed
Failed checks:
- E2E Tests / Playwright (chromium)
View details: gh pr checks <pr-number>
On timeout:
⏱️ Timeout after 10 minutes.
Some checks still running.
View: gh pr checks <pr-number>
After CI completes, check for Copilot review comments:
./scripts/workflow/copilot-comments.sh <PR>
If comments exist, fix the code. Applied suggestions are auto-resolved by Copilot when it detects your commit. For declined suggestions only, reply and resolve manually:
./scripts/workflow/respond-to-copilot.sh <PR> "<path>:<line>" "Ignored: <why>. —Claude"
Once CI is green and Copilot comments are resolved:
./scripts/workflow/label-ready.sh <PR>
Present complete summary:
🎉 Workflow Complete!
✅ Committed: feat(issues): Update issues functionality
✅ Pushed to: origin/feature/issue-list-filters
✅ PR Created: #123 (https://github.com/timothyfroehlich/PinPoint/pull/123)
✅ CI Status: All checks passing
Next Steps:
- Request review: gh pr review 123 --request
- View PR: gh pr view 123 --web
Your code is ready for team review! 🚀
Steps marked // turbo auto-run without approval:
pnpm run preflightpnpm run e2e:full (if user approved)git push✅ Use when:
❌ Don't use when:
Required for:
Install: npm install -g gh or use system package manager
Leverages:
pnpm run preflight - Full validation suitepnpm run e2e:full - Complete E2E testspnpm run smoke - Fast smoke testsWorks with Husky pre-commit hooks:
lint-staged runs on commit