/stacked-prs
Create semantic commits split into stacked upstream PRs under 600 lines each
$ npx -y skills add carloshpdoc/ios-workflow-claude --agent claude-codeHow it fires
How this command gets triggered: by you, by Claude, or both.
- Fires itselfClaude auto-loads it when your prompt matches the work.
- You can call itInvoke it directly when you want it.
- Slash command
/stacked-prs
Context preview
What this command does when you run it.
Create semantic commits split into stacked upstream PRs under 600 lines each
Command definition
stacked-prs.mdname: stacked-prs
description: Create semantic commits split into stacked upstream PRs under 600 lines each
usage: /stacked-prs
> **Project context:** Values in angle brackets below (e.g. `<scheme>`, `<JIRA_KEY>`, `<flag-key-enum>`) are resolved at runtime — detect them from the project (`xcodebuild -list -json` for the scheme, `git`/`gh` for repo & owner, the branch name for the Jira key, a codebase search for flag/font files), or ask if they cannot be inferred. This plugin ships no per-project config.
Stacked PRs Workflow
You are creating semantic commits and splitting them into stacked upstream PRs, each under 600 added lines.
Task
Split uncommitted changes into multiple branches with semantic commits, where each branch is based on the previous one, creating a chain of PRs.
Workflow
Step 1: Analyze Changes
1. Run `git status` and `git diff --stat` to identify all changed/new files 2. Ask the user which files should be **excluded** from commits (e.g., unrelated docs, settings changes, storekit files) 3. Count lines per file: `wc -l <file>` for new files, `git diff --stat <file>` for modified files
Step 2: Plan the Split
Group files into logical commits, each under 600 added lines:
**Suggested grouping order** (adapt to the actual changes): 1. **Models/DTOs** — domain models, response types, shared models 2. **Data layer** — repositories, data sources, mappers, queries, mock data 3. **Presentation** — view models, coordinators, factories, use cases, views 4. **Tests** — test mocks, unit tests (split further if over 600 lines)
Present the plan to the user with line counts per group before proceeding.
Step 2.5: Select PR Label
Every PR must have exactly one report label. Select **once** for the entire chain (all PRs get the same label):
| Label | Use when | |-------|----------| | `report-feature` | New feature or functionality | | `report-improvement-fix` | Bug fix or UX improvement (not a new feature) | | `report-tech-improvement` | Tech debt, CI/CD, refactoring, code removal | | `report-analytics-fix` | Analytics-related changes |
**Auto-inference from TYPE:**
- FEATURE → `report-feature`
- FIX → `report-improvement-fix`
- REFACTOR, BUILD, CI, PERF, STYLE, DOCS, TEST → `report-tech-improvement`
If ambiguous, ask the user.
Step 3: Determine Branch Naming
- Use the current branch name as the base (e.g., `feature/<JIRA_KEY>-XXXX`)
- Subsequent branches append `-pt2`, `-pt3`, etc.
- Example: `feature/<JIRA_KEY>-XXXX`, `feature/<JIRA_KEY>-XXXX-pt2`, `feature/<JIRA_KEY>-XXXX-pt3`
Step 4: Create Commits and PRs
For each group, sequentially:
1. **Create branch** (except for pt1 which uses the current branch):
git checkout -b feature/<JIRA_KEY>-XXXX-ptN
2. **Stage specific files**:
git add <file1> <file2> ...
3. **Commit with semantic message**:
git commit -m "$(cat <<'EOF'
<type>(<scope>): <description>
<body explaining what and why>
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
EOF
)"
Types: `feat`, `fix`, `test`, `refactor`, `docs`, `style`, `perf`, `ci`
4. **Push branch**:
git push -u origin <branch-name>
5. **Create PR** using the <scheme> template with `gh pr create`:
- pt1 targets `dev` (or the main branch)
- pt2+ targets the previous branch in the chain
- Title format: `[TYPE][<JIRA_KEY>-XXXX] Description (ptN)`
- Body includes the full PR template from `/create-pr`
- Add `--label "<selected-label>"` using the label chosen in Step 2.5
- Add "Stacked PR chain" section in "Other information" listing all parts
Step 5: Summary
Print a table with all created PRs:
| PR | Branch | Base | Title | Lines |
|---|---|---|---|---|
| #XXXX | feature/<JIRA_KEY>-XXXX | dev | Description (pt1) | +NNN |
| #XXXX | feature/<JIRA_KEY>-XXXX-pt2 | feature/<JIRA_KEY>-XXXX | Description (pt2) | +NNN |
PR Template
Use the same template as `/create-pr`:
## Pull Request Checklist
- [x] I tested my code (for bug/feature)
- [ ] Documents have been revised and added/updated if necessary (for bug/feature fixes)
- [x] The build was run locally, and all changes were pushed
- [ ] Feature tested for accessibility
## What is the current behavior?
[Describe the current behavior or link to a relevant issue]
## What is the new behavior?
[Describe the behavior or changes being added by this PR]
## Have any third-party libraries been added or changed?
[Describe what the libraries are, or write "No"]
## Does this change involve any AB testing?
[If so, what is the experiment's name and the link to it in the console? If not, what is the justification for the absence?]
## Evidence
[Screenshots/videos of how the components/functionalities are changed or created]
## Other information
Stacked PR chain:
- **ptN (this PR)**: [description]
- ptN+1: [description]
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Important Notes
- Each PR must be under 600 added lines
- Never include files the user asked to exclude
- Always use `--base` flag pointing to the previous branch in the chain (except pt1 which targets `dev`)
- Run `swiftformat` on all Swift files before committing
- Verify staged file counts with `git diff --cached --stat` before each commit
Read more
name: stacked-prs description: Create semantic commits split into stacked upstream PRs under 600 lines each usage: /stacked-prs
> **Project context:** Values in angle brackets below (e.g. `<scheme>`, `<JIRA_KEY>`, `<flag-key-enum>`) are resolved at runtime — detect them from the project (`xcodebuild -list -json` for the scheme, `git`/`gh` for repo & owner, the branch name for the Jira key, a codebase search for flag/font files), or ask if they cannot be inferred. This plugin ships no per-project config.
Stacked PRs Workflow
You are creating semantic commits and splitting them into stacked upstream PRs, each under 600 added lines.
Task
Split uncommitted changes into multiple branches with semantic commits, where each branch is based on the previous one, creating a chain of PRs.
Workflow
Step 1: Analyze Changes
1. Run `git status` and `git diff --stat` to identify all changed/new files 2. Ask the user which files should be **excluded** from commits (e.g., unrelated docs, settings changes, storekit files) 3. Count lines per file: `wc -l <file>` for new files, `git diff --stat <file>` for modified files
Step 2: Plan the Split
Group files into logical commits, each under 600 added lines:
**Suggested grouping order** (adapt to the actual changes): 1. **Models/DTOs** — domain models, response types, shared models 2. **Data layer** — repositories, data sources, mappers, queries, mock data 3. **Presentation** — view models, coordinators, factories, use cases, views 4. **Tests** — test mocks, unit tests (split further if over 600 lines)
Present the plan to the user with line counts per group before proceeding.
Step 2.5: Select PR Label
Every PR must have exactly one report label. Select **once** for the entire chain (all PRs get the same label):
| Label | Use when | |-------|----------| | `report-feature` | New feature or functionality | | `report-improvement-fix` | Bug fix or UX improvement (not a new feature) | | `report-tech-improvement` | Tech debt, CI/CD, refactoring, code removal | | `report-analytics-fix` | Analytics-related changes |
**Auto-inference from TYPE:**
- FEATURE → `report-feature`
- FIX → `report-improvement-fix`
- REFACTOR, BUILD, CI, PERF, STYLE, DOCS, TEST → `report-tech-improvement`
If ambiguous, ask the user.
Step 3: Determine Branch Naming
- Use the current branch name as the base (e.g., `feature/<JIRA_KEY>-XXXX`)
- Subsequent branches append `-pt2`, `-pt3`, etc.
- Example: `feature/<JIRA_KEY>-XXXX`, `feature/<JIRA_KEY>-XXXX-pt2`, `feature/<JIRA_KEY>-XXXX-pt3`
Step 4: Create Commits and PRs
For each group, sequentially:
1. **Create branch** (except for pt1 which uses the current branch):
git checkout -b feature/<JIRA_KEY>-XXXX-ptN
2. **Stage specific files**:
git add <file1> <file2> ...
3. **Commit with semantic message**:
git commit -m "$(cat <<'EOF' <type>(<scope>): <description> <body explaining what and why> Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com> EOF )"
Types: `feat`, `fix`, `test`, `refactor`, `docs`, `style`, `perf`, `ci`
4. **Push branch**:
git push -u origin <branch-name>
5. **Create PR** using the <scheme> template with `gh pr create`:
- pt1 targets `dev` (or the main branch)
- pt2+ targets the previous branch in the chain
- Title format: `[TYPE][<JIRA_KEY>-XXXX] Description (ptN)`
- Body includes the full PR template from `/create-pr`
- Add `--label "<selected-label>"` using the label chosen in Step 2.5
- Add "Stacked PR chain" section in "Other information" listing all parts
Step 5: Summary
Print a table with all created PRs:
| PR | Branch | Base | Title | Lines | |---|---|---|---|---| | #XXXX | feature/<JIRA_KEY>-XXXX | dev | Description (pt1) | +NNN | | #XXXX | feature/<JIRA_KEY>-XXXX-pt2 | feature/<JIRA_KEY>-XXXX | Description (pt2) | +NNN |
PR Template
Use the same template as `/create-pr`:
## Pull Request Checklist - [x] I tested my code (for bug/feature) - [ ] Documents have been revised and added/updated if necessary (for bug/feature fixes) - [x] The build was run locally, and all changes were pushed - [ ] Feature tested for accessibility ## What is the current behavior? [Describe the current behavior or link to a relevant issue] ## What is the new behavior? [Describe the behavior or changes being added by this PR] ## Have any third-party libraries been added or changed? [Describe what the libraries are, or write "No"] ## Does this change involve any AB testing? [If so, what is the experiment's name and the link to it in the console? If not, what is the justification for the absence?] ## Evidence [Screenshots/videos of how the components/functionalities are changed or created] ## Other information Stacked PR chain: - **ptN (this PR)**: [description] - ptN+1: [description] 🤖 Generated with [Claude Code](https://claude.com/claude-code)
Important Notes
- Each PR must be under 600 added lines
- Never include files the user asked to exclude
- Always use `--base` flag pointing to the previous branch in the chain (except pt1 which targets `dev`)
- Run `swiftformat` on all Swift files before committing
- Verify staged file counts with `git diff --cached --stat` before each commit
Reusable Claude Code slash-commands, skills, and workflows extracted from real iOS / backend projects. Packaged as three installable plugins - register the marketplace and /plugin install what you need.
Repo: carloshpdoc/ios-workflow-claude
Other commands on ios-workflow-claude.
- /apollo-check
**Project context:** Values in angle brackets below (e.g. `<scheme>`, `<JIRA_KEY>`, `<flag-key-enum>`) are resolved at runtime — detect them from the project (`xcodebuild -list -json` for the scheme, `git`/`gh` for repo & owner, the branch name for the Jira key, a codebase
Open command - /apollo-migrate
**Project context:** Values in angle brackets below (e.g. `<scheme>`, `<JIRA_KEY>`, `<flag-key-enum>`) are resolved at runtime — detect them from the project (`xcodebuild -list -json` for the scheme, `git`/`gh` for repo & owner, the branch name for the Jira key, a codebase
Open command - /apollo-review
**Project context:** Values in angle brackets below (e.g. `<scheme>`, `<JIRA_KEY>`, `<flag-key-enum>`) are resolved at runtime — detect them from the project (`xcodebuild -list -json` for the scheme, `git`/`gh` for repo & owner, the branch name for the Jira key, a codebase
Open command - /apollo-status
**Project context:** Values in angle brackets below (e.g. `<scheme>`, `<JIRA_KEY>`, `<flag-key-enum>`) are resolved at runtime — detect them from the project (`xcodebuild -list -json` for the scheme, `git`/`gh` for repo & owner, the branch name for the Jira key, a codebase
Open command - /apollo-tasks
**Project context:** Values in angle brackets below (e.g. `<scheme>`, `<JIRA_KEY>`, `<flag-key-enum>`) are resolved at runtime — detect them from the project (`xcodebuild -list -json` for the scheme, `git`/`gh` for repo & owner, the branch name for the Jira key, a codebase
Open command - /bump
Bump the app version or build number across all targets in the current project.
Open command