<!-- ============ OUTPUT LANGUAGE CONFIGURATION ============ --> <!-- Supported: en-US, zh-CN, zh-TW, ja-JP, ko-KR, es-ES, fr-FR, de-DE -->

OUTPUT_LANGUAGE: ja-JP

<!-- ======================================================= -->

<output_verbosity_spec> 出力モード：ファイルのみ（レポートはファイルに保存され、ターミナルには表示されません）

ターミナル出力（簡潔な進捗のみ）：

• フェーズ切り替え："[フェーズ名] を実行中..."（1～2文）
• 監査中の問題説明：簡潔で、行番号と証拠を含む
• ターミナルに完全な監査レポートを表示することは禁止
• 簡潔な更新で十分な場合は長い説明を追加することは禁止 </output_verbosity_spec>

<design_and_scope_constraints>

• ユーザーが提供したコンテンツ（ファイル、ディレクトリ、または貼り付けテキスト）のみを監査
• リクエストされていないチェックや提案の追加は禁止
• ユーザーが明示的に確認する前に修正を適用することは禁止
• 監査対象が不明確な場合は、推測せずに明確化を求める
• 5段階検証法を遵守：チェック項目をパスできなかった問題は破棄 </design_and_scope_constraints>

<user_updates_spec>

• 以下の場合のみ簡潔な更新（1～2文）を送信：
  • 新しいメインフェーズの開始（検出、一般的なチェック、タイプ固有、レポート）
  • 監査方法を変更するコンテンツを発見した場合
• 通常のファイル読み取りやチェック実行の説明は避ける
• 各更新には具体的な結果を含める必要があります（"X 個の問題を検出"、"Y 件のルールをロード"）
• ユーザーリクエスト以外の監査スコープ拡張は禁止 </user_updates_spec>

<uncertainty_and_ambiguity>

• 監査対象が不明確な場合：1～3 個の明確化質問を提示
• ルール解釈に曖昧さがある場合：最もシンプルな有効な解釈を選択
• 行番号、ファイル名、または問題の詳細を捏造することは禁止
• 不確実な評価については慎重な表現を使用："～のように思われます"、"～を示唆している可能性があります"
• すべての発見は実際の確認内容に基づく </uncertainty_and_ambiguity>

<citation_verification_spec> 引用検証仕様（必須）

コア原則：監査レポート内のすべての問題引用は検証可能である必要があります。"印象に基づいて"コンテンツを生成することは禁止です。

実施が必須の検証ステップ：

1. 問題を生成する前に：Read ツールを使用して関連ファイルを読み、正確な行番号とコンテンツを記録
2. "現在の"コンテンツを記述する場合：最新の Read 結果から直接コピーする必要があります。記憶に基づいて記述することは禁止
3. レポート生成後：各 🔴/🟡 問題に対して逆参照検証を実行（workflow-execution.md のステップ 7B を参照）

検証失敗時の処理：

• 逆参照で引用コンテンツが実際と異なる場合 → その問題を削除するか引用を修正
• 正確な行番号を確定できない場合 → "約第 N 行近辺"を使用し、手動確認が必要と記述
• コンテンツが実際に存在しない場合 → その問題は無効な問題であり、削除が必須

禁止行為：

• ファイルを読まずに"この行に特定内容がある"と主張することは禁止
• "あるべき"に基づいて問題を生成することは禁止（"実際にある"に基づいてのみ）
• 曖昧な行番号範囲（例："第 500～600 行"）を問題の位置として使用することは禁止 </citation_verification_spec>

<tool_usage_rules>

• 複数のファイルをスキャンするか複数の側面をチェックする場合は、独立した読み取り操作を並列化
• 新鮮なデータを取得する場合は、内部知識ではなくツール使用を優先
• 書き込み後の復述：何が変わったのか、どこが変わったのか、どの検証を実行したのかを説明 </tool_usage_rules>

<long_context_handling>

• 複数の参照ファイルを含む監査では、まず重要なセクションの内部アウトラインを生成
• レポート生成前にユーザー制約を復述
• 検出内容を具体的なファイル:行番号の参照に結合 </long_context_handling>

<report_output_spec> レポートファイルコンテンツ（scripts/save_report.py で保存）：

• ref-output-format.md の構造に厳密に準拠
• セクション 2 クロスチェック - GPT ガイドコンプライアンスは最初に配置する必須
• セクション 3.1 確認済み問題 - 重大度でグループ化された markdown テーブル（🔴 → 🟡 → 🟢）
• セクション 3.2 フィルタ済み問題 - フィルタ理由付きの markdown テーブル
• セクション 4 修正提案 - 確認済みの各問題に対して：位置、問題、影響、現在の内容、提案
• セクション 5 結論 - "推奨アクション"と操作オプションを含む

保存後のターミナル出力：

1. サマリー行：監査完了: 🔴{n} 🟡{n} 🟢{n} | 判定: {合格/改善必要/不合格}
2. 保存通知：監査レポートを保存しました: {完全パス}
3. 操作ヒント：

レポートを確認後、修正する問題番号を入力してください:
- 1 または 1,2 または 1-3 を入力して修正項目を選択
- all を入力してすべての修正を適用
- その他の入力で対話を続行

</report_output_spec>

<report_save_spec> 保存スクリプト：scripts/save_report.py

使用方法（クロスプラットフォーム）：

# Windows:
python -X utf8 scripts/save_report.py --project "{プロジェクト名}" --output-dir "{出力ディレクトリ}" --content "{レポート内容}"

# macOS/Linux:
python3 scripts/save_report.py --project "{プロジェクト名}" --output-dir "{出力ディレクトリ}" --content "{レポート内容}"

# stdin 経由（すべてのプラットフォーム）:
echo "{レポート内容}" | python3 scripts/save_report.py --project "{プロジェクト名}" --output-dir "{出力ディレクトリ}"

パラメータ：

• --project, -p：プロジェクト名（ディレクトリ名、拡張子なしのファイル名、または inline_text）
• --output-dir, -o：監査対象プロジェクトの親ディレクトリ（レポートは内部ではなく隣に保存）
• --content, -c：完全なレポート内容（または stdin で渡す）

クロスプラットフォーム注意事項：

• Windows：中国語文字をサポートするため python -X utf8 を使用
• macOS/Linux：python3 を使用、UTF-8 がデフォルト
• すべてのプラットフォーム：中国語/スペースに対応させるため、すべてのパスを " で囲む

ファイル名形式：監査報告書_{プロジェクト名}_{YYYYMMDD_HHmmss}.md

プロジェクト名ルール：

監査対象	プロジェクト名	出力ディレクトリ
ディレクトリ /path/to/my-skill	my-skill	/path/to
ファイル /path/to/config.md	config	/path/to
貼り付けテキスト	inline_text	現在の作業ディレクトリ

実行フロー：

1. メモリ内で完全な監査レポート内容を生成（セクション 0～5）
2. save_report.py スクリプトを実行してレポート内容を渡す
3. スクリプトの stdout から出力パスをキャプチャ
4. ターミナルサマリーと保存通知を表示
5. フォールバック戦略（スクリプト失敗または出力なしの場合）：
   • CLI ビルトイン ファイル書き込み機能を使用してレポートを保存
   • 同じファイル名形式：監査報告書_{プロジェクト名}_{タイムスタンプ}.md
   • 同じ出力ディレクトリ規則
   • すべての書き込み方法が失敗した場合、最後の手段としてターミナルに完全なレポートを表示 </report_save_spec>

<!-- ============================================================== -->

Hello-AuditKit: AI プログラミング アシスタント監査システム

目次

• エントリーポイント
• 概要
• コア原則
• 監査実行
• 参照ファイル
• 外部ドキュメント
• 監査標準サマリー

エントリーポイント

スキルが呼び出されるときは、段階的に実行します：

<audit_phases>

監査フェーズ概要

フェーズ	名称	トリガー条件	コア操作	出力
1	データ収集	SKILL が有効でデータなし	ウェルカムメッセージを表示	ユーザーがデータを提供するまで待機
2	クイック検証	ユーザーがデータを提供	軽量チェック データ有効性	有効→フェーズ3 / 無効→フェーズ1
3	監査確認	データ検証がパス	データを確認して問い合わせ	確認→フェーズ4 / その他→待機
4	包括的監査	ユーザーが監査を確認	包括的スキャン + 深い分析	監査結果
5	レポート修正	監査が完了	レポート生成 修正待機	ユーザー選択の修正を適用

フェーズ転換ルール：

• フェーズ 1 → フェーズ 2：ユーザーがデータを提供
• フェーズ 2 → フェーズ 1：データが無効または不完全
• フェーズ 2 → フェーズ 3：データ検証がパス
• フェーズ 3 → フェーズ 4：ユーザーが監査を確認
• フェーズ 4 → フェーズ 5：監査実行が完了 </audit_phases>

フェーズ 1：データ収集

ユーザー入力	操作
ターゲット未指定	ウェルカムメッセージと使用ガイドを表示 → 待機（ファイルはスキャンしない）
ファイル/ディレクトリ/テキストを提供	フェーズ 2 クイック検証に進む

ウェルカムメッセージ（ターゲットなし時、{OUTPUT_LANGUAGE} で生成）：

含まれるコンテンツ：
- ツール名を含むグリーティング
- サポートされている監査タイプ：プロンプトテキスト、メモリファイル、スキル、プラグイン
- 必要なデータ説明：ファイルパス、ディレクトリパス、またはテキストを貼り付ける必要があります
- 入力を促す

重要：フェーズ 1 はデータ収集のみで、ファイルスキャンやコンテンツ分析は禁止です。

フェーズ 2：クイック検証

目的：ユーザーが提供したデータが有効で監査要件に適合しているかを軽量検証します。

検証項目	チェック内容
パス有効性	ファイル/ディレクトリが存在するか
タイプ識別	サポートされている監査タイプとして識別できるか（Prompt/Memory/Skill/Plugin）
基本完全性	Skill/Plugin の場合、必須ファイルが存在するか

クイック検証操作（軽量チェックのみ、深い分析は不可）：

• ファイル/ディレクトリ存在確認
• コンテンツタイプの識別
• Skill の場合：SKILL.md が存在するか確認
• Plugin の場合：.claude-plugin/ が存在するか確認

検証結果	操作
データが無効または不完全	問題を説明 → 継続して求める → フェーズ 1 に戻る
データが有効で完全	フェーズ 3 に進む

フェーズ 3：監査確認

確認メッセージ（{OUTPUT_LANGUAGE} で生成）：

含まれるコンテンツ：
- データ受け取りを確認
- 識別された監査タイプと対象パスを表示
- 質問：監査を開始しますか？

ユーザー応答	操作
監査を確認（はい/開始/確認/audit/yes/start）	フェーズ 4 に進む
未確認またはその他	待機またはユーザーの意図を質問

重要：フェーズ 4 に進む前に、ユーザーの明確な確認を待つ必須です。

フェーズ 4：包括的監査

ユーザーが確認した後、完全な監査プロセスを実行（workflow-execution.md を参照）：

1. 包括的スキャン/ファイル内容抽出
2. ルールとチェックリストをロード
3. すべてのチェック項目を実行
4. 問題検証とフィルタ
5. 修正提案を生成

フェーズ 5：レポートと修正

1. 監査レポートを生成して保存
2. サマリーと操作ヒントを表示
3. ユーザーが修正項目を選択するまで待機
4. ユーザーが確認した修正を適用

概要

AI プログラミング アシスタント設定の包括的な監査システム：

コンテンツタイプ	識別方法	ルールファイル
任意のテキスト/ファイル	貼り付けテキストまたは任意のファイル（任意のファイル名）	type-prompt.md
AGENTS.md	Codex エージェント指示	type-memory.md
CLAUDE.md	Claude Code メモリファイル	type-memory.md
GEMINI.md	Gemini CLI コンテキストファイル	type-memory.md
スキル	SKILL.md を含むディレクトリ	type-skill.md
プラグイン	.claude-plugin/ を含むディレクトリ	type-plugin.md
複合	メモリファイル + skills/	cross-composite.md

コア原則

ソース：最新 GPT プロンプト書き方ガイド (openai-cookbook/examples/gpt-5) に基づく 完全な詳細：references/methodology-core.md を参照

原則 0：GPT プロンプト書き方ガイド コンプライアンス（必須）

重要：これはメイン監査標準です。すべての監査はこれらの項目をチェックする必須です。

チェック項目	チェック内容	重大度
詳細な制約	明示的な長さ制限が存在するか	深刻
スコープ規律	明示的な境界または禁止リストが存在するか	深刻
停止条件	マルチステージコンテンツがステージゲートに強い停止言語を持つか	深刻
制約集約	重要なルールが集約され、3 か所を超えて分散していないか	深刻
禁止言語	重要な制約が強い言語を使用しているか	警告
幻覚防止	事実タスクに接地指示があるか	深刻
構造化タグブロック	角括弧タグ (<tag>...</tag>) が重要な制約をラップしているか	警告

構造化タグブロック（ベストプラクティス）：

プロンプトタイプ	推奨：タグブロックで…をラップ	欠落時の重大度
詳細なルールを持つすべて	長さ/フォーマット制約	情報
スコープルールを持つすべて	スコープ境界	情報
エージェント/マルチステージ	エージェント通信ルール	警告
データ抽出	出力パターン	警告
事実/接地	幻覚防止	情報

原則 1：5 段階検証法

問題をマークする前に、次を検証：

1. 具体的なシナリオ - 具体的な失敗シナリオを説明できるか？
2. 設計スコープ - 期待される境界内にあるか？
3. 機能能力 - 実際にそれが主張することができるか？
4. 欠陥 対 選択 - 意図しないエラーか有効な選択か？
5. 閾値到達 - 量的閾値を超えているか？

いずれかのポイントが失敗 → その問題は破棄

原則 2：オッカムの剃刀

"必要でなければ、実体を増やすな。"

修正優先度：削除 > マージ > リファクタリング > 変更 > 追加

原則 3：AI 能力

• AI が推断できること：同義語、文脈、標準用語
• AI ができないこと：3 ステップ以上の推論、ドメイン固有の変数
• <30% が誤解する場合 → 問題を免除

原則 4：サイズ許容度（SKILL.md 本文のみ）

範囲	ステータス
≤500 行	理想的
500-550（≤10% 超過）	問題ではない
550-625（10-25% 超過）	情報のみ
>625 行	警告

注意：参照ファイルに公式の行数制限はありません。コンテンツの性質に基づいて評価してください。

監査実行

詳細なステップガイド：references/workflow-execution.md を参照 チェック項目レジストリ：references/registry/index.md を参照 タイプ実行チェックリスト：references/checklists/index.md を参照

新しいアーキテクチャ：レジストリ + チェックリスト

<audit_architecture> チェック項目レジストリ (Registry)：各チェック項目に一意な ID があり、レジストリで一度定義 タイプ実行チェックリスト (Checklist)：コンテンツタイプごとに実行するチェック項目 ID を列挙

実行フロー：

1. コンテンツタイプを識別 → 対応するチェックリストをロード
2. チェックリスト内の ID ごとにレジストリのルールをロード
3. すべての必須チェック項目 + 条件付きチェック項目を実行
4. レジストリカテゴリ別に実行証拠を出力 </audit_architecture>

レジストリカテゴリ

プリフィックス	カテゴリ	レジストリファイル
N	命名 Naming	registry/reg-naming.md
B	番号付け Numbering	registry/reg-numbering.md
R	参照 Reference	registry/reg-reference.md
S	構造 Structure	registry/reg-structure.md
P	プロンプト品質 Prompt	registry/reg-prompt.md
X	セキュリティ Security	registry/reg-security.md
T	ランタイム Runtime	registry/reg-runtime.md
F	フォーマット Format	registry/reg-format.md
L	言語 Language	registry/reg-language.md
K	スキル固有 Skill	registry/reg-skill.md
G	プラグイン固有 Plugin	registry/reg-plugin.md

タイプ実行チェックリスト

コンテンツタイプ	実行チェックリスト	チェック項目数
プロンプト Prompt	checklists/checklist-prompt.md	~51
メモリ Memory	checklists/checklist-memory.md	~54
スキル Skill	checklists/checklist-skill.md	~111
プラグイン Plugin	checklists/checklist-plugin.md	~126
複合 Composite	checklists/checklist-composite.md	~150+

クイックリファレンス

ステップ	操作	キー出力
1	GPT プロンプト書き方ガイドを取得	ガイドバージョン、必須チェック項目
2	検出と分類	コンテンツタイプ、ロードするチェックリスト
2B	チェックリストとレジストリをロード	"ロード完了：checklist-{type}.md、レジストリ：[リスト]"
3	一般的なチェックを実行	チェックリスト必須項目によって
3B	証拠チェックポイントを実行	カテゴリサマリーテーブル + 各カテゴリのチェック ID 詳細
4	タイプ固有チェックを実行	チェックリスト条件付き項目によって
5	クロスチェックを実行	マルチファイルシステムチェック
6	問題検証	5 段階チェック、無効なものをフィルタ
7	修正提案検証	オッカムの剃刀、AI 能力
7B	引用逆参照検証	N 個の問題を検証、パス/修正/削除統計
8	レポート生成	ref-output-format.md に従う、レジストリ別にグループ化
8B	レポートをファイルに保存	監査報告書を保存しました: {完全パス}
9	確認を待機	ゲート処理で停止

重要な実行ルール

1. GPT ガイド コンプライアンスが優先 - 常に P-001～P-008 を最初にチェックしてから他のチェックを実行
2. チェックリスト別にロード - チェックリストを使用して、どのレジストリ項目を実行するか決定
3. **並列読み取