Execute qualquer Skill no Manus
com um clique

Execute qualquer Skill no Manus com um clique

commit-push-pr

Estrelas0

Forks0

Atualizado6 de abril de 2026 às 09:58

Create a git commit, push a branch, and open a Pull Request with gh. Use when asked to commit changes, push to origin, or create PRs, especially when conventional commits and PR templates are required.

Instalação

Instalar com Codex ou Claude Copie este prompt, cole no Codex, Claude ou outro assistente e deixe que ele revise a página da skill e instale para você.

Executar no Manus

Fonte

whywaita

whywaita/dotfiles

Abrir repositório GitHub Ver repositórios do creator

Download

Executar no Manus

Ocupações relacionadasSOC

Baseado na classificação ocupacional SOC

Desenvolvedores de softwareInformática e Matemática·SOC 15-1252

SKILL.md

readonly

name	commit-push-pr
description	Create a git commit, push a branch, and open a Pull Request with gh. Use when asked to commit changes, push to origin, or create PRs, especially when conventional commits and PR templates are required.

Commit, Push, and PR Workflow

Workflow

Detect PR language by reading README / README.md.
- If the README contains Japanese text, use Japanese for PR title/body; otherwise use English.
Ensure a feature branch.
- Run git branch --show-current.
- If on main or master, infer branch naming from git branch -r --list 'origin/*' | grep -v 'HEAD\|main\|master', propose a name, then run git switch -c <branch-name>.
Try signed commit first, fallback if it fails.
- Attempt a signed commit with git commit -S.
- If the signed commit fails, retry without signing using git -c commit.gpgsign=false commit and note the fallback in the response.
Create a Conventional Commit.
- Format:
  - <type>[optional scope]: <description>
  - Optional body
  - Conversation log:
    - prompt: <user prompt>
    - ----
    - <assistant response>
    - Repeat for each exchange
  - Optional footer(s)
- Use feat|fix|docs|style|refactor|test|chore|ci|build|perf as needed.
- Keep description present tense, lowercase, under 50 chars, no period.
Rebase onto the base branch to detect and resolve conflicts.
- Determine the base branch via git symbolic-ref refs/remotes/origin/HEAD.
- git fetch origin <base-branch>.
- git rebase origin/<base-branch>.
  - If clean: proceed.
  - If conflicts: resolve them, git add <files>, git rebase --continue. Repeat for each conflicting commit.
  - Report which files had conflicts and how they were resolved.
Push the branch.
- If no upstream: git push -u origin <branch-name>.
- Otherwise: git push (use git push --force-with-lease if rebase was performed).
Create a PR with gh pr create.
- Look for PR templates in .github/PULL_REQUEST_TEMPLATE.md, .github/PULL_REQUEST_TEMPLATE/, or docs/PULL_REQUEST_TEMPLATE.md.
- If no template, use a language-appropriate default template.
- Use a HEREDOC body:
```
gh pr create --title "<title>" --body "$(cat <<'EOF'
<body>
EOF
)"
```
Output the PR URL.
Verify CI status.
- gh pr checks <pr-number> --watch (timeout 10 minutes), or gh run list --branch <branch> --limit 5 + gh run view <run-id>.
- If all checks pass: report success.
- If any check fails: a. gh run view <run-id> --log-failed to get detailed logs. b. Analyze and fix the failure (build errors, test failures, lint errors, etc.). c. Create a new commit (fix(ci): <description>), push. d. Re-check CI. Repeat up to 3 times. e. If still failing after 3 attempts, report remaining failures to the user.

Default PR templates

English

## Summary
- <1-3 bullets>

## Changes
- <specific changes>

## Test Plan
- <how to test>

## Notes
- <extra context>

Japanese

## 概要
- <1〜3点>

## 変更点
- <具体的な変更>

## テスト方法
- <テスト手順>

## 備考
- <補足>

Mais deste repositório

mesmo repositório

poker-hand-review

whywaita/dotfiles

ポーカーのハンドレビューと座学を統合的に行うスキル。ユーザのハンドをGTO Wizardのソルバーデータとブログ記事を根拠に多角的にレビューし、同時に集合分析ベースの体系的な座学を実施する。数学的根拠（ポットオッズ、エクイティ、EV計算）とexploit観点を含む。「ハンドレビューして」「このハンドどう思う？」「レビューお願い」「hand review」「この判断正しかった？」「座学したい」「このスポットを勉強したい」「集合分析を見たい」「深掘りして勉強」「このスポットの全体像を知りたい」

2026-04-190

design-to-spec

whywaita/dotfiles

設計ドキュメント（Design Doc）を実装可能な仕様書（Spec）に変換するスキル。「なぜ作るか」を「何を作るか」に変換し、実装者・QA・保守者が参照できる明確な仕様を生成する。「スペックにまとめて」「仕様書にして」「実装仕様を書いて」「specに変換して」でトリガーすること。 dig で曖昧さを解消してから使用すると最も効果的。

2026-04-060

dig

whywaita/dotfiles

既存の設計ドキュメント・RFC・計画書を読み込み、AskUserQuestion による構造化された質問を通じて、曖昧さ・矛盾・未定義事項を洗い出し、決定事項と残課題を整理するスキル。「深掘りして」「曖昧な点を洗い出して」「設計の穴を突いて」「challenge my assumptions」「ドキュメントを読んで質問して」のような依頼でトリガーすること。仕様書（spec）の生成が目的の場合は design-to-spec を使うこと。

Automates browser interactions for web testing, form filling, screenshots, and data extraction. Use when the user needs to navigate websites, interact with web pages, fill forms, take screenshots, test web applications, or extract information from web pages.

2026-02-040

Commit, Push, and PR Workflow

Workflow

Detect PR language by reading README / README.md.

If the README contains Japanese text, use Japanese for PR title/body; otherwise use English.

Ensure a feature branch.

Run git branch --show-current.
If on main or master, infer branch naming from git branch -r --list 'origin/*' | grep -v 'HEAD\|main\|master', propose a name, then run git switch -c <branch-name>.

Try signed commit first, fallback if it fails.

Attempt a signed commit with git commit -S.
If the signed commit fails, retry without signing using git -c commit.gpgsign=false commit and note the fallback in the response.

Create a Conventional Commit.

Format:
- <type>[optional scope]: <description>
- Optional body
- Conversation log:
  - prompt: <user prompt>
  - ----
  - <assistant response>
  - Repeat for each exchange
- Optional footer(s)
Use feat|fix|docs|style|refactor|test|chore|ci|build|perf as needed.
Keep description present tense, lowercase, under 50 chars, no period.

Rebase onto the base branch to detect and resolve conflicts.

Determine the base branch via git symbolic-ref refs/remotes/origin/HEAD.
git fetch origin <base-branch>.
git rebase origin/<base-branch>.
- If clean: proceed.
- If conflicts: resolve them, git add <files>, git rebase --continue. Repeat for each conflicting commit.
- Report which files had conflicts and how they were resolved.

Push the branch.

If no upstream: git push -u origin <branch-name>.
Otherwise: git push (use git push --force-with-lease if rebase was performed).

Create a PR with gh pr create.

Look for PR templates in .github/PULL_REQUEST_TEMPLATE.md, .github/PULL_REQUEST_TEMPLATE/, or docs/PULL_REQUEST_TEMPLATE.md.
If no template, use a language-appropriate default template.

Use a HEREDOC body:

gh pr create --title "<title>" --body "$(cat <<'EOF'
<body>
EOF
)"

Output the PR URL.

Verify CI status.

gh pr checks <pr-number> --watch (timeout 10 minutes), or gh run list --branch <branch> --limit 5 + gh run view <run-id>.
If all checks pass: report success.
If any check fails: a. gh run view <run-id> --log-failed to get detailed logs. b. Analyze and fix the failure (build errors, test failures, lint errors, etc.). c. Create a new commit (fix(ci): <description>), push. d. Re-check CI. Repeat up to 3 times. e. If still failing after 3 attempts, report remaining failures to the user.

Default PR templates

English

## Summary - <1-3 bullets> ## Changes - <specific changes> ## Test Plan - <how to test> ## Notes - <extra context>

Japanese

## 概要 - <1〜3点> ## 変更点 - <具体的な変更> ## テスト方法 - <テスト手順> ## 備考 - <補足>