一键在 Manus 中运行任何 Skill

create-issue

星标2

分支0

更新时间2026年3月25日 05:11

GitHub Issueを作成してGitHubに投稿するスキル。「Issueを作成」「Issue作成」「Issueにして」「Issueとして投稿」「GitHubにIssue」「create issue」「open issue」「バグ報告」「機能追加をIssueに」「改善提案をIssueに」などの依頼でトリガーする。コンテキスト収集→Issue本文生成→ラベル存在確認・作成→gh issue create投稿の流れでIssueを作成する。

安装

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

在 Manus 中运行

来源

studiogadget

studiogadget/skills

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

下载

在 Manus 中运行

GitHub Issue 作成スキル

ユーザーが指定した内容（機能追加・バグ修正・改善提案など）について、構造化されたGitHub Issueを作成し gh issue create コマンドで投稿する。

トリガー条件

「〇〇のIssueを作成して」
「〇〇をIssueにして」
「〇〇をGitHubにIssue投稿して」
「〇〇の改善提案をIssueにして」
「〇〇のバグをIssue報告して」
英語: "create issue for ○○", "open issue for ○○"

ワークフロー（5ステップ）

Step 1: コンテキスト収集

Issue の内容を充実させるため、以下を自律的に調査する。

必須調査項目:

会話コンテキスト — ユーザーとの直近の会話から、変更理由・背景・課題を抽出
関連コード — 変更対象ファイルの現状実装を確認（ファイルパス・行番号を特定）
仕様書 — docs/specs/ 配下の requirements.md, design.md（存在する場合）
設定ファイル — 関連する config.yaml のセクション

判断が必要な場合のみユーザーに確認:

Issue の種別が不明確な場合（feature / fix / refactor）
影響範囲が曖昧な場合

Step 2: Issue 本文の生成

Issue テンプレートに従って本文を生成する。

生成ルール:

言語: 日本語（コード・識別子は英語）
WHY / WHAT / Acceptance Criteria を必ず含める
禁止語を使用しない: best / optimal / faster / always / never / perfect
コード参照はファイルパス・行番号を明記する
疑似コードを含める場合は実装イメージが伝わる程度に簡潔に記載する
secrets / PII を含めない
判断が必要な場合以外は確認なしで即座に実行すること

ラベル選択ルール:

Issue 種別	ラベル
新機能	`enhancement`
バグ修正	`bug`
リファクタ	`refactor`
ドキュメント	`documentation`
テスト	`test`
性能改善	`performance`

Step 3: ラベルの存在確認と作成

投稿前に、使用するラベルがリポジトリに存在するか確認し、存在しない場合は作成する。

# ラベルの存在確認
$labelExists = gh label list --json name --jq ".[].name" | Select-String -Quiet "^<label>$"

if (-not $labelExists) {
    # ラベルが存在しない場合は作成
    gh label create --force "<label>" --color "<color>"
}

ラベルカラー対応表:

ラベル	カラー
`enhancement`	`#a2eeef`
`bug`	`#d73a4a`
`refactor`	`#e4e669`
`documentation`	`#0075ca`
`test`	`#bfd4f2`
`performance`	`#f9d0c4`

Step 4: gh CLI で投稿

Issue 本文を一時ファイル issue_body.md に書き出す
gh issue create コマンドで投稿する
一時ファイルを削除する（2で失敗した場合も必ず実行すること）

try {
    # 投稿コマンド
    gh issue create --title "<title>" --body-file issue_body.md --label "<label>"
}
finally {
    # クリーンアップ（成功・失敗にかかわらず実行）
    Remove-Item issue_body.md -ErrorAction SilentlyContinue
}

タイトル形式: <type>(<scope>): <summary>

type: feat / fix / refactor / docs / test / chore / perf
scope: 対象モジュール/機能の短縮名
summary: 変更内容の要約（日本語可）

Step 5: 結果報告

作成された Issue の URL を提示する
Issue 内容の要点（WHY / WHAT / AC の概要）を箇条書きで要約する

注意事項

gh CLI がインストール済みかつ認証済みであることを前提とする
gh コマンドが失敗した場合は、エラー内容をユーザーに報告し対処法を提示する
gh コマンドが失敗した場合も、issue_body.md は必ず削除すること（クリーンアップの徹底）
PowerShell 環境でのヒアドキュメント（@- << 'EOF'）は非対応のため、一時ファイル経由で投稿する

同仓库更多 Skills

同仓库

cc-sdd-review-slice-stack

studiogadget/skills

cc-sdd実装用統合ブランチのコミット群（ベースブランチとの差分）をreview slice単位のstacked PRに再構成する際に使用。「review sliceに分割」「stacked PRを作成」「PRをスタックして」「レビュー用にPRを分けて」「review slice stack」という依頼でトリガーする。dry-run（既定）でslice計画を提示し、apply指示で実際にブランチ・PRを作成する。

2026-05-252

cc-sdd-restack-after-merge

studiogadget/skills

stacked PRの下位PRがマージされた後に上位branchをrestack（rebase/cherry-pick再構成）する際に使用。「restackして」「上位PRを更新して」「restack after merge」「PRのbaseを更新」「スタックを整理」という依頼でトリガーする。対象sliceの特定→rebase→変更ファイル確認と代表テスト実行→force-with-leaseでpush→PR base更新→auto-merge判定の順で進める。

2026-05-222

sec-full-scan

studiogadget/skills

リリース前の全ファイル静的解析スキル。プロジェクト構造を自動検出し、ソースモジュールごとのサブエージェントと依存関係スキャンを並列実行してコードベース全体の脆弱性を検出する。手動呼び出し専用: /sec-full-scan

2026-05-192

sec-runtime-scan

studiogadget/skills

ステージング環境にデプロイ済みのサーバーに対してランタイム検証を実行する。HTTPヘッダー・動的プローブ・認証テストに特化。手動呼び出し専用: /sec-runtime-scan [環境名]

2026-05-192

sec-diff-review

studiogadget/skills

PR・ブランチの変更差分（git diff）を静的解析してセキュリティ脆弱性を検出する。開発中・PRレビュー時に使用。手動呼び出し専用: /sec-diff-review

2026-05-192

resolve-pr-review-threads

studiogadget/skills

PRの未Resolveレビュー指摘に対応するスキル。「PRの指摘に対応して」「Resolveされていないスレッドを解消」「PR reviewの対応」「未解決のレビューコメントを修正」「Copilotの指摘を直して」「Codexの指摘に対応」「chatgpt-codex-connectorの指摘」「レビュー対応」で起動。PR URL or 番号 → 未Resolveスレッド取得 → 対象ファイル修正 → ユーザーへ最終ゲートとプッシュの実行手順を案内、の流れで進める。

2026-05-162

name

create-issue

description

GitHub Issue 作成スキル

ユーザーが指定した内容（機能追加・バグ修正・改善提案など）について、構造化されたGitHub Issueを作成し gh issue create コマンドで投稿する。

トリガー条件

「〇〇のIssueを作成して」
「〇〇をIssueにして」
「〇〇をGitHubにIssue投稿して」
「〇〇の改善提案をIssueにして」
「〇〇のバグをIssue報告して」
英語: "create issue for ○○", "open issue for ○○"

ワークフロー（5ステップ）

Step 1: コンテキスト収集

Issue の内容を充実させるため、以下を自律的に調査する。

必須調査項目:

会話コンテキスト — ユーザーとの直近の会話から、変更理由・背景・課題を抽出
関連コード — 変更対象ファイルの現状実装を確認（ファイルパス・行番号を特定）
仕様書 — docs/specs/ 配下の requirements.md, design.md（存在する場合）
設定ファイル — 関連する config.yaml のセクション

判断が必要な場合のみユーザーに確認:

Issue の種別が不明確な場合（feature / fix / refactor）
影響範囲が曖昧な場合

Step 2: Issue 本文の生成

Issue テンプレートに従って本文を生成する。

生成ルール:

言語: 日本語（コード・識別子は英語）
WHY / WHAT / Acceptance Criteria を必ず含める
禁止語を使用しない: best / optimal / faster / always / never / perfect
コード参照はファイルパス・行番号を明記する
疑似コードを含める場合は実装イメージが伝わる程度に簡潔に記載する
secrets / PII を含めない
判断が必要な場合以外は確認なしで即座に実行すること

ラベル選択ルール:

Issue 種別	ラベル
新機能	`enhancement`
バグ修正	`bug`
リファクタ	`refactor`
ドキュメント	`documentation`
テスト	`test`
性能改善	`performance`

Step 3: ラベルの存在確認と作成

投稿前に、使用するラベルがリポジトリに存在するか確認し、存在しない場合は作成する。

# ラベルの存在確認
$labelExists = gh label list --json name --jq ".[].name" | Select-String -Quiet "^<label>$"

if (-not $labelExists) {
    # ラベルが存在しない場合は作成
    gh label create --force "<label>" --color "<color>"
}

ラベルカラー対応表:

ラベル	カラー
`enhancement`	`#a2eeef`
`bug`	`#d73a4a`
`refactor`	`#e4e669`
`documentation`	`#0075ca`
`test`	`#bfd4f2`
`performance`	`#f9d0c4`

Step 4: gh CLI で投稿

Issue 本文を一時ファイル issue_body.md に書き出す
gh issue create コマンドで投稿する
一時ファイルを削除する（2で失敗した場合も必ず実行すること）

try {
    # 投稿コマンド
    gh issue create --title "<title>" --body-file issue_body.md --label "<label>"
}
finally {
    # クリーンアップ（成功・失敗にかかわらず実行）
    Remove-Item issue_body.md -ErrorAction SilentlyContinue
}

タイトル形式: <type>(<scope>): <summary>

type: feat / fix / refactor / docs / test / chore / perf
scope: 対象モジュール/機能の短縮名
summary: 変更内容の要約（日本語可）

Step 5: 結果報告

作成された Issue の URL を提示する
Issue 内容の要点（WHY / WHAT / AC の概要）を箇条書きで要約する

注意事項

gh CLI がインストール済みかつ認証済みであることを前提とする
gh コマンドが失敗した場合は、エラー内容をユーザーに報告し対処法を提示する
gh コマンドが失敗した場合も、issue_body.md は必ず削除すること（クリーンアップの徹底）
PowerShell 環境でのヒアドキュメント（@- << 'EOF'）は非対応のため、一時ファイル経由で投稿する