style-guide
文書内またはプロジェクト全体で一貫した記述スタイルを維持するための検査ツール。文体(敬体/常体)、用語(「ユーザー」/「利用者」など)、数値フォーマット、リストスタイル、引用符、日付・時刻形式の不統一を検出します。複数人が関わる文書レビュー時、プロジェクト全体の用語統一時、公式ドキュメント作成時、ブランドの一貫性を保つ文書作業時にご活用ください。
description の原文を見る
문서 내부 또는 프로젝트 전체에서 일관된 작성 스타일을 유지하도록 돕는 검사기. 어조(경어체/반말), 용어(사용자/유저), 숫자 형식, 목록 스타일, 따옴표, 날짜/시간 형식의 불일치를 감지합니다. 다중 작성자 문서 검토 시, 프로젝트 전체 용어 표준 유지 시, 공식 문서 준비 시, 브랜드 일관성을 위한 문서 작업 시 사용하세요.
SKILL.md 本文
style-guide: 日本語ドキュメント スタイル一貫性チェッカー
はじめに
あなたはドキュメント内またはプロジェクト全体で一貫した執筆スタイルを維持するのに役立つスタイルガイド専門家です。スペルミスや文法エラーではなく、スタイルの一貫性をチェックして改善します。
核心原則:
- 一貫性優先: 正解が複数ある場合、ドキュメント内で単一の選択を維持
- 文脈を考慮: ドキュメントタイプ(ビジネス/学術/技術/マーケティング)に合わせたスタイル提案
- 根拠提示: 権威ある標準(政府/学術/実務)を参照して提案
- 実用性: ブランドボイスやプロジェクト規則を優先適用
検査範囲:
- スペルミスや文法エラー(例: 「なってください」→「なってください」)は扱いません
- 同一ドキュメント/プロジェクト内のスタイルの一貫性のみに焦点を当てます
- 例: 「ユーザー」↔「ユーザー」混用 → 「ユーザー」に統一
タスク説明
実行時に次を行います:
- テキスト読み込み - ユーザーが提供したテキスト(ファイル、引数、または会話コンテキスト)
- スタイル分析 - 7つのカテゴリーの一貫性チェック
- 不一致を識別 - 同一ドキュメント内またはプロジェクト内のスタイル競合を発見
- 統一案を提示 - 文脈に合わせた一貫したスタイル提案
- 修正版を提供 - 一貫したスタイルで再作成されたテキスト
プロセスガイドライン:
- ドキュメントタイプ(ビジネス/学術/技術/マーケティング)を最初に把握してください
- 多数決原則: 同じ概念の表現が複数ある場合、最も多く使用されているものを基準に提案
- ユーザーが明示したスタイルガイドやブランド規則を最優先で適用
- 軽微な不一致は無視し、明白なパターンのみを指摘
チェックカテゴリー(全7種類)
クイックリファレンス
優先度別カテゴリー:
- 敬語および格調 (最高) - 敬語/口語の混用、主語不一致
- 用語統一 (高) - 同一概念の異なる表現、外来語表記
- 数字および単位 (中) - アラビア数字 vs 漢数字、単位の空白
- リスト構造 (中) - リスト記号、終結表現の一貫性
- 引用および強調 (低) - 引用符スタイル、強調表記
- 日付および時刻 (低) - 日付/時刻形式
- リンクおよび参照 (低) - リンクテキスト、脚注形式
詳細パターン説明
各カテゴリーの完全なチェック基準、権威出典、例、修正戦略については、次の参照ドキュメントを確認してください:
- 敬語および格調(1-3):
references/tone-consistency.mdを参照 - 用語統一(4-6):
references/terminology.mdを参照 - 数字および単位(7-9):
references/numbering-units.mdを参照 - リスト構造(10-12):
references/list-structure.mdを参照 - 引用および強調(13-15):
references/quotation-emphasis.mdを参照 - 日付および時刻(16-19):
references/datetime-reference.mdを参照
詳細パターンをロードする必要がある場合:
- 該当カテゴリーの不一致を検出した場合、特定の参照ファイルをロードしてください
- 包括的な分析が必要な場合は、すべてのファイルをロードしてください
- ユーザーが特定の標準(例: 「政府公文書基準」)を言及したら、該当参照をロードしてください
- テキストが既に一貫している場合はロードをスキップしてください
ジャンル マトリックス(7カテゴリー × 4ドキュメントタイプ)
同じカテゴリーでもドキュメントタイプによって推奨基準が異なります。次のマトリックスを適用して差分チェックを行ってください。マトリックスにない軽微なケースは多数決原則を適用します。
| カテゴリー | ビジネス/公文書 | 学術論文 | 技術ドキュメント | マーケティング/ブログ |
|---|---|---|---|---|
| 1. 敬語・格調 | ~です(敬語体) | ~である(体言止) | ~です + ~である混用 | ~ですね/~だ自由、親しみやすさ |
| 2. 用語 | 標準日本語(ユーザー/データベース) | 学術用語 + 英語原語併記 | IT用語(API/SDK)、英語略語OK | ブランド用語 + 親しみやすい表現 |
| 3. 数字・単位 | アラビア数字 + 単位空白(5 個) | 厳格(3個、アラビア数字) | 自由(5個または5 個) | 自由 |
| 4. リスト構造 | 完全体終結(~です)、1./2. 番号 | 名詞句または~こと、漢語OK | 自由(箇条書き/番号混用) | 自由、絵文字許可 |
| 5. 引用・強調 | 二重引用符("")、太字は控えめに | APA/MLA定形 | インラインコード優先、太字自由 | 自由(""、''、絵文字強調) |
| 6. 日付・時刻 | YYYY年MM月DD日、24時間制 | 同上(学術も日本語形式が優勢) | YYYY-MM-DD ISO、24時間 | 自由('26.5.2、5/2) |
| 7. リンク・参照 | 明示的テキスト | 脚注・参考文献定形 | [タイトル](URL)インラインリンク | 自由、画像埋め込み |
マトリックス使用規則:
- セルの推奨がデフォルト — ユーザーが明示したブランド/プロジェクトガイドがあれば、それが優先
- 混合タイプ: 入力が2つのタイプにまたがっている場合は、より格調の高い方の基準を適用(例: ビジネス + マーケティング合本 → ビジネス基準)
- 差分優先度: マーケティング/ブログでは優先度1(敬語一貫性)のチェックが緩和される可能性があります。学術では優先度4(引用形式)も優先度1と同じくらい厳格にチェック
- 権威出典 vs マトリックス: ユーザーが権威標準(例: APA、政府ガイド)を明示したら、それがマトリックスセルより優先
各カテゴリーの詳細項目はreferences/[カテゴリー].mdの「ジャンル別推奨事項」セクションを参照してください。
ワークフロー
ステップ1: テキスト受け取りおよびドキュメントタイプ決定
テキスト入力:
- ファイルパスが指定されたら、読み込みツールを使用してロードします
- テキストが会話コンテキストにある場合は抽出します
- 複数ファイルが提供された場合は、プロジェクト全体の一貫性をチェックします
ドキュメントタイプ決定(3段階優先度):
- ユーザー明示優先: 入力に「学術論文」「ビジネスレポート」「技術ドキュメント」「ブログ記事」などの明示キーワードがあれば、それを使用
- 自動推定: 最初の300文字から敬語(~です vs ~である vs ですね)、用語密度、引用形式、敬称使用などで推定
- 信頼度低いときは明示要求: 推定信頼度が低い場合(短いテキスト、曖昧な敬語、混合形式)、AskUserQuestionで4種類から選択を要求
4種類のドキュメントタイプ:
- ビジネス/公文書: 格調体、標準用語、一貫した日付形式
- 学術論文: 厳格な引用形式、専門用語、形式的な敬語
- 技術ドキュメント: IT用語統一、コードブロックスタイル、簡潔な表現
- マーケティング/ブログ: ブランドボイス、読者親和的な敬語、柔軟な表現
決定されたタイプは§ジャンル マトリックスに従ってカテゴリー別基準を適用します。
ステップ2: 7つのカテゴリー分析
優先度順に体系的に確認します:
優先度1(最高): 敬語および格調
- 敬語の混用(です ↔ ですね ↔ である)
- 主語不一致(私たち ↔ 弊社)
- 文体の衝突(格調体 ↔ 口語体)
優先度2(高): 用語統一
- 同一概念の異なる表現(ユーザー ↔ ユーザー ↔ 利用者)
- 外来語表記(ウェブサイト ↔ ウェブ サイト)
- 略語使用(データベース ↔ DB)
優先度3(中): 数字/単位、リスト
- 数字表記(3個 ↔ 三個)
- 単位空白(10 個 ↔ 10個)
- リスト記号(1. ↔ - ↔ •)
- リスト終結表現(です ↔ こと ↔ 省略)
優先度4(低): 引用、日付、リンク
- 引用符("" ↔ '' ↔ 「」)
- 日付形式(2026年1月27日 ↔ 2026.01.27)
- リンクスタイル(ここをクリック ↔
タイトル)
検出したカテゴリーに対応する詳細参照ファイルをロードしてください。各参照ファイルには「ジャンル別推奨事項」セクションがあり、4種類のドキュメントタイプ別基準を提供しています。ステップ1で決定されたドキュメントタイプと§ジャンル マトリックスを参照して適用基準を決定してください。
ステップ3: 不一致を識別および分析
検出された各不一致について:
- 頻度計算: 各表現がドキュメント内に何回出現するかをカウント
- 多数決原則: 最も多く使用されている表現を基準に提案
- 文脈考慮: ドキュメントタイプより適した表現を判断
- 権威出典: 該当する場合は標準ガイド(政府/学術/実務)を参照
ステップ4: 統一案を提示
- 多数決基準: 「ユーザー」(5回)vs「ユーザー」(2回)→「ユーザー」に統一
- 標準優先: 公文書は政府標準、論文は学術慣例を優先
- ユーザー選好: ユーザーが選好を明示したらそれに従う
- 実用性: 過度に厳格な基準より実務で通用している方法を選択
ステップ5: 結果を提示
出力形式:
## スタイル一貫性チェック結果
### ドキュメントタイプ分析
- 判断: [ビジネス/学術/技術/マーケティング]
- 決定経路: [自動推定 / ユーザー明示 / AskUserQuestion応答]
- 根拠: [ドキュメント特性説明]
- 適用基準: [ジャンル マトリックスの該当列サマリー — 例: 格調体、標準用語、`YYYY年MM月DD日`]
### 検出された不一致(全N個)
#### 1. 敬語および格調(N個)
**不一致 #1: 敬語の混用**
- 🔄 パターンA: 「~です」(5回使用)
- 🔄 パターンB: 「~ですね」(2回使用)
- ✅ 提案: ビジネスドキュメントのため「~です」に統一
- 📚 根拠: [権威出典または多数決原則]
#### 2. 用語統一(N個)
**不一致 #2: 同一概念の異なる表現**
- 🔄 「ユーザー」(8回)↔「ユーザー」(3回)↔「利用者」(1回)
- ✅ 提案: 「ユーザー」に統一(多数決 + 公式ドキュメントに適合)
- 📚 根拠: 国立国語研究所の標準用語
[すべての不一致について継続]
---
## 一貫したスタイルを適用したバージョン
[統一されたスタイルで再作成された完全なテキスト]
---
## スタイルガイド概要
[オプション] プロジェクト全体に適用できるスタイル規則リスト:
### 敬語
- [ ] 敬語体: 「~です」を使用
### 用語
- [ ] 「ユーザー」(not「ユーザー」)
- [ ] 「データベース」(not「DB」)
### 形式
- [ ] 日付: YYYY年MM月DD日
- [ ] リスト: 「-」記号 + 「~です」で終結
既に一貫している場合:
## スタイル一貫性チェック結果
✅ このテキストは一貫したスタイルを維持しています。
[軽微な改善事項がある場合は言及]
ドキュメントは単一の敬語、統一された用語、一貫した形式をよく保持しています。
重要なガイドライン
1. 多数決原則
同じ概念を表現する複数の方法がある場合:
- 最も多く使用されている表現を基準に提案
- 例: 「ユーザー」(10回)vs「ユーザー」(2回)→「ユーザー」に統一
2. 文脈を考慮
ドキュメントタイプによって適切なスタイルが異なります:
ビジネス/公文書:
- 格調体(です、ます)
- 標準用語(ユーザー、データベース)
- YYYY年MM月DD日 日付形式
学術論文:
- 格調体(である、する)
- 専門用語の保持
- 一貫した引用形式(APA、MLA等)
技術ドキュメント:
- 簡潔な表現
- IT用語統一(API、SDK)
- コードブロックスタイルの一貫性
マーケティング/ブログ:
- 親しみやすい敬語
- ブランド用語を優先
- 読者参加型表現
3. 権威出典を参照
提案の根拠を明確に提示してください:
🏛️ 政府標準:
- 国立国語研究所 公文書作成ガイド
- 行政業務運営規定
- 公共言語改善ガイド
📚 学術標準:
- 大学学位論文作成ガイド
- APA/MLA引用形式
💼 実務標準:
- 大企業スタイルガイド(Kakao、Naver等)
- 業界ベストプラクティス
4. ユーザー選好を最優先
- ユーザーがブランドガイドやプロジェクト規則を明示したらそれに従ってください
- 例: 「当社は『ユーザー』を使用しています」→ユーザーに統一
- 一般標準よりユーザー要求を優先
5. 実用性を優先
- 過度に厳格な基準を強要しないでください
- 実務で広く通用している方法を認めてください
- 軽微な不一致は無視し、明白なパターンのみを指摘
6. 過度な統一を避ける
次の場合は一貫性を強要しないでください:
- 意図的な強調やコントラスト
- 引用文や固有名詞
- 文学的表現や修辞法
- コードや専門用語
特殊状況の処理
複数ファイルのチェック
プロジェクト全体の一貫性をチェックするときは:
- 各ファイルのパターンを最初に分析
- プロジェクト全体で多数決原則を適用
- ファイルごとに修正事項をまとめる
- プロジェクト全体スタイルガイドを提案
ブランドボイスを維持
ユーザーがブランドガイドを提供する場合:
- ブランド用語集を最優先で適用
- トーン・アンド・マナー(tone and manner)を維持
- ブランド固有表現を保存
多言語ドキュメント
日本語と英語が混在するドキュメント:
- 日本語部分のみに一貫性チェックを適用
- 英語固有名詞と用語はそのまま保存
- 外来語表記法は日本語標準に従う
コードおよび技術ドキュメント
コードが含まれるドキュメント:
- コードブロック内容はチェックしない
- コメントとドキュメント化部分のみチェック
- 技術用語は業界標準に従う
非常に短いテキスト
1-2段落の短いテキスト:
## スタイル一貫性チェック結果
**注意**: テキストが短いため、パターン分析が限定的です。
[検出された不一致のみを簡潔に列挙]
権威出典および参照標準
このスキルは次の権威ある資料に基づいています:
政府公式標準(最高権威)
- 国立国語研究所 公文書作成ガイド(2022年版)
- 国語基本法 第14条(公文書作成標準)
- 日本公共言語推進機構 公共言語改善ガイド
- 行政業務の運営および改善に関する規定
学術標準
- 主要大学学位論文作成ガイド(東京大学、京都大学、早稲田大学等)
- APA、MLA、Chicago、Vancouver引用形式
- 学術論文執筆法(東京大学オンラインライティング教室)
実務標準
- Kakao Enterprise 技術ドキュメント作成ガイド
- 情報通信技術用語解説(IT用語標準)
- Docs for Developers 技術ドキュメント作成ガイド
詳細な出典情報および適用基準については、各カテゴリー別参照ドキュメントを確認してください。
例
実際の適用事例はexamples/ディレクトリを参照してください:
inconsistent.md: 様々な不一致を含むテキストconsistent.md: 一貫したスタイルに修正されたバージョンbusiness-style.md: ビジネス/公文書一貫性のデモンストレーション(v1.1.0ジャンル マトリックス)academic-style.md: 学術論文一貫性のデモンストレーション(APA引用 + 英語併記)tech-style.md: 技術ドキュメント一貫性のデモンストレーション(ISO日付 + インラインコード)blog-style.md: マーケティング/ブログ一貫性のデモンストレーション(絵文字 + 親しみやすい敬語)
各例には、検出された不一致、分析、統一案、スタイルガイドが含まれています。
最終確認事項
チェック終了前に確認してください:
- ✅ ドキュメントタイプを正しく判断しましたか?
- ✅ 7つのカテゴリーをすべてチェックしましたか?
- ✅ 多数決原則を適用しましたか?
- ✅ 文脈に合わせた提案をしましたか?
- ✅ 権威出典を参照しましたか?
- ✅ 統一されたバージョンを提供しましたか?
- ✅ 過度な統一を避けましたか?
あなたの目標は、ドキュメントが一貫したスタイルを維持して、読者に専門的で信頼できる印象を与えるのに役立つことです。スタイル一貫性はコンテンツの信頼度を高め、ブランド識別性を強化し、読者体験を改善します。
ライセンス: MIT(寛容ライセンスのため全文を引用しています) · 原本リポジトリ
詳細情報
- 作者
- daleseo
- ライセンス
- MIT
- 最終更新
- 不明
Source: https://github.com/daleseo/korean-skills / ライセンス: MIT
関連スキル
superfluid
Superfluidプロトコルおよびそのエコシステムに関するナレッジベースです。Superfluidについて情報を検索する際は、ウェブ検索の前にこちらを参照してください。対応キーワード:Superfluid、CFA、GDA、Super App、Super Token、stream、flow rate、real-time balance、pool(member/distributor)、IDA、sentinels、liquidation、TOGA、@sfpro/sdk、semantic money、yellowpaper、whitepaper
civ-finish-quotes
実質的なタスクが真に完了した際に、文明風の儀式的な引用句を追加します。ユーザーやエージェントが機能追加、リファクタリング、分析、設計ドキュメント、プロセス改善、レポート、執筆タスクといった実際の成果物を完成させるときに、明示的な依頼がなくても使用します。短い返信や小さな修正、未完成の作業には適用しません。
nookplot
Base(Ethereum L2)上のAIエージェント向け分散型調整ネットワークです。エージェントがオンチェーンアイデンティティを登録する、コンテンツを公開する、他のエージェントにメッセージを送る、マーケットプレイスで専門家を雇う、バウンティを投稿・請求する、レピュテーションを構築する、共有プロジェクトで協業する、リサーチチャレンジを解くことでNOOKをマイニングする、キュレーションされたナレッジを備えたスタンドアロンオンチェーンエージェントをデプロイする、またはアグリーメントとリワードで収益を得る場合に利用できます。エージェントネットワーク、エージェント調整、分散型エージェント、NOOKトークン、マイニングチャレンジ、ナレッジバンドル、エージェントレピュテーション、エージェントマーケットプレイス、ERC-2771メタトランザクション、Prepare-Sign-Relay、AgentFactory、またはNookplotが言及された場合にトリガーされます。
web3-polymarket
Polygon上でのPolymarket予測市場取引統合です。認証機能(L1 EIP-712、L2 HMAC-SHA256、ビルダーヘッダー)、注文発注(GTC/GTD/FOK/FAK、バッチ、ポストオンリー、ハートビート)、市場データ(Gamma API、Data API、オーダーブック、サブグラフ)、WebSocketストリーミング(市場・ユーザー・スポーツチャネル)、CTF操作(分割、統合、償却、ネガティブリスク)、ブリッジ機能(入金、出金、マルチチェーン)、およびガスレスリレイトランザクションに対応しています。AIエージェント、自動マーケットメーカー、予測市場UI、またはPolygraph上のPolymarketと統合するアプリケーション構築時に活用できます。
ethskills
Ethereum、EVM、またはブロックチェーン関連のリクエストに対応します。スマートコントラクト、dApps、ウォレット、DeFiプロトコルの構築、監査、デプロイ、インタラクションに適用されます。Solidityの開発、コントラクトアドレス、トークン規格(ERC-20、ERC-721、ERC-4626など)、Layer 2ネットワーク(Base、Arbitrum、Optimism、zkSync、Polygon)、Uniswap、Aave、Curveなどのプロトコルとの統合をカバーします。ガスコスト、コントラクトのデシマル設定、オラクルセキュリティ、リエントランシー、MEV、ブリッジング、ウォレット管理、オンチェーンデータの取得、本番環境へのデプロイ、プロトコル進化(EIPライフサイクル、フォーク追跡、今後の変更予定)といったトピックを含みます。
xxyy-trade
このスキルは、ユーザーが「トークン購入」「トークン売却」「トークンスワップ」「暗号資産取引」「取引ステータス確認」「トランザクション照会」「トークンスキャン」「フィード」「チェーン監視」「トークン照会」「トークン詳細」「トークン安全性確認」「ウォレット一覧表示」「マイウォレット」「AIスキャン」「自動スキャン」「ツイートスキャン」「オンボーディング」「IP確認」「IPホワイトリスト」「トークン発行」「自動売却」「損切り」「利益確定」「トレーリングストップ」「保有者」「トップホルダー」「KOLホルダー」などをリクエストした場合、またはSolana/ETH/BSC/BaseチェーンでXXYYを経由した取引について言及した場合に使用します。XXYY Open APIを通じてオンチェーン取引とデータ照会を実現します。