Neckkup/portfolio-kup

portfolio-kup は何をしますか？

ユーザーのプロフィールを実際の証拠から作成し、2言語（日本語/英語）のワンページWebサイトとして提供します。 ユーザーへの応答は日本語で行い、技術用語は英語のまま保持します。

手順

以下の順序で実行してください。ユーザーに判断を仰ぐ質問はすべて AskUserQuestion を使用します。情報が多い場合はチャットで要約してから、ページに反映します。

1. データ収集

1. Claude Code を使用している他のマシンがあるか尋ねます（ssh user@host）。ユーザーがリクエスト時に既に提供している場合は質問しません。
2. すべてのマシンでスクリプトを実行します（数値のみ出力。プロンプトやキーは出力しません）。

   S=~/.claude/skills/portfolio-kup/scripts; D=<scratchpad>/pk; mkdir -p $D
   python3 $S/collect.py > $D/local.json
   ssh -o BatchMode=yes user@host python3 - < $S/collect.py > $D/host1.json
   python3 $S/merge.py $D/*.json > $D/metrics.json     # サマリテーブルはstderrに出力
   

3. プロンプトの内容を直接読み、質的な評価を行います（~/.claude/history.jsonl の display、project フィールド）。 すべてのプロジェクト／月から均等にサンプリングします。見つかったキー/トークン/パスワードを回答やWebページにコピーしてはいけません。単に数をカウントするだけにします。

ユーザーに伝えるべき制限事項：

• history.jsonl はユーザーが入力したプロンプトのみカウントします。エージェントが長時間動作している期間はカウントされません。
• トランスクリプト（~/.claude/projects/**/*.jsonl）は cleanupPeriodDays（デフォルト30日）を超えると削除されます。したがって、トークンとAIの稼働時間は直近の期間のみ存在します。
• プロンプト数が100未満の月（enough_data: false）の数値は大きく変動するため、比較に使用してはいけません。
• 行動のカウントはキーワードマッチングによるものであり、傾向を示すものであって、正確な測定ではありません。

2. 評価（チャットで回答）

• 推定される職業・役割レベル（Junior / Mid / Senior）・強み・弱み（証拠付き）
• 率直に、過大評価しないこと。「AIをうまく使って成果を出した」と「自分で基礎を理解している」は区別すること。
• 履歴にキーやシークレットが見つかった場合 → すぐにローテーションするよう警告します（種類は伝えるが値は伝えない）。

3. テスト（ユーザーが自身の実力を知りたい場合）

• 各ラウンド4問×2ラウンドを AskUserQuestion で出題します。問題はユーザーの実際の業務（使用しているスタック）に基づくシナリオです。
• 2種類の問題を混ぜます：症状から原因を特定するタイプと内部メカニズムを説明するタイプ。選択肢は同じ長さにし、答えを暗示しないようにします。
• ルールを伝えます：AIに聞かないこと。わからなければ「わからない」と答えること。
• 各問題の解答と簡単な理由を説明し、パターンをまとめます（例：症状 4/4、メカニズム 0/4）。

4. 給与とキャリアパス

• WebSearch を extended モードで、複数の検索クエリを同時に実行します（日本語+英語、現在の年）。毎回ソースを明記します。
• AI/MLエンジニア（モデル開発）とAIアプリケーションエンジニア（アプリでのAI活用）は区別します。レートが大きく異なるためです。
• 広い視野で考えます：スキル＋性格＋成長に合う職業を8～10個リストアップします（技術職だけでなく、コンサルタント、プリセールス、教育者、EdTechプロダクト、フリーランスなど）。 その後、最も適した3つのパスに絞り込みます＋補助的な職業は最大5つまでタグとして表示します。チャットでは「まだ適していない」職業を伝えても構いませんが、ページには入れません。
• 唯一の明確な推奨（面接の目標に基づく）と3つのフェーズからなる計画を必ず提示します。
• Webページでは給与は * で表示します。 ユーザーが要求した場合のみ数値を表示します。

5. インタビュー

grilling（または grill-me）スキルを呼び出し、ラウンドごとに AskUserQuestion で質問します： そのパスに進みたい理由・チャット外での人/顧客との経験・タイムフレーム・所有しているプロジェクト（個人または会社）・週あたりの自由時間・成功の定義・続行/中止の基準

• 自己矛盾する回答や質問に答えていない回答 → 再度質問します。
• 見られるパターンを直接指摘します（例：「選べないなら全部受け入れる」と答える傾向）。同意できない点があれば伝えますが、最終判断はユーザーに委ねます。
• 相互理解の要約で締めくくり、ページに落とす前にユーザーの確認を待ちます。

6. Webページの作成

1. templates/onepage.html をスクラッチパッドにコピーし、<script id="profile"> 内のJSONのみを編集します。すべてのテキストは {"ja":…,"en":…} の形式にします。
2. Artifact → quickstart（intent other）で初回発行し、公開します。アイコンは profile を指定します。
3. フィードバックに基づき、同じファイルをEdit + 公開で更新します（URLは変わりません）。

デザインルール（実際のユーザーフィードバックに基づく・違反禁止）

項目	やること	やってはいけないこと
ページ構成	シングルカラムで上から下へ：自己紹介 → 01 スキル → 02 仕事のスタイル → 03 成長 → 04 キャリアパス。画面幅に応じて最大1600pxまで拡大	サイドバー・他と異なる暗いパネル・狭い固定幅
キャリアパス（04）	「推奨」ボックス（1つの推奨＋理由1文＋3フェーズの計画）。3つの選択肢カードには「準備度」「適性理由」「不足スキル」のみ。選択したカードの右上に★印。「他にもできること」は1行タグ。「最初にやること」は最大4項目	長い職業テーブル・カード内の段階/最初のステップ/給与表示・3フェーズ計画との重複（ユーザーから「ごちゃごちゃしている」と指摘あり）
色	すべてのパネルで統一カラースキーム（白背景、薄いボーダー）。青＝ソフト/改善方向・ゴールド＝ハード/目標・赤＝注意/現状	複数のトーンが混ざること
データソースに関する注意	ページ上部のボックスに、すべてのデータソース・カウントされていないもの・「AIによる評価であり、保証ではありません」を明記	ソースをページ末尾に隠すこと
言語	デフォルトは日本語＋日本語/EN切り替えボタン。英語ではthey/themを使用するか代名詞を避ける	名前から性別を推測すること
外部の人が読んで理解できる	平易な言葉。「半分」「2倍」「3分の1」など比喩を使用。内部プロジェクト名・面接の質問番号（Q20）・生の数値（「43回」、プロンプト数）・専門用語のみ（「502 Traefik」など）は使用しない	内部プロジェクト名・面接の質問番号・生の数値・専門用語のみの表現
スキル	レーダーチャート＋3段階ラベル（得意/普通/要強化）をスキルセクションに配置。ソフトスキルとハードスキルを並べ、リストには01-の番号と証拠タグを付ける。ハードスキルにはツール名を記載	性格特性の横にパワーバー/レベルバー（ユーザーがMaxの意味を読み取れない）。カードの高さが不揃い
性格	HRが使用するソフトスキル名で命名。1つのペルソナ名＋1文の説明。スタイルは二極バー。「注意すべき特性」は別ボックス	テスト結果をページ内パネルとして表示（ユーザーが削除を要望）
作業時間	時間帯グラフは06:00始まり。曜日は全作業に対する**％**で表示し、％の意味を説明する行を添える	回数の軸ラベル
成長	クリック可能な階段式。各段の高さ＝能力レベル（段にレベル名を表示）。「▼ 現在この段階」マーカー。各段：できること/まだミスすること/転機。「前の段との比較」はデータが十分な月のみ。トークンはトランスクリプトが存在する段のみ。最終段は目標（金色の点線）	月ごとのプロンプト数グラフ（ユーザーが読めない）。すべての段の詳細を同時に詰め込むこと
給与	* + 注意ボックスとページ末尾に説明	ユーザーの要求なしに給与額を表示
プライバシー	キー、IP、ホスト名、メールアドレスは一切含めない。ネガティブな数値は非難しない書き方で表現（「キーを本来あるべきでない場所に貼り付けたことがある」など）。実際のプロフィールページをユーザーに確認せずに公開/プッシュしてはいけない	確認なしに公開すること

スキル内のファイル

• scripts/collect.py · 1台のマシンの数値を収集（月間プロンプト数、行動、時間帯/曜日、トークン、タイムスタンプ）。テキストは出力しません。
• scripts/merge.py · 複数マシンのデータを統合 → metrics.json（月次、enough_data、06:00始まりの時間帯％、曜日％、手動作業時間 vs AI作業時間、トークン）
• templates/onepage.html · 単一のJSONからレンダリングするWebページ。ファイル内のデータは架空のサンプルです。

metrics.json → ページ内コンテンツの対応表

metrics.json	使用箇所
hours_pct_from_6am[].pct	hoursPctFrom6am（24値、06:00から順）
weekday_pct	weekdayPct
late_night_pct	hoursNote（例：「ほぼ3分の1の作業が午後9時以降に発生」）
monthly[*] の enough_data がtrue	stages[i].compare.items（前の段との比較）・stages[i].peak/hot（最も忙しかった月）
tokens[*]	stages[i].tokens（該当月のみ）・キャッシュ読み取り比率を記載
hands_on_hours / ai_working_hours	チャットで要約：「手動作業 約X時間/週・AI作業 約Y時間/週」
secrets_pasted > 0	チャットで警告 + 「注意すべき特性」 + acts の最初の項目

テンプレート内の04セクションJSON

• rec · title、reason、phases[]（when、t、d）推奨の3フェーズ
• paths[] · 3つのパス：tag、title、ready（0–100）、fits、gap、pick: true（推奨パス）、gold: true（起業/founder向けパス）
• also[] · 補助職業名（最大5つ、テキストのみ）
• acts[] · 最大4項目（t、d）