{
    "schema": "forja/skill@1",
    "name": "escribir-pruebas-para-un-cambio",
    "title": "Escribir pruebas para un cambio",
    "description": "Genera las pruebas que faltan para cubrir el camino que se modificó.",
    "version": "1.0.0",
    "author": "Equipo editorial",
    "category": "Desarrollo de software",
    "tags": [
        "pruebas",
        "calidad",
        "automatización"
    ],
    "compatibility": [
        "OpenClaw",
        "Claude",
        "ChatGPT"
    ],
    "updated_at": "2026-09-22T00:20:40-05:00",
    "source": "https://socket-studio.com/demo-aplicaciones/ai-skills/skills/escribir-pruebas-para-un-cambio",
    "objective": "Cubrir con pruebas el comportamiento que un cambio introduce o modifica,\nincluyendo los casos límite que nadie escribe a mano.",
    "instructions": "Escribes pruebas que fallarían si el cambio se revirtiera. Una prueba que pasa\ncon y sin el cambio no prueba nada.",
    "workflow": [
        "Identifica el comportamiento nuevo o modificado.",
        "Escribe el caso feliz.",
        "Escribe los límites: vacío, cero, negativo, máximo, nulo.",
        "Escribe el caso de error esperado.",
        "Usa el mismo marco y las mismas convenciones que el resto del proyecto."
    ],
    "rules": [
        "Una aserción por concepto: no mezcles tres comprobaciones en una prueba.",
        "Nombra la prueba por el comportamiento, no por el método.",
        "No uses datos aleatorios sin semilla fija.",
        "No pruebes la implementación interna, prueba el resultado observable."
    ],
    "inputs": [
        "codigo: función o módulo modificado",
        "marco: framework de pruebas del proyecto"
    ],
    "outputs": [
        "pruebas: código listo para pegar",
        "cobertura: qué casos quedan sin cubrir y por qué"
    ],
    "examples": [
        "Para una función que divide, las pruebas incluyen división exacta, con resto,\npor cero y con operandos negativos."
    ],
    "prompt": "## Objetivo\n\nCubrir con pruebas el comportamiento que un cambio introduce o modifica,\nincluyendo los casos límite que nadie escribe a mano.\n\n## Instrucciones\n\nEscribes pruebas que fallarían si el cambio se revirtiera. Una prueba que pasa\ncon y sin el cambio no prueba nada.\n\n## Workflow\n\n1. Identifica el comportamiento nuevo o modificado.\n2. Escribe el caso feliz.\n3. Escribe los límites: vacío, cero, negativo, máximo, nulo.\n4. Escribe el caso de error esperado.\n5. Usa el mismo marco y las mismas convenciones que el resto del proyecto.\n\n## Reglas\n\n- Una aserción por concepto: no mezcles tres comprobaciones en una prueba.\n- Nombra la prueba por el comportamiento, no por el método.\n- No uses datos aleatorios sin semilla fija.\n- No pruebes la implementación interna, prueba el resultado observable.\n\n## Inputs\n\n- codigo: función o módulo modificado\n- marco: framework de pruebas del proyecto\n\n## Outputs\n\n- pruebas: código listo para pegar\n- cobertura: qué casos quedan sin cubrir y por qué\n\n## Ejemplos\n\nPara una función que divide, las pruebas incluyen división exacta, con resto,\npor cero y con operandos negativos."
}