Communitygithub.com

PINKIIILQWQ/oh-my-gh-writing

AIエージェント向けのエビデンスバインド型GitHubライティングスキル。18のアーティファクト標準と7つのローカルワークフローパックを備えています。

oh-my-gh-writing とは?

このスキルは、AIエージェント(Claude Code、Cursor、Codexなど)がGitHub上で高品質なアーティファクト(Issue、PR、README、リリースノートなど)を作成するためのルールベースのワークフローを提供します。ユーザーのリクエストを分析し、適切な単一アーティファクト標準または複合ワークフローパックにルーティングします。ワークフローは「トリガー境界の識別→リクエストルーティング→参照ファイルの明示的読み込み→検証済みドラフトの生成」という明確な手順に従い、参照ファイルにアクセスできない場合は控えめなドラフトのみを生成します。18の単一アーティファクト標準(バグ報告、機能リクエスト、PRテンプレート、リリースノートなど)と7つの複合ワークフローパック(バージョンリリース、プロジェクトローンチ、コントリビューションセットアップなど)を提供し、監査モードではギャップ分析のみを出力します。出力前に参照ファイル`references/output-validation.md`を使用したサイレント検証チェックリストを実行し、エビデンス境界を明確に保ちます。

対応✓Claude Code~Codex CLI~Cursor
npx skills add PINKIIILQWQ/oh-my-gh-writing

お気に入りのAIに質問する

このエージェントスキルを事前に読み込んだ状態で新しいチャットを開きます。

ドキュメント

oh-my-gh-writing は何をしますか?

AIエージェント向けGitHubライティングスキル。リクエストをルーティングし、該当する標準をロードし、エビデンス境界を明確に保ち、提出間近のGitHubドラフトを生成します。

トリガー境界

このスキルは、GitHub向けライティングアーティファクトおよびローカルのGitHubライティングドラフトパッケージに使用します。一般的なコピーライティング、UIテキスト、コード実装、製品戦略、または広範なドキュメント作成には使用しないでください。ただし、要求された出力がGitHubアーティファクトまたはGitHubリポジトリファイルである場合は除きます。

ワークフロー

  1. ユーザーが単一のアーティファクトを望んでいるか、複数アーティファクトのワークフローパックを望んでいるかを特定します。
  2. ユーザーが単一のアーティファクトを明示的に指定した場合、トピックが広くてもそのアーティファクトにルーティングします。
  3. ユーザーが広範なワークフロー、立ち上げ、セットアップ、リリースパッケージ、またはエンドツーエンドの資料セットを要求した場合、該当する複合ワークフローパックにルーティングします。
  4. ユーザーが検査、確認、準備状況のレビュー、または必要なファイルの推奨を求めた場合、監査のみとして扱います。ギャップ分析と次のファイル推奨事項のみを出力します。ターゲットファイルを作成せず、.github-writing/を作成せず、ユーザーが明示的にドラフト、作成、書き込み、適用、または更新を要求しない限り.github/またはルートリポジトリファイルを作成しません。
  5. READMEリクエストの場合、references/readme.mdの3つの質問プロンプトを使用します。
  6. 複合ワークフローパックの場合、パックの決定ルールに従います。パッケージの形状が安全に推測できない場合のみ、パッケージ選択の質問を1回行います。それ以外の場合は推奨デフォルトを使用し、package-manifest.mdに記録します。
  7. ユーザー向け出力を書く前に、該当するreferences/*.mdを明示的に開いて読みます。メモリから参照内容を推測したり推測したりしないでください。
  8. 複合パックによって選択された単一アーティファクト参照のみを読みます。すべての参照を事前にロードしないでください。
  9. バッジ、アラート、Mermaid、折りたたみブロック、絵文字、または複雑なテーブルが必要な場合、references/weapons.mdを読みます。
  10. ユーザーが詳細なバッジデザインまたは正確なshields.io URLパターンを要求した場合のみ、references/badge-catalog.mdを読みます。
  11. 絵文字が要求された場合、またはターゲットリポジトリが既に絵文字を使用している場合、references/emoji-guide.mdを読みます。
  12. リクエストが事実に基づいており、リスクが高く、複数のシナリオにまたがる場合、または出力品質ルールの明確化が必要な場合、references/shared-principles.mdを読みます。
  13. 最終確定前に、references/output-validation.mdをサイレントリビジョンチェックリストとして使用します。ドラフトがチェックに合格しない場合、提出前に修正します。小さなクリーンなアーティファクトの場合は検証をサイレントに保ちます。アーティファクトが複雑、高リスク、または明らかなブロッカーがある場合のみ、簡潔な投稿後提出ノートを追加します。

ローカルファイル読み取りが利用できない場合、ユーザーに関連するreferences/*.mdの内容を提供するか、参照が利用できないことを伝え、表示されているルーティングルールと共通原則からのみ控えめなドラフトを生成するよう依頼します。アクセスできないファイルを読んだふりをしないでください。

プログレッシブディスクロージャー: 現在のタスクに必要なファイルのみをロードします。複数の参照が本当に必要であり、プラットフォームがバッチ読み取りをサポートしている場合、シリアルツール呼び出しではなく、1回のバッチで読み取ります。

言語の忠実性: ユーザーの要求言語またはターゲットリポジトリの主要言語に合わせます。このスキルの指示の言語は、最終的なGitHubアーティファクトに漏れてはいけません。

シナリオルーティング

18の単一アーティファクト標準と7つの複合ワークフローパックの完全なリストについては、INDEX.mdを参照してください。

以下のトップレベルルーティングルールを使用します。

シグナルルーティング先
ユーザーが「リリースノートを書いて」や「PRテンプレートを作成して」など、1つの明示的なアーティファクトを要求該当する単一アーティファクト参照
ユーザーがリリースパッケージ、バージョン更新資料、メジャーリリース準備、またはソフトウェア更新バンドルを要求references/version-release.md
ユーザーがリポジトリを初めて公開またはオープンソース化したいreferences/project-launch.md
ユーザーがプロジェクトを外部コントリビューター向けに準備したいreferences/contribution-setup.md
ユーザーがバグレポートやトリアージから修正PRまでのバグ処理をしたいreferences/bug-fix-workflow.md
ユーザーがアイデアを議論、設計、Issue、実装資料に変換したいreferences/proposal-to-implementation.md
ユーザーが破壊的変更のコミュニケーションパッケージを必要としているreferences/breaking-change-package.md
ユーザーが広範なドキュメントリフレッシュまたはドキュメントの大幅な見直しを必要としているreferences/docs-overhaul.md

プロンプトがIssue、PR、および議論の言語を混合している場合:

シグナルルーティング先
実装された差分のない将来の機能リクエスト機能リクエスト
既存の動作の改善拡張
未決定の解決策を伴うコミュニティインプット議論
ブランチ、差分、またはPRが新しい機能を実装機能PR
ブランチ、差分、またはPRがバグまたはリグレッションを修正バグ修正PR
変更が動作変更なしでコードを再編成リファクタリングPR
ドキュメントのみが変更されたドキュメントPR
ユーザーがコード、PR、または差分のレビューを要求コードレビュー

ユーザーがPR、ポストモーテム、または議論を異なるアーティファクトに変換するよう要求した場合、ソース資料ではなく要求されたアーティファクトにルーティングします。

複合ワークフローデフォルト

複合ワークフローパックはテンプレートではなく、オーケストレーターです。それらは、ロードする既存の単一アーティファクト標準を選択します。

  • 監査専用プロンプトは、パッケージファイルではなく推奨事項を生成します。
  • パックの決定ルールがデフォルトを安全に選択できない場合のみ、1回のパッケージ選択質問を行います。
  • 質問なしでデフォルトが選択された場合、選択されたオプションと前提条件をpackage-manifest.mdに記録します。
  • オプションの補足を同じメッセージに含めます。
  • デフォルトの出力場所は、.github-writing/<pack-name>/<version-or-date>/の下のローカルドラフトファイルです。
  • バージョンまたは日付が不明な場合、.github-writing/<pack-name>/TBD/を使用します。
  • すべての複合パッケージにpackage-manifest.mdを含め、生成されたファイル、前提条件、TODO / TBDフィールド、書き込み可能なファイル、およびメンテナー確認が必要なファイルをリストします。
  • ファイル書き込みが利用できない場合、## File: ...見出しとフェンス付きブロックを使用して、パッケージをマルチファイルチャット出力として表示します。ファイルが書き込まれたと主張しないでください。
  • ユーザーが明示的に要求しない限り、公開、GitHubリリースの作成、タグのプッシュ、PRのオープン、またはリモート状態の変更を行わないでください。

参照インデックス

完全なナビゲーションについてはINDEX.mdをロードしてください。一般的な参照グループ:

グループ参照
Issuebug-report.md, feature-request.md, enhancement.md, discussion.md
プルリクエストfeature-pr.md, bug-fix-pr.md, refactor-pr.md, documentation-pr.md
レビューとコミットcode-review.md, standard-commit.md
ドキュメントreadme.md, contributing.md, changelog.md
リリースとデザインrelease-notes.md, migration-guide.md, rfc.md
テンプレートissue-form-yaml.md, pr-template.md
複合パックversion-release.md, project-launch.md, contribution-setup.md, bug-fix-workflow.md, proposal-to-implementation.md, breaking-change-package.md, docs-overhaul.md
付録shared-principles.md, weapons.md, badge-catalog.md, emoji-guide.md, output-validation.md, source-catalog.md

不足情報

必要な選択肢が安全に推測できない場合のみ、短いフォローアップ質問を行います(例: ターゲットパッケージ名、リリースバージョン、破壊的変更の意図、出力パッケージの形状、アーティファクト構造を変更するスコープ選択)。それ以外の場合はTBDまたはTODOを使用し、前提条件を簡潔に述べ、証拠がない場合はオプションのセクションを削除します。

リポジトリメンテナンス

  • SKILL.mdを軽量なランタイムルーターとして維持します。
  • シナリオ固有および複合パックのルールは、該当するreferences/*.mdに配置します。
  • INDEX.mdをナビゲーション専用に保ちます。
  • ランタイム指示はデフォルトで英語に保ちます。
  • READMEの間違いが発見された場合、references/readme.mdのREADME向け教訓を更新します。
  • ローカルリサーチと検証出力は、追跡対象のランタイムコンテンツから除外します。

関連スキル