rebase

Engineering Community

Repo stars 2,380
License MIT
Author repo dotfiles

Interpretation is structured for decision-making; original keeps the upstream SKILL.md unchanged.

Decide Fit First

Core job: Interactive rebase onto a base branch, resolving conflicts along the way and verifying tests pass. Compares against remote when…
Best fit: Use it when the task has reusable inputs, steps, and validation criteria rather than a one-off answer.
Avoid forcing it: If the source lacks commands, platform support, or external-service evidence, keep those fields unknown instead of guessing.

Design Intent

Structure: The skill is organized around “Step 1: Determine base branch”, “Step 2: Start the rebase”, “Step 3: Resolve conflicts”, “Step 4: Run related tests”, showing how the author expects the agent to judge fit, collect context, and produce verifiable output.
Trigger evidence: Prioritize the author’s wording around when to use it, what context to collect, and what output shape to produce.
Evidence boundary: Author text states facts, repository files prove commands and paths, and Fluxly only adds fit, limits, and usage judgment.

How To Use It

Inputs: Provide target material, scope, expected result, forbidden changes, and validation method.
Invocation: Name rebase directly; if the source includes slash commands, start with the command and then add task context.
Validation: Start small and check whether the result follows “Step 1: Determine base branch / Step 2: Start the rebase / Step 3: Resolve conflicts” before expanding.

Boundaries And Review

Dependencies: It usually needs no extra API key, so start with a small validation task.
Permissions: Declared permissions include read / shell-exec; ask the agent to state file, command, and rollback boundaries before acting.
Quality bar: A useful result names the deliverable, evidence, and next action. Generic prose means the task needs tighter context.

Rebase

Rebase the current branch onto a base branch, resolving conflicts and verifying tests along the way.

Step 1: Determine base branch

Determine the base branch in this order:

Use $ARGUMENTS if the user specifies a branch
Use bin/base-branch if the script exists and is executable
Ask the user which branch to rebase onto

Step 2: Start the rebase

Fetch latest and begin the rebase:

git fetch origin
git rebase origin/<base-branch>

If the rebase completes with no conflicts, skip to Step 6.

Step 3: Resolve conflicts

Identify the conflicting files with git diff --name-only --diff-filter=U
Read each conflicting file and understand both sides of the conflict
Resolve the conflict by taking both sides into account — don't blindly pick one side. Understand the intent of each change and produce a result that incorporates both correctly.
Stage the resolved files with git add

If a conflict is ambiguous and you can't confidently determine the correct resolution, ask the user.

Run the tests related to the files that had conflicts. If tests fail due to the conflict resolution, fix them before proceeding.

If tests fail but seem unrelated to the rebase, verify by stashing and testing:

git stash
# run tests again
git stash pop

If tests also fail without your changes, the failures are pre-existing. Note this for the user and continue.
If tests only fail with your changes, the rebase introduced the problem. Investigate and fix.

If you are unable to resolve test failures, let the user know what's broken and what you tried.

Step 5: Continue the rebase

git rebase --continue

If there are more conflicts, go back to Step 3. Repeat until the rebase is complete.

Step 6: Check remote and compare

Check if a remote tracking branch exists:

git rev-parse --verify @{u} 2>/dev/null

If a remote branch exists, run the /remote-diff skill to compare the rebase result against the remote and flag any potential issues.

If no remote branch exists, skip this step and report that the rebase is complete.

Fluxly profile Author and license come from source; runtime, permissions, and network are Fluxly detections or estimates

Fluxly category: Engineering
Author-declared agents: No explicit declaration found; this is not inferred or tested compatibility
Static check: 94 / 100 · heuristic scan, not runtime safety proof
Author / version / license: @ryanb · MIT
Fluxly token estimate: Lean
Fluxly setup estimate: Guided setup
External API key: No requirement detected
Detected OS requirements: Unspecified
Runtime requirements: Unspecified
Detected file/system behavior: Read-only
Shell exec
Detected network behavior: External requests
Install commands: None (reference only)

Profile is derived at build time from SKILL.md and install vectors. Subject to drift from author intent.

Heads up: 未限定 allowed-tools，默认拥有全部工具权限。

Output preview rebase.preview

The current SKILL.md does not define a fixed output example.

SKILL.md SKILL.md

# Rebase

Rebase the current branch onto a base branch, resolving conflicts and verifying tests along the way.

## Step 1: Determine base branch

Determine the base branch in this order:
1. Use `$ARGUMENTS` if the user specifies a branch
2. Use `bin/base-branch` if the script exists and is executable
3. Ask the user which branch to rebase onto

## Step 2: Start the rebase

Fetch latest and begin the rebase:

```bash
git fetch origin
git rebase origin/<base-branch>
```

If the rebase completes with no conflicts, skip to Step 6.

## Step 3: Resolve conflicts

1. Identify the conflicting files with `git diff --name-only --diff-filter=U`
2. Read each conflicting file and understand both sides of the conflict
3. Resolve the conflict by taking both sides into account — don't blindly pick one side. Understand the intent of each change and produce a result that incorporates both correctly.
4. Stage the resolved files with `git add`

If a conflict is ambiguous and you can't confidently determine the correct resolution, ask the user.

## Step 4: Run related tests

Run the tests related to the files that had conflicts. If tests fail due to the conflict resolution, fix them before proceeding.

If tests fail but seem **unrelated** to the rebase, verify by stashing and testing:

```bash
git stash
# run tests again
git stash pop
```

- If tests also fail without your changes, the failures are pre-existing. Note this for the user and continue.
- If tests only fail with your changes, the rebase introduced the problem. Investigate and fix.

If you are unable to resolve test failures, let the user know what's broken and what you tried.

## Step 5: Continue the rebase

```bash
git rebase --continue
```

If there are more conflicts, go back to Step 3. Repeat until the rebase is complete.

…

Evidence boundary and execution chain

Author text anchors workflow facts; Fluxly only indexes current sections, terms, files, and commands.

sections -> Step 1: Determine base branch → Step 2: Start the rebase → Step 3: Resolve conflicts → Step 4: Run related tests → Step 5: Continue the rebase → Step 6: Check remote and compare
terms    -> unrelated · Rebase the current branch onto a base branch, resolving conflicts and verifying tests along the way. · Determine the base branch in this order: 1. · If the rebase completes with no conflicts, skip to Step 6. · 1. Identify the conflicting files with git diff --name-only --diff-filter=U 2. · If a conflict is ambiguous and you can't confidently determine the correct resolution, ask the user. · Run the tests related to the files that had conflicts. · - If tests also fail without your changes, the failures are pre-existing.
files/cmd -> $ARGUMENTS · bin/base-branch · git diff --name-only --diff-filter=U · git add · /remote-diff
body sha256 -> 8a5cdd456604