jpskill.com
🛠️ 開発・MCP コミュニティ

clean-typescript

TypeScriptで、一般的によいとされる書き方に沿って、読みやすく効率的なコードを作成し、保守しやすい状態に保つSkill。

📜 元の英語説明(参考)

Write clean, efficient TypeScript code that follows common best practices

🇯🇵 日本人クリエイター向け解説

一言でいうと

TypeScriptで、一般的によいとされる書き方に沿って、読みやすく効率的なコードを作成し、保守しやすい状態に保つSkill。

※ jpskill.com 編集部が日本のビジネス現場向けに補足した解説です。Skill本体の挙動とは独立した参考情報です。

⚡ おすすめ: コマンド1行でインストール(60秒)

下記のコマンドをコピーしてターミナル(Mac/Linux)または PowerShell(Windows)に貼り付けてください。 ダウンロード → 解凍 → 配置まで全自動。

🍎 Mac / 🐧 Linux
mkdir -p ~/.claude/skills && cd ~/.claude/skills && curl -L -o clean-typescript.zip https://jpskill.com/download/9092.zip && unzip -o clean-typescript.zip && rm clean-typescript.zip
🪟 Windows (PowerShell)
$d = "$env:USERPROFILE\.claude\skills"; ni -Force -ItemType Directory $d | Out-Null; iwr https://jpskill.com/download/9092.zip -OutFile "$d\clean-typescript.zip"; Expand-Archive "$d\clean-typescript.zip" -DestinationPath $d -Force; ri "$d\clean-typescript.zip"

完了後、Claude Code を再起動 → 普通に「動画プロンプト作って」のように話しかけるだけで自動発動します。

💾 手動でダウンロードしたい(コマンドが難しい人向け)
  1. 1. 下の青いボタンを押して clean-typescript.zip をダウンロード
  2. 2. ZIPファイルをダブルクリックで解凍 → clean-typescript フォルダができる
  3. 3. そのフォルダを C:\Users\あなたの名前\.claude\skills\(Win)または ~/.claude/skills/(Mac)へ移動
  4. 4. Claude Code を再起動

⚠️ ダウンロード・利用は自己責任でお願いします。当サイトは内容・動作・安全性について責任を負いません。

🎯 このSkillでできること

下記の説明文を読むと、このSkillがあなたに何をしてくれるかが分かります。Claudeにこの分野の依頼をすると、自動で発動します。

📦 インストール方法 (3ステップ)

  1. 1. 上の「ダウンロード」ボタンを押して .skill ファイルを取得
  2. 2. ファイル名の拡張子を .skill から .zip に変えて展開(macは自動展開可)
  3. 3. 展開してできたフォルダを、ホームフォルダの .claude/skills/ に置く
    • · macOS / Linux: ~/.claude/skills/
    • · Windows: %USERPROFILE%\.claude\skills\

Claude Code を再起動すれば完了。「このSkillを使って…」と話しかけなくても、関連する依頼で自動的に呼び出されます。

詳しい使い方ガイドを見る →
最終更新
2026-05-18
取得日時
2026-05-18
同梱ファイル
1

📖 Skill本文(日本語訳)

※ 原文(英語/中国語)を Gemini で日本語化したものです。Claude 自身は原文を読みます。誤訳がある場合は原文をご確認ください。

TypeScript の整理

TypeScript は、形式的なものではなく、正確性と明確性を高めるためのツールとして使用します。 型はバグと認知負荷を軽減するものであるべきです。

型の哲学

  • 賢すぎる型や過度に汎用的な型よりも、明示的で読みやすい型を優先します
  • any と安全でない型アサーションは避けます
  • 必要に応じて any の代わりに unknown を使用します
  • 推論が明確で安定している場合は、TypeScript に型を推論させます

型とインターフェース

  • ほとんどの場合、type エイリアスを優先します
  • interface は主に、公開され、拡張可能なオブジェクトの形状に使用します
  • 型は小さく、構成可能で、適切な名前を付けます

関数と API

  • 公開関数には明示的な戻り値の型を優先します
  • API を大幅に改善する場合を除き、関数のオーバーロードは避けます
  • 関数のシグネチャはシンプルで予測可能に保ちます

Null許容と安全性

  • nullundefined は明示的に処理します
  • 最後の手段を除き、non-null assertion (!) には依存しないでください
  • コントロールフローとガードによる絞り込みを優先します

Enum と定数

  • enum避けます
  • 共用体型または as const オブジェクトを優先します
  • ランタイム出力は予測可能で最小限に保ちます

エラー処理

  • 型エラーとエラー状態を明示的に型付けします
  • 適切な場合は、例外をスローするよりも、結果オブジェクトまたは型付きエラーを優先します
  • 広範な型の背後に失敗モードを隠さないでください

一般原則

  • 型は意図を説明するものであるべきです
  • 型が理解しにくい場合は、おそらく間違っています
  • 理論的な完全性よりも保守性を重視します
📜 原文 SKILL.md(Claudeが読む英語/中国語)を展開

Clean TypeScript

We use TypeScript as a correctness and clarity tool, not as ceremony. Types should reduce bugs and cognitive load.

Type Philosophy

  • PREFER explicit, readable types over clever or overly generic ones
  • AVOID any and unsafe type assertions
  • Use unknown instead of any when necessary
  • Let TypeScript infer types when inference is clear and stable

Types & Interfaces

  • PREFER type aliases for most use cases
  • Use interface primarily for public, extendable object shapes
  • Keep types small, composable, and well-named

Functions & APIs

  • PREFER explicit return types for public functions
  • Avoid function overloads unless they meaningfully improve the API
  • Keep function signatures simple and predictable

Nullability & Safety

  • Handle null and undefined explicitly
  • DO NOT rely on non-null assertions (!) except as a last resort
  • Prefer narrowing via control flow and guards

Enums & Constants

  • AVOID enum
  • PREFER union types or as const objects
  • Keep runtime output predictable and minimal

Error Handling

  • Type errors and error states explicitly
  • Prefer result objects or typed errors over throwing where appropriate
  • Do not hide failure modes behind broad types

General Principles

  • Types should explain intent
  • If a type is hard to understand, it’s probably wrong
  • Favor maintainability over theoretical completeness