with one click
dotfiles
dotfiles contains 14 collected skills from kergoth, with repository-level occupation coverage and site-owned skill detail pages.
Skills in this repository
Run end-to-end GitHub issue triage using the local triage scripts and parallel subagent scoring. Use when asked to create, refresh, or rerun issue triage markdown with complexity, difficulty, benefit, scope, and execution-lane recommendations (`agent-implementation`, `agent-assist-human`, `human-only`).
Find and resume a past Claude Code, Codex, or Cursor Agent conversation by searching session history files by keyword. Use this skill whenever the user wants to find a previous conversation, can't remember which directory or agent they were using, wants to look up work from a past session, needs to resume a session they can't locate with /resume, codex resume, or agent --resume, or says something like "I know we discussed X somewhere" or "where was that session about Y". Infers search scope, agent, and keywords from the user's description and presents matching sessions with summaries before asking which to resume. Always use this skill rather than manually searching ~/.claude/, ~/.codex/, or ~/.cursor/ yourself.
Use for commit-level Git workflows in non-`.jj/` repositories: stage one logical change, write or revise commit messages, amend, create fixup commits, split bundled edits, curate history with rebase or autosquash, and verify bisectability. In repositories containing `.jj/`, use this skill only for explicit Git-only commit intent; generic commit intent routes to `jujutsu` plus `jj-commits`. Trigger on requests such as "commit this", "check it in", "ship it", "stage and commit", "amend", "fixup", "clean up history", "reword/split commits", or "draft/rewrite the commit message". Also use for indirect commit-message creation when drafting plans that specify commits (including `superpowers:writing-plans` outputs), and when writing commit message text in design docs, PR notes, or other artifacts.
Guidelines for designing and implementing command-line interfaces. Use when creating a new CLI tool, adding subcommands or flags to an existing one, implementing help text, designing error messages, or structuring CLI output. Also use when reviewing CLI code for usability, when the user asks about CLI best practices, or when generating argument parsers, config handling, or shell completions. Applies to any language.
Apply Christopher Larson's preferred Bash and POSIX shell script style when creating or substantially editing user-facing shell scripts. Use when writing or modifying shell utilities under `scripts/` or `script/` (including extensionless shebang executables, pre-commit entry scripts, and CI helpers), `.sh` files, shell snippets intended for the user to keep, or any Bash or POSIX sh program that will become part of the maintained codebase. Do not use for temporary test scripts, disposable intermediate artifacts, or scripts written solely for AI-agent execution.
Use for generic commit-related intent in `.jj/` repositories. Must be paired with `jujutsu` in the same turn; never use it as a standalone skill. Explicit Git-only `.jj` commit intent routes to `git-commits`.
Use when working with version control in a repository that contains `.jj/`, or when the user explicitly mentions Jujutsu or `jj`. When the VCS context is ambiguous, check for `.jj/` in the working tree before defaulting to plain Git. Do not use this skill as the primary route for non-`.jj/` generic Git tasks.
Use when opening pull requests, drafting or revising PR descriptions, addressing PR review feedback, updating an existing PR after a force-push or rebase, handling PR templates, or working with GitHub pull requests, GitLab merge requests, or Bitbucket pull requests. Covers personal defaults for PR description hygiene and reviewer-facing content. Invoke this skill before running `gh pr create`, `glab mr create`, or equivalent, even on terse requests like "open a PR", "send a PR", "ship the PR", "PR it", "push it up for review", or "make an MR" — those phrases all map to the activities above.
Use when creating, filing, writing, or revising issues, epics, initiatives, tasks, stories, enhancements, or bug reports in any tracker — GitHub Issues, Jira, Linear, GitLab, Asana, Shortcut. Covers structural conventions per issue type and self-containment rules for descriptions.
Improve prose quality and reduce AI writing patterns in written artifacts. Use this skill whenever writing, drafting, editing, or reviewing any prose content: emails, design documents, proposals, Confluence pages, Obsidian notes, PR descriptions, commit message bodies, technical blog posts, READMEs, documentation, RFCs, ADRs, or any text where the output should read as human-written. Also use when the user asks to "make this sound human," "clean up the writing," "de-AI this," or "rewrite." Even if the user does not explicitly request writing quality, use this skill whenever the primary output is prose rather than code.
Evaluate whether to adopt an open-source project, GitHub repository, or nested artifact such as a skill or plugin. Use when the user wants project due diligence, adoption analysis, trust or stewardship review, maintainer health checks, release-cadence review, bus-factor analysis, community responsiveness review, or security and exfiltration risk assessment. Prefer this skill whenever the user is considering whether to trust or adopt an open-source project, even if they only mention a subpath, file, plugin, or skill inside a larger repository.
CLI syntax for dispatching prompts to external model agents (claude, cursor, codex, gemini). Use when spawning a second-opinion review, running prompts through alternate models, or scripting multi-model workflows.
Guide for writing, reading, and debugging cram functional tests (.t files). Use this when working with cram test files, creating new .t tests, debugging test failures, understanding cram output diffs, or when you encounter exit code 80 or .err files from test runs. Also use when the user mentions cram, .t files, or transcript-style shell tests.
Use when running the `obsidian` CLI command, interacting with an Obsidian vault from the terminal, creating/appending/reading notes programmatically, searching vault content, managing daily notes, querying tags or backlinks, or automating any Obsidian vault operations. Requires Obsidian 1.12+, app running, CLI enabled in Settings → General → CLI.