PR Submission Workflow
Canonical copy. .claude/skills/pr-submission/SKILL.md is a stub pointing here, the same way CLAUDE.md points at AGENTS.md.
Use this skill whenever opening a pull request for the SparkyFitness repository.
1. Core Non-Negotiable Rules
- Zero AI Attribution (Strict Monorepo Rule):
- Commit messages, commit trailers, PR titles, PR bodies, and comments must never contain
Co-Authored-By: Claude (or any other assistant trailer), "Generated with...", "🤖", or any mention of Claude, Gemini, Antigravity, Copilot, Cursor, etc.
- Write strictly from the perspective of the repository author/maintainer.
- Branch Management (Use Current Branch Unless on Main or Detached HEAD):
- Always check the current active branch:
git branch --show-current.
- If on
main, master, or detached HEAD (empty string): Create a new topic branch (git checkout -b fix/<topic> or feat/<topic>) because GitHub does not allow creating a PR from main into main, and pushing from detached HEAD fails.
- If already on an active work/dev branch (e.g.
dev, fix/..., feat/...): Do not create a new branch. Stay on the current branch, commit changes, and push directly to origin.
- Preserve Complete PR Template:
- Always load
.github/pull_request_template.md.
- Never delete or strip any sections, questions, or checkboxes, even if they are not applicable to the current change (e.g. keep Frontend, Backend, UI, Mobile checklist blocks intact).
- Fill in the applicable fields, check applicable boxes (
[x]), and leave non-applicable boxes unchecked or noted with N/A.
- Pre-flight Validation Must Pass:
- Always run
pnpm run validate and relevant test suites in the modified packages before committing/pushing.
2. Step-by-Step Submission Procedure
Step 1: Pre-Submission Validation
Run the standard validation commands for all packages touched in the PR:
- Server (
SparkyFitnessServer/):cd SparkyFitnessServer && pnpm format && pnpm test && pnpm validate
# If database migrations were added or modified:
pnpm run test:migrations
- Frontend (
SparkyFitnessFrontend/):cd SparkyFitnessFrontend && pnpm format && pnpm test && pnpm validate
- Mobile (
SparkyFitnessMobile/):cd SparkyFitnessMobile && pnpm test && pnpm validate
- Garmin Microservice (
SparkyFitnessGarmin/):cd SparkyFitnessGarmin && ./venv/bin/python -m unittest discover tests
Inspect git status and git diff to ensure no scratch files, debug logs, or unwanted changes are staged.
Step 2: Branch Check & Staging
- Check active branch:
BRANCH=$(git branch --show-current)
- Handle branch state:
- Stage modified files:
git add <files>
Step 3: Commit Message
Write a concise conventional commit message referencing any linked issue:
git commit -m "fix(<domain>): concise summary of fix
- Bullet point detailing specific change
- Bullet point detailing another change
Fixes #<issue_number>"
Step 4: Prepare PR Body from Template
Read .github/pull_request_template.md and populate the body file:
- Description:
- What problem does this PR solve? (1-2 sentences)
- How did you implement the solution? (Technical bullet points)
- Linked Issue:
Closes #<issue_number>
- How to Test: Concrete steps to run commands, trigger the flow, and verify behavior.
- PR Type: Mark
[x] on the applicable type (Issue, New Feature, Refactor, Documentation).
- Checklist: Mark
[x] on all applicable mandatory items that were executed. Keep all other checklist items as-is.
- Screenshots: Provide screenshots for UI changes, or
N/A for backend/headless changes.
- Notes for Reviewers: Note any relevant configuration keys, architectural decisions, or performance context.
Step 5: Push Branch & Create PR
Push the branch to origin:
BRANCH=$(git branch --show-current)
git push -u origin "$BRANCH"
Create the PR targeting main via GitHub CLI:
gh pr create --base main --title "fix(<domain>): <summary>" --body-file "<path-to-body-file>"
Step 6: Final Verification
Verify the created PR via gh pr view <number> to ensure formatting and checklists rendered cleanly.
1---2name: pr-submission3description: Use whenever the user asks to submit, open, create, or publish a pull request (PR) — e.g. "submit this as PR", "open a PR", "create PR for me", "submit PR", "make a PR". Enforces pre-submission package validation, active branch reuse (only branching when on main or detached HEAD), strict zero-AI-attribution commit standards, and mandatory full adherence to .github/pull_request_template.md without removing any sections or checkboxes.4---56# PR Submission Workflow78Canonical copy. `.claude/skills/pr-submission/SKILL.md` is a stub pointing here, the same way `CLAUDE.md` points at `AGENTS.md`.910Use this skill whenever opening a pull request for the SparkyFitness repository.1112---1314## 1. Core Non-Negotiable Rules15161. **Zero AI Attribution (Strict Monorepo Rule)**:17 - Commit messages, commit trailers, PR titles, PR bodies, and comments must **never** contain `Co-Authored-By: Claude` (or any other assistant trailer), "Generated with...", "🤖", or any mention of Claude, Gemini, Antigravity, Copilot, Cursor, etc.18 - Write strictly from the perspective of the repository author/maintainer.192. **Branch Management (Use Current Branch Unless on Main or Detached HEAD)**:20 - Always check the current active branch: `git branch --show-current`.21 - **If on `main`, `master`, or detached HEAD (empty string)**: Create a new topic branch (`git checkout -b fix/<topic>` or `feat/<topic>`) because GitHub does not allow creating a PR from `main` into `main`, and pushing from detached HEAD fails.22 - **If already on an active work/dev branch (e.g. `dev`, `fix/...`, `feat/...`)**: **Do not create a new branch.** Stay on the current branch, commit changes, and push directly to origin.233. **Preserve Complete PR Template**:24 - Always load `.github/pull_request_template.md`.25 - **Never delete or strip any sections, questions, or checkboxes**, even if they are not applicable to the current change (e.g. keep Frontend, Backend, UI, Mobile checklist blocks intact).26 - Fill in the applicable fields, check applicable boxes (`[x]`), and leave non-applicable boxes unchecked or noted with `N/A`.274. **Pre-flight Validation Must Pass**:28 - Always run `pnpm run validate` and relevant test suites in the modified packages before committing/pushing.2930---3132## 2. Step-by-Step Submission Procedure3334### Step 1: Pre-Submission Validation35Run the standard validation commands for all packages touched in the PR:3637- **Server (`SparkyFitnessServer/`)**:38 ```bash39 cd SparkyFitnessServer && pnpm format && pnpm test && pnpm validate40 # If database migrations were added or modified:41 pnpm run test:migrations42 ```43- **Frontend (`SparkyFitnessFrontend/`)**:44 ```bash45 cd SparkyFitnessFrontend && pnpm format && pnpm test && pnpm validate46 ```47- **Mobile (`SparkyFitnessMobile/`)**:48 ```bash49 cd SparkyFitnessMobile && pnpm test && pnpm validate50 ```51- **Garmin Microservice (`SparkyFitnessGarmin/`)**:52 ```bash53 cd SparkyFitnessGarmin && ./venv/bin/python -m unittest discover tests54 ```5556Inspect `git status` and `git diff` to ensure no scratch files, debug logs, or unwanted changes are staged.5758### Step 2: Branch Check & Staging591. Check active branch:60 ```bash61 BRANCH=$(git branch --show-current)62 ```632. Handle branch state:64 - **If `BRANCH` is empty (detached HEAD), `main`, or `master`**: Create a new topic branch:65 ```bash66 git checkout -b fix/<topic> # or feat/<topic>67 ```68 - **If already on a named work/dev branch (e.g. `dev`, `fix/...`, `feat/...`)**: Stay on the current branch.693. Stage modified files:70 ```bash71 git add <files>72 ```7374### Step 3: Commit Message75Write a concise conventional commit message referencing any linked issue:76```bash77git commit -m "fix(<domain>): concise summary of fix7879- Bullet point detailing specific change80- Bullet point detailing another change8182Fixes #<issue_number>"83```8485### Step 4: Prepare PR Body from Template86Read `.github/pull_request_template.md` and populate the body file:871. **Description**:88 - **What problem does this PR solve?** (1-2 sentences)89 - **How did you implement the solution?** (Technical bullet points)90 - **Linked Issue**: `Closes #<issue_number>`912. **How to Test**: Concrete steps to run commands, trigger the flow, and verify behavior.923. **PR Type**: Mark `[x]` on the applicable type (Issue, New Feature, Refactor, Documentation).934. **Checklist**: Mark `[x]` on all applicable mandatory items that were executed. **Keep all other checklist items as-is.**945. **Screenshots**: Provide screenshots for UI changes, or `N/A` for backend/headless changes.956. **Notes for Reviewers**: Note any relevant configuration keys, architectural decisions, or performance context.9697### Step 5: Push Branch & Create PR981. Push the branch to `origin`:99 ```bash100 BRANCH=$(git branch --show-current)101 git push -u origin "$BRANCH"102 ```1031042. Create the PR targeting `main` via GitHub CLI:105 ```bash106 gh pr create --base main --title "fix(<domain>): <summary>" --body-file "<path-to-body-file>"107 ```108109### Step 6: Final Verification110Verify the created PR via `gh pr view <number>` to ensure formatting and checklists rendered cleanly.