Menu
Use when checking what PRs are waiting for your review, or when starting your day to see what needs attention
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
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 | inbox |
| description | Use when checking what PRs are waiting for your review, or when starting your day to see what needs attention |
Show PRs awaiting your review across repositories. Surfaces what needs your attention with context to prioritize.
Announce: "Using git:inbox to check PRs awaiting your review..."
# PRs where you're requested reviewer
gh search prs --review-requested=@me --state=open --json repository,number,title,author,createdAt,url
# PRs where you're assigned
gh search prs --assignee=@me --state=open --json repository,number,title,author,createdAt,url
For each PR, get review state:
gh pr view {number} --repo {owner}/{repo} --json reviews,reviewRequests
Format as actionable list:
## PRs Awaiting Your Review
### {repo} #{number}: {title}
- **Author:** @{author}
- **Age:** {days} days
- **URL:** {full_url}
- **Status:** {review_status}
---
{N} PRs need your attention. Check out a PR for local review?
Important:
Use AskUserQuestion:
Which PR would you like to check out for review?
(A) #{number} - {title}
(B) #{number} - {title}
(C) #{number} - {title}
(D) None right now
If user picks one → invoke git:checkout with the PR.
| Command | Purpose |
|---|---|
gh search prs --review-requested=@me --state=open | PRs requesting your review |
gh pr view {n} --repo {r} --json reviews | Get review status |
git:checkout - Check out a PR for local reviewcode-review - Guide the actual review process (separate skill)