Git i control de versions
Operacions de Git, assistència per a commits i gestió de branques
gh-review-requests
getsentry
Fetch unread GitHub notifications for open PRs where review is requested from a specified team or opened by a team member. Use when asked to "find PRs I need to review", "show my review requests", "what needs my review", "fetch GitHub review requests", or "check team review queue".
iterate-pr
getsentry
Iterate on a PR until CI passes. Use when you need to fix CI failures, address review feedback, or continuously push fixes until all checks are green. Automates the feedback-fix-push-wait cycle.
developing-claude-code-plugins
obra
Use when working on Claude Code plugins (creating, modifying, testing, releasing, or maintaining) - provides streamlined workflows, patterns, and examples for the complete plugin lifecycle
tinkering
rfxlamia
Safe experimentation framework for AI agents. Creates isolated sandbox environments for trying new features, testing approaches, and exploring solutions without polluting the main codebase. USE WHEN: Agent needs to try something uncertain, explore multiple approaches, test a new library, prototype a feature, or run a technical spike before committing to implementation. PRIMARY TRIGGERS: "experiment with" = Setup sandbox + run experiment "try this approach" = Quick experiment in sandbox "spike" / "POC" / "prototype" = Time-boxed technical investigation "tinker" / "tinkering mode" = Enter experimentation workflow "explore options" = Multi-approach comparison in sandbox NOT FOR: Debugging (use debugger), testing (use test runner), or committed feature work (use git branches). DIFFERENTIATOR: Unlike git branches (for committed direction), tinkering is for "I don't know if this will work" exploration. Try 5 things in sandbox before committing to a branch. Faster feedback, zero codebase pollution.
babysit-pr
BuilderIO
Monitor a PR, fix feedback and CI failures until fully green for 30 min. Run with /babysit-pr <number>
ship-now
BuilderIO
Fast-path the current branch through local pnpm prep:urgent, targeted recovery, feedback resolution, whole-branch push, immediate admin merge, and fresh-branch rotation. Use when the user explicitly wants to merge immediately after local prep recovery, then monitor beta, docs production, and release workflows. GitHub Actions auto-deploys beta and the docs site through the prebuilt publisher; other production promotion is manual.
ship-and-monitor
BuilderIO
Run the normal guarded ship flow, then monitor beta deployments, the docs production lane, release tails, and any explicitly requested manual production promotion. Use when standard /ship needs post-merge verification.
self-modifying-code
BuilderIO
Tiers, checkpoints, and off-limits paths for an agent editing the app's own source. Use when designing UI for agent editability, deciding whether a file is safe for the agent to change, or when tempted to patch config, .env, or an @agent-native/* package. Do not load it for ordinary source edits.
roasbeef-prose
Roasbeef
Writing style guide for Roasbeef's technical prose. This skill should be used when writing PR descriptions, commit messages, technical documentation, blog posts, or any written content that should match Roasbeef's established voice. Activate when creating PRs, drafting commit messages, writing release notes, or composing technical explanations.
commit
ccusage
Creates atomic Conventional Commits. Use when committing code changes, splitting a diff into independently revertable hunks, staging precise patches non-interactively, or writing commit messages.
create-pr
ccusage
Runs the full PR lifecycle. Use when creating a branch, committing, pushing, opening a PR, requesting AI review, replying to review threads, and driving CI to green.
fix-ci
ccusage
Diagnoses and fixes failing GitHub Actions checks with gh. Use when CI fails on a pull request and needs logs, focused fixes, and validation.
running-in-ci
max-sixty
CI environment rules for GitHub Actions workflows. Use when operating in CI — covers security, CI monitoring, and comment formatting.
release
max-sixty
Worktrunk release workflow. Use when user asks to "do a release", "release a new version", "cut a release", or wants to publish a new version to crates.io and GitHub.
github-pr-fix
holon-run
"Fix pull requests based on review feedback and CI failures. Use when: (1) Addressing PR review comments, (2) Fixing CI/test failures, (3) Resolving merge conflicts, (4) Implementing requested changes."
issue-triage
max-sixty
Triages new GitHub issues — classifies, reproduces bugs, attempts conservative fixes, and comments. Use when a new issue is opened and needs automated triage.
writing-user-outputs
max-sixty
CLI output formatting standards for worktrunk. Use when writing user-facing messages, error handling, progress output, hints, warnings, or working with the output system.
dependabot-pr-automation
chainloop-dev
Reviews open Dependabot pull requests, assesses their risk level based on version bump type and CI status, approves low-risk PRs, and merges them. Use when asked to process, review, merge, or triage Dependabot PRs.
worktrunk
max-sixty
Guidance for Worktrunk, a CLI tool for managing git worktrees. Covers configuration (user config at ~/.config/worktrunk/config.toml and project hooks at .config/wt.toml), usage, and troubleshooting. Use for "setting up commit message generation", "configuring hooks", "automating tasks", or general worktrunk questions.
cco-git
egorfedorov
Show git-aware context suggestions for current working directory
golang-continuous-integration
samber
"GitHub Actions CI/CD pipeline configuration for Golang projects — workflow files for test, lint, SAST, coverage and vulnerability-scan jobs, Dependabot and Renovate config files, GoReleaser release pipelines, Docker build/push, repository security settings, and AI-driven PR review. Use when setting up or improving Go project CI, writing or fixing .github/workflows/*.yml, adding a linter or security scanner as a pipeline job, wiring automated dependency-update bots, or adding quality gates. Covers wiring tools into a pipeline, not the analysis they perform: do NOT use for choosing or interpreting security findings (→ See samber/cc-skills-golang@golang-security skill) or for choosing, upgrading, or auditing dependency versions (→ See samber/cc-skills-golang@golang-dependency-management skill)."
golang-dependency-management
samber
"Dependency management for Golang projects — go.mod and go.sum, go get install and upgrade flows, Minimal Version Selection, conflict resolution with replace/exclude/retract, govulncheck scanning of the module tree, outdated dependency and binary size auditing, vendoring, tool directives, and go.work workspaces. Use when adding, removing, or upgrading Go dependencies, deciding whether to take on a package, resolving version conflicts, or auditing what a module pulls in. Covers choosing and upgrading dependency versions, not the surrounding tooling: do NOT use for fixing an exploitable vulnerability in code (→ See samber/cc-skills-golang@golang-security skill) or for wiring Dependabot/Renovate update bots into CI workflows (→ See samber/cc-skills-golang@golang-continuous-integration skill)."
golang-refactoring
samber
"Golang refactoring — safe, at-scale restructuring of existing Go code: a coverage-adaptive safety net, behavior-preserving transforms (gopls Rename/Extract, gofmt -r, gopatch), the Fowler catalog mapped to Go, breaking import cycles, and small stacked PRs. Apply when a function or type has grown too large, a code smell blocks a feature, or the user asks to refactor Go code — also for renaming at scale, extracting functions or interfaces, moving code between packages, or planning a multi-step refactor. Target styles owned elsewhere → See samber/cc-skills-golang@golang-naming (renames), samber/cc-skills-golang@golang-project-layout (splits), samber/cc-skills-golang@golang-modernize (idioms), samber/cc-skills-golang@golang-code-style (control flow), samber/cc-skills-golang@golang-design-patterns (patterns/DI)."
commit-archaeologist
Shubhamsaboo
Reconstructs why code exists from local git history, including the introducing commit, later changes, current authors, repeated companion files, and likely intent. Use when the user asks "why does this code exist", "who wrote this function and why", or to "explain the history of this function" before a rewrite, refactor, or risky edit. Runs entirely locally.