メニュー
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 不一致で自動失効するため、再度このスキルを実行する。