oya-inai-intake

name	oya-inai-intake
description	受付箱（Vault の外のフォルダ。既定 `~/Desktop/受付箱`）に置かれたファイルや会話上の語り（面談メモ・支援記録・会議録・モニタリング等）を受け取り、Obsidian Vault と Neo4j 支援DB への仕分け宣言を出す親スキル。判断だけを担い、書き込みは子スキル（oya-inai-vault / oya-inai-neo4j）へ渡す。「受付箱に入れました」「受付箱を見て」「この記録を取り込んで」「面談メモです」「聞き取りを仕分けて」「インテークして」などの発言時、および語りを含む .md/.txt/.docx/.xlsx/.pdf ファイル添付時に必ずこのスキルを使用すること。

oya-inai-intake — 単一インテーク（親：仕分けの判断）

最上位規則 — No Fabrication（何よりも先に）

1. 絶対に入力テキストにない情報を創作・推測しない。
2. 「一般的にこうだろう」という推測は禁止。不明な項目は空欄・null のまま出力する。
3. **仕分けは分類であって補完ではない。**語りに無いことを埋めた1行が、後から事実として引き継がれる。

この規則は本スキルのすべての手順に優先し、子スキルにも引き継がれる。

役割と境界

**親は判断、子は手続き。**本スキルは「どの事実がどちらの系のどの器に落ちるか」を決めて宣言するだけで、ファイルも DB も書かない。

人（語り・添付） → oya-inai-intake（本スキル：仕分け宣言）
                     ├→ oya-inai-vault（Obsidian への保存・ページ生成）
                     └→ oya-inai-neo4j（Neo4j への構造化登録）

• 子スキルは単独でも起動できる（本スキルを経ずに「Obsidian に書いて」等で呼ばれる）
• 受付箱のファイルの読み取りは親（本スキル）が行い、内容を判断したうえで子へ渡す。親は受付箱の中を動かさない——受付箱から raw/ への移動と sha256 の算出は oya-inai-vault の手続き

判断規則の正典（本文に写さない）

事実ごとの落とし先は、本スキル同梱の reference/dual-intake-routing.md を読む。

• §2 — 迷ったときの3つの問い
• §3 — 事実の型ごとの正本表22行（意味が近い対の排他規則を含む）
• §6 — 仕分け宣言の定型文

**本スキルの本文には判断規則を書かない。**写した瞬間から正典と乖離が始まるため（二重管理の禁止）。仕分けのたびに reference/ を読んで適用する。reference/ の写しが見つからない場合は仕分けを進めず、導入手順に従って再取得する。

reference/dual-intake-routing.md は機械配布された写し（AUTO-GENERATED・編集禁止）。正典は oya-inai-wiki docs/dual-intake-routing.md にあり、oya-inai-db/scripts/sync_skill_refs.py が同期する。同期点は shared-schema の台帳（SEMANTIC_MODEL.md §7）に登録済み。

補助の正典: 棚の構成は Vault の CLAUDE.md §1、frontmatter の語彙（provided_by / share_scope）は schema.md §1・§7。

手順

Step 1 — 受付箱を読む

入力の入口は受付箱（Vault の外のフォルダ。既定 ~/Desktop/受付箱）。まず受付箱の中を一覧し、あるファイル（.md .txt .docx .xlsx .pdf）を読む。会話に直接貼られた語りのテキストも入力として受ける。

• ファイルは本スキルが読み、原文を書き換えない。受付箱の中で移動も削除もしない（原本を raw/ の棚へ移すのは oya-inai-vault の手続き）
• 受付箱が空で、会話にも語りがなければ、推測で進めず「受付箱にファイルを置いてください」と伝えて止まる
• チャットの添付として渡された場合は、中身は読めるがファイルの実体（バイト列）に手が届かない。このままでは原本の保存と sha256 の算出ができないので、仕分けだけなら進めてよいが、原本を残すものは受付箱に置き直してもらう（これが呼びかけてよい唯一の例外で、Step 5 の質問1点には数えない）

Step 2 — 出所の推定（棚・provided_by・share_scope）

語りの文脈（誰が話したか・どこから来た文書か）から raw/ の棚を推定する。棚が決まれば provided_by はほぼ機械的に決まる。

raw/ の棚（CLAUDE.md §1）	provided_by
10_本人・家族から/	本人 または 家族
20_会議/	会議
30_事業所から/（事業所ごとにサブフォルダ可）	事業所
40_後見・法律から/	後見人
50_医療から/	医療機関
60_行政・制度/	行政
70_自分の作成物/	相談支援
90_assets/	（バイナリ資産。出所は内容に従う）

この8棚表は Vault CLAUDE.md §1 の写しであり、登録済み同期点（scripts/sync_skill_refs.py --check が正典との一致を検査する）。棚を増減するときは正典を先に変える。

share_scope は提供元の明示があればそれに従い、迷ったら安全側の consent-required（schema.md §1。欠落時もこの扱い）。提供元が「ここだけの話」と限定したものは origin-only。

Step 3 — 事実ごとの落とし先の判定

1. 語りを事実の単位に分解する（1文に複数の事実が混ざっていれば分ける）
2. 各事実に routing §2 の3つの問いを当て、§3 の正本表で行を特定する
3. 意味が近い対（禁忌と引き金、指示と手順、記録と学び、開催事実と決定理由など）は、正本表の判断規則の列に従って排他で振り分ける
4. どの行にも当たらない・複数行に読める事実は、推測で決めず宣言に「要確認」として明記する

Step 4 — person_id / clientId の解決

• Neo4j の clientId が正であり、Vault の person_id はそれを写す（routing §1）
• 既知の本人: Vault の wiki/persons/ と Neo4j の Client を照合して特定する。表記揺れ（ひらがな・呼び名）は同一人物に統合し、確信が持てなければ人に確認する
• 新規の本人: 既存の最大番号の次番（例: P_901 まで使用済みなら P_902）を提案し、人が承認してから確定する。承認なしに採番を確定しない。氏名から推測できる番号にしない
• 既存の oya-inai-db 利用者で clientId が空の場合は、後付け採番の手順書（導入手順を参照）へ誘導する

Step 5 — 仕分け宣言（黙認方式）

routing §6 の定型に従い、会話上に宣言を出して進む。質問は最大1点まで（新規採番の承認と、Step 3 で「要確認」になった事実はこの1点に含めてよい）。訂正があれば従い、宣言を出し直す。

Step 6 — 子への受け渡し YAML

訂正がなければ（＝黙認が成立したら）、次の形式の YAML を会話上に出し、子スキルへ渡す。ファイルには落とさない——訂正は会話で行われるため、会話に見えていることが訂正可能性の担保である。

person: { person_id: "P_900", clientId: "P_900", is_new: false }
source:
  shelf: "raw/10_本人・家族から/"
  filename: "2026-08-10_初回面談.md"     # 受付箱から棚へ移す際の名前の提案。実名を含めない
  sha256: null                            # 算出は oya-inai-vault が移動の前に行う
  provided_by: "家族"
  share_scope: "consent-required"
to_vault:
  - { type: trigger, subtype: distress, modality: auditory, intensity: high, summary: "..." }
  - { type: protocol, domain: morning, summary: "..." }
to_neo4j:
  - { label: NgAction, action: "...", reason: "...", riskLevel: Panic, source: 家族 }
  - { label: CarePreference, category: "...",  ,   }

• summary 等の値は語りにある表現だけで書く（No Fabrication）
• この YAML は人にも読める。人が訂正できる形であることが要件（G-2）

複数本人が登場する語り（会議録で頻出）

• 事実は本人ごとに帰属させ、person ごとに YAML を分ける
• 会議ページ（type: meeting）だけは person_ids に複数を列挙できる（schema.md §2）

承認の非対称（子へ引き継ぐ規則）

系	方式	理由
Obsidian（oya-inai-vault）	黙認方式。宣言して進み、訂正があれば従う	仮名のみで実名を持たない
Neo4j（oya-inai-neo4j）	登録前に必ず人の確認。確認なしの登録経路を作らない	実名・連絡先が入る（G-3）

本スキルの仕分け宣言に対する黙認は、Neo4j 側の登録承認を兼ねない。to_neo4j の内容は oya-inai-neo4j が改めて人の確認を取る。

使用例

ユーザー: 受付箱に面談メモを入れました。取り込んでください。
→ Step 1〜5 を実行し、仕分け宣言を出す。訂正がなければ Step 6 の YAML を出して
   oya-inai-vault / oya-inai-neo4j へ渡す。

実例は Vault の 記入例/語りの例/（語り5本と仕分け宣言）を参照。

関連

• 子スキル: oya-inai-vault（Obsidian への手続き）／oya-inai-neo4j（Neo4j への手続き）
• 判断規則の正典: Vault docs/dual-intake-routing.md
• 環境要件（有料枠・filesystem MCP・neo4j MCP）: 導入手順の「MCP 設定」の章