moyu-ko

Descripción general de la skill moyu-ko

Para qué sirve moyu-ko

moyu-ko es una skill de edición de código creada para frenar la sobreingeniería antes de que empiece. Ayuda a que una IA haga el cambio correcto más pequeño posible, se mantenga dentro del alcance pedido por el usuario y evite añadir abstracciones, pruebas, documentación o dependencias extra salvo que se hayan solicitado.

Quién debería instalarla

Instala la moyu-ko skill si a menudo quieres que una IA aplique parches sobre código existente, corrija un bug puntual o haga un cambio mínimo sin reescrituras. Encaja especialmente bien en equipos que valoran diffs precisos, velocidad de revisión y bajo nivel de churn en la implementación.

Qué la diferencia

A diferencia de un prompt genérico que dice “sé conciso”, moyu-ko incorpora guardarraíles explícitos: edita solo los archivos solicitados, prioriza la implementación más simple y detente a preguntar cuando la petición no esté clara. Eso la hace especialmente útil para moyu-ko for Code Editing cuando controlar el alcance importa más que hacer refactors amplios.

Cómo usar la skill moyu-ko

Instálala y actívala

Usa el flujo de instalación estándar del directorio para el paso de moyu-ko install y luego invoca la skill sobre una tarea que esté claramente planteada como edición de código. Un buen disparador sería un prompt como: “Use moyu-ko to make only the minimal change needed to fix this bug in src/auth.ts.”

Dale a la skill una tarea acotada

El patrón de moyu-ko usage funciona mejor cuando especificas:

• el archivo o archivos exactos que hay que tocar
• el cambio de comportamiento deseado
• qué no debe cambiar
• cualquier restricción conocida, como “no new dependencies” o “do not add tests”

Entrada más sólida:

Update src/cart.ts so the discount only applies to logged-in users. Do not change other pricing logic or create new files.

Entrada más débil:

Improve the checkout flow.

Lee primero los archivos correctos

Para un flujo de trabajo de moyu-ko guide más rápido, empieza por SKILL.md y después inspecciona los archivos que definen la superficie del cambio en tu repo. Como este repositorio de skill es intencionalmente pequeño, el valor principal está en entender las reglas de comportamiento, no en buscar carpetas de soporte adicionales.

Pide diffs mínimos

Cuando quieras que la skill responda bien, pide explícitamente el cambio más pequeño posible y menciona cualquier límite duro. Por ejemplo:

Use moyu-ko to patch api.ts. Change only the validation branch, avoid new helpers, and ask before touching any other file.

Preguntas frecuentes sobre la skill moyu-ko

¿moyu-ko es solo para edición de código?

Sí, ese es su uso previsto. La moyu-ko skill está pensada para edición disciplinada, no para planificación amplia, trabajo de arquitectura ni andamiaje inicial de greenfield. Si necesitas un rediseño, quizá te convenga más un prompt normal.

¿Cuándo no debería usar moyu-ko?

No uses moyu-ko cuando en realidad quieras que la IA explore varias alternativas, añada pruebas de apoyo o limpie código adyacente como parte de la tarea. Su valor está en controlar el alcance, así que puede ser una mala opción para refactors abiertos.

¿Es apta para principiantes?

Sí, siempre que puedas describir el cambio con claridad. Las reglas de la skill son simples, pero funciona mejor cuando la petición ya viene acotada. Quienes empiezan obtienen mejores resultados si nombran el archivo, el comportamiento y la lista de “no tocar”.

¿En qué se diferencia de un prompt normal?

Un prompt normal puede pedir cambios mínimos, pero moyu-ko convierte eso en el modo de trabajo por defecto. Así reduce la probabilidad de reescrituras accidentales, abstracciones añadidas o archivos extra cuando solo querías una edición concreta.

Cómo mejorar la skill moyu-ko

Da instrucciones de alcance más precisas

La mayor mejora de calidad llega cuando estrechas la superficie de edición. Indica el archivo exacto, la sección más pequeña que debe cambiar y el resultado que esperas. Cuanto más precisa sea la petición, menos probable será que moyu-ko se quede atascada pidiendo aclaraciones o edite de más.

Incluye límites explícitos

Si algo debe permanecer intacto, dilo. Límites útiles:

• “no new helper functions”
• “no new dependencies”
• “do not change public APIs”
• “keep the diff under 10 lines if possible”

Estas restricciones ayudan a que moyu-ko for Code Editing produzca un resultado fácil de revisar.

Espera preguntas cuando la tarea sea ambigua

Un fallo común es no especificar lo suficiente el objetivo y esperar que el modelo deduzca el resto. Si la petición puede afectar a otros archivos o requiere una nueva abstracción, moyu-ko debería detenerse y preguntar. Eso es una ventaja, no un error.

Itera sobre el primer parche, no sobre todo el plan

Si la primera salida queda demasiado amplia, ajusta la siguiente instrucción en vez de ampliar la tarea. Por ejemplo, pide “only the line that parses the input” en lugar de “clean up the module”. Así mantienes moyu-ko usage alineado con su diseño de cambio mínimo.