メニュー
パッチバグフィクス以外の実装作業を行うときに必ず参照する。Issue 起票、専用ブランチ作成、実装、PR 作成、同期状態確認、ahead/behind がない場合のみマージする標準フローを定義する。巨大モノレポ、複数会社・複数人で同時実装する状況、機能追加、仕様変更、リファクタリング、設計変更、依存関係変更、DB/API/UI/アーキテクチャ変更で使用する。
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
ユーザーの暗黙知を対話で引き出すとき（傾聴、インタビュー、曖昧な回答の具体化、過去の意思決定の掘り下げ、前提への挑戦、矛盾の統合、動機の引き出し、思考の精緻化）に参照する。Rogers 傾聴・DICE プロービング・CDM・悪魔の代弁者・弁証法的探究・動機づけ面接 OARS・ナラティブ引き出し・ソクラテス式質問の 8 技法を統合し、場面に応じた選択ガイドと共通ルールを定義する。
既存スキルに従って作業しても期待通り進まないとき、Web 検索などで異なる情報・より新しい情報が得られたとき、スキルの条件分岐を厳守するとスタックや実装の自由度が制限され最良の結果が得られないと判断したときに参照する。`.agents/skills/<name>/SKILL.md` をローカルで改変する手順、および改変内容が有用と判断した場合に `philtzjp/skills` リポジトリへ変更提案 Issue を起票する手順とテンプレートを定義する。
新規パッケージの追加、`turbo.json` / `pnpm-workspace.yaml` / `tsconfig` の編集、`apps/` や `packages/` の構成変更、責務パッケージ（`log` / `error` / `prompt` / `env` / `db`）の配置・参照を行うときに参照する。Turborepo + pnpm のベストプラクティス、`workspace:*` プロトコル、JIT コンパイル方針を定義する。
コミット、プッシュ、ブランチ作成/切り替え/削除、マージ、リベース、`gh pr merge` による PR マージなどあらゆる Git / GitHub 操作を行うときに参照する。コミットメッセージのフォーマット (`type(scope): 説明`)、マージコミット件名 (`merge(scope): 説明`) の `--subject` / `--body ""` 指定、`--author` の扱い、`git fetch --prune` などの安全チェック、マージコミット件名・本文への PR/Issue 番号 (`#N`) 禁止、`Co-Authored-By` 禁止、`git add .` 禁止などを定義する。
日本語で文章を書く・編集する・レビューする・返信する際に参照する。英語（特にスラング・口語・技術用語）の直訳による不自然な日本語、体言止めの乱用、「〜どうぞ」「〜まで。」などの訳語調を検出し、自然な日本語に直す。コミットメッセージ、PR 説明、ドキュメント、UI 文言、ユーザーへの日本語応答を含む。
API エンドポイントの設計・実装・変更を行うとき（OpenAPI スキーマ、ヘルスチェック、ルーティング、認証方式の追加など）に参照する。OpenAPI 準拠、RFC 9457 エラー、パスバージョニング、認証（ネットワーク公開 API は Bearer、loopback サービスは Origin 検証で代替可）、Spectral リント、単一 HTTP フレームワーク（Hono / Nitro 等から選定）への統一を定義する。
| name | issue-branch-pr-flow |
| description | パッチバグフィクス以外の実装作業を行うときに必ず参照する。Issue 起票、専用ブランチ作成、実装、PR 作成、同期状態確認、ahead/behind がない場合のみマージする標準フローを定義する。巨大モノレポ、複数会社・複数人で同時実装する状況、機能追加、仕様変更、リファクタリング、設計変更、依存関係変更、DB/API/UI/アーキテクチャ変更で使用する。 |
commit-and-git スキルも併用する以下のすべてを満たす場合のみ、パッチバグフィクスとしてこのフローを省略できる:
git status --short --branch で作業ツリー、現在ブランチ、upstream 状態を確認するgit fetch --prune を実行する- [ ] チェックボックス）で記述し、各条件の達成状況を追跡・チェック可能にする<type>/<issue-number>-<short-kebab-summary> にするtype は feat、fix、refactor、docs、test、chore、ci、build のいずれかにする#<issue-number> を記載する）; MAY: Issue の自動クローズが必要な場合のみ、英語キーワード（Closes #<issue-number> 等）の使用、または PR 作成時に GitHub の Development で Issue をリンクする方法を明示的に選択する; NEVER: 英語以外の同義表現（例: 「#N をクローズする」）で自動クローズを期待しない（自動クローズは英語キーワード + #N でのみ発火する）gh pr create --body "<本文>" または gh pr create --body-file <file> を使用し、PR 本文を明示するCo-Authored-By を含めない。--fill やエディタ生成により Co-Authored-By が混入する可能性がある場合は使用しないgit fetch --prune を再実行するgit status --short --branch でローカルブランチが upstream に対して ahead / behind / diverged していないことを確認するgit fetch --prune と ahead / behind 確認をもう一度行うgh pr merge <番号> --merge --subject "merge(scope): 説明（日本語、短い文）" --body "" で件名と空の本文を明示する; NEVER: デフォルトのマージコミットメッセージ（Merge pull request #N from ...）を使用しない; NEVER: 件名・本文に PR 番号（#N）や Issue 番号など参照を含めない; NEVER: merge プレフィクスでマージであることが明示されるため、説明文に「マージ」と書かない（NG: merge(api): foo をマージ → OK: merge(api): foo を追加）gh issue close <番号> で手動クローズする