plc-brief（Projectと成果をわかりやすく説明）

論理名: SKL_plc_brief

人が読んで「何のためのPJか、何ができたか、自分はどう使えるか、何に役立ちそうか」が自然につながる説明を返す。成果物の内容を人の行動・用途・具体例へ翻訳し、調べた管理情報をそのまま並べない。現在地・残件・判断事項は、その理解に必要な分だけ添える。相談と変更判断の入口は plc-consult、Registryの画面は plc-viewer。本スキルは説明で止まり、パイプラインを実行しない。

使い方と対象

• /plc-brief <Layerパス or L-ID> [詳しく知りたいこと]。Project名指定も可。Codexでは $plc-brief。
• 公開版には HTML モード（図解スライド）は無い。HTML を求められたら、文章の説明で返し、HTML は公開版に無いと伝える。
• 指定がなければ、この会話で直前に明示されたLayerを対象にする。曖昧なら候補を最大3件示して1問聞く。推測で別案件を選ばない。
• L-IDはリポジトリルートから rg で intent.yaml のトップレベル scope_id を検索し、YAMLを読んで完全一致を確認する。検索範囲は存在する Flow/・.ai-plc/projects/・Stock/、Documents/ 内のコピーは除く。RegistryのProject行はパス解決の補助に限り、最終的にintentのIDを確認する。重複パスなら本人に選んでもらう。
• 名前しかないときはProject Registryを限定照会する。対象不明ならローカルの候補最大3件だけを示し、0件なら不明と伝える。Registryが利用不能でも明示パスの説明は続けられる。
• 親ProjectとSubLayerは区別する。親を説明するときは関連する子のintent/backlogを必要な分だけ読み、未確認の子を明記する。親タスクのcompletedだけで子全体の完了を断定しない。

読むものと照合

共通規約は .claude/rules/ai-plc-system.md（§6/9/18）、ai-plc-session.md（§7.0/7.2/9.1）、ai-plc-adaptive.md（§6）。段階の細部が必要なら .claude/skills/ai-plc/0N-<stage>/SKILL.md を読む。

1. 確認時点を日時・タイムゾーン付きで記録する。intent.yaml と backlog.yaml を正本として読む。Goal/成功条件、status、workflow_depth、mode、説明設定、制約、各Taskのstatus・AC（無ければdescription）・依存・output、construction、decisions/refactoring_logを確認する。Registryのtasksは凍結された写しなので進捗の正本にしない。summaryや古い会話より実際のTask行を優先する。
2. context.yaml・必要な Context/・主要成果物そのもの・検証レポートを読む。成果物から用途、できること、入力/使い方、結果、利用条件を確認する。最初は主要な成果物・残件に関わるものを5〜10件以内に絞り、根拠が足りない箇所だけ追加で読む。Agent定義は必要なときだけ補足確認する。ファイルの存在だけで内容・品質を合格にしない。URLや参照先が読めないときはその部分を未確認とする。機密情報を外部へ送らず、説明のための外部検索・同期・ツール導入はしない。
3. 記録と実態を分ける。 completedのTaskについてoutputの実在・内容とACの証拠を照合する。証拠は対象版・確認日・検証範囲を確かめ、成果物が検証後に変わったら再検証済みとは言わない。更新日時の順序は疑いの手掛かりであり、版の同一性はハッシュ・snapshot等で確認する。自己申告やreviewerのNo findingsをAC充足・本人理解の証明にしない。全体完了は元Goalと成功条件にも照合する。
4. 根拠の欠落・古い記録・正本間の不一致・読めないYAMLを明記する。読めた範囲だけ説明し、欠落を0件・不要・完了とみなさない。古いという理由だけで未達とも断定しない。同時更新が見えたら関係ファイルだけ再読込し、安定した同一時点を確認できなければその限界を添える。

段階の照合（内部確認・要請時の補足）

以下は裏で状態を確かめる観点であり、通常出力の目次ではない。4段階の表・省略工程の列挙は、本人が工程や進め方を聞いたときだけ補足する。通常は「予約操作の手順をまとめたスキルができた」「比較資料は下書きまでできた」のように成果の状態へ翻訳する。段階を説明するときも必ず直線的に通るとみなさず、明示ログと実ファイルを照合する。単一のStageを断定できなければ、分かる状態を具体的に書く。

段階（正式名）	裏で確認すること（段階を聞かれたら説明）
Collection（背景を集める）	なぜ始めたか、誰の何を解決するか、収集済みの背景・制約・出典、その不足や未確定の前提。資料があっても内容の確認/合意は別。
Inception（目的と進め方を決める）	Goal/成功条件、何に分けたか、順番・依存・担当、採った進め方と理由、未承認の案。backlogが空なら未分解かsimpleで省略かをログから区別。
Construction（必要なAgent定義を準備する）	このリポジトリでは実行指示を作る段階。construction.tasks と実在するAgent定義・command_template_refを照合し、準備・整合確認・残件を説明。本体成果物の作成/検証はOperation。定義があるだけで実行済みにしない。
Operation（実作業と検証を進める）	出来た成果物と使える範囲、AC達成/一部/未達/未確認と証拠、未完了・blocked/deferred・再検証・本人作業、問題と完了の条件/見通し。継続運用なら直近の運用記録と未観測範囲も示す。

• Constructionの要否はRUL_plc_adaptive §6が正。construction.tasksを正とし、requiredとの食い違いは指摘する。欄のない既存Layerはrequired:false・tasks空として扱い、Agentがないだけで停止中とは言わない。simpleのInception省略やConstruction不要はログ/規則を根拠に「省略」「不要」、未着手は「未着手」、証拠がなければ「未確認」と区別する。
• pipeline_variant: jev が残っていても本体版の用語で説明する。Jev監視のAPI・判定・accept/rejectは実行しない。自動承認ログはAIの選択であり本人の承認と区別する。

出力

通常は、目的と今の状態が分かる短い冒頭に続けて、内容ごとの段落と意味の分かる短い見出しで説明する。複数の論点があるときは見出しで切り分け、一つの短い説明に長い目次を足さない。以下の意味を成果物と本人の質問に合わせてつなぎ、固定見出しや全項目の表を義務にしない。

必要な専門用語・略語・管理用の番号は、最初の登場時に日常の言葉で意味と今回の関係を補う。正式名への展開だけで済ませず、不要な番号は通常説明に出さない。元資料に意味の根拠がない場合は推測で埋めず、分かる内容と未確認の点を示す。誰が何をするか、なぜその課題にその対応をするかという前提も、理解に必要な分だけ補う。

目的・今使える範囲・重要な残件・本人が判断する点など、読み手が見つけたい要点を短く太字にする。段落全体、全見出し、細部の数字まで強調せず、飾りのための記号や色を増やさない。読みやすさの印象から、本人が内容を理解した・自分で説明できると推定しない。

主な成果物を理解・利用するのに関係しない別Taskの終了経緯や調査の細部は省く。重要な未検証は関係する本文で一度説明し、同じ注意点を末尾で再列挙しない。実行環境の導入手順や自動検出の話は、利用に支障がある場合や聞かれた場合だけ補足する。使い方は自然な依頼例を先に示し、ファイルを読み込ませる操作から説明を始めない。

1. どんなPJか: 誰のどんな困りごとを、どう解決しようとしたか。背景の長い経緯より目的を先に置く。
2. 結局何ができたか: 成果物の名前と内容、今できること。スキルなら対応する依頼・本人が渡す情報・返る結果、資料なら何を判断/実行するために使うかを説明する。未完成なら下書き/準備済みの範囲と目指す完成形を分け、設計した機能を実動作で確認済みとは言わない。
3. どう使うか: そのまま試せる依頼例や利用場面を1つ示す。例は実成果物が対応する入力/条件に沿わせる。成果物が不明/読めないときは使い方を捏造せず、分かる用途と確認に必要なものを伝える。説明のために依頼例の操作を実行しない。
4. 何に役立ちそうか: これまでの手間や迷いがどこで減るか、判断や作業がどう変わるかを、成果物の仕組みに結びつけて説明する。期待効果は推論だと分かる言葉（「〜が期待できます」「〜を狙っています」）で示し、実測効果と分ける。測っていない削減時間/成功率や「ミスがなくなる」等の保証を作らない。
5. 今の状態と重要な残件: 使う/判断するうえで影響する未完成・未検証・制約と、本人が決めることがあれば短く添える。技術調査の細部は、その人の使い方への影響に翻訳する。例えば時間初期値の違いは「希望の予約時間どおりになっているか確認する手順を入れた」と説明できる。

intent.explanation.level（未指定reasoned、不正値は警告してreasoned）と今回の希望に合わせて詳しさを調整する。guidedでも工程表や用語の列挙を自動追加せず、今回のPJ・成果・利用例の理解を助ける説明を増やす。

裏では決定事項/仮説/本人判断、ACと証拠、確認時点/未確認範囲を照合する。通常出力では読み手の判断に影響する事実や不確実性を文章へ織り込み、固定の「決定事項」「仮説」「未確認範囲」一覧や全AC表を毎回付けない。承認記録がなければ承認済みとせず、自動選択と本人承認、本人担当Taskと承認待ちを分ける。本人の判断待ちが確認できたときだけ何を決めれば進むかを説明し、未確認の承認を「待ち」と断定しない。

主な成果物のリンクを説明の近くへ必要な分だけ添える。確認時点（日時・時間帯）やProject IDは最後の短い注記にまとめられる。重要な未検証・成果の不一致は注記へ隠さず、関係する成果/使い方の本文で説明する。裏で読む正本・Task ID・AC達成/一部/未達/未確認・検証版の対応は、詳しい根拠を求められたら示せるようにする。

Task完了件数、Registryの整合、記録処理の完了は通常の成果説明へ自動挿入しない。数字を求められたときは「記録上N/M件completed」と母数/意味を明示し、実成果やGoal達成率と分ける。根拠のない進捗率・納期を作らず、estimated_hoursの単純合計やdeadlineを完了予測にしない。見積不能なら何が分かれば見積もれるかを具体的に示す。

対象ごとの違いや、誰が何をして何を受け渡すかが文章だけでは追いにくい場面では、何を見せる図・比較表かを短く示して任意提案する。根拠にない人物・流れ・因果を描かず、図解を毎回の必須出力にしない。HTMLの別画面や追加ツールを前提にしない。新事実/因果/効果を足さず、公開や大量派生生成は行わない。

対話やクイズによる理解確認は本人が希望した時にだけ使う。確認したい内容・目的・本人の手間を先に示し、既知内容の説明し直しや採点を強制しない。読みやすさの自己申告と、内容を説明できたことの確認は別の結果として扱う。通常の説明を返して止まり、理解確認のためにパイプラインや業務操作を実行しない。

最終説明の末尾にも、共通session §7.4の最低出力「次のアクション」と「次のプロンプト」を短く付ける。現在の有効な次工程が分かればその開始文、終了/実行不能なら同節の終了文/読取依頼文を本文にそのまま出す。形式全体をStage完了報告へ変えず、plc-nextを必須の中継にしない。案内だけで次工程の実行・承認・記録変更をしない。

読取の境界

• intent/backlog/context/成果物/Registryのstatus・承認・説明設定を変更しない。ログ/キャッシュを書くコマンドも呼ばない。見つかった不一致は説明するだけで修復しない。
• 通常のStage/Task完了報告ではないため、説明の完了から対象Project完了やNext Action実行を宣言しない。必要なときだけ、変更相談は plc-consult、点検は plc-status-audit（読取のみ）への案内を添える。選択・承認の質問が必要なら共通§9.1に従うが、判断待ち一覧の説明だけで新しい承認質問を発行しない。
• AGENTS.mdによる依頼記録が必要な環境では、本スキルによる対象Projectの読取と、本人の既存承認に基づく正式Collection/Backfillの記録を別工程として扱う。説明先へのTask追加やstatus変更を本スキルから行わない。記録先の報告が必要でも、成果説明の後に短い注記/リンクだけを添え、記録件数やPropagationを説明の主役にしない。