Pull

Purpose

Bring the current branch up to date with the remote default branch (typically
```
origin/main
```
) using a merge (not rebase, unless AGENTS.md or team policy says otherwise).
Resolve merge conflicts safely and verify with pnpm lint && pnpm test
(or the repo’s documented checks).
Prefer rerere and clear conflict styles so repeated conflicts are easier to handle.

Prerequisites

Git remote
```
origin
```
exists and points at the expected host.
You know which branch is the integration base (usually
```
main
```
; use the repo’s default if different).

When to Use

"pullして", "main を取り込んで", "同期して", or similar—when the feature branch must match
```
origin/main
```
(or the team base branch).
After git push
is rejected with non-fast-forward, or when the local branch is behind the remote tracking branch.
When preparing to push and the branch needs the latest upstream changes first (often chained before push).

Do Not Use When

The user only wants to push without merging the base (use push; if push fails, then use pull).
The user wants to create or update a GitHub PR (use create-pr-jp).
The goal is merging or landing an approved PR on the default branch (use a land or merge workflow skill if the workspace defines one—not this skill).

Related Skills

push: After sync and green checks, publish commits to
```
origin
```
.
create-pr-jp: Open or update a PR; out of scope for pull.

Procedure

Ensure the working tree is safe to merge: commit or stash uncommitted work before merging.

Enable rerere locally (recommended):

```
git config rerere.enabled true
```
```
git config rerere.autoupdate true
```

Confirm remotes and branch:
```
origin
```
exists; the current branch is the one that should receive the merge.
Fetch:
```
git fetch origin
```
Fast-forward the current branch from its remote counterpart if it exists (picks up remote-only commits before merging main):
- ```
git pull --ff-only origin "$(git branch --show-current)"
```
Merge the base branch (replace
```
main
```
if the repo uses another default):
- Prefer
```
git -c merge.conflictstyle=zdiff3 merge origin/main
```
  for clearer conflict context.
If conflicts appear, resolve them (see Conflict Resolution below), then:
- ```
git add <files>
```
- ```
git commit
```
  or
```
git merge --continue
```
  as appropriate.
Verify: run pnpm lint && pnpm test
, or follow
```
AGENTS.md
```
/ project scripts if they differ.
Summarize for the user: hardest conflicts, how they were resolved, and any follow-ups.

Output

Current branch contains the merged base; conflicts resolved; pnpm lint && pnpm test
(or repo equivalent) passed.
A clear narrative of what was merged and any notable resolution decisions.

Usage

Reference flow (adapt

main

/ branch names to the repo):

git config rerere.enabled true
git config rerere.autoupdate true

git fetch origin

# Optional: sync remote feature branch commits first
git pull --ff-only origin "$(git branch --show-current)"

# Merge default branch (zdiff3 for conflict readability)
git -c merge.conflictstyle=zdiff3 merge origin/main

# After resolving conflicts:
# git add … && git commit   # or git merge --continue

pnpm lint && pnpm test

Conflict Resolution

Inspect before editing:
- ```
git status
```
  for conflicted files;
```
git diff
```
  /
```
git diff --merge
```
  for hunks.
- Optional:
```
git diff :1:path :2:path
```
  and
```
:1:
```
  vs
```
:3:
```
  for base vs ours/theirs.
- With
```
merge.conflictstyle=zdiff3
```
  , markers are
```
<<<<<<<
```
  ours,
```
|||||||
```
  base,
```
=======
```
  ,
```
>>>>>>>
```
  theirs.
- Infer intent on both sides; choose semantics first, then edit code.
Prefer minimal, intention-preserving edits aligned with the branch’s purpose.
Resolve in batches; rerun
pnpm lint && pnpm test
after a logical batch of files when helpful.
Use ours/theirs only when one side should win entirely.
Generated files: fix sources first, then regenerate with the project’s command; stage regenerated output.
Import conflicts: if unclear, temporarily keep both imports, finish the merge, then let lint/typecheck trim unused imports.
After resolution:
```
git diff --check
```
(no conflict markers left).

When to Ask the User

Ask only when there is no safe default. Prefer a documented decision and proceed otherwise.

Ask when:

Product behavior cannot be inferred from code, tests, or docs.
The conflict affects a public API, migration, or contract with no clear safe choice.
Two designs are equally plausible with no local signal.
The change risks data loss, schema damage, or irreversible effects without a safe default.
The branch or remote names cannot be determined locally.

Otherwise complete the merge, note assumptions briefly, and leave reviewable history.

Present Results to User

State the base branch merged (e.g.
```
origin/main
```
) and the current branch name.
List major conflict areas and how they were fixed.
Report pnpm lint && pnpm test
(or what ran) and pass/fail.
Do not claim a PR was updated or that commits were pushed—those are create-pr-jp and push.

Notes

Default integration strategy here is merge; do not rebase unless the repository explicitly requires it.
If
```
git pull --ff-only origin <branch>
```
fails, diagnose (diverged history) before merging
```
origin/main
```
.

Troubleshooting

Situation	Action
Dirty working tree	Commit or stash before merge
`merge` conflicts	Follow Conflict Resolution, then `pnpm lint && pnpm test`
Wrong default branch name	Use `git symbolic-ref refs/remotes/origin/HEAD` or repo docs for `main` vs `master`
Lint/test fails after merge	Fix or revert; do not push broken state—coordinate with push only after green checks

pull

NPX Install

Tags

SKILL.md Content