prompt-optimization-analyzer

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Prompt Optimization Analyzer

提示词优化分析器

When to Use This Skill

何时使用该Skill

Always use when:

User asks to "review", "analyze", "optimize", or "improve" a skill prompt
User says a skill "isn't triggering" or "isn't working as expected"
User wants to "reduce token usage" in a skill
User is "preparing a skill for publication" or sharing
User asks "why isn't my skill being called?"
User wants to "compare" two skill prompt versions

Consider using when:

User shares a skill file for any reason (offer to analyze)
User mentions a skill is "using too many tokens"
User describes confusing or inconsistent skill behavior

务必使用的场景：

用户要求“审核”“分析”“优化”或“改进”某个Skill提示词
用户反馈Skill“未触发”或“未按预期工作”
用户希望减少Skill中的“Token使用量”
用户正“为Skill发布做准备”或进行分享
用户询问“为什么我的Skill没有被调用？”
用户想要“对比”两个Skill提示词版本

考虑使用的场景：

用户因任何原因分享Skill文件（主动提供分析服务）
用户提到Skill“Token使用量过高”
用户描述Skill存在混乱或不一致的行为

Analysis Framework

分析框架

Run each skill prompt through this comprehensive diagnostic checklist. Report findings in order of severity (Critical → High → Medium → Low).

将每个Skill提示词通过以下全面诊断清单进行检测。按问题严重程度排序报告结果（严重→高→中→低）。

1. Trigger Pattern Analysis

1. 触发模式分析

Critical Issues:

❌ Missing or extremely vague description field
❌ Description doesn't match actual skill capabilities
❌ No clear trigger patterns identifiable from description
❌ Trigger patterns overlap heavily with other common skills

High Priority:

⚠️ Description is too generic ("helps with tasks", "assists users")
⚠️ Trigger keywords buried in long description
⚠️ Missing key verbs or nouns that users would naturally use
⚠️ Ambiguous scope (could apply to too many or too few situations)

Optimization Opportunities:

💡 Could add explicit trigger examples to description
💡 Could make description more action-oriented
💡 Could add domain-specific terminology
💡 Could clarify when NOT to use skill

Good Patterns:

✅ Description starts with clear trigger context
✅ Includes specific verbs that map to user intent
✅ Provides clear scope boundaries
✅ Uses "Use when..." or "This skill should be used when..." patterns

严重问题：

❌ 缺失或极其模糊的描述字段
❌ 描述与Skill实际能力不匹配
❌ 无法从描述中识别清晰的触发模式
❌ 触发模式与其他常用Skill高度重叠

高优先级问题：

⚠️ 描述过于通用（如“协助完成任务”“帮助用户”）
⚠️ 触发关键词被淹没在冗长描述中
⚠️ 缺失用户自然会使用的关键动词或名词
⚠️ 范围模糊（适用场景过多或过少）

优化机会：

💡 可在描述中添加明确的触发示例
💡 可让描述更具行动导向
💡 可添加领域特定术语
💡 可明确说明何时不应使用该Skill

良好模式：

✅ 描述以清晰的触发场景开头
✅ 包含与用户意图匹配的具体动词
✅ 提供明确的范围边界
✅ 使用“当……时使用”或“该Skill应在……时使用”的表述模式

2. Token Efficiency Analysis

2. Token效率分析

Token Waste Patterns:

Redundancy:

🔴 Repeating the same concept in multiple ways without adding clarity
🔴 Restating information already in the description
🔴 Duplicate examples that teach the same pattern
🔴 Verbose explanations where concise language would work

Example - Before (wasteful):

This skill helps you create documents. It's useful for document creation.
When you need to make a document, this skill can help. Documents that can
be created include reports, letters, and memos.

Example - After (efficient):

Creates professional documents including reports, letters, and memos.

Over-Politeness:

🔴 Excessive apologetic language ("please", "kindly", "if you don't mind")
🔴 Unnecessary hedging ("might", "perhaps", "possibly") where direct instruction works
🔴 Filler phrases ("it should be noted that", "it's important to mention")

Example - Before:

You might want to perhaps consider possibly using this approach if you think it could help.

Example - After:

Use this approach when [specific condition].

Bloated Structure:

🔴 Excessive nested XML tags when flat structure would work
🔴 Long prose explanations where bullet points are clearer
🔴 Including "meta" instructions about the skill itself (usually unnecessary)
🔴 Detailed explanations of concepts Claude already knows

Over-Specified Formatting:

🔴 Dictating exact phrasing for every possible response
🔴 Template sentences that reduce flexibility
🔴 Formatting rules that don't materially impact quality

Efficiency Checklist:

Calculate estimated token count (rough: 1 token ≈ 4 characters)
Identify sections that could be condensed by 30%+
Flag any paragraph longer than 100 words for review
Look for opportunities to replace prose with structured format

Token浪费模式：

冗余内容：

🔴 以多种方式重复同一概念但未提升清晰度
🔴 重复描述字段中已有的信息
🔴 重复教授同一模式的示例
🔴 使用冗长解释，而简洁语言即可表达清楚

示例 - 优化前（浪费Token）：

This skill helps you create documents. It's useful for document creation.
When you need to make a document, this skill can help. Documents that can
be created include reports, letters, and memos.

示例 - 优化后（高效）：

Creates professional documents including reports, letters, and memos.

过度礼貌表述：

🔴 过多道歉类语言（如“please”“kindly”“if you don't mind”）
🔴 在可直接指令的场景中使用不必要的模糊表述（如“might”“perhaps”“possibly”）
🔴 填充性短语（如“it should be noted that”“it's important to mention”）

示例 - 优化前：

You might want to perhaps consider possibly using this approach if you think it could help.

示例 - 优化后：

Use this approach when [specific condition].

臃肿结构：

🔴 在可使用扁平结构的场景中使用过多嵌套XML标签
🔴 使用冗长段落解释，而项目符号列表更清晰
🔴 包含关于Skill本身的“元”指令（通常不必要）
🔴 详细解释Claude已掌握的概念

过度指定格式：

🔴 规定每个可能响应的精确措辞
🔴 使用降低灵活性的模板句子
🔴 对质量无实质影响的格式规则

效率检查清单：

估算Token数量（大致：1 Token ≈ 4个字符）
识别可压缩30%以上的章节
标记任何超过100词的段落以供审核
寻找用结构化格式替代散文式表述的机会

3. Anti-Pattern Detection

3. 反模式检测

Reference the prompting-pattern-library skill for detailed anti-patterns. Key failures to check:

Ambiguity Failures:

❌ Unclear success criteria ("make it better", "improve quality")
❌ Vague output format requirements
❌ Ambiguous scope ("explain X" without audience/depth specification)
❌ Undefined technical terms or jargon

Conflicting Instructions:

❌ "Be concise but comprehensive"
❌ "Be creative but follow strict rules"
❌ "Be formal but conversational"
❌ Multiple competing priorities without clear hierarchy

Implicit Assumptions:

❌ Assuming Claude knows context not provided in skill
❌ Assuming knowledge beyond training cutoff
❌ Assuming familiarity with domain-specific processes
❌ Assuming Claude can access external state/memory

Over-Constraint:

❌ So many rules that quality suffers (rule count > 20 is warning sign)
❌ Micro-managing phrasing instead of outcomes
❌ Restricting Claude's reasoning ability unnecessarily
❌ Specifying implementation details instead of desired results

Under-Specification:

❌ No examples for complex or novel tasks
❌ Missing error handling guidance
❌ No quality criteria defined
❌ Unclear edge case handling

参考prompting-pattern-library Skill获取详细的反模式内容。需检查的关键问题：

模糊性问题：

❌ 成功标准不明确（如“做得更好”“提升质量”）
❌ 输出格式要求模糊
❌ 范围模糊（如“解释X”但未指定受众/深度）
❌ 未定义的技术术语或行话

冲突指令：

❌ “既要简洁又要全面”
❌ “既要富有创意又要严格遵循规则”
❌ “既要正式又要口语化”
❌ 多个相互竞争的优先级且无明确层级

隐含假设：

❌ 假设Claude知晓Skill中未提供的上下文
❌ 假设Claude掌握训练截止日期之后的知识
❌ 假设Claude熟悉领域特定流程
❌ 假设Claude可访问外部状态/记忆

过度约束：

❌ 规则过多导致质量下降（规则数量>20为警告信号）
❌ 微观管理措辞而非关注结果
❌ 不必要地限制Claude的推理能力
❌ 指定实现细节而非期望结果

规格不足：

❌ 复杂或新颖任务无示例
❌ 缺失错误处理指导
❌ 未定义质量标准
❌ 边缘情况处理不明确

4. Clarity and Structure Review

4. 清晰度与结构审核

Structural Issues:

⚠️ No clear sections or organization (wall of text)
⚠️ Instructions scattered throughout instead of logically grouped
⚠️ Missing or unclear headers
⚠️ Poor information hierarchy (important stuff buried)
⚠️ Inconsistent formatting (switching between styles)

Language Clarity:

⚠️ Overly complex sentences (25+ words frequently)
⚠️ Passive voice where active is clearer
⚠️ Abstract concepts without concrete examples
⚠️ Technical jargon without definitions
⚠️ Pronouns with unclear antecedents

Better Patterns:

✅ Use imperative voice ("Create X" not "You should create X")
✅ One instruction per sentence when possible
✅ Concrete examples alongside abstract rules
✅ Consistent terminology throughout
✅ Clear section headers that preview content

结构问题：

⚠️ 无清晰章节或组织（大段无分隔文本）
⚠️ 指令分散而非逻辑分组
⚠️ 缺失或不清晰的标题
⚠️ 信息层级混乱（重要内容被埋没）
⚠️ 格式不一致（在不同样式间切换）

语言清晰度问题：

⚠️ 过于复杂的句子（频繁出现25词以上的句子）
⚠️ 在可用主动语态的场景中使用被动语态
⚠️ 抽象概念无具体示例
⚠️ 技术行话无定义
⚠️ 指代不明的代词

良好模式：

✅ 使用祈使语气（如“创建X”而非“你应该创建X”）
✅ 尽可能每句对应一个指令
✅ 抽象规则搭配具体示例
✅ 全程使用一致术语
✅ 使用可预览内容的清晰章节标题

5. Example Quality Assessment

5. 示例质量评估

Poor Examples:

❌ Examples that don't demonstrate the core pattern
❌ Overly simple examples that miss edge cases
❌ Examples without explanation of why they work
❌ Too many examples teaching the same thing
❌ Examples using outdated syntax or practices

High-Quality Examples:

✅ Show before/after or good/bad contrasts
✅ Include "why this works" explanations
✅ Cover common edge cases
✅ Demonstrate key patterns concisely
✅ Realistic scenarios (not toy problems)

Example Count:

0 examples: Usually needs at least 1-2 for complex tasks
1-3 examples: Usually optimal
4-6 examples: Carefully evaluate if all are necessary
7+ examples: Almost always contains redundancy

劣质示例：

❌ 示例未展示核心模式
❌ 过于简单的示例未覆盖边缘情况
❌ 示例未解释其有效的原因
❌ 过多示例教授同一内容
❌ 使用过时语法或实践的示例

高质量示例：

✅ 展示优化前后或优劣对比
✅ 包含“为何有效”的解释
✅ 覆盖常见边缘情况
✅ 简洁展示关键模式
✅ 真实场景（而非玩具问题）

示例数量：

0个示例：复杂任务通常至少需要1-2个示例
1-3个示例：通常为最优数量
4-6个示例：需仔细评估是否所有示例均必要
7+个示例：几乎必然存在冗余

6. Special Pattern Checks

6. 特殊模式检查

Tool Usage Instructions:

⚠️ Are tool-calling instructions actually necessary?
⚠️ Does skill over-specify when Claude should know?
⚠️ Are there instructions about tools Claude doesn't have access to?

Meta-Instructions:

⚠️ Instructions about "how to use this skill" (usually redundant with description)
⚠️ Explaining skill's purpose inside the skill (already in description)
⚠️ Documentation for documentation's sake

Conditional Logic:

⚠️ Complex if/then trees that Claude can reason about independently
⚠️ Edge case handling that duplicates Claude's reasoning
⚠️ Over-specified decision trees (trust Claude's judgment more)

工具使用指令：

⚠️ 工具调用指令是否真的必要？
⚠️ Skill是否过度指定Claude本应知晓的内容？
⚠️ 是否包含关于Claude无法访问的工具的指令？

元指令：

⚠️ 关于“如何使用该Skill”的指令（通常与描述重复）
⚠️ 在Skill内部解释Skill的用途（已在描述中说明）
⚠️ 为了文档而文档的内容

条件逻辑：

⚠️ Claude可独立推理的复杂if/then分支
⚠️ 与Claude推理能力重复的边缘情况处理
⚠️ 过度指定的决策树（应更多信任Claude的判断）

Output Format

输出格式

Structure analysis results as follows:

按以下结构组织分析结果：

Skill Overview

Skill概述

Name: [skill name]
Estimated token count: [rough estimate]
Overall assessment: [1-2 sentence summary]

名称：[Skill名称]
估算Token数量：[大致估算]
总体评估：[1-2句总结]

Critical Issues (Must Fix)

严重问题（必须修复）

[List any critical problems that will prevent skill from working]

[列出所有会导致Skill无法工作的严重问题]

High Priority Improvements

高优先级改进

[List significant improvements that will materially help]

[列出可实质性提升Skill效果的重要改进建议]

Token Optimization Opportunities

Token优化机会

[Specific sections/patterns that waste tokens with estimates]

Section X: ~[N] tokens could be saved by [specific change]
Pattern Y: ~[N] tokens wasted on [specific issue]

[指出浪费Token的具体章节/模式及估算]

章节X：通过[具体修改]可节省约[N]个Token
模式Y：因[具体问题]浪费约[N]个Token

Medium Priority Suggestions

中优先级建议

[Helpful improvements that aren't urgent]

[有帮助但不紧急的改进建议]

Low Priority Polish

低优先级优化

[Nice-to-haves that would marginally improve]

[可小幅提升体验的锦上添花内容]

Rewrite Suggestions

重写建议

[For any section with critical issues, provide rewritten version]

Before (X tokens):

[original text]

After (Y tokens, Z% reduction):

[optimized text]

[对存在严重问题的章节提供重写版本]

优化前（X个Token）：

[原文]

优化后（Y个Token，减少Z%）：

[优化后的文本]

Estimated Impact

预估影响

Total potential token savings: ~[N] tokens ([X]%)
Clarity improvement: [Significant/Moderate/Minor]
Trigger reliability: [Better/Same/Need testing]

潜在总Token节省量：约[N]个Token（[X]%）
清晰度提升：[显著/中等/轻微]
触发可靠性：[提升/不变/需测试]

Analysis Process

分析流程

First Pass - Skim
- Get overall sense of skill purpose
- Check description field first
- Note structure and organization
- Flag any obvious red flags
Second Pass - Deep Dive
- Run through each checklist section systematically
- Mark specific line numbers or sections with issues
- Count approximate tokens in bloated sections
- Identify patterns (don't just note individual issues)
Third Pass - Synthesize
- Prioritize findings by severity and impact
- Group related issues together
- Prepare concrete rewrite examples for worst sections
- Calculate potential savings
Output Generation
- Start with most critical issues
- Be specific (quote exact text, give line numbers)
- Provide rewrites, not just criticism
- Estimate token impacts
- Balance criticism with recognition of what works well

第一遍 - 快速浏览
- 整体了解Skill用途
- 首先检查描述字段
- 注意结构与组织方式
- 标记明显的危险信号
第二遍 - 深入分析
- 系统地逐一检查每个清单章节
- 标记存在问题的具体行号或章节
- 估算臃肿章节的Token数量
- 识别模式（而非仅记录单个问题）
第三遍 - 综合整理
- 按严重程度和影响优先级排序发现的问题
- 将相关问题分组
- 为问题最严重的章节准备具体的重写示例
- 计算潜在的Token节省量
生成输出
- 从最严重的问题开始
- 内容具体（引用确切文本，给出行号）
- 提供重写版本而非仅批评
- 估算Token影响
- 在批评的同时认可Skill的优点

Key Principles

核心原则

Be Specific

具体明确

❌ "The description could be better" ✅ "The description 'helps with tasks' is too vague. Suggest: 'Analyzes code quality metrics and suggests refactoring priorities for Python codebases'"

❌ “描述可以更好” ✅ “描述‘协助完成任务’过于模糊。建议修改为：‘分析Python代码库的代码质量指标并提出重构优先级建议’”

Show Impact

展示影响

❌ "This section is redundant" ✅ "Lines 45-78 repeat concepts from lines 12-23, wasting ~120 tokens (18% of skill)"

❌ “该章节冗余” ✅ “第45-78行重复了第12-23行的内容，浪费约120个Token（占Skill总Token的18%）”

Provide Solutions

提供解决方案

❌ "This doesn't work" ✅ "This doesn't work because [reason]. Instead, try: [concrete rewrite]"

❌ “这无法正常工作” ✅ “这无法正常工作的原因是[具体原因]。建议尝试：[具体重写内容]”

Respect Intent

尊重意图

Understand what the skill author was trying to achieve
Preserve core functionality while optimizing
Don't just delete - replace with better alternatives
Acknowledge trade-offs in suggestions

理解Skill作者的目标
在优化的同时保留核心功能
不要仅删除内容，而是用更好的替代方案替换
在建议中说明权衡

Context Matters

结合上下文

A 2000-token skill for complex workflows may be appropriate
A 2000-token skill for simple formatting is bloated
Judge efficiency relative to task complexity
Consider how frequently skill will be triggered

针对复杂工作流的2000 Token Skill可能是合理的
针对简单格式化的2000 Token Skill则过于臃肿
相对于任务复杂度判断效率
考虑Skill的触发频率

Common Optimization Wins

常见优化成果

Quick Wins (Usually Save 20-40% Tokens)

快速优化（通常节省20-40%的Token）

1. Remove Meta-Commentary Delete sections explaining the skill to Claude (Claude will read and understand)

2. Condense Verbose Prose Replace paragraphs with bullet points, remove filler words

3. Consolidate Examples Replace 5 similar examples with 2 contrasting examples

4. Trust Claude's Reasoning Remove over-specified decision trees and edge case handling

5. Simplify Structure Flatten unnecessary XML nesting, remove redundant headers

1. 删除元注释 删除向Claude解释Skill的章节（Claude会自行阅读并理解）

2. 压缩冗长散文 用项目符号列表替代段落，删除填充词

3. 合并示例 用2个对比示例替代5个相似示例

4. 信任Claude的推理能力 删除过度指定的决策树和边缘情况处理

5. 简化结构 扁平化不必要的XML嵌套，删除冗余标题

Deep Optimizations (Can Save 40-60% Tokens)

深度优化（可节省40-60%的Token）

1. Rewrite Entire Sections Take bloated sections and rewrite from scratch focusing on clarity

2. Remove Implicit Instructions Delete instructions about things Claude already knows how to do

3. Consolidate Redundant Concepts Merge sections teaching the same pattern multiple ways

4. Streamline Tool Instructions Trust Claude's tool-use abilities more, remove over-specification

5. Clarify Over Adding Instead of adding more examples/explanation, clarify existing content

1. 重写整个章节 针对臃肿章节从零开始重写，聚焦清晰度

2. 删除隐含指令 删除关于Claude已掌握技能的指令

3. 合并冗余概念 合并多次教授同一模式的章节

4. 简化工具指令 更多信任Claude的工具使用能力，删除过度指定内容

5. 优先明确而非添加 不要添加更多示例/解释，而是优化现有内容的清晰度

Red Flags for Common Skill Issues

常见Skill问题的危险信号

"My skill isn't triggering"

“我的Skill没有触发”

Check:

Description too vague or generic?
Description doesn't mention key trigger words?
Skill scope overlaps too much with existing skills?
Trigger pattern requires exact phrasing user won't say?

检查方向：

描述是否过于模糊或通用？
描述是否未提及关键触发词？
Skill范围是否与现有Skill过度重叠？
触发模式是否要求用户使用不会说的精确措辞？

"My skill triggers too often"

“我的Skill触发过于频繁”

Check:

Description too broad ("helps with writing")?
Missing scope boundaries or exclusions?
Generic trigger words that match many queries?
Need more specific domain terminology?

检查方向：

描述是否过于宽泛（如“协助写作”）？
是否缺失范围边界或排除条件？
是否使用了与许多查询匹配的通用触发词？
是否需要添加更具体的领域术语？

"My skill gives inconsistent results"

“我的Skill结果不一致”

Check:

Conflicting instructions?
Ambiguous success criteria?
Too many conditional branches?
Under-specified output requirements?

检查方向：

是否存在冲突指令？
成功标准是否模糊？
是否存在过多条件分支？
输出要求是否规格不足？

"My skill seems slow"

“我的Skill运行缓慢”

Check:

Token count >2000? (high context load)
Requesting Claude read multiple large references?
Over-complicated reasoning chains?
Excessive examples or edge case handling?

检查方向：

Token数量是否超过2000？（上下文负载过高）
是否要求Claude读取多个大型参考资料？
是否存在过于复杂的推理链？
是否存在过多示例或边缘情况处理？

Reference Integration

参考集成

This skill works alongside:

prompting-pattern-library: Reference for patterns and anti-patterns
token-budget-advisor: Assess if skill fits within token budgets
skill-creator: Guidelines for building skills initially
learning-capture: Identify patterns from analysis to capture

When analyzing prompts, reference the prompting-pattern-library for detailed pattern explanations. Focus this skill on active diagnosis and concrete suggestions.

该Skill可与以下工具配合使用：

prompting-pattern-library: 参考模式与反模式内容
token-budget-advisor: 评估Skill是否符合Token预算
skill-creator: 初始构建Skill的指南
learning-capture: 从分析中识别可留存的模式

分析提示词时，参考prompting-pattern-library获取详细的模式解释。本Skill专注于主动诊断和具体建议。

Limitations and Caveats

局限性与注意事项

What this skill can't do:

Guarantee a skill will trigger in all desired situations (triggering is complex)
Test actual skill performance (requires real usage)
Determine if skill logic is correct for domain (needs domain expertise)
Predict user behavior or query patterns

Best used for:

Identifying clear anti-patterns and inefficiencies
Suggesting specific improvements with examples
Estimating token costs and optimization potential
Catching common failure modes before publication

Remember:

Analysis is a starting point, not gospel
Some verbose skills are appropriately complex
User intent matters more than arbitrary token targets
Test optimized versions to ensure they still work correctly

该Skill无法完成的工作：

保证Skill在所有期望场景中触发（触发逻辑复杂）
测试Skill的实际性能（需要真实使用数据）
判断Skill逻辑是否适用于特定领域（需要领域专业知识）
预测用户行为或查询模式

最佳适用场景：

识别明确的反模式和低效问题
提供具体的改进建议及示例
估算Token成本和优化潜力
在发布前发现常见的故障模式

请记住：

分析只是起点，并非绝对标准
部分冗长的Skill可能是为了应对复杂任务
用户意图比任意Token目标更重要
测试优化后的版本以确保其仍能正常工作