القائمة
push 前にユーザーへ実装内容の理解度クイズを徹底出題し、全問正答 + 明示許可を得て初めて push を解禁するゲートスキル。トリガー: ship フローの quiz フェーズ到達時、または「クイズ出して」「push クイズ」「quiz me」等のユーザー指示。承認は `ship.sh quiz approve` で HEAD SHA に紐づけて記録する。
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
GitHub Pull Request のレビューコメントに一括対応する時に使う。トリガー: 「PR レビュー直して」「レビューコメント対応」「レビューフィードバック反映」「PR の指摘対応」「PR #123 のコメント対応」「review fix」「apply PR review」「address PR feedback」等のユーザー指示、または `/pr-review-fix` スラッシュコマンド、`pr-review-fix` スキル指定。未解決 (isResolved=false) スレッドを網羅収集 → 分類 → 承認付き修正計画 → 実装コミット → push → 返信 & resolve まで 7 フェーズで一気通貫。
開発フロー (計画 → ブランチ → 実装 → テスト → フォーマット → コミット → PR → Copilot レビュー → レビュー対応) を状態機械で進めるパイプラインスキル。グローバル CLAUDE.md の基本ルールにより、複数フェーズにわたる開発依頼の標準フロー。中断したフローの再開にも使う。
GitHub Pull Request を作成する時に使う。トリガー: 「PR 作って」「PR 作成」「プルリクエスト作って」「create PR」「open PR」「raise PR」等のユーザー指示、または `pr-create` スキル指定。コミット済みブランチから push 確認 → タイトル / 本文案の提示 → `gh pr create` 実行 → Copilot レビュー依頼 → 到着をバックグラウンド監視し、指摘があれば pr-review-fix へ自動接続するまでを一気通貫。コミット作成自体は担当せず、事前に commit スキル等で済ませておく前提。
Update a custom npm package managed in ~/nix-config/pkgs/ to the latest version. Edits the .nix file with the new version and hash, then rebuilds with darwin-rebuild.
Discord webhook 経由で個人チャンネルに画像を送信するスキル。リモートコントロール中の Claude がユーザーに画面状態や成果物画像を共有する用途。トリガー「画像を Discord に送って」「スクリーンショット送って」「画面を共有して」「send screenshot to discord」等のユーザー指示、または `discord-image` スキル指定。ローカルファイル / macOS スクリーンショット / 画像 URL の 3 モードに対応。
ゲームのアイデアを自律的に大量生成し、比較・評価・淘汰を繰り返して最良のアイデアを選び出すスキル。 ユーザーが明示的に「game-idea-loopを起動して」と指示すると発動する。 ユーザーが制約条件（ジャンル、プラットフォーム、テーマ等）を与えると、 それに基づいて数十のアイデアを生成→評価→淘汰のループを自動で回し、 思考の全過程をMarkdownファイルに記録する。 ゲームコンセプトのアイデア出しに特化。
| name | push-quiz |
| description | push 前にユーザーへ実装内容の理解度クイズを徹底出題し、全問正答 + 明示許可を得て初めて push を解禁するゲートスキル。トリガー: ship フローの quiz フェーズ到達時、または「クイズ出して」「push クイズ」「quiz me」等のユーザー指示。承認は `ship.sh quiz approve` で HEAD SHA に紐づけて記録する。 |
コミット済みの実装内容についてユーザーにクイズを出題し、ユーザーが内容を完全に理解し、明示的に push を許可するまで push を解禁しない。目的は push の安全確認ではなく、実装に使われた技術・設計判断をユーザーが学ぶこと。
ゲートはホスト PCmac24055 のみで有効 (他マシンでは ship の quiz フェーズが自動 skip される)。対象ホストは ship.sh の quiz_enabled() で判定している。
ship.sh quiz approve は、全問正答 + ユーザーの明示的な push 許可の両方が揃うまで絶対に実行しない。効率化・ユーザーの多忙・自明な変更を理由にした省略は禁止 (省略したい場合はユーザー自身に ship.sh skip quiz <理由> の意思を確認する)git diff の実物から出題するgit diff origin/<default>...HEAD --stat
git diff origin/<default>...HEAD
git log origin/<default>..HEAD --oneline
選別基準: 「この問題に答える過程で、ユーザーが他の場面にも応用できる技術・パターン・判断基準を学べるか？」。クイズの目的は push の安全確認ではなく学習。Yes と言えない問題は出さない。この基準を満たすなら問題数は少なくてよい (目安: 3〜8 問。数合わせのための水増し禁止)。
全ての問題は差分に実在するコード・コマンド・機能に紐づける。実装から遊離した一般論・名前付き法則・メタな抽象問題 (「この現象を説明する原則は？」等) は学習目的でも禁止。問うのは「このコードのこの部分はどう動くか / なぜこう書いたか」。
出題してよい観点 (優先順):
| 観点 | 例 |
|---|---|
| 使われた技術の仕組み | 今回使ったコマンド・言語機能・API はどういう原理で動いているか (例: git commit-tree は何をする plumbing か) |
| 設計判断とトレードオフ | なぜ A 方式でなく B 方式か。捨てた代替案と、その選択で失ったもの |
| 一般化できるパターン | この実装で使った手法は、どんな種類の問題に応用できるか (例: 承認を SHA に紐づける = content-addressable な失効管理) |
| 落とし穴と回避策 | この技術を素朴に使うとハマる罠は何で、今回どう回避したか |
| 信頼境界・限界 | 機械的に保証される範囲と、規約・運用頼みの範囲の境目はどこか |
出題禁止 (表面的な振る舞い当てクイズ):
file:line) を示して解説する全問正答後、最後に AskUserQuestion で「この内容で push を許可しますか？」を確認する。許可を得たら:
~/.claude/skills/ship/scripts/ship.sh quiz approve # 承認を HEAD SHA に記録
承認後にコミットを積み直した場合は SHA 不一致で自動失効するため、再度このスキルを実行する。