siae-devforge

Enterprise test generation agent invoked via /code-coverage. Analyzes a repository, infers tech stack, and generates deterministic unit tests targeting >=70% coverage. Zero user runtime interactions.

Mostra la tua adoption personale delle 5 skill core DevForge, confrontata con la media del team. Legge il ledger task-scoped di PR #2 e aggrega da ~/.claude/devforge-activity.jsonl. Utile prima di aprire una PR per auto-valutare se stai seguendo il workflow.

Invoca la skill `siae-dev-analytics` per generare report ROI degli sviluppatori SIAE che usano Claude Code + DevForge.

Pre-compute deterministic quality signals (coverage, lint, complexity, CI SARIF, spec-drift) for the current SHA. Run on-demand prior to code review.

Esegue un piano implementativo in una sessione separata, a batch con checkpoint umani

Usa questo agente quando uno step significativo di un progetto e' stato completato e deve essere revisionato rispetto al piano originale, agli standard di codice SIAE, e alle best practice di sicurezza e architettura. L'agente assume un atteggiamento scettico e metodico: l'implementatore ha finito sospettosamente in fretta, e ogni scorciatoia deve essere scoperta. Esempi di attivazione: <example> Context: L'utente ha completato l'implementazione di un endpoint REST su Spring Boot user: "Ho finito il servizio di autenticazione, puoi fare una review?" assistant: "[Attiva code-reviewer] Avvio la review completa a 6 punti. L'implementazione e' stata completata velocemente — verifico ogni aspetto con attenzione." <commentary>L'agente viene attivato per una review post-implementazione. Applica il framework completo a 6 punti con approccio scettico.</commentary> </example> <example> Context: Pipeline dati Python completata su AWS Glue user: "La pipeline bronze-to-silver e' pronta, review please" assistant: "[Attiva code-reviewer] Analizzo la pipeline contro gli standard SIAE: naming, pattern Medallion, security, test coverage, e conformita' architetturale." <commentary>Review di una data pipeline — l'agente verifica pattern specifici come Medallion architecture, Glue best practices, e PySpark code quality.</commentary> </example> <example> Context: Modulo Terraform/Terragrunt per nuova infrastruttura user: "Ho creato il modulo Terraform per il nuovo servizio, controlla tutto" assistant: "[Attiva code-reviewer] Review IaC: verifico struttura file, naming, security (IAM least privilege, encryption), state management, e conformita' al pattern Terragrunt SIAE." <commentary>Per moduli IaC la review enfatizza security, struttura file (_input.tf, _local.tf, _output.tf), e aderenza ai pattern Terragrunt documentati.</commentary> </example>

Use this agent when the user needs to generate technical documentation from source code. It analyzes codebases and produces HLD (High Level Design), LLD (Low Level Design), and/or API documentation (OpenAPI 3.x) using SIAE templates and PlantUML diagrams. Optionally publishes to Confluence via MCP Atlassian. Examples: <example> Context: The user has a Spring Boot microservice and needs architectural documentation. user: "Genera l'HLD per il servizio payment-service" assistant: "Analizzo il codice sorgente di payment-service per generare l'High Level Design..." <commentary>The agent scans the codebase, identifies architecture patterns, external integrations, and generates a complete HLD using the hld-template.md with C4 diagrams in PlantUML.</commentary> </example> <example> Context: The user is implementing a new feature and needs detailed design documentation. user: "Crea il Low Level Design per la feature di notifiche push" assistant: "Analizzo i componenti coinvolti nella feature notifiche push per generare l'LLD..." <commentary>The agent reads the relevant source files, maps the data model, sequence flows, error handling, and produces a complete LLD using the lld-template.md.</commentary> </example> <example> Context: The user has REST endpoints and needs API documentation. user: "Documenta le API del servizio catalog-service in formato OpenAPI" assistant: "Analizzo gli endpoint REST di catalog-service per generare la documentazione API..." <commentary>The agent discovers controllers/routes, extracts endpoints, request/response schemas, status codes, and generates API documentation following the api-doc-template.md and OpenAPI 3.x structure.</commentary> </example> <example> Context: The user wants to publish generated documentation to Confluence. user: "Genera l'HLD di billing-service e pubblicalo su Confluence nello space ARCH" assistant: "Analizzo billing-service, genero l'HLD, e dopo la tua conferma lo pubblico su Confluence..." <commentary>The agent generates the document first, shows the preview, then displays a pre-flight card ALTO before publishing to Confluence via MCP Atlassian.</commentary> </example> <example> Context: The user needs complete documentation for a new project. user: "Genera tutta la documentazione per il nuovo servizio order-management" assistant: "Analizzo il codebase di order-management per generare HLD, LLD e API doc..." <commentary>The agent generates all three document types: HLD for system overview, LLD for implementation details, and API doc for endpoint reference.</commentary> </example>

Esegue il pre-flight MCP sport-kg per task implementativi su servizi mappati nel KG SIAE. Prefissi servizio (allineati con hooks/sport-task-detect — single source of truth): sport-*-service, sport-*-drools, sport-gestione-*, pop-*-service, pop-be, pae-*, ciam-*, dol-be, digital-channels-sport-*, esb-sport-*, esb-sso-*, mag-concertini-*, portal-apigateway-*, ttpp-*-bff-service. Pipeline 5-step deterministica: disambiguazione → demand_impact → wide scan parallelo → demand_impact_deep (condizionale) → impact_with_evidence (condizionale). Output strutturato grep-abile da incollare in cima al design doc generato da siae-brainstorming. Protegge il context window della conversazione principale dai 50KB+ di output dei tool MCP, restituisce un blocco markdown compatto. Esempi di attivazione: <example> Context: Brainstorming su feature che modifica la conferma pagamento di sport-gestione-licenze-service user: "Devo aggiungere l'arricchimento dei profili locale alla conferma pagamento in PagamentoServiceImpl" assistant: "Dispatch mcp-impact-analyst per pre-flight: identifico servizio target, rischio, vincoli prima di proporre opzioni." <commentary>L'agent viene invocato come Stage 0 del brainstorming quando il task tocca un servizio mappato nel KG sport-kg. Restituisce un blocco standardizzato con rischio + vincoli + volumi che orienta le opzioni.</commentary> </example> <example> Context: Bug su sport-locale-service riportato in produzione user: "C'e' un NPE su /detailLocale, dobbiamo fixarlo" assistant: "Dispatch mcp-impact-analyst con focus debug: subgrafo errori sport-locale-service + caller reali." <commentary>Modalita' debugging-oriented: chiama debug_service + service_health + who_calls per il path interessato e ritorna error pattern + caller a rischio regression.</commentary> </example> <example> Context: Modifica DTO in digital-channels-sport-dto user: "Voglio aggiungere un campo a DichiarazioneEventoDTO" assistant: "Dispatch mcp-impact-analyst per impact_of_dto_change: blast radius transitivo sui consumer reali." <commentary>Modifica DTO library = potenziale breaking change cross-service. L'agent usa impact_of_dto_change + impact_with_evidence per identificare consumer attivi negli ultimi 30gg ES.</commentary> </example>

Investiga domande "come funziona X / chi chiama Y / quale auth usa Z" su sistemi SIAE mappati nel KG sport-kg + Elasticsearch + repository clonati. Pipeline 3-stage deterministica: KG topology → ES runtime → code grep, con fail-fast. Output strutturato (CONFIRMED / PARTIAL / REFUTED + confidence + evidence_type) per ogni claim. Adatto a Q&A multi-domanda parallele, dove ogni agent investiga un sotto-problema indipendente e produce un blocco markdown integrabile in un report consolidato. Differenza da mcp-impact-analyst: quello e' rigido (pre-flight design su servizio noto, output con 3 vincoli + decisioni). Qui invece l'oggetto e' una DOMANDA generica, non un task implementativo, e l'output e' un blocco di evidenze per chiudere un gap di conoscenza. Esempi di attivazione: <example> Context: Utente chiede chi chiama un servizio specifico via gateway esterno user: "Quali sono i clienti che eseguono chiamate dei MS SPORT contattando apigateway-service-ext e che tipo di auth usano?" assistant: "Dispatch qa-investigator: pipeline KG (who_calls) → ES (caller breakdown 30gg) → grep (auth filter chain). Output strutturato con CONFIRMED/REFUTED per ogni cliente atteso." <commentary>Q&A su topology + auth — qa-investigator combina KG, ES traffic e code grep nelle 3 stage. Ritorna blocco md con matrice clienti + meccanismo auth + gap.</commentary> </example> <example> Context: Utente vuole sapere come e' processato un workflow batch user: "Come viene elaborato il workflow di rilascio licenza e da quale microservizio?" assistant: "Dispatch qa-investigator: stage 1 identifica host workflow via list_services + search_endpoints; stage 2 verifica volumi ES; stage 3 grep su repo per pipeline cron/scheduler/Drools." <commentary>Workflow analysis che non e' un design task — e' Q&A pura. L'agent fa pipeline deterministica e ritorna sequenza + fallback path + caller distribution.</commentary> </example> <example> Context: 4 domande indipendenti su sistema SPORT — utente vuole risposta consolidata user: "(1) Chi scrive notifica_movimento? (2) Workflow rilascio? (3) Caller apigateway interno? (4) Caller apigateway-ext?" assistant: "Dispatch 4 qa-investigator paralleli, uno per domanda. Ognuno scrive nel scratchpad condiviso. Consolido al ritorno." <commentary>Pattern multi-domanda parallel: 4 invocazioni concorrenti, ognuna con scope ristretto. Lo scratchpad evita re-discovery di entita' trasversali (es. AAS IdP scoperto in domanda 4 ma usato anche in 1+3).</commentary> </example>

Verifica che l'implementazione sia conforme alla specifica/design doc: tutti i requisiti implementati, nessuna feature non richiesta (YAGNI), test che coprono ogni requisito, file modificati coerenti col piano. Usa questo agent dopo che un implementer dichiara il lavoro completato. Examples: <example> Context: L'utente ha completato l'implementazione di una feature e vuole verificare la conformita' al piano. user: "Ho finito di implementare la feature di gestione utenti, puoi verificare che sia tutto conforme al design?" assistant: "Invoco l'agent siae-devforge:spec-reviewer per verificare la conformita' al design doc." <commentary>L'agent viene invocato dopo che l'implementer dichiara il lavoro completato. Cerca il design doc in docs/plans/ e verifica ogni requisito contro l'implementazione reale.</commentary> </example> <example> Context: Code review in corso, il reviewer vuole verificare che non manchino requisiti dal piano. user: "/forge-review" assistant: "Lancio code review completa. Uso l'agent spec-reviewer per verificare la conformita' al piano implementativo." <commentary>Lo spec-reviewer viene invocato come parte del flusso forge-review per integrare la verifica di conformita' alla specifica nella code review standard.</commentary> </example> <example> Context: Un developer ha completato un bug fix e vuole assicurarsi di aver coperto tutti i punti del piano. user: "Verifica che il fix per il bug DIRITTI-1234 copra tutti i punti del piano 2026-02-28-diritti-fix-design.md" assistant: "Invoco l'agent siae-devforge:spec-reviewer con il piano specificato per verificare completezza e conformita'." <commentary>L'agent puo' essere invocato con un riferimento esplicito a un design doc specifico in docs/plans/.</commentary> </example>

Enterprise test generation agent invoked via /code-coverage. Analyzes a repository, infers tech stack, and generates deterministic unit tests targeting >=70% coverage. Zero user runtime interactions.

Genera il Master Test Plan (MTP) in formato .docx e la Product Risk Analysis (PRA) in formato .xlsx conformi ai template SIAE, attraverso un flusso interattivo a 6 fasi. Orchestra: intake perimetro (3 canali: JIRA/chat/documenti), analisi funzionale, conferma sistemi impattati, discovery GitHub opzionale, produzione .docx e .xlsx via patch template. Lingua: italiano.

Aggiunge un nuovo prefix S3 alla event rule EventBridge `transient_relational_new` in modules/transient/eventbridge-new-data.tf seguendo il flusso completo SIAE — crea release+feature branch, applica edit, apre PR draft, mergia in deploy/collaudo, esegue make dev. Trigger - "aggiungi prefix transient", "nuovo prefix bronze", "aggiungi dominio a transient_relational_new", "abilita ingestion {db_name}", "registra prefix EventBridge", "registra dominio EDW".

Use when evaluating, choosing, or analyzing architectural patterns for an existing or new system. Analizza architettura di sistemi software: C4 model, HLD, bounded context, CQRS, event-driven, microservizi vs monolite, resilienza, accoppiamento tra servizi. Trigger: VALUTARE, SCEGLIERE, ANALIZZARE pattern architetturali. **Best after**: siae-brainstorming Step 4 (options proposed) — questa skill è specialistica per deepen architectural choice già scoperto. Examples: "valutiamo CQRS", "microservizi o monolite?", "crea il C4", "definisci i bounded context", "HLD per il sistema X".

Use when setting up E2E test automation, Playwright/Cypress, or CI/CD test pipelines. Configura test automation E2E, setup Playwright/Cypress e pipeline CI/CD test. Trigger: automatizza test, setup Playwright, setup Cypress, test E2E, test di regressione automatici, CI/CD pipeline test, GitHub Actions test.

29 hooks across 6 events