ワンクリックで
update
Use when updating your branch with upstream changes - fetches, merges, and intelligently resolves conflicts
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
メニュー
Use when updating your branch with upstream changes - fetches, merges, and intelligently resolves conflicts
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
Use when investigating an agent-harness CLI's internals (Claude Code, codex, opencode, or similar): extracting the system prompt or tool descriptions, finding what code path produces a specific UI message, decoding minified function names or Rust symbols, understanding undocumented config keys, or otherwise spelunking a shipped binary (or its pinned source) to figure out how the tool actually behaves.
Use when about to lock in a non-trivial or hard-to-reverse decision, fire AskUserQuestion to offload a call, proceed on your own preferred option, or assert something is done / found / tested / fixed / "that's how it works" — especially when the basis is memory, the handoff, the first framing, or an unchecked assumption rather than something verified this session. Also invoked as /gut-check. Use even when you feel confident; confidence is the symptom, not the all-clear.
Obsidian vault mechanics - wiki links, .obsidian/ config, daily notes, plugins. Use when working with Obsidian vaults or structured markdown.
Analyze an enriched note and route to the best vault destination. Stage 3 of the processing pipeline.
Diagnose and fix LSP setup for the current project's detected ecosystems (Rust, TypeScript, Ruby). Use when the SessionStart hook nudged about a missing LSP plugin, when the env isn't ready (no `bundle install`, no `cargo build`, missing server binary), when LSP calls are failing, or when the user invokes `/actually-lsp-doctor` directly. Walks the per-ecosystem state machine, reports what's missing, then runs the fix.
Use when structuring prose so readers can skim it - drafting or restructuring READMEs, docs, PR or issue bodies, design docs, RFCs, or any long-form text where a wall of prose hides the structure. Also use when explicitly asked to make something scannable or skimmable, convert prose to a list, surface a buried list, fix a wall of text, or decide whether bullets or prose fit. Strong signal: text with parallel sentence shapes, contrast markers ("that's distinct from", "versus"), bolded terms followed by colons, or an embedded "X, Y, and Z" series. Composes with prose-clarity skills (concision) and voice skills (personality) rather than replacing them. Skip for source code and for casual one-line replies where formatting reads as overkill.
| name | update |
| description | Use when updating your branch with upstream changes - fetches, merges, and intelligently resolves conflicts |
Update your current branch with changes from the upstream branch, intelligently resolving conflicts when they occur.
Announce: "Using git:update to sync your branch with upstream..."
Philosophy:
git rev-parse --abbrev-ref @{upstream} 2>/dev/null
If this succeeds, use the result (e.g., origin/main).
If no tracking branch:
gh pr view --json baseRefName -q '.baseRefName' 2>/dev/null
If this succeeds, use origin/{result}.
If both fail, use AskUserQuestion:
I couldn't detect an upstream branch for this branch.
Which branch should I merge from?
(A) main
(B) master
(C) Other - I'll specify
git fetch origin
git rev-list --count HEAD..{upstream}
If count is 0, report "Already up to date with {upstream}" and stop.
git merge {upstream} --no-edit
| Exit Code | Meaning | Action |
|---|---|---|
| 0 | Clean merge | Push and report success |
| 1 | Conflicts | Proceed to conflict resolution |
On clean merge:
git push
Report:
## Update Complete
Merged `{upstream}` into `{current-branch}`
{N} commits pulled in
Pushed to origin
git diff --name-only --diff-filter=U
Read the conflict:
cat {file} # Shows conflict markers
Understand "ours" (your branch):
git log --oneline -5 HEAD -- {file}
git show HEAD:{file} # Your version
Understand "theirs" (upstream):
git log --oneline -5 {upstream} -- {file}
git show {upstream}:{file} # Their version
Get commit messages for context:
# What your commits were doing
git log --format="%s%n%b" HEAD...$(git merge-base HEAD {upstream}) -- {file}
# What upstream commits were doing
git log --format="%s%n%b" {upstream}...$(git merge-base HEAD {upstream}) -- {file}
For each conflict, determine the type:
| Type | Description | Resolution Strategy |
|---|---|---|
| Independent | Changes to different parts of file | Keep both changes |
| Overlapping | Same area, different purposes | Blend changes thoughtfully |
| Contradictory | Mutually exclusive changes | Present options to user |
Analysis approach:
For independent changes:
For overlapping changes:
For contradictory changes:
After resolving, show summary:
## Conflict Resolution Summary
Merged `main` into `feature/my-branch`
### {filename}
**Your changes:** {1-2 sentence summary of what your commits did}
**Upstream changes:** {1-2 sentence summary of what upstream commits did}
**Resolution:** {1-2 sentence explanation of how resolved}
```diff
{Show key parts of the resolution}
[Repeat for each file]
Verification:
Does this resolution look correct? (A) Yes, commit and push (B) Let me review/adjust manually (C) Show me more context on a specific file
Use AskUserQuestion with these options.
## Workflow: Verification & Completion
### Step 1: Verify no conflict markers
```bash
grep -rn "^<<<<<<< \|^=======$\|^>>>>>>> " {resolved_files}
If any found, resolution is incomplete - fix before proceeding.
| File Type | Check |
|---|---|
.json | python -m json.tool {file} > /dev/null |
.yaml/.yml | python -c "import yaml; yaml.safe_load(open('{file}'))" |
.ts/.tsx | npx tsc --noEmit {file} (if tsconfig exists) |
.py | python -m py_compile {file} |
git add {resolved_files}
git commit -m "Merge {upstream} into {branch}
Resolved conflicts in:
$(for f in {resolved_files}; do echo "- $f"; done)"
git push
## Update Complete
Merged `{upstream}` into `{branch}`
Resolved {N} conflict(s):
- {file1}
- {file2}
Pushed to origin. PR should now be mergeable.
| Situation | Handling |
|---|---|
| Binary file conflicts | Flag for manual resolution: "Binary file {file} has conflicts - please resolve manually" |
| Submodule conflicts | Flag with guidance: "Submodule {name} has conflicts. Usually: accept upstream version or update to specific commit" |
| Someone else's branch | Check with gh pr view --json author -q '.author.login'. If not current user, warn: "This is @{author}'s branch. They should be aware of changes. Continue?" |
| Too complex to resolve | Present what was understood, mark specific hunks as needing manual attention |
| Merge already in progress | Detect with git status showing "You have unmerged paths". Offer to continue or abort. |
| Command | Purpose |
|---|---|
git rev-parse --abbrev-ref @{upstream} | Get tracking branch |
git merge --abort | Cancel in-progress merge |
git diff --name-only --diff-filter=U | List conflicted files |
git checkout --ours {file} | Take your version entirely |
git checkout --theirs {file} | Take upstream version entirely |
git show HEAD:{file} | Your version of file |
git show MERGE_HEAD:{file} | Upstream version of file |
git:commit - Commit practices (used after resolution)git:pull-request - Creating/updating PRsgit:triage - Overview of work state