resume-improver
Skill0 starsChanged 32 days agoMITView on GitHub
日本語の職務経歴書を採用担当者・現場マネージャーが短時間で評価しやすい形に診断、推敲、再構成するスキル。職務経歴書、レジュメ、CV、キャリアの棚卸し、応募書類の添削・改善・短縮、実績の整理について依頼されたときは、明示されなくても必ず使う。直近の強みを先に伝える逆時系列サマリーと、根拠を保つ Appendix の二段構成で改善する。
In this repository13 other files it gives its agents.
- ai-credit-efficient-reviewSkill
- branch-tldrSkill
- drafting-tweet-from-todaySkill
- finding-unused-customizationsSkill
- hacker-news-digest-jaSkill
- japanese-tech-writingSkill
- natural-japaneseSkill
- pr-branch-composition-checkSkill
- prompt-feedback-skillSkill
- semantic-commit-helperSkill
- session-stockerSkill
- syncing-forked-skillsSkill
- tf-destroy-plan-inverterSkill
The file
Files
職務経歴書の改善
職務経歴書は、採用側が候補者に初めて触れる成果物である。 読み手は限られた時間で「現在できること」「どの規模・文脈で成果を出したか」「深掘りしたい点」を判断する。 経歴を時系列に漏れなく並べるのではなく、直近の役割と本人の成果を先に届け、詳細は後段で参照できるように再構成する。
入力を確認する
職務経歴書本文、経歴メモ、LinkedIn の内容、箇条書きの実績を素材として扱う。
次の情報が不足し、正確な改訂案を作れない場合だけ、最小限の質問をする。
- 各社の在籍期間、役割、雇用形態
- 本人が担った行動・意思決定と、組織やプロジェクト全体の成果の区別
- 成果の根拠となる数値、対象規模、比較基準
- 応募先の職種・レベル、または強調したい専門性
素材が不完全でも、わかる範囲で構成案と草案を作る。
事実が確認できない箇所を推測や創作で埋めず、[要確認: ...] と明示する。
改善の手順
- 現在の職務、直近の実績、応募先との関連性を特定する。
- プロジェクト説明・組織の成果・本人の貢献を切り分ける。本人の役割、働きかけ、結果がつながる形にする。
- 読み手が最初に判断すべき情報だけをサマリーへ置き、残りの文脈を Appendix に移す。
- 両セクションを新しい経歴から古い経歴への逆時系列で並べる。
- 実績を「論文タイトル程度」の、簡潔で具体的な見出しにする。数値と定性的な影響を適切に組み合わせる。
- 誤解を生みやすい主張、根拠のない比較級、本人の貢献が不明な記述を修正または
[要確認]とする。
情報を削る目的は経歴を薄めることではない。 初見の読者が興味を持つ経験へすぐ到達でき、その後に必要な深さで検証できるように情報へのアクセスを設計する。
推奨する構成
原則として、以下の構成で Markdown の改訂案を作る。 ユーザーが指定した応募書式や出力形式がある場合は、それを優先しつつ、この情報設計を維持する。
# 職務経歴書
最終更新日:YYYY-MM-DD
氏名:氏名
## 主な職務経歴(サマリー)
### 会社名(YYYY/MM - 現在または YYYY/MM)
- 役割:役職、責任範囲
- 成果・実績:
- 成果が伝わる簡潔な見出し
- 成果が伝わる簡潔な見出し
### 前職の会社名(YYYY/MM - YYYY/MM)
- 役割:役職、責任範囲
- 成果・実績:
- 成果が伝わる簡潔な見出し
## 業務外の経歴
- 資格・認定:取得年月、資格名
- アウトプット・登壇:記事、登壇、OSS、書籍、コミュニティ活動とリンク
## Appendix 職務経歴詳細(逆時系列)
### 会社名(YYYY/MM - 現在または YYYY/MM)
- 会社規模:社員数、事業規模など(時点を添える)
- 組織構造:所属組織、チーム規模、レポートライン
#### プロジェクトまたはチーム名(YYYY/MM - YYYY/MM)
- 案件規模:人数、対象ユーザー、予算など
- 役割:具体的な責任と権限
- 技術スタック:使用技術・ツール
- 背景・課題:
- 取り組み:
- 成果・実績:セクションごとの基準
主な職務経歴(サマリー)
- 会社ごとに「役割」と「成果・実績」だけを残す。
- 直近の経歴を最初に置く。
- 成果は箇条書きにし、一読で深掘りしたくなる粒度に留める。
- 役職名だけで責任範囲が伝わらない場合は、対象組織・プロダクト・意思決定範囲を短く補う。
- 「AWS コストを年間 18% 削減」「開発組織共通のリリースルールを制定」のように、結果または介在価値が見える表現にする。
- 数字がないこと自体を問題にしない。信頼できる定性成果は残し、数値を捏造しない。
業務外の経歴
- 業務外の資格、執筆、登壇、OSS、コミュニティ貢献を独立してまとめる。
- 会社の業務として行った活動は、対応する職務経歴へ記載する。
- 単なる URL の列挙ではなく、テーマ・役割・到達点を短く添える。
Appendix 職務経歴詳細
- サマリーの成果を検証・深掘りするための文脈を置く。
- 会社規模と組織構造を示し、役職名だけではわからない課題の規模を伝える。
- 各プロジェクトで、背景、本人の役割、取り組み、成果を区別する。
- 技術スタックは、成果や担当範囲の理解に役立つものを優先する。羅列だけにしない。
- 古い経歴は、現在の応募先に関係する知見を保ちつつ、最新の経歴より簡潔にしてよい。
出力形式
依頼内容に応じて、次をこの順で返す。
- 改善ポイント:現状の読み手負荷、埋もれている強み、確認が必要な情報を 3〜7 件で示す。
- 改訂案:上の構成に沿った、そのまま編集・転記できる Markdown を提示する。
- 確認事項:事実の裏付けや応募先に応じた調整が必要な箇所だけを列挙する。
「添削だけ」「構成だけ」など範囲が指定されている場合は、その範囲に絞る。 原文を無断で省略して情報を失わせない。何をサマリーから Appendix に移したか、重要な再表現をしたかは改善ポイントで説明する。
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

