{
  "skill_name": "mcp-coldfusion-developer",
  "eval_focus": [
    "audit-lint-default-no-fix",
    "explicit-remediation-fix-true-only",
    "post-fix-validation-and-handoff",
    "local-first-routing-and-templates",
    "platform-vs-legacy-boundary",
    "scenario-based-synergy-handoffs"
  ],
  "evals": [
    {
      "id": 1,
      "prompt": "Analizza `handlers/order.cfc` e `views/order/edit.cfm`: esegui lint e riporta solo i problemi trovati.",
      "expected_output": "Audit lint in sola lettura, con elenco issue e nessuna modifica automatica ai file.",
      "expectations": [
        "Esegue lint_code su file CFML in modalita audit",
        "Non usa fix: true in assenza di richiesta esplicita",
        "Restituisce severita, posizione e sintesi dei problemi"
      ]
    },
    {
      "id": 2,
      "prompt": "Procedi con remediation del lint su `views/order/edit.cfm`; e' autorizzato fix automatico solo dove sicuro.",
      "expected_output": "Remediation con fix: true dichiarato esplicitamente e report delle correzioni applicate.",
      "expectations": [
        "Attiva fix: true solo perche la richiesta lo esplicita",
        "Documenta quali fix sono stati applicati e quali no",
        "Mantiene fallback manuale per warning non autofixabili"
      ]
    },
    {
      "id": 3,
      "prompt": "Dopo la fix, valida il flusso UI di checkout e consegna handoff finale con note browser e aggiornamento docs operative.",
      "expected_output": "Post-fix validation completa con check browser, verifica regressioni e handoff verso documentazione aggiornata.",
      "expectations": [
        "Esegue validazione post-fix sul percorso utente rilevante",
        "Produce handoff esplicito a mcp-browser-automation per verifica UI",
        "Allinea o propone aggiornamento docs tramite mcp-docs-navigator"
      ]
    },
    {
      "id": 4,
      "prompt": "Devo creare una nuova pagina Platform partendo dai template locali della skill. Guidami nella raccolta dei prerequisiti minimi e indica quali template usare senza dare per scontato docs-node.",
      "expected_output": "Routing verso i reference e template locali corretti, raccolta dei prerequisiti minimi e distinzione netta tra pagina .cfm contenitore e logica nel manager .cfc.",
      "expectations": [
        "Carica o richiama reference locali per bootstrap pagina e migrazione senza dipendere da docs-node",
        "Indica l'uso dei template locali shared, mvc3 o mvc4 in base allo scenario",
        "Raccoglie prerequisiti minimi come path pagina, path manager, tipo pagina, versione manager ed eventuale product tree",
        "Non usa fix: true perche il task e di bootstrap e analisi"
      ]
    },
    {
      "id": 5,
      "prompt": "Questa pagina legacy e in mvc3 con griglia. Dimmi se va trattata come MVC3, MVC3_XGRID o MVC4 e guidami nella migrazione a mvc4 evidenziando i controlli obbligatori.",
      "expected_output": "Classificazione della variante corretta, checklist sintetica di migrazione mvc3 -> mvc4 e warning su xgrid, chiavi e metodi obsoleti.",
      "expectations": [
        "Carica o richiama reference locale su page bootstrap o migrazione e reference locale xgrid",
        "Classifica esplicitamente il caso come MVC3, MVC3_XGRID o MVC4 prima di proporre modifiche",
        "Richiama controlli su pk_ids, row_id e metodi da rinominare o rimuovere",
        "Mantiene il boundary Platform standard senza mescolare pattern legacy cliente deploy"
      ]
    },
    {
      "id": 6,
      "prompt": "Ho una correzione su componente documentale: devo farla in core, in client/core oppure come client patch? Spiegami la scelta corretta e il workflow da seguire.",
      "expected_output": "Decisione motivata tra core, client/core e client patch con richiamo ai boundary, alla catena factory e al workflow patch corretto.",
      "expectations": [
        "Richiama reference locale su client boundaries e patch, piu il reference stabile core-client-override-pattern quando utile",
        "Distingue chiaramente sviluppo standard Platform, override client/core e patch cliente",
        "Per client patch richiama il vincolo dei due commit separati e il no squash",
        "Evita di trattare JS o CSS come semplice patch manuale se il reference lo esclude"
      ]
    },
    {
      "id": 7,
      "prompt": "Dobbiamo introdurre un nuovo parametro cliente e capire se va in codice, file .cfg, cfg JSON, cfgset o GUI; inoltre potrebbe servire aggiornare clientfactory. Guidami senza fare assunzioni esterne.",
      "expected_output": "Classificazione corretta del tipo di configurazione e richiamo al percorso locale per factory, cfg e perimetro product tree.",
      "expectations": [
        "Richiama reference locale su factory, config e product tree",
        "Classifica esplicitamente il cambiamento come codice, .cfg, .json, cfgset o GUI",
        "Indica quando verificare clientfactory o bootstrap equivalente",
        "Resta local-first e usa docs-node solo come supporto opzionale di verifica"
      ]
    },
    {
      "id": 8,
      "prompt": "Abbiamo uno scan security con possibili XSS e XSRF su un cliente deploy legacy, ma docs-node non e disponibile. Voglio una strategia di remediation e il corretto handoff se il caso diventa multi-sorgente.",
      "expected_output": "Piano di remediation security basato su reference locali, distinzione tra Platform e cliente deploy legacy, e handoff a skill analitiche quando il caso richiede piu fonti.",
      "expectations": [
        "Richiama reference locale su security remediation e legacy routing senza dipendere da docs-node",
        "Distingue remediation di codice applicativo da remediation di app server o web server",
        "Tratta il cliente deploy legacy come boundary separato rispetto allo standard Platform",
        "Produce handoff esplicito a mcp-technical-analyst quando servono ticket, commit, docs e altre evidenze insieme"
      ]
    }
  ]
}