メニュー
方針合意後の実装を自律的に進め、テストを丁寧に書き、セルフレビューを徹底するスキル。 実装タスク全般で使うこと。機能追加、バグ修正、リファクタリング、テスト追加など、 コードを書く作業が発生したら必ずこのワークフローを通す。 「実装して」「作って」「追加して」「直して」「書いて」といった依頼はもちろん、 ユーザーが方針を決めて「進めて」「お任せ」「どんどんやって」と言った場合にも使う。 確認を挟まず自律的に完成まで持っていくためのワークフロー。
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
「点と点を線にする」快感を軸にゲームデザインを設計・レビューするスキル。 人間の脳は「無関係に見えたAとBに関係性を見出した瞬間」に強い快感を得る。 伏線回収・知識アンロック・シナジー発見・隠れた関係性は全てこの派生。 「線（=AとBを結ぶ説明）はプレイヤー自身に引いてもらう設計」が核心で、 デザイナーは点を配置し、余白（=線にあたる部分）をあえて残す。 以下のような場面で使う: - 新しいゲームメカニクスを設計するとき - ストーリー・世界観・伏線を設計するとき - チュートリアル・知識提示・情報UIを設計するとき - ゲームの「面白さが弱い」「淡々としている」「アハ体験がない」と感じたとき - 既存のゲーム（cookie, factory, rpg, abyss, godfield, metropolis など）の面白さを強化する提案をするとき - 「点と線で考えて」「伏線として」「アンロックの設計」「アハ体験」といったキーワード
ゲームデザインを分析し、面白さを改善するための提案を行う。対象ゲームを指定するか、全ゲームを対象にできる。
ユーザーの発言内容だけを忠実にドキュメント化するスキル。PRD・仕様書・企画書・ 提案書など構造化ドキュメントの作成時に使う。AIが「言ってないことを勝手に補足する」 問題を防ぐためのもの。以下のような場面で必ず発動すること: "PRDを書いて", "企画書を作って", "仕様書をまとめて", "ドキュメントにして", "草案を書いて", "叩き台を作って", "提案書を書いて", "聞いた内容をまとめて", "話した内容を文書化して", "言ったことだけ書いて", "勝手に足さないで" またユーザーの口頭説明や会話からドキュメントを起こす場面でも積極的に使うこと。
| name | autonomous-dev |
| description | 方針合意後の実装を自律的に進め、テストを丁寧に書き、セルフレビューを徹底するスキル。 実装タスク全般で使うこと。機能追加、バグ修正、リファクタリング、テスト追加など、 コードを書く作業が発生したら必ずこのワークフローを通す。 「実装して」「作って」「追加して」「直して」「書いて」といった依頼はもちろん、 ユーザーが方針を決めて「進めて」「お任せ」「どんどんやって」と言った場合にも使う。 確認を挟まず自律的に完成まで持っていくためのワークフロー。 |
方針が固まったら、確認を挟まず一気に完成まで持っていく。品質はセルフレビューの反復で担保する。
ユーザーが方針に合意した後の逐次確認は、作業を中断させるだけで価値を生まない。代わりに、自分自身で何度もレビューと改善を回すことで、ユーザーの時間を奪わずに高い品質を実現する。
実装の方向性が不明確な場合のみ、ユーザーに確認する。
方針が明確なら（ユーザーが「進めて」と言っている、要件が自明、など）、この Phase はスキップして即座に Phase 2 に入る。
Phase 1 を抜けたら、以降はユーザーに確認を求めない。 完成するまで自律的に進める。
設計やUXの判断は、局所的なコードだけ見ていると的外れになる。実装に入る前に、変更が影響する範囲の全体像を掴む。
devtools（Chrome DevTools MCP）で関係する画面を渡り歩いて、現状のUIを把握する。
コードだけ読んでも、実際の見た目やユーザーの操作感は分からない。画面を見ることで「ここに追加すると狭くなる」「この色は周囲と合わない」といった判断ができる。
主要ユースケースを洗い出し、データの流れや呼び出し関係を把握する。
実装コードより先にテストを書く。テストが実装の仕様書になる。
テスト設計 - 何をテストするか洗い出す
テスト実装 - 丁寧に書く
"test" ではなく具体的な値）testing.md ルールに従うテスト実行 - 全テストがFAIL（未実装なので）することを確認
テストを通すための最小限の実装を書く。
error-handling.md, robustness.md, ts-pattern.md 等）に従うpnpm lint:fix && pnpm lint && pnpm test を実行実装が動いたら、ここから品質を磨き上げる。改善点が見つからなくなるまでレビューと修正を繰り返す。
各ラウンドで以下の観点をチェックし、問題を見つけたら即座に修正してから次のラウンドに進む。
code-intent-documentation.md）ラウンド N:
1. 変更した全ファイルを読み直す（差分ではなくファイル全体）
2. 上記7つの観点でチェック
3. 問題を発見 → 修正 → lint & test 実行
4. 修正があった → ラウンド N+1 へ
5. 修正がなかった → 最終確認へ
修正が発生しなくなるまで回す。目安は3ラウンド程度。1ラウンド目で粗い問題、2ラウンド目で細かい問題、3ラウンド目で確認、という流れになることが多い。
レビューが収束したら、最後に一度だけ全体を通して確認する。
pnpm lint:fix && pnpm lint && pnpm test
全パスを確認してから Phase 6 に進む。
完了したら、ユーザーに簡潔に報告する。
報告に含めるもの:
報告に含めないもの:
| やりがち | なぜダメか | 代わりに |
|---|---|---|
| 実装の途中で「この方針でいいですか？」 | ユーザーの時間を奪う | 方針は Phase 1 で合意済み。迷ったら自分で判断 |
| セルフレビュー1回で完了 | 最初のレビューでは構造的な問題を見落としやすい | 目安3ラウンド、収束するまで回す |
| diff だけ見てレビュー | 文脈を見失い、周辺との不整合を見逃す | ファイル全体を読み直す |
| テストを後から書く | 実装に引きずられて甘いテストになる | テストを先に書く |
| 「完了しました」だけ報告 | ユーザーが変更内容を把握できない | 何を変えたかと、レビューで直した点を簡潔に |