dotfiles

Coach the user through implementing, debugging, or learning a task themselves so they build a working mental model. Use when the user explicitly wants to remain the actor and learn while doing: "guide me", "teach me", "help me learn", "I want to understand how to do this", "don't do it for me", "let me figure it out", or similar. Also use when they want to diagnose a problem themselves rather than receive a fix. Don't use for direct implementation, one-shot explanations, document creation, or general Q&A. If "show me how" or "walk me through" could mean coaching or a direct answer, ask which path they want before using this skill.

Drafts, rewrites, and reviews prose in Petar's personal voice while removing generic AI writing patterns. Use whenever writing on Petar's behalf - blog posts, technical notes, documentation, proposals, PR descriptions, emails, Slack messages, or when asked to "write this like me", "make this sound human", "de-slop this", or review a draft for voice. Do not use for code or routine assistant status updates.

Pauses to ask focused clarifying questions when a request lacks enough information to execute correctly. Use when the task is vague, has multiple plausible interpretations, is missing acceptance criteria, or when wrong assumptions would produce significant wasted work. Don't use when the request is already well-specified, when requirements were clarified earlier in the same conversation, when the task is trivially unambiguous (e.g., fix a specific typo), or when general clarification techniques are being discussed rather than applied to a specific task.

Refines existing code for clarity, readability, and maintainability without changing behavior, interfaces, or outputs. Use when asked to "simplify", "clean up", "refactor for readability", "reduce complexity", or polish code without adding features. Don't use when the request involves changing behavior, adding functionality, migrating to a new pattern or library, renaming public APIs, or any structural change that alters interfaces or outputs.

Fetches and displays source code from GitHub file and directory URLs using the gh CLI. Use when the user shares a github.com/owner/repo/blob/... or github.com/owner/repo/tree/... URL, a raw.githubusercontent.com URL, a GitHub Enterprise URL (e.g. github.mycompany.com/...), or explicitly asks to read, fetch, or show the contents of a file or directory on GitHub. Supports file contents, single-line anchors (#L10), line ranges (#L10-L25), directory listings, and shallow repository clones. Don't use for GitHub pull request URLs (/pull/), issue URLs (/issues/), commit URLs (/commit/), release URLs (/releases/), GitHub Actions workflow URLs (/actions/), Gist URLs (gist.github.com), or GitHub wiki URLs (/wiki/). Don't use when the user only wants to discuss, mention, or link to a GitHub project without requesting its file contents.

Conducts exhaustive requirements-gathering interviews for software features or systems. Reads existing context, then asks structured numbered questions covering purpose, technical design, UI/UX, edge cases, security, and rollout. Use when the user says "interview me", "deep dive on requirements", "spec this out", "fill out the spec", "help me think through this feature", or when a feature needs thorough requirements elicited before a spec or plan can be written. Don't use for quick clarifying questions during an in-progress task (use ask-questions-if-underspecified instead), for writing or updating a SPEC.md document (use create-spec instead), for generating a task plan (use create-plan instead), or for general architectural discussions that don't need structured requirements output.

Writes and rewrites technical documentation for software projects: README files, API references, architecture docs, user guides, and inline doc comments. Use when the user wants to create, improve, or restructure documentation for a codebase, library, CLI tool, or API. Also use when the user wants to audit existing docs for accuracy, clarity, or completeness. Don't use for commit messages, PR descriptions, changelogs, blog posts, marketing copy, or ad-hoc code comments that aren't part of a documentation system.

Upgrades Elixir Mix/Hex dependencies safely, covering patch/minor bumps, major-version migrations with changelog research, and post-update verification. Use when the user asks to update deps, bump packages, upgrade a specific Hex package, or run mix hex.outdated. Don't use for: adding a new dependency, removing a dependency, resolving a dependency conflict or lockfile error without upgrading, or updating npm/pip/cargo/other non-Elixir package managers.

Draft or update clear, reviewer-centered pull request descriptions. Use when the user asks for a PR description/body, GitHub PR body, PR summary, context-first PR narrative, to update an existing PR description, or to turn commits/diffs into a consistent PR narrative. Do not use for commit messages unless the user is explicitly writing a PR description.

Keep DEVLOG.md up to date and use it to resume project context in the user's personal developer-log style. Use when the user asks to update, write, continue, summarize, resume, catch up from, or maintain @DEVLOG.md / DEVLOG.md after or before a work session, or asks to capture what they did, learned, decided, got stuck on, where to continue next, or what happened last time.

Analyzes all uncommitted changes (staged and unstaged), groups them into atomic commits by logical purpose, and generates clear conventional commit messages with practical, context-rich bodies. Use when the user asks to "smart commit", "group my commits", "split into atomic commits", "organize my changes into commits", or when there are many uncommitted changes across multiple files that should be separated into well-scoped commits. Don't use for a single, simple commit message request, for push/pull operations, for rebasing or squashing existing commits, or when the user just says "commit this" without asking for grouping or splitting.

Use ast-grep for syntax-aware structural code search, analysis, linting, and safe rewrite planning. Load this when a task asks to find code by shape/AST, refactor repeated code patterns, inspect function/component/import usage structurally, write ast-grep rules, or when ripgrep would be too imprecise.