wiki-policy-check

wiki-policy-check — ビジネスルールの漏出を監査し、型付きスキーマを検証する

このスキルには2 つのモードがあります。

モード	使用する場面	動作
audit	デフォルトです。ユーザーが「何か漏れていませんか？」「ドキュメントを監査して」「このリポジトリにビジネスルールがないか確認して」と尋ねた場合。	プロンプト駆動型です。エージェントがこのリポジトリ内のすべての Markdown を読み、漏出を報告します（以下の「手順」を参照）。
validate-schema	ユーザーが wiki の対象にある型付き Decisions/Rules/Events の検証を依頼した場合。wiki-lint（epic #4 Story 05）から呼び出された場合。または新しい ADR/Rule の公開後。	スクリプト駆動型です。scripts/validate-schema.ts が <wiki>/_schemas/typed-schema.yaml を読み込み、ADR-0009 に従って frontmatter と events.jsonl の各行を検証します。

2 つのモードは独立しています。audit は従来のプロンプトベースのスキルであり、validate-schema はプログラムによるアドオン（wiki-service の epic #4 Story 02）です。

プロジェクトルート

このスキルは、エージェントの現在の作業ディレクトリではなく、プロジェクトルート（監査を実行するリポジトリ）からの相対パスにあるファイルを読み込みます。

• プロジェクト内から呼び出す場合は、このスキルに示されている相対パスを使用します。
• 別のディレクトリから呼び出す場合は、すべてのパスの先頭に <project-root>/ を付けるか、スクリプト形式の呼び出し時にプロジェクトルートを明示的に指定します。
• プロジェクトルートが曖昧な場合は、実行前にハーネスの質問ツールを使ってユーザーに確認します。

プロンプトの作成

CLAUDE.md / AGENTS.md のプロジェクト全体の規約（「Skill Prompting Conventions」）に従います。以下の判断ポイントでは、ハーネスの構造化質問ツール（Claude Code の AskUserQuestion、Codex の ask_user_question、または OpenCode の question）を使用します。列挙できないパス／名前／値に限り、自由形式のテキストを使用します。

判断ポイント	構造化する理由	推奨する選択肢
モード	漏出の提示方法に影響します	報告のみ · ブロック（CI スタイル）· 移行の提案
対象範囲（複数選択）	網羅性に影響します	すべての Markdown · 特定のパス · 差分のみ

自由形式のプロンプト（構造化ツールは不要）：

• カスタムのビジネスルール定義

一時停止なしモード：ユーザーがスキルの途中での確認を明示的に無効にしている場合は、構造化プロンプトをすべて「未解決の質問」（または同等の項目）に記載し、ブロックせずに続行します。

プロジェクトのガードレール

.wiki-guardrails.yml がある場合は、wiki のパス、Markdown の許可リスト、機密パスに関するローカルポリシーの情報源として扱います。このスキルから別の許可リストを推測してはいけません。ファイルがない場合は、CLAUDE.md / AGENTS.md を読み、ガードレールが不足していることを報告します。

wiki の場所

「中央 wiki」のパスはプロジェクトによって異なります。実行前に、プロジェクトの CLAUDE.md および／または AGENTS.md（存在する場合は .agents/rules/ も）を読み、次を確認します。

1. wiki の場所（例：サブフォルダーとしての wiki/、兄弟ディレクトリとしての ../knowledge-base/、外部 URL）。
2. ビジネスルールに関するプロジェクト独自の定義。多くのプロジェクトでは「ビジネスルール — ポリシー」セクションで明示しています。特にニュアンスを含む境界線を尊重してください（例：税務製品では「規制アルゴリズム＝技術、規制対象の範囲に関する判断＝製品」とする場合や、公開サイトでは「マーケティング文言＝ローカル、そこで表現されるルール＝wiki」とする場合があります）。

プロジェクトにポリシーの記述がない場合は、以下の一般的な定義を適用し、監査の一部としてポリシーがないことを報告します。

実行するタイミング

• このリポジトリでドキュメントの更新を長期間続けた後。
• 大量のドキュメントを追加する PR を作成する前。
• 定期的に（多くのプロジェクトでは月次が適切です）。
• ユーザーが「何か漏れていませんか？」「ドキュメントを監査して」などと尋ねたとき。

手順

1. プロジェクトのポリシーを読む（CLAUDE.md、AGENTS.md、必要に応じて .agents/rules/）。次の項目を確認します。
   • Wiki のパス（サブディレクトリまたは兄弟ディレクトリ）。
   • 「これは技術的な内容」と「これはプロダクトの内容」に該当する、プロジェクト固有の例（プロジェクト固有のニュアンスは、以下の一般的なリストより優先されます）。
2. このリポジトリ内のすべての .md を列挙する。次のパスは除外します。
   • node_modules/**、.git/**、dist/**、build/**、.next/**、.wrangler/**、.astro/**、.cache/**
   • 自動生成された出力（Playwright の test-results/、ロックファイル、生成された型定義）
3. 各ファイルを最後まで読む。技術的な内容が大半のドキュメントでも、途中に漏れが隠れていることがあります。ざっと目を通すだけでは不十分です。
4. 各ファイルの内容を分類する。
   • 完全に技術的 → 対応不要。
   • 完全にビジネス関連（顧客向けの内容、価格設定、ポリシー、収益化、顧客の利用プロセス、コンプライアンス、プロダクトの意思決定） → 移行対象として報告する。
   • 混在 → ファイル全体ではなく、ビジネス関連の箇所を具体的に特定して報告する。
5. 一般的なシグナル：ほとんどの場合、情報漏れを示します（プロジェクトのポリシーで追加または上書きされる場合があります）。
   • 価格設定／収益化：通貨表記（「R$」「$」「€」）、パーセンテージの料率、「月額料金」、「テイクレート」、「サブスクリプションプラン」、「Free/Pro プラン」、「固定月額」。
   • 顧客向けポリシー：「キャンセル」、「返金」、「無断キャンセル」、「サービスクレジット」、「保証」、「利用規約」、「サービスレベル契約」。
   • 顧客の利用プロセス／ペルソナ：ターゲット顧客の説明、アンカー顧客への言及、単なる例のラベルではなくプロダクトの位置づけとして使われている ICP に関する表現。
   • コンプライアンス方針：「LGPD」、「GDPR」、「CCPA」、「同意」、「プライバシーポリシー」、「データ保持」、「匿名化」、「忘れられる権利」、責任に関する声明。
   • スコープの決定：「X はサポートするが Y はサポートしない」、段階的なロールアウトに関する表現、アンカー顧客との取り決め。
   • 外部連携の理由：いつ、なぜ利用するか、請求への影響（技術的な「連携方法」はこのまま残し、「利用すべきか」はプロダクトに関する内容です）。
   • 未解決のプロダクト上の課題：オーナーへの質問、保留中の決定、機能に関する「後で決める」という記述。
6. Wiki と照合する：報告対象の各項目について、手順 1 で特定した Wiki の場所を調べ、正式な内容がすでに存在するか確認します。
   • 存在する場合 → 推奨対応は「相互参照を追加して、ここから削除」（重複させない）。
   • 存在しない場合 → 推奨対応は「/wiki-ingest を使って移行」（このリポジトリではなく、Wiki のリポジトリ／フォルダーから実行）。
7. 単一のレポートを出力する。ファイルは変更しないでください。
8. 変更を適用する前に確認を求める。このスキルは報告のみを行います。移行するかどうかはユーザーが決定します。

出力形式

## Wiki Policy Check — <YYYY-MM-DD>

### Findings (<n>)

| File | Excerpt | Type | Suggested action | Confidence |
|---|---|---|---|---|
| <path>:<line> | "<short quote>" | business | migrate to <wiki>/business/<page>.md | high |
| ... | ... | mixed | cross-ref + delete | medium |

### Files audited and clean (<n>)
- <list>

### Notes
- Auto-generated content skipped: <count> files
- Already covered by the wiki: <count> findings (cross-ref recommended)
- Project policy gaps observed: <list any policy text that was missing or unclear>

ルール

• 読み取り専用：このスキルがファイルを変更することはありません。実際の移行は、ユーザーが /wiki-ingest を実行して行います（wiki リポジトリまたは wiki フォルダー内）。
• プロジェクトのポリシーは汎用ポリシーに優先します：プロジェクト独自の CLAUDE.md にニュアンス（例：「税務アルゴリズムはここでは技術的な内容として扱う」）が定められている場合は、上記の汎用シグナルリストで該当すると判断される場合でも、それに従ってください。
• 迷った場合はフラグを付けます：何かがビジネスルールかどうか判断に迷う場合は、フラグを付けてください。判断はオーナーに委ねます。
• 重複させないでください：wiki にすでにルールが存在する場合、推奨アクションは「ここでは相互参照して削除」であり、「再度移行」ではありません。
• 汎用的な技術スタックへの言及にはフラグを付けないでください：「React」「TanStack Start」「Drizzle」「Better Auth」「Convex」「Cloudflare Workers」などの技術名は技術的な内容なので、そのまま残します。これらの技術が製品に関する説明と組み合わされている場合（「顧客が Y なので X を使う」など）に限りフラグを付けます。漏えいしているのは技術ではなく、製品に関する説明です。
• マーケティングコピーの特例：プロジェクトが公開サイトを提供している場合、コピーそのものはサイト上に置きます（表示する必要があるため）。ただし、コピーに含まれるルールは wiki に置き、コピーではルールを繰り返さず、参照するようにします。
• 自動生成されたコンテンツはスキップします（ビルド出力、ロックファイル、生成された型、テスト結果）。
• 抜粋は具体的にしてください：言い換えではなく、実際の引用を抜き出してください。ユーザーは正確な文言を見て判断します。

---

モード 2：validate-schema（スクリプト駆動）

Decisions（<wiki>/<project>/decisions/ADR-*.md）、Rules（<wiki>/<project>/rules/RULE-*.md）のフロントマター、および Events（<wiki>/<project>/history/events.jsonl）の各行を、中央の型付きスキーマ <wiki>/_schemas/typed-schema.yaml に照らして検証します。

スキーマ仕様は ADR-0009 (wiki-service) にあり、正規のスキーマファイルは wiki-content リポジトリの wiki/_schemas/typed-schema.yaml にあります。

使用するタイミング

• wiki-content への PR を通じて新しい ADR または Rule を公開した後（スモークテスト）。
• wiki-content 全体に対して定期的に実行する場合（リグレッションチェック）。
• wiki-lint スキル（エピック #4 ストーリー 05）から warning または block モードで呼び出される場合。
• CI ゲートで手動検証する場合（将来）。

実行方法

# Default: JSON output, exit 0 if all valid, exit 1 if invalid
bun ~/.claude/skills/wiki-policy-check/scripts/validate-schema.ts --wiki-path /path/to/wiki

# Human-readable output
bun ~/.claude/skills/wiki-policy-check/scripts/validate-schema.ts --wiki-path /path/to/wiki --format table

# Custom schema path (e.g. for tests)
bun ~/.claude/skills/wiki-policy-check/scripts/validate-schema.ts --wiki-path /path/to/wiki --schema-path /path/to/typed-schema.yaml

フラグ

フラグ	デフォルト	説明
--wiki-path <path>	（必須）	wiki の対象ルート（例：/tmp/wc-clone/wiki）。配下の */decisions/、*/rules/、*/history/ をグロブで検索します。
--format json|table	json	json は機械可読（jq で処理可能）、table は人間による確認用です。
--schema-path <path>	<wiki>/_schemas/typed-schema.yaml	スキーマの場所を上書きします（主にテスト用）。
--help / -h	—	使用方法を表示します。

終了コード

コード	意味
0	すべてのドキュメントが有効で、ID の重複も孤立した参照もありません。
1	次のいずれかに該当します：スキーマが無効、ID が重複、または参照が孤立。
2	実行エラー（スキーマファイルが見つからない、グロブ検索に失敗したなど）。

出力（JSON スキーマ）

{
  "schema_version": "1.0.0",
  "summary": { "valid": 3, "invalid": 1, "duplicate_ids": 0, "orphan_refs": 1 },
  "validations": {
    "decisions": [
      { "path": "<project>/decisions/ADR-0001.md", "valid": true, "id": "ADR-0001", "project": "<project>" },
      { "path": "...", "valid": false, "errors": [{ "field": "status", "message": "must have required property 'status'" }], ... }
    ],
    "rules": [...],
    "events": [{ "path": "...events.jsonl", "line": 2, "valid": true, "kind": "etl-run" }]
  },
  "duplicate_ids": [
    { "project": "<project>", "id": "ADR-0001", "paths": ["path1.md", "path2.md"] }
  ],
  "orphan_refs": [
    { "in": "<path>", "ref": "ADR-9999", "reason": "ADR-9999 not found in same project (<project>)" }
  ]
}

ルール

• Decisions と Rules では additionalProperties: false（厳格）、Events では additionalProperties: true（レガシー ETL イベントを許容）にします。
• 相互参照の検証はプロジェクト単位です（ADR-0009 Decision #6 に準拠）。supersedes: ADR-NNNN は同じプロジェクト内の ADR のみを対象に検証します。プロジェクトをまたぐ参照はスキップされます。
• ID の重複チェックはプロジェクト単位かつ種類単位です（smart-city/ADR-0001 と front-manager/ADR-0001 は共存できますが、smart-city/decisions/ 内の ADR-0001 が 2 つある場合は重複します）。
• 日付とタイムスタンプには、スキーマ内の pattern 正規表現を使用します（format: date ではありません）。ADR-0009 Decision #11 に準拠しています。ajv-cli の厳格モードでは、ajv-formats プラグインなしでは format が認識されません。
• YAML フロントマターの日付は、js-yaml の JSON_SCHEMA エンジンを使って文字列として解析されます（デフォルトの DEFAULT_SCHEMA では 2026-05-22 が Date オブジェクトに変換されます）。

テスト

cd ~/.claude/skills/wiki-policy-check
bun test scripts/validate-schema.test.ts
# → 8 pass, 0 fail

有効な ADR、無効な ADR（status の欠落）、ID の重複、孤立した参照、有効な Rule、有効な Event（複数の kind）、無効な Event（ts の欠落）、集計の要約を網羅する 8 件の単体テストです。フィクスチャは scripts/fixtures/wiki/ にあります。

境界

• スクリプトは読み取り専用で、Wiki ファイルを変更することはありません。
• スキルはグローバルで、特定のプロジェクトに属しません。スクリプトはポータブルで、必要なのは bun と package.json の依存関係のみです。
• ビジネスルールの漏えいを監査するモード（スキル本来の目的）には、上記のモード 1 を使用してください。