Ejecuta cualquier Skill en Manus
con un clic

Ejecuta cualquier Skill en Manus con un clic

gh-pr

Estrellas245

Forks7

Actualizado13 de junio de 2026 a las 05:23

This skill should be used when creating a GitHub pull request via `gh pr create`. Defines PR body format with Why/What/Notes sections and ensures proper assignment.

Instalación

Instalar con Codex o Claude Copia este prompt, pégalo en Codex, Claude u otro asistente, y deja que revise la página de la skill y la instale por ti.

Ejecutar en Manus

Fuente

fredrikaverpil

fredrikaverpil/dotfiles

Abrir repositorio de GitHub Ver repositorios del creador

Descarga

Ejecutar en Manus

Ocupaciones relacionadasSOC

Basado en la clasificación ocupacional SOC

Desarrolladores de softwareOcupaciones informáticas y matemáticas·SOC 15-1252

SKILL.md

readonly

name	gh-pr
description	This skill should be used when creating a GitHub pull request via `gh pr create`. Defines PR body format with Why/What/Notes sections and ensures proper assignment.

GitHub Pull Request Creation

When creating a pull request, use the gh CLI with the following format and conventions.

Always create draft PRs.
Keep PR titles, descriptions, and comments concise and clear.
Include only useful information. Remove redundancy and over-explanation.
Prefer explicitness and clarity over verbosity.
Express Why/What/Notes content as concise, to-the-point bullet lists. Avoid prose paragraphs.
Include a small, illustrative code snippet whenever it conveys the change faster than prose. This is desired for PRs in general, and especially for bug fixes: a minimal example of the triggering case (and what went wrong) makes the problem concrete for reviewers. Keep it short — just enough to convey the point, not a full reproduction.

PR title format

Write the title as if the whole PR was squashed into a single commit using conventional commits.

PR Body Format

## Why?

[Explain the motivation for this change. What problem does it solve?]

## What?

[Describe what was changed. List the key modifications.]

## Notes

[Optional. Additional context, testing notes, or follow-up items.]

Command Template

gh pr create --draft --assignee @me --title "<title>" --body "$(cat <<'EOF'
## Why?

<motivation>

## What?

<changes>

## Notes

<optional notes>
EOF
)"

File References

Use [file:lineno](url) with SHA-pinned URLs: https://github.com/<owner>/<repo>/blob/<sha>/<path>#L<lineno>

SHA: git rev-parse HEAD
Repo: gh repo view --json nameWithOwner -q .nameWithOwner

Rules

Always assign PR to @me using --assignee @me
## Why? - Required. Explain motivation and problem being solved
## What? - Required. Describe the changes made
## Notes - Optional. Omit entirely if no notes are needed
Use imperative mood in title (e.g., "Add feature" not "Added feature")
Keep title concise and descriptive
When referencing files, always use [file:lineno](url) format with SHA-pinned URLs

Example

gh pr create --draft --assignee @me --title "Add user authentication" --body "$(cat <<'EOF'
## Why?

Users need secure access to their accounts. Currently there is no
authentication mechanism in place.

## What?

- Add login/logout endpoints
- Implement JWT token generation
- Add password hashing with bcrypt
- Create auth middleware for protected routes

## Notes

Requires `JWT_SECRET` env variable to be set in production.
EOF
)"

Más de este repositorio

mismo repositorio

nvim-config

fredrikaverpil/dotfiles

Native Neovim config idioms and conventions — use whenever writing, reviewing, or modifying any Neovim configuration that uses Neovim's built-in conventions WITHOUT a plugin manager framework (no lazy.nvim, packer, etc.). Covers directory structure, vim.pack plugin management, lsp/ auto-discovery, plugin/ loading order, keymaps, and standard paths. Trigger on any task involving init.lua, plugin/*.lua, lsp/*.lua, vim.pack.add(), vim.lsp.enable(), or "native neovim config" — even if the user just says "add a plugin" or "configure LSP" in a native-style config.

2026-06-20245

gh-pr

fredrikaverpil/dotfiles

This skill should be used when creating a GitHub pull request via `gh pr create`. Defines PR body format with Why/What/Notes sections, ensures proper assignment, and prompts for Jira ticket number.

2026-06-13245

obsidian

fredrikaverpil/dotfiles

Find, navigate, read, and edit notes in the user's personal Obsidian vault (an iCloud-synced markdown collection on macOS). Use whenever the user mentions "the vault", "my notes", "Obsidian", a daily note, a meeting note, scratchpad, or asks to look up/jot down something that sounds personal-knowledge-base-like (e.g. "what did I write about X", "add a note about Y", "today's daily note") — even if they don't say the word "Obsidian".

2026-05-08245

obsidian

fredrikaverpil/dotfiles

2026-05-08245

codebase-audit

fredrikaverpil/dotfiles

Analyze a git repo's history to surface high-churn files, ownership risks, bug hotspots, momentum trends, and firefighting patterns. Use this skill whenever the user wants to understand a codebase, assess repo health, or orient themselves before reading code — even if they don't explicitly say "audit".

2026-04-13245

nvim-plugin

fredrikaverpil/dotfiles

Guide for writing Neovim plugins in Lua following official Neovim conventions (https://neovim.io/doc/user/lua-plugin/). Use this skill whenever the user is creating, modifying, or reviewing a Neovim plugin — including when they mention plugin structure, ftplugin, health checks, keymaps, setup() functions, vimdoc, LuaCATS annotations, or lazy loading in the context of Neovim plugin development. Also trigger when the user is working in a directory that looks like a Neovim plugin (contains plugin/, lua/, ftplugin/ subdirectories).

2026-04-06245

GitHub Pull Request Creation

When creating a pull request, use the gh CLI with the following format and conventions.

Always create draft PRs.

Keep PR titles, descriptions, and comments concise and clear.

Include only useful information. Remove redundancy and over-explanation.

Prefer explicitness and clarity over verbosity.

Express Why/What/Notes content as concise, to-the-point bullet lists. Avoid prose paragraphs.

Include a small, illustrative code snippet whenever it conveys the change faster than prose. This is desired for PRs in general, and especially for bug fixes: a minimal example of the triggering case (and what went wrong) makes the problem concrete for reviewers. Keep it short — just enough to convey the point, not a full reproduction.

PR title format

Write the title as if the whole PR was squashed into a single commit using conventional commits.

PR Body Format

## Why? [Explain the motivation for this change. What problem does it solve?] ## What? [Describe what was changed. List the key modifications.] ## Notes [Optional. Additional context, testing notes, or follow-up items.]

Command Template

gh pr create --draft --assignee @me --title "<title>" --body "$(cat <<'EOF' ## Why? <motivation> ## What? <changes> ## Notes <optional notes> EOF )"

File References

Use [file:lineno](url) with SHA-pinned URLs: https://github.com/<owner>/<repo>/blob/<sha>/<path>#L<lineno>

SHA: git rev-parse HEAD

Repo: gh repo view --json nameWithOwner -q .nameWithOwner

Rules

Always assign PR to @me using --assignee @me

## Why? - Required. Explain motivation and problem being solved

## What? - Required. Describe the changes made

## Notes - Optional. Omit entirely if no notes are needed

Use imperative mood in title (e.g., "Add feature" not "Added feature")

Keep title concise and descriptive

When referencing files, always use [file:lineno](url) format with SHA-pinned URLs

Example

gh pr create --draft --assignee @me --title "Add user authentication" --body "$(cat <<'EOF' ## Why? Users need secure access to their accounts. Currently there is no authentication mechanism in place. ## What? - Add login/logout endpoints - Implement JWT token generation - Add password hashing with bcrypt - Create auth middleware for protected routes ## Notes Requires `JWT_SECRET` env variable to be set in production. EOF )"