リポジトリ運用の指針

このリポジトリは、日本の就職活動と転職のための可搬な Agent Skills を管理する。キャリア相談、応募書類の添削、面接対策、企業研究、内定判断、おためし転職の体験・業務設計、副業の可否と案件条件の確認を対象とする。公開リポジトリであり、求職者本人が自分の Claude にインストールして使う。employer カテゴリでは求人企業の採用担当者・現場のマネージャー・経営者を対象とし、立場ごとにカテゴリを分ける。

構成

• スキルは skills/<category>/<skill-name>/SKILL.md に置く。
• カテゴリは career、documents、interview、research、offer、trial、employer、sidework のいずれか。定義は scripts/_repo.py の CATEGORIES だけにあるので、新設するときはそこを更新する。
• scripts/、references/、assets/ は、そのスキルの手順が実際に必要とする場合だけ追加する。
• 1スキル1作業を既定にする。 利用者が「今これをしたい」と言える単位で切る。offer の4スキル（条件確認、比較、辞退、退職段取り）が基準の粒度である。
• 複数の段階を1スキルに束ねてよいのは、次を両方満たすときだけ。 otameshi-candidate と trial-work-design がこれにあたる。
  • 分割すると description の起動条件が衝突する。同じ固有名詞（サービス名、制度名）でしか呼ばれない段階どうしは、分けても選び分けられない。
  • 段階の切り替えが利用者の1回の相談の中で起きる。別々の日に別々の判断として行う作業は、束ねずに分ける。
• 束ねたスキルは、段階ごとの手順をSKILL.mdに並べない。 ## 進め方 には依頼と参照の対応表だけを置き、段階ごとの成果物は各 references/ に持たせる。対応表がないまま段階が増えたスキルは、束ねる条件を満たしていないとみなす。
• 立場が違うものは必ず分ける。 求職者向け（trial）と企業向け（employer）は、同じ段階でも守るべき制約が違う。企業向けは募集前（業務設計、募集文、社内説明）、応募者対応、契約条件、振り返りを別々のスキルにする。
• スキル同梱の scripts/_common.py は生成物であり、直接編集しない。入力検証とCLIの定型は scripts/_common_source.py だけを編集し、python3 scripts/sync_common.py で配り直す。スキルは単独でインストールされ、skills/<category>/<skill-name>/ より上の階層は利用者の環境に届かないため、リポジトリ共通のモジュールを import できない。
• スキルを追加・改名・削除したら .claude-plugin/marketplace.json、READMEの収録スキル表、skills.sh.json の表示グループを更新する。検証スクリプトが3箇所すべての不一致を落とす。
• PLACEHOLDER や TODO が残った雛形をコミットしない。

執筆

• 名前は小文字とハイフンのみ、64文字以内、親ディレクトリ名と一致させる。
• description は「何をするか」と「いつ使うか」の両方を英語で書く（エージェントの検索用）。本文と参照資料は日本語で書く。
• SKILL.md は簡潔に保ち、条件分岐する詳細は references/ に逃がす。
• SKILL.md の節は ## 進め方、## 判断上の制約、## 個人情報と権限境界 の3つにする。検証スクリプトがこの3節を確認する。
• 冒頭の段落は、何をするかに続けて、このスキルが行わないことを書いて締める（「合否の予測、経験の創作、応募の代行は行わない」）。description の do not use to ~ と対応させる。
• 出力の雛形は references/report-format.md に置き、## 進め方 からは参照するだけにする。SKILL.md に表や見出し構成を書かない。段階を束ねたスキルは、段階ごとの references/ が各自の成果物仕様を持つため、この1本を置かなくてよい。
• 次に渡すスキルの案内は references/report-format.md の引き継ぎ節に置く。SKILL.md と両方に書かない。
• 同梱スクリプトは ## 進め方 の中で、それを使う工程として案内する。専用の節を作らない。
• ## 個人情報と権限境界 の節を置き、外部への行為を勝手に実行しないことを本文で約束する。検証スクリプトが節の有無と約束の記載を確認する。文面はスキルごとに変えてよく、注意すべき点が違うので揃えない。
• 手順を固定しすぎない。妥当なやり方が複数ある場面では、判断基準と確認できる成果物で書く。
• 制度・法令・給与相場・採用慣行など時点に依存する事実は、必要なときに一次情報を確認する。記憶で断定しない。

個人情報（最優先）

• 実在する求職者の応募書類、氏名、連絡先、学歴・職歴、選考状況をコミットしない。公開リポジトリなので、一度入れば取り消せない。例示は明らかに架空の内容にする。
• スキルは、作業に必要な範囲を超えた個人情報を収集・保存・出力しない設計にする。
• 検証スクリプトはメールアドレス、電話番号、12桁数字らしき文字列を検出して落とす。回避せず、内容を架空のものに置き換える。
• 開発中の添削作業の入出力は private/ 以下（.gitignore 済み）か、リポジトリ外で扱う。
• スキル自体も、利用者が明示的に求めない限り、原稿や添削結果をファイルに残さない設計にする。

権限境界

すべてのスキルは、応募の送信、企業・採用担当者・エージェントへの連絡、求人サイトや ATS の登録・更新、面接日程の確定、退職手続き、副業の申請・届出の提出、発注者への受諾の返信や契約の締結を自動実行してはならない。実行直前に、対象・内容・時期・影響を示して利用者の明示的な承認を得る。

trial と employer は相談・原稿作成・運用準備のみを行う。企業側から候補者への連絡、契約の締結、支払いも含め、掲載・応募・送信・日程確定などの外部操作は利用者本人が行う。employer は、成果への満足や採用判断を支払いの条件にする定めや、職務と無関係な属性による選別を作らない。

合否や通過率の予測、労働法・税務の専門的判断を断定的に示さない。sidework は、就業規則の適法性や有効性を判定せず、勤務先に知られないための手順や、申告・届出を避ける方法を作らない。

検証

スキルを変更したら次を実行する。

python3 scripts/validate_skills.py && python3 scripts/run_tests.py

validate_skills.py は配布した _common.py が単一ソースと一致するかも調べる。ズレたら python3 scripts/sync_common.py で配り直してコミットする。

新規または大幅に変更したスキルは、現実的な依頼で実際に動かし、見出しや文言だけでなく出力を確認する。