pull

SKILL.md

Pull

Workflow

Verify git status is clean or commit/stash changes before merging.

Ensure rerere is enabled locally:

git config rerere.enabled true

git config rerere.autoupdate true

Confirm remotes and branches:

Ensure the origin remote exists.

Ensure the current branch is the one to receive the merge.

Fetch latest refs:

git fetch origin

Sync the remote feature branch first:

git pull --ff-only origin $(git branch --show-current)

This pulls branch updates made remotely (for example, a GitHub auto-commit)
before merging origin/main.

Merge in order:

Prefer git -c merge.conflictstyle=zdiff3 merge origin/main for clearer
conflict context.

If conflicts appear, resolve them (see conflict guidance below), then:

git add <files>

git commit (or git merge --continue if the merge is paused)

Verify with project checks (follow repo policy in AGENTS.md).

Summarize the merge:

Call out the most challenging conflicts/files and how they were resolved.

Note any assumptions or follow-ups.

Conflict Resolution Guidance (Best Practices)

Inspect context before editing:

Use git status to list conflicted files.

Use git diff or git diff --merge to see conflict hunks.

Use git diff :1:path/to/file :2:path/to/file and
git diff :1:path/to/file :3:path/to/file to compare base vs ours/theirs
for a file-level view of intent.

With merge.conflictstyle=zdiff3, conflict markers include:

<<<<<<< ours, ||||||| base, ======= split, >>>>>>> theirs.

Matching lines near the start/end are trimmed out of the conflict region,
so focus on the differing core.

Summarize the intent of both changes, decide the semantically correct
outcome, then edit:

State what each side is trying to achieve (bug fix, refactor, rename,
behavior change).

Identify the shared goal, if any, and whether one side supersedes the
other.

Decide the final behavior first; only then craft the code to match that
decision.

Prefer preserving invariants, API contracts, and user-visible behavior
unless the conflict clearly indicates a deliberate change.

Open files and understand intent on both sides before choosing a resolution.

Prefer minimal, intention-preserving edits:

Keep behavior consistent with the branch’s purpose.

Avoid accidental deletions or silent behavior changes.

Resolve one file at a time and rerun tests after each logical batch.

Use ours/theirs only when you are certain one side should win entirely.

For complex conflicts, search for related files or definitions to align with
the rest of the codebase.

For generated files, resolve non-generated conflicts first, then regenerate:

Prefer resolving source files and handwritten logic before touching
generated artifacts.

Run the CLI/tooling command that produced the generated file to recreate it
cleanly, then stage the regenerated output.

For import conflicts where intent is unclear, accept both sides first:

Keep all candidate imports temporarily, finish the merge, then run lint/type
checks to remove unused or incorrect imports safely.

After resolving, ensure no conflict markers remain:

git diff --check

When unsure, note assumptions and ask for confirmation before finalizing the
merge.

When To Ask The User (Keep To A Minimum)

Do not ask for input unless there is no safe, reversible alternative. Prefer
making a best-effort decision, documenting the rationale, and proceeding.

Ask the user only when:

The correct resolution depends on product intent or behavior not inferable
from code, tests, or nearby documentation.

The conflict crosses a user-visible contract, API surface, or migration where
choosing incorrectly could break external consumers.

A conflict requires selecting between two mutually exclusive designs with
equivalent technical merit and no clear local signal.

The merge introduces data loss, schema changes, or irreversible side effects
without an obvious safe default.

The branch is not the intended target, or the remote/branch names do not exist
and cannot be determined locally.

Otherwise, proceed with the merge, explain the decision briefly in notes, and
leave a clear, reviewable commit history.
1d