rdlugs

git-fix-issue

Fetch a GitHub issue/PR or GitLab issue/MR, understand what needs fixing or building, draft an implementation plan, implement it on the current branch, then offer to open a PR/MR. Use this whenever the user references an issue, bug, ticket, feature request, PR, or MR (by number, URL, or "the issue linked to this PR") and wants it implemented or fixed — e.g. "fix issue

git-issue

Draft a clean, well-structured issue as markdown text for a code-hosting tracker (GitHub, GitLab, Jira, or similar). Use this whenever the user wants to file, write, open, or draft an issue, bug report, feature request, ticket, or task — including phrasings like "make an issue for this", "write up a bug report", "turn this into a ticket", "I need to file something for the flaky test", or when they paste an error/stack trace/PR discussion and ask for it to become an issue. Also use it when they hand you loose notes, a Slack thread, or a chat log and want a properly formatted issue out of it. Produces markdown ready to paste into the tracker's issue field, and after drafting asks whether to actually post/create the issue — posting it directly if a GitHub/GitLab connector or authenticated CLI is available, otherwise handing over a ready-to-run command.

local-code-review

Review uncommitted local code changes (working directory + staged) in a git repo, hunting for bugs, security issues, missing test coverage, and blast radius — everything downstream the change could break — then report findings grouped by severity and lay out an ordered plan to fix them. Use this skill whenever the user asks to review their changes, check their diff, look over what they wrote before committing, sanity-check a patch, trace what a change might affect, or says anything like "review my code", "can you look at this before I push", "did I break anything", "what does this touch", or "check my changes" — even if they don't say the words "code review". Also use it when the user is about to commit, open a PR, or asks whether their work-in-progress looks correct.

mr-fix

Fetch unresolved code review comments from a GitLab MR or GitHub PR, plan the fixes, implement them after approval, verify, self-review the diff in a bounded fix loop, and commit. Use this skill whenever the user mentions fixing, addressing, resolving, or implementing MR comments, PR comments, review findings, review feedback, reviewer suggestions, or code review results — and whenever they type /mr-fix, /mr-fix 298, or /mr-fix MR 298. Also use it when the user pastes review comments and asks to act on them, or says things like "address the review on 298", "fix what the reviewer flagged", or "handle the MR feedback".

mr-review

Use this skill whenever the user wants to perform a code review on a GitLab Merge Request (MR). Triggers include: any mention of "code review", "review MR", "review merge request", "review MR ID", "check MR", "review this MR", or when the user provides an MR ID (e.g. "MR 42", "!42") with or without an associated issue ID. This skill handles the full review lifecycle: reading prior review comments, fetching related issue context, performing a structured code review with impact analysis, and posting the result as a GitLab MR comment. Always use this skill when a GitLab MR review is involved — even if the user says "just a quick review" or only provides an MR ID.

grilling

Interview the user relentlessly about a plan or design. Use when the user wants to stress-test a plan before building, or uses any 'grill' trigger phrases.