polish

name	polish
description	職務経歴書（docs/README.md）全体の文章と構成を底上げする。文体の統一・冗長の削減・成果の訴求力・粒度の一貫性・読み手目線を診断し、優先度つきで具体的なリライト案を提示してから反映する。文章を整えたい・構成を磨きたい・推敲してほしいと頼まれたら使う。

職務経歴書 文章・構成 底上げスキル

resume スキルが「実績の棚卸し（update）」「ベストプラクティス監査（audit）」「lint と PDF（build）」を担うのに対し、 このスキルは 既にある文章そのものの質 を磨く。情報を足すのではなく、いまの内容をより伝わる形に整えるのが役割。

対象ファイル

• 本体: docs/README.md … 職務経歴書。ここだけを編集する
• 触らない: ルート README.md（GitHub プロフィール用）
• lint 設定: config/.textlintrc.json, config/.markdownlint.jsonc（最終的にこれを通せる文章にする）

まず docs/README.md を通して読み、全体像を掴んでから始めること。

進め方

診断 → 優先度つき提案 → 同意を得て反映 の順で回す。1回の実行では 欲張らず 1〜3 箇所 に絞って確実に良くする。 残りは次回に回す（継続的な底上げが前提）。情報を新たに足したくなったら、それは resume の update の仕事なので越境しない。

1. 診断（6つの軸で読む）

各軸を ✅（良い）/ ⚠️（要改善）/ ❌（弱い）で評価し、根拠となる該当箇所を引用する。

1. 構成・流れ … セクション順序は読み手（採用担当）の知りたい順か。重複・脱線がないか。 見出し階層が論理的か。職務要約 → 基本情報 → スキル → 職歴 → 資格の導線が自然か。
2. 文体・トーンの統一 … 常体/敬体、語尾、絵文字の使い方、カタカナ語や英数字の表記が職歴間で揃っているか。
3. 成果の訴求力 … 受動的な記述を能動的に。動詞を強く（「対応した」→「設計した／主導した」）。 結果が埋もれていないか。「何をしたか」より「どう良くなったか」が前に出ているか。
4. 粒度・一貫性 … 各実績が同じ構造（課題 → 施策 → 成果）で揃っているか。 実績ごとの分量・詳しさのバラつきが大きすぎないか。
5. 簡潔さ … 一文が長すぎないか。冗長表現・二重否定・同義の繰り返しがないか。 箇条書きにできる説明文を地の文で書いていないか。
6. 読み手目線 … 流し読みで 3 秒で要点が掴めるか。専門用語に文脈の補足があるか。 太字・見出しが効果的に効いているか（太字の乱用で逆に埋もれていないか）。

2. 提案

• ❌ → ⚠️ の順に優先度を付け、「現状 → 改善案」 の形で具体的な文面まで示す。
• リライトは意味を変えない。事実・数値・固有名詞を勝手に足さない／盛らない。 情報の追加が必要だと感じたら「これは update 案件」と切り分けて伝える。
• 現職などぼかしたい意向が既に示された箇所は尊重し、表現の改善に留めて内容を膨らませない。

3. 反映

• ユーザーの同意を得てから docs/README.md を編集する。
• 編集後、構成セルフチェック（見出し階層・テーブル崩れ・リンク切れ）を行う。
• 仕上げの lint・PDF 生成は resume の build に委ねる（このスキルでは実行しない）。必要なら誘導する。

注意（公開リポジトリ）

公開リポジトリのため、社外秘・機密・特定可能な個人情報・誇張表現を増やさない。 リライトで踏み込みすぎない。迷ったらユーザーに確認する。

完了時

底上げした箇所を要約し、gitmoji + Conventional Commits 形式のコミットメッセージ案を提示する （例: docs: :art: 実績の訴求力と文体を底上げ）。コミットはユーザーの指示があるまで行わない。