ai-artist

Codex 互換性に関する注意：

• Codex では $skill-name を使ってリポジトリのスキルを呼び出します。このミラー版では、従来の Claude の /skill-name 参照を書き換えています。
• タスクトラッカーの必須事項：ワークフローまたはスキルのステップを実行する前に、すべてのステップについてタスクの追跡を作成または更新し、進捗に応じて同期を保ってください。
• ユーザーへの質問を促すプロンプトは、Codex でユーザーに直接質問することを意味します。
• Claude 固有のモード切り替え指示があっても無視してください。
• 厳格な実行契約：ユーザーがスキルを明示的に呼び出した場合、そのスキルのプロトコルに記載されたとおりに実行してください。
• サブエージェントの認可：ユーザーが呼び出したスキル、または AI が検出したスキルのプロトコルでサブエージェントが必要な場合、そのスキルの有効化により、そのタスクに必要な spawn_agent サブエージェントの使用が認可されます。
• ユーザーが事前に逸脱を明示的に承認しない限り、プロトコルのステップを省略、並べ替え、統合しないでください。
• ワークフロースキルでは、記載されている子スキルの各ステップを明示的に実行し、ステップごとの根拠を報告してください。
• 必須のステップやツールをこの環境で実行できない場合は、適応する前に停止してユーザーに確認してください。

Codex プロジェクト参照ドキュメントの読み込み（フックなし）

Codex では、Claude のフックによるドキュメントの自動挿入は行われません。 コーディング、計画、デバッグ、テスト、レビューを行う際は、以下のルーティングに従ってプロジェクトのドキュメントを明示的に開いてください。

必ず読むドキュメント：

• docs/project-config.json（プロジェクト固有のパス、コマンド、モジュール、ワークフロー／テストの設定）
• docs/project-reference/docs-index-reference.md（完全な docs/project-reference/* カタログへの案内）
• docs/project-reference/lessons.md（常に適用されるガードレールとアンチパターン）

状況に応じて読むドキュメント：

• バックエンド／CQRS／API／ドメイン／エンティティの変更：backend-patterns-reference.md、domain-entities-reference.md、project-structure-reference.md
• フロントエンド／UI／スタイリング／デザインシステム：frontend-patterns-reference.md、scss-styling-guide.md、design-system/README.md
• 仕様／テストケースの計画、または TC のマッピング：feature-docs-reference.md
• 統合テストの実装／レビュー：integration-test-reference.md
• E2E テストの実装／レビュー：e2e-test-reference.md
• コードレビュー／監査作業：code-review-rules.md と、変更ファイルに応じた上記のドメイン関連ドキュメント

すべてのドキュメントをむやみに読む必要はありません。まず docs-index-reference.md を読み、次にタスクに関連するファイルだけを開いてください。

クイックサマリー

目標： AI のテキスト、画像、動画生成モデル（Claude、GPT、Midjourney、DALL-E、Stable Diffusion、Flux、Veo）向けのプロンプトを作成し、最適化します。

ワークフロー：

1. 特定 — モデルの種類（LLM、画像、動画）と望ましい成果を判断します
2. 構成 — モデルに特化したプロンプトパターンを適用します（LLM には Role／Context／Task、画像には Subject／Style／Composition）
3. 改善 — A/B テスト、スタイルキーワード、ネガティブプロンプトを使って反復します

主なルール：

• 明確さ、コンテキスト、構造、反復を基本原則として活用します
• モデル固有の構文を適用します（Midjourney の --ar、SD の重み付きトークンなど）
• 分野ごとの詳細なガイダンス（マーケティング、コード、執筆、データ）には、参照ファイルを読み込みます

懐疑的な姿勢を保ってください。批判的思考と段階的な思考を適用してください。すべての主張には追跡可能な根拠と信頼度の割合が必要です（アイデアは 80% を超える必要があります）。

AI Artist - プロンプトエンジニアリング

AI テキストおよび画像生成モデルに効果的なプロンプトを作成します。

基本原則

1. 明確さ — 具体的にし、曖昧さを避けます
2. コンテキスト — シーン、役割、制約を最初に設定します
3. 構造 — 一貫した形式（Markdown、XML タグ、区切り文字）を使います
4. 反復 — 出力に基づいて改善し、バリエーションを A/B テストします

クイックパターン

LLM プロンプト（Claude/GPT/Gemini）

[Role] You are a {expert type} specializing in {domain}.
[Context] {Background information and constraints}
[Task] {Specific action to perform}
[Format] {Output structure - JSON, markdown, list, etc.}
[Examples] {1-3 few-shot examples if needed}

画像生成（Midjourney/DALL-E/Stable Diffusion）

[Subject] {main subject with details}
[Style] {artistic style, medium, artist reference}
[Composition] {framing, angle, lighting}
[Quality] {resolution modifiers, rendering quality}
[Negative] {what to avoid - only if supported}

例：Portrait of a cyberpunk hacker, neon lighting, cinematic composition, detailed face, 8k, artstation quality --ar 16:9 --style raw

参考資料

詳しいガイダンスを確認するには、以下を読み込んでください。

トピック	ファイル	説明
LLM	references/llm-prompting.md	システムプロンプト、少数ショット、CoT、出力形式
画像	references/image-prompting.md	スタイルキーワード、モデル構文、ネガティブプロンプト
Nano Banana	references/nano-banana.md	Gemini の画像プロンプト、物語調のスタイル、複数画像入力
高度な手法	references/advanced-techniques.md	メタプロンプト、連鎖、A/B テスト
ドメイン索引	references/domain-patterns.md	汎用パターン、ドメイン別ファイルへのリンク
マーケティング	references/domain-marketing.md	見出し、製品コピー、メール、広告
コード	references/domain-code.md	関数、レビュー、リファクタリング、デバッグ
文章作成	references/domain-writing.md	ストーリー、登場人物、会話、編集
データ	references/domain-data.md	抽出、分析、比較

モデル別のヒント

モデル	主な構文
Midjourney	--ar、--style、--chaos、--weird、--v 6.1
DALL-E 3	自然言語、パラメーターなし、HD 品質オプション
Stable Diffusion	重み付きトークン (word:1.2)、LoRA、ネガティブプロンプト
Flux	自然なプロンプト、スタイルの組み合わせ、--guidance
Imagen/Veo	描写的なテキスト、アスペクト比、スタイル参照

アンチパターン

• 曖昧な指示（「もっとよくして」）
• 制約の矛盾
• ドメイン固有のタスクに必要なコンテキストの不足
• 冗長な詳細を含めた過剰なプロンプト
• モデル固有の強みや限界を無視すること

---

[IMPORTANT] 作業を始める前に、タスク管理を使ってすべての作業を小さなタスクに分解してください。各ファイルを読む作業も含めます。これにより、長いファイルによるコンテキストの喪失を防げます。簡単なタスクの場合、AI は必ずユーザーにスキップするかどうかを尋ねてください。

AI のミス防止 — すべてのタスクで回避すべき失敗パターン：

削除する前に、後続の参照を確認してください。 コンポーネントを削除すると、ドキュメントやコードに古い情報が連鎖的に残ります。削除する前に、参照しているすべてのファイルを特定してください。 AI が生成した内容を実際のコードと照合してください。 AI は API、クラス名、メソッドのシグネチャを捏造することがあります。ドキュメントに記載したり参照したりする前に、必ず grep で存在を確認してください。 編集後は依存関係をすべてたどってください。 定義を変更しても、そこから派生する後続の変数や利用箇所を見落とすことがあります。必ず依存関係を最後までたどってください。 正しさを確認するときは、すべてのコードパスをたどってください。 コードが存在することを確認しても、実行されることを確認したことにはなりません。正常系だけでなく、早期リターン、エラー分岐、条件によるスキップも必ずたどってください。 デバッグ時は、修正する前に「どの層の責任か」を確認してください。 不具合が呼び出し元（誤ったデータ）にあるのか、呼び出し先（誤った処理）にあるのかをたどってください。責任を持つ層で修正し、症状が現れる箇所だけにパッチを当てないでください。 既存の値には意図があると考え、変更する前に理由を確認してください。 定数、上限、フラグ、パターンを変更する前に、コメントを読み、git blame を確認し、周辺のコードを調べてください。 最初の出力だけでなく、影響を受けるすべての出力を確認してください。 複数のスタックにまたがる変更では、すべての出力を検証する必要があります。チェックが1つ成功しても、すべてのチェックが成功したことにはなりません。 全体を先に見るデバッグ — 目先の原因に飛びつかないでください。 失敗を調査するときは、まず前提条件をすべて列挙してください（設定、環境変数、DB 名、エンドポイント、DI 登録、データの前提条件）。その後、コード層の仮説を立てる前に、それぞれを根拠と照らして確認してください。 外科的な変更 — 差分テストを適用してください。 不具合修正では、変更する各行が不具合に直接関係している必要があります。周辺コードのスタイル変更や改善はしないでください。機能強化タスクでは、改善を実装し、その内容を明示してください。 コーディング前に曖昧さを明らかにし、黙って決めないでください。 依頼に複数の解釈がある場合は、それぞれの作業量の見積もりを示して質問してください。全レコード対象、ファイルベース、またはより複雑な方法を、決めつけて選ばないでください.

批判的思考の姿勢 — 批判的思考と順序立てた思考を適用してください。実行に移す各主張には、たどって確認できる根拠と80％を超える確信度が必要です。 ハルシネーション防止： 推測を事実として述べないでください。すべての主張に根拠を示し、不確実性を率直に認め、出力に誤りがないか自分で確認し、独立して相互参照し、自分の確信度にも懐疑的でいてください。根拠のない確信こそ、あらゆるハルシネーションの根源です。

必ず注意： 批判的思考を適用してください。実行に移す各主張には、たどって確認できる根拠と80％を超える確信度が必要です。ハルシネーションを防ぐため、推測を事実として述べないでください。

必ず注意： AI のミス防止策を適用してください。全体を先に見るデバッグ、責任を持つ層での修正、コーディング前の曖昧さの明示、コンパクション後のファイル再読を徹底してください。

最後に確認すること

• 必須・重要・必ず注意 作業を始める前に、タスク管理を使って作業を小さな ToDo タスクに分解してください
• 必須・重要・必ず注意 新しいコードを作成する前に、コードベース内の類似パターンを3つ以上検索してください
• 必須・重要・必ず注意 実行に移す各主張に file:line 形式の根拠を示してください（確信度は80％超）
• 必須・重要・必ず注意 作業品質を検証するための最終レビュー用 ToDo タスクを追加してください

[TASK-PLANNING] 作業に取りかかる前に、タスクの範囲を分析し、タスク管理を使って小さな ToDo タスクとサブタスクに体系的に分解してください。

フックなしプロンプトプロトコルのミラー（自動同期）

ソース：.claude/hooks/lib/prompt-injections.cjs + .claude/.ck.json

[WORKFLOW-EXECUTION-PROTOCOL] [BLOCKING] ワークフロー実行プロトコル — 必須・重要・厳守。いかなる理由があっても省略しないでください。

汎用的な移植性の境界： 再利用可能なスキルとプロトコルのテキストはプロジェクトに依存しないものとします。プロジェクト固有の規約は、docs/project-config.json と docs/project-reference/ から確認してください。shared/sdd-artifact-contract.md の共通 AI-SDD を適用します。docs/project-config.json と docs/project-reference/docs-index-reference.md を読み、そこに記載されているプロジェクト参照ドキュメントを開いてください。この共通コンテキストとローカルドキュメントを利用できる場合は、サポートされている任意の AI ツールで実行できます。

1. 検出： プロンプトをワークフローカタログと照合します
2. 分析： 最適なワークフローを見つけ、カスタムのステップ構成のほうが適しているかどうかも評価します
3. 確認（必須形式）： ユーザーが明示的にワークフロー／スキルを呼び出し、かつローカルプロトコルで明示的な呼び出しを確認とみなす場合を除き、次の構成でユーザーに直接質問します
   • 質問："どのワークフローを有効にしますか？"
   • 選択肢 1："[最適なワークフロー] を有効にする（推奨）"
   • 選択肢 2："カスタムワークフローを有効にする：[step1 → step2 → ...]"（1 行で理由を記載）
4. 有効化（確認後）： 標準ワークフローの場合は $workflow-start <workflowId> を呼び出し、カスタムステップの場合は手動で順に実行します
5. タスクを作成： ワークフローのすべてのステップについてタスク追跡を行います
6. 実行： 各ステップを順番に実行します [CRITICAL-THINKING-MINDSET] 批判的思考と段階的思考を適用します。すべての主張には追跡可能な根拠が必要であり、確信度が 80% を超える場合にのみ行動します。 ハルシネーション防止の原則： 推測を事実として提示しないでください。すべての主張に出典を示し、不確実な点は率直に認め、出力に誤りがないか自己確認し、独立した情報源と照合し、自分の確信を疑ってください。根拠のない確信こそが、あらゆるハルシネーションの根本原因です。 AI の注意力に関する原則（初頭効果・新近効果）： 長いプロンプト／プロトコルでは、指示の順守が長いコンテキストウィンドウでも保たれるよう、最も重要な 3 つのルールを冒頭と末尾の両方に配置します。 目標主導の実行： まず成功基準を定義し、検証が完了するまで繰り返し、観察可能なチェックに合格した場合にのみ終了します。 テストで意図を検証： テストでは、現在の挙動をなぞるだけでなく、ビジネスルール／不変条件を保護し、保護対象の意図が損なわれた場合に失敗するようにします。

[LESSON-LEARNED-REMINDER] [BLOCKING] タスク計画と継続的改善 — 必須。省略しないでください。

作業を始める前に、作業を小さなタスクに分割し、タスク追跡を行います。最後のタスクとして「AI のミスと教訓を分析する」を追加します。

教訓の抽出 — 症状への対処ではなく、根本原因のみ：

1. 症状ではなく、失敗モード（推論／前提の誤り）を特定します。「誤った列挙値を使った」ではなく、「ソースを読まずに API が存在すると仮定した」とします。
2. 一般性を検証します。この失敗モードは 3 つ以上のコンテキスト／コードベースに当てはまりますか？ 当てはまらない場合は、抽象度を 1 段階上げます。
3. 普遍的なルールとして記述します。プロジェクト固有の名前／パス／クラスを除き、どのコードベースでも役立つ内容にします。
4. 統合します。同じ失敗モードを共有する複数のミスは、1 つの教訓にまとめます。
5. 再発判定：「この注意書きがなければ、今後のセッションで再発するか？」いいえの場合は $learn を省略します。
6. 自動修正判定：「$code-review／$code-simplifier／$security／$lint で検出できるか？」はいの場合は、代わりにレビュー用スキルを改善します。
7. 両方の判定を通過した場合： $learn を実行するようユーザーに依頼します。 [TASK-PLANNING] [MANDATORY] ワークフローまたはスキルのステップを実行する前に、予定されているすべてのステップのタスク追跡を作成／更新し、各ステップの開始時と完了時に内容を同期してください。