# リポジトリ運用の指針 このリポジトリは、日本の就職活動と転職のための可搬な Agent Skills を管理する。キャリア相談、応募書類の添削、面接対策、企業研究、内定判断、おためし転職の体験・業務設計、副業の可否と案件条件の確認を対象とする。**公開リポジトリであり、求職者本人が自分の Claude にインストールして使う。`employer` カテゴリでは求人企業の採用担当者・現場のマネージャー・経営者を対象とし、立場ごとにカテゴリを分ける。** ## 構成 - スキルは `skills///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///` より上の階層は利用者の環境に届かないため、リポジトリ共通のモジュールを 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` は、就業規則の適法性や有効性を判定せず、勤務先に知られないための手順や、申告・届出を避ける方法を作らない。 ## 検証 スキルを変更したら次を実行する。 ```bash python3 scripts/validate_skills.py && python3 scripts/run_tests.py ``` `validate_skills.py` は配布した `_common.py` が単一ソースと一致するかも調べる。ズレたら `python3 scripts/sync_common.py` で配り直してコミットする。 新規または大幅に変更したスキルは、現実的な依頼で実際に動かし、見出しや文言だけでなく出力を確認する。