prompt-template-designer
同じようなAIタスクのプロンプトを何度も使う場合に、そのパターンを汎用的なテンプレートとして設計し、業務効率とAIの回答精度を向上させるSkill。
📜 元の英語説明(参考)
Design reusable prompt templates that encode domain-specific patterns for recurring AI tasks. Use when you've executed similar prompts 2+ times and need to capture the pattern as reusable intelligence. NOT for one-off prompts or generic "ask AI a question" patterns.
🇯🇵 日本人クリエイター向け解説
同じようなAIタスクのプロンプトを何度も使う場合に、そのパターンを汎用的なテンプレートとして設計し、業務効率とAIの回答精度を向上させるSkill。
※ jpskill.com 編集部が日本のビジネス現場向けに補足した解説です。Skill本体の挙動とは独立した参考情報です。
下記のコマンドをコピーしてターミナル(Mac/Linux)または PowerShell(Windows)に貼り付けてください。 ダウンロード → 解凍 → 配置まで全自動。
mkdir -p ~/.claude/skills && cd ~/.claude/skills && curl -L -o prompt-template-designer.zip https://jpskill.com/download/16872.zip && unzip -o prompt-template-designer.zip && rm prompt-template-designer.zip
$d = "$env:USERPROFILE\.claude\skills"; ni -Force -ItemType Directory $d | Out-Null; iwr https://jpskill.com/download/16872.zip -OutFile "$d\prompt-template-designer.zip"; Expand-Archive "$d\prompt-template-designer.zip" -DestinationPath $d -Force; ri "$d\prompt-template-designer.zip"
完了後、Claude Code を再起動 → 普通に「動画プロンプト作って」のように話しかけるだけで自動発動します。
💾 手動でダウンロードしたい(コマンドが難しい人向け)
- 1. 下の青いボタンを押して
prompt-template-designer.zipをダウンロード - 2. ZIPファイルをダブルクリックで解凍 →
prompt-template-designerフォルダができる - 3. そのフォルダを
C:\Users\あなたの名前\.claude\skills\(Win)または~/.claude/skills/(Mac)へ移動 - 4. Claude Code を再起動
⚠️ ダウンロード・利用は自己責任でお願いします。当サイトは内容・動作・安全性について責任を負いません。
🎯 この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-18
- 取得日時
- 2026-05-18
- 同梱ファイル
- 1
📖 Skill本文(日本語訳)
※ 原文(英語/中国語)を Gemini で日本語化したものです。Claude 自身は原文を読みます。誤訳がある場合は原文をご確認ください。
プロンプトテンプレートデザイナー
クイックスタート
# 1. テンプレート化する価値があるか確認
# 基準: 2回以上の使用、5つ以上の判断ポイント、ドメイン固有
# 2. パターンの抽出
# 不変要素(定数)と可変要素(パラメータ)を特定
# 3. テンプレートの作成
# 意図 → 制約 → 成功基準の構造を使用
ペルソナ
繰り返されるプロンプト構造を抽出するパターンライブラリのデザイナーのように考えてください。何が変化するか(パラメータ)と何が一定であるか(パターン)を特定し、ドメイン知識を制約にエンコードし、品質を維持しながら認知負荷を軽減するテンプレートを設計します。
分析の質問
1. 再発チェック
「このパターンを2回以上使用しましたか?」
| シナリオ | テンプレート化? |
|---|---|
| 「Gitコミットメッセージを生成する」(毎日) | YES |
| 「新しい開発者にReactフックを説明する」(1回) | NO |
| 「Bashのパーミッションエラーをデバッグする」(繰り返し) | YES |
| 「特定のAPIの癖を調査する」(ユニーク) | NO |
原則: 早すぎるテンプレート化はメンテナンスの負担を増やします。2回目の使用を待ちます。
2. バリエーション分析
「何が一定で、何が変化しますか?」
| タイプ | 内容 | 例 |
|---|---|---|
| 不変要素 | テンプレート構造 | 意図動詞、コア制約、出力形式 |
| 可変要素 | パラメータ | ファイル名、プロジェクトコンテキスト、閾値 |
3. 複雑さチェック
「これには5つ以上の判断ポイントがありますか?」
高価値テンプレート (5つ以上の判断): コードレビュープロンプト(アクション動詞、言語、レビューの焦点、出力形式、重大度レベル、スタイルガイド、コンテキスト、修正 vs 識別)
低価値 (1-3の判断): 「特定のGitコマンドを説明する」→ 直接尋ねるだけ
4. ドメイン知識チェック
「これはドメイン固有のインテリジェンスをエンコードしていますか?」
高価値: チームの慣習、品質基準、プロジェクト制約 低価値: 一般的な「AIに質問する」または「コードを生成する」
5. パラメータ設計
「どのパラメータが柔軟でありながら曖昧でないようにしますか?」
| パターン | 例 |
|---|---|
| Enum | {{ACTION_TYPE}} - 値: [CREATE, DEBUG, REFACTOR] |
| Path | {{TARGET_FILE}} - タイプ: file_path |
| Text | {{CHANGES_MADE}} - タイプ: bullet_list |
| Composite | {{ERROR_CONTEXT}} - 必須フィールド: error_message, file_location |
ルール: 3〜7個のパラメータが最適です。それ以上 → 複数のテンプレートに分割します。
原則
原則 1: 2回以上繰り返される場合にテンプレート化する
- 初回使用: プロンプトを直接記述
- 2回目の使用: パターンに気づき、テンプレートを抽出
- 3回目以降の使用: テンプレートを使用し、改良
原則 2: ハードコーディングよりもパラメータ化
# 以前 (ハードコーディング)
DEBUG backup.sh with "Permission denied" error
# 以後 (パラメータ化)
DEBUG {{SCRIPT_NAME}} with "{{ERROR_MESSAGE}}" error
原則 3: 成功パターンを文書化する
テンプレートには以下を含める必要があります。
- いつ使用するか(トリガー条件)
- なぜそれが機能するか(エンコードされたパターン)
- 記入済みの例(具体的なインスタンス化)
- よくある間違い(避けるべきこと)
原則 4: バージョン管理と進化
### v2.0.0 (2025-11-18)
- BREAKING: {{CHANGES}} を構造化された {{CHANGES_MADE}} に変更
- 「ビジネス価値」の要件を追加
### v1.0.0 (2025-10-15)
- 成功したプロンプトからの初期抽出
原則 5: 効果を測定する
| メトリクス | 目標 |
|---|---|
| 成功率 | >85% |
| 節約時間 | 測定可能 |
| 必要なイテレーション | <3 |
| チームの採用 | >50% |
テンプレート構造
---
template_name: {{descriptive-name}}
category: {{create|debug|refactor|optimize|analyze|generate}}
domain: {{backend|frontend|devops|testing|documentation}}
version: {{semantic-version}}
success_rate: {{percentage}}
---
# {{Template Name}}
## いつ使用するか
{{Trigger conditions}}
## パラメータ
### {{PARAM_1}}
- **タイプ**: {{enum|path|text|composite}}
- **例**: {{value}}
- **必須**: {{yes|no}}
## テンプレート
\```
INTENT:
{{ACTION_VERB}} {{description with parameters}}
CONSTRAINTS:
- {{invariant constraint}}
- {{parameterized constraint using {{PARAM}}}}
SUCCESS CRITERIA:
- {{measurable criterion}}
\```
## 例 (記入済み)
{{Concrete instantiation}}
## よくある間違い
- {{Anti-pattern and how to avoid}}
例: Gitコミットメッセージジェネレーター
---
template_name: git-commit-message-conventional
category: generate
version: 2.0.0
success_rate: 95%
---
## パラメータ
- **CHANGES_MADE**: 変更のリスト (必須)
- **JIRA_TICKET**: PROJ-NNNN 形式 (必須)
- **SCOPE**: [auth, api, ui, db, devops] (必須)
- **TYPE**: [feat, fix, docs, refactor, test] (必須)
## テンプレート
\```
GENERATE Git commit message
CHANGES: {{CHANGES_MADE}}
CONSTRAINTS:
- Format: {{TYPE}}({{SCOPE}}): <description> [{{JIRA_TICKET}}]
- Subject: 命令形、<50文字
- Body: WHY (ビジネス価値) を説明
SUCCESS CRITERIA:
- commitlint に合格
- チームメイトが差分を読まなくても理解できる
\```
## 例 (記入済み)
\```
feat(auth): add JWT refresh endpoint [PROJ-1234]
- Add /auth/refresh: improves mobile UX by eliminating re-logins
- Extend token to 24h: reduces authentication friction
\```
## よくある間違い
- Jiraチケットを忘れる
- 過去形 ("Added") の代わりに命令形 ("Add") を使用する
- WHAT の代わりに WHY を説明する
アンチパターン
| アンチパターン | 症状 | 修正 |
|---|---|---|
| パターンより先にテンプレート | 未使用のプロンプトに対して作成 | 最初に手動で2回以上使用する |
| 過剰なパラメータ化 | 15個以上のパラメータ | 3〜7個を目指し、それ以上は分割する |
| パラメータ不足 | 1つのシナリオでのみ機能 | 3つ以上のユースケースに適用する必要がある |
| 成功メトリクスなし | 品質を追跡しない | 成功率、節約時間を追跡する |
クイックリファレンス
テンプレート作成チェックリスト:
- [ ] パターンを2回以上使用しましたか?
- [ ] 定数と変数を特定しましたか?
- [ ] 5つ以上の判断ポイントがありますか?
- [ ] 例を含むパラメータはありますか?
- [ ] 記入済みの例が含まれていますか?
- [ ] 成功基準は定義されていますか?
パラメータ設計:
(原文はここで切り詰められています)
📜 原文 SKILL.md(Claudeが読む英語/中国語)を展開
Prompt Template Designer
Quick Start
# 1. Check if template-worthy
# Criteria: 2+ uses, 5+ decision points, domain-specific
# 2. Extract pattern
# Identify invariants (constants) vs variants (parameters)
# 3. Create template
# Use Intent → Constraints → Success Criteria structure
Persona
Think like a patterns library designer extracting recurring prompt structures. Identify what varies (parameters) vs what stays constant (pattern), encode domain knowledge into constraints, and design templates that reduce cognitive load while maintaining quality.
Analysis Questions
1. Recurrence Check
"Have I used this pattern 2+ times?"
| Scenario | Template? |
|---|---|
| "Generate Git commit message" (daily) | YES |
| "Explain React hooks to new dev" (once) | NO |
| "Debug Bash permission error" (recurring) | YES |
| "Research specific API quirk" (unique) | NO |
Principle: Premature templating adds maintenance burden. Wait for second use.
2. Variation Analysis
"What stays constant vs what changes?"
| Type | What It Is | Examples |
|---|---|---|
| Invariants | Template structure | Intent verb, core constraints, output format |
| Variants | Parameters | File names, project context, thresholds |
3. Complexity Check
"Does this have 5+ decision points?"
High-value template (5+ decisions): Code review prompt (action verb, language, review focus, output format, severity levels, style guide, context, fixes vs identify)
Low-value (1-3 decisions): "Explain specific Git command" → just ask directly
4. Domain Knowledge Check
"Does this encode domain-specific intelligence?"
High-value: Team conventions, quality standards, project constraints Low-value: Generic "ask AI a question" or "generate code"
5. Parameter Design
"What parameters make this flexible but not vague?"
| Pattern | Example |
|---|---|
| Enum | {{ACTION_TYPE}} - Values: [CREATE, DEBUG, REFACTOR] |
| Path | {{TARGET_FILE}} - Type: file_path |
| Text | {{CHANGES_MADE}} - Type: bullet_list |
| Composite | {{ERROR_CONTEXT}} - Required fields: error_message, file_location |
Rule: 3-7 parameters optimal. More → split into multiple templates.
Principles
Principle 1: Template When Recurs 2+
- First use: Write prompt directly
- Second use: Notice pattern, extract template
- Third+ uses: Use template, refine
Principle 2: Parameters Over Hard-Coding
# Before (hard-coded)
DEBUG backup.sh with "Permission denied" error
# After (parameterized)
DEBUG {{SCRIPT_NAME}} with "{{ERROR_MESSAGE}}" error
Principle 3: Document Success Patterns
Templates must include:
- When to use (trigger conditions)
- Why it works (pattern encoded)
- Example filled (concrete instantiation)
- Common mistakes (what to avoid)
Principle 4: Version and Evolve
### v2.0.0 (2025-11-18)
- BREAKING: Changed {{CHANGES}} to structured {{CHANGES_MADE}}
- Added "business value" requirement
### v1.0.0 (2025-10-15)
- Initial extraction from successful prompts
Principle 5: Measure Effectiveness
| Metric | Target |
|---|---|
| Success rate | >85% |
| Time saved | Measurable |
| Iterations needed | <3 |
| Team adoption | >50% |
Template Structure
---
template_name: {{descriptive-name}}
category: {{create|debug|refactor|optimize|analyze|generate}}
domain: {{backend|frontend|devops|testing|documentation}}
version: {{semantic-version}}
success_rate: {{percentage}}
---
# {{Template Name}}
## When to Use
{{Trigger conditions}}
## Parameters
### {{PARAM_1}}
- **Type**: {{enum|path|text|composite}}
- **Example**: {{value}}
- **Required**: {{yes|no}}
## Template
\```
INTENT:
{{ACTION_VERB}} {{description with parameters}}
CONSTRAINTS:
- {{invariant constraint}}
- {{parameterized constraint using {{PARAM}}}}
SUCCESS CRITERIA:
- {{measurable criterion}}
\```
## Example (Filled)
{{Concrete instantiation}}
## Common Mistakes
- {{Anti-pattern and how to avoid}}
Example: Git Commit Message Generator
---
template_name: git-commit-message-conventional
category: generate
version: 2.0.0
success_rate: 95%
---
## Parameters
- **CHANGES_MADE**: List of changes (required)
- **JIRA_TICKET**: PROJ-NNNN format (required)
- **SCOPE**: [auth, api, ui, db, devops] (required)
- **TYPE**: [feat, fix, docs, refactor, test] (required)
## Template
\```
GENERATE Git commit message
CHANGES: {{CHANGES_MADE}}
CONSTRAINTS:
- Format: {{TYPE}}({{SCOPE}}): <description> [{{JIRA_TICKET}}]
- Subject: Imperative mood, <50 chars
- Body: Explain WHY (business value)
SUCCESS CRITERIA:
- Passes commitlint
- Teammate understands without reading diff
\```
## Example (Filled)
\```
feat(auth): add JWT refresh endpoint [PROJ-1234]
- Add /auth/refresh: improves mobile UX by eliminating re-logins
- Extend token to 24h: reduces authentication friction
\```
## Common Mistakes
- Forgetting Jira ticket
- Past tense ("Added") instead of imperative ("Add")
- Explaining WHAT instead of WHY
Anti-Patterns
| Anti-Pattern | Symptom | Fix |
|---|---|---|
| Template Before Pattern | Creating for unused prompts | Use manually 2+ times first |
| Over-Parameterization | 15+ parameters | Aim for 3-7, split if more |
| Under-Parameterization | Only works for one scenario | Must apply to 3+ use cases |
| No Success Metrics | Never tracked quality | Track success rate, time saved |
Quick Reference
Template Creation Checklist:
- [ ] Used pattern 2+ times?
- [ ] Identified constants vs variants?
- [ ] 5+ decision points?
- [ ] Parameters with examples?
- [ ] Filled example included?
- [ ] Success criteria defined?
Parameter Design:
- [ ] Descriptive names (not {{X}})?
- [ ] Type specified?
- [ ] Examples provided?
- [ ] Required/optional marked?
Teaching Integration (L2 → L3)
Transition signal: Student has written similar prompts 2+ times with 85%+ success
Teaching sequence:
- "You've done this before. What's similar?" (identify recurrence)
- "What constraints appear in both?" (extract constants)
- "What changed?" (parameterize variants)
- "Let's formalize as reusable intelligence" (create template)
If Verification Fails
- Check recurrence: "Has this been used 2+ times?"
- Check complexity: "Are there 5+ decision points?"
- Check parameters: "3-7 well-designed parameters?"
- Stop and report if template adds more cognitive load than it saves