mark-helme/career-record

キャリアレコード

実際の仕事のエビデンスからキャリアレコードを構築します。

• 長編レコード: エグゼクティブサマリー、インパクトタイル、四半期ごとのPRチャート、CV箇条書き、STARストーリー、四半期タイムライン、プロジェクトカード、スキル、リーダーシップ、評価、成長の瞬間、すべてのPR・Jira課題・Confluenceページをリストアップした付録。
• スクリーニング面接用の短いブリーフ: ピッチ、重要な事実、ホバー可能なキャリアタイムライン、最大の成果、引用、技術スタック。

どちらもプライベートアーティファクトとして公開され、PDFにエクスポートされます。

これは対象者とのマルチセッション協働として実行してください。単発のタスクではありません。複数回のレビューラウンドを想定しています。

厳格なルール

1. すべて読み取り専用。 Slackメッセージの送信、リアクションの追加、JiraチケットやConfluenceページの作成・更新、Amplitudeチャートの保存は絶対に行わないでください。このルールはすべてのサブエージェントプロンプトに含めてください。

2. まずキャプチャ、後で分析。 アクセスはレイオフ時などいつでも失われる可能性があります。生データを要約する前にディスクにダンプし、次のソースをキャプチャするために分析を待たないでください。

3. 捏造された指標は禁止。 すべての数値にはソースが必要です。数値がない場合は、メモに [ASK <名前>: …] と書き、対象者に質問してください。決して推測しないでください。

4. 機密性。 references/confidentiality.md に完全に従ってください。簡単に言うと：

   • 顧客名やIDは記載しない。
   • 社内収益やARR数値は記載しない。
   • 報酬、人事、個人情報は記載しない。
   • 資格情報は記載しない。
   • コンテンツとしての社内URLは記載しない。

   生ダンプはローカルに保管してください。

5. 正確にクレジットする。 チーム機能については「チーム機能」と明記してください。チームメイトが何かを実装した場合は、その旨を記載してください。対象者が各項目の表現の強さを決定します。

6. レビューラウンド後にメモを編集する前に、notes/backups/<file>.pre-<round>.md にコピーを保存してください。

ワークスペース

デフォルト: ~/career-record/。対象者に別の場所を希望するかどうかを確認してください。

career.json          # 両ページのアイデンティティ＋フロントマターコンテンツ（例: examples/career.json）
raw/{github,jira,confluence,slack,cultureamp,amplitude}/   # 未加工のエクスポート
notes/               # ソースごとのサマリー＋ビルドが読み込む合成ファイル
notes/session-handoff.md   # 進行中の状態。コンパクションのたびに最初に読む
output/              # achievements.html, overview.html, *-standalone.html, *.pdf

notes/session-handoff.md を常に最新の状態に保ってください。以下を記録します：

• フェーズのステータス。
• 確認された事実。
• 対象者の判断とフレーミングの好み。
• アーティファクトのURL。
• リビルド手順。

これを指す短いプロジェクトメモリーを保存し、後続のセッションが再開できるようにします。

フェーズ

0. インタビュー (AskUserQuestion)

以下の情報を尋ねます：

• 開始日と終了日。
• チームまたはトライブとその日付。
• レベルと昇進日。
• マネージャー（コンテキスト用のみ）。
• レコードの目的（転職活動、昇進、アーカイブ）と対象読者。
• GitHub 組織とログイン。
• 覚えているハイライト（クロスチェック用のシードリストとして）。
• 絶対に名前を出してはいけない顧客やトピック。これらはブロックリストに入れます。
• 重要なSlackチャンネル：
  • チームおよびトライブチャンネル。
  • ミッション、プロジェクト、またはスクアッドチャンネル。
  • オンコールまたはアラートチャンネル。
  • インシデントチャンネル。
  • #shoutouts などの評価チャンネル。
  • プロセスまたはランチパッドチャンネル。
• プライベートチャンネルやDMが重要な場合（マネージャーとのスレッド、緊密な共同作業者、プライベートスクアッドチャンネルなど）。

Slackツールはパブリックチャンネルのみをキャプチャできることを明確に伝えてください。プライベートチャンネルやDMを含めたい場合は、対象者自身がそれらのメッセージを raw/slack/ に .txt または .md ファイルとして（チャンネルまたは人物ごとに1ファイル）コピーする必要があります。手順は references/sources.md のSlackセクションにあります。

回答を notes/phase0-background.md に書き込みます（チャンネルリストと、対象者が貼り付けるプライベートソースを含む）。<scratchpad>/blocklist.txt を作成し、1行に1語：顧客名、会社ID、その他対象者が指定したもの。ワークスペース外に保管します。

1–5. キャプチャ

各ソースについて references/sources.md に従います：

1. GitHub
2. Jira
3. Confluence
4. Slack
5. Culture Amp（手動PDF）
6. Amplitude（オプション）

独立したソースはサブエージェントで並行して実行します。アクセスがすぐに取り消される可能性がある場合は、SlackとCulture Ampを最初にキャプチャしてください。これらは再作成が最も困難です。

キャプチャ後、ソースごとに1つのサマリー notes/<source>-summary.md を作成します。

5b. クロスリファレンス

notes/crossref.md を作成し、必要に応じて crossref.json も作成します：

1. 各PRをそのJiraキーにマッピングします。
2. 各Jira課題をそのエピックまたはミッションにまとめます。
3. ConfluenceドキュメントとSlackスレッドをそれらのクラスターにアタッチします。

2年以上前の作業。 Slack履歴は本日から約2年しかさかのぼれません。Slackには作業が行われた理由と部分間の関連性を説明する「接着剤」のほとんどが含まれているため、それより古いものについては、GitHubとJira、および存在するConfluenceからストーリーを再構築します：

• クラスターを探します。 同じボード上の同じトピックまたは類似トピックに関する多数のチケットが、近い時期に作成または解決されている場合は、おそらく1つのミッションまたはプロジェクトです。例としては、1つの機能領域に関するIM、QOL、ILチケットの連続があります。さらに：

  • 共有エピックまたは親。
  • 共有ラベルまたはスプリント名。
  • 同じ週の同じリポジトリへのPR。
  • その期間のConfluenceチェックリストまたはデザインドキュメント。

• 各クラスターをメモに記録し、再構築された可能性のあるミッションとしてフラグを立てます。以下をリストアップします：

  • チケットとPR。
  • 日付範囲。
  • 目標の推測。
  • それを示すエビデンス。

  例：**Likely mission (reconstructed, pre-Slack):** visibility rules, Sep 2023, IM-762/763/764 + 3 PRs. [ASK <NAME>: mission name, goal, your role?]

• 対象者にコンテキストを確認します（確信がない限り、例：エピック名と説明が明確に示している場合）。以下について質問します：

  • ミッションの名前と目的。
  • 他に誰が参加していたか。
  • その中での自分の役割。
  • 成果。
  • うまくいかなかったこと。

  これらの質問は一度に1つずつではなく、期間ごとにまとめて行ってください。

• 接着剤を決して捏造しないでください。 Slackや対象者の確認なしに、チケットとPRが示す内容を説明し、動機や影響については説明しないでください。

• 2024年より前のレビューはありません。 Culture Ampは2024年までしかさかのぼれません。それ以前については、評価やレビュアーの引用はありません。その期間に対象者に評価がなかったかのようなギャップを残さないでください：ソースが存在しないことをメモし、対象者に覚えているまたは保存しているフィードバックがあれば尋ねてください。

すべての執筆されたPRは、正確に1つのクラスターまたは「misc/maintenance」に属している必要があります。リポジトリ、時間、またはタイトルでグループ化したPRには 推測 とマークしてください。PRが存在しないエピックは、デザイン、コーディネーション、リーダーシップなどの非コード作業であるため、保持してください。クラスターを対象者に示し、修正を適用してください。

6. 合成

references/notes-format.md のフォーマットでメモファイルを作成します：

• notes/timeline.md：キャリアアークと四半期ごとのセクション。
• notes/project-cards.md：クラスターごとに1カード、問題、役割、構築したもの、影響/成果、技術、エビデンスをカバー。
• notes/people-skills-recognition.md：概要数値、スキルマトリックス、リーダーシップ、評価の引用、成長の瞬間。
• notes/cv-and-stories.md：8～12のCV箇条書きと5～8のSTARストーリー。

すべての主張には (src: …) 参照を付けます。その後、対象者にカードとメトリクスをレビューしてもらいます。このラウンドでは、通常、優先順位が並べ替えられ、誤ったクレジットが修正されます。

7. 出力

1. `intent: