بنقرة واحدة
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