project-setup

新しいプロジェクト・取り組みの知識フレームをセットアップする。ゴールは「次のセッションがcheck_in・searchで文脈を取れる状態」。最初に相手（ユーザー）を知り、相手に合った充填経路を選ぶ。

発動しない場面

• 既にフレームが立っているdomainでの通常作業
• 保存先が未確定の「覚えて」系依頼（remember skillの担当。本skillは新規domainのフレーム新設に限る）

新規domainのフレーム一括作成は、本スキルを経由せずに直接行わない。

フレーム定義（最低限ここまで）

充填経路によらず共通のゴール。職種中立の語彙で定義する。

#	項目	落とし先
F1	プロジェクト識別子＋一言説明	domain:タグ新設 + notes
F2	主要な関心事 2〜4個	素タグ（固有概念にはdescription付与）
F3	既に決まっている方針	decision（ユーザー裁定を経て記録）
F4	進行中・直近やること	activity
F5	参照すべき場所	domain/素タグのnotesに参照ポインタ（他マシン・他セッションから解決できるものに限る）

F5に書けるのは、URL・サービス名・共有ドライブやドキュメントツール上の場所など、書いた本人のマシン以外からも解決できるポインタに限る。マシンローカルの絶対パス（~/・/Users/...）やユーザーレベル設定配下（~/.claude/等）は書かない。CALMの記録はcheck_inで他セッションのtag notesとして注入され、export等でpeerを超えて人に渡りうるため。ローカル固有の場所しか出てこなかった場合はF5を空のままにし、その情報を残す必要があれば remember の判定木へ流す（セットアップ独自の仕分けをしない）。

本skillが設計上あらかじめ落とし先を固定している書き込み（フレームF1〜F5、およびStep 1のauto-memoryへのペルソナ記録）は、保存先が未確定の依頼を扱う remember の判定対象ではない。判定が要るのはフレームに収まらない知識のほうで、そちらは後述のとおりrememberの判定木へ流す。

タグは単独で新設できない。domain:タグ・素タグは、それらをtagsに載せたエンティティ書き込みで初めて実体化する。notes・descriptionの付与はその後段でしか行えない。

topicは中身が載るときだけ作る。中身のないtopicを儀式的に先に立てても検索・紐づけの足場にならない。本skillではセットアップの経緯ログとF3のdecisionが中身にあたるので、それらを載せる器としてこのセットアップを表すtopicを1件だけ作る。F3が空（decisionが1件も無い）でも経緯ログは残るのでtopicは作る。議論用のtopicを先回りで乱立させない（議論のtopicは議論が始まってから自然発生に任せる）。

Step 1: プロファイリング

• auto-memoryに既存のユーザーペルソナ（userタイプ）があれば読む。十分ならStep 2へ直行する
• 無い・薄い場合は内部推定する。材料: userレベルの設定（~/.claude/CLAUDE.md・rules・導入済みskill/plugin）、作業ディレクトリとホームディレクトリの構成、ここまでの会話の文脈
• 推定するのは「職種・専門性」と「このセットアップの目的」。ユーザーに「あなたはエンジニアですか」と直接は聞かない（内部推定が原則。判定不能なときだけ、目的を普通の言葉で聞く）
• 推定・確認できたペルソナはauto-memoryのユーザーペルソナ（userタイプ）として記録する。既存ペルソナと矛盾したら上書きせずユーザーに確認する
• プロファイリングは取り込みではない: userレベル設定の内容をCALMの記録（decision/material/notes）へ転記しない

Step 2: 経路選択

• 判定を一言宣言してから進む（例:「コードプロジェクトのセットアップとして進めるね」）。黙って振り分けない。違っていればユーザーがここで訂正できる
• コードプロジェクト × 開発目的 → coding-project-setup sub-skillへ委譲する（以降の手順はそちら）
  • 「開発目的」とは実装・保守などコードを書く/変更する作業が主目的であることを指す。コードプロジェクトでも目的がドキュメント整備・調査のみで実装を伴わない場合は開発目的に含めない。判断に迷ったらStep 3（職種中立経路）に倒す
• それ以外 → Step 3（職種中立経路）へ

経路の追加はこのStepの分岐に足す（現時点の分岐はcodingのみ。二分岐固定の設計ではない）。

Step 3: 職種中立経路（会話ヒアリング）

• フォーム型の質問リストを提示しない。「一言で何？」「N個挙げて」のような要約・圧縮・選別の作業をユーザーに課さない
• オープンな聞き方で始める（例:「このプロジェクトのこと教えて。何をやるやつ？」）。ユーザーの自由な発話を充填材料として扱い、F1〜F5への構造化はAIが行う（coding経路のmd走査と同じ位置づけ）
• 発話から充填案（domain名と一言説明の起草・タグ候補・decision候補）を構成して提示し、裁定を受ける
• 裁定の粒度を分ける: **タグセット（F1/F2）**はまとめて一括承認でよい。**decision候補（F3）**は1件ずつ中身を展開して個別裁定する
• domain名の案が固まったら、提示の前にsearch_tags(query=<候補名>, namespace="domain", include_notes=True)で既存タグとの衝突を確認する。namespaceを絞らない・include_notesを省いた呼び出しでは判定材料（notes）が返らない。search_tagsはタグ名のLIKE一致とベクトル検索のハイブリッドなので意味的に近いだけの別名タグも返る。衝突判定は返却されたnameの完全一致で行い、上位ヒットの有無では判定しない。usage_countは判定に使わない（retract済みを含む付与回数で、余談1件でもすでに1以上になるため区別できない）
• 完全一致するdomain:タグが無ければそのまま続行する。ある場合は以下で分ける。archived（検索結果の各タグに付くbooleanで、退役済みかどうかを示す）がtrueのタグも完全一致として扱い同じ分岐に入る（archivedの値で扱いが変わるのは最後の枝だけ）
  • get_activities(tags=["domain:<名前>"], status="active")が1件以上返る → F4が埋まっており稼働中のフレームが既設。本skillの対象外なので、見つかったアクティビティ名を挙げてそのアクティビティへのcheck-inを案内して終了する（check_inはactivity_idが必要なため、案内は具体的なアクティビティを名指しする）
  • 0件ならstatus="snoozed"・"shelved"・"completed"でも個別に呼ぶ。statusの既定値"active"はpending+in_progressしか返さず、全ステータスを一括で返す値は存在しないため、この追加呼び出しを省くと寝かせてある・終了済みのフレームを見落とす。1件以上返る → 過去にフレームが立っている（寝かせてある / 終了済み）ので、見つかったアクティビティを挙げ、そこへ合流するか・同じdomainで立て直すか・別名で新設するかをユーザーに裁定させる
  • どのステータスでもアクティビティが無く、notesが空でない → 取得した既存notesをユーザーに提示し、別名で新設するか既存domainへ合流するかを裁定させる（合流する場合、Step 4のnotes書き込みは新規作成ではなくマージになる）
  • アクティビティもnotesも無い場合、archivedがfalseならそのまま続行してフレームを埋める（過去の言及だけでタグが実体化した状態）。archivedがtrueなら退役済みでフレームが立っているとは扱わない。同名で立て直すか別名にするかをユーザーに確認してから進む（別名にするなら新しい名前でこの確認をやり直す）
• 埋まらなかった項目だけ、会話の流れに沿ってフォローアップで聞く（例: F4が空なら「じゃあ最初は何から手をつける？」、F5が空なら「資料とかドキュメントってどこに置いてる？　自分のPC以外からも見られる場所にある？」）
• 「わからない・まだ無い」は正当な回答。F1のみ必須、F2〜F5は空のまま進めてよい
• タグ作成規律はcoding経路と共通: 素タグは少なめ（2〜4個目安）、description（100字以内の一言定義）を付けるのはプロジェクト固有の意味・実体を指すタグのみ。一般語彙タグには付けない
• フレームに収まらない知識（規範・判断基準・手順・背景の生発話）は remember の判定木で置き場を判定する（セットアップ独自の仕分けをしない）

Step 4: 書き込みと報告

• 書き込みは2段構成。タグを実体化させるエンティティ書き込みが先、タグ属性（notes・description）の付与が後になる
  1. このセットアップを表すtopicをadd_topicで1件作る（title 35字以内、descriptionにセットアップの目的と範囲を書く）。tagsにはF1のdomain:タグとF2の素タグをすべて載せる。これがタグを実体化させる器を兼ねるので、素タグを載せ忘れると後段のdescription付与がNOT_FOUNDで落ちる
  2. セットアップ実行の経緯をadd_logsで記録する（recording skillの基準に従う）。topic_idには1で作ったtopicを指定する
  3. decision（decision-record skillの規律に従う。topic_idは1で作ったtopic）→ activity（activity-start skillの規律に従う）
  4. タグ属性をupdate_tagで付ける: domain:タグのnotes、固有概念の素タグのdescription、F5の参照ポインタ（domain/素タグのnotesへ）。update_tagはnotesとdescriptionを同時指定できず、notesは全文置換なので、domain:タグのnotesは一言説明と参照ポインタをまとめた最終形を1回で書く。既存notesを持つdomain:タグへ書く場合は、Step 3のsearch_tags（include_notes=Trueで呼ぶ）で取得した既存notesを保持したままマージした全文を書く（全文置換なので、書かなかった内容は消える）
• 作成したフレームの一覧（タグ・decision件数・activity・ポインタ）を提示する

運用開始後の増分は対象外

会話中に未知のドメイン固有概念に遭遇したときのインタビューは、habit（未知概念インタビュー）が担う。本skillは初期一括のみ。