Menu
Use when committing changes to git - provides best practices for staging, commit messages, signing, and handling hook failures
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 | commit |
| description | Use when committing changes to git - provides best practices for staging, commit messages, signing, and handling hook failures |
Preferences and best practices for interacting with a git repository.
ALWAYS use git add with specific files that have been updated. NEVER use git add . or git add -A.
IF adding files that look like they are agent configuration, or adding planning documentation, ALWAYS prompt the user to confirm if they should be included or not.
PREFER writing out a commit message to the scratch/ directory, and save it to a name reflecting what is being commited. Then use use git commit -t scratch/path-to-message.txt
We have git commit signing setup. If it fails due to a message like:
error: 1Password: failed to fill whole buffer
fatal: failed to write commit object
... it is because the user was being prompted to authorize signing, and didn't see it or missed it. Do not try to fix or bypass it. Stop and prompt the user about either fixing it, or confirm bypassing it.
When git precommit checks fail, analyze what the failures are, and try to autofix when possible, otherwise think through how to fix it. Ask the user how to proceed when it's unclear if how to fix.
DO NOT follow sorbet's autocorrection advice. DO NOT skip verification without confirmation from the user.
If we see errors like:
git: 'duet-prepare-commit-msg' is not a git command. See 'git --help'.
it is because we previously were using git-duet. It uses a git template, with hooks that call git duet-prepare-commit-msg. We've sinced moved, but the files will still be present
In this case, check .git/hooks/ for references to these. Remove files that call it.