AgentePotente c40ddf4b59 Initial commit: framework-translator skill (LLM-native approach)

- SKILL.md: Istruzioni complete per LLM (Fasi 1-5)
- references/mapping_patterns.md: 13 pattern di trasformazione
- references/skill_template.md: Template standardizzato SKILL.md
- scripts/: 3 script meccanici bash (scan, structure, packaging)
- PIANO_SVILUPPO.md: Piano di sviluppo originale (documentazione)

Approccio: LLM-native con script minimali per operazioni meccaniche.
Token usage stimato: ~35-65K per framework.
Vantaggi: comprensione semantica, adattabilità, manutenzione semplice.

2026-03-07 10:14:37 +01:00

25 KiB

Raw Blame History

Framework → AgentSkills Translator

Piano di Sviluppo per Skill Generalizzata di Trasformazione

Versione: 1.0 | Data: 2026-03-07 | Autore: AgentePotente

🎯 Obiettivo

Creare una skill framework-translator che trasformi framework testuali eterogenei (come orto_v1) in un set di skills AgentSkills-compatibili, strutturate e pronte per la distribuzione.

Problema: I framework sono spesso documenti complessi, multi-cartella, con strutture arbitrarie (agenti, workflow, knowledge, script, prompt). Trasformarli manualmente in AgentSkills richiede lavoro ripetitivo e conoscenza del formato target.

Soluzione: Una skill che:

Analizza la struttura del framework input
Identifica entità trasformabili (agenti, workflow, knowledge)
Applica pattern di mappatura predefiniti
Genera skills AgentSkills-compatibili con struttura standardizzata
Produce references centralizzate e documentazione

📊 Analisi del Caso di Studio: orto_v1 → orto-skills

Input: orto_v1 Framework

orto_v1/
├── README.md                          # Panoramica framework
├── orti_registry.json                 # Registry centrale
├── docs/
│   ├── 00_indice.md                   # Index documentazione
│   ├── 01_visione_e_requisiti.md      # Visione prodotto
│   ├── 02_scope_e_assunzioni.md       # Scope e assunzioni
│   ├── 03_architettura_multiagente.md # Architettura agenti (12)
│   ├── 04_contratti_e_messaggistica.md
│   ├── 05_sicurezza_privacy_affidabilita.md
│   ├── architettura_storage.md        # Storage markdown
│   ├── agents/                        # 12 agenti specializzati
│   │   ├── 00_agent_index.md
│   │   ├── 01_orchestratore_planner.md
│   │   ├── 02_agronomo_colture.md
│   │   ├── 03_stagionalita_calendario.md
│   │   ├── 04_fitopatologo_trattamenti.md
│   │   ├── 05_irrigazione_automazione.md
│   │   ├── 06_layout_zoning.md
│   │   ├── 07_nutrizione_consumi.md
│   │   ├── 08_data_knowledge_manager.md
│   │   ├── 09_ui_ux_agent.md
│   │   ├── 10_qa_safety_agent.md
│   │   ├── 11_weather_intelligence_agent.md
│   │   └── 12_ops_integrazioni_agent.md
│   ├── workflows/                     # 5 workflow end-to-end
│   │   ├── 00_workflow_index.md
│   │   ├── 00_init_orto.md
│   │   ├── 01_onboarding.md
│   │   ├── 02_piano_stagionale.md
│   │   ├── 03_esecuzione_settimanale.md
│   │   ├── 04_diagnosi_problemi.md
│   │   └── 05_irrigazione_dinamica_meteo.md
│   ├── data/                          # Data model
│   ├── schemas/                       # JSON schemas
│   ├── gui/                           # GUI specification
│   ├── skills/                        # Skills catalog (17 skills)
│   │   ├── 00_skills_overview.md
│   │   └── 01_skill_catalog.md
│   ├── knowledge/                     # Knowledge base
│   └── allegati/                      # Templates + examples
├── prompts/
│   ├── master_prompt_openclaw.md
│   ├── prompt_onboarding.md
│   ├── prompt_init_orto.md
│   └── prompt_demo_sessione_tipo.md
└── scripts/
    ├── README_SCRIPTS.md
    ├── init_new_orto.py
    ├── init_orto.sh
    ├── json_to_md_converter.py
    ├── sync_md_from_agents.py
    ├── register_orto.py
    ├── template_garden_config.md
    └── template_questionnaire_responses.md

Output: orto-skills Suite

orto-suite/
├── 9 skills AgentSkills:
│   ├── orto-init/                     # Da: Workflow 00 + init_new_orto.py
│   ├── orto-onboarding/               # Da: Workflow 01 + prompt_onboarding.md
│   ├── orto-agronomo/                 # Da: Agente 02 + skill AGR-CROP-MIX
│   ├── orto-calendario/               # Da: Agente 03 + skill AGR-SEASONALITY
│   ├── orto-fitopatologo/             # Da: Agente 04 + skill PHYTO-DIAG + PHYTO-TREAT-BIO
│   ├── orto-layout/                   # Da: Agente 06 + skill AGR-COMPANION
│   ├── orto-irrigazione/              # Da: Agente 05 + skill IRR-ZONING + IRR-SCHEDULING
│   ├── orto-meteo-decisioni/          # Da: Agente 11 + skill MET-IRR-DECISION
│   └── orto-orchestratore/            # Da: Agente 01 + QA-CONSISTENCY + merge workflow
│
├── references/ (8 file, 88 KB)
│   ├── colture_it.md                  # Da: docs/knowledge/ + colture catalog
│   ├── calendario_it.md               # Da: docs/workflows/ + stagionalità
│   ├── malattie_trattamenti.md        # Da: docs/agents/04 + knowledge fitopatologia
│   ├── irrigazione_parametri.md       # Da: docs/agents/05 + knowledge irrigazione
│   ├── consociazioni_layout.md        # Da: docs/agents/06 + knowledge consociazioni
│   ├── meteo_soglie.md                # Da: docs/agents/11 + knowledge meteo
│   ├── conflitti_risoluzione.md       # Da: docs/03_architettura_multiagente.md (sez. conflitti)
│   └── qa_checklist.md                # Da: Agente 10 QA & Safety
│
└── Symlink: ogni skill → ../references (condivisi)

🔍 Pattern di Trasformazione Distillati

1. Agente → Skill (Non 1:1)

Pattern	Esempio	Note
1 Agente → 1 Skill	Agente 02 (Agronomo) → orto-agronomo	Caso ideale, quando agente è auto-contenuto
1 Agente → 1 Skill + References	Agente 05 (Irrigazione) → orto-irrigazione + irrigazione_parametri.md	Knowledge pesante estratta in references
2+ Agenti → 1 Skill	Agente 04 (Fitopatologo) + skill PHYTO-DIAG + PHYTO-TREAT-BIO → orto-fitopatologo	Agenti correlati mergiati per coerenza
Agente + Workflow → Skill	Agente 01 (Orchestratore) + Workflow 02/03/04 → orto-orchestratore	Orchestratore coordina workflow multipli
Workflow → Skill	Workflow 00 (Init) + init_new_orto.py → orto-init	Workflow con script diventa skill operativa
Agente Eliminato	Agente 08 (Data Manager), 09 (UI/UX), 12 (Ops)	Non essenziali per MVP, funzionalità assorbite

Regola: Non mappare 1:1. Raggruppa per coerenza funzionale e minimizza skills mantenendo separazione of concerns.

2. Knowledge → References Centralizzate

Input Pattern	Output Pattern
`docs/knowledge/*.md`	`references/*.md` (1:1 o mergiato)
`docs/agents/*/` (sezioni knowledge)	Estratte → `references/*.md`
`docs/skills/01_skill_catalog.md`	Mappato → references da creare
Tabelle, liste, parametri	Mantenuti in markdown strutturato

Regola: Tutto il knowledge pesante (>500 linee) o condiviso (usato da 2+ skills) → references/. Skills leggono references on-demand.

3. Workflow → Fasi nel Corpo SKILL.md

Input	Output
`docs/workflows/01_onboarding.md`	orto-onboarding: Fase 1-5 (blocchi questionario)
`docs/workflows/02_piano_stagionale.md`	orto-agronomo: Fase 1-4 (filtra, candidate, costruisci piano)
`docs/workflows/03_esecuzione_settimanale.md`	orto-calendario: Fase 1-3 (genera task, meteo-check, output)

Regola: Ogni workflow diventa una sequenza di fasi nel corpo della skill. Mantenere nomi fasi descrittivi (Fase 1: Filtra Colture per Vincoli).

4. Scripts → scripts/ nella Skill (Opzionale)

Input	Output	Decisione
`init_new_orto.py` (20 KB)	Integrato in orto-init (logica inline)	Script semplice → inline nel corpo
`json_to_md_converter.py`	Non incluso	Utility una-tantum, non needed runtime
`sync_md_from_agents.py`	Non incluso	QA tool, non needed runtime

Regola: Includere scripts/ solo se:

Script è riutilizzabile (eseguito multiple volte)
Script è deterministico (no modifiche ambientali)
Script è più efficiente che riscriverlo ogni volta

5. Storage Architecture → Documentato in SKILL.md

Input	Output
`docs/architettura_storage.md`	Sezione "Gestione Progetti & Registry" in orto-orchestratore + orto-init
Struttura directory orto/	Documentata in SKILL.md con tree markdown
Registry JSON	Specificato formato + percorso in SKILL.md

Regola: La skill deve sapere dove leggere/scrivere. Documentare struttura directory e convenzioni naming nel corpo SKILL.md.

6. Prompts → Integrati o Eliminati

Input	Output
`prompts/master_prompt_openclaw.md`	Non incluso (era prompt di generazione, non runtime)
`prompts/prompt_onboarding.md`	Integrato in orto-onboarding (Fase 1: Raccolta Dati)
`prompts/prompt_init_orto.md`	Integrato in orto-init (Input section)

Regola: Prompt che sono template di input → integrati come sezioni Input nella skill. Prompt di generazione framework → eliminati (non servono runtime).

🏗️ Architettura della Skill `framework-translator`

Struttura Proposta

framework-translator/
├── SKILL.md                           # Istruzioni traduzione
├── scripts/
│   ├── analyze_framework.py           # Analizza struttura input
│   ├── map_entities.py                # Mappa agenti/workflow → skills
│   ├── extract_knowledge.py           # Estrae knowledge → references
│   ├── generate_skill.py              # Genera SKILL.md da template
│   └── validate_output.py             # Valida skills generate
├── references/
│   ├── mapping_patterns.md            # Pattern di mappatura (tabella sopra)
│   ├── skill_template.md              # Template SKILL.md standardizzato
│   ├── agent_analysis_checklist.md    # Checklist analisi agenti
│   └── quality_criteria.md            # Criteri QA per skills generate
└── assets/
    └── example_outputs/               # Esempi: orto_v1 → orto-skills

Frontmatter (Bozza)

name: framework-translator
description: Trasformare framework testuali eterogenei (multi-cartella, multi-agente, workflow) in set di skills AgentSkills-compatibili. Usare quando: (1) convertire framework esistente in skills eseguibili, (2) standardizzare documentazione multi-agente in formato AgentSkills, (3) estrarre knowledge da framework e centralizzare in references, (4) generare pipeline di skills coordinate da orchestratore. Output: Cartella <framework>-skills/ con N skills AgentSkills-compatibili, references centralizzate, script INSTALL.sh, documentazione installazione.

📋 Processo di Traduzione (Workflow della Skill)

Fase 1: Analisi Framework Input

Obiettivo: Capire struttura, entità, dipendenze del framework input.

Input: Percorso framework (es. /path/to/framework/)

Azioni:

Scansiona struttura directory

find <framework_path> -type f -name "*.md" | head -50

Identifica cartelle chiave
- agents/ o agenti/ → Agenti da trasformare
- workflows/ o flussi/ → Workflow da mappare
- knowledge/ o docs/ → Knowledge da estrarre
- scripts/ → Script da valutare
- prompts/ → Prompt da integrare
Leggi file index/overview
- agents/00_agent_index.md o simile
- workflows/00_workflow_index.md o simile
- README.md del framework
Estrai metadata agenti Per ogni file agente:
- Nome agente
- Missione/responsabilità
- Input/output (se specificati)
- Skills richieste (se specificate)
- Regole decisionali
Estrai metadata workflow Per ogni workflow:
- Nome workflow
- Trigger/condizioni
- Fasi/step
- Agenti coinvolti

Output: analysis_report.md con:

Lista agenti (N totale, nomi, responsabilità)
Lista workflow (N totale, nomi, agenti coinvolti)
Knowledge base identificata (file, dimensioni, argomenti)
Scripts valutati (includere? sì/no + motivo)

Fase 2: Mappatura Entità → Skills

Obiettivo: Decidere come trasformare agenti + workflow in skills.

Input: analysis_report.md

Azioni:

Applica pattern di mappatura (da references/mapping_patterns.md)
- 1 Agente → 1 Skill (se auto-contenuto)
- 2+ Agenti → 1 Skill (se correlati funzionalmente)
- Workflow → Skill (se operativo, con script)
- Agente + Workflow → Skill (se orchestrazione)

Raggruppa per coerenza funzionale

Esempio:
- Agronomo Colture + Nutrizione & Consumi → orto-agronomo (se overlap forte)
- Fitopatologo + Trattamenti → orto-fitopatologo (già uniti)
- Irrigazione + Automazione → orto-irrigazione (mantieni unito)

Identifica orchestratore
- Quale skill coordina le altre?
- Di solito: Agente 01 (Planner/Orchestratore) + QA
Identifica references necessarie
- Quali knowledge sono condivisi da 2+ skills?
- Quali sono troppo pesanti per il corpo SKILL.md?

Output: mapping_plan.md con:

Skills da generare (N totale, nomi, agenti/workflow di origine)
References da creare (N totale, nomi, contenuti)
Giustificazione decisioni di mappatura

Fase 3: Estrazione Knowledge → References

Obiettivo: Centralizzare knowledge in file references condivisi.

Input: mapping_plan.md + framework source files

Azioni:

Per ogni reference pianificata:
- Identifica file sorgente nel framework
- Estrai contenuto rilevante (tabelle, liste, parametri)
- Riformatta in markdown strutturato (TOC, sezioni, tabelle)
- Normalizza naming (lowercase, underscore)
Applica criterio di inclusion
- Includere: Dati fattuali, parametri, tabelle, regole
- Escludere: Narrative, introduzioni lunghe, esempi ridondanti
Crea symlink plan
- Quali skills useranno quale reference?
- Documenta nel file reference (header: "Usato da: skill-X, skill-Y")

Output: Cartella references/ con N file .md

Fase 4: Generazione Skills

Obiettivo: Creare N skills AgentSkills-compatibili.

Input: mapping_plan.md + references/ + framework source

Azioni:

Per ogni skill pianificata:

a. Genera frontmatter YAML
```
name: <skill-name>
description: <descrizione concisa con trigger e output>
```
b. Genera corpo SKILL.md (usa template da references/skill_template.md)
- Quando Usare: 3-5 scenari trigger
- Input: Tabella input richiesti (nome, tipo, obbligatorio, esempio)
- Processo:
  - Fase 1: (da workflow o agente)
  - Fase 2:
  - ...
- Output: File/documento generato, formato, struttura
- Gestione Progetti: (se applicabile) Struttura directory, registry
- References: Elenco references usate con link
c. Integra script (se deciso in Fase 2)
- Copia script in scripts/ della skill
- Documenta uso nel corpo SKILL.md
d. Valida struttura
- Frontmatter presente e valido?
- Corpo <500 linee (o references usate)?
- References linkati esistono?

Crea struttura skill

<skill-name>/
├── SKILL.md
├── scripts/ (opzionale)
└── README.md (opzionale, solo se utile per umani)

Output: Cartella <framework>-skills/ con N sottocartelle skill

Fase 5: Packaging e Documentazione

Obiettivo: Rendere le skills pronte per distribuzione.

Input: Cartella <framework>-skills/

Azioni:

Crea references centralizzate
- Sposta references/ in root di <framework>-skills/
- Crea symlink in ogni skill → ../references

Genera INSTALL.sh

#!/bin/bash
# Script installazione framework-skills
SOURCE="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"
TARGET="$HOME/.openclaw/skills/<framework>-skills"

echo "Installing <framework>-skills..."
cp -r "$SOURCE/<framework>-suite" "$TARGET"
echo "Installation complete!"

Genera README.md root
- Panoramica framework
- Lista skills (N totale, nomi, descrizioni brevi)
- Istruzioni installazione (3 metodi: script, manuale, chat-only)
- Struttura directory
Validazione finale
- Tutte le skills hanno SKILL.md valido?
- Tutti i references linkati esistono?
- INSTALL.sh funziona?
- README.md chiaro?

Output: Pacchetto pronto per distribuzione

✅ Criteri di Qualità (QA Checklist)

Per Ogni Skill Generata

Frontmatter YAML valido (name + description presenti)
Descrizione trigger-specifica (include "Usare quando:" con 3+ scenari)
Corpo <500 linee (o references usate appropriatamente)
Fasi numerate e nominate (Fase 1: , Fase 2: , ...)
Output documentato (file, formato, struttura)
References linkati (se usati, percorsi corretti)
Niente JSON per dati (solo markdown, tranne registry)
Niente sezioni ridondanti (no "When to Use" nel corpo se già in description)

Per Ogni Reference

TOC in header (se >100 linee)
Contenuto strutturato (tabelle, liste, sezioni)
Niente narrative (solo dati fattuali, parametri, regole)
Header con metadata (Usato da: skill-X, skill-Y)
Nome lowercase underscore (es. colture_it.md)

Per Pacchetto Complessivo

Struttura ultra-semplice (una cartella da copiare)
Symlink funzionanti (tutti risolti)
INSTALL.sh testato (esecuzione verificata)
README.md chiaro (installazione in 3 metodi)
Niente file ridondanti (no build/, no guide duplicate)
Git-initialized (ogni skill ha .git/ se richiesto)

🧪 Piano di Test

Test 1: Framework Semplice (1-2 agenti)

Input: Framework minimale con 2 agenti + 1 workflow

Obiettivo: Verificare mappatura base 1:1

Criteri successo:

2 skills generate
1 reference (se knowledge condiviso)
INSTALL.sh funziona

Test 2: Framework Medio (5-7 agenti)

Input: Framework con 5-7 agenti + 3 workflow + knowledge

Obiettivo: Verificare raggruppamento agenti correlati

Criteri successo:

4-5 skills generate (alcuni merge)
3-4 references centralizzate
Orchestratore identificato correttamente

Test 3: Framework Complesso (10+ agenti)

Input: orto_v1 o simile (12 agenti, 5 workflow, knowledge estesa)

Obiettivo: Verificare scala completa

Criteri successo:

8-10 skills generate (merge ottimizzati)
6-10 references
Conflitti gestiti (documentati in reference conflitti)
Pacchetto pronto per produzione

📅 Roadmap di Sviluppo

Sprint 1: Core Infrastructure (2-3 sessioni)

Creare struttura skill framework-translator
Scrivere references/mapping_patterns.md (pattern distillati sopra)
Scrivere references/skill_template.md (template standardizzato)
Implementare scripts/analyze_framework.py
Testare su framework semplice (mock o reale)

Sprint 2: Estrazione e Mappatura (3-4 sessioni)

Implementare scripts/map_entities.py
Implementare scripts/extract_knowledge.py
Scrivere references/agent_analysis_checklist.md
Testare su framework medio (5-7 agenti)
Raffinare pattern di mappatura basato su test

Sprint 3: Generazione Skills (4-5 sessioni)

Implementare scripts/generate_skill.py
Scrivere references/quality_criteria.md
Implementare validazione output
Testare su orto_v1 (framework complesso)
Confrontare output con orto-skills manuali (gap analysis)

Sprint 4: Packaging e Documentazione (2-3 sessioni)

Implementare scripts/validate_output.py
Automatizzare creazione symlink
Generare INSTALL.sh dinamico
Generare README.md dinamico
Documentare skill (corpo SKILL.md completo)
Test end-to-end su 2-3 framework diversi

Sprint 5: Refinement e Production (2-3 sessioni)

Raccogliere feedback da test reali
Ottimizzare pattern di mappatura
Migliorare gestione edge cases
Scrivere esempi in assets/example_outputs/
Pubblicare skill (clawhub o manuale)

🔧 Edge Cases da Gestire

1. Framework Non-Standard

Problema: Framework senza cartelle agents/ o workflows/

Soluzione:

Scansione euristica (cerca file con "agent", "workflow", "skill" nel nome)
Chiedi all'utente di identificare entità principali
Fallback: tratta ogni file .md come potenziale skill

2. Agenti con Overlap Funzionale Forte

Problema: 2+ agenti con responsabilità quasi identiche

Soluzione:

Rileva overlap (confronta descrizioni missione)
Suggerisci merge in skill unica
Documenta decisione in mapping_plan.md

3. Knowledge Molto Grande (>50 KB)

Problema: Single reference file troppo pesante

Soluzione:

Splitta per argomento (es. colture_it.md → colture_nord.md, colture_centro.md, colture_sud.md)
Usa TOC dettagliato per navigazione
Documenta in SKILL.md quando leggere quale parte

4. Workflow con Dipendenze Cicliche

Problema: Workflow A richiede output di B, B richiede output di A

Soluzione:

Rileva cicli (grafo dipendenze)
Segnala all'utente (richiede refactoring framework)
Fallback: crea skill orchestratore che gestisce iterazione

5. Script con Dipendenze Esterne

Problema: Script richiedono librerie Python non standard

Soluzione:

Documenta dipendenze in scripts/README.md
Genera requirements.txt per la skill
Valuta se includere script o convertire logica in markdown

📝 Decisioni di Progetto

1. Naming Convention

Decisione: Skill names in lowercase-kebab-case con prefix del framework

Esempio: orto-init, orto-agronomo, framework-translator

Motivo: Coerente con AgentSkills esistenti, leggibile, git-friendly

2. References: Copie o Symlink?

Decisione: Symlink centralizzati (una copia, N link)

Motivo:

Aggiornamenti automatici (modifichi reference, tutte skills vedono cambio)
Risparmio spazio (no duplicati)
Coerente con orto-skills

3. Script: Includere o Inline?

Decisione: Includere solo se riutilizzabile e deterministico

Motivo:

Script una-tantum → inline nel corpo (meno complessità)
Script riutilizzabile → scripts/ (efficienza, token savings)

4. Output: Una Cartella o N Cartelle Separate?

Decisione: Una cartella <framework>-suite/ con tutte skills + references

Motivo:

Ultra-semplice da installare (cp -r)
References centralizzati
Coerente con orto-skills

🎓 Lezioni Apprese da orto_v1 → orto-skills

Cosa Ha Funzionato Bene

Raggruppamento agenti correlati (es. Fitopatologo + Trattamenti → 1 skill)
References centralizzate (8 file, 88 KB, condivisi da 9 skills)
Symlink per references (aggiornamenti automatici, no duplicati)
Una cartella da copiare (installazione ultra-semplice)
Documentazione fasi nel corpo (Fase 1, Fase 2, ... chiaro e azionabile)

Cosa Potrebbe Migliorare

Automazione analisi iniziale (fatta manuale, potrebbe essere script)
Pattern di mappatura documentati prima (abbiamo distillato dopo)
Validazione QA automatizzata (fatta manuale, checklist non eseguita automaticamente)
Gestione conflitti (documentata in reference, ma potrebbe essere più esplicita nel processo)

Pattern da Preservare

Progressive disclosure (metadata → SKILL.md → references)
Concise is key (SKILL.md <500 linee, references per dettagli)
Human-readable output (markdown, tabelle, liste, no JSON per dati)
Audit trail (documentare decisioni in mapping_plan.md)

🚀 Prossimi Passi Immediati

Creare cartella framework-translator/ nel workspace
Scrivere SKILL.md bozza (frontmatter + processo alto livello)
Creare references/mapping_patterns.md (pattern distillati sopra)
Creare references/skill_template.md (template standardizzato)
Testare analisi su orto_v1 (run manuale di Fase 1)
Iterare basato su risultati

📌 Note Finali

Questa skill è meta: Trasforma framework in skills, che a loro volta potrebbero essere usate per trasformare altri framework.

Valore principale: Riduce tempo di trasformazione da giorni/settimane a ore, con consistenza e qualità prevedibili.

Rischio principale: Over-engineering. Mantenere skill semplice e focalizzata su pattern comuni. Edge cases gestiti con escalation all'utente.

Successo metrico: Framework trasformato in ≤4 ore, con QA score ≥0.9 (da qa_checklist.md).

Fine del documento di piano. Pronto per revisione e feedback.

25 KiB Raw Blame History

Framework → AgentSkills Translator

🎯 Obiettivo

📊 Analisi del Caso di Studio: orto_v1 → orto-skills

Input: orto_v1 Framework

Output: orto-skills Suite

🔍 Pattern di Trasformazione Distillati

1. Agente → Skill (Non 1:1)

2. Knowledge → References Centralizzate

3. Workflow → Fasi nel Corpo SKILL.md

4. Scripts → scripts/ nella Skill (Opzionale)

5. Storage Architecture → Documentato in SKILL.md

6. Prompts → Integrati o Eliminati

🏗️ Architettura della Skill framework-translator

Struttura Proposta

Frontmatter (Bozza)

📋 Processo di Traduzione (Workflow della Skill)

Fase 1: Analisi Framework Input

Fase 2: Mappatura Entità → Skills

Fase 3: Estrazione Knowledge → References

Fase 4: Generazione Skills

Fase 5: Packaging e Documentazione

✅ Criteri di Qualità (QA Checklist)

Per Ogni Skill Generata

Per Ogni Reference

Per Pacchetto Complessivo

🧪 Piano di Test

Test 1: Framework Semplice (1-2 agenti)

Test 2: Framework Medio (5-7 agenti)

Test 3: Framework Complesso (10+ agenti)

📅 Roadmap di Sviluppo

Sprint 1: Core Infrastructure (2-3 sessioni)

Sprint 2: Estrazione e Mappatura (3-4 sessioni)

Sprint 3: Generazione Skills (4-5 sessioni)

Sprint 4: Packaging e Documentazione (2-3 sessioni)

Sprint 5: Refinement e Production (2-3 sessioni)

🔧 Edge Cases da Gestire

1. Framework Non-Standard

2. Agenti con Overlap Funzionale Forte

3. Knowledge Molto Grande (>50 KB)

4. Workflow con Dipendenze Cicliche

5. Script con Dipendenze Esterne

📝 Decisioni di Progetto

1. Naming Convention

2. References: Copie o Symlink?

3. Script: Includere o Inline?

4. Output: Una Cartella o N Cartelle Separate?

🎓 Lezioni Apprese da orto_v1 → orto-skills

Cosa Ha Funzionato Bene

Cosa Potrebbe Migliorare

Pattern da Preservare

🚀 Prossimi Passi Immediati

📌 Note Finali

25 KiB

Raw Blame History

🏗️ Architettura della Skill `framework-translator`