بنقرة واحدة
checkout
Use when checking out a PR, branch, or ref for local work - sets up worktree with context
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
القائمة
Use when checking out a PR, branch, or ref for local work - sets up worktree with context
التثبيت باستخدام 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 | checkout |
| description | Use when checking out a PR, branch, or ref for local work - sets up worktree with context |
Check out a PR, branch, or ref into an isolated worktree with relevant context.
Announce: "Using git:checkout to set up a worktree for {target}..."
git:inbox when user picks a PRAccept:
https://github.com/{owner}/{repo}/pull/{number}{repo}#{number} or #{number} (infer repo from cwd){number} (infer owner/repo from git remote)feature/auth, main, etc.# Get owner/repo from current directory if needed
gh repo view --json owner,name -q '"\(.owner.login)/\(.name)"'
gh pr view {number} --json title,body,author,state,baseRefName,headRefName,url,reviews,reviewRequests
REQUIRED: Use superpowers:using-git-worktrees skill for directory selection.
# Fetch the PR branch
git fetch origin {headRefName}
# Create worktree
git worktree add .worktrees/pr-{number}-{short-desc} origin/{headRefName}
Naming: pr-{number}-{2-3-word-description} (e.g., pr-1234-add-oauth)
## PR #{number} Ready for Review
**Title:** {title}
**Author:** @{author}
**Branch:** {headRefName} → {baseRefName}
**URL:** {full_url}
### Summary
{1-3 sentence summary from PR body}
### Files Changed ({count})
{Grouped by directory}
### Review Status
{Existing reviews, requested reviewers}
---
**Worktree ready at:** `{full_path}`
# For existing branch
git worktree add .worktrees/{branch-slug} {branch}
# For new branch
git worktree add .worktrees/{branch-slug} -b {branch}
**Worktree ready at:** `{full_path}`
**Branch:** {branch}
| Input | Action |
|---|---|
| PR URL/number | Fetch PR, create worktree, show PR context |
| Branch name | Create worktree for branch |
| Ref/SHA | Create worktree at that ref |
| Mistake | Fix |
|---|---|
| Creating worktree before fetching PR branch | Always git fetch first |
| Generic worktree name | Include PR number AND short description |
| Missing PR context | Always summarize PR and show review status |
superpowers:using-git-worktrees - Handles directory selection and verificationgit:inbox - Discover PRs needing reviewcode-review - Guide the actual review process