VibeCoding スタート

このスキルを使用して、最初のプロジェクトセッションからリリースと観測まで、Codexに軽量なエンジニアリングシステムを提供します。目標は、後続のセッションがチャット全体を再生することなく、理解、レビュー、検証、受け入れ、安全に継続できるプロジェクトを作ることです。

最初のアクション

プロジェクトのAGENTS.mdを読み、以下のホットコンテキスト順に従ってください：

docs/INDEX.md
docs/CURRENT.md
docs/PRODUCT.md
docs/PRD.md
docs/ACCEPTANCE.md

docs/CODEMAP.md、アクティブなADR、計画、作業ログ、標準、ローカルの未加工エビデンスは、タスクに必要な場合にのみ読んでください。6つのドキュメントのスケルトンが存在しない場合は、実装の前にコンパニオンのvibecoding-project-knowledgeスキルのINITモードを使用してください。

譲れないプロジェクト境界

すべてのプロジェクトは同じ最小スケルトンを受け取ります：AGENTS.md、docs/INDEX.md、PRODUCT.md、PRD.md、ACCEPTANCE.md、CURRENT.md、CODEMAP.md。
複雑さによってドキュメントの深さとゲートの強度は変化しますが、スケルトンは削除しません。
PRODUCT.mdは理由を説明し、PRD.mdは何を説明し、ACCEPTANCE.mdはそれを証明する方法を説明します。これらの責任を暗黙的に統合しないでください。
セッションが要件、機能、非目標、制約、または意味のあるユーザーシナリオを変更した場合は、PRD.mdを更新してください。
未加工のセッション、ログ、失敗した試行、調査、エビデンスは、デフォルトで.project-memory/の下にローカルに保持します。編集され、意図的に厳選された例のみをdocs/examples/に昇格させてください。
カスタムインフラストラクチャの前に、既存のプロジェクト機能、標準ライブラリ、公式SDK/API/ツール、成熟したオープンソースプロジェクト、パッケージ、アダプター、または構成を優先してください。
このワークフローの一部として、メモリデータベース、ベクターデータベース、検索エンジン、テストフレームワーク、デプロイフレームワーク、CIサービス、または可観測性バックエンドを構築しないでください。

エンジニアリングゲート

すべてのプロジェクトに同じ語彙を使用し、リスクに応じて深さを調整します：

G0 スコープ
→ G1 意図
→ G2 再利用
→ G3 計画
→ G4 構築
→ G5 敵対的レビュー
→ G6 検証
→ G7 人間による承認
→ G8 リリース
→ G9 観測

G0 スコープ

作業をアプリケーション/プロダクト、統合/アダプター、またはインフラストラクチャ/セキュリティ/ランタイムに分類します。インフラストラクチャに近いほど、再利用、レビュー、復旧のエビデンスを強化する必要があります。

G1 意図

チェーンを明確にします：

PRODUCT（なぜ）→ PRD（何を）→ ACCEPTANCE（証明方法）

実装前に、問題、ユーザー、現在と望ましい状態、機能要件、非目標、制約、受け入れ基準、リスクを記録します。

G2 再利用

重要でない一般的な機能については、構築する前に検索し、以下の順序で決定します：

使用 → 適応 → 構成 → 構築 → 中止

「構築」を選択した場合は、検索した代替案、拒否された再利用パス、メンテナンス責任、および所有者の受け入れ方法をADRに記録します。モデルがコードを書ける能力は、カスタムコードが正しい選択であることのエビデンスではありません。

G3 計画

複雑な作業を小さなマイルストーンに分割し、各マイルストーンの後に検証ポイントを設定します。スコープ、アーキテクチャ、またはリスクが大幅に変更された場合は、停止して再計画します。

G4 構築

実装は小さく、元に戻せるように保ちます。既存のツールチェーンを使用し、投機的な抽象化、依存関係、インフラストラクチャは避けます。

G5 敵対的レビュー

独立したレビュアーが、PRODUCT.md、PRD.md、ACCEPTANCE.md、アクティブな決定、関連する構造、差分、およびテストを精査します。抜け漏れ、誤った前提、リグレッション、重複機能、過剰設計、セキュリティ/データリスク、テストのギャップ、ロールバック障害を探します。重要な変更については、作成者が最終レビュアーになってはなりません。

G6 検証

リスクに比例して、正常系、エラー系、境界値、無効入力、リグレッション、復旧パスをカバーします。機械によるエビデンスと所有者が読める説明を報告します。緑色のチェックマークは、実際にチェックした不変条件のみを証明します。

G7 人間による承認

所有者が、結果が意図されたプロダクトであり、その観測可能な振る舞いが理解可能であることを確認します。自動チェックと独立レビューはこのステップを置き換えません。

G8 リリース

実際の使用前に、バージョン、最終正常状態、リリースノート、バックアップ、ロールバック方法、移行リスク、正確なリリースターゲットを記録します。

G9 観測

リリース後、健全性とユーザーからのエビデンスを観測します。健全な場合のみ継続し、エビデンスが問題を示した場合は停止してロールバックまたはロールフォワードします。結果を、必要に応じてテスト、作業ログ、ADR、プロダクトの意図、受け入れ、またはポストモーテムにフィードバックします。

ナレッジクローズアウト

実質的なセッションの終了時に、コンパニオンのvibecoding-project-knowledgeスキルのUPDATEモードを使用します：

未加工のセッション詳細と大きな出力をローカルの.project-memory/ディレクトリに保存します。
CURRENT.mdおよび関連するアクティブなドキュメントをキュレーションします。
構造が変更された場合はCODEMAP.mdを更新します。
要件、機能、非目標、制約、またはユーザーシナリオが変更された場合はPRD.mdを更新します。
重要な選択をADRに記録します。
インデックスと作業ログを更新します。
関連する決定論的オーディットを実行します。

機械によるエビデンス、人間が読める説明、および所有者の受け入れ方法なしに完了を主張しないでください。

参考文献

規範的なルールとリリース境界については Standard v1.3 を読んでください。
INIT、UPDATE、またはAUDIT手順については、コンパニオンのvibecoding-project-knowledgeスキルを読んでください。

VibeCoding-Start