Klerith/fernando-skills

解決する問題

Claude CodeのようなLLMに「アルカノイドゲームを作って」のような広範なリクエストを与えると、それは静かに即興で対応する傾向があります—あなたの入力なしに数十の設計決定（クラスと関数、グローバルとローカルの状態、命名など）を行います。これらの決定のそれぞれは、後で元に戻すのにコストがかかります。LLMはコードを非常に速く生成するため、決定が見えなくなり、各会話が以前の選択の記憶なしに新しく始まり、同じコンテキストを手動で貼り付けるためにコンテキストを無駄にするため、問題はさらに悪化します。このプロジェクトは、仕様を中心的な成果物にすることでこれら3つすべてを解決します：明示的な決定を強制し、セッション間で永続化し、安定した参照として一度ロードします。

仕組み

このプロジェクトは、ペアとして機能する2つのClaude Codeスキルを提供します。/specスキルは、機能仕様の設計を案内します。プロジェクトのメモリファイル（CLAUDE.md、AGENTS.md、README.md）と既存の仕様を読み取り、機能が明確になるまで3〜5個のブロックで明確化質問をします。仕様をセクションごとに構築し、各部分を確認してから次に進み、最後にspecs/NN-slug.mdとしてステータスDraftで保存します。

その後、チャット外（エディタで）で仕様を再読し、手動でステータスをApprovedに変更します—これは意図的な人間の行為です。Claudeは自分の作業を承認できないためです。承認した後にのみ、/spec-implが使用可能になります。

/spec-implスキルは仕様を見つけ、ステータスがApprovedであることを検証し、gitブランチ（例：spec-03-levels-and-highscores）を作成し（別途設定がない限り）、順序付けられた計画に従って仕様を段階的に実装します。各ステップの後、差分をレビューできるように一時停止します。実装中に変更が必要な場合は、計画モードに戻って仕様を更新します—コードに直接即興で対応することは決してありません。

仕様自体はREADMEに記載されている6つの部分からなる構造に従います：一文の目標、明示的な範囲内と範囲外の項目、具体的な名前とパスを持つデータモデル、各ステップがシステムを作動状態に保つ順序付けられた実装計画、検証可能な受け入れ基準（「Escを押すとゲームが一時停止し、メニューが表示される」などのブールチェック項目）、および理由とともに行われた決定と破棄された決定の記録。

対象者

これは、Claude Code（または含まれるインストーラーを介してCursor、Codex、Antigravityなどの他のコーディングエージェント）を使用する開発者向けで、計画外のLLMコード生成の混乱を避けたい人向けです。タスクが2つ以上のファイルに触れる場合、元に戻すのにコストがかかる決定（スキーマ、形式、API）を含む場合、1つのセッションより長くかかる場合、または他の成果物によって再利用される契約を生成する場合に理想的です。些細なバグ修正、機械的なリファクタリング、探索的な実験、または単一のプロンプトに収まる一回限りのタスクには意図されていません。

ハイライト

• ペアのスキル：/spec（設計）と/spec-impl（実装）。
• 仕様はgitでバージョン管理され、永続的な設計決定ログとして機能します。
• 人間の承認が必要：実装を開始する前に、仕様のステータスをDraftからApprovedに手動で変更する必要があります。
• 各差分をレビューするための一時停止を伴う段階的な実装—巨大な400行のコミットはもうありません。
• Claude Codeを超えて：インストーラースクリプトがCursor、Codex、Antigravity用にスキルを適応させます。
• 仕様には、「うまく機能する」や「良いUX」のような曖昧なステートメントではなく、検証可能なブール値の受け入れ基準が含まれます。
• READMEからの精神的なルール：プランモードを開きたくなったら、おそらく必要です。機能の計画に退屈したら、おそらく必要ありません。