mcpField
P
pr-open

pr-open

github.com/bklit開発1.8k646 回インストール今日更新
リポジトリ

pr-open について

bklit-ui の変更をマージ可能な PR に整えるための、エンドツーエンドのワークフロースキルです。Git の安全対策、コミット、検証、レジストリ再構築、ビルド、PR 作成を扱います。

主な機能

  1. 01変更内容とブランチ状況の確認
  2. 02Git の安全規則に沿ったステージングとコミット
  3. 03lint の実行とレジストリ再構築
  4. 04本番ビルドの検証
  5. 05依頼時のプッシュと PR 作成

活用シーン

  1. 01マージ可能な PR に向けた変更の準備
  2. 02レジストリと本番ビルド成果物の検証
  3. 03依頼に応じたコミットと PR 作成

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/bklit/bklit-ui --skill pr-open

インストール後、Claude Code で/pr-openを入力して読み込まれたか確認します。

詳細

PR オープンスキル

bklit-ui で作業をコミットし、マージ可能な PR を作成するためのエンドツーエンドのワークフローです。

ユーザーが変更の追加、コミット、検証、プッシュ、PR の作成を求めている場合、または @pr-open に言及している場合に、このスキルを読んでください。

開始前

  1. ブランチの状況を確認する

    • ユーザーがこのブランチで以前の PR をマージしており、新しい変更がある場合は、古いフィーチャーブランチに積み重ねるのではなく、最新の main からブランチを作成します。 
      git fetch origin main
git checkout -b <new-branch-name> origin/main
    • 意図した変更だけを再適用するか、チェリーピックしてください。無関係な registry:build の変更（例：編集が意図的な場合を除き、再フォーマットされた packages/ui/registry/examples/*）はコミットしないでください。

  2. シークレットは絶対にコミットしないでください — .env、認証情報、API キーなどは除外してください。ユーザーがそれらのコミットを求めた場合は警告してください。

  3. Git の安全対策（必須）

    • git config を更新しないでください。
    • ユーザーが明示的に依頼しない限り、破壊的なコマンド（push --force、reset --hard）を実行しないでください。
    • ユーザーが明示的に依頼しない限り、フックをスキップしないでください（--no-verify）。
    • ユーザーの git ルールにある amend の条件をすべて満たさない限り、git commit --amend を実行しないでください（HEAD のコミットが自分のもので、プッシュされていない場合、またはユーザーが amend を依頼した場合）。
    • フックが原因でコミットに失敗した場合は、問題を修正して新しいコミットを作成してください。失敗したコミットを amend しないでください。
    • コミットメッセージには HEREDOC を使用してください（下記参照）。
    • ユーザーがプッシュまたは PR 作成を依頼していない限り、プッシュしないでください。

ステップ 1 — 変更を確認する

リポジトリのルートから並行して実行します。

git status
git diff
git diff --staged
git log -5 --oneline

PR を作成する場合は、ベースブランチとの差分も確認します。

git fetch origin main
git log origin/main..HEAD --oneline
git diff origin/main...HEAD --stat

何を変更したかだけでなく、なぜ変更したのかを説明するコミットメッセージを作成します。最近のリポジトリのスタイル（例：feat(charts): …、fix(web): …）に合わせてください。

ステップ 2 — ステージングとコミット（コミット前のループ）

ステージング
git add <paths>   # prefer explicit paths over blind git add -A
コミット
git commit -m "$(cat <<'EOF'
<subject line>

<optional body — 1–2 sentences on why>
EOF
)"

Husky のコミット前フックで npx ultracite fix が実行されます（.husky/pre-commit を参照）。

コミット前フックが失敗する、またはステージングされていない修正が残る場合
  1. フックの出力を読み、報告された問題をすべて修正します（lint の正確性、ネストされた三項演算子、正当な場合に限る biome-ignore など）。
  2. 影響を受けたファイルを再ステージングします：git add <paths>
  3. 新しいコミットで再度コミットします（または、amend の条件を満たし、直前のコミットが成功していてフックがファイルを自動変更した場合に限り amend します）。

git commit が成功し、git status がクリーンになる（フックによるフォーマット変更が残っていない）まで繰り返します。

ステップ 3 — リポジトリのルートから Ultracite を実行する

コミットがクリーンになったら、ルートの pnpm スクリプトを実行します（単発の修正を行う場合を除き、npx ultracite を直接実行しないでください）。

pnpm lint          # ultracite check

チェックに失敗した場合：

pnpm lint:fix      # ultracite fix (same as pnpm format)

続いて、次の手順を実行します。

  1. git diff を確認し、予期しない変更がないか調べます。
  2. ファイルに変更があった場合：git add <paths> → git commit -m "$(cat <<'EOF' Fix lint issues from ultracite EOF )"
  3. 修正が保留されていない状態でチェックに合格するまで、pnpm lint を再実行します。

pnpm lint が失敗している場合や、lint の修正がステージングされていない場合は、PR を作成しないでください。

ステップ 4 — shadcn レジストリを再ビルドする（必須）

本番ビルドの前に、すべての PR で必ず実行してください。packages/ui に変更がない場合も同様です。apps/web/public/r/ のレジストリアーティファクトは、コミット済みの UI パッケージと同期されている必要があります。

リポジトリのルートから実行します。

pnpm registry:build

これにより、packages/ui から apps/web/public/r/ が更新されます（packages/ui/package.json の registry:build を参照）。

  1. ビルド後に git diff を確認します。apps/web/public/r/ にある意図的な変更は含めてください。
  2. 編集が意図的な場合を除き、packages/ui/registry/examples/* の付随的な再フォーマットはコミットしないでください。
  3. apps/web/public/r/（または編集した場合は packages/ui/registry.json）に変更があった場合：
git add apps/web/public/r packages/ui/registry.json
git commit -m "$(cat <<'EOF'
chore(registry): rebuild shadcn registry for PR
EOF
)"
  1. public/r/ 以外のソースファイルが変更された場合は、ステップ 3（pnpm lint）を再実行します。

レジストリの出力が古いまま（registry:build の実行後に apps/web/public/r/ の差分が未コミットの状態）では、PR を作成しないでください。

ステップ 5 — ビルドをテストする

PR を作成する前に、本番ビルドを実行して型エラーやコンパイルエラーを検出します。

デフォルト（モノレポ全体）：

pnpm build

Web アプリのみ（変更が apps/web に限られる場合は高速です）：

cd apps/web && pnpm build

開発環境や CI に近い環境で Web ビルドが OOM になる場合は、ヒープを増やして再試行します：

cd apps/web && NODE_OPTIONS='--max-old-space-size=8192' pnpm build

TypeScript に変更を加えた場合は、任意ですが推奨：

pnpm check-types
ビルドに失敗した場合
  1. 根本原因（型、インポート、レジストリファイルの不足など）を修正します。
  2. 成功するまで、失敗したコマンドを再実行します。
  3. 内容が明確なメッセージで修正をコミットし、packages/ui 配下のソースファイルを変更した場合は、ステップ 3（pnpm lint）とステップ 4（pnpm registry:build）を再実行します。

ステップ 6 — プッシュする

ユーザーがプッシュまたは PR の作成を依頼した場合のみ実行します：

git push -u origin HEAD

ブランチがすでにプッシュされていて、コミットを追加した場合は、git push だけで十分です。

ステップ 7 — PR を作成する

リポジトリのルートから GitHub CLI を使用します：

gh pr create --title "<PR title>" --body "$(cat <<'EOF'
## Summary

- <bullet: what changed and why>
- <bullet: user-facing impact>
- <bullet: follow-ups or deploy notes if any>

## Test plan

- [ ] `pnpm lint` passes at repo root
- [ ] `pnpm registry:build` run; `apps/web/public/r/` committed if updated
- [ ] `pnpm build` (or `apps/web` build for web-only changes)
- [ ] <manual verification step 1>
- [ ] <manual verification step 2>

EOF
)"

PR の URL をユーザーに返します。

PR タイトルのガイドライン
  • 短く、命令形で、対象範囲を明確にします（例：Add @bklit/chart-animation registry item）
  • 可能であれば、主なコミットの件名に合わせます
PR 本文のテンプレート（毎回この構成を使用）
## Summary

- <1–3 bullets: what and why>

## Test plan

- [ ] `pnpm lint` passes at repo root
- [ ] `pnpm registry:build` run; registry outputs committed if changed
- [ ] Production build succeeds (`pnpm build` or scoped web build)
- [ ] <feature-specific check>
- [ ] <regression check if applicable>

必要に応じて、追加のセクションを含めます：

  • Context — マージ済みの PR または issue へのリンク（例：「#70 のフォローアップ」）
  • Deploy notes — 例：Open in v0 で利用するには、レジストリ JSON を ui.bklit.com に反映する必要があります
リポジトリ固有の PR に関する注意事項
  • Registry：ステップ 4 では必ず pnpm registry:build を実行します。ビルドによって更新された場合は、apps/web/public/r/ をコミットします。
  • 禁止事項：意図的な変更でない限り、registry:build による packages/ui/registry/examples/* の付随的な整形変更をコミットしないでください。
  • チャートやドキュメントの作業：該当する場合は、ドキュメントページ、Studio、または Open in v0 の手動確認について記載します。

チェックリスト全体（クイックリファレンス）

ステップコマンド／アクション次のステップに進む前に満たす条件
1git status / git diff / git log対象範囲を把握する
2git add → git commitプリコミットフックが成功し、作業ツリーがクリーンである
3pnpm lint → 必要に応じて pnpm lint:fix → 再コミットpnpm lint が終了コード 0 で終了する
4pnpm registry:build → 変更があれば apps/web/public/r/ をコミット古いレジストリ差分がない
5pnpm build（TS に変更があれば pnpm check-types も実行）ビルドが終了コード 0 で終了する
6git push -u origin HEADユーザーがプッシュ／PR を依頼した場合のみ
7Summary + Test plan を含めて gh pr createPR の URL を返す

よくある失敗

失敗対処方法
プリコミット時の Biome エラーコードを修正します。biome-ignore は、1 行で理由を説明できる場合にのみ追加します
フックがファイルを修正したが、コミットはすでに成功しているgit add して新しいコミットを作成します（許可されている場合は amend でも可）
コミット後に pnpm lint が失敗するpnpm lint:fix を実行し、差分を確認してコミットした後、pnpm lint を再実行します
レジストリの利用側で Can't resolve './animation' が発生する不足している @bklit/* レジストリ依存関係を追加し、pnpm registry:build を実行します
Web ビルドが OOM になるapps/web のビルドで NODE_OPTIONS='--max-old-space-size=8192' を指定します
PR ブランチがすでにマージされているorigin/main から新しいブランチを作成し、新しい変更のみを再適用します

フローの例

ユーザー：「これをコミットして PR を作成して」

  1. git status + git diff + git log -3
  2. git add apps/web packages/ui → git commit（成功するまでプリコミットの問題を修正）
  3. pnpm lint → 必要に応じて pnpm lint:fix → コミット → pnpm lint
  4. pnpm registry:build → 変更があれば apps/web/public/r/ をコミット
  5. pnpm build（成功するまで修正）→ 必要に応じてコミット
  6. git push -u origin HEAD
  7. Summary + Test plan のテンプレートを使って gh pr create
  8. PR のリンクと、検証した内容を一行で返信

コメント

Markdown 対応