dotfiles
dotfiles contiene 11 skills recopiladas de Gelio, con cobertura ocupacional por repositorio y páginas de detalle dentro del sitio.
Skills en este repositorio
Use when creating git commits in any project. Covers mandatory commit body, Markdown formatting, staging discipline, the Write-tool + git-commit-F pattern for reliable commits, and post-commit verification. This skill should be used whenever Claude is about to create a git commit, even if another commit-related skill or plugin is also active — this one provides the universal authoring rules. Triggers on: "commit", "git commit", "create a commit", "stage and commit", "fixup", "amend", "absorb", "autosquash", "reword".
Verify that every commit on the current branch passes all project checks independently. Use after rebasing, before creating a PR, or when picking up a branch. Triggers on: "verify commits", "verify branch", "check each commit", "per-commit verification", "/verify-branch-commits".
Creates comprehensive handoff documents for seamless AI agent session transfers. Triggered when: (1) user requests handoff/memory/context save, (2) context window approaches capacity, (3) major task milestone completed, (4) work session ending, (5) user says 'save state', 'create handoff', 'I need to pause', 'context is getting full', (6) resuming work with 'load handoff', 'resume from', 'continue where we left off'. Proactively suggests handoffs after substantial work (multiple file edits, complex debugging, architecture decisions). Solves long-running agent context exhaustion by enabling fresh agents to continue with zero ambiguity.
Plan and lead a human through reviewing a local git diff for maximum comprehension — scope and triage the change, pick the right diff range, and order the walk so each file is legible when reached. Use before opening or reviewing a PR, when reviewing another engineer's branch checked out locally, or any time the user wants to understand a diff rather than have it auto-reviewed for bugs. Triggers on: "walk me through this diff", "help me review this branch", "review this diff", "understand these changes", "how should I review this", "/diff-walkthrough". Complements /code-review (which hunts bugs) and verify-branch-commits (which checks per-commit correctness) — this one optimizes a human's understanding.
Write and reply to GitHub PR review comments matching the user's preferred style — SHA-pinned permalinks for code, linked ticket IDs, in-thread replies. Use this whenever drafting or replying to a PR review comment (inline or review-body), leaving a comment on a PR or issue, responding to review feedback, or working a pending/draft review — even if the user doesn't say "skill". Triggers on "PR comment", "review comment", "reply to review", "reply to this comment", "leave a comment on the PR", "draft review", "pending review", "respond to the reviewer". Layers on top of `jira-preferences` (permalink + SHA-selection mechanics), `pr-conventions` (PR descriptions), and `commit-conventions` (commit messages).
Write PR descriptions matching the user's preferred style. Use when creating a pull request, drafting a PR description, drafting a PR body, opening a PR, or when the user says "write a PR description", "draft PR", "open PR", "create PR", "/pr-conventions". Layers on top of any project-level PR skills (e.g., edb-git-conventions:pr).
Route the rationale behind a branch's design decisions to where a reviewer will actually see it, with a bias toward durable homes (in-code comment, README, PR description) and an inline PR comment only for the ephemeral, line-specific residue. Use when finishing a feature branch or opening/updating a PR that made non-obvious choices, when a decisions ledger / agent-plan with Q-decisions exists, or when the user says "surface the decisions", "document the rationale", "where should this rationale live", "route decision rationale", "/route-decision-rationale". Pairs with `pr-conventions` when drafting a PR description — invoke it whenever load-bearing reasoning is at risk of living only in commit bodies, which reviewers never read.
Annotate a TODO/review-feedback file with context from the current conversation to help the next agent implement the items. Use when the user says "add context to TODOs", "enrich TODOs", "annotate TODOs for the next agent", "add implementation hints", or asks you to look at a todos/impl-todos file and add what you know. Also triggers when the user asks to prepare handoff notes for remaining work after completing an implementation session.
User preferences for working with Jira via the Atlassian MCP. Use whenever interacting with Jira tickets — creating, editing, reading, searching, linking, commenting on, or transitioning issues, adding worklogs, or running JQL. Applies to all Jira operations regardless of project. Triggers on any use of mcp__atlassian__ tools, references to ticket keys (e.g. MIG-1234, PROJ-567), or when the user mentions Jira tickets, issues, epics, sprints, or comments.
Work through a todos.md task list with subagent delegation, TODO tracking, and commit strategy. Use when the user says "work on todos", "pick up todos", "/todos <path>", "work through the remaining tasks", or references a todos.md file they want worked through. Also use when a user says "pick up where you left off" and a todos.md exists in the working directory. Triggers on any mention of working through a checklist file or task list file.
Use when the user asks to update, upgrade, build, or install Neovim from source