global-standards
プロジェクト全体のコーディング規約や技術選定、開発標準を統一し、品質と一貫性を高めるための専門知識を提供するSkill。
📜 元の英語説明(参考)
Project-wide coding standards and conventions specialist. Use PROACTIVELY when writing code, making architectural decisions, or establishing project conventions. Covers coding style, commenting, error handling, validation, tech stack consistency, and project conventions across all languages and frameworks.
🇯🇵 日本人クリエイター向け解説
プロジェクト全体のコーディング規約や技術選定、開発標準を統一し、品質と一貫性を高めるための専門知識を提供するSkill。
※ jpskill.com 編集部が日本のビジネス現場向けに補足した解説です。Skill本体の挙動とは独立した参考情報です。
⚠️ ダウンロード・利用は自己責任でお願いします。当サイトは内容・動作・安全性について責任を負いません。
🎯 このSkillでできること
下記の説明文を読むと、このSkillがあなたに何をしてくれるかが分かります。Claudeにこの分野の依頼をすると、自動で発動します。
📦 インストール方法 (3ステップ)
- 1. 上の「ダウンロード」ボタンを押して .skill ファイルを取得
- 2. ファイル名の拡張子を .skill から .zip に変えて展開(macは自動展開可)
- 3. 展開してできたフォルダを、ホームフォルダの
.claude/skills/に置く- · macOS / Linux:
~/.claude/skills/ - · Windows:
%USERPROFILE%\.claude\skills\
- · macOS / Linux:
Claude Code を再起動すれば完了。「このSkillを使って…」と話しかけなくても、関連する依頼で自動的に呼び出されます。
詳しい使い方ガイドを見る →- 最終更新
- 2026-05-17
- 取得日時
- 2026-05-17
- 同梱ファイル
- 1
📖 Skill本文(日本語訳)
※ 原文(英語/中国語)を Gemini で日本語化したものです。Claude 自身は原文を読みます。誤訳がある場合は原文をご確認ください。
プロジェクト標準
このスキルは、言語やフレームワークに関わらず、コードベース全体に適用されるプロジェクト全体のコーディング標準、規約、およびベストプラクティスに関する包括的なガイダンスを提供します。
このスキルを使用するタイミング
このスキルは、以下の状況で使用してください。
- コードの記述時 - プロジェクト標準との一貫性を確保する
- アーキテクチャの決定時 - 確立されたパターンに従う
- オンボーディング時 - プロジェクトの規約を理解する
- コードレビュー時 - 標準への準拠を確認する
- リファクタリング時 - 変更中の整合性を維持する
- 新機能のセットアップ時 - プロジェクトの規約に従う
コア標準領域
1. コーディングスタイル
適用するタイミング:
- 変数、関数、クラス、モジュール、またはファイルの名前付け
- 可読性と保守性のためのコード構造化
- 関数のサイズと単一責任の決定
- 未使用のコード、コメントアウトされたブロック、またはデッドインポートの削除
- 重複を避けるための再利用可能なロジックの抽出
- 一貫したフォーマットとインデントの適用
- 明確さと簡潔さのためのコードのリファクタリング
原則:
- 意図を明らかにする、明確で記述的な名前
- DRY (Don't Repeat Yourself) 原則
- 単一責任の原則
- 構造による自己文書化コード
- コードベース全体での一貫したフォーマット
適用対象: すべてのコードファイル (.py,.js, .ts,.jsx, .tsx,.vue, .rb,.go, .java,.rs, .cpp,.c, .swift,.kt)
2. コメント標準
適用するタイミング:
- コードにコメントが必要かどうかの判断
- 複雑なアルゴリズムや自明でないビジネスロジックの文書化
- ドキュメント文字列や関数ドキュメントの記述
- 既存のコメントの関連性のレビュー
- 古いコメントや誤解を招くコメントの削除
- 自明でないコードの決定や回避策の説明
原則:
- 最小限で役立つコメント
- 「何を」ではなく「なぜ」を説明する
- 明確な命名によりコードを自己文書化する
- コメントは複雑なロジックやビジネスルールを説明するべき
- コードが何をするかを繰り返すコメントは避ける
- コメントは常に最新で関連性のあるものにする
適用対象: コードベース全体のすべてのコードファイル
3. エラー処理
適用するタイミング:
try-catchまたはtry-exceptブロックでのコードのラップ- カスタム例外クラスまたはエラークラスの作成
- エラー境界の実装 (React など)
- API 呼び出しからの HTTP エラーの処理
- ユーザーフレンドリーなエラーメッセージの表示
- 指数バックオフによる再試行ロジックの実装
finallyブロックでのリソースのクリーンアップ- エラーをキャッチするか伝播させるかの決定
- 適切な重大度レベルでのエラーのログ記録
- 外部サービスのためのサーキットブレーカーの実装
- 構造化された応答による検証エラーの処理
原則:
- ユーザーフレンドリーなエラーメッセージ
- 適切な例外タイプと階層
- 優雅な劣化
- コンテキストを含む包括的なログ記録
finallyブロックでのリソースクリーンアップ- 適切なエラー伝播
- 一時的な障害に対する再試行ロジック
適用対象: エラーをスローする可能性のあるすべてのコード (API ハンドラー、サービス関数、データ処理、ファイル操作、外部統合、ネットワークリクエスト、データベース操作)
4. 入力検証
適用するタイミング:
- フロントエンドでのフォーム入力の検証
- API リクエストボディ、クエリパラメータ、およびヘッダーの検証
- サーバーサイド検証ロジックの実装
- 検証スキーマの作成 (Zod, Yup, Pydantic, Joi)
- XSS、SQL インジェクションを防ぐためのユーザー入力のサニタイズ
- データ型、フォーマット、範囲、および必須フィールドの検証
- ビジネスルール検証の実装
- 検証エラーメッセージの表示
- ドメイン固有のルールに対するカスタムバリデーターの記述
- ファイルアップロード検証の処理
原則:
- クライアント側とサーバー側の両方で検証する
- 一貫性のために検証ライブラリを使用する
- セキュリティ脆弱性を防ぐために入力値をサニタイズする
- 明確で実用的なエラーメッセージを提供する
- システム境界で検証する
- ブロックリストよりも許可リストを使用する
適用対象: フォームコンポーネント、API ハンドラー、リクエストバリデーター、入力サニタイザー、スキーマ定義、検証ミドルウェア、ファイルアップロード、Webhook、外部 API 統合
5. テックスタックの一貫性
適用するタイミング:
- 新しい機能のためのライブラリやパッケージの選択
- フレームワーク固有のパターンを使用した機能の実装
- 新しいサービス、統合、またはサードパーティ API のセットアップ
- データベース接続、ORM 設定、またはクエリビルダーの構成
- 認証、認可、またはセキュリティ機能の追加
- テストフレームワーク、ツール、またはテストユーティリティのセットアップ
- デプロイ、CI/CD パイプライン、またはインフラストラクチャの構成
- 新しい依存関係を追加するかどうかの評価
- キャッシング、監視、ログ記録、または可観測性の実装
- 代替アプローチ間の選択
原則:
- 既存の技術選択との一貫性
- フレームワーク固有のパターンとイディオムに従う
- 新しい依存関係を追加するよりも既存のツールを優先する
- 技術的な決定を文書化する
- アーキテクチャの一貫性を維持する
適用対象: フロントエンド、バックエンド、データベース、インフラストラクチャ、テスト、デプロイ、サードパーティ統合
6. プロジェクト規約
適用するタイミング:
- ファイルとディレクトリ構造の整理
- Git コミットメッセージまたは PR 説明の記述
- 環境変数、構成、およびシークレットの管理
- プロジェクトの依存関係の追加または更新
- CI/CD ワークフローのセットアップまたは変更
- 機能フラグの実装
- README ファイルまたはプロジェクトドキュメントの更新
- コードレビュープロセスの確立
- 変更履歴またはリリースノートの維持
- リンター、フォーマッター、またはプリコミットフックの構成
- 開発環境のセットアップ
- モノレポまたはマルチパッケージ構造の管理
原則:
- 一貫したファイルとディレクトリの整理
- 慣習的なコミットメッセージ
- 明確なドキュメント
- 適切な依存関係管理
- 自動化された品質チェック
- 明確な開発ワークフロー
適用対象: 構成ファイル (.env, package.json, requirements.txt, pyproject.toml, Dockerfile, docker-compose.yml, Makefile)、ディレクトリ (.github/, .gitlab-ci/, scripts/, docs/)、ドキュメントファイル
📜 原文 SKILL.md(Claudeが読む英語/中国語)を展開
Project Standards
This skill provides comprehensive guidance on project-wide coding standards, conventions, and best practices that apply across the entire codebase regardless of language or framework.
When to Use This Skill
Use this skill when:
- Writing code - Ensuring consistency with project standards
- Making architectural decisions - Following established patterns
- Onboarding - Understanding project conventions
- Code review - Checking adherence to standards
- Refactoring - Maintaining consistency during changes
- Setting up new features - Following project conventions
Core Standards Areas
1. Coding Style
When to apply:
- Naming variables, functions, classes, modules, or files
- Structuring code for readability and maintainability
- Deciding on function size and single responsibility
- Removing unused code, commented-out blocks, or dead imports
- Extracting reusable logic to avoid duplication
- Applying consistent formatting and indentation
- Refactoring code for clarity and simplicity
Principles:
- Clear, descriptive names that reveal intent
- DRY (Don't Repeat Yourself) principle
- Single Responsibility Principle
- Self-documenting code through structure
- Consistent formatting across the codebase
Applies to: All code files (.py,.js, .ts,.jsx, .tsx,.vue, .rb,.go, .java,.rs, .cpp,.c, .swift,.kt)
2. Commenting Standards
When to apply:
- Deciding whether code needs a comment
- Documenting complex algorithms or non-obvious business logic
- Writing docstrings or function documentation
- Reviewing existing comments for relevance
- Removing outdated or misleading comments
- Explaining non-obvious code decisions or workarounds
Principles:
- Minimal, helpful comments
- Explain why, not what
- Keep code self-documenting through clear naming
- Comments should explain complex logic or business rules
- Avoid comments that restate what code does
- Keep comments evergreen and relevant
Applies to: All code files across the entire codebase
3. Error Handling
When to apply:
- Wrapping code in try-catch or try-except blocks
- Creating custom exception or error classes
- Implementing error boundaries (React, etc.)
- Handling HTTP errors from API calls
- Displaying user-friendly error messages
- Implementing retry logic with exponential backoff
- Cleaning up resources in finally blocks
- Deciding where to catch versus propagate errors
- Logging errors with appropriate severity levels
- Implementing circuit breakers for external services
- Handling validation errors with structured responses
Principles:
- User-friendly error messages
- Proper exception types and hierarchies
- Graceful degradation
- Comprehensive logging with context
- Resource cleanup in finally blocks
- Appropriate error propagation
- Retry logic for transient failures
Applies to: All code that may throw errors (API handlers, service functions, data processing, file operations, external integrations, network requests, database operations)
4. Input Validation
When to apply:
- Validating form inputs on the frontend
- Validating API request bodies, query parameters, and headers
- Implementing server-side validation logic
- Creating validation schemas (Zod, Yup, Pydantic, Joi)
- Sanitizing user input to prevent XSS, SQL injection
- Validating data types, formats, ranges, and required fields
- Implementing business rule validation
- Displaying validation error messages
- Writing custom validators for domain-specific rules
- Handling file upload validation
Principles:
- Validate on both client and server sides
- Use validation libraries for consistency
- Sanitize input to prevent security vulnerabilities
- Provide clear, actionable error messages
- Validate at system boundaries
- Use allowlists over blocklists
Applies to: Form components, API handlers, request validators, input sanitizers, schema definitions, validation middleware, file uploads, webhooks, external API integrations
5. Tech Stack Consistency
When to apply:
- Choosing libraries or packages for new functionality
- Implementing features using framework-specific patterns
- Setting up new services, integrations, or third-party APIs
- Configuring database connections, ORM settings, or query builders
- Adding authentication, authorization, or security features
- Setting up testing frameworks, tools, or test utilities
- Configuring deployment, CI/CD pipelines, or infrastructure
- Evaluating whether to add a new dependency
- Implementing caching, monitoring, logging, or observability
- Choosing between alternative approaches
Principles:
- Consistency with existing technology choices
- Follow framework-specific patterns and idioms
- Prefer existing tools over adding new dependencies
- Document technology decisions
- Maintain architectural consistency
Applies to: Frontend, backend, database, infrastructure, testing, deployment, third-party integrations
6. Project Conventions
When to apply:
- Organizing files and directory structure
- Writing git commit messages or PR descriptions
- Managing environment variables, configuration, and secrets
- Adding or updating project dependencies
- Setting up or modifying CI/CD workflows
- Implementing feature flags
- Updating README files or project documentation
- Establishing code review processes
- Maintaining changelogs or release notes
- Configuring linters, formatters, or pre-commit hooks
- Setting up development environments
- Managing monorepo or multi-package structures
Principles:
- Consistent file and directory organization
- Conventional commit messages
- Clear documentation
- Proper dependency management
- Automated quality checks
- Clear development workflows
Applies to: Configuration files (.env, package.json, requirements.txt, pyproject.toml, Dockerfile, docker-compose.yml, Makefile), directories (.github/, .gitlab-ci/, scripts/, docs/), documentation files (README.md, CHANGELOG.md, CONTRIBUTING.md)
Reference Files
For detailed standards documentation, load reference files as needed:
references/coding-style.md- Detailed coding style guidelines, naming conventions, formatting standardsreferences/commenting.md- Commenting best practices, docstring standards, when to commentreferences/error-handling.md- Error handling patterns, exception hierarchies, logging strategiesreferences/validation.md- Validation patterns, schema definitions, security considerationsreferences/tech-stack.md- Technology stack reference, framework patterns, dependency guidelinesreferences/conventions.md- Project conventions, file structure, git workflows, CI/CD standards
When working on specific areas, load the appropriate reference file for detailed guidance.
Best Practices
Consistency First
- Follow existing patterns in the codebase
- When in doubt, match the style of surrounding code
- Maintain consistency across all files
Progressive Enhancement
- Start with simple, clear code
- Add complexity only when necessary
- Refactor for clarity and maintainability
Documentation
- Keep documentation up to date
- Document decisions and trade-offs
- Include examples in documentation
Quality Gates
- Use linters and formatters
- Run tests before committing
- Review code for standards adherence
Integration with Other Skills
- code-review: Use when reviewing code for standards adherence
- dead-code-removal: Follow coding style when cleaning up code
- debugging: Apply error handling standards when analyzing errors
- dependency-management: Follow tech stack standards when managing dependencies