feat(i18n): Add Japanese (ja/) translation (#105)

- Translate all 101 markdown files: P1 core, all 10 modules, examples,
  auxiliary docs (CONTRIBUTING, CODE_OF_CONDUCT, SECURITY, CLAUDE.md, etc.),
  peripheral docs (.github/, docs/, resources/, scripts/)
- Translate comments and user-facing messages in 06-hooks/*.sh examples
- Copy 05-mcp/*.json examples (standard JSON, no comments)
- Update root README.md language switcher to include 日本語
- Add ja/TRANSLATION_NOTES.md (glossary + style guide)

All translations pass pre-commit quality gates (markdown-lint,
cross-references, mermaid-syntax, link-check, build-epub).
This commit is contained in:
JiangCheng
2026-04-30 07:16:46 +09:00
committed by GitHub
parent 32212292df
commit 1d1df9235b
118 changed files with 30380 additions and 3 deletions

View File

@@ -0,0 +1,278 @@
<!-- i18n-source: 03-skills/blog-draft/SKILL.md -->
<!-- i18n-source-sha: f396788 -->
<!-- i18n-date: 2026-04-27 -->
---
name: blog-draft
description: アイデアとリソースからブログ記事の下書きを作成する。ブログ記事の執筆、リサーチからのコンテンツ作成、記事の下書き作成時に使用する。リサーチ、ブレインストーミング、アウトライン作成、バージョン管理付きの反復的な下書き作成を案内する。
---
## ユーザー入力
```text
$ARGUMENTS
```
進める前にユーザー入力を**必ず**考慮する。ユーザーは以下を提供すべきである。
- **Idea/Topic**: ブログ記事の主要なコンセプトやテーマ
- **Resources**: URL、ファイル、リサーチ用の参考情報任意だが推奨
- **Target audience**: ブログ記事の対象読者(任意)
- **Tone/Style**: フォーマル、カジュアル、技術的、など(任意)
**重要**: ユーザーが**既存のブログ記事**の更新を要求している場合、ステップ 0-8 をスキップして直接**ステップ 9**から開始する。まず既存の下書きファイルを読み、その後で反復プロセスを進める。
## 実行フロー
以下のステップを順次実行する。**ステップをスキップしたり、指示された箇所でユーザー承認なしに進めたりしてはならない。**
### Step 0: プロジェクトフォルダの作成
1. 次の形式でフォルダ名を生成する: `YYYY-MM-DD-short-topic-name`
- 今日の日付を使用
- トピックから短く URL フレンドリーなスラッグを作成(小文字、ハイフン、最大 5 単語)
2. フォルダ構造を作成:
```
blog-posts/
└── YYYY-MM-DD-short-topic-name/
└── resources/
```
3. 進める前にフォルダ作成をユーザーに確認する。
### Step 1: リサーチとリソース収集
1. ブログ記事ディレクトリ内に `resources/` サブフォルダを作成
2. 提供された各リソースに対して:
- **URLs**: 取得して主要情報を `resources/` にマークダウンファイルとして保存
- **Files**: 読み込んで `resources/` に要約
- **Topics**: ウェブ検索を使用して最新情報を収集
3. 各リソースについて、`resources/` に要約ファイルを作成:
- `resources/source-1-[short-name].md`
- `resources/source-2-[short-name].md`
- など
4. 各要約には以下を含める:
```markdown
# Source: [Title/URL]
## Key Points
- Point 1
- Point 2
## Relevant Quotes/Data
- Quote or statistic 1
- Quote or statistic 2
## How This Relates to Topic
関連性の簡潔な説明
```
5. リサーチの要約をユーザーに提示する。
### Step 2: ブレインストーミングと明確化
1. アイデアとリサーチしたリソースに基づき、以下を提示:
- リサーチから特定された**主要テーマ**
- ブログ記事の**取りうる切り口**
- カバーすべき**重要ポイント**
- 明確化が必要な情報の**ギャップ**
2. 明確化のための質問:
- 読者に持って帰ってほしい主要なテイクアウェイは何か?
- リサーチの中で特に強調したい点はあるか?
- 目標の長さはshort: 500-800 words、medium: 1000-1500、long: 2000+
- 除外したい点はあるか?
3. **進める前にユーザー応答を待つ。**
### Step 3: アウトライン提案
1. 以下を含む構造化されたアウトラインを作成:
```markdown
# Blog Post Outline: [Title]
## Meta Information
- **Target Audience**: [who]
- **Tone**: [style]
- **Target Length**: [word count]
- **Main Takeaway**: [key message]
## Proposed Structure
### Hook/Introduction
- Opening hook idea
- Context setting
- Thesis statement
### Section 1: [Title]
- Key point A
- Key point B
- Supporting evidence from [source]
### Section 2: [Title]
- Key point A
- Key point B
[全セクションについて続ける...]
### Conclusion
- Summary of key points
- Call to action or final thought
## Sources to Cite
- Source 1
- Source 2
```
2. アウトラインをユーザーに提示し、**承認または修正を求める**。
### Step 4: 承認されたアウトラインの保存
1. ユーザーがアウトラインを承認したら、ブログ記事フォルダ内の `OUTLINE.md` に保存する。
2. アウトラインが保存されたことを確認する。
### Step 5: アウトラインのコミットgit リポジトリの場合)
1. カレントディレクトリが git リポジトリかどうか確認する。
2. はいの場合:
- 新しいファイルブログ記事フォルダ、resources、OUTLINE.mdをステージング
- 次のメッセージでコミットを作成: `docs: Add outline for blog post - [topic-name]`
- リモートへプッシュ
3. git リポジトリでない場合は、このステップをスキップしユーザーに伝える。
### Step 6: 下書き作成
1. 承認されたアウトラインに基づき、ブログ記事の下書き全文を作成する。
2. OUTLINE.md の構造に厳密に従う。
3. 含めるもの:
- フック付きの魅力的な導入
- 明確なセクション見出し
- リサーチからの裏付けとなる証拠と例
- セクション間の滑らかな遷移
- テイクアウェイのある力強い結論
- **Citations**: すべての比較、統計、データポイント、事実主張は元のソースを必ず引用すること
4. 下書きをブログ記事フォルダ内に `draft-v0.1.md` として保存する。
5. フォーマット:
```markdown
# [Blog Post Title]
*[Optional: subtitle or tagline]*
[インライン引用付きの本文...]
---
## References
- [1] Source 1 Title - URL or Citation
- [2] Source 2 Title - URL or Citation
- [3] Source 3 Title - URL or Citation
```
6. **引用要件**:
- すべてのデータポイント、統計、比較にはインライン引用を必ず付ける
- [1]、[2] などの番号引用、または [Source Name] のような名前付き引用を使用
- 引用を末尾の References セクションへリンクする
- 例: "Studies show that 65% of developers prefer TypeScript [1]"
- 例: "React outperforms Vue in rendering speed by 20% [React Benchmarks 2024]"
### Step 7: 下書きのコミットgit リポジトリの場合)
1. git リポジトリかどうか確認する。
2. はいの場合:
- 下書きファイルをステージング
- 次のメッセージでコミットを作成: `docs: Add draft v0.1 for blog post - [topic-name]`
- リモートへプッシュ
3. git リポジトリでない場合は、スキップしてユーザーに伝える。
### Step 8: レビュー用に下書きを提示
1. 下書きの内容をユーザーに提示する。
2. フィードバックを求める:
- 全体の印象は?
- 拡張または削減が必要なセクションは?
- トーン調整は必要か?
- 不足している情報は?
- 具体的な編集や書き直しは?
3. **ユーザー応答を待つ。**
### Step 9: 反復または最終化
**ユーザーが変更を要求した場合:**
1. すべての要望を記録する
2. 以下の調整を加えてステップ 6 へ戻る:
- バージョン番号を増加v0.2、v0.3 など)
- すべてのフィードバックを反映
- `draft-v[X.Y].md` として保存
- ステップ 7-8 を繰り返す
**ユーザーが承認した場合:**
1. 最終下書きのバージョンを確認
2. ユーザーが要求すれば任意で `final.md` にリネーム
3. ブログ記事作成プロセスを要約:
- 作成したバージョンの総数
- バージョン間の主要な変更
- 最終ワード数
- 作成したファイル
## バージョン追跡
すべての下書きは段階的なバージョン番号付きで保持する:
- `draft-v0.1.md` - 初回下書き
- `draft-v0.2.md` - 1 回目のフィードバック反映後
- `draft-v0.3.md` - 2 回目のフィードバック反映後
- など
これによりブログ記事の進化を追跡し、必要に応じて差し戻すことができる。
## 出力ファイル構造
```
blog-posts/
└── YYYY-MM-DD-topic-name/
├── resources/
│ ├── source-1-name.md
│ ├── source-2-name.md
│ └── ...
├── OUTLINE.md
├── draft-v0.1.md
├── draft-v0.2.md (反復した場合)
└── draft-v0.3.md (さらに反復した場合)
```
## 品質のためのヒント
- **Hook**: 質問、意外な事実、共感できるシナリオで始める
- **Flow**: 各段落は次の段落と接続させる
- **Evidence**: リサーチデータで主張を裏付ける
- **Citations**: 以下については必ずソースを引用する:
- すべての統計とデータポイント(例: "According to [Source], 75% of..."
- 製品、サービス、アプローチ間の比較(例: "X performs 2x faster than Y [Source]"
- 市場トレンド、リサーチ結果、ベンチマークについての事実主張
- 形式: [Source Name] または [Author, Year] のインライン引用を使用
- **Voice**: 全体を通じて一貫したトーンを保つ
- **Length**: 目標ワード数を尊重
- **Readability**: 短い段落、適切な箇所での箇条書きを使用
- **CTA**: 明確な CTA または考えさせる問いで終える
## 注意事項
- 指定されたチェックポイントでは必ずユーザー承認を待つ
- 履歴のためすべての下書きバージョンを保持する
- URL が提供された場合は最新情報のためウェブ検索を使用する
- リソースが不十分な場合はユーザーに追加を求めるか、追加リサーチを提案する
- 対象読者(技術系、一般、ビジネスなど)に応じてトーンを適応させる