プロンプトライブラリ

GitHubのプロンプト

GitHub ワークフロー向けのプロンプト:プルリクエストの説明、Issue のトリアージ、マージ済みの変更からのリリースノート。

プロンプト本体は、作成・テストした言語である英語です。これらのページの説明と案内文は翻訳されています。

  • pull requests
  • code review
  • documentation
100/100 · 154 トークン

プルリクエストの説明

diff からプルリクエストの説明を書きます:何が変わったか、なぜか、どうテストするか。

使う場面: 変更を終え、レビュアーがすべての行を読まなくても動ける説明がほしいとき。

prompt
You are a senior software engineer writing a pull request description.

## Task
Write a pull request description for the diff below.

## Requirements
- Describe only changes present in the diff.
- Explain why the change was made using the context provided; write "reason not provided" when the context does not say.
- List the steps a reviewer follows to test the change.
- Name any migration, configuration change, or breaking change.
- Keep the whole description under 250 words.

## Output format
Return markdown with four sections: Summary (2 sentences), Changes (bulleted list), How to test (numbered list), and Notes for reviewers (bulleted list).

## Input
<diff>
{{diff}}
</diff>

<context>
{{context}}
</context>

変数

{{diff}}
ブランチの git diff の出力。
{{context}}
変更の元になった Issue または理由。

入力例

diff: adds a retry wrapper around the payment client and a config value PAYMENT_MAX_RETRIES.
context: payments fail when the provider returns 503.

出力例

## Summary
Retries payment requests that fail with 503. The retry count is configurable.

## Changes
- Add `withRetry` in payment/client.ts
- Add `PAYMENT_MAX_RETRIES` (default 3)

## How to test
1. Set the provider mock to return 503 twice...

例示です。期待される形を示すために書いたもので、モデルが生成したものではありません。

  • release notes
  • changelog
  • documentation
100/100 · 162 トークン

マージ済みプルリクエストからのリリースノート

マージされたプルリクエストを、ソフトウェアの利用者向けに書かれたリリースノートにまとめます。

使う場面: リリースを切り、プルリクエストのタイトル一覧を利用者が読めるノートにしたいとき。

prompt
You are a maintainer writing release notes for users of the project.

## Task
Write release notes from the list of merged pull requests below.

## Requirements
- Group entries under Added, Changed, Fixed, and Removed.
- Rewrite each entry to say what changed for the user, in one sentence.
- Keep the pull request number at the end of each entry.
- Put breaking changes first under a "Breaking changes" heading, with the action users must take.
- Leave out entries that only change tests, tooling, or internal refactoring.

## Output format
Return markdown with one heading per group that has entries and a bulleted list under each. Do not include empty groups.

## Input
<version>
{{version}}
</version>

<pull_requests>
{{pull_requests}}
</pull_requests>

変数

{{version}}
リリースするバージョン番号。
{{pull_requests}}
マージされたプルリクエスト。1 行に 1 つ、番号とタイトル付き。

入力例

version: 2.4.0
pull_requests: #412 feat: add CSV export; #415 fix: crash on empty project; #418 chore: bump eslint.

出力例

## Added
- Export any report as a CSV file. (#412)

## Fixed
- Opening a project with no items no longer crashes the app. (#415)

例示です。期待される形を示すために書いたもので、モデルが生成したものではありません。

自分用に調整する

要件を自分の基準に合わせて編集し、結果をチェックしましょう。プロンプトアナライザーは入力に合わせて再採点し、オプティマイザーは要件を落とさずに冗長な表現を削り、セキュリティスキャナーはモデルに送る前に秘密情報や個人データを検出します。

その他のカテゴリ