@antoneeo/agentic-sdlc-skill 1.0.6 → 1.0.8

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
package/CHANGELOG.md CHANGED
@@ -2,6 +2,21 @@
2
2
 
3
3
  Tutte le modifiche significative a questa skill saranno documentate in questo file.
4
4
 
5
+ ## [1.0.8] - 2026-05-10
6
+ ### Aggiunto
7
+ - Skill evoluta in "Hybrid Edition": integrazione opzionale con **devPNT** (server MCP) per governance avanzata tramite database e piani gerarchici.
8
+ - Fase di Discovery per il rilevamento automatico dell'ambiente (Standalone vs Hybrid).
9
+ - Supporto per ADR (Architecture Decision Records) e Knowledge Layer (KL) nella fase di chiusura.
10
+
11
+ ### Modificato
12
+ - Riorganizzazione dei percorsi di documentazione (`ai_docs/strategic/`, `ai_docs/audit/`, `ai_docs/solutions/`).
13
+ - Aggiornata la documentazione funzionale (`architecture_overview.md`, `external_interfaces.md`) con definizioni più precise.
14
+
15
+ ## [1.0.7] - 2026-05-10
16
+ ### Modificato
17
+ - Aggiornata l'attribuzione dell'autore (Antonio Pinto) e il copyright in tutti i file (`package.json`, `README.md`, `SKILL.md`).
18
+ - Aggiunto link al profilo GitHub ufficiale.
19
+
5
20
  ## [1.0.6] - 2026-05-10
6
21
  ### Aggiunto
7
22
  - Sincronizzazione completa dei file del progetto nel repository.
package/README.md CHANGED
@@ -41,4 +41,5 @@ Una volta installata, avvia Gemini CLI e verifica che la skill sia presente:
41
41
  - `gemini-extension.json`: Manifesto dell'estensione.
42
42
 
43
43
  ---
44
- Sviluppato da **antoneeo**
44
+ Realizzato da **Antonio Pinto** ([GitHub](https://github.com/Antoneeo))
45
+ © 2026 Antonio Pinto. Tutti i diritti riservati.
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "agentic-sdlc-skill",
3
- "version": "1.0.6",
3
+ "version": "1.0.8",
4
4
  "description": "Protocollo SDLC Documentation-First per Gemini CLI.",
5
- "author": "antoneeo"
5
+ "author": "Antonio Pinto (https://github.com/Antoneeo)"
6
6
  }
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "@antoneeo/agentic-sdlc-skill",
3
- "version": "1.0.6",
3
+ "version": "1.0.8",
4
4
  "description": "Protocollo SDLC Documentation-First per Gemini CLI. Gestisce audit, analisi, sviluppo e chiusura feature con documentazione sincronizzata.",
5
5
  "keywords": [
6
6
  "gemini-cli",
@@ -9,7 +9,7 @@
9
9
  "documentation",
10
10
  "ai-agent"
11
11
  ],
12
- "author": "antoneeo",
12
+ "author": "Antonio Pinto (https://github.com/Antoneeo)",
13
13
  "license": "MIT",
14
14
  "publishConfig": {
15
15
  "access": "public"
@@ -1,59 +1,67 @@
1
- ---
2
- name: agentic-sdlc
3
- description: Protocollo SDLC "Documentation-First". Utilizzare per gestire lo sviluppo di nuove feature, eseguire l'audit di progetti esistenti e mantenere rigorosamente aggiornata la documentazione tecnica prima, durante e dopo l'implementazione del codice.
4
- ---
5
-
6
- # Agentic SDLC
7
-
8
- Questa skill implementa un workflow rigoroso per lo sviluppo software, assicurando che la documentazione preceda sempre l'implementazione (Documentation-First). Sei un ingegnere del software senior che segue rigorosamente questo processo.
9
-
10
- ## Workflow Operativo
11
-
12
- ### 1. Fase di Audit e Allineamento
13
- Prima di rispondere a qualsiasi richiesta operativa, verifica lo stato della documentazione del progetto.
14
- - Controlla la presenza di `ai_docs/handoff.md`. Se esiste, leggilo per riprendere il contesto dell'ultima sessione.
15
- - Controlla l'esistenza della cartella `/ai_docs`.
16
- - Se `/ai_docs` non esiste o mancano i documenti fondamentali, non procedere con un'analisi dell'intero progetto in un solo colpo. Esegui invece un'analisi strutturata in step:
17
- 1. **Mappatura:** Crea un file di tracciamento (es. `ai_docs/audit_plan.md`) elencando le macro-directory e i file chiave da analizzare.
18
- 2. **Stato dell'Analisi:** Accanto a ogni elemento nel piano, indica lo stato: `[PENDING]`, `[ANALYZED]`, oppure `[SKIPPED]` (con relativa motivazione, es. "file generato", "asset statico").
19
- 3. **Esecuzione a Lotti (Batching):** Analizza la codebase seguendo l'ordine del file di piano, aggiornando lo stato man mano. Se il progetto è grande, esegui l'analisi a blocchi per evitare di saturare la memoria contestuale, chiedendo conferma all'utente tra un blocco e l'altro se necessario.
20
- 4. **Creazione Documenti:** Sulla base dei risultati dell'audit, compila i documenti fondamentali rispettando i seguenti formati:
21
- - `ai_docs/architecture.md`: Deve seguire questa struttura:
22
- - `# Architettura del Progetto`
23
- - `## Stack Tecnologico`
24
- - `## Struttura delle Directory`
25
- - `## Pattern Architetturali`
26
- - `ai_docs/existing_features.md`: Deve seguire questa struttura:
27
- - `# Funzionalità Esistenti`
28
- - Elenco puntato nel formato: `- [ID] **Nome Feature**: Descrizione`
29
- - `ai_docs/features_history.md`: Deve essere una tabella Markdown con le seguenti colonne: `| ID | Nome Feature | Stato | Data Inizio | Data Fine | Doc. Analisi | Note |`. Gli stati ammessi sono `[PLANNED]`, `[IN_PROGRESS]`, `[COMPLETED]`.
30
-
31
- ### 2. Fase di Analisi della Richiesta
32
- Per ogni nuova feature richiesta dall'utente:
33
- - Crea `ai_docs/solutions/ANALYSIS_[nome_feature].md`. Il documento deve obbligatoriamente seguire questa struttura:
34
- - `# Analisi della Feature: [Nome Feature]`
35
- - `## Obiettivo` (Cosa si vuole ottenere e quali problemi risolve)
36
- - `## Impatto` (Modifiche ai file esistenti, performance, nuove dipendenze)
37
- - `## Piano d'Azione` (Elenco di task con checkbox `[ ]`)
38
- - `## Strategia di Test` (Test unitari AAA, test d'integrazione, esempi)
39
- - Aggiungi la nuova feature in `ai_docs/features_history.md` con stato `[PLANNED]`.
40
-
41
- ### 3. Fase di Sviluppo e Test
42
- Solo dopo aver completato la Fase 2:
43
- 1. Aggiorna lo stato della feature in `ai_docs/features_history.md` a `[IN_PROGRESS]`.
44
- 2. Implementa il codice in modo chirurgico seguendo il piano definito. **Importante:** Per ogni file o macro-directory modificata o creata durante lo sviluppo, aggiorna `ai_docs/audit_plan.md` reimpostando (o aggiungendo) il suo stato a `[PENDING]`.
45
- 3. **Obbligatorio:** Scrivi i test automatici seguendo il pattern AAA (Arrange, Act, Assert).
46
- 4. Esegui i test. Se falliscono, correggi il codice e riesegui. **Se i test falliscono per più di 3 volte consecutive, fermati e chiedi istruzioni all'utente.**
47
-
48
- ### 4. Fase di Chiusura
49
- A completamento della feature (test passati con Exit Code 0):
50
- - Rivedi gli elementi contrassegnati come `[PENDING]` in `ai_docs/audit_plan.md` per estrarre eventuali novità strutturali.
51
- - Aggiorna `architecture.md` e `existing_features.md` sulla base di questa revisione se la feature ha introdotto nuove dipendenze, pattern o capacità.
52
- - Riporta lo stato dei file appena rivisti in `ai_docs/audit_plan.md` a `[ANALYZED]`.
53
- - Aggiorna `ai_docs/features_history.md` impostando lo stato a `[COMPLETED]`.
54
-
55
- ### 5. Gestione delle Sessioni (Handoff)
56
- Quando viene richiesto di mettere in pausa il lavoro o di chiudere la sessione:
57
- - Aggiorna (o crea) il file `ai_docs/handoff.md` descrivendo esattamente a che punto ti trovi (es. "Sto lavorando al file X", "L'ultimo test fallito è Y", "Il prossimo passo è Z").
58
- - Questo file serve per preservare il tuo contesto di ragionamento. Quando avvierai una nuova sessione, la Fase 1 ti chiederà di leggerlo per riprendere il lavoro in modo fluido.
59
-
1
+ ---
2
+ name: agentic-sdlc
3
+ description: Protocollo SDLC "Documentation-First" con integrazione opzionale devPNT. Utilizzare per gestire lo sviluppo di nuove feature, eseguire l'audit di progetti esistenti e mantenere rigorosamente aggiornata la documentazione tecnica prima, durante e dopo l'implementazione del codice.
4
+ author: Antonio Pinto (https://github.com/Antoneeo)
5
+ copyright: © 2026 Antonio Pinto
6
+ ---
7
+
8
+ # Agentic SDLC (Hybrid Edition)
9
+
10
+ Questa skill implementa un workflow rigoroso per lo sviluppo software, assicurando che la documentazione preceda sempre l'implementazione (Documentation-First). Se rileva la presenza del server MCP **devPNT**, potenzia il workflow utilizzando il database per la governance e i piani gerarchici.
11
+
12
+ Realizzata da **Antonio Pinto** (https://github.com/Antoneeo).
13
+
14
+ ## Workflow Operativo
15
+
16
+ ### 0. Fase di Discovery (Ambiente)
17
+ Prima di rispondere a qualsiasi richiesta operativa, verifica la disponibilità dei tool `devpnt_*`.
18
+ - **MODALITÀ HYBRID (devPNT presente):** Delega la gestione dei piani (Master/Action) e del versionamento degli artefatti (`D-UC`, `P-TM`, `E-ISP`, `E-TDD`) a devPNT. Usa la cartella `ai_docs/` per salvare le versioni Markdown ("shadow-copy") dei documenti per garantire visibilità e compatibilità.
19
+ - **MODALITÀ STANDALONE (devPNT assente):** Gestisci tutto via filesystem in `ai_docs/`. In caso di progetti complessi, suggerisci l'adozione di devPNT per una governance avanzata.
20
+
21
+ ### 1. Fase di Audit e Allineamento
22
+ Verifica lo stato della documentazione del progetto.
23
+ - Controlla la presenza di `ai_docs/audit/handoff.md`. Se esiste, leggilo per riprendere il contesto dell'ultima sessione.
24
+ - Controlla l'esistenza della cartella `ai_docs/`.
25
+ - Se `ai_docs/` non esiste o mancano i documenti fondamentali, non procedere con un'analisi dell'intero progetto in un solo colpo. Esegui invece un'analisi strutturata in step:
26
+ 1. **Mappatura:** Crea un file di tracciamento (es. `ai_docs/audit/audit_plan.md`) elencando le macro-directory e i file chiave da analizzare. Se in modalità **Hybrid**, puoi usare `devpnt_kl_init_scope` per generare la mappatura iniziale.
27
+ 2. **Stato dell'Analisi:** Accanto a ogni elemento nel piano, indica lo stato: `[PENDING]`, `[ANALYZED]`, oppure `[SKIPPED]` (con relativa motivazione, es. "file generato", "asset statico").
28
+ 3. **Esecuzione a Lotti (Batching):** Analizza la codebase seguendo l'ordine del file di piano, aggiornando lo stato man mano. Se il progetto è grande, esegui l'analisi a blocchi per evitare di saturare la memoria contestuale, chiedendo conferma all'utente tra un blocco e l'altro se necessario.
29
+ 4. **Creazione Documenti:** Sulla base dei risultati dell'audit, compila i documenti fondamentali rispettando i seguenti formati:
30
+ - `ai_docs/strategic/architecture.md`: Deve seguire questa struttura:
31
+ - `# Architettura del Progetto`
32
+ - `## Stack Tecnologico`
33
+ - `## Struttura delle Directory`
34
+ - `## Pattern Architetturali`
35
+ - `ai_docs/strategic/existing_features.md`: Deve seguire questa struttura:
36
+ - `# Funzionalità Esistenti`
37
+ - Elenco puntato nel formato: `- [ID] **Nome Feature**: Descrizione`
38
+ - `ai_docs/strategic/features_history.md`: Deve essere una tabella Markdown con le seguenti colonne: `| ID | Nome Feature | Stato | Data Inizio | Data Fine | Doc. Analisi | Note |`. Gli stati ammessi sono `[PLANNED]`, `[IN_PROGRESS]`, `[COMPLETED]`.
39
+
40
+ ### 2. Fase di Analisi della Richiesta
41
+ Per ogni nuova feature richiesta dall'utente:
42
+ - **Hybrid:** Crea un nodo nel Master Plan e definisci l'Action Plan tramite devPNT. Salva i documenti di design (`D-UC`, `P-TM`, `E-ISP`, `E-TDD`) nel Database e crea contemporaneamente il file Markdown in `ai_docs/solutions/ANALYSIS_[nome_feature].md`.
43
+ - **Standalone:** Crea `ai_docs/solutions/ANALYSIS_[nome_feature].md`. Il documento deve obbligatoriamente seguire questa struttura:
44
+ - `# Analisi della Feature: [Nome Feature]`
45
+ - `## Obiettivo` (Cosa si vuole ottenere e quali problemi risolve)
46
+ - `## Impatto` (Modifiche ai file esistenti, performance, nuove dipendenze)
47
+ - `## Piano d'Azione` (Elenco di task con checkbox `[ ]`)
48
+ - `## Strategia di Test` (Test unitari AAA, test d'integrazione, esempi)
49
+ - In entrambe le modalità, aggiungi la nuova feature in `ai_docs/strategic/features_history.md` con stato `[PLANNED]`.
50
+
51
+ ### 3. Fase di Sviluppo e Test
52
+ Solo dopo aver completato la Fase 2:
53
+ 1. Aggiorna lo stato della feature in `features_history.md` a `[IN_PROGRESS]`.
54
+ 2. Implementa il codice in modo chirurgico seguendo il piano definito. **Importante:** Per ogni file o macro-directory modificata o creata durante lo sviluppo, aggiorna `ai_docs/audit/audit_plan.md` reimpostando (o aggiungendo) il suo stato a `[PENDING]`.
55
+ 3. **Obbligatorio:** Scrivi i test automatici seguendo il pattern **AAA (Arrange, Act, Assert)**.
56
+ 4. Esegui i test. Se falliscono, correggi il codice e riesegui. **Se i test falliscono per più di 3 volte consecutive, fermati e chiedi istruzioni all'utente.**
57
+
58
+ ### 4. Fase di Chiusura
59
+ A completamento della feature (test passati con Exit Code 0):
60
+ - **Hybrid:** Se la feature ha implicazioni di design, proponi un **ADR** tramite devPNT e aggiorna il Knowledge Layer (KL).
61
+ - **Standalone:** Rivedi gli elementi contrassegnati come `[PENDING]` in `ai_docs/audit/audit_plan.md` per estrarre eventuali novità strutturali. Aggiorna `architecture.md` e `existing_features.md` in `ai_docs/strategic/` se necessario.
62
+ - Riporta lo stato dei file appena rivisti in `ai_docs/audit/audit_plan.md` a `[ANALYZED]`.
63
+ - Aggiorna `features_history.md` impostando lo stato a `[COMPLETED]`.
64
+
65
+ ### 5. Gestione delle Sessioni (Handoff)
66
+ Quando viene richiesto di mettere in pausa il lavoro o di chiudere la sessione:
67
+ - Aggiorna (o crea) il file `ai_docs/audit/handoff.md` descrivendo esattamente a che punto ti trovi (es. "Sto lavorando al file X", "L'ultimo test fallito è Y", "Il prossimo passo è Z"). Questo file serve per preservare il tuo contesto di ragionamento.