@antoneeo/agentic-sdlc-skill 1.3.0 → 1.4.0
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 +15 -2
- package/README.md +19 -14
- package/gemini-extension.json +1 -1
- package/package.json +1 -1
- package/references/analysis_template.md +14 -8
- package/references/architecture_template.md +7 -4
- package/references/feature_vision_template.md +19 -0
- package/references/principles_template.md +12 -0
- package/references/project_vision_template.md +25 -0
- package/references/roadmap_template.md +8 -0
- package/scripts/init.js +118 -63
- package/scripts/postinstall.js +1 -1
- package/skills/agentic-sdlc-skill/SKILL.md +68 -47
package/CHANGELOG.md
CHANGED
|
@@ -1,6 +1,18 @@
|
|
|
1
1
|
# Changelog - Agentic SDLC Skill
|
|
2
2
|
|
|
3
|
-
Tutte le modifiche significative a questa skill saranno documentate in questo file.
|
|
3
|
+
Tutte le modifiche significative a questa skill saranno documentate in questo file.
|
|
4
|
+
|
|
5
|
+
## [1.4.0] - 2026-06-07
|
|
6
|
+
### Added
|
|
7
|
+
- Introdotta la governance della **Vision** con nuova struttura `ai_docs/vision/` (`project_vision.md`, `roadmap.md`, `principles.md`, `features/`).
|
|
8
|
+
- Aggiunto il **Vision Gate** nel workflow operativo: ogni feature significativa deve essere verificata rispetto a obiettivi, non-obiettivi, benefici attesi e segnali di successo prima dell'analisi tecnica.
|
|
9
|
+
- Aggiunti template Vision in `references/` e sezione `Allineamento alla Vision` nel template di analisi.
|
|
10
|
+
- `agentic-sdlc-init` ora crea i documenti Vision boilerplate nei nuovi progetti.
|
|
11
|
+
|
|
12
|
+
## [1.3.1] - 2026-05-14
|
|
13
|
+
### Fixed
|
|
14
|
+
- Correzione documentazione (README + CHANGELOG) della sintassi per invocare il bin `agentic-sdlc-install-skill`. La forma `npx @antoneeo/agentic-sdlc-skill agentic-sdlc-install-skill` documentata in 1.3.0 **non funziona** perché npx non riesce a disambiguare il bin quando il pacchetto ne espone più di uno (errore: `could not determine executable to run`). Sintassi corretta: lanciare `agentic-sdlc-install-skill` direttamente dopo `npm install -g`, oppure usare `npx -p @antoneeo/agentic-sdlc-skill agentic-sdlc-install-skill` con `-p` esplicito.
|
|
15
|
+
- Nessuna modifica al codice della skill: il bin di 1.3.0 funziona correttamente, era solo la doc a indicare la sintassi sbagliata.
|
|
4
16
|
|
|
5
17
|
## [1.3.0] - 2026-05-14
|
|
6
18
|
### Added
|
|
@@ -9,7 +21,8 @@ Tutte le modifiche significative a questa skill saranno documentate in questo fi
|
|
|
9
21
|
|
|
10
22
|
### Usage
|
|
11
23
|
```bash
|
|
12
|
-
|
|
24
|
+
npm install -g @antoneeo/agentic-sdlc-skill@latest
|
|
25
|
+
agentic-sdlc-install-skill
|
|
13
26
|
```
|
|
14
27
|
|
|
15
28
|
## [1.2.4] - 2026-05-14
|
package/README.md
CHANGED
|
@@ -2,11 +2,12 @@
|
|
|
2
2
|
|
|
3
3
|
A "Documentation-First" SDLC protocol designed to manage the software development lifecycle rigorously. It natively supports **Claude Code** (skill auto-installed in `~/.claude/skills/`), **Gemini CLI** (extension), and **Codex AI** (skill auto-installed in `~/.codex/skills/`).
|
|
4
4
|
|
|
5
|
-
## Key Features
|
|
6
|
-
- **Documentation-First**: Requires documentation (`
|
|
7
|
-
- **
|
|
8
|
-
- **
|
|
9
|
-
- **
|
|
5
|
+
## Key Features
|
|
6
|
+
- **Documentation-First**: Requires documentation (`ai_docs/`) to be created or updated before writing code.
|
|
7
|
+
- **Vision-Guided Governance**: Adds `ai_docs/vision/` and a Vision Gate so features stay aligned with goals, non-goals, and expected benefits.
|
|
8
|
+
- **Automatic Audit**: Analyzes the existing architecture and features.
|
|
9
|
+
- **Traceable Workflow**: Tracks feature status in `features_history.md`.
|
|
10
|
+
- **Built-In Quality**: Native integration of analysis, development, and testing.
|
|
10
11
|
|
|
11
12
|
## Installation
|
|
12
13
|
|
|
@@ -28,13 +29,18 @@ The `postinstall` script automatically detects installed CLIs and configures eac
|
|
|
28
29
|
|
|
29
30
|
If after `npm install -g` you do **not** see the line `--- Agentic SDLC Skill Discovery ---` in the npm output, and `~/.claude/skills/agentic-sdlc/` does not exist, the `postinstall` hook was skipped by npm. The most common cause is `ignore-scripts=true` in your npm config (set by some Node installers, corporate IT policies, or security tools).
|
|
30
31
|
|
|
31
|
-
|
|
32
|
+
The package ships an explicit `agentic-sdlc-install-skill` command that does the same work but does **not** depend on the `postinstall` hook. After `npm install -g`, the bin shim is created regardless of `ignore-scripts`, so you can simply run:
|
|
32
33
|
|
|
33
34
|
```bash
|
|
34
|
-
|
|
35
|
+
npm install -g @antoneeo/agentic-sdlc-skill@latest
|
|
36
|
+
agentic-sdlc-install-skill
|
|
35
37
|
```
|
|
36
38
|
|
|
37
|
-
|
|
39
|
+
You should see the `--- Agentic SDLC Skill Discovery ---` banner and `📦 Installed Claude Code skill at: ...`. Then restart Claude Code (or Codex) and the skill will be available.
|
|
40
|
+
|
|
41
|
+
> **Note on `npx`**: because the package exposes two bin commands, the shorthand `npx @antoneeo/agentic-sdlc-skill agentic-sdlc-install-skill` does not work — npx cannot disambiguate. If you prefer npx, use the explicit `-p` form: `npx -p @antoneeo/agentic-sdlc-skill agentic-sdlc-install-skill`.
|
|
42
|
+
|
|
43
|
+
Alternatively, fix the npm config and reinstall (the `postinstall` hook will then run automatically):
|
|
38
44
|
|
|
39
45
|
```bash
|
|
40
46
|
npm config set ignore-scripts false
|
|
@@ -42,8 +48,6 @@ npm uninstall -g @antoneeo/agentic-sdlc-skill
|
|
|
42
48
|
npm install -g @antoneeo/agentic-sdlc-skill@latest
|
|
43
49
|
```
|
|
44
50
|
|
|
45
|
-
Then restart Claude Code (or Codex) and the skill will be available.
|
|
46
|
-
|
|
47
51
|
### Via Gemini CLI (local alternative)
|
|
48
52
|
|
|
49
53
|
> **Tip:** Before installing, copy this folder from the USB drive to your computer's hard drive (for example, `C:\tools\agentic-sdlc-skill`). This keeps the skill available even after the USB drive is removed.
|
|
@@ -71,10 +75,11 @@ After installation, start Gemini CLI and verify that the skill is available:
|
|
|
71
75
|
The skill activates automatically when it detects requests related to development, audits, or feature management. You can also invoke it explicitly:
|
|
72
76
|
> "Use the agentic-sdlc skill to analyze this project"
|
|
73
77
|
|
|
74
|
-
## Project Structure
|
|
75
|
-
- `skills/`: Contains the skill logic (`SKILL.md`).
|
|
76
|
-
- `references/`: Markdown templates for architecture, analysis, and feature history.
|
|
77
|
-
- `
|
|
78
|
+
## Project Structure
|
|
79
|
+
- `skills/`: Contains the skill logic (`SKILL.md`).
|
|
80
|
+
- `references/`: Markdown templates for Vision, architecture, analysis, and feature history.
|
|
81
|
+
- `ai_docs/vision/`: Project and feature Vision documents created by the SDLC workflow.
|
|
82
|
+
- `gemini-extension.json`: Extension manifest.
|
|
78
83
|
|
|
79
84
|
---
|
|
80
85
|
Created by **Antonio Pinto** ([GitHub](https://github.com/Antoneeo))
|
package/gemini-extension.json
CHANGED
package/package.json
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "@antoneeo/agentic-sdlc-skill",
|
|
3
|
-
"version": "1.
|
|
3
|
+
"version": "1.4.0",
|
|
4
4
|
"description": "Protocollo SDLC Documentation-First per Claude Code, Gemini CLI e Codex. Auto-installa le skill native in ~/.claude/skills/ e ~/.codex/skills/. Gestisce audit, analisi, sviluppo e chiusura feature con documentazione sincronizzata.",
|
|
5
5
|
"keywords": [
|
|
6
6
|
"claude-code",
|
|
@@ -1,13 +1,19 @@
|
|
|
1
1
|
# Analisi della Feature: [Nome Feature]
|
|
2
2
|
|
|
3
|
-
## Obiettivo
|
|
4
|
-
- Cosa si vuole ottenere?
|
|
5
|
-
- Quali problemi risolve?
|
|
6
|
-
|
|
7
|
-
##
|
|
8
|
-
-
|
|
9
|
-
-
|
|
10
|
-
-
|
|
3
|
+
## Obiettivo
|
|
4
|
+
- Cosa si vuole ottenere?
|
|
5
|
+
- Quali problemi risolve?
|
|
6
|
+
|
|
7
|
+
## Allineamento alla Vision
|
|
8
|
+
- Quale documento di Vision guida questa feature? (`ai_docs/vision/project_vision.md` o `ai_docs/vision/features/VISION_[nome_feature].md`)
|
|
9
|
+
- Quale beneficio atteso realizza?
|
|
10
|
+
- Quali non-obiettivi o vincoli di Vision devono essere rispettati?
|
|
11
|
+
- Quali segnali di successo dimostreranno che la feature è coerente con la Vision?
|
|
12
|
+
|
|
13
|
+
## Impatto
|
|
14
|
+
- Modifiche ai file esistenti?
|
|
15
|
+
- Impatti sulle performance?
|
|
16
|
+
- Nuove dipendenze?
|
|
11
17
|
|
|
12
18
|
## Piano d'Azione
|
|
13
19
|
1. [ ] Sviluppo...
|
|
@@ -6,10 +6,13 @@
|
|
|
6
6
|
- **Database:** [es. PostgreSQL]
|
|
7
7
|
- **Strumenti di Test:** [es. Jest, Vitest]
|
|
8
8
|
|
|
9
|
-
## Struttura delle Directory
|
|
10
|
-
- `src/`: Codice sorgente.
|
|
11
|
-
- `
|
|
12
|
-
- `
|
|
9
|
+
## Struttura delle Directory
|
|
10
|
+
- `src/`: Codice sorgente.
|
|
11
|
+
- `ai_docs/vision/`: Vision di progetto, roadmap, principi e mini-vision delle feature.
|
|
12
|
+
- `ai_docs/strategic/`: Architettura, feature esistenti e storico feature.
|
|
13
|
+
- `ai_docs/solutions/`: Analisi e piani delle singole feature.
|
|
14
|
+
- `ai_docs/audit/`: Piano di audit e handoff di sessione.
|
|
15
|
+
- `tests/`: Test automatici.
|
|
13
16
|
|
|
14
17
|
## Pattern Architetturali
|
|
15
18
|
- [es. MVC, Clean Architecture, Layered Architecture]
|
|
@@ -0,0 +1,19 @@
|
|
|
1
|
+
# Vision della Feature: [Nome Feature]
|
|
2
|
+
|
|
3
|
+
## Problema
|
|
4
|
+
- Quale problema specifico risolve questa feature?
|
|
5
|
+
|
|
6
|
+
## Beneficio Atteso
|
|
7
|
+
- Quale risultato utile deve produrre per utenti o stakeholder?
|
|
8
|
+
|
|
9
|
+
## Utenti o Stakeholder
|
|
10
|
+
- Chi beneficia direttamente o indirettamente della feature?
|
|
11
|
+
|
|
12
|
+
## Segnali di Successo
|
|
13
|
+
- Come sapremo che la feature ha raggiunto l'obiettivo?
|
|
14
|
+
|
|
15
|
+
## Non-Obiettivi / Fuori Scope
|
|
16
|
+
- Cosa non deve essere incluso in questa feature?
|
|
17
|
+
|
|
18
|
+
## Vincoli e Principi Collegati
|
|
19
|
+
- Quali principi di `ai_docs/vision/principles.md` guidano questa feature?
|
|
@@ -0,0 +1,12 @@
|
|
|
1
|
+
# Principi di Vision
|
|
2
|
+
|
|
3
|
+
I principi in questo file guidano trade-off, scope e decisioni tecniche quando più soluzioni sono possibili.
|
|
4
|
+
|
|
5
|
+
## Principi
|
|
6
|
+
- **[Principio]**: [Descrizione pratica del criterio decisionale].
|
|
7
|
+
|
|
8
|
+
## Trade-off Preferiti
|
|
9
|
+
- Preferire [A] rispetto a [B] quando [condizione].
|
|
10
|
+
|
|
11
|
+
## Anti-Pattern Strategici
|
|
12
|
+
- [Comportamento o direzione da evitare perché devia dalla Vision].
|
|
@@ -0,0 +1,25 @@
|
|
|
1
|
+
# Vision del Progetto
|
|
2
|
+
|
|
3
|
+
## North Star
|
|
4
|
+
- Qual è l'obiettivo finale che il progetto deve preservare nel tempo?
|
|
5
|
+
|
|
6
|
+
## Problema Centrale
|
|
7
|
+
- Quale problema reale risolve il progetto?
|
|
8
|
+
|
|
9
|
+
## Utenti Target
|
|
10
|
+
- Chi sono gli utenti o stakeholder principali?
|
|
11
|
+
|
|
12
|
+
## Valore Atteso
|
|
13
|
+
- Quale beneficio misurabile o osservabile deve produrre il progetto?
|
|
14
|
+
|
|
15
|
+
## Obiettivi
|
|
16
|
+
- [Obiettivo 1]
|
|
17
|
+
- [Obiettivo 2]
|
|
18
|
+
|
|
19
|
+
## Non-Obiettivi
|
|
20
|
+
- [Cosa il progetto non vuole diventare]
|
|
21
|
+
- [Cosa è esplicitamente fuori scope]
|
|
22
|
+
|
|
23
|
+
## Segnali di Successo
|
|
24
|
+
- [Indicatore qualitativo o quantitativo]
|
|
25
|
+
- [Comportamento utente o metrica attesa]
|
package/scripts/init.js
CHANGED
|
@@ -1,4 +1,4 @@
|
|
|
1
|
-
#!/usr/bin/env node
|
|
1
|
+
#!/usr/bin/env node
|
|
2
2
|
|
|
3
3
|
const fs = require('fs');
|
|
4
4
|
const path = require('path');
|
|
@@ -17,58 +17,110 @@ function checkCommand(cmd) {
|
|
|
17
17
|
}
|
|
18
18
|
|
|
19
19
|
// 1. Path definitions
|
|
20
|
-
const directories = [
|
|
21
|
-
path.join(cwd, 'ai_docs'),
|
|
22
|
-
path.join(cwd, 'ai_docs', '
|
|
23
|
-
path.join(cwd, 'ai_docs', '
|
|
24
|
-
path.join(cwd, 'ai_docs', '
|
|
25
|
-
|
|
26
|
-
|
|
27
|
-
|
|
28
|
-
|
|
29
|
-
|
|
30
|
-
|
|
20
|
+
const directories = [
|
|
21
|
+
path.join(cwd, 'ai_docs'),
|
|
22
|
+
path.join(cwd, 'ai_docs', 'vision'),
|
|
23
|
+
path.join(cwd, 'ai_docs', 'vision', 'features'),
|
|
24
|
+
path.join(cwd, 'ai_docs', 'strategic'),
|
|
25
|
+
path.join(cwd, 'ai_docs', 'audit'),
|
|
26
|
+
path.join(cwd, 'ai_docs', 'solutions')
|
|
27
|
+
];
|
|
28
|
+
|
|
29
|
+
const files = {
|
|
30
|
+
projectVision: path.join(cwd, 'ai_docs', 'vision', 'project_vision.md'),
|
|
31
|
+
roadmap: path.join(cwd, 'ai_docs', 'vision', 'roadmap.md'),
|
|
32
|
+
principles: path.join(cwd, 'ai_docs', 'vision', 'principles.md'),
|
|
33
|
+
architecture: path.join(cwd, 'ai_docs', 'strategic', 'architecture.md'),
|
|
34
|
+
existingFeatures: path.join(cwd, 'ai_docs', 'strategic', 'existing_features.md'),
|
|
35
|
+
featuresHistory: path.join(cwd, 'ai_docs', 'strategic', 'features_history.md'),
|
|
31
36
|
auditPlan: path.join(cwd, 'ai_docs', 'audit', 'audit_plan.md'),
|
|
32
|
-
handoff: path.join(cwd, 'ai_docs', 'audit', 'handoff.md'),
|
|
33
|
-
claudeConfig: path.join(cwd, 'CLAUDE.md'),
|
|
34
|
-
geminiConfig: path.join(cwd, 'GEMINI.md'),
|
|
35
|
-
codexAgents: path.join(cwd, 'AGENTS.md'),
|
|
36
|
-
cursorRules: path.join(cwd, '.cursorrules')
|
|
37
|
-
};
|
|
37
|
+
handoff: path.join(cwd, 'ai_docs', 'audit', 'handoff.md'),
|
|
38
|
+
claudeConfig: path.join(cwd, 'CLAUDE.md'),
|
|
39
|
+
geminiConfig: path.join(cwd, 'GEMINI.md'),
|
|
40
|
+
codexAgents: path.join(cwd, 'AGENTS.md'),
|
|
41
|
+
cursorRules: path.join(cwd, '.cursorrules')
|
|
42
|
+
};
|
|
38
43
|
|
|
39
44
|
// 2. Operational Protocol (System Prompt)
|
|
40
|
-
const protocolContent = `# "Agentic SDLC" Operational Protocol
|
|
41
|
-
|
|
42
|
-
You are a senior software engineer strictly following a "Documentation-First" process. NEVER implement code without completing the preceding documentation steps. Use your tools (file read/write, shell execution) to adhere to the following phases.
|
|
43
|
-
|
|
44
|
-
## 1. Audit and Alignment Phase
|
|
45
|
-
Before responding to any operational request:
|
|
46
|
-
- Check for the existence of the \`ai_docs/\`
|
|
47
|
-
- If \`ai_docs/\` is missing or essential documents are absent, create them by analyzing the source code:
|
|
48
|
-
1. \`ai_docs/
|
|
49
|
-
2. \`ai_docs/
|
|
50
|
-
3. \`ai_docs/
|
|
51
|
-
4. \`ai_docs/
|
|
52
|
-
|
|
53
|
-
|
|
54
|
-
|
|
55
|
-
-
|
|
56
|
-
|
|
57
|
-
|
|
58
|
-
|
|
59
|
-
|
|
60
|
-
|
|
61
|
-
|
|
62
|
-
|
|
63
|
-
|
|
64
|
-
|
|
65
|
-
|
|
66
|
-
|
|
67
|
-
-
|
|
68
|
-
|
|
69
|
-
|
|
70
|
-
|
|
71
|
-
|
|
45
|
+
const protocolContent = `# "Agentic SDLC" Operational Protocol
|
|
46
|
+
|
|
47
|
+
You are a senior software engineer strictly following a "Documentation-First" and "Vision-Guided" process. NEVER implement code without completing the preceding documentation steps. Use your tools (file read/write, shell execution) to adhere to the following phases.
|
|
48
|
+
|
|
49
|
+
## 1. Audit and Alignment Phase
|
|
50
|
+
Before responding to any operational request:
|
|
51
|
+
- Check for the existence of the \`ai_docs/\` and \`ai_docs/vision/\` folders.
|
|
52
|
+
- If \`ai_docs/\` is missing or essential documents are absent, create them by analyzing the source code:
|
|
53
|
+
1. \`ai_docs/vision/project_vision.md\`: North Star, target users, goals, non-goals, success signals.
|
|
54
|
+
2. \`ai_docs/vision/roadmap.md\`: Milestones, expected benefits, priorities, success signals.
|
|
55
|
+
3. \`ai_docs/vision/principles.md\`: Stable decision principles and strategic anti-patterns.
|
|
56
|
+
4. \`ai_docs/strategic/architecture.md\`: Tech Stack, Directory Structure, Architecture Patterns.
|
|
57
|
+
5. \`ai_docs/strategic/existing_features.md\`: List of current features.
|
|
58
|
+
6. \`ai_docs/strategic/features_history.md\`: Feature history table (ID, Name, Status, Dates).
|
|
59
|
+
7. \`ai_docs/audit/audit_plan.md\`: Codebase analysis plan in batches.
|
|
60
|
+
- Never treat architecture or feature history as a substitute for Vision.
|
|
61
|
+
|
|
62
|
+
## 2. Vision Gate
|
|
63
|
+
For every new feature request or significant behavior change:
|
|
64
|
+
- Read \`ai_docs/vision/project_vision.md\`, \`ai_docs/vision/roadmap.md\`, and \`ai_docs/vision/principles.md\`.
|
|
65
|
+
- If Vision documents are missing, empty, or ambiguous, create or update them before technical analysis.
|
|
66
|
+
- For significant features, create \`ai_docs/vision/features/VISION_[feature_name].md\` covering Problem, Expected Benefit, Users/Stakeholders, Success Signals, Non-Goals, and linked principles.
|
|
67
|
+
- If the request conflicts with Vision, stop and surface the conflict instead of implementing silently.
|
|
68
|
+
|
|
69
|
+
## 3. Request Analysis Phase
|
|
70
|
+
For every new feature request:
|
|
71
|
+
- Create \`ai_docs/solutions/ANALYSIS_[feature_name].md\` (Objective, Vision Alignment, Impact, Action Plan, Test Strategy).
|
|
72
|
+
- Add an entry in \`ai_docs/strategic/features_history.md\` with status \`[PLANNED]\`.
|
|
73
|
+
|
|
74
|
+
## 4. Development and Testing Phase
|
|
75
|
+
Only after Phases 2 and 3 are complete:
|
|
76
|
+
1. Update feature status to \`[IN_PROGRESS]\` in \`ai_docs/strategic/features_history.md\`.
|
|
77
|
+
2. Implement code surgically following the plan.
|
|
78
|
+
3. **Mandatory:** Write automated tests following the **AAA (Arrange, Act, Assert)** pattern.
|
|
79
|
+
4. Execute tests. If they fail, fix and re-run until Exit Code is 0.
|
|
80
|
+
|
|
81
|
+
## 5. Closing Phase
|
|
82
|
+
Upon feature completion:
|
|
83
|
+
- Verify the delivered result against \`ai_docs/vision/project_vision.md\` and the feature Vision document, including non-goals.
|
|
84
|
+
- Update \`ai_docs/strategic/architecture.md\` and \`ai_docs/strategic/existing_features.md\` if necessary.
|
|
85
|
+
- Update \`ai_docs/vision/\` documents if goals, non-goals, roadmap, expected benefits, or success signals changed.
|
|
86
|
+
- Update \`ai_docs/strategic/features_history.md\` setting status to \`[COMPLETED]\`.
|
|
87
|
+
`;
|
|
88
|
+
|
|
89
|
+
const projectVisionBoilerplate = `# Project Vision
|
|
90
|
+
|
|
91
|
+
## North Star
|
|
92
|
+
- TBD
|
|
93
|
+
|
|
94
|
+
## Target Users
|
|
95
|
+
- TBD
|
|
96
|
+
|
|
97
|
+
## Goals
|
|
98
|
+
- TBD
|
|
99
|
+
|
|
100
|
+
## Non-Goals
|
|
101
|
+
- TBD
|
|
102
|
+
|
|
103
|
+
## Success Signals
|
|
104
|
+
- TBD
|
|
105
|
+
`;
|
|
106
|
+
|
|
107
|
+
const roadmapBoilerplate = `# Vision Roadmap
|
|
108
|
+
|
|
109
|
+
| Milestone | Expected Benefit | Priority | Success Signal | Status |
|
|
110
|
+
|:---|:---|:---|:---|:---|
|
|
111
|
+
| M1 | - | - | - | [PLANNED] |
|
|
112
|
+
`;
|
|
113
|
+
|
|
114
|
+
const principlesBoilerplate = `# Vision Principles
|
|
115
|
+
|
|
116
|
+
## Principles
|
|
117
|
+
- TBD
|
|
118
|
+
|
|
119
|
+
## Strategic Anti-Patterns
|
|
120
|
+
- TBD
|
|
121
|
+
`;
|
|
122
|
+
|
|
123
|
+
const historyBoilerplate = `# Feature History
|
|
72
124
|
|
|
73
125
|
| ID | Feature Name | Status | Start Date | End Date | Analysis Doc | Notes |
|
|
74
126
|
|:---|:---|:---|:---|:---|:---|:---|
|
|
@@ -95,11 +147,14 @@ const writeIfNotExists = (filePath, content, description) => {
|
|
|
95
147
|
console.log(`⏭️ Skipped: ${path.relative(cwd, filePath)} already exists.`);
|
|
96
148
|
return false;
|
|
97
149
|
}
|
|
98
|
-
};
|
|
99
|
-
|
|
100
|
-
writeIfNotExists(files.
|
|
101
|
-
writeIfNotExists(files.
|
|
102
|
-
writeIfNotExists(files.
|
|
150
|
+
};
|
|
151
|
+
|
|
152
|
+
writeIfNotExists(files.projectVision, projectVisionBoilerplate, 'Project Vision Boilerplate');
|
|
153
|
+
writeIfNotExists(files.roadmap, roadmapBoilerplate, 'Vision Roadmap Boilerplate');
|
|
154
|
+
writeIfNotExists(files.principles, principlesBoilerplate, 'Vision Principles Boilerplate');
|
|
155
|
+
writeIfNotExists(files.architecture, '# Project Architecture\n\n- Stack:\n- Patterns:\n', 'Architecture Boilerplate');
|
|
156
|
+
writeIfNotExists(files.existingFeatures, '# Existing Features\n\n- \n', 'Features Boilerplate');
|
|
157
|
+
writeIfNotExists(files.featuresHistory, historyBoilerplate, 'History Table');
|
|
103
158
|
writeIfNotExists(files.auditPlan, '# Audit Plan\n\n| Directory/File | Status | Notes |\n|:---|:---|:---|\n| / | [PENDING] | Initial analysis |\n', 'Audit Plan');
|
|
104
159
|
|
|
105
160
|
// 5. Client Discovery and Configuration
|
|
@@ -115,17 +170,17 @@ if (checkCommand('gemini')) {
|
|
|
115
170
|
writeIfNotExists(files.geminiConfig, protocolContent, 'Gemini Configuration');
|
|
116
171
|
}
|
|
117
172
|
|
|
118
|
-
if (checkCommand('codex')) {
|
|
119
|
-
console.log('✅ Codex AI detected.');
|
|
120
|
-
writeIfNotExists(files.codexAgents, protocolContent, 'Codex AGENTS.md');
|
|
121
|
-
}
|
|
173
|
+
if (checkCommand('codex')) {
|
|
174
|
+
console.log('✅ Codex AI detected.');
|
|
175
|
+
writeIfNotExists(files.codexAgents, protocolContent, 'Codex AGENTS.md');
|
|
176
|
+
}
|
|
122
177
|
|
|
123
178
|
// Cursor/Windsurf (always recommended)
|
|
124
179
|
writeIfNotExists(files.cursorRules, protocolContent, 'Cursor/Windsurf Rules');
|
|
125
180
|
|
|
126
181
|
console.log('\n✅ Setup completed successfully!');
|
|
127
182
|
console.log('💡 Next steps:');
|
|
128
|
-
console.log(' 1. If using Claude Code, start it: it will read CLAUDE.md.');
|
|
129
|
-
console.log(' 2. If using Gemini CLI, commands will use GEMINI.md.');
|
|
130
|
-
console.log(' 3. If using Codex, restart/open the project so it reads AGENTS.md.');
|
|
131
|
-
console.log(' 4. Start analyzing the codebase following ai_docs/audit/audit_plan.md.');
|
|
183
|
+
console.log(' 1. If using Claude Code, start it: it will read CLAUDE.md.');
|
|
184
|
+
console.log(' 2. If using Gemini CLI, commands will use GEMINI.md.');
|
|
185
|
+
console.log(' 3. If using Codex, restart/open the project so it reads AGENTS.md.');
|
|
186
|
+
console.log(' 4. Start analyzing the codebase following ai_docs/audit/audit_plan.md.');
|
package/scripts/postinstall.js
CHANGED
|
@@ -17,64 +17,85 @@ Privilegia qualità e comprensione rispetto alla velocità apparente.
|
|
|
17
17
|
|
|
18
18
|
- **Comprendi prima di agire:** non modificare codice senza aver capito il motivo; nei bug cerca la root cause, non workaround.
|
|
19
19
|
- **Mantieni coerenza architetturale:** rispetta layer, responsabilità, naming, pattern e convenzioni esistenti.
|
|
20
|
-
- **Applica DRY e semplicità:** non duplicare logica o conoscenza; crea astrazioni solo se riducono complessità reale.
|
|
21
|
-
- **Preserva la qualità:** ogni modifica deve mantenere o migliorare stabilità, testabilità e manutenibilità.
|
|
22
|
-
- **Verifica tecnicamente:** chiudi ogni task implementativo con test/lint/smoke test, o spiega perché non eseguiti.
|
|
23
|
-
- **Mantieni memoria utile:** documenta decisioni e stato operativo rilevanti, non rumore.
|
|
20
|
+
- **Applica DRY e semplicità:** non duplicare logica o conoscenza; crea astrazioni solo se riducono complessità reale.
|
|
21
|
+
- **Preserva la qualità:** ogni modifica deve mantenere o migliorare stabilità, testabilità e manutenibilità.
|
|
22
|
+
- **Verifica tecnicamente:** chiudi ogni task implementativo con test/lint/smoke test, o spiega perché non eseguiti.
|
|
23
|
+
- **Mantieni memoria utile:** documenta decisioni e stato operativo rilevanti, non rumore.
|
|
24
|
+
- **Proteggi la Vision:** ogni decisione deve restare allineata a obiettivo finale, benefici attesi, utenti target e non-obiettivi dichiarati.
|
|
24
25
|
|
|
25
26
|
Se una patch sembra facile ma non capisci perché il codice attuale è fatto così, indaga prima di modificarlo.
|
|
26
27
|
|
|
27
28
|
## Workflow Operativo
|
|
28
29
|
|
|
29
|
-
### 0. Fase di Discovery (Ambiente)
|
|
30
|
-
Prima di rispondere a qualsiasi richiesta operativa, verifica la disponibilità dei tool `devpnt_*`.
|
|
31
|
-
- **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à.
|
|
32
|
-
- **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.
|
|
30
|
+
### 0. Fase di Discovery (Ambiente)
|
|
31
|
+
Prima di rispondere a qualsiasi richiesta operativa, verifica la disponibilità dei tool `devpnt_*`.
|
|
32
|
+
- **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à. Mantieni sempre la Vision leggibile in `ai_docs/vision/`.
|
|
33
|
+
- **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.
|
|
33
34
|
|
|
34
35
|
### 1. Fase di Audit e Allineamento
|
|
35
|
-
Verifica lo stato della documentazione del progetto.
|
|
36
|
-
- Controlla la presenza di `ai_docs/audit/handoff.md`. Se esiste, leggilo per riprendere il contesto dell'ultima sessione.
|
|
37
|
-
- Controlla l'esistenza della cartella `ai_docs/`.
|
|
38
|
-
- 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:
|
|
36
|
+
Verifica lo stato della documentazione del progetto.
|
|
37
|
+
- Controlla la presenza di `ai_docs/audit/handoff.md`. Se esiste, leggilo per riprendere il contesto dell'ultima sessione.
|
|
38
|
+
- Controlla l'esistenza della cartella `ai_docs/`.
|
|
39
|
+
- 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:
|
|
39
40
|
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.
|
|
40
41
|
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").
|
|
41
42
|
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.
|
|
42
|
-
4. **Creazione Documenti:** Sulla base dei risultati dell'audit, compila i documenti fondamentali rispettando i seguenti formati:
|
|
43
|
-
- `ai_docs/
|
|
44
|
-
|
|
45
|
-
|
|
46
|
-
|
|
43
|
+
4. **Creazione Documenti:** Sulla base dei risultati dell'audit, compila i documenti fondamentali rispettando i seguenti formati:
|
|
44
|
+
- `ai_docs/vision/project_vision.md`: Deve descrivere North Star, utenti target, problema centrale, obiettivi, non-obiettivi e segnali di successo.
|
|
45
|
+
- `ai_docs/vision/roadmap.md`: Deve descrivere milestone, benefici attesi, priorità e indicatori di avanzamento.
|
|
46
|
+
- `ai_docs/vision/principles.md`: Deve elencare i principi decisionali stabili che guidano trade-off e scope.
|
|
47
|
+
- `ai_docs/vision/features/`: Deve contenere una mini-vision per ogni feature significativa.
|
|
48
|
+
- `ai_docs/strategic/architecture.md`: Deve seguire questa struttura:
|
|
49
|
+
- `# Architettura del Progetto`
|
|
50
|
+
- `## Stack Tecnologico`
|
|
51
|
+
- `## Struttura delle Directory`
|
|
47
52
|
- `## Pattern Architetturali`
|
|
48
53
|
- `ai_docs/strategic/existing_features.md`: Deve seguire questa struttura:
|
|
49
54
|
- `# Funzionalità Esistenti`
|
|
50
55
|
- Elenco puntato nel formato: `- [ID] **Nome Feature**: Descrizione`
|
|
51
|
-
- `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]`.
|
|
52
|
-
|
|
53
|
-
### 2.
|
|
54
|
-
|
|
55
|
-
-
|
|
56
|
-
-
|
|
57
|
-
|
|
58
|
-
- `##
|
|
59
|
-
- `##
|
|
60
|
-
- `##
|
|
61
|
-
- `##
|
|
62
|
-
-
|
|
63
|
-
|
|
64
|
-
|
|
65
|
-
|
|
66
|
-
|
|
67
|
-
|
|
68
|
-
|
|
69
|
-
|
|
70
|
-
|
|
71
|
-
|
|
72
|
-
|
|
73
|
-
-
|
|
74
|
-
-
|
|
75
|
-
-
|
|
76
|
-
-
|
|
77
|
-
|
|
78
|
-
###
|
|
79
|
-
|
|
80
|
-
|
|
56
|
+
- `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]`.
|
|
57
|
+
|
|
58
|
+
### 2. Vision Gate
|
|
59
|
+
Prima di analizzare tecnicamente una nuova feature, modifica comportamentale o refactor significativo, ripristina il contesto di Vision:
|
|
60
|
+
- Leggi `ai_docs/vision/project_vision.md`, `ai_docs/vision/roadmap.md` e `ai_docs/vision/principles.md`.
|
|
61
|
+
- Se uno di questi documenti manca, è vuoto o non chiarisce l'obiettivo finale, crealo o aggiornalo prima di procedere.
|
|
62
|
+
- Per ogni feature significativa, crea o aggiorna `ai_docs/vision/features/VISION_[nome_feature].md` con:
|
|
63
|
+
- `## Problema`
|
|
64
|
+
- `## Beneficio Atteso`
|
|
65
|
+
- `## Utenti o Stakeholder`
|
|
66
|
+
- `## Segnali di Successo`
|
|
67
|
+
- `## Non-Obiettivi / Fuori Scope`
|
|
68
|
+
- `## Vincoli e Principi Collegati`
|
|
69
|
+
- Se la richiesta dell'utente confligge con Vision, non implementare in silenzio: esplicita il conflitto e proponi una scelta (aggiornare la Vision oppure modificare/rifiutare la richiesta).
|
|
70
|
+
|
|
71
|
+
### 3. Fase di Analisi della Richiesta
|
|
72
|
+
Per ogni nuova feature richiesta dall'utente:
|
|
73
|
+
- **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`.
|
|
74
|
+
- **Standalone:** Crea `ai_docs/solutions/ANALYSIS_[nome_feature].md`. Il documento deve obbligatoriamente seguire questa struttura:
|
|
75
|
+
- `# Analisi della Feature: [Nome Feature]`
|
|
76
|
+
- `## Obiettivo` (Cosa si vuole ottenere e quali problemi risolve)
|
|
77
|
+
- `## Allineamento alla Vision` (Quale Vision documenta il beneficio, quali non-obiettivi rispettare)
|
|
78
|
+
- `## Impatto` (Modifiche ai file esistenti, performance, nuove dipendenze)
|
|
79
|
+
- `## Piano d'Azione` (Elenco di task con checkbox `[ ]`)
|
|
80
|
+
- `## Strategia di Test` (Test unitari AAA, test d'integrazione, esempi)
|
|
81
|
+
- In entrambe le modalità, aggiungi la nuova feature in `ai_docs/strategic/features_history.md` con stato `[PLANNED]`.
|
|
82
|
+
|
|
83
|
+
### 4. Fase di Sviluppo e Test
|
|
84
|
+
Solo dopo aver completato le Fasi 2 e 3:
|
|
85
|
+
1. Aggiorna lo stato della feature in `features_history.md` a `[IN_PROGRESS]`.
|
|
86
|
+
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]`.
|
|
87
|
+
3. **Obbligatorio:** Scrivi i test automatici seguendo il pattern **AAA (Arrange, Act, Assert)**.
|
|
88
|
+
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.**
|
|
89
|
+
|
|
90
|
+
### 5. Fase di Chiusura
|
|
91
|
+
A completamento della feature (test passati con Exit Code 0):
|
|
92
|
+
- Verifica che il risultato consegnato rispetti `project_vision.md`, l'eventuale `VISION_[nome_feature].md` e i non-obiettivi dichiarati.
|
|
93
|
+
- **Hybrid:** Se la feature ha implicazioni di design, proponi un **ADR** tramite devPNT e aggiorna il Knowledge Layer (KL).
|
|
94
|
+
- **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.
|
|
95
|
+
- Aggiorna i documenti in `ai_docs/vision/` se l'implementazione ha modificato obiettivi, non-obiettivi, milestone, benefici attesi o segnali di successo.
|
|
96
|
+
- Riporta lo stato dei file appena rivisti in `ai_docs/audit/audit_plan.md` a `[ANALYZED]`.
|
|
97
|
+
- Aggiorna `features_history.md` impostando lo stato a `[COMPLETED]`.
|
|
98
|
+
|
|
99
|
+
### 6. Gestione delle Sessioni (Handoff)
|
|
100
|
+
Quando viene richiesto di mettere in pausa il lavoro o di chiudere la sessione:
|
|
101
|
+
- 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.
|