prompt-validator

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Skill: Validador de Prompts

技能：提示词验证器

Validar y mejorar prompts dirigidos a agentes de IA aplicando un conjunto fijo de 11 reglas de redacción imperativa.

El skill no ejecuta el prompt ni produce el código pedido; solo audita la redacción y devuelve un informe accionable.

验证并优化面向AI代理的提示词，应用一套固定的11条祈使式撰写规则。

本技能不会执行提示词或生成所需代码；仅审核提示词的撰写方式，并返回可执行的评估报告。

Propósito

目的

Auditar un prompt recibido del usuario y devolver:

Un porcentaje de efectividad del prompt (0–100%), basado en cuántas reglas evaluables cumple.
Una lista de sugerencias de mejora concretas, con: texto actual, propuesta de reemplazo y motivo. La regla aplicada se muestra como referencia discreta, no como acusación.
Una propuesta de prompt reescrito que aplique todas las sugerencias.

Usar cuando el usuario pida revisar, validar, mejorar o auditar un prompt; o cuando pegue un prompt en el chat y pida feedback sobre su redacción.

审核用户提供的提示词，并返回：

提示词的有效率百分比（0–100%），基于符合可评估规则的数量计算。
具体的改进建议列表，包含：当前文本、替换方案及改进原因。所应用的规则作为参考展示，而非指责。
一份重写后的提示词方案，整合所有改进建议。

当用户要求审核、验证、改进或评估提示词，或是在聊天中粘贴提示词并询问其撰写反馈时使用本技能。

Alcance

适用范围

Incluye:

Análisis de prompts dirigidos a agentes de código (Claude Code, Cursor, Copilot, Cline, etc.).
Detección de las 11 oportunidades de mejora tipificadas en Reglas.
Sugerencia concreta de reemplazo para cada oportunidad detectada.
Cálculo del porcentaje de efectividad del prompt.
Generación de un prompt reescrito final que integre todas las sugerencias.

No incluye:

Ejecutar o cumplir el prompt (no escribir el código, middleware, refactor, etc. que el prompt pide).
Evaluar la corrección técnica del contenido del prompt (si la solución pedida tiene sentido en el stack del usuario). El skill audita redacción, no arquitectura.
Reglas distintas de las 11 listadas (estilo de redacción literaria, ortografía, gramática general).
Validar prompts para imagen, audio o tareas no-código (el skill está calibrado a prompts de desarrollo).

包含：

分析面向代码类AI代理（Claude Code、Cursor、Copilot、Cline等）的提示词。
检测规则中列出的11类典型改进机会。
为每个检测到的改进机会提供具体的替换建议。
计算提示词的有效率百分比。
生成整合所有建议的最终重写提示词。

不包含：

执行或完成提示词要求的任务（不编写提示词所要求的代码、中间件、重构内容等）。
评估提示词内容的技术正确性（即用户要求的解决方案在其技术栈中是否合理）。本技能仅审核撰写方式，而非架构设计。
11条规则之外的其他规则（文学写作风格、拼写、通用语法等）。
验证面向图像、音频或非代码类任务的提示词（本技能针对开发类提示词校准）。

Entradas

输入

Para ejecutar bien el skill, el agente necesita:

Obligatorio: el texto del prompt a auditar, completo y literal.
Opcional:
- type
  — declara explícitamente el tipo de prompt. Valores permitidos:
  - ```
  Funcional
```
  — describe comportamiento, criterios de aceptación (
```
  BR-XX
```
  ,
```
  SC-XX
```
  ), reglas de negocio o necesidad del usuario (p. ej. user stories, descripciones de feature, especificaciones de comportamiento). No requiere detalles técnicos como rutas, nombres de clase o archivos. Las reglas de delimitar alcance y usar nombres exactos se marcan N/A.
- ```
Técnico
```
    — solicita implementación, refactor o cambios concretos de código (p. ej. "crea AuthService", "refactoriza /features/auth"). Las reglas de delimitar alcance y usar nombres exactos aplican plenamente.
  El usuario puede declararlo de varias formas:
```
type: Funcional
```
  ,
```
type=Funcional
```
  ,
```
tipo=Funcional
```
  , o en lenguaje natural ("es un prompt funcional", "este es técnico"). El agente reconoce ambas formas y normaliza variantes sin acento (
```
tecnico
```
  →
```
Técnico
```
  ).
  Si no se declara, el agente lo infiere — ver paso 0 de Ejecución del análisis.
- Lenguaje/stack del proyecto (ayuda a juzgar si un nombre es "exacto" o genérico, p. ej.
```
AuthService
```
  vs
```
un servicio
```
  ).
- Si el usuario quiere solo las sugerencias o también el prompt reescrito (por defecto: ambos).
- Si el prompt es un fragmento de uno mayor o independiente (un fragmento puede legítimamente referirse a contexto ya establecido).

Si el prompt llega como captura, imagen o referencia indirecta (p. ej. "el prompt que te pasé ayer"), pedir el texto literal antes de auditar. No inventar el contenido.

为了良好执行本技能，代理需要：

必填： 待审核的提示词完整原文。
可选：
- type
  — 明确声明提示词类型。允许的值：
  - ```
  Funcional
```
  （功能类）—— 描述行为、验收标准（
```
  BR-XX
```
  、
```
  SC-XX
```
  ）、业务规则或用户需求（例如用户故事、功能描述、行为规范）。不需要路径、类名或文件名等技术细节。范围界定和使用确切名称的规则标记为N/A。
- ```
Técnico
```
    （技术类）—— 请求实现、重构或具体的代码修改（例如“创建AuthService”、“重构/features/auth”）。范围界定和使用确切名称的规则完全适用。
  用户可以通过多种方式声明：
```
type: Funcional
```
  、
```
type=Funcional
```
  、
```
tipo=Funcional
```
  ，或自然语言表述（“这是一个功能类提示词”、“这是技术类的”）。代理可识别这两种形式，并对无重音的变体进行标准化（
```
tecnico
```
  →
```
Técnico
```
  ）。
  如果未明确声明，代理将自动推断—— 参见分析执行流程的步骤0。
- 项目的语言/技术栈（有助于判断某个名称是“确切”还是“通用”，例如
```
AuthService
```
  vs
```
一个服务
```
  ）。
- 用户是否只需要改进建议还是同时需要重写后的提示词（默认：两者都提供）。
- 提示词是某个完整提示词的片段还是独立完整的提示词（片段可合理引用已建立的上下文）。

如果提示词以截图、图片或间接引用形式提供（例如“我昨天发给你的那个提示词”），必须先请求原文再进行审核。不得自行编造内容。

Salidas

输出

El skill siempre responde con esta estructura:

undefined

本技能始终按照以下结构返回结果：

undefined

Análisis del prompt

提示词分析

Prompt analizado:

[transcripción literal del prompt]

Tipo detectado: Funcional | Técnico

Efectividad: XX%

Reglas no evaluables: [descripciones, ver reglas de formato abajo]

Reglas cumplidas: [descripciones, ver reglas de formato abajo]

待分析提示词：

[提示词原文转录]

检测到的类型： 功能类 | 技术类

有效率：XX%

不可评估规则： [描述，参见下方格式规则]

符合规则： [描述，参见下方格式规则]

Sugerencias de mejora

改进建议

1. [Título corto de la mejora]

Texto actual: "<fragmento literal>"
Propuesta: "<reemplazo concreto>"
Por qué mejora: <explicación en 1 línea>
Regla: [nombre de la regla]

[... una entrada por cada sugerencia, numeradas en orden de regla ...]

1. [简短改进标题]

当前文本："<原文片段>"
建议方案："<具体替换内容>"
改进原因：<1行解释>
规则：[规则名称]

[...每个建议对应一条条目，按规则顺序编号...]

Prompt reescrito (propuesta)

重写后的提示词（方案）

[prompt completo aplicando todas las sugerencias]


Si el prompt **no tiene oportunidades de mejora**, omitir la sección "Sugerencias de mejora" y la propuesta reescrita; el bloque de cabecera (Tipo, Efectividad, Reglas no evaluables, Reglas cumplidas) se mantiene seguido de:

Sin sugerencias.


Si el usuario pidió **solo sugerencias** o **solo prompt reescrito**, devolver únicamente esa sección manteniendo el bloque de cabecera arriba.

[整合所有建议的完整提示词]


如果提示词**没有改进空间**，则省略“改进建议”部分和重写方案；保留标题块（类型、有效率、不可评估规则、符合规则），并添加：

无改进建议。


如果用户明确要求**仅提供改进建议**或**仅提供重写后的提示词**，则仅返回对应部分，同时保留上方的标题块。

Reglas de formato para listas de reglas

规则列表格式规则

Aplicar a

Reglas no evaluables

Reglas cumplidas

y a la cita

Regla:

dentro de cada sugerencia:

No mostrar códigos (
```
R-1
```
,
```
R-2
```
, …): usar siempre el nombre/descripción de la regla (p. ej.
```
Usar verbos imperativos directos
```
).
No numerar los elementos (sin
```
1.
```
,
```
2.
```
, …): el orden no aporta valor.
Siempre presentar como lista con viñetas, una regla por línea, independientemente de la cantidad de elementos.
Separar cada bloque de cabecera con una línea en blanco (
```
Tipo detectado
```
,
```
Efectividad
```
,
```
Reglas no evaluables
```
,
```
Reglas cumplidas
```
): sin línea en blanco el renderizador los fusiona en un mismo párrafo.
En
```
Reglas no evaluables
```
se puede añadir un paréntesis breve aclarando el motivo cuando sea no obvio: p. ej.
```
Delimitar el alcance (N/A en prompt funcional)
```
.

R-9 se reporta siempre como bloque aparte

Mejora opcional · refinamiento de exclusividad

(no en

Reglas cumplidas

ni en

Sugerencias de mejora

), sin afectar el porcentaje.

Ejemplo de formato:

Reglas no evaluables:

Delimitar el alcance (N/A en prompt funcional)

Usar nombres exactos (N/A en prompt funcional)

Reglas cumplidas:

Usar verbos imperativos directos

Evitar lenguaje conversacional

Usar acciones específicas

Evitar términos subjetivos

Usar "NO" explícitos

Evitar instrucciones implícitas

Una intención por frase

Usar formato checklist para listas de tareas

适用于

不可评估规则

、

符合规则

以及每个建议中的

规则:

引用：

不显示规则代码（
```
R-1
```
、
```
R-2
```
…）：始终使用规则的名称/描述（例如
```
使用直接祈使动词
```
）。
不编号条目（不使用
```
1.
```
、
```
2.
```
…）：顺序无意义。
始终以项目符号列表呈现，每条规则占一行，无论条目数量多少。
标题块的每个部分之间空一行（
```
检测到的类型
```
、
```
有效率
```
、
```
不可评估规则
```
、
```
符合规则
```
）：如果不空行，渲染器会将它们合并为同一段落。
在
```
不可评估规则
```
中，可添加简短括号说明非显而易见的原因：例如
```
范围界定（功能类提示词中为N/A）
```
。
R-9始终作为独立块
```
可选优化 · 排他性细化
```
呈现（不包含在
```
符合规则
```
或
```
改进建议
```
中），不影响有效率百分比。

格式示例：

不可评估规则：

范围界定（功能类提示词中为N/A）

使用确切名称（功能类提示词中为N/A）

符合规则：

使用直接祈使动词

避免会话式语言

使用具体动作

避免主观术语

使用明确的“NO”表述

避免隐含指令

单句单一意图

对任务列表使用清单格式

Cálculo de efectividad

有效率计算

Efectividad = (Reglas cumplidas / Reglas evaluables) × 100, redondeado al entero más cercano.
Reglas evaluables = de las 11, las que aplican al prompt. Descontar las marcadas como N/A:
- R-5 y R-10 son N/A si el tipo de prompt es Funcional.
- R-11 es N/A si el prompt no enumera ≥2 acciones.
- Cualquier regla cuyo patrón no aplica al contenido del prompt.
R-9 (refinamiento opcional) no entra en el cálculo del porcentaje. Si aplica, se muestra como sugerencia separada bajo el título
```
Mejora opcional · refinamiento de exclusividad
```
, sin afectar la efectividad.

有效率 = (符合规则数 / 可评估规则数) × 100，四舍五入至最接近的整数。
可评估规则数 = 11条规则中适用于当前提示词的数量。扣除标记为N/A的规则：
- 如果提示词类型为功能类，则R-5和R-10为N/A。
- 如果提示词未列出≥2个动作，则R-11为N/A。
- 任何规则的模式不适用于提示词内容的，也标记为N/A。
R-9（可选细化规则）不纳入有效率计算。如果适用，将作为独立建议显示在
```
可选优化 · 排他性细化
```
标题下，不影响有效率。

Reglas

规则

Las 11 reglas de auditoría. Cada una incluye el patrón a detectar y ejemplos MAL → BIEN.

11条审核规则，每条包含检测模式和错误→正确示例。

R-1 · Usar verbos imperativos directos

R-1 · 使用直接祈使动词

Detectar verbos en modo no-imperativo dirigidos al agente (

puedes

podrías

deberías

sería bueno que

tendrías que

MAL:
```
Puedes crear un middleware
```
BIEN:
```
Crea un middleware
```

检测面向代理的非祈使动词（对应中文的“可以”、“能否”、“应该”、“最好”、“需要”等表述）。

错误示例：
```
Puedes crear un middleware
```
（你可以创建一个中间件）
正确示例：
```
Crea un middleware
```
（创建一个中间件）

R-2 · Evitar lenguaje conversacional

R-2 · 避免会话式语言

Detectar fórmulas de cortesía o desiderativas dirigidas al agente (

me gustaría que

te pido que

necesito que por favor

quisiera

por favor

MAL:

Me gustaría que implementes refresh tokens

BIEN:
```
Implementa refresh tokens
```

检测面向代理的礼貌用语或愿望式表述（对应中文的“我希望”、“请你”、“麻烦你”、“我想要”等）。

错误示例：
```
Me gustaría que implementes refresh tokens
```
（我希望你实现刷新令牌）
正确示例：
```
Implementa refresh tokens
```
（实现刷新令牌）

R-3 · Usar acciones específicas

R-3 · 使用具体动作

Detectar verbos genéricos sin objeto concreto:

mejorar

optimizar

arreglar

pulir

revisar

cuando no van acompañados de qué exactamente y cómo.

MAL:
```
Mejora la autenticación
```

BIEN:

Implementa refresh token con expiración automática a los 15 minutos

检测无具体对象的通用动词：对应中文的“改进”、“优化”、“修复”、“打磨”、“审核”，且未伴随具体内容和实现方式。

错误示例：
```
Mejora la autenticación
```
（改进认证功能）

正确示例：

Implementa refresh token con expiración automática a los 15 minutos

（实现自动15分钟过期的刷新令牌）

R-4 · Evitar términos subjetivos

R-4 · 避免主观术语

Lista cerrada de términos ambiguos para un agente. Detectar:

limpio

bonito

elegante

robusto

escalable

profesional

moderno

bien hecho

de calidad

idiomático

MAL:
```
Hazlo limpio y moderno
```

BIEN:

Usa componentes pequeños (<150 líneas) y separación feature-based bajo /features

Cada término subjetivo detectado debe convertirse en una restricción observable concreta en la sugerencia.

检测一组对代理而言模糊的术语：对应中文的“简洁”、“美观”、“优雅”、“健壮”、“可扩展”、“专业”、“现代”、“完善”、“高质量”、“符合语言习惯”。

错误示例：
```
Hazlo limpio y moderno
```
（做得简洁又现代）
正确示例：
```
Usa componentes pequeños (<150 líneas) y separación feature-based bajo /features
```
（使用小型组件（<150行），并在/features下按功能拆分）

每个检测到的主观术语必须在建议中转换为具体的可观测约束。

R-5 · Delimitar el alcance

R-5 · 范围界定

Solo aplica a prompts de tipo Técnico. En prompts Funcionales (descripciones de comportamiento, user stories, criterios de aceptación), la falta de ruta o módulo concreto no es una oportunidad de mejora: marcar la regla como N/A y excluirla del cálculo de efectividad.

Detectar instrucciones globales sin ruta, módulo o entidad concreta:

refactoriza el proyecto

revisa todo el código

actualiza el sistema

MAL:
```
Refactoriza el proyecto
```
BIEN:
```
Refactoriza únicamente /features/auth
```

仅适用于技术类提示词。在功能类提示词（行为描述、用户故事、验收标准）中，缺少具体路径或模块不属于改进机会：将该规则标记为N/A，并排除在有效率计算之外。

检测无具体路径、模块或实体的全局指令（对应中文的“重构整个项目”、“审核所有代码”、“更新系统”）。

错误示例：
```
Refactoriza el proyecto
```
（重构整个项目）
正确示例：
```
Refactoriza únicamente /features/auth
```
（仅重构/features/auth）

R-6 · Usar "NO" explícitos

R-6 · 使用明确的“NO”表述

Detectar prohibiciones tibias o sugeridas:

preferiblemente no

evita en lo posible

trata de no

intenta no usar

MAL:
```
Preferiblemente no usar Redux
```
BIEN:
```
No uses Redux
```

检测模糊或暗示性的禁止表述（对应中文的“最好不要”、“尽量避免”、“尝试不要”、“尽量不要使用”）。

错误示例：
```
Preferiblemente no usar Redux
```
（最好不要使用Redux）
正确示例：
```
No uses Redux
```
（不要使用Redux）

R-7 · Evitar instrucciones implícitas

R-7 · 避免隐含指令

Detectar apelaciones a estándares no especificados:

buenas prácticas

código de calidad

como debe ser

siguiendo las convenciones

código limpio

SOLID

(sin más detalle).

MAL:
```
Hazlo siguiendo buenas prácticas
```
BIEN (checklist explícito):
- Evita lógica en componentes
- Usa hooks para estado
- Separa dominio e infraestructura

Cada apelación implícita debe convertirse en una lista de reglas explícitas en la sugerencia (con tu mejor inferencia razonable del contexto, marcando claramente que son suposiciones a confirmar).

检测对未指定标准的提及（对应中文的“最佳实践”、“高质量代码”、“应有的样子”、“遵循规范”、“简洁代码”、“SOLID原则”）。

错误示例：
```
Hazlo siguiendo buenas prácticas
```
（按照最佳实践来做）
正确示例（明确清单）：
- 避免在组件中编写逻辑
- 使用hooks管理状态
- 分离领域层与基础设施层

每个隐含提及必须在建议中转换为明确的规则列表（基于对上下文的合理推断，并明确标记为待确认的假设）。

R-8 · Una intención por frase

R-8 · 单句单一意图

Detectar frases que mezclan múltiples objetivos con

y aprovecha para

y de paso

y también

mientras tanto

además optimiza

MAL:

Implementa autenticación y aprovecha para mejorar el routing y optimizar el código

BIEN (descompuesto):

```
Implementa autenticación.
```
```
No modifiques routing global.
```
```
No optimices módulos no relacionados.
```

检测混合多个目标的句子，使用对应中文的“顺便”、“同时”、“并且”、“另外还优化”等表述。

错误示例：

Implementa autenticación y aprovecha para mejorar el routing y optimizar el código

（实现认证功能，顺便改进路由并优化代码）

正确示例（拆分）：
- ```
Implementa autenticación.
```
  （实现认证功能。）
- ```
No modifiques routing global.
```
  （不要修改全局路由。）
- ```
No optimices módulos no relacionados.
```
  （不要优化无关模块。）

R-9 · Usar "solo / únicamente / exclusivamente"

R-9 · 使用“仅/唯一/排他”表述

Detectar instrucciones de alcance que podrían ser absolutas pero no llevan el cuantificador exclusivo. Aplicar solo cuando R-5 ya está cumplida (hay un alcance concreto) pero falta el refuerzo de exclusividad.

ACEPTABLE:
```
Modifica archivos dentro de /auth
```

MEJOR:

Modifica únicamente archivos dentro de /auth

Esta regla es de refinamiento: marcarla como

Mejora opcional · refinamiento de exclusividad

en el output y no incluirla en el cálculo del porcentaje de efectividad.

检测范围指令本可以是绝对表述，但缺少排他性限定词的情况。仅当R-5已符合要求（有具体范围）但缺少排他性强化时适用。

可接受：
```
Modifica archivos dentro de /auth
```
（修改/auth目录下的文件）
更优：
```
Modifica únicamente archivos dentro de /auth
```
（仅修改/auth目录下的文件）

本规则属于细化优化：在输出中标记为

可选优化 · 排他性细化

，不纳入有效率百分比计算。

R-10 · Usar nombres exactos

R-10 · 使用确切名称

Solo aplica a prompts de tipo Técnico. En prompts Funcionales se usa lenguaje de dominio ("el flujo de autenticación", "el usuario", "la solicitud"), no nombres de clase, archivo o función: marcar la regla como N/A y excluirla del cálculo de efectividad.

Detectar sustantivos genéricos cuando el contexto permitiría un nombre específico:

un servicio

el componente

una clase

un método

MAL:
```
Crea un servicio
```
BIEN:
```
Crea AuthService
```

Si el prompt no contiene el contexto suficiente para sugerir un nombre exacto, marcar la sugerencia como

Crea <Nombre>Service

y pedir al usuario que rellene el nombre.

仅适用于技术类提示词。在功能类提示词中使用领域语言（“认证流程”、“用户”、“请求”），而非类名、文件名或函数名：将该规则标记为N/A，并排除在有效率计算之外。

检测在上下文允许使用具体名称时使用的通用名词（对应中文的“一个服务”、“该组件”、“一个类”、“一个方法”）。

错误示例：
```
Crea un servicio
```
（创建一个服务）
正确示例：
```
Crea AuthService
```
（创建AuthService）

如果提示词没有足够上下文来建议确切名称，将建议标记为

Crea <Nombre>Service

，并请求用户补充名称。

R-11 · Usar formato checklist para listas de tareas

R-11 · 对任务列表使用清单格式

Detectar prompts que enumeran ≥2 acciones en una sola línea separadas por comas o

sin formato de lista.

MAL:

Implementa middleware auth, hook useAuth y redirect a /login

BIEN:

Implementa:
- middleware auth
- hook useAuth
- redirect a /login

检测将≥2个动作放在同一行，用逗号或“和”分隔且未使用列表格式的提示词。

错误示例：
```
Implementa middleware auth, hook useAuth y redirect a /login
```
（实现auth中间件、useAuth钩子并重定向到/login）

正确示例：

Implementa:
- middleware auth
- hook useAuth
- redirect a /login

Ejecución del análisis

分析执行流程

Para cada prompt recibido, el agente debe:

Determinar el tipo de prompt:
- Si el usuario declaró
  type
  explícitamente (p. ej.
```
type: Funcional
```
  ,
```
type=Tecnico
```
  ,
```
tipo=Funcional
```
  , o en lenguaje natural como "este es un prompt funcional"), usar ese valor. Normalizar variantes sin acento (
```
tecnico
```
  →
```
Técnico
```
  ,
```
funcional
```
  →
```
Funcional
```
  ).
- Si no se declaró, inferirlo:
  - Funcional si el prompt: usa lenguaje de comportamiento (
```
el sistema debe
```
    ,
```
el usuario puede
```
    ,
```
como ... quiero ... para ...
```
    ), describe criterios de aceptación (p. ej.
```
BR-XX
```
    ,
```
SC-XX
```
    , Gherkin), casos de uso o reglas de negocio, y no menciona archivos, rutas, clases, funciones ni verbos de codificación.
  - Técnico si el prompt: pide implementar / refactorizar / crear / modificar / corregir código, menciona archivos, rutas, clases, funciones, endpoints, o usa verbos de codificación (
```
implementa
```
    ,
```
crea
```
    ,
```
refactoriza
```
    ,
```
migra
```
    ,
```
optimiza
```
    ,
```
arregla
```
    ).
  - Si es ambiguo, asumir Técnico (criterio más estricto: aplica más reglas).
- Declarar el tipo en el output. Si fue inferido (no declarado), añadir la nota: "Tipo inferido; declara
  type: Funcional
  o
  type: Técnico
  si quieres cambiarlo.". Si fue declarado, no añadir nota.
Leer el prompt completo y separarlo en frases u oraciones.
Aplicar las 11 reglas en orden, frase por frase. Una misma frase puede activar varias sugerencias (p. ej.
```
Me gustaría que mejores el código de forma elegante
```
activa R-1, R-2, R-3 y R-4). Si el tipo es Funcional, omitir R-5 y R-10 (marcar N/A).
Citar literalmente el fragmento en el campo "Texto actual" de cada sugerencia. No parafrasear el fragmento original; sí parafrasear/reescribir en la propuesta.
Producir la propuesta más concreta posible. Si falta contexto (p. ej. para nombrar
```
AuthService
```
), proponer un placeholder explícito y pedir confirmación.
Calcular la efectividad según la fórmula en Salidas › Cálculo de efectividad.
Generar el prompt reescrito integrando todas las sugerencias, manteniendo la intención original del usuario. No añadir requisitos nuevos que el prompt no contemplaba.

对于收到的每个提示词，代理必须：

确定提示词类型：
- 如果用户明确声明了
  type
  （例如
```
type: Funcional
```
  、
```
type=Tecnico
```
  、
```
tipo=Funcional
```
  ，或自然语言如“这是一个功能类提示词”），使用该值。对无重音的变体进行标准化（
```
tecnico
```
  →
```
Técnico
```
  ，
```
funcional
```
  →
```
Funcional
```
  ）。
- 如果未明确声明，自动推断：
  - 功能类：如果提示词使用行为语言（“系统应”、“用户可以”、“作为…我想要…以便…”）、描述验收标准（例如
```
BR-XX
```
    、
```
SC-XX
```
    、Gherkin）、用例或业务规则，且未提及文件、路径、类、函数或编码动词。
  - 技术类：如果提示词请求实现/重构/创建/修改/修复代码，提及文件、路径、类、函数、端点，或使用编码动词（“实现”、“创建”、“重构”、“迁移”、“优化”、“修复”）。
  - 如果模糊不清，默认假设为技术类（更严格的标准：适用更多规则）。
- 在输出中声明类型。如果是自动推断（未明确声明），添加说明：“类型为自动推断；若需修改，请声明
  type: Funcional
  或
  type: Técnico
  。”。如果是明确声明，则不添加说明。
完整阅读提示词，将其拆分为句子或分句。
按顺序应用11条规则，逐句检查。同一句子可能触发多个建议（例如
```
Me gustaría que mejores el código de forma elegante
```
触发R-1、R-2、R-3和R-4）。如果是功能类提示词，忽略R-5和R-10（标记为N/A）。
逐字引用原文片段作为每个建议的“当前文本”。不得改写原文片段；但可在建议方案中改写/重写。
生成尽可能具体的建议方案。如果缺少上下文（例如命名
```
AuthService
```
），建议使用明确的占位符并请求确认。
根据输出 › 有效率计算中的公式计算有效率。
生成重写后的提示词，整合所有建议，保留用户的原始意图。不得添加提示词未包含的新要求。

Antipatrones

反模式

Evitar al ejecutar este skill:

Cumplir el prompt en lugar de auditarlo (p. ej. el usuario pega
```
Crea un middleware
```
y el agente crea el middleware).
Inventar sugerencias que no derivan de las 11 reglas (no es un skill de estilo libre).
Aplicar R-5 o R-10 a un prompt Funcional: en descripciones de comportamiento o user stories, la ausencia de rutas y nombres de clase es esperada, no una oportunidad de mejora. Marcar N/A y excluir del cálculo.
Penalizar el refinamiento opcional en la efectividad: la regla de exclusividad (
```
solo
```
/
```
únicamente
```
) es refinamiento, no entra en el porcentaje.
Reescribir la intención del prompt en la propuesta final (añadir features, cambiar el stack, decidir por el usuario decisiones de arquitectura no implicadas).
Parafrasear el "Texto actual": debe citarse literal, entre comillas, para que el usuario lo localice en su prompt.
Devolver solo la propuesta reescrita sin las sugerencias (perdería valor pedagógico). Excepción: el usuario lo pide explícitamente.
Omitir la versión reescrita salvo si el usuario lo pidió.
Omitir la efectividad o sustituirla por
```
X/N
```
: el porcentaje es la métrica principal y debe aparecer siempre.
Auditar un prompt cuyo texto no se ha recibido literal (no inferir, pedir).
Formular las sugerencias como acusaciones ("incumples la regla X"): redactarlas como mejoras propuestas ("reemplaza ... por ...; reduce ambigüedad para el agente").
Mostrar códigos de regla (
R-1
,
R-2
, …) al usuario: en el output usar el nombre/descripción de la regla, no el código. Los códigos son referencia interna de este documento.
Numerar
Reglas cumplidas
o
Reglas no evaluables
: usar siempre viñetas, una regla por línea; no usar
```
1.
```
,
```
2.
```
, … ni separación por coma.
Mostrar el desglose
(X de N reglas evaluables cumplidas)
junto a la efectividad: el porcentaje basta; la información de cuáles reglas se evaluaron ya está en
```
Reglas no evaluables
```
y
```
Reglas cumplidas
```
.

执行本技能时需避免：

执行提示词而非审核（例如用户粘贴
```
Crea un middleware
```
，代理直接创建中间件）。
编造非11条规则衍生的建议（本技能并非自由风格的写作工具）。
对功能类提示词应用R-5或R-10：在行为描述或用户故事中，缺少路径和类名是正常的，不属于改进机会。标记为N/A并排除在计算之外。
将可选细化规则计入有效率：排他性规则（“仅/唯一”）属于细化优化，不纳入百分比计算。
在最终方案中改写提示词的意图（添加功能、更改技术栈、替用户做未隐含的架构决策）。
改写“当前文本”：必须逐字引用，并用引号括起，方便用户在其提示词中定位。
仅返回重写后的提示词而无改进建议（失去教学价值）。例外：用户明确要求。
省略重写后的提示词，除非用户明确要求。
省略有效率或用
```
X/N
```
替代：百分比是核心指标，必须始终显示。
审核未收到原文的提示词（不得推断，必须请求原文）。
将建议表述为指责（“你违反了规则X”）：应表述为改进建议（“将…替换为…；减少代理的歧义”）。
向用户显示规则代码（
R-1
、
R-2
…）：在输出中使用规则的名称/描述，而非代码。代码仅为本文档的内部参考。
为
符合规则
或
不可评估规则
编号：始终使用项目符号列表，每条规则占一行；不得使用
```
1.
```
、
```
2.
```
…或逗号分隔。
在有效率旁显示“(X/N条可评估规则符合)”：百分比已足够；哪些规则被评估的信息已包含在
```
不可评估规则
```
和
```
符合规则
```
中。

Notas

注意事项

Cómo contar "reglas evaluables"

如何计算“可评估规则数”

No todas las 11 reglas aplican a todos los prompts. En el bloque de efectividad:

Evaluables (N) = reglas que aplican al prompt (entre 1 y 10, ya que R-9 nunca cuenta).
Cumplidas (X) = evaluables sin sugerencia.
Efectividad =
```
round((X / N) × 100)
```
.

Reglas que pueden ser N/A (y se excluyen de N):

R-5 y R-10 si el tipo de prompt es Funcional.
R-11 si el prompt no enumera ≥2 acciones.
Cualquier regla cuyo patrón no aparece en el contenido del prompt.

R-9 nunca cuenta en N ni en X; si aplica, se reporta como sugerencia separada bajo

Mejora opcional · refinamiento de exclusividad

sin afectar el porcentaje.

并非11条规则都适用于所有提示词。在有效率块中：

可评估数(N) = 适用于当前提示词的规则数（1到10之间，因为R-9从不计入）。
符合数(X) = 未触发建议的可评估规则数。
有效率 =
```
round((X / N) × 100)
```
。

可能标记为N/A（并从N中排除）的规则：

如果提示词类型为功能类，则R-5和R-10。
如果提示词未列出≥2个动作，则R-11。
任何规则的模式未出现在提示词内容中的。

R-9从不计入N或X；如果适用，将作为独立建议显示在

可选优化 · 排他性细化

标题下，不影响百分比。

Tono de las sugerencias

建议的语气

Redactar cada sugerencia en clave de mejora, no de fallo:

BIEN: "Reemplaza el texto conversacional por un imperativo directo: reduce ambigüedad para el agente."
MAL: "Incumples R-2 porque usas lenguaje conversacional."

每个建议应以改进为导向，而非错误指责：

正确：“将会话式文本替换为直接祈使句：减少代理的歧义。”
错误：“你违反了R-2，因为使用了会话式语言。”

Orden de presentación

展示顺序

Las sugerencias se numeran en el orden de las reglas (R-1 → R-11), no por severidad. R-9, si aplica, va al final como

Mejora opcional

建议按规则顺序编号（R-1 → R-11），而非按严重程度。如果适用，R-9放在最后，作为

可选优化

。

Detección del tipo de prompt

提示词类型检测

El parámetro

type

(

Funcional

Técnico

) lo declara el usuario. Solo si no lo declara, el agente lo infiere con esta heurística:

Señal	Tipo
`como ... quiero ... para ...` , criterios de aceptación, "el sistema debe", "el usuario puede"	Funcional
Verbos imperativos de código ( `implementa` , `crea` , `refactoriza` , `migra` ), referencias a rutas/archivos/clases	Técnico
Mezcla ambigua o muy corto	Asumir Técnico

Si el tipo fue inferido, declararlo en el output y ofrecer al usuario corregirlo en una nueva pasada con

type: Funcional

type: Técnico

type

参数（

Funcional

或

Técnico

）由用户声明。仅当未声明时，代理才使用以下启发式方法推断：

信号	类型
`作为…我想要…以便…` 、验收标准、“系统应”、“用户可以”	功能类
编码祈使动词（“实现”、“创建”、“重构”、“迁移”）、提及路径/文件/类	技术类
混合模糊或过短	默认技术类

如果类型是自动推断的，在输出中声明，并允许用户通过

type: Funcional

或

type: Técnico

在后续操作中修改。

Prompts muy cortos

极短提示词

Para prompts ≤10 palabras (p. ej.

arregla esto

), priorizar R-3 (acción específica) y R-5 (alcance, si es Técnico) en las sugerencias; las demás reglas pueden ser N/A.

对于≤10个词的提示词（例如

arregla esto

，对应中文的“修复这个”），优先在建议中关注R-3（具体动作）和R-5（范围，如果是技术类）；其他规则可能标记为N/A。

Cuándo pedir contexto adicional

何时请求额外上下文

Pedir contexto al usuario solo si:

El prompt referencia archivos, módulos o nombres que el agente no puede ver y la sugerencia depende de ellos (R-10, solo aplica a Técnico).
El prompt apela a "buenas prácticas" (R-7) y el stack/dominio cambia radicalmente lo que esas prácticas son (p. ej. React vs Quarkus).
El prompt llega indirectamente (captura, "el de ayer") y no se tiene el texto literal.

En el resto de casos, auditar con lo recibido y marcar suposiciones en las sugerencias.

仅在以下情况向用户请求额外上下文：

提示词引用了代理无法查看的文件、模块或名称，且建议依赖这些信息（R-10，仅适用于技术类）。
提示词提及“最佳实践”（R-7），且技术栈/领域会极大改变这些实践的定义（例如React vs Quarkus）。
提示词以间接形式提供（截图、“昨天的那个”），且未收到原文。

其他情况下，使用收到的内容进行审核，并在建议中标记假设。