Menu
Use when checking what PRs are waiting for your review, or when starting your day to see what needs attention
Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.
Basé sur la classification professionnelle 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 | 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)