開発開始ガイドライン

https://kickoff.jujin.dev/ai/startup/v1.md と https://kickoff.jujin.dev/ai/instructions.md を読み、サービスの要件と制約から企画を始めてください。確定済みの判断と既存の権限を維持してください。バージョン管理システムとリポジトリホスティングも計画に含め、既存の選択を維持して未決定事項だけを検討してください。カタログ記事は私が依頼した場合や判断の理解に役立つ場合だけ参照してください。 不確実性・依存関係・変更リスク・共同作業・引継ぎ・既存の方法・導入費用から、追加のエージェントスキルや作業ツールが必要か判断してください。追加スキルなし、Spec Kit、適切な代案を比較し、適合性と利点・欠点を説明してください。私が選択を受け入れるか委任したら、既存の導入許可の範囲で必要な構成だけを外部AIエージェントに導入・設定し、利用可能か検証してから対応する方式で呼び出してください。既存の導入と記録を再利用してください。ツールを使えなければ手動の次の手順と未検証の事項を伝えてください。 ユーザーが決める未決定事項は、現実的な選択肢・利点と欠点、要件と制約に基づく推薦案を添えて質問してください。「推薦どおりに任せます」と委任したら、その文脈の範囲で聞き直さず判断・記録し、既存の許可範囲で進め、内部実装は自分で処理してください。採用したプロジェクト基準をMarkdownチェックリストとして維持し、変更前に関連項目を読み、変更後に実際の結果を検証してください。詳細はAI行動規則に従ってください。大きな作業は作業ファイルを更新し、単位ごとに保存・検証して検証通過後に既存の禁止規則を守って自動でローカルコミットしてください。リモート操作やリポジトリ・書込みツールがない場合は指示に従ってください。完了・中断時は実際の成果、適用したデザイン・構成と主要な判断の理由・トレードオフ、ユーザー確定と委任された判断の区別、検証、作業文書の場所、保存・コミット状態、残作業を報告してください。

目的と適用範囲

開発開始ガイドライン、provided by kickoff by jujin。ガイドライン: v1。リビジョン: 8。更新日: 2026-10-08。英語が原文で、日本語・韓国語は原文リビジョン8に対応します。

サービスの案を合意済みの計画に変えます。本書は情報収集と企画を、AI行動規則は質問・委任・根拠・作業記録・コミット・報告を扱います。開始時に必須のサイト文書はこの二つだけです。既存のプロジェクト指示・確定済みの判断とともに適用します。ユーザーの言語で答え、上位の指示を優先します。

1. サービスの背景を集める

版・リビジョンと二つの文書を読めたかを短く報告します。どちらかを取得できなければURLを伝え、本文の提供を求めるか再試行します。未読の規則を適用済みとは言わず、集められる背景情報の収集は続けます。

提供済みの回答は再利用し、不足する入力をまとめて聞きます。

• サービス・アプリ名: 提供された仮称を使うか未定とします。確定名を勝手に作りません。
• サービスの説明: 誰が使い、どんな主な行動をし、どんな結果を求めるかを聞きます。粗い一文から始めて構いません。対象、MVP、対象外、測定可能な成功条件を具体化してから構成を推薦します。
• 参考事項: 優先事項と既知の制約を聞きます。既存システム・デザイン、連携、機微データ、アクセシビリティ、予算、日程、チーム、プラットフォーム、運用のうち関連する項目を扱います。「なし」「まだ不明」も可能です。空欄は制約なしではなく追加確認の対象です。秘密情報は求めません。

説明は会話の出発点で、完成した仕様ではありません。追加質問は小さな関連グループで行い、専門用語はそのサービスの例で説明します。

2. プロジェクトで必要な判断を導く

要件と制約から判断の一覧を導き、依存順に進めます。サイトへの掲載に関係なく、アーキテクチャ・道具・視覚デザイン・運用方式を検討します。プロジェクトへの適合性で同等に評価します。カタログの分類別検討表、完全な索引、各分類から一つずつ選ぶ手順は求めません。両立する選択は組み合わせられます。

バージョン管理を計画に含めます。変更履歴の必要性を確認し、バージョン管理システムとリポジトリホスティングを区別し、要件が変更を裏付けない限り既存の選択を維持します。オフライン作業、共同作業・レビュー、ファイルの特性、連携、アクセス権・公開範囲、費用、運用・バックアップの責任を比較します。GitとGitリポジトリホスティングは併用でき、新規アカウントや公開リポジトリを前提としません。選んだ組合せと理由、または保留・対象外の理由を記録します。既存リポジトリの所有権・アクセス権・許可範囲を尊重します。

ユーザーが決める未決定事項には 自分で選ぶ / 推薦を受ける / この範囲を委任 / 対象外 / 保留 を提示します。行動規則に従い、現実的な選択肢・利点と欠点、要件と制約に基づく推薦案を添えて質問します。「推薦どおりに任せます」はその文脈の選択の委任です。聞き直さず判断・記録し、既存の許可範囲で進めます。迷っている場合は一貫した組合せを提案し、不明や沈黙を委任と解釈しません。保留・対象外には理由と再検討条件を残します。許可範囲内の内部実装は自分で処理します。

カタログは任意の学習資料です。ユーザーが指定した場合や判断の理解を助ける場合に特定の記事を参照し、引用前に読みます。llms.txt・catalog.json・分類ページ・リンク先の全記事の取得は必須ではありません。任意の資料を取得できないことだけを理由に企画を止めません。根拠の不足は行動規則に従って扱います。

3. ソフトウェアの境界を計画する

合意した選択の範囲内で、モジュールの責任、依存方向、ドメイン・データの所有、公開契約、外部境界、復旧の担当を定めます。プロジェクトの規模において、合意した要件と品質基準を満たす最も単純なアーキテクチャを選びます。

SOLID・GRASPをプログラミング方式に合わせて使い、凝集した責任、低い結合度、依存方向、明確な契約を検討します。これらは堅実な実装と将来の保守を支える判断基準であり、必須の層・パターン・クラスの一覧ではありません。具体的な責任、リスクのある境界、根拠のある保守上の必要性がある場合だけ抽象化やサービスを追加し、その利点と費用を説明します。推測による複雑さを避け、オブジェクト指向や特定のアーキテクチャを強制しません。

入力検証、認可、秘密情報管理、データの寿命、復旧可能な失敗、運用の可視性を必要に応じて計画します。合意した予算・停止時間・復旧・運用責任から、ビルド・テスト・リリース・互換性・ロールバック・保守の手順を導きます。検証を要件とリスクの高い境界に結びます。

4. ユーザー体験を計画する

主な利用の流れ、情報階層、ナビゲーション、レイアウト、書体、色・間隔、部品、操作を必要に応じて定義します。継承するデザイン制約を尊重します。初期・読込中・空・成功・エラー・無効・復旧状態を含めます。

画面幅ごとの読み順、ラベル、キーボード操作、見えるフォーカス、コントラスト、代替テキスト、動きの低減を計画します。WebはWCAG 2.2 AAを目標に適用する検証を定め、ネイティブはプラットフォーム指針を含めます。未検証で準拠を宣言しません。見た目は主な作業を支えるものです。

読みやすい内容、明確な階層、一貫した部品とフィードバック、サービスに合う個性を備えた視覚体系を作ります。重要なデザインの選択は、スタイル名だけでなく利用者の作業・使いやすさ・既存の制約を根拠に説明します。デザインの具体化の程度をプロジェクトの規模に合わせます。

5. 必要な収益化と運用を計画する

収益化が目標かを確認します。目標なら、誰がどの価値に支払うか、価格と無料・有料の範囲、関連する収益・運用費の仮定、決済の責任を定めます。収入とともに転換率・継続率・利用者の信頼を考慮します。該当する場合は明確な価格・広告の案内、購入状態、決済失敗、解約、返金、サポートを計画します。代案を比較し、仮定と確認済みの提供者の条件・法的要件を区別して根拠の規則に従います。無料・非商用サービスには有料モデルを強制せず、関連する資金源・持続的な運用の制約を記録します。

6. 必要に合うAI作業方式を選ぶ

スキルや作業ツールを推薦する前に、不確実性、依存関係、変更リスク、共同作業、引継ぎ、既存の方法、導入・保守の費用を評価します。規模だけでは判断しません。既存の方法が十分な大きいプロジェクトでも、追加スキルなしで始める選択を同等に検討します。小さい変更でもリスクが高ければ体系的な手順が必要な場合があります。

サイト内外から関連する選択肢だけを比較します。例えば、Spec Kitは仕様から実装までの追跡、Superpowersは繰り返せる開発スキル、OpenSpecは変更提案と仕様の差分の記録が必要な場合に検討します。これは適合性の仮説であり、品質の順位や必須の導入一覧ではありません。利点、手順の費用、互換性、再検討条件を説明します。採用済みのツールを維持し、重なる作業方式を組み合わせる前に役割と記録の所有を定めます。

採用・委任された判断、許可済みの導入、有効化・呼出し、使えないツールはAI行動規則に従います。選んだ方式の成果物を計画・作業・採用基準の記録に再利用し、必須の内容と確認を保ち、競合する文書を作りません。

7. 計画を提示してから開発する

プロジェクトの規模に合わせてAIが計画を作成します。

• 提供された名前・説明・背景、番号付き要件、MVPと対象外、測定可能な完了条件。
• 関連する製品・ソフトウェア・デザイン・収益化・運用の判断と代案・理由・仮定・影響・再検討条件。提案・採用・却下・置換・保留の状態、判断の担当、正確な委任範囲。
• 採用したプロジェクト基準、適用範囲、確認方法を記したMarkdownチェックリスト。AI行動規則に従って維持・確認します。
• リスク、未確定の質問、阻害事項、依存順の作業一覧、要件に結び付けた検証計画。
• 版・リビジョンと実際に参照した資料だけを記録。カタログ取得日・記事ID一覧・カタログの複製は必須ではありません。

計画全体を示して承認を受けます。開発を妨げる判断を解決し、妨げない保留事項も明示します。計画承認と明示的な開発依頼後に開発します。既存の承認と開発権限はその範囲で有効なので、聞き直さず実行します。企画や企画の委任だけでは開発・デプロイ・公開・支出は許可されません。

大きな作業では行動規則に従い、作業ファイルの更新、再開時の確認、単位ごとの保存・検証、既存の禁止規則を守った自動ローカルコミットを行います。完了・中断時には実際の成果、適用したデザイン・構成と主要な判断の理由・トレードオフ、判断の担当、検証、作業文書の場所と保存・コミット状態、残る事項と次の作業を報告します。

8. 共同で改善する

表現、不足する話題、反例、翻訳をIssueやPRで提案できます。任意の貢献ガイドに例・シナリオ検討・版管理規則があります。今回の正式公開前の改善はv1リビジョン8とし、既存のv1/latest URLとAPI schemaVersion 1は変えません。本書はAIを案内しますが、遵守は保証しません。