file-pr

PR の作成

作成する前に、このブランチの PR がすでに存在するか確認してください。

git fetch origin <base> を実行し、変更内容を git diff origin/<base>...HEAD で確認してください。ローカルのベースブランチがリモートより遅れていると、無関係なコミットが説明に含まれることがあります。

PR のタイトルと本文はアメリカ英語で記述してください。リポジトリに GLOSSARY.md がある場合は、そこに記載されたドメイン用語を使用してください。

タイトルが $conventional-commits スキルに従っていることを確認してください。変更の重要性が伝わる、簡潔で人が読みやすいタイトルを優先してください。

悪い例

❌ perf(server): negotiate permessage-deflate on the websocket

良い例

✅ perf(server): cut websocket frame size by 70%+ with gzipping

本文の冒頭では、ユーザーの最初のプロンプトに基づいて問題を簡潔に説明し、その後、解決策を手短に説明してください。実装内容の列挙から始めないでください。

悪い例

❌ Removed implicit workspace carry-over from every "new thread" entry point (cmd+n / cmd+shift+o, sidebar v1/v2 buttons, command palette). New threads inherit only the project from context; branch, worktree, and env mode always come from the configured defaults. Delete buildContextualThreadOptions, startNewThreadInProjectFromContext, and the v1 sidebar's seed-context machinery.

良い例

✅ My "new worktree" default was ignored when starting new threads on existing worktrees. Super unintuitive. Now your preferences always apply.

この本文構成のうち該当するセクションを、以下の順序どおりに使用してください。プレースホルダーはすべて置き換え、内容のないセクションは省略してください。git ls-files .github/pull_request_template.md がパスを出力する場合は、そのテンプレートに記入し、以下のセクションをテンプレート内に配置してください。

## 📝 Summary

<Explain the problem, then the solution in plain language. This should be short, concise, and human-readable.>

<Visual of the change, see "Summary visual">

## ✅ Verification

- **Before:** <screenshot/output/failing test run>
  **After:** <screenshot/output/passing test run>

## 🔍 Reviews

| Review   | Found   | Fixed   |
| -------- | ------- | ------- |
| <review> | <count> | <count> |

<If any finding remains unfixed, name it and explain why.>

## 🔗 Issues

<Write "Closes #123" for every ticket the PR closes.>

## 💥 Merge danger

**Door:** <one-way or two-way>

<optional: description>

**Blast Radius:** <one-word description>

<optional: potential ramifications of merge>

## ⚠️ Needs attention

<List follow-up work, known limitations, or other issues that need the user's attention.>

実行したレビューは、何も見つからなかったレビューも含め、すべて列挙してください。実行していないチェックやレビューを実行したと主張しないでください。

概要を示す図

要点が明確になる最小限の図を選んでください。

• ロジックやアルゴリズムは擬似コードで示します。

on(save)
  if content is unchanged
    return cached result
  write new content
  return fresh result

• 実行時の制御フローは呼び出しツリーで示します。

submitForm
  createSession
    persistPrompt
    launchAgent
  navigateToSession

• UI の構造は、重要な状態とモジュール境界を含めてコンポーネントツリーで示します。

<SessionPage> (apps/example/src/routes/session.tsx)
  useSessionEvents()
  <SessionToolbar>
    <RunSkillButton> (packages/ui)

• ファイルの役割や大規模なリファクタリングは、簡潔なファイルツリーで示します。

src/
├── commands/       # parses user actions
├── sessions/       # owns session state
└── transport/      # sends API requests

• コンポーネント間のやり取り、制御フロー、データフローは Mermaid で示します。

sequenceDiagram
    participant User
    participant UI
    participant Daemon
    User->>UI: choose command
    UI->>Daemon: send expanded prompt
    Daemon-->>UI: stream result

• 要点が変更箇所にあり、周辺の構造がすでに存在する場合は diff を使用します。トピックに合った diff の形式にしてください。

コンポーネントの変更の場合：

 <SessionPage>
   useSessionEvents()
   <SessionToolbar>
+    <RunSkillButton />
   <SessionTimeline>
+    <SkillResultCard />

ファイル構成の変更の場合：

 src/
 ├── commands/
+│   └── show-me.ts       # expands the slash command
 ├── sessions/
-└── transport.ts
+└── transport/
+    ├── client.ts
+    └── stream.ts

呼び出しツリーやコールスタックの変更の場合：

 submitForm
   createSession
     persistPrompt
+    expandSkillMention
     launchAgent
-  navigateToSession
+  navigateToSession
+    subscribeToEvents

状態や制御フローの変更の場合：

 on(save)
-  write content
+  if content is unchanged
+    return cached result
+  write new content
+  invalidate cache

• 変更の大半が新規の内容である場合、省略したコンテキストによって所有関係や順序が分からなくなる場合、またはユーザーがそのままコピーできる形を必要としている場合は、ブロック全体を示します。

function expandSkill(command: string): string {
  const skillName = command.slice(1);
  return `use the ${skillName} skill`;
}

図は、それを補足する短い説明のすぐ近くに配置してください。ユーザーの現在の質問や、現在の議論の論点を解決するために必要な呼び出し、ファイル、プロパティ、状態、境界だけを残してください。

この中から 1 つ使っても、複数使ってもかまいません。すべてを使うことはまずないでしょう。判断を働かせ、ユーザーに情報を詰め込みすぎないようにしてください。

検証

変更が機能することを示す具体的な証拠を提示してください。変更前と変更後を示してください。

スクリーンショットは最上位の証拠です。環境が整っていて、変更が視覚的なものである場合は、必ずスクリーンショットを使ってください。画像はリンクではなく、必ず本文内に表示してください。

実行に基づく証拠は次点です。テスト結果やコンソール出力などを示してください。擬似コードを使い、失敗していたテストがどのように成功するようになったか、正確に示してください。

マージ時のリスク

変更が一方向のドアか、双方向のドアかを説明してください。双方向のドアは元に戻せますが、一方向のドアは元に戻せません。ロールバックが容易な PR はリスクが低くなります。破壊的な操作や、元に戻すのが難しい判断を伴う変更は一方向のドアです。

影響範囲とは、この PR で導入される変更が及ぼす可能性のある範囲です。あらゆる可能性を考慮してください。例として、レイアウトのずれ、利用者向け機能の破損、モバイル対応への影響などがあります。

作成

ドラフトではなく、実際の PR を作成してください。ユーザーが CI のスキップを依頼し、該当するラベルが存在する場合は、PR に skip-ci と skip-deploy のラベルを追加してください。