Ejecuta cualquier Skill en Manus
con un clic

Ejecuta cualquier Skill en Manus con un clic

stack-split

Estrellas1

Forks0

Actualizado26 de marzo de 2026 a las 20:32

Use when you need to break up, split, or decompose a large commit into smaller atomic commits. Use INSTEAD of manual git rebase -i + edit or git reset HEAD^. Prevents: non-working intermediate commits, wrong split ordering, missed downstream restack.

Instalación

Instalar con Codex o Claude Copia este prompt, pégalo en Codex, Claude u otro asistente, y deja que revise la página de la skill y la instale por ti.

Ejecutar en Manus

Fuente

higherorderfunctor

higherorderfunctor/stacked-workflow-skills

Abrir repositorio de GitHub Ver repositorios del creador

Descarga

Ejecutar en Manus

Ocupaciones relacionadasSOC

Basado en la clasificación ocupacional SOC

Desarrolladores de softwareOcupaciones informáticas y matemáticas·SOC 15-1252

Explorador de archivos

3 archivos

SKILL.md

readonly

name	stack-split
description	Use when you need to break up, split, or decompose a large commit into smaller atomic commits. Use INSTEAD of manual git rebase -i + edit or git reset HEAD^. Prevents: non-working intermediate commits, wrong split ordering, missed downstream restack.
argument-hint	[commit]
disable-model-invocation	true
compatibility	Requires git-branchless

Split a large commit into multiple smaller, atomic commits. Target commit defaults to HEAD if not specified.

Pre-flight

Load references — read references/git-branchless.md and references/philosophy.md (relative to this skill's directory) before proceeding.

Check branchless init:

if [ ! -d ".git/branchless" ]; then git branchless init; fi

Check for stale rebase state:
```
ls .git/rebase-merge .git/rebase-apply 2>/dev/null
```
If present, run git rebase --abort before proceeding.

Steps

Identify the target commit. If $ARGUMENTS is provided, use it. Otherwise default to HEAD.
Analyze the commit to understand what it contains:
```
git show --stat <commit>
git show <commit>
```
Read the full diff. Identify logical groups following the ordering in references/philosophy.md:
- Refactoring / cleanup (should be first)
- Type definitions / interfaces / schemas
- Core logic changes
- Edge cases / error handling
- Tests
Documentation belongs with the feature it documents, not as a separate split. Dependencies and config files go in the commit that first uses them.
Propose a split plan to the user. For each proposed commit:
- One-sentence description
- Which files/hunks belong to it
- Why it's a separate concern
Wait for user approval before proceeding.
Perform the split using interactive rebase:
```
git rebase -i <commit>^
```
Mark the target commit as edit, then:
```
git reset HEAD^
```
This unwinds the commit but keeps all changes in the working tree.
Stage and commit each group in the agreed order:
```
git add -p  # or git add <specific-files>
git commit -m "descriptive message for this group"
```
Repeat for each logical group. Each commit must:
- Be describable in one sentence
- Leave the codebase in a working state
- Target 50-200 lines
Complete the rebase:
```
git rebase --continue
```
Restack if there are downstream commits:
```
git restack
```
Verify the result:
```
git sl
```
Show the user the new stack. If a test command is available, run tests across the new commits:
```
git test run -x '<test-command>' 'stack()'
```

Alternative: Full Stack Restructure

If the user wants to restructure multiple commits (not just split one), use /stack-plan instead.

Tips

Format changes should ALWAYS be a separate commit (they dominate diffs and hide functional changes)
If a file has both refactoring and new logic, use git add -p to split hunks within the file
Prefer too many small commits over too few large ones — they can always be squashed later
Each commit message should explain WHY, not just WHAT

Más de este repositorio

mismo repositorio

index-repo-docs

higherorderfunctor/stacked-workflow-skills

Use when you need to create or update a reference doc from a repo's wiki, docs, and issues. Fetches and distills into a focused reference.

2026-03-261

repo-review

higherorderfunctor/stacked-workflow-skills

Use when you need a multi-perspective review of this repo. Spawns 6 specialized reviewers (git expert, agentic UX, human UX, nix expert, FP/DRY expert, consistency auditor). Aggregates findings, deduplicates, respects recorded decisions, and proposes changes with human approval.

2026-03-261

stack-fix

higherorderfunctor/stacked-workflow-skills

Use when you need to fix, correct, or update content in an earlier commit. Absorbs staged changes into correct stack commits INSTEAD of running git absorb or git commit --fixup via Bash. Prevents: missed dry-run preview, leftover staged changes going unnoticed, forgetting to restack. Falls back to guided manual amend when absorb cannot route hunks.

2026-03-261

stack-plan

higherorderfunctor/stacked-workflow-skills

Use when you need to plan commits, restructure a stack, or commit uncommitted work as organized atomic commits. Builds a stack from a description, uncommitted work, or existing commits INSTEAD of manual git rebase -i, git reset --soft, or ad-hoc git move sequences. Prevents: wrong commit ordering, forward references, git move -F panics, untested intermediates.

2026-03-261

stack-submit

higherorderfunctor/stacked-workflow-skills

Use when you need to push, submit, or create pull requests for a commit stack. Syncs, validates, and pushes INSTEAD of manual git sync + git submit + PR/MR creation. Handles branch creation, stacked PR/MR creation with correct base branches, and sentinel commit exclusion.

2026-03-261

stack-summary

higherorderfunctor/stacked-workflow-skills

Use when you need to audit, analyze, or review stack quality before restructuring. Produces a structured summary with per-commit classification, philosophy audit, and violation flags. Output feeds directly into /stack-plan restructure mode. Use INSTEAD of manual git log inspection.

2026-03-261

name	stack-split
description	Use when you need to break up, split, or decompose a large commit into smaller atomic commits. Use INSTEAD of manual git rebase -i + edit or git reset HEAD^. Prevents: non-working intermediate commits, wrong split ordering, missed downstream restack.
argument-hint	[commit]
disable-model-invocation	true
compatibility	Requires git-branchless

Split a large commit into multiple smaller, atomic commits. Target commit defaults to HEAD if not specified.

Pre-flight

Load references — read references/git-branchless.md and references/philosophy.md (relative to this skill's directory) before proceeding.

Check branchless init:

if [ ! -d ".git/branchless" ]; then git branchless init; fi

Check for stale rebase state:
```
ls .git/rebase-merge .git/rebase-apply 2>/dev/null
```
If present, run git rebase --abort before proceeding.

Steps

Identify the target commit. If $ARGUMENTS is provided, use it. Otherwise default to HEAD.
Analyze the commit to understand what it contains:
```
git show --stat <commit>
git show <commit>
```
Read the full diff. Identify logical groups following the ordering in references/philosophy.md:
- Refactoring / cleanup (should be first)
- Type definitions / interfaces / schemas
- Core logic changes
- Edge cases / error handling
- Tests
Documentation belongs with the feature it documents, not as a separate split. Dependencies and config files go in the commit that first uses them.
Propose a split plan to the user. For each proposed commit:
- One-sentence description
- Which files/hunks belong to it
- Why it's a separate concern
Wait for user approval before proceeding.
Perform the split using interactive rebase:
```
git rebase -i <commit>^
```
Mark the target commit as edit, then:
```
git reset HEAD^
```
This unwinds the commit but keeps all changes in the working tree.
Stage and commit each group in the agreed order:
```
git add -p  # or git add <specific-files>
git commit -m "descriptive message for this group"
```
Repeat for each logical group. Each commit must:
- Be describable in one sentence
- Leave the codebase in a working state
- Target 50-200 lines
Complete the rebase:
```
git rebase --continue
```
Restack if there are downstream commits:
```
git restack
```
Verify the result:
```
git sl
```
Show the user the new stack. If a test command is available, run tests across the new commits:
```
git test run -x '<test-command>' 'stack()'
```

Alternative: Full Stack Restructure

If the user wants to restructure multiple commits (not just split one), use /stack-plan instead.

Tips

Format changes should ALWAYS be a separate commit (they dominate diffs and hide functional changes)
If a file has both refactoring and new logic, use git add -p to split hunks within the file
Prefer too many small commits over too few large ones — they can always be squashed later
Each commit message should explain WHY, not just WHAT