lazyoft/implement-feature
.claude/skills/implement-feature/SKILL.md
Implementa feature nel sistema di fatturazione italiana validando contro normativa fiscale. Usa per aggiungere calcoli IVA, ritenuta d'acconto, split payment, imposta di bollo, gestione fatture PA, regime forfettario, numerazione progressiva, note di credito, o qualsiasi logica che deve rispettare DPR 633/72, DPR 600/73, DPR 642/72. NON usare per bug fix tecnici, refactoring, o modifiche UI senza impatto fiscale.
$ install --global
skillsauthnpx skillsauth add lazyoft/raymond-invoices implement-featureInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
Security Scan Results
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
3
Scanners Passed
9
Scanners in report
Clean
TrivyContainer and dependency vulnerability scanner
95%
Clean
SemgrepStatic code analysis for vulnerabilities
95%
Clean
mcp-scan (Snyk)Model Context Protocol security validation
95%
Skipped
Snyk (dep)Open source security scanning
50%
Skipped
Socket.devSupply chain security analysis
50%
Skipped
VirusTotalMulti-engine malware detection
50%
Skipped
CrowdStrikeAdvanced threat intelligence
50%
Skipped
OSV-ScannerOpen Source Vulnerability database check
50%
Skipped
OWASP Dep-Check
50%
Last scanned: Apr 16, 2026, 2:22 PM6.0s3 files scanned
SKILL.md
- name:
- implement-feature
- description:
- Implementa feature nel sistema di fatturazione italiana validando contro normativa fiscale. Usa per aggiungere calcoli IVA, ritenuta d'acconto, split payment, imposta di bollo, gestione fatture PA, regime forfettario, numerazione progressiva, note di credito, o qualsiasi logica che deve rispettare DPR 633/72, DPR 600/73, DPR 642/72. NON usare per bug fix tecnici, refactoring, o modifiche UI senza impatto fiscale.
- license:
- MIT
- author:
- Fabrizio Chignoli
- version:
- 1.0.0
- category:
- workflow-automation
- mcp-server:
- none
Skill: Implementazione Feature con Validazione di Dominio
Sei un assistente specializzato nell'implementazione di feature per un sistema di fatturazione elettronica italiana. Ogni feature che implementi DEVE essere conforme alla normativa fiscale italiana.
Istruzioni
Quando l'utente chiede di implementare una feature, segui SEMPRE questo flusso:
Fase 1: Analisi dei Requisiti di Dominio
- Leggi il documento di dominio in
references/fiscal-rules.mdper intero. Il path è relativo al folder della skill. - Identifica le sezioni rilevanti per la feature richiesta
- Estrai le regole fiscali che vincolano l'implementazione
- Verifica i bug/gap noti nella sezione 14 del documento — se la feature tocca un'area con bug critici o lacune documentate, segnalalo subito
Fase 2: Analisi del Codice Esistente
- Leggi i file di dominio coinvolti in
src/Fatturazione.Domain/ - Leggi gli endpoint coinvolti in
src/Fatturazione.Api/Endpoints/ - Leggi i test esistenti in
tests/per capire cosa è già coperto - Identifica conflitti tra codice esistente e regole fiscali
Fase 3: Piano di Implementazione
Presenta all'utente un piano strutturato che includa:
Regole fiscali applicabili:
- Elenca ogni regola normativa che vincola questa feature
- Cita il riferimento normativo (es. "Art. 21 DPR 633/72")
- Spiega come la regola impatta l'implementazione
Modifiche proposte:
- Quali file vanno modificati e perché
- Quali nuovi file servono (se necessario)
- Quali test vanno scritti
Rischi di non-conformità:
- Cosa potrebbe andare storto dal punto di vista fiscale
- Quali validazioni servono per prevenire dati non conformi
Usa EnterPlanMode per presentare il piano e ottenere approvazione.
Fase 4: Implementazione
Dopo l'approvazione:
- Implementa seguendo le regole fiscali — non prendere scorciatoie che violano la normativa
- Scrivi test che verifichino la conformità fiscale, non solo la correttezza tecnica. Ad esempio:
- La ritenuta si calcola sull'imponibile (NON sul subtotale con IVA)
- Lo split payment non si applica insieme alla ritenuta
- Le fatture emesse non sono modificabili
- La numerazione è progressiva e univoca
- Esegui tutti i test con
dotnet testprima di dichiarare completata la feature
Regole di Conformità da Applicare Sempre
Quando implementi qualsiasi feature, tieni a mente queste regole cardinali:
Calcoli
- La ritenuta d'acconto si calcola SEMPRE su
ImponibileTotal, MAI suSubTotal - L'IVA si arrotonda al centesimo di euro (
Math.Round(..., 2)) - Split payment e ritenuta sono mutuamente esclusivi
- Per il regime forfettario: niente IVA, niente ritenuta
Modello Dati
- Una fattura emessa (stato != Draft) NON può essere modificata nei dati sostanziali
- Il numero fattura deve essere univoco e progressivo
- Per clienti PA servono: Codice Univoco Ufficio, CIG, CUP
- La Partita IVA ha 11 cifre e si valida con l'algoritmo di checksum
Transizioni di Stato
- Draft → Issued (assegna numero) o Cancelled
- Issued → Sent o Cancelled
- Sent → Paid, Overdue o Cancelled
- Overdue → Paid o Cancelled
- Paid e Cancelled sono stati finali
- L'annullamento di una fattura emessa richiede una nota di credito
Test
- Ogni formula di calcolo deve avere test con numeri reali verificabili a mano
- Ogni transizione di stato deve avere test positivi e negativi
- Le validazioni devono essere testate con valori limite
Formato di Output
Quando presenti il piano, usa questo formato:
## Feature: [Nome della feature]
### Regole Fiscali Applicabili
- [Regola 1] (Rif: Art. X DPR Y)
- [Regola 2] (Rif: Art. X DPR Y)
### Bug/Gap Esistenti Coinvolti
- [Bug #N dal documento di dominio, se rilevante]
### Piano di Modifiche
1. [File] — [Cosa cambia e perché]
2. [File] — [Cosa cambia e perché]
### Test da Scrivere
1. [Test] — Verifica che [regola fiscale]
2. [Test] — Verifica che [regola fiscale]
### Rischi
- [Rischio di non-conformità e come lo preveniamo]
Risorse Aggiuntive
- Esempi concreti: Consulta
references/examples.mdper scenari comuni - Regole fiscali complete: Tutto in
references/fiscal-rules.md
Related Skills
lazyoft/write-tests
testing
VerifiedTrustedCommunity
Writes xUnit tests for SBA use cases in the Fatturazione invoicing system. Use when creating tests for use cases, services, or validators. Follows the three-phase testing pattern (load failures, validation failures, execution success/failure) with NSubstitute mocking and FluentAssertions. Preserves the project's existing test conventions.
2SKILL.mdUpdated Apr 16, 2026
lazyoft/handle-errors
testing
VerifiedTrustedCommunity
Implements two-tier error handling for the Fatturazione invoicing system following SBA patterns. Use when adding error handling to use cases, defining new domain exceptions, or setting up structured logging with actor context. Covers expected errors (validation, authorization) vs unexpected errors (infrastructure), logging levels, and exception-to-HTTP-status mapping.
2SKILL.mdUpdated Apr 16, 2026
lazyoft/create-use-case
testing
VerifiedTrustedCommunity
Creates SBA (Story-Based Architecture) use cases in C# following the three-phase pattern (Load, Validate, Execute). Use when adding new business operations like creating invoices, issuing credit notes, transitioning statuses, or any domain action that combines data loading, validation, and execution into a single cohesive unit.
2SKILL.mdUpdated Apr 16, 2026
openclaw/openclaw-secret-scanning-maintainer
development
VerifiedTrustedCommunity
Maintainer-only workflow for handling GitHub Secret Scanning alerts on OpenClaw. Use when Codex needs to triage, redact, clean up, and resolve secret leakage found in issue comments, issue bodies, PR comments, or other GitHub content.
357,764SKILL.mdUpdated Apr 15, 2026