.md
Skill.mdサーチャーJP

Skill.md検索

2258件の Skill.mdから、あなたに最適なものを見つけましょう

T

コミット差分からPRを自動生成する

by tokiraku

現在のブランチとベースブランチの差分を自動分析し、PRタイトルと説明文を自動生成できます。 コミット履歴や変更ファイル情報から、適切なConventional Commitsプレフィックス(feat・fix・refactor等)を判定します。 PR説明に背景・目的・変更内容・破壊的変更の有無をMarkdown形式で自動フォーマットできます。 ユーザー承認後にGitHubへ自動でPRを作成でき、手作業のコピペを削減できます。 ソフトウェア開発者:PR作成の定型作業を自動化したい方 チームリード:PR品質を統一し、レビュー効率を高めたい方 GitHub利用プロジェクト管理者:PR作成フローを標準化したい方 開発生産性を高めたい個人・チーム:毎回のタイトル・説明作成を自動化したい方 GitHubプルリクエスト作成スキルは、git branch・git log・git diffコマンドでブランチ差分を収集した後、変更の目的(機能追加・バグ修正・リファクタリング等)・変更ファイル・Breaking Change有無・関連Issue番号を分析します。タイトルは50~72文字以内で命令形、Conventional Commitsプレフィックス付与が基準。PR説明は「背景→目的→変更内容→変更種別→確認方法→補足」のテンプレートで生成され、Breaking Changeがあれば該当箇所に⚠マークとClosesキーワードを自動挿入します。GitHub MCPが利用可能な場合は優先使用され、ユーザー明示的承認後にPRを作成します。

レビューテストドキュメント
02952026-04-07
T

プロジェクト立ち上げの要件と憲章を一度に定義できる

by tokiraku

キックオフヒアリングで3ラウンドに分けて段階的に質問を提示し、プロジェクトの輪郭・技術スタック・制約・成功基準を構造化。 収集した情報から技術要件ドキュメント(機能要件・非機能要件・技術スタック・制約を網羅)を自動生成。 プロジェクト憲章(目標・スコープ・マイルストーン・リスク・ステークホルダーをまとめた承認文書)を同時生成。 Mermaid図(システム構成図・フロー図・ER図など)を自動選択・埋め込みで、複雑な要件を視覚化。 AGENTS.mdへの反映で、Claude Code・GitHub Copilot両方で共有できるプロジェクトコンテキストを宣言。 プロジェクト開始時に要件定義と承認文書を一度に準備したいプロダクトマネージャー 技術スタック・制約・リスクを早期に可視化してから開発着手したい開発チーム チーム内の認識ズレを防ぎ、共通の目標・スコープを確立したいスクラムマスター 複数のAIコーディングアシスタント間でプロジェクト情報を一元化したい開発者 質問形式でインタラクティブにプロジェクト情報を収集する3ラウンドヒアリング。Step1で引数(プロジェクト名/概要)確認。Step2ラウンド1(最大5問):ゴール・対象ユーザー・MVP機能・既存資産・リリース目標。Step3ラウンド2(最大5問、ラウンド1回答に基づき調整):言語/FW/クラウド・チーム構成・セキュリティ要件・予算/ライセンス・パフォーマンス目標。Step4ラウンド3(成功基準/リスク要確認)。Step5でサマリー提示・確認。Step6で技術要件ドキュメント生成(出力先:docs/requirements/-tech-requirements.md)。複数システム間の関係はgraph LR、複数アクターのリクエストはsequenceDiagram、ユーザー操作フローはflowchart TD、エンティティ関係はerDiagramで図を自動選択。詳細な機能要件深堀りはrequirementsスキルで後続実行。

レビューテストドキュメント
02672026-04-07
T

要件ドキュメントから実装タスクを自動生成

by tokiraku

要件ドキュメント(機能要件・非機能要件)を読み込み、実装レベルの粒度でタスクに自動分解します。大ざっぱな要件をそのまま実装するのではなく、1〜2時間で完了できるサイズの実装単位に細分化するため、着手しやすくなります。 タスク一覧を tasks/todo.md に永続化し、セッションをまたいで参照できます。セッションが終わっても タスクが保存されているため、次のセッションで即座に作業を再開できます。 現セッションのタスク管理ツール(TodoWrite)に自動セットできます。分解したタスクが即座にタスク管理ツールに反映されるため、タスク作成後すぐに進捗を追跡できます。 フェーズ別のタスク整理ができます。設計→インフラ・基盤→ドメイン層→アプリケーション層→プレゼンテーション層→フロントエンド→テスト→非機能要件対応 という実装順序に沿ってタスクが自動分類されます。 要件IDの引継ぎと親子関係を管理できます。元の要件ID(FR-001 等)を保持しながら、タスクID(FR-001-01、FR-001-02 等)を採番するため、要件とタスクのトレーサビリティ(追跡可能性)が確保されます。 要件ドキュメントを受け取ったが、「これをどうやって実装しよう」と困っている人 複数の要件を抱えており、優先度・順序立てて実装タスクに変換したい人 セッションをまたいで一貫性のあるタスク管理をしたい人 要件とコード実装のトレーサビリティを確保したい人(品質管理・監査の観点) このスキルは /requirements または /tech-requirements で作成した要件ドキュメントを読み込み、実装可能な粒度(1〜2時間で完了できるタスク)に分解します。 Step 1 では対象ドキュメントを特定します。ファイルパス引数がある場合はそれを使用、ない場合は docs/requirements/ 配下のファイルを Glob で一覧取得し、複数ある場合はユーザーに確認、1つの場合は自動選択します。*-tech-requirements.md と機能要件 *-requirements.md が両方ある場合は両方読み込みます。 Step 2 では要件を解析します。機能要件(FR-xxx)から要件ID・名・優先度(MoSCoW)・受け入れ基準(Given/When/Then)を、非機能要件(NFR-xxx)からID・カテゴリ・計測基準を、技術ドキュメントからは技術スタック・マイルストーン・アーキテクチャ制約を抽出します。 Step 3 では実装レベルのタスク粒度(1〜2時間で完了、完了判定が明確)に分解し、設計→インフラ→ドメイン→アプリケーション→プレゼンテーション→フロントエンド→テスト→非機能対応 の8フェーズに分類します。タスクIDは要件IDを引き継ぎ(FR-001-01等)、インフラ・設計は独自プレフィックス(INFRA-001、SETUP-001)、テストは元IDに-test付加します。 Step 4 では生成予定のタスク一覧をフェーズごとに示し、ユーザー承認を得た上で tasks/todo.md に出力し TodoWrite にセットします。

レビューテストドキュメント
02352026-04-07