一键在 Manus 中运行任何 Skill

github-pr

星标2

分支0

更新时间2026年5月7日 18:37

Automates the end-to-end Git workflow: branch creation, staging, committing, pushing, and opening or updating a GitHub pull request. Use when a feature or fix is ready for review and requires a structured PR, or when branch changes may need to be pushed to an existing PR for follow-up review.

安装

用 Codex 或 Claude 帮你安装复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。

在 Manus 中运行

来源

mfmezger

mfmezger/ai_agent_dotfiles

打开 GitHub 仓库查看创作者相关仓库

下载

在 Manus 中运行

GitHub Workflow

This skill guides the process of moving local changes to a GitHub Pull Request.

Prerequisites

git must be installed and configured.
gh (GitHub CLI) must be installed and authenticated.

Commit Message Format

Use Conventional Commits with this required format: <type>(<scope>): <summary>

type REQUIRED. Common values: feat, fix, docs, refactor, chore, test, perf, ci, build, style.
scope REQUIRED. Short noun for the changed area (for example: config, api, ui, docs).
summary REQUIRED. Imperative, <= 72 chars, no trailing period.

Rules:

Never add AI attribution anywhere in the GitHub workflow. Do not write Generated by ..., Co-authored-by: Claude, Co-authored-by: Opus, Co-authored-by: Sonnet, or any other AI/model/agent attribution.
This ban applies to commit subjects, commit bodies, commit footers, PR titles, PR bodies, and PR comments. Do not add it even if a default template, tool, model habit, or previous workflow suggests it.
Do not add sign-offs or breaking-change footers unless the user requests them.

Workflow Steps

Follow this order exactly: confirm branch state, stage, commit, push, then handle the PR.

Branch Check / Creation
- Check the current branch before doing anything else.
- If already on a suitable non-default working branch, stay on it.
- If on a default branch such as main or master, create a feature branch first.
- Identify the scope of changes (e.g., feat, fix, docs, chore).
- Propose a branch name following the pattern <type>/<kebab-case-description>.
- Execute when a new branch is needed: git checkout -b <branch-name>
Review & Stage Changes
- Review changes with git status and git diff.
- By default, stage only the files that belong to the current requested change.
- If the user provided file paths/globs, stage only those files.
- If there are ambiguous extra changed files, ask before staging/committing and leave them unstaged unless the user explicitly includes them.
- Stage the intended files with git add ....
- Optionally inspect recent subjects for local scope patterns: git log -n 10 --pretty=format:%s.
Commit
- Propose a message in exact format: <type>(<scope>): <summary>.
- Execute: git commit -m "<message>"
- If pre-commit hooks fail, diagnose and fix the issues before re-staging and re-committing.
- Do not move on to PR actions until the commit succeeds.
Push
- Push the committed branch to the remote before any PR creation or review trigger.
- If this is the first push for the branch, use: git push -u origin <branch-name>
- If the upstream is already set, use: git push
- Never post /gemini review before the push succeeds for the latest commit.
Pull Request Handling
- Only after a successful push, check whether a PR for the current branch already exists.
- Use gh pr view --json url,number,headRefName to detect an existing PR for the checked-out branch.
- If no PR exists:
  - Create the PR using gh pr create.
  - Provide a concise title (often the commit message) and a body summarizing the changes.
  - Execute: gh pr create --title "<title>" --body "<body>"
  - Share the generated PR URL with the user.
- If a PR already exists:
  - Do not open a duplicate PR.
  - After the push succeeds, add a PR comment containing exactly /gemini review to trigger the code quality review.
  - Execute: gh pr comment <number-or-url> --body "/gemini review"
  - Share the existing PR URL with the user and mention that the review trigger comment was added after pushing the new commit.

Common Failures

Pre-commit hooks: If hooks fail, fix the files and stage them again before committing.
Untracked files: Ensure new files are added.
Remote branch already exists: If the branch exists, ask the user if they want to overwrite or use a different name.

同仓库更多 Skills

同仓库

html-reporting

mfmezger/ai_agent_dotfiles

Produce single-file, self-contained HTML artifacts instead of Markdown for any output a human will actually read. Use whenever the user asks for a "report", "research summary", "write-up", "spec", "plan", "PR explainer", "code review", "design mockup", "prototype", "dashboard", "deck", or anything that benefits from tables, SVG diagrams, color coding, side-by-side comparisons, sliders, drag-and-drop, or shareable visuals. Also use when the user wants to share something visual with a teammate, when a Markdown plan would exceed ~100 lines, when interactive tweaking would help (sliders, copy-as-JSON, copy-as-prompt buttons), or when the model is about to resort to ASCII-art charts or Unicode color blocks in Markdown. Strongly prefer this skill for any "summarize and present" task — even if the user doesn't explicitly say "HTML".

2026-06-032

github-pr-feedback

mfmezger/ai_agent_dotfiles

Use this skill whenever the user asks to look at GitHub PR feedback, PR review comments, review bot output, Gemini/Claude review feedback, or pasted reviewer suggestions and wants a markdown table that separates what should be fixed from what does not need to be fixed. This skill should trigger for PR feedback triage, deciding whether review comments are actionable, and producing a concise markdown report with yes/no emoji decisions and reasoning.

2026-05-152

agent-registry

mfmezger/ai_agent_dotfiles

Use this skill whenever the user wants to interact with Google Cloud's Agent Registry using gcloud commands. Triggers on any mention of "agent registry", "agent-registry", "mcp-servers", "gcloud agents", "register an agent", "list agents", "create a service", "agent service", or any request to manage agents, MCP servers, endpoints, or services in Google Cloud Agent Registry. Also triggers on requests to integrate or use the Google Agent Development Kit (ADK) with the Agent Registry.

2026-05-082

tidy-first

mfmezger/ai_agent_dotfiles

Follow Kent Beck's "Tidy First" approach by strictly separating structural changes (renames, extractions, reorganizations that must not change behavior) from behavioral changes (features, bug fixes, logic changes). Use when refactoring, restructuring code, renaming variables/functions, extracting methods, separating concerns, preparing code for new features, or whenever you need structural and behavioral changes to land in separate commits.

2026-05-082

commit

mfmezger/ai_agent_dotfiles

Read this skill before making git commits

2026-05-072

fastapi

mfmezger/ai_agent_dotfiles

FastAPI application design and implementation conventions. Use this skill when building, updating, or reviewing FastAPI services, routers, dependencies, request/response schemas, streaming endpoints, or API tests. Trigger on FastAPI-specific work such as path operation design, dependency injection, response models, `Annotated` parameters, `fastapi` CLI usage, SQLModel-backed APIs, or refactoring older FastAPI code to current patterns.

2026-03-302

name	github-pr
description	Automates the end-to-end Git workflow: branch creation, staging, committing, pushing, and opening or updating a GitHub pull request. Use when a feature or fix is ready for review and requires a structured PR, or when branch changes may need to be pushed to an existing PR for follow-up review.

GitHub Workflow

This skill guides the process of moving local changes to a GitHub Pull Request.

Prerequisites

git must be installed and configured.
gh (GitHub CLI) must be installed and authenticated.

Commit Message Format

Use Conventional Commits with this required format: <type>(<scope>): <summary>

type REQUIRED. Common values: feat, fix, docs, refactor, chore, test, perf, ci, build, style.
scope REQUIRED. Short noun for the changed area (for example: config, api, ui, docs).
summary REQUIRED. Imperative, <= 72 chars, no trailing period.

Rules:

Never add AI attribution anywhere in the GitHub workflow. Do not write Generated by ..., Co-authored-by: Claude, Co-authored-by: Opus, Co-authored-by: Sonnet, or any other AI/model/agent attribution.
This ban applies to commit subjects, commit bodies, commit footers, PR titles, PR bodies, and PR comments. Do not add it even if a default template, tool, model habit, or previous workflow suggests it.
Do not add sign-offs or breaking-change footers unless the user requests them.

Workflow Steps

Follow this order exactly: confirm branch state, stage, commit, push, then handle the PR.

Branch Check / Creation
- Check the current branch before doing anything else.
- If already on a suitable non-default working branch, stay on it.
- If on a default branch such as main or master, create a feature branch first.
- Identify the scope of changes (e.g., feat, fix, docs, chore).
- Propose a branch name following the pattern <type>/<kebab-case-description>.
- Execute when a new branch is needed: git checkout -b <branch-name>
Review & Stage Changes
- Review changes with git status and git diff.
- By default, stage only the files that belong to the current requested change.
- If the user provided file paths/globs, stage only those files.
- If there are ambiguous extra changed files, ask before staging/committing and leave them unstaged unless the user explicitly includes them.
- Stage the intended files with git add ....
- Optionally inspect recent subjects for local scope patterns: git log -n 10 --pretty=format:%s.
Commit
- Propose a message in exact format: <type>(<scope>): <summary>.
- Execute: git commit -m "<message>"
- If pre-commit hooks fail, diagnose and fix the issues before re-staging and re-committing.
- Do not move on to PR actions until the commit succeeds.
Push
- Push the committed branch to the remote before any PR creation or review trigger.
- If this is the first push for the branch, use: git push -u origin <branch-name>
- If the upstream is already set, use: git push
- Never post /gemini review before the push succeeds for the latest commit.
Pull Request Handling
- Only after a successful push, check whether a PR for the current branch already exists.
- Use gh pr view --json url,number,headRefName to detect an existing PR for the checked-out branch.
- If no PR exists:
  - Create the PR using gh pr create.
  - Provide a concise title (often the commit message) and a body summarizing the changes.
  - Execute: gh pr create --title "<title>" --body "<body>"
  - Share the generated PR URL with the user.
- If a PR already exists:
  - Do not open a duplicate PR.
  - After the push succeeds, add a PR comment containing exactly /gemini review to trigger the code quality review.
  - Execute: gh pr comment <number-or-url> --body "/gemini review"
  - Share the existing PR URL with the user and mention that the review trigger comment was added after pushing the new commit.

Common Failures

Pre-commit hooks: If hooks fail, fix the files and stage them again before committing.
Untracked files: Ensure new files are added.
Remote branch already exists: If the branch exists, ask the user if they want to overwrite or use a different name.