Back to Details

github

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

github

github

最新の規約を優先する

Prioritize the latest conventions

エージェントのメモリや過去の会話に古い手順が残っていると、同じ誤りを何度も繰り返す。
  • スキルは作業を始めるたびに入れ直す。前回読んだ内容やメモリで済ませない。
  • メモリや過去の会話の手順がスキルと食い違ったら、スキルに従う。食い違っていたメモリは、どこがどう違うかをユーザーに伝え、更新か削除を提案する。許可なしにメモリを書き換えない。
  • スキルの内容をメモリに保存しない。
  • 会話が長くなってコンテキストが要約されたら、Git の操作を続ける前にスキルを読み直す。
If outdated procedures remain in the Agent's memory or in past conversations, the same mistakes will keep being repeated.
  • Reload the Skill each time before starting work. Do not rely on previously read content or memory.
  • If instructions in memory or past conversations conflict with the Skill, follow the Skill. Tell the user specifically how they differ and propose updating or deleting the conflicting memory. Do not rewrite memory without permission.
  • Do not save the Skill's contents to memory.
  • If a long conversation's context is summarized, reread the Skill before continuing Git operations.

フロー

Workflow

パッチバグフィクス以外の実装作業は、この順で進める。
  1. Issue を起票する。
  2. Issue 番号を含む専用ブランチを作る。
  3. 実装する。
  4. PR を作る。
  5. ahead / behind とマージ可否を確認する。
  6. merge
    ラベルを付け、philtz-organizer-bot に squash でマージさせる。
判断に迷う作業はパッチバグフィクスではなく通常フローとして扱う。通常フロー対象の実装を、Issue なし、専用ブランチなし、PR なしで進めない。デフォルトブランチ上で始めない。
会社、チーム、担当領域をまたぐ変更では、影響範囲、検証内容、残リスクを Issue と PR に明記する。
Implementation work other than a patch bug fix must follow this order.
  1. Open an Issue.
  2. Create a dedicated branch containing the Issue number.
  3. Implement the changes.
  4. Open a PR.
  5. Check ahead / behind and whether the PR can be merged.
  6. Add the 
    merge
    label and have philtz-organizer-bot perform a squash merge.
When it is difficult to determine how to classify a task, treat it as the normal workflow rather than a patch bug fix. Do not proceed with implementation covered by the normal workflow without an Issue, a dedicated branch, or a PR. Do not start on the default branch.
For changes spanning multiple companies, teams, or areas of responsibility, clearly state the impact, validation performed, and remaining risks in both the Issue and the PR.

フローを省略できる場合

Cases where the workflow can be omitted

次をすべて満たすときだけ、パッチバグフィクスとして Issue の起票を省略できる。ブランチと PR は省略できない。デフォルトブランチには直接 push できないため。
  • 既存挙動の明確な不具合を直す最小差分である。
  • 仕様追加、設計変更、データモデル変更、API 契約変更、依存関係変更、権限・課金・認証の変更を含まない。
  • 変更範囲が局所的で、他チームの作業や統合予定リポジトリに影響しない。
  • Issue 化して合意形成する価値より、即時修正する価値が明らかに高い。
  • ユーザーがパッチ対応を明示している、または同等の Issue や PR の文脈が既にある。
An Issue may be omitted for a patch bug fix only when all of the following conditions are met. The branch and PR still cannot be omitted. Direct pushes to the default branch are not allowed.
  • It is a minimal diff that fixes a clear defect in existing behavior.
  • It does not include a feature addition, design change, data model change, API contract change, dependency change, or change to permissions, billing, or authentication.
  • The scope is local and does not affect other teams' work or repositories with planned integrations.
  • The value of fixing the issue immediately is clearly greater than the value of opening an Issue to establish agreement.
  • The user has explicitly requested a patch response, or equivalent Issue or PR context already exists.

開始前

Before starting

sh
git status --short --branch
git fetch --prune
  • git hook を有効にする。リポジトリに 
    .vite-hooks/
    があれば 
    git config core.hooksPath .vite-hooks
    を、
    lefthook.yaml
    しかなければ 
    lefthook install
    を実行する。どちらも clone ごとの設定なので、新しい作業環境では毎回実行する。
  • デフォルトブランチ、現在ブランチ、リモート追跡ブランチの状態を確認する。
  • 未コミット変更があれば、内容と所有者を確認する。今回の作業に無関係な変更をステージ、コミット、修正しない。
  • 現在ブランチがデフォルトブランチでなければ、今回の作業用か確認する。
  • gh など Issue や PR の操作に必要なツールや権限がなければ、不足を報告し、ローカル実装だけ先行してよいか確認する。
sh
git status --short --branch
git fetch --prune
  • Enable Git hooks. If the repository contains 
    .vite-hooks/
    , run 
    git config core.hooksPath .vite-hooks
    . If it contains only 
    lefthook.yaml
    , run 
    lefthook install
    . Each is configured per clone, so run the appropriate command every time in a new work environment.
  • Check the states of the default branch, the current branch, and remote-tracking branches.
  • If there are uncommitted changes, check their contents and ownership. Do not stage, commit, or modify changes unrelated to the current task.
  • If the current branch is not the default branch, confirm whether it is being used for the current task.
  • If the tools or permissions required for Issue or PR operations, such as gh, are unavailable, report the missing requirements and ask whether it is acceptable to proceed with local implementation only.

Issue

Issue

  • 既存 Issue があるか先に確認する。なければ実装前に作る。
  • タイトルと本文は、philtzjp/.github の 
    conventions.yml
    に従う。リポジトリに 
    .github/conventions.yml
    があれば、そちらに従う。本文は署名の行から始め、見出しを背景、作業範囲、受け入れ条件の順に書く。必要なら最後に備考を足す。
  • 背景は最初の行から箇条書きにする。影響範囲や検証方針は、作業範囲か備考に書く。
  • philtz-organizer-bot が Issue の書式を検査し、違反があれば内容をコメントにまとめるので、直す。
  • 受け入れ条件は task list（
    - [ ]
    ）で書き、達成状況を追跡できるようにする。
  • 複数会社や複数領域に影響するなら、担当境界とレビュー観点を書く。
  • 実装単位が大きすぎない粒度に分割する。
  • Issue が曖昧なまま大きな変更に着手しない。
  • Check whether an existing Issue is already present. If not, create one before implementation.
  • The title and body must follow the 
    conventions.yml
    in philtzjp/.github. If the repository contains 
    .github/conventions.yml
    , follow that file instead. The body must start with the signature line, followed by headings in this order: Background, Scope of Work, and Acceptance Criteria. Add Notes at the end if needed.
  • Format the Background as a bullet list starting on the first line. Put the impact scope and validation approach under Scope of Work or Notes.
  • philtz-organizer-bot checks Issue formatting and summarizes any violations in a comment, so correct them.
  • Write Acceptance Criteria as a task list (
    - [ ]
    ) so completion can be tracked.
  • If the work affects multiple companies or areas, state the responsibility boundaries and review perspectives.
  • Split the work into units that are not too large for a single implementation.
  • Do not begin a large change while the Issue is still vague.

ブランチ

Branch

  • Issue 番号を含む専用ブランチを作る。
  • 名前は 
    <type>/<issue-number>-<short-kebab-summary>
    。
  • type は feat、fix、refactor、docs、test、chore、ci、build のいずれか。
  • 作成前にベースブランチが最新であることを確認する。
  • 複数 Issue の実装を1ブランチに混ぜない。
  • ユーザーの確認なしにブランチを切り替えない。
  • Create a dedicated branch containing the Issue number.
  • Name it 
    <type>/<issue-number>-<short-kebab-summary>
    .
  • The type must be one of feat, fix, refactor, docs, test, chore, ci, or build.
  • Before creating the branch, confirm that the base branch is up to date.
  • Do not mix the implementation of multiple Issues in one branch.
  • Do not switch branches without the user's confirmation.

実装

Implementation

  • Issue の受け入れ条件に沿って、最小の論理単位で実装する。
  • スコープが広がったら Issue と PR の説明を更新する。必要なら別 Issue に分割する。
  • 変更に応じてテスト、Lint、型チェック、E2E、ドキュメント更新を行う。
  • レビューしづらい巨大差分を、理由なく1 PR にまとめない。
  • Implement the changes in the minimum logical units, following the Issue's Acceptance Criteria.
  • If the scope expands, update the Issue and PR descriptions. Split the work into a separate Issue if necessary.
  • Depending on the changes, run tests, Lint, type checks, E2E tests, and update documentation.
  • Do not combine an enormous diff that is difficult to review into a single PR without a reason.

コミットメッセージ

Commit messages

type: 説明
の形式。日本語の短い文にする。モノレポでは 
type(scope): 説明
にし、説明を短く保つためにカッコ表記は使わない。
type は次のいずれか。
  • feat 新機能 / fix バグ修正 / perf 性能改善 / refactor 機能変更なしの改善
  • docs ドキュメント / style スタイル修正 / test テスト / chore その他
  • ci CI/CD 設定 / build ビルド設定 / merge PR のマージ（philtz-organizer-bot が作る squash のコミット専用。人とエージェントは使わない）
scope の決め方。
  • ファイル変更のあったトップレベルディレクトリ名（リポジトリ直下のディレクトリ名）を使う。
  • Turborepo などのモノレポで apps/ や packages/ 配下を変更するなら、配下のパッケージ名やアプリ名（leaf 名）を使う。apps/dashboard なら dashboard、packages/log なら log。
  • リポジトリ全体に関わる変更は repo。
  • 隠しディレクトリは先頭のドットを含めて書く。agents ではなく .agents。
  • スラッシュで階層を表現しない。
  • apps や packages などモノレポの親ディレクトリ自体を scope にしない。
  • workspace、design のような実体のない総称や、存在しないフォルダ名を使わない。
NG: feat(workspace): / feat(design): / feat(agents): / feat(apps): / feat(apps/dashboard): / feat(packages/log):
OK: feat(repo): / feat(.agents): / feat(.claude): / feat(dashboard): / feat(log):
説明の書き方。
  • 動作で終える。〜する、〜追加、〜修正、〜削除、〜実装など。
  • 動作を伴わない名詞で終えない。
    feat(api): ユーザー認証
    ではなく 
    feat(api): ユーザー認証を追加
    。
  • emoji を含めない。
  • 論理的なスコープ（パッケージ、機能）ごとにコミットを分割する。無関係な変更を1つのコミットに混ぜない。
Use the 
type: description
format. Keep the description as a short sentence. In a monorepo, use 
type(scope): description
, and do not use parenthetical notation in the description to keep it concise.
The type must be one of the following:
  • feat: new feature / fix: bug fix / perf: performance improvement / refactor: improvement without a functional change
  • docs: documentation / style: style fix / test: tests / chore: other
  • ci: CI/CD configuration / build: build configuration / merge: PR merge. This type is only for the squash commit created by philtz-organizer-bot and must not be used by humans or Agents.
How to choose the scope:
  • Use the top-level directory name of the changed file, meaning a directory directly under the repository root.
  • In a monorepo such as Turborepo, when changing files under apps/ or packages/, use the leaf package or application name. For apps/dashboard, use dashboard; for packages/log, use log.
  • Use repo for changes affecting the entire repository.
  • Include the leading dot for hidden directories. Use .agents, not agents.
  • Do not represent hierarchy with slashes.
  • Do not use monorepo parent directories such as apps or packages themselves as the scope.
  • Do not use generic terms for things that do not exist as concrete entities, such as workspace or design, or names of folders that do not exist.
NG: feat(workspace): / feat(design): / feat(agents): / feat(apps): / feat(apps/dashboard): / feat(packages/log):
OK: feat(repo): / feat(.agents): / feat(.claude): / feat(dashboard): / feat(log):
How to write the description:
  • End with an action, such as add, fix, remove, or implement.
  • Do not end with a noun that does not express an action. Use 
    feat(api): add user authentication
    , not 
    feat(api): user authentication
    .
  • Do not include emoji.
  • Split commits by logical scope, such as a package or feature. Do not mix unrelated changes in one commit.

コミットの実行

Executing commits

  • ファイルごとに 
    git diff
    を実行し、各変更の作者を確認する。
  • git add .
    と 
    git add -A
    を使わない。
  • committer を上書きしない。常にユーザーの git config を使う。
  • Co-Authored-By
    を、コミットメッセージと PR 本文のどちらにも含めない。
すべての変更がエージェントによるもので、ユーザーが編集した行がない場合だけ、
--author
で自身のエージェント種別を明示する。
sh
git commit --author="Claude <noreply@anthropic.com>" -m "<message>"
git commit --author="Codex <noreply@openai.com>" -m "<message>"
git commit --author="Cursor Agent <cursoragent@cursor.com>" -m "<message>"
実際に動作しているエージェント種別と一致する行を使う。他エージェントの例を流用しない。一部でもユーザーによる変更があれば、通常の 
git commit
を使う。
  • commit-msg hook が未承認の 
    Co-authored-by:
    を自動付与する環境では、それを除去する hook を入れて対処する。
    git commit --no-verify
    で hook を迂回しない。
  • 履歴修正で force push が必要なら、guard の許可を一時的に有効にして push し、作業後に戻す。
  • PR の途中のコミットは squash されて main に残らない。途中のコミットのメッセージを直すためだけに、履歴を書き換えて force push しない。
  • Run 
    git diff
    for each file and verify the author of each change.
  • Do not use 
    git add .
    or 
    git add -A
    .
  • Do not override the committer. Always use the user's git config.
  • Do not include 
    Co-Authored-By
    in either the commit message or the PR body.
Use 
--author
to identify your own Agent type only when all changes were made by the Agent and no lines were edited by the user.
sh
git commit --author="Claude <noreply@anthropic.com>" -m "<message>"
git commit --author="Codex <noreply@openai.com>" -m "<message>"
git commit --author="Cursor Agent <cursoragent@cursor.com>" -m "<message>"
Use the line that matches the Agent type that is actually running. Do not copy another Agent's example. If even part of the changes was made by the user, use a normal 
git commit
.
  • If a commit-msg hook automatically adds an unapproved 
    Co-authored-by:
    trailer, add a hook that removes it and use that hook to address the issue. Do not bypass hooks with 
    git commit --no-verify
    .
  • If rewriting history requires a force push, temporarily allow the guard to permit the push and restore the guard after finishing the work.
  • Intermediate commits in a PR are squash merged and do not remain on main. Do not rewrite history and force push solely to correct the message of an intermediate commit.

author と committer

Author and committer

GitHub は、コミットに記録されたメールアドレスで、どのアカウントの変更かを判断する。名前は判断に使わない。登録していないアドレスでコミットすると、アイコンが灰色になり、誰の変更か追えなくなる。author と committer のアドレスは別々に判断されるので、片方だけ灰色になることもある。
最初にコミットする前に、設定を確認する。
sh
git config --show-origin user.name
git config --show-origin user.email
env | grep -E '^GIT_(AUTHOR|COMMITTER)_'
  • user.email が未設定か、
    root@...
    、
    ...@localhost
    、
    ....local
    のような自動生成のアドレスなら、コミットしない。ユーザーに状況を伝え、設定を相談する。
  • リポジトリ単位の設定や環境変数がグローバル設定を上書きしていないか、
    --show-origin
    の出力で確かめる。CI、Docker、devcontainer、クラウドのエージェント環境では、設定が入っていないことが多い。
  • ユーザーの許可なしに git config を書き換えない。
  • どのアドレスを使うか迷っていたら、GitHub が発行する noreply アドレスを提案する。必ずアカウントに紐づき、個人のアドレスを公開せずに済む。
    gh api user --jq '"\(.id)+\(.login)@users.noreply.github.com"'
    で取得できる。
rebase、cherry-pick、
commit --amend
では、author はそのまま残り、committer は実行した環境の設定に置き換わる。実行したあとは両方を確認する。
sh
git log --format='%h author=%an <%ae> committer=%cn <%ce>' -10
push したあとは、GitHub 上でアカウントに紐づいたかを確認する。null の側が灰色のアイコンになっている。
sh
gh api repos/<owner>/<repo>/commits/<sha> --jq '{author: .author.login, committer: .committer.login}'
灰色になっていたら、原因と直し方をユーザーに説明する。使ったアドレスを GitHub の Settings → Emails に追加して確認を済ませれば、過去のコミットにもさかのぼって紐づく。履歴を書き換えて直そうとしない。
GitHub uses the email address recorded in a commit to determine which account made the change. It does not use the name for this purpose. If a commit uses an address that is not registered, its avatar appears gray and the contributor can no longer be identified. The author and committer addresses are evaluated separately, so either one may appear gray.
Before the first commit, check the configuration.
sh
git config --show-origin user.name
git config --show-origin user.email
env | grep -E '^GIT_(AUTHOR|COMMITTER)_'
  • If user.email is unset or is an automatically generated address such as 
    root@...
    , 
    ...@localhost
    , or 
    ....local
    , do not commit. Explain the situation to the user and discuss the appropriate configuration.
  • Use the output of 
    --show-origin
    to check whether repository-specific settings or environment variables are overriding global settings. These settings are often absent in CI, Docker, devcontainer, and cloud Agent environments.
  • Do not modify git config without the user's permission.
  • If unsure which address to use, propose a GitHub-issued noreply address. It must be linked to the account and avoids exposing a personal address. It can be obtained with 
    gh api user --jq '"\(.id)+\(.login)@users.noreply.github.com"'
    .
During rebase, cherry-pick, and 
commit --amend
, the author is preserved while the committer is replaced with the configuration of the environment performing the operation. Check both after execution.
sh
git log --format='%h author=%an <%ae> committer=%cn <%ce>' -10
After pushing, verify on GitHub that the commits are linked to the account. The icon for the null side appears gray.
sh
gh api repos/<owner>/<repo>/commits/<sha> --jq '{author: .author.login, committer: .committer.login}'
If either icon is gray, explain the cause and the remedy to the user. Add the address used to GitHub's Settings → Emails and complete the verification; this can retroactively link past commits as well. Do not attempt to fix the problem by rewriting history.

Git 操作の安全確認

Git operation safety checks

あらゆる Git 操作（コミット、プッシュ、ブランチ作成、マージ、リベース）の前に 
git fetch --prune
を実行する。そのうえで確認する。
  • 現在のブランチがデフォルトブランチにマージ済みでないか。済みなら警告してブランチの切り替えを提案する。
  • リモート追跡ブランチがまだ存在するか。削除されていれば警告する。
  • ローカルブランチがリモートより遅れていないか。遅れていれば 
    git pull --rebase
    を提案する。
  • リモートと乖離していないか。乖離していれば警告し、リベースかマージを提案する。
ユーザーの承認なしに 
git pull
や 
git rebase
を実行しない。確認なしにローカルブランチを削除しない。
Before every Git operation, including commits, pushes, branch creation, merges, and rebases, run 
git fetch --prune
and then perform the following checks.
  • Check whether the current branch has already been merged into the default branch. If it has, warn the user and suggest switching branches.
  • Check whether the remote-tracking branch still exists. If it has been deleted, warn the user.
  • Check whether the local branch is behind the remote. If it is, propose 
    git pull --rebase
    .
  • Check whether the local branch and remote have diverged. If they have, warn the user and propose either a rebase or a merge.
Do not run 
git pull
or 
git rebase
without the user's approval. Do not delete a local branch without confirmation.

PR

PR

sh
gh pr create --body "<本文>"
gh pr create --body-file <file>
  • 本文を必ず明示する。
    --fill
    やエディタ生成で 
    Co-Authored-By
    が混入し得る場合は使わない。
  • タイトルと本文は、philtzjp/.github の 
    conventions.yml
    に従う。リポジトリに 
    .github/conventions.yml
    があれば、そちらに従う。
  • タイトルは 
    type(scope): 説明
    にする。説明はそのまま main のコミットの件名になる。
  • 本文は署名の行から始め、見出しを背景、作業範囲、受け入れ条件、影響範囲・残リスクの順に書く。必要なら最後に備考を足す。
  • 対象 Issue を自然言語で参照する。本文の背景に 
    #<issue-number>
    を書く。
  • Closes #N
    などの自動クローズのキーワードを使わない。Issue はマージ後に手で閉じる。
  • philtz-organizer-bot が PR を開いたとき、編集したとき、push したときに書式を検査し、
    organizer-bot/conventions
    のステータスを付ける。違反があれば内容をコメントにまとめるので、直す。
  • 作成前にローカルブランチを upstream へ push する。
  • Draft で早めに作り、実装完了後に Ready for review へ切り替える。
  • レビュー、CI、必要な検証を迂回してマージしない。
sh
gh pr create --body "<body>"
gh pr create --body-file <file>
  • Always provide the body explicitly. Do not use 
    --fill
    or an editor-generated body if it may introduce 
    Co-Authored-By
    .
  • The title and body must follow the 
    conventions.yml
    in philtzjp/.github. If the repository contains 
    .github/conventions.yml
    , follow that file instead.
  • Format the title as 
    type(scope): description
    . The description becomes the subject of the commit on main.
  • The body must start with the signature line, followed by headings in this order: Background, Scope of Work, Acceptance Criteria, and Impact and Remaining Risks. Add Notes at the end if needed.
  • Refer to the target Issue in natural language. Write 
    #<issue-number>
    in the Background section of the body.
  • Do not use auto-closing keywords such as 
    Closes #N
    . Close the Issue manually after the merge.
  • When philtz-organizer-bot opens or edits a PR, or when a push occurs, it checks the formatting and adds the 
    organizer-bot/conventions
    status. If there are violations, it summarizes them in a comment, so correct them.
  • Push the local branch to its upstream before creating the PR.
  • Create the PR as a Draft early, then switch it to Ready for review after implementation is complete.
  • Do not merge while bypassing reviews, CI, or required validation.

マージ前チェック

Pre-merge checks

sh
git fetch --prune
git status --short --branch
  • ローカルブランチが upstream に対して ahead / behind / diverged していないこと。
  • PR ブランチがベースブランチに対して behind していないこと。
  • PR が mergeable で、コンフリクトがなく、必須の CI、レビュー、チェックが通っていること。
  • organizer-bot/conventions
    のステータスが成功していること。
対処。
  • ahead なら push して再確認する。
  • behind か diverged なら、ユーザーに報告し、rebase / merge / pull の方針を確認してから同期する。
  • PR ブランチがベースブランチに対して behind なら、ベースブランチを取り込んで検証を再実行する。
  • コンフリクト、失敗した CI、未解決レビュー、未確認の ahead / behind があるならマージしない。
sh
git fetch --prune
git status --short --branch
  • The local branch must not be ahead, behind, or diverged from its upstream.
  • The PR branch must not be behind the base branch.
  • The PR must be mergeable, have no conflicts, and have all required CI, reviews, and checks passing.
  • The 
    organizer-bot/conventions
    status must have succeeded.
How to respond:
  • If it is ahead, push and check again.
  • If it is behind or diverged, report the situation and confirm whether to rebase, merge, or pull before synchronizing.
  • If the PR branch is behind the base branch, integrate the base branch and rerun validation.
  • Do not merge if there are conflicts, failed CI checks, unresolved reviews, or unconfirmed ahead / behind states.

マージ

Merge

人とエージェントはマージしない。デフォルトブランチには誰も直接 push できず、画面のマージボタンも使えない。マージは philtz-organizer-bot だけが行う。
直前にもう一度 
git fetch --prune
と ahead / behind の確認を行い、PR に 
merge
ラベルを付ける。
sh
gh pr edit <番号> --add-label merge
philtz-organizer-bot は、次をすべて満たすときだけ squash でマージする。
  • PR が開いていて、Draft でない。
  • タイトルと本文が規約に合っている。
  • ブランチがデフォルトブランチに追いついている。
  • 必須の検査が通り、ruleset が求める承認がある。ラベルを付けたのが org の owner なら、承認は確かめない。
main に残るのは 1 PR につき 1 つのコミットで、件名は 
merge(scope): 説明
になる。説明は PR のタイトルから取り、scope は変更したファイルから bot が決める。本文は付かない。author は PR を出した人、committer は philtz-organizer-bot で、
(#N)
と 
Co-authored-by
は付かない。
  • gh pr merge
    を使わない。
  • merge プレフィクスでマージであることは明示されるので、PR のタイトルの説明に「マージ」と書かない。
    feat(api): foo をマージ
    ではなく 
    feat(api): foo を追加
    。
  • 条件を満たさなければ、bot が理由をコメントしてラベルを外す。直してからラベルを付け直す。
  • ラベルを付けて 1 分たってもマージもコメントもされなければ、ラベルを外して付け直す。
Neither humans nor Agents perform merges. No one can push directly to the default branch, and the merge button in the UI cannot be used. Only philtz-organizer-bot performs merges.
Immediately before merging, run 
git fetch --prune
again, check ahead / behind, and add the 
merge
label to the PR.
sh
gh pr edit <number> --add-label merge
philtz-organizer-bot performs a squash merge only when all of the following conditions are met:
  • The PR is open and is not a Draft.
  • The title and body comply with the conventions.
  • The branch is up to date with the default branch.
  • All required checks pass and the ruleset's required approval has been granted. If the person who added the label is the org owner, approval does not need to be verified.
Only one commit per PR remains on main, with the subject 
merge(scope): description
. The description is taken from the PR title, and the bot determines the scope from the changed files. There is no commit body. The author is the person who opened the PR, and the committer is philtz-organizer-bot. Neither 
(#N)
nor 
Co-authored-by
is added.
  • Do not use 
    gh pr merge
    .
  • Because the merge prefix already indicates that the commit is a merge, do not write "merge" in the PR title's description. Use 
    feat(api): add foo
    , not 
    feat(api): merge foo
    .
  • If the conditions are not met, the bot comments with the reason and removes the label. Correct the problem and then reapply the label.
  • If one minute passes after applying the label without either a merge or a comment, remove the label and apply it again.

マージ後

After merging

  • 対象 Issue は自動では閉じないので、
    gh issue close <番号>
    で閉じる。
  • リモートの作業ブランチはマージで自動的に消える。ローカルのブランチは、ユーザーの意図を確認してから消す。
  • マージ、レビュー、検証を保留する場合や解決が pending の場合は、Issue をクローズせず、保留（pending review）として状況と再開条件をコメントに残す。重複起票を防ぐため。
  • 未解決の同一事象について Issue を重複起票しない。
  • 同一事象で複数の Issue が起票・クローズされていたら、最古の Issue を親（正本）として sub-issue 関係を付け、後発を duplicate としてクローズし、変更内容を各 Issue にコメントする。
  • The target Issue is not closed automatically, so close it with 
    gh issue close <number>
    .
  • The remote work branch is removed automatically by the merge. Delete the local branch only after confirming the user's intent.
  • If the merge, review, or validation is on hold, or if a resolution remains pending, do not close the Issue. Leave the status and conditions for resumption in a comment as pending review. This prevents duplicate Issues.
  • Do not open a duplicate Issue for the same unresolved incident.
  • If multiple Issues have been opened or closed for the same incident, use the oldest Issue as the canonical parent, establish a sub-issue relationship, close the later Issues as duplicates, and comment the changes on each Issue.

Issue コメント

Issue comments

進み具合、完了、対応できないこと、設計のメモを Issue に残すときの書き方。GitHub はコメントにテンプレートを当てないので、次の形で書く。
markdown
✳︎ <会社名> <モデル名> <バージョン>
Use the following format when recording progress, completion, anything that cannot be handled, or design notes in an Issue. GitHub does not apply a template to comments, so use this structure.
markdown
✳︎ <company-name> <model-name> <version>

背景

Background

このコメントの論点を書く。実装の状況、調べた結果、前提の変化など。
State the purpose of this comment here. Include the implementation status, investigation results, changes in assumptions, and so on.

作業範囲

Scope of Work

  • 行ったこと、調べた範囲、これからの対応
  • What was done, what was investigated, and how it will be handled next

受け入れ条件

Acceptance Criteria

  • 受け入れ条件 1。満たし方と、確かめたコマンドと結果
  • 受け入れ条件 2。満たせない理由と制約
  • Acceptance criterion 1. How it was met, plus the commands checked and their results
  • Acceptance criterion 2. Why it cannot be met and any constraints

備考

Notes

補足、関連する Issue や PR。なければ見出しごと消す。

- 署名の行は Issue や PR の本文と同じ。モデル名がバージョンを含むとき（GPT-5.5 など）は `<バージョン>` を省く。
- 主観ではなく、確かめられる事実、根拠、制約で書く。
- scope は Issue のタイトルが表すので、コメントには書かない。
- 受け入れ条件は Issue の項目ごとに、満たしたか、満たせないかを書く。
- 対応できないことを記録するときと、レビューやマージを保留するときは、Issue を閉じない。保留なら理由と再開の条件を書く。
- 重複として閉じたときは、正本にした最古の Issue と、duplicate にしたことを備考に書く。
Supplementary information and related Issues or PRs. If there is none, remove the entire heading.

- The signature line is the same as in Issue and PR bodies. If the model name includes the version, such as GPT-5.5, omit `<version>`.
- Write verifiable facts, evidence, and constraints rather than subjective statements.
- The scope is already represented by the Issue title, so do not include it in the comment.
- For each Acceptance Criterion in the Issue, state whether it has been met or cannot be met.
- When recording something that cannot be handled, or when review or the merge is on hold, do not close the Issue. If it is on hold, state the reason and the conditions for resumption.
- When closing an Issue as a duplicate, mention the canonical oldest Issue and the duplicate status in Notes.

Release

Release

GitHub Release のリリースノートの書き方。GitHub は Release にテンプレートを当てないので、次の形で書く。
  • 署名を付けない。署名を付けるのは、Issue と PR の本文とコメントだけ。
  • tag は 
    v<セマンティックバージョン>
    、リリース名は 
    <リポジトリ名> v<バージョン>
    にする。
  • 主観ではなく、変わった事実と制約で書く。
  • 配布物を添付するときは、ダウンロードのリンクを実際の tag の URL にする。
markdown
<リポジトリ名> v<バージョン> は、<前のバージョン> からの変更を 1〜2 文でまとめる。
GitHub does not apply a template to Release notes, so use the following format.
  • Do not add a signature. Signatures are used only in Issue and PR bodies and comments.
  • Use 
    v<semantic-version>
    for the tag and 
    <repository-name> v<version>
    for the release name.
  • Write verifiable facts about what changed and any constraints rather than subjective statements.
  • When attaching distributable artifacts, make the download link point to the actual tag URL.
markdown
<repository-name> v<version> summarizes the changes from <previous-version> in 1–2 sentences.

変更内容

Changes

<機能追加などの分類>

<category, such as feature addition>

  • <変更>
  • <change>

制約

Constraints

  • <制約>
  • <constraint>

インストール

Installation

  1. <手順>
  1. <step>

更新手順

Upgrade Instructions

  1. <手順>
  1. <step>

備考

Notes

補足、既知の問題、pre-release にした理由など。なければ見出しごと消す。

当てはまらない見出しは消してよい。
Supplementary information, known issues, the reason for making it a pre-release, and so on. If there is none, remove the entire heading.

Remove any headings that do not apply.