coding-project-setup

コードプロジェクトの知識フレームをセットアップする。project-setupのsub-skillで、プロファイリング済み（相手はエンジニア・目的は開発）を前提とする。ゴールは「次のセッションがcheck_in・searchで文脈を取れる状態」。既存mdの走査とインタビューは排他ではなく、同一フレームを埋める2つの充填手段。mdで埋まった項目はスキップし、穴だけ聞く。

発動の入口

原則としてproject-setup skillのプロファイリング（Step 1〜2）を経て委譲される。エンジニアのユーザーが直接頼んだ場合も発動してよいが、ペルソナがauto-memoryに無ければproject-setup側のプロファイリングを先に行う。

コードを扱わない取り組みのセットアップはproject-setupの職種中立経路の担当であり、本スキルは発動しない。

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

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

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

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

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

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

手順

Step 1: domain確認

• ユーザーの発話・cwdからdomain名の案を作り、search_tags(query=<候補名>, namespace="domain", include_notes=True)で既存タグを確認する。namespaceを絞らない・include_notesを省いた呼び出しでは判定材料（notes）が返らない
• search_tagsはタグ名のLIKE一致とベクトル検索のハイブリッドなので、意味的に近いだけの別名タグも返る。衝突判定は返却されたnameの完全一致で行い、上位ヒットの有無では判定しない。usage_countは判定に使わない（retract済みを含む付与回数で、余談1件でもすでに1以上になるため区別できない）
• 完全一致するdomain:タグが無ければそのままStep 2へ進む。ある場合は以下で分ける。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 5のnotes書き込みは新規作成ではなくマージになる）
  • アクティビティもnotesも無い場合、archivedがfalseならそのまま続行してフレームを埋める（過去の言及だけでタグが実体化した状態）。archivedがtrueなら退役済みでフレームが立っているとは扱わない。同名で立て直すか別名にするかをユーザーに確認してから進む（別名にするなら新しい名前でこの確認をやり直す）

Step 2: md走査（読み取りのみ、何も変更しない）

• 対象: リポジトリ内でremoteから取得できるmd（README / docs/ / CONTRIBUTING / ADR / リポジトリのCLAUDE.md 等）
• 対象外: ユーザーレベルのローカルmd（~/.claude/配下等）。CALMの記録はexport等でpeerを超えて人に渡りうるため、取り込み自体を避ける
• フレームF1〜F5への充填案を抽出する。詳細情報は転記・再構造化せず、参照ポインタ（リポジトリ内パス・URL）として扱う

Step 3: 充填案の提示・裁定

• F1〜F5の充填案と未充填項目を1つの表にまとめて提示する
• 裁定の粒度を分ける: **タグセット（F1/F2）**はまとめて一括承認でよい。**decision候補（F3）**は1件ずつ中身を展開して個別裁定する。md由来の内容はユーザーが裁定して通せば合意扱いとし、どのmdのどの記述に由来するかをreason本文の中に文章として書く（リポジトリ内の相対パスで示す。reason末尾の定型節に由来用の節は無いので、独自の見出し行を足さない）
• タグ作成規律: 素タグは少なめに倒す（2〜4個目安）。ディレクトリ構造からの機械的切り出しはしない。description（100字以内の一言定義）を付けるのは「プロジェクト固有の意味・実体を指すタグ」のみ（造語・固有名詞・一般語の固有用法）。一般語彙タグには付けない。判定は「名前が読めるか」ではなく「このプロジェクト固有の意味か」で行う

Step 4: 未充填分の会話ヒアリング

• フォーム型の質問リストを提示しない。「一言で何？」「N個挙げて」のような要約・圧縮・選別の作業をユーザーに課さない
• 未充填項目を会話の流れに沿って聞く（例: F3が空なら「技術選定とかアーキテクチャでもう決まってることある？」、F4が空なら「直近は何から手をつける？」）
• ユーザーの自由な発話はmdと同じ充填材料として扱い、F1〜F5への構造化（一言説明の起草・タグ候補の抽出）はAIが行って案として提示・裁定を受ける
• 「わからない・まだ無い」は正当な回答。F1のみ必須、F2〜F5は空のまま進めてよい
• フレームに収まらない知識（規範・判断基準・手順・背景の生発話）は remember の判定木で置き場を判定する

Step 5: 書き込み実行

• 書き込みは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は一言説明・リポジトリのremote識別子・参照ポインタをまとめた最終形を1回で書く。既存notesを持つdomain:タグへ書く場合は、Step 1のsearch_tags（include_notes=Trueで呼ぶ）で取得した既存notesを保持したままマージした全文を書く（全文置換なので、書かなかった内容は消える）
• mdの全文をmaterialに複製しない

Step 6: 結果報告

• 作成したフレームの一覧（タグ・decision件数・activity・ポインタ）を提示する

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

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