Naming Skill

Name: Naming Skill
Author: NeverSight

ASecurity

日本語または英語の意図から、短い英語名の候補を作り、kebab-case、snake_case、camelCase、PascalCase、dot.case、path/case、CONSTANT_CASE など change-case 由来の形式へ整形する。ファイル、スラッグ、メモ、スクリプト、文書、短い技術成果物の命名に使う。ブランド名、商品名、長いタイトル、一般的な翻訳、命名形式の制約が関係しない用途には使わない。

207 stars

0 votes

0 copies

1 views

Added 9/4/2026

datapython

Security Analysis

A100/100

Scanned 9/4/2026

Install to Claude Code

$npx -y skills add NeverSight/skills_feed --skill naming-skill --agent claude-code

Installs into .claude/skills of the current project.

Are you the author of Naming Skill?

Add the live security badge to your README — it updates automatically with every re-scan.

[![Security: A — Skills Directory](https://www.skillsdirectory.com/api/skills/neversight-naming-skill/badge)](https://www.skillsdirectory.com/skills/neversight-naming-skill)

More formats (shields.io, HTML) on the badges page.

Download Zip

Files

SKILL.md

---
name: naming-skill
description: "日本語または英語の意図から、短い英語名の候補を作り、kebab-case、snake_case、camelCase、PascalCase、dot.case、path/case、CONSTANT_CASE など change-case 由来の形式へ整形する。ファイル、スラッグ、メモ、スクリプト、文書、短い技術成果物の命名に使う。ブランド名、商品名、長いタイトル、一般的な翻訳、命名形式の制約が関係しない用途には使わない。"
---

# 命名スキル

日本語または英語の意図から、短く扱いやすい英語名の候補を作る。

## ワークフロー

1. 希望する命名形式を確認する。
   - 単語の連結形式やケース形式が指定されていない場合は、候補を出す前に一度だけ聞き返す。
   - 選択肢は簡潔に提示する: `kebab-case`, `snake_case`, `camelCase`, `PascalCase`, `dot.case`, `CONSTANT_CASE`。
   - 指定形式が珍しい、曖昧、または説明が必要な場合だけ、`references/change-case-formats.md` を読む。
   - 変換仕様の細部が必要な場合だけ、`references/change-case-spec.md` を読む。

2. 命名対象の意図を抽出する。
   - 何を表す名前なのか、対象・用途・役割を特定する。
   - 日付、バージョン、拡張子、ディレクトリ指定は、ユーザーが含めたいと明示した場合だけ意味要素として扱う。
   - 拡張子付きの名前を決める文脈で拡張子が指定されている場合は、変換後にその拡張子を維持する。

3. 日本語入力は直訳ではなく、意味が自然に伝わる英語へ意訳する。
   - 辞書的な逐語訳より、用途が分かる自然な英語表現を優先する。
   - フォーマット前の英語語句は最大4語に収める。
   - `file`, `document`, `memo`, `data`, `new` のような汎用語は、区別に必要な場合だけ残す。

4. 候補を生成する。
   - アイデア出しを求められた場合は、3〜7個の候補を出す。
   - 1つだけ求められた場合は、最有力候補を1つ出す。
   - すべての候補は、連結される英単語を最大4語までにする。
   - 抽象語だけでなく、用途が分かる名詞・動詞を優先する。例: `invoice-summary`, `model-audit`, `user-feedback`, `release-notes`。

5. 候補生成と形式変換の責務を分ける。
   - エージェントは、日本語または英語の意図を最大4語の自然な英語語句へ圧縮する。
   - ローカルスクリプトは、その英語語句を指定された形式へ機械的に変換する。
   - 原則として、最終出力は `scripts/format_name.py "english phrase" --style "requested-style"` で作る。
   - 拡張子が指定されている場合だけ `--extension EXT` を付ける。
   - 数字分割、区切り文字上書き、先頭・末尾文字保持が必要な場合は、`--separate-numbers`, `--delimiter`, `--prefix-characters`, `--suffix-characters` を使う。
   - `camelCase` / `PascalCase` の数字結合が必要な場合だけ `--merge-ambiguous-characters` を使う。
   - スクリプトが「4語を超える」と拒否した場合は、英語語句を短くして再実行する。
   - 変換ロジックを変更した場合は、`scripts/verify_format_name.py` を実行して代表ケースを検証する。

6. 結果を返す。
   - 推奨名を最初に示す。
   - 必要に応じて、`短い`, `具体的`, `移植性が高い` などの理由を一言添える。
   - 拡張子、ディレクトリ、形式に関する仮定が結果へ影響する場合だけ、その仮定を書く。

## 形式判断ルール

- 形式指定がない場合は推測せず、必ず聞き返す。
- `ハイフン`, `ケバブ`, `slug`, `URL向け` は `kebab-case` と扱う。
- `スネーク`, `Python向け`, `underscore` は `snake_case` と扱う。
- `JS風`, `lower camel`, `キャメル` は `camelCase` と扱う。
- `クラス名風`, `upper camel`, `パスカル` は `PascalCase` と扱う。
- `環境変数風`, `定数風`, `大文字スネーク` は `CONSTANT_CASE` と扱う。
- `ドット区切り`, `設定名風` は `dot.case` と扱う。
- `ディレクトリに分ける`, `path case` は `path/case` と扱う。ただし、これは1つの名前ではなくパスを作る可能性があるため注意を促す。

## 品質基準

- ひと目で用途が分かる名前を優先する。
- 一時的な作業メモより、後から見ても意味が残る安定した概念を優先する。
- 不要な装飾、句読点、絵文字、全角文字、形式を壊す文字は避ける。
- `summary`, `notes`, `analysis`, `final` のように広すぎる名前は、より具体的な名詞がある場合は避ける。
- 拡張子付きの名前を求められ、ユーザーが拡張子を明示している場合だけ拡張子を維持する。

## エラーハンドリング

- 日本語テキストだけが与えられ、形式指定がない場合は、名前を生成する前に希望形式を聞く。
- 指定形式が未対応の場合は、`references/change-case-formats.md` を読み、近い対応形式を提示して選択を求める。
- 変換結果が直感とずれる場合は、`references/change-case-spec.md` を読み、ローカルスクリプトの仕様に基づいて説明する。
- 意味を表す英語語句が4語を超える場合は、修飾語を削って圧縮してから整形する。
- `path/case` が1つの名前として指定された場合は、ディレクトリ分割を意図しているか確認する。必要なら `kebab-case` を代案として提示する。

Attribution

NeverSight

View source More from NeverSight →

SSkills DirectorySkills Directory

Know which skills are safe — weekly.

Best new skills + every skill we flagged as malicious. From the team that scanned 103,619.

Join free

Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.

Comments (0)

No comments yet. Be the first to comment!

--- name: naming-skill description: "日本語または英語の意図から、短い英語名の候補を作り、kebab-case、snake_case、camelCase、PascalCase、dot.case、path/case、CONSTANT_CASE など change-case 由来の形式へ整形する。ファイル、スラッグ、メモ、スクリプト、文書、短い技術成果物の命名に使う。ブランド名、商品名、長いタイトル、一般的な翻訳、命名形式の制約が関係しない用途には使わない。" --- # 命名スキル日本語または英語の意図から、短く扱いやすい英語名の候補を作る。 ## ワークフロー 1. 希望する命名形式を確認する。 - 単語の連結形式やケース形式が指定されていない場合は、候補を出す前に一度だけ聞き返す。 - 選択肢は簡潔に提示する: `kebab-case`, `snake_case`, `camelCase`, `PascalCase`, `dot.case`, `CONSTANT_CASE`。 - 指定形式が珍しい、曖昧、または説明が必要な場合だけ、`references/change-case-formats.md` を読む。 - 変換仕様の細部が必要な場合だけ、`references/change-case-spec.md` を読む。 2. 命名対象の意図を抽出する。 - 何を表す名前なのか、対象・用途・役割を特定する。 - 日付、バージョン、拡張子、ディレクトリ指定は、ユーザーが含めたいと明示した場合だけ意味要素として扱う。 - 拡張子付きの名前を決める文脈で拡張子が指定されている場合は、変換後にその拡張子を維持する。 3. 日本語入力は直訳ではなく、意味が自然に伝わる英語へ意訳する。 - 辞書的な逐語訳より、用途が分かる自然な英語表現を優先する。 - フォーマット前の英語語句は最大4語に収める。 - `file`, `document`, `memo`, `data`, `new` のような汎用語は、区別に必要な場合だけ残す。 4. 候補を生成する。 - アイデア出しを求められた場合は、3〜7個の候補を出す。 - 1つだけ求められた場合は、最有力候補を1つ出す。 - すべての候補は、連結される英単語を最大4語までにする。 - 抽象語だけでなく、用途が分かる名詞・動詞を優先する。例: `invoice-summary`, `model-audit`, `user-feedback`, `release-notes`。 5. 候補生成と形式変換の責務を分ける。 - エージェントは、日本語または英語の意図を最大4語の自然な英語語句へ圧縮する。 - ローカルスクリプトは、その英語語句を指定された形式へ機械的に変換する。 - 原則として、最終出力は `scripts/format_name.py "english phrase" --style "requested-style"` で作る。 - 拡張子が指定されている場合だけ `--extension EXT` を付ける。 - 数字分割、区切り文字上書き、先頭・末尾文字保持が必要な場合は、`--separate-numbers`, `--delimiter`, `--prefix-characters`, `--suffix-characters` を使う。 - `camelCase` / `PascalCase` の数字結合が必要な場合だけ `--merge-ambiguous-characters` を使う。 - スクリプトが「4語を超える」と拒否した場合は、英語語句を短くして再実行する。 - 変換ロジックを変更した場合は、`scripts/verify_format_name.py` を実行して代表ケースを検証する。 6. 結果を返す。 - 推奨名を最初に示す。 - 必要に応じて、`短い`, `具体的`, `移植性が高い` などの理由を一言添える。 - 拡張子、ディレクトリ、形式に関する仮定が結果へ影響する場合だけ、その仮定を書く。 ## 形式判断ルール - 形式指定がない場合は推測せず、必ず聞き返す。 - `ハイフン`, `ケバブ`, `slug`, `URL向け` は `kebab-case` と扱う。 - `スネーク`, `Python向け`, `underscore` は `snake_case` と扱う。 - `JS風`, `lower camel`, `キャメル` は `camelCase` と扱う。 - `クラス名風`, `upper camel`, `パスカル` は `PascalCase` と扱う。 - `環境変数風`, `定数風`, `大文字スネーク` は `CONSTANT_CASE` と扱う。 - `ドット区切り`, `設定名風` は `dot.case` と扱う。 - `ディレクトリに分ける`, `path case` は `path/case` と扱う。ただし、これは1つの名前ではなくパスを作る可能性があるため注意を促す。 ## 品質基準 - ひと目で用途が分かる名前を優先する。 - 一時的な作業メモより、後から見ても意味が残る安定した概念を優先する。 - 不要な装飾、句読点、絵文字、全角文字、形式を壊す文字は避ける。 - `summary`, `notes`, `analysis`, `final` のように広すぎる名前は、より具体的な名詞がある場合は避ける。 - 拡張子付きの名前を求められ、ユーザーが拡張子を明示している場合だけ拡張子を維持する。 ## エラーハンドリング - 日本語テキストだけが与えられ、形式指定がない場合は、名前を生成する前に希望形式を聞く。 - 指定形式が未対応の場合は、`references/change-case-formats.md` を読み、近い対応形式を提示して選択を求める。 - 変換結果が直感とずれる場合は、`references/change-case-spec.md` を読み、ローカルスクリプトの仕様に基づいて説明する。 - 意味を表す英語語句が4語を超える場合は、修飾語を削って圧縮してから整形する。 - `path/case` が1つの名前として指定された場合は、ディレクトリ分割を意図しているか確認する。必要なら `kebab-case` を代案として提示する。