narrative-portfolio

name	narrative-portfolio
description	LAPRAS MCPを起点に、外部ソースの横断調査・本人へのヒアリング・デザイン方向の提案・実装までを一気通貫で行い、その人にしかない「ナラティブ・ポートフォリオ」（キャリアを物語として体験させる自作Webページ）を作り上げる。ユーザーが「narrative-portfolio」「ナラティブポートフォリオを作りたい」「LAPRASのデータで自分のポートフォリオ/年表/キャリアの物語を作って」と言ったら必ず使う。LAPRAS MCPが設定されている環境で、ポートフォリオ・経歴の可視化・自己紹介ページ・キャリアの振り返りコンテンツの相談を受けたときも、明示的な指名がなくてもこのスキルを提案する。

narrative-portfolio

LAPRAS MCP のデータを「地図」に、外部ソースを深く読み込み、本人と対話しながら、その人専用のナラティブ・ポートフォリオを作る。

このスキルの価値は3点に集約される。作業全体を通してこの3点を守ることが、個別の手順より重要。

1. 深さ — 一覧やスコアの表面ではなく、README・記事本文・取材記事まで読み、本人すら整理していない物語の構造（転機・円環・伏線）を掘り出す
2. 事実性 — 全ての記述に出典を付け、捏造をゼロにする。出典で裏づけられない魅力的な話より、裏づけのある地味な事実
3. 形式 — 表現形式そのものを人物に合わせて発想する。形式は「その人らしさ」の一部であり、テンプレートの流用ではナラティブにならない

前提条件

• LAPRAS MCP がセットアップ済みであること（社内手順: https://github.com/lapras-inc/scouty/issues/33121#issuecomment-4920523716 。MCPの設定方法は使っているエージェントごとに異なる）
• 成果物は依存ゼロの静的ファイル+相対パスで作り、ローカルで閲覧する（HTMLを file:// で直接開ける状態が完成形）。デプロイはスキルの範囲外
• python3 や Chrome は「あれば使う」。無い環境向けの代替手順を各フェーズに用意してある

進め方の原則

フェーズの手順より先に、振る舞いの原則を示す。それぞれが防ごうとしている失敗パターンと理由は references/quality-guardrails.md にある。作業開始前に必ず読むこと。

また、各フェーズに着手する前に references/phase-examples.md の該当節を読む。会話の粒度・止まり方・成果物の形の見本がフェーズ別にある（例はすべて架空の人物。内容の流用は禁止で、参考にしてよいのは形式と粒度だけ）。

• チェックポイントで必ず止まる。方向性の選択・決定書・初稿トーンの3箇所は、本人の反応を待ってから次に進む。先回りの作り込みは品質ではなく事故を生む
• 本人の質問には、まず答える。質問が来たターンは会話として完結させ、作業ツールを並走させない
• トークンを大きく消費する処理（一括リサーチ等）は、対象・規模・概算を示して本人のGOを得てから
• 成果物や候補は小さく出して反応を待つ。複数案を頼まれてもいないのにフル実装しない
• 成果物や候補を見せるときは、開くところまで自分でやる。Phase 0 の能力チェックで確認した手段（ブラウザ操作 → OS標準ブラウザで開くコマンド）の順に試し、どれも使えない環境でだけファイルリンクと最短の開き方を提示する
• 本人向けの提示は進行ハブ（hub/index.html）に統一する。画面はスキル同梱のテンプレート（assets/hub/ をコピー）で固定し、エージェントが更新するのは hub-data.js だけ（テンプレートの編集は禁止 — 走行ごとに出力が変わると実験にならない）。フェーズの節目ごとにハブを更新して開き直し、TUIは短い通知と決定の受け取りに使う。報告の中身は「現在地・分かったこと・決めてほしいこと」で、内部作業ファイルのパス列挙を主役にしない。詳細は references/progress-hub.md
• 推測を事実のように書かない。分からないことは「分からない」とし、取得できなかったソースは取得できなかったと記録する
• チェックポイントとGO確認を通過するたび、作業ディレクトリの log.md に1〜3行追記する。各フェーズの開始と終了も日時つきで1行ずつ記録する（Phase 7 の所要時間はこの記録から算出する。記録が無ければ所要時間は「不明」と書くしかなくなる）。書式は固定: - 2026-07-24 15:30 [タグ] 内容、タグの語彙は P0開始〜P7終了・CP1・CP2・CP3・GO・能力・逸脱 のみ。作業が中断してエージェントが交代しても、このログと作業ファイルだけで再開できるようにするため。Phase 7 のプロセス記録もここから埋める
• スキルの手順自体への指摘・改善案が出たら、作業ディレクトリの skill-feedback.md に記録する（作品への感想とは分ける。観察したフェーズ・指摘・根拠となった出来事を書く）

全体の流れ

Phase	内容	止まる場所
0	接続確認と素材の厚み診断	診断結果を提示
1	調査（認識形成）	全件読解の前にGO確認・採点の前に coverage report
2	方向性提案（複数軸×複数案）	チェックポイント①: 本人が選ぶ
3	決定書	チェックポイント②: 本人が承認
4	素材収穫と帰属確定	—
5	実装（デフォルト1作品）	チェックポイント③: 初稿トーン確認
6	検証	—
7	鑑賞とフィードバック	完了

作業ディレクトリの構成（推奨）

散らかると本人にも自分にも現在地が分からなくなるので、作業ルート（例: narrative-portfolio-work/）を1つ作り、この構成で進める:

research/      identity.json・population.json・cards/（source card）・dossiers.json・used-claims.json
probes/        方向性提案の雰囲気見本と選抜ボード
assets/        収穫した素材と素材台帳（ledger.json）
site/          成果物（このフォルダ内だけで完結・相対パス）
review/        esa 添付用スクリーンショット
hub/           進行ハブ（assets/hub/ テンプレートのコピー+hub-data.js。references/progress-hub.md）
scripts/       検査スクリプト（スキル同梱 scripts/ のコピー。編集禁止）
log.md         進行ログ（能力チェックの結果+チェックポイント・GO確認ごとに1〜3行追記）
feedback.md    Phase 7 の回答（assets/feedback-template.md の形式）
skill-feedback.md  スキル自体への指摘の記録（出たときだけ）

Phase 0: 接続確認と素材の厚み診断

まず一度だけ、この環境で使える手段を確認して log.md に記録する（後続フェーズはこの記録を参照し、能力判定をやり直さない）: ブラウザ操作（in-app・MCP）／headless Chrome／python3／subagent 並列／画像の目視／質問UIツール／GUIでファイルを開くコマンド（macOS の open 等）。

LAPRAS MCP から職歴・アウトプット一覧・スキルタグを取得し、「この人の素材はどれだけ厚いか」を機械的に測って本人に提示する。

測るもの:

• 職歴・アウトプット・記事・登壇イベントの件数
• アウトプットから辿れる外部リンクの種別と数（GitHubリポジトリ／記事プラットフォーム／動画／個人・会社サイト）
• 画像素材の見込み（サムネイル・OGP・サイト内画像がどの程度ありそうか）

本人の氏名・組織名など、作品の主体を特定する文字列は canonical identity としてここで確定する: 本人運営の一次ソースを最低2件照合し、原文どおりの表記を根拠URLつきで research/identity.json に保存する。ローマ字からの漢字補完・記憶からの再構成は捏造として扱う。以後の全工程（source card・採点・見本・成果物・生成スクリプト）はこのファイルを参照する。方式は references/research-method.md。

あわせて調査の母集団を列挙する: 職歴・アウトプット・Selection・外部リンクの全件を挙げ、重複・fork・翻訳版・同一案件の複数記事を識別する（重要度はまだ決めない）。母集団の境界は「LAPRAS から直接到達できる一次ソース」と「案件を裏づける公式ソース」の一段階まで。一覧系ツールはページングを最終ページまで辿り、取得合計件数を LAPRAS プロフィール画面の表示件数と突合してから research/population.json に保存する（1ページ目を全集合と思い込むのが典型事故。方式は references/research-method.md）。

この診断は後のフィードバック集計で「結果の面白さが素材の厚みに依存していたか」を判断する母数になるので、数字で残す。素材が薄くても中止しない。薄いなりの規模（例: 短い1作品）を設計する材料にする。

この段階では表現形式の話をしない（形式の好みを聞くのも、候補を見せるのも Phase 2 から）。認識ができる前に形式を聞くと、本人の自己申告と過去の印象に引っ張られ、調査から発想する意味がなくなる。

最後に道具一式を設置する: スキルディレクトリの絶対パスを特定して log.md に記録し、assets/hub/ を作業ディレクトリの hub/ に、スキルの scripts/ を作業ディレクトリの scripts/ にコピーする。検査スクリプトは以後、作業ディレクトリ内のコピーを実行する（スキルの場所が特定できなければ本人に聞く。ハブ・検査スクリプトの自作や即興は禁止）。hub-data.example.js を hub-data.js に複製して初期化し、hub/index.html を開いて厚み診断の結果を見せる（手順は references/progress-hub.md）。

技術メモ: 環境によっては Node ベースの fetch が社内ネットワークの TLS 検査で失敗することがある。その場合は curl での直接取得に切り替える。python3 がシェルのラッパー等で壊れている環境では、/usr/bin/python3 など実体のパスで実行する。

Phase 1: 調査（認識形成）

方向性の提案より先に、対象者への確かな認識を作る。ここを薄くすると以降の全てが一般論になる。読む前に選抜しない — メタデータ（タイトル・スター数・OGP）で深掘り対象を選ぶと、表層シグナルの弱い重大ソースを落とす。順序は「全件を読む → 統合する → 採点する」。方式の詳細は references/research-method.md。

1. GO確認: 母集団の全件リストと規模を示し、読みの深さの選択肢を概算つきで提示して本人が選ぶ
2. 全件読解（パス1）: 母集団の100%について実コンテンツを開いて読み、統一形式の source card を書く（1カード=1ファイル research/cards/<id>.json。メタデータだけで読んだ扱いにしない）。10件前後のバッチで回し、カードを書くたび population.json の status を更新、バッチごとに残数を log.md に記録する（中断・再開は population.json の pending を数えるだけでできる）。subagent が使えれば種別ごとにバッチ分担、無ければ逐次。読めないソースはフォールバックを試し、ダメなら inaccessible と記録する。画像・動画素材の有無と内容の見当も source card に記録する
3. 統合と coverage report: 全カードを統合して時系列・反復テーマ・転機を抽出し、coverage report（全ソースのステータスと、分かったことの骨子）をハブで本人に提示する
4. 採点: coverage report の提示後に S/A/B/C を付け、採点ボード（S/A全件を画像付きで比較できるハブ画面）で本人に見せて調整してもらう。本人が昇格・降格を判断できる状態が提示の完了条件
5. 深掘り（パス2）: 対象と規模を再提示してGOをもらい、S級は全件必須で（A級は柱に使う可能性があるもの）、出典3値タグつきの「調査書」（research/dossiers.json）に昇格させる。出典タグ集計は調査書からしか作れないので、S級の昇格を省略すると実験の計測データが欠落する

Phase 2: 方向性提案（チェックポイント①）

認識ができてから、表現の方向性を複数軸×複数案で提案する。1案に絞って持っていかない。軸の例: 印刷物系／映像系／端末・ログ系／空間系／遊戯系 — ただし軸自体もその人の人物性から発想し直す。

• 各案は「捨てられる粒度」の雰囲気見本（静的HTML1枚など）で見せる。文字の説明でトーンを聞かない
• 実在の素材（実績・作品・数字）を一級市民として使う案を優先する。抽象的なデータ可視化より「実在の仕事の物理的な記録」の方が個人の説得力が出る
• 方向性は Phase 1 で記録したビジュアル実現性（使える素材の量と質）を踏まえて発想する。素材の裏づけがない方向を提案しない
• 過去事例の形式を候補に持ち込まない。過去に作られた事例の形式は「その人のための」答えであって、別の人の出発点にならない。過去の成果物の形式名を提案に混ぜることも、本人への質問に出すことも禁止
• AI slop の回避原則と、雰囲気見本の作り方は references/design-taste.md を読む
• 本人と一緒に選ぶ。決めるのは本人

Phase 3: 決定書（チェックポイント②）

作り込みに入る前に、1枚の決定書で論点を固定し、本人の承認を得る。含めるもの:

• 物語の背骨（起点・転機・クライマックス。すべて調査書の事実に基づき、各行に根拠 claim の id を併記する）
• 表現形式と規模（デフォルトは1作品。複数作品は本人が望んだ場合のみ）
• 素材の方針（実素材優先・AI生成画像は補助まで）
• やらないことリスト

Phase 4: 素材収穫と帰属確定

Phase 1 で存在と内容の見当を付けた素材候補から、採用するものだけを原寸で収穫し、帰属と利用可否を確定する。

• 画像・サムネイル等は curl 等の機械収集でよいが、使用前に全数を自分の目で見る（見切れ・低品質・無関係の混入を弾く）
• 帰属のハードルールを適用する: 一次ソースで被写体（何の写真か）が確定しない画像は使わない。使う画像は出典を画面内かキャプションに明示する。全素材を assets/ledger.json に台帳化する（列の定義は references/quality-guardrails.md が唯一の正）
• このルールの背景は references/quality-guardrails.md にある。安易に破ると捏造ポートフォリオになる

Phase 5: 実装（チェックポイント③）

• デフォルトは1作品。静的・依存ゼロ・相対パス（ローカルでそのまま開けることを最優先。ルート絶対パスは配信環境に依存するので使わない）
• 記述・数字・画像はすべて調査書と素材台帳から。出典のないコピーを書かない。氏名・組織名は research/identity.json の canonical 表記を参照し、生成スクリプトにリテラルで埋め込まない
• 成果物に事実（文・数字・固有名詞）を1つ書くたび、根拠 claim の id を research/used-claims.json に追記する（[{"claim_id": "...", "used_in": "site/..."}]）。Phase 7 の出典タグ集計はこのファイルから機械集計する。実装後に記憶でまとめて再構成するのは禁止
• 初稿のトーンが見える最小の状態で一度見せ、反応をもらってから残りを作る
• 使用モデル・消費トークンの概算・チェックポイントの通過記録を随時メモしておく（Phase 7 のテンプレに記入する）

Phase 6: 検証

「完成した」と言う前に機械検証を通す。目視だけの確認は当てにならない（縮小プレビューの目視は崩れを見逃す）。

1. 参照整合: python3 scripts/check_refs.py site（src/href に加えて srcset・CSS の url() も全数検査）。python3 が無ければ同じ検査を自分で全数行う
2. 固有名詞: python3 scripts/check_identity.py .。疑わしい出現を1件ずつ目視し、誤表記は identity.json の forbidden に、正当な出現は ignore に振り分けて、exit 0 になるまで再実行する（異表記0件が完了条件）。参照整合や schema 検証が通っても、本人の基本情報が正しいことの検証にはならない
3. 素材台帳の突合: python3 scripts/check_ledger.py .（site/ 内の全画像が台帳に載っていて use: true であること。台帳に無い画像の混入は捏造の入口）
4. レイアウト: python3 scripts/measure_layout.py site（全HTMLページを headless Chrome で機械測定。原本は無変更）。Chrome が無い環境の代替は references/verification.md
5. 目視: 崩れやすい箇所（固定幅×可変テキスト、画像まわり）を等倍で確認する

Phase 7: 鑑賞とフィードバック

1. 完成物を本人に見せる。開くところまで自分でやる（進め方の原則を参照）。相対パスで作ってあるので file:// 直開きで見られる。サーバ経由で見たければ出力ディレクトリで python3 -m http.server 8642 等でも可
2. 鑑賞が終わったら、references/feedback-questions.md の質問を一言一句そのまま・一問ずつ提示する（質問 1/7 形式で現在地を示す。質問UIツールがあれば使う。提示と回答の受け方の詳細は同ファイル。追加質問は最大2問まで）
3. 成果物のスクリーンショットを1〜3枚用意する（トップ+特徴的な箇所）。自分で撮れる手段（ブラウザ機能・headless Chrome）があれば撮って review/ に保存し、無ければ撮ってほしい箇所を指定して本人に依頼する。これは esa 上で品質を比較する材料になるので省略しない。案内では「撮影済みか・追加撮影が要るか・どのファイルを添付するか」をファイル名で明示する
4. 回答を assets/feedback-template.md の形式で md にまとめる。メタ情報（厚み診断・モデル・時間・トークン・チェックポイント記録・出典タグ集計・検証実施状況）はスキル側で実際の走行記録から埋め、本人には定性質問だけ答えてもらう。出典タグ集計は scripts/count_source_tags.py の出力を、所要時間は log.md のフェーズ開始・終了記録の合算を転記する。不明・未計測の値は推測で埋めず、空欄か「不明」と書く（このmdは実験データなので、それらしい値の創作が一番害になる）
5. まとめた md を本人に見せてから、esa へのコメント投稿を案内する（md本文+review/ の画像添付。添付するファイル名を列挙する）: https://lapras.esa.io/posts/16747 （自動投稿はしない。本人が目視してから自分で貼る）
6. 途中で中断した場合も、「どこで・なぜやめたか」の一行だけでも esa にコメントしてもらうよう案内する

リファレンス

• references/quality-guardrails.md — 帰属・事実性・進め方のハードルール（失敗パターン集つき）。作業開始前に読む
• references/phase-examples.md — フェーズ別の会話と成果物の見本（架空人物2名・内容の流用禁止）。各フェーズの着手前に該当節を読む
• references/research-method.md — 母集団の定義・全件読解と source card・coverage report・出典3値タグ・重要度採点
• references/design-taste.md — AI slop 回避・方向性提案の作り方・雰囲気見本の粒度
• references/progress-hub.md — 進行ハブ（本人向けWeb UI）の構成・採点ボード・フォールバック
• references/verification.md — 検証の手順（参照整合・固有名詞・レイアウト機械測定）
• references/feedback-questions.md — 固定フィードバック質問セットと、提示・回答の受け方
• assets/feedback-template.md — フィードバック回答 md のテンプレート
• scripts/check_refs.py — 参照整合チェッカー