technicalpickles
UserPersonal collection of Claude Code skills for development workflows
Categories
Indexed Skills (39)
route
Analyze an enriched note and route to the best vault destination. Stage 3 of the processing pipeline.
process-inbox
Process accumulated inbox notes through the full pipeline (ingest, enrich, route, connect, link). User-facing orchestrator.
ingest
Turn a raw session notes file into an ingested note, ready for the enrich stage. Defaults to keeping it whole; only splits when bullets show a real cross-topic signal. Stage 1 of the processing pipeline.
devlog
Use when finishing a feature, fixing a notable bug, wrapping up a work session, or discovering something non-obvious (a gotcha, undocumented behavior, a workaround that took several tries, a constraint you only noticed after hitting it). Write the entry immediately, in the same turn - don't ask permission, don't offer, just do it. Do NOT use for routing, connecting, or moving notes (that's process-inbox), and do NOT use for one-off external-source capture (that's second-brain:capture).
triage
Use when reviewing git state across worktrees, stashes, and branches - helps decide what to clean up, resume, or address
capture
Use when the user asks to read a source and make a note for it, create or find an atomic note, or check whether a note already exists. Triggers on "read <url> and make a note", "make a note for", "create (or find) an atomic note", "do we have notes about X?", "check if we have a note for", "capture this", "put together a note", "distill this", and on a bare URL/PDF/tweet/thread handed over with intent to write it up. Covers the whole loop as one arc - search the vault first, read the primary source, write the note through the sb CLI, then offer connections. Use inside an Obsidian vault or anywhere a vault is configured. Do NOT use for draining an accumulated inbox backlog (that is process-inbox), for extracting insights from the current conversation (that is devlog), or for routing already-captured notes to their homes (that is route).
setup
Scaffolds principle-anchoring configuration for a project. Writes docs/agents/principles.md, adds a `### Principles` block to `## Agent skills` in CLAUDE.md or AGENTS.md, and optionally drafts hook integration snippets for settings.json or tool-routing. Run once per project before using stay-principled:grill. Re-run only if the principles file layout changes.
park
Save current work context for later resumption
connect
Find related notes via semantic search and weave links. Stage 4 of the processing pipeline.
distill-rules
Review routing corrections and propose updates to vault CLAUDE.md routing rules.
enrich
Turn an ingested insight into a proper zettelkasten note with clean prose. Stage 2 of the processing pipeline.
link-daily
Link a processed note to today's daily note. Stage 5 of the processing pipeline.
inbox
Use when checking what PRs are waiting for your review, or when starting your day to see what needs attention
actually-lsp-doctor
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.
developing-pipelines
Use when creating, modifying, or debugging Buildkite pipeline YAML files - ensures current syntax from official docs, validates configurations before proposing changes, and references Buildkite best practices instead of relying on training data
colima
Use when Docker commands fail with "Cannot connect to Docker daemon", when starting/stopping container environments on macOS, when managing Docker contexts or profiles, or when running incus (system containers / VMs with nested virtualization) on macOS - provides Colima lifecycle management, profile handling, SSH commands, and troubleshooting
designing-clis
Use when building, improving, or reviewing command-line interfaces for better user experience - before implementing commands/output/errors, when users report confusion or frustration, or when CLI feels hard to use - provides UX principles, visual design techniques, and practical patterns for creating discoverable, delightful CLIs
api-documentation-discovery
Use when APIs fail repeatedly with version-related errors (method not found, wrong arguments, unknown flag) or when about to use library APIs with uncertain knowledge - guides finding current, accurate documentation instead of guessing from training data
hk
Use when hk.pkl exists in project, hook output shows hk running, or working with git hooks in hk-managed projects. Also use when setting up, configuring, or troubleshooting hk git hooks.
working-in-scratch-areas
Use when creating one-off scripts, debug tools, analysis reports, or temporary documentation - ensures work is saved to persistent .scratch areas with proper documentation, organization, and executable patterns
working-with-mise
Use when adding, configuring, or troubleshooting mise-managed tools - ensures proper CLI usage, detects existing config files, and diagnoses PATH/activation issues when commands aren't found
scope
Guide for working with Scope, a developer environment management tool that automates environment checks, detects known errors, and provides automated fixes. Use when creating Scope configurations (ScopeKnownError, ScopeDoctorGroup, ScopeReportLocation), debugging environment issues, or writing rules for error detection and remediation.
checkout
Use when checking out a PR, branch, or ref for local work - sets up worktree with context
push
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`.
gut-check
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.
working-with-mcp
Use when user mentions MCPProxy/MCP tools (e.g., "check buildkite mcp", "use slack mcp") or when you need to discover or call tools through MCPProxy - immediately checks if mcp__MCPProxy__* tools are available, suggests /mcp reconnect if missing (MCPProxy MCP server not connected), explains when to use MCP tools vs HTTP API for debugging
obsidian
Obsidian vault mechanics - wiki links, .obsidian/ config, daily notes, plugins. Use when working with Obsidian vaults or structured markdown.
working-in-monorepos
Use when working in repositories with multiple subprojects (monorepos) where commands need to run from specific directories - prevents directory confusion, redundant cd commands, and ensures commands execute from correct locations
vault-capture
Use when Josh asks to write a note, make a note, or capture something for his "pickled-knowledge" Obsidian vault - triggers on "write a note about X", "make a note for this", "capture this", "note this up", "put together a note on X", or a bare URL/article/tweet handed over with intent to write it up. Do NOT use for generic writing help, drafting prose that isn't a vault note, or when Josh is just asking a question and not asking for a note.
update
Use when a branch or PR has merge conflicts, is behind main, or needs upstream changes pulled in. Triggers on "resolve the merge conflicts", "there's a merge conflict on the PR, fix it", "rebase this PR on main", "catch this branch up with main", "update my branch". Fetches, merges the base branch (merge, not rebase), and resolves conflicts by reading the intent of both sides. Do NOT use for fast-forwarding a local main after a merge (just git pull).
commit
Use when committing changes to git - provides best practices for staging, commit messages, signing, and handling hook failures
pull-feedback
Use when the user has authored a GitHub pull request and wants to work through review feedback on it. Triggers on phrases like "pull down the review on #N", "address the feedback", "what did @reviewer say on my PR", "let's work through the comments", or any request to triage, respond to, or systematically handle review threads on the user's own PR. Do NOT use for reviewing someone else's PR, authoring PR content or replies, or checking which PRs are waiting on the user for review.
taskwarrior
Use when querying or modifying tasks via the taskwarrior CLI - dense recipes for listing, single-field lookups, multi-task batched lookups, full-text search, and the soft description-length convention. Activates on `task list`, `task add`, `task info`, `task done`, "what's on the backlog", "find a task", or any taskwarrior interaction.
tailscale-cli
Use when running `tailscale` commands to debug connectivity, inspect status, or manage `tailscale serve`/`funnel`/Services — especially when `tailscale serve status` looks wrong, `tailscale` isn't found in a shell, `tailscale ping` fails against a host that's clearly up, you're working across a mix of macOS (GUI app) and Linux (VM/container) nodes in the same tailnet, or a node/sidecar joins fine but something downstream (a grant, an app-level check) crash-loops or silently fails — that's often an ACL/tagOwners issue, not a code bug. Also use for authoring or reading tailnet ACLs (tagOwners, grants, the legacy `acls` array) or querying the live policy via the Tailscale API.
tailscale-serve-patterns
Use when deciding how to expose a locally-running server over a tailnet (loopback bind + `tailscale serve` vs. binding directly to the tailnet interface), when a service is reachable at its Tailscale address but a request seems to bypass expected auth, when working with Tailscale identity headers (`Tailscale-User-Login` and friends) for browser auth, or when a "bind is loopback-only" security check doesn't seem to reflect what's actually reachable (Docker port publish, reverse proxy, container networking). Also use this BEFORE handing the user a `localhost`/`127.0.0.1` URL or a bare port number for anything you just started serving (a quick script, a dev server, a one-off demo, a review page) if there's any chance they'll open it from another device (phone, tablet, another machine) -- check whether Tailscale is available and give them a tailnet URL that actually works from there instead of a URL that only works on the machine you're running on.
grill
Walk a depth-first decision tree anchored to a project's documented principles before brainstorming opens options. Reads docs/agents/principles.md (or probes docs/principles.md and docs/ops-principles.md directly), shortlists principles relevant to the topic, asks one question at a time with a recommended answer per question, surfaces conflicts emergently, and outputs a brief that downstream brainstorming or planning can consume. Use when starting design work and the project has principles documented; redirects to stay-principled:setup otherwise. Auto-routes from phrases like "grill me with principles", "anchor this to the principles", "what principles bear on this", "stay principled on this".
unpark
Resume work from a parked handoff
actually-lsp-ignore
Ignore actually-lsp nudges for an ecosystem in this project. Use when the user wants to silence, dismiss, or ignore the LSP setup nudges for a specific ecosystem (Rust, TypeScript, Ruby), or invokes `/actually-lsp-ignore` directly. Writes `dismissed=true` to `.claude/actually-lsp.json`. Persistent across sessions for this project only.
snapshot
Capture current session state without stopping
Bio shown is the top-scored skill's repo description as a fallback — real GitHub bios land in a future update.