菜单
Use when running git push or diagnosing why a push failed. Especially when output mixes SSH transport with hook output (lefthook, husky, pre-commit), errors include "Permission denied (publickey)" or "rejected/non-fast-forward", a pre-push hook fails, or about to debug SSH with `-v`.
用 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 | push |
| description | Use when running git push or diagnosing why a push failed. Especially when output mixes SSH transport with hook output (lefthook, husky, pre-commit), errors include "Permission denied (publickey)" or "rejected/non-fast-forward", a pre-push hook fails, or about to debug SSH with `-v`. |
Preferences for git push, especially diagnosing failures.
When git push exits non-zero, output mixes three layers:
Identify the failed layer before debugging:
lefthook or hook: pre-push → pre-push hook failed; transport was finePermission denied (publickey) → SSH auth refused! [rejected] / non-fast-forward → push needs rebaseA wall of test or coverage output is NOT an SSH problem. The hook ran tests, the tests failed, the push was blocked.
Same rules as pre-commit failures in the commit skill: analyze the failures, autofix when possible, ask the user when unclear. Do NOT skip with --no-verify without explicit confirmation.
Before adding -v to debug an SSH issue, check whether core.sshCommand is configured:
git config --get core.sshCommand
If it returns nothing, GIT_SSH_COMMAND="ssh -v" git push origin <branch> is fine.
If it returns anything (custom IdentityFile, IdentityAgent, deploy-key flags, etc.), DO NOT use GIT_SSH_COMMAND="ssh -v". It REPLACES core.sshCommand entirely, dropping every flag. Output will look like the wrong keys are being offered, because they are, but only because you removed the constraint.
Append -v to the existing command instead:
GIT_SSH_COMMAND="$(git config core.sshCommand) -v" git push origin <branch>
If you started a push with run_in_background and then ran a foreground retry (e.g., because the first looked stuck), the background push may have already succeeded. Before re-investigating "why is push failing":
git -C <worktree> log --oneline origin/<branch>..HEAD. Empty output means the push went through.pwd and git rev-parse --show-toplevel.gh pr view <pr> to see if the commit landed.Don't escalate to "SSH might be broken" before confirming the push didn't already complete.