cc-ship 0.0.7 → 0.0.8

package/skills/ship-shaping/SKILL.md

@@ -1,151 +1,151 @@
----
-name: ship-shaping
-description: "Templates et guidelines pour le shaping de packages en scopes indépendants"
-user-invocable: false
----
-
-# Skill: Shaping
-
-Ce skill fournit les templates et guidelines pour la phase de shaping : planifier UN package en scopes indépendants avec critères de vérification.
-
-## Ce que produit le Shaper
-
-Le Shaper prend un package du mapping et produit sa planification détaillée :
-
-```
-.ship/packages/<nom-package>/
-├── package.md       # Vision, scopes, truths, artifacts, key links
-└── verification.md  # Critères de vérification par scope
-```
-
-**L'Executor viendra ensuite** implémenter scope par scope.
-
-## Templates disponibles
-
-Les templates sont dans le skill `ship-writing` :
-
-| Template | Description | Fichier |
-|----------|-------------|---------|
-| **Package** | Planification du package en scopes | `skills/ship-writing/templates/package.md` |
-| **Verification** | Critères de vérification | `skills/ship-writing/templates/verification.md` |
-
-## Principes de shaping v2
-
-### 1. UN package à la fois
-
-Le Shaper se concentre sur UN seul package. Pour shaper un autre package, on relance l'agent.
-
-### 2. Scopes indépendants
-
-Chaque scope doit être :
-- **Déployable seul** : apporte de la valeur en soi
-- **Vérifiable seul** : pas besoin du scope suivant pour valider
-- **Ordonné** : le scope N+1 peut dépendre de N, jamais l'inverse
-
-### 3. Must-haves explicites
-
-Pour chaque scope, on définit :
-- **Truths** : comportements observables ("l'utilisateur peut...")
-- **Artifacts** : fichiers/composants à créer
-- **Key links** : connexions critiques entre éléments
-
-### 4. Not included explicite
-
-Ce qui est hors périmètre doit être documenté pour éviter le scope creep.
-
-### 5. Critères de vérification
-
-Chaque scope a des critères de vérification :
-- **auto** : vérifiable par l'agent (tests, lint, build)
-- **manual** : nécessite intervention humaine (UI, UX)
-- **blocking** / **warning** / **info** : niveau de sévérité
-
-## Bonnes pratiques
-
-### Pour les scopes
-
-- Commencer par le scope qui apporte le plus de valeur
-- Limiter à 3-5 truths par scope
-- Nommer les scopes par leur valeur utilisateur, pas par leur aspect technique
-
-### Pour les truths
-
-- Formuler en "L'utilisateur peut..." ou "Le système..."
-- Vérifiables objectivement
-- Granularité fine (pas de mega-truth)
-
-### Pour les artifacts
-
-- Lister les fichiers principaux, pas tous les fichiers
-- Inclure le chemin relatif complet
-- Décrire brièvement le rôle
-
-### Pour les key links
-
-- Se concentrer sur les connexions non-évidentes
-- Documenter le sens de la dépendance
-- Expliquer la nature (API, event, import...)
-
-### Pour les critères de vérification
-
-- Un critère = une vérification atomique
-- Préférer auto quand c'est possible
-- blocking pour les critères critiques uniquement
-
-## Workflow de shaping v2
-
-```
-Inputs globaux                    Package du mapping
-(prd.md, architecture.md,   +    (identifié dans mapping.md)
- requirements.md)
-        │                               │
-        └───────────────┬───────────────┘
-                        │
-                        ▼
-┌─────────────────────────────────────────┐
-│ 1. EXTRACTION                           │
-│    Extraire les exigences pertinentes   │
-│    pour CE package                      │
-└─────────────────────────────────────────┘
-                        │
-                        ▼
-┌─────────────────────────────────────────┐
-│ 2. DÉCOUPAGE EN SCOPES                  │
-│    Proposer les scopes                  │
-│    → Validation utilisateur             │
-└─────────────────────────────────────────┘
-                        │
-                        ▼
-┌─────────────────────────────────────────┐
-│ 3. MUST-HAVES                           │
-│    Pour chaque scope :                  │
-│    - Truths (comportements)             │
-│    - Artifacts (fichiers)               │
-│    - Key links (connexions)             │
-└─────────────────────────────────────────┘
-                        │
-                        ▼
-┌─────────────────────────────────────────┐
-│ 4. VÉRIFICATION                         │
-│    Définir les critères par scope       │
-│    (auto/manual, blocking/warning/info) │
-└─────────────────────────────────────────┘
-                        │
-                        ▼
-┌─────────────────────────────────────────┐
-│ 5. NOT INCLUDED                         │
-│    Expliciter ce qui est hors scope     │
-└─────────────────────────────────────────┘
-                        │
-                        ▼
-              package.md + verification.md
-```
-
-## Utilisation
-
-L'agent qui utilise ce skill doit :
-
-1. **Lire les templates** pour structurer ses outputs
-2. **Appliquer les principes** pour valider la qualité du shaping
-3. **Suivre le workflow** pour ne rien oublier
-4. **Valider les scopes** avec l'utilisateur avant de finaliser
+---
+name: ship-shaping
+description: "Templates et guidelines pour le shaping de packages en scopes indépendants"
+user-invocable: false
+---
+
+# Skill: Shaping
+
+Ce skill fournit les templates et guidelines pour la phase de shaping : planifier UN package en scopes indépendants avec critères de vérification.
+
+## Ce que produit le Shaper
+
+Le Shaper prend un package du mapping et produit sa planification détaillée :
+
+```
+.ship/packages/<nom-package>/
+├── package.md       # Vision, scopes, truths, artifacts, key links
+└── verification.md  # Critères de vérification par scope
+```
+
+**L'Executor viendra ensuite** implémenter scope par scope.
+
+## Templates disponibles
+
+Les templates sont dans le skill `ship-writing` :
+
+| Template | Description | Fichier |
+|----------|-------------|---------|
+| **Package** | Planification du package en scopes | `skills/ship-writing/templates/package.md` |
+| **Verification** | Critères de vérification | `skills/ship-writing/templates/verification.md` |
+
+## Principes de shaping v2
+
+### 1. UN package à la fois
+
+Le Shaper se concentre sur UN seul package. Pour shaper un autre package, on relance l'agent.
+
+### 2. Scopes indépendants
+
+Chaque scope doit être :
+- **Déployable seul** : apporte de la valeur en soi
+- **Vérifiable seul** : pas besoin du scope suivant pour valider
+- **Ordonné** : le scope N+1 peut dépendre de N, jamais l'inverse
+
+### 3. Must-haves explicites
+
+Pour chaque scope, on définit :
+- **Truths** : comportements observables ("l'utilisateur peut...")
+- **Artifacts** : fichiers/composants à créer
+- **Key links** : connexions critiques entre éléments
+
+### 4. Not included explicite
+
+Ce qui est hors périmètre doit être documenté pour éviter le scope creep.
+
+### 5. Critères de vérification
+
+Chaque scope a des critères de vérification :
+- **auto** : vérifiable par l'agent (tests, lint, build)
+- **manual** : nécessite intervention humaine (UI, UX)
+- **blocking** / **warning** / **info** : niveau de sévérité
+
+## Bonnes pratiques
+
+### Pour les scopes
+
+- Commencer par le scope qui apporte le plus de valeur
+- Limiter à 3-5 truths par scope
+- Nommer les scopes par leur valeur utilisateur, pas par leur aspect technique
+
+### Pour les truths
+
+- Formuler en "L'utilisateur peut..." ou "Le système..."
+- Vérifiables objectivement
+- Granularité fine (pas de mega-truth)
+
+### Pour les artifacts
+
+- Lister les fichiers principaux, pas tous les fichiers
+- Inclure le chemin relatif complet
+- Décrire brièvement le rôle
+
+### Pour les key links
+
+- Se concentrer sur les connexions non-évidentes
+- Documenter le sens de la dépendance
+- Expliquer la nature (API, event, import...)
+
+### Pour les critères de vérification
+
+- Un critère = une vérification atomique
+- Préférer auto quand c'est possible
+- blocking pour les critères critiques uniquement
+
+## Workflow de shaping v2
+
+```
+Inputs globaux                    Package du mapping
+(prd.md, architecture.md,   +    (identifié dans mapping.md)
+ requirements.md)
+        │                               │
+        └───────────────┬───────────────┘
+                        │
+                        ▼
+┌─────────────────────────────────────────┐
+│ 1. EXTRACTION                           │
+│    Extraire les exigences pertinentes   │
+│    pour CE package                      │
+└─────────────────────────────────────────┘
+                        │
+                        ▼
+┌─────────────────────────────────────────┐
+│ 2. DÉCOUPAGE EN SCOPES                  │
+│    Proposer les scopes                  │
+│    → Validation utilisateur             │
+└─────────────────────────────────────────┘
+                        │
+                        ▼
+┌─────────────────────────────────────────┐
+│ 3. MUST-HAVES                           │
+│    Pour chaque scope :                  │
+│    - Truths (comportements)             │
+│    - Artifacts (fichiers)               │
+│    - Key links (connexions)             │
+└─────────────────────────────────────────┘
+                        │
+                        ▼
+┌─────────────────────────────────────────┐
+│ 4. VÉRIFICATION                         │
+│    Définir les critères par scope       │
+│    (auto/manual, blocking/warning/info) │
+└─────────────────────────────────────────┘
+                        │
+                        ▼
+┌─────────────────────────────────────────┐
+│ 5. NOT INCLUDED                         │
+│    Expliciter ce qui est hors scope     │
+└─────────────────────────────────────────┘
+                        │
+                        ▼
+              package.md + verification.md
+```
+
+## Utilisation
+
+L'agent qui utilise ce skill doit :
+
+1. **Lire les templates** pour structurer ses outputs
+2. **Appliquer les principes** pour valider la qualité du shaping
+3. **Suivre le workflow** pour ne rien oublier
+4. **Valider les scopes** avec l'utilisateur avant de finaliser

package/skills/ship-writing/SKILL.md

@@ -1,152 +1,152 @@
----
-name: ship-writing
-description: "Guidelines de style pour la rédaction de documents markdown"
-user-invocable: false
----
-
-# Skill: Writing
-
-Ce skill fournit des guidelines de style pour la rédaction de documents markdown cohérents et professionnels.
-
-## Principes généraux
-
-### Clarté avant tout
-- Une idée par phrase
-- Un sujet par paragraphe
-- Éviter le jargon inutile
-- Préférer les mots simples aux mots complexes
-
-### Structure hiérarchique
-- Utiliser les niveaux de titres (`#`, `##`, `###`) de manière logique
-- Ne pas sauter de niveau (pas de `###` après `#`)
-- Maximum 3-4 niveaux de profondeur
-
-### Concision
-- Aller droit au but
-- Supprimer les mots inutiles
-- "En raison du fait que" → "Parce que"
-- "Dans le but de" → "Pour"
-
-## Formatage markdown
-
-### Titres
-```markdown
-# Titre principal (un seul par document)
-
-## Section majeure
-
-### Sous-section
-
-#### Détail (utiliser avec parcimonie)
-```
-
-### Listes
-- Utiliser `-` pour les listes non ordonnées
-- Utiliser `1.` pour les listes ordonnées
-- Indenter avec 2 espaces pour les sous-listes
-
-```markdown
-- Premier item
-  - Sous-item
-  - Autre sous-item
-- Deuxième item
-
-1. Étape 1
-2. Étape 2
-3. Étape 3
-```
-
-### Emphase
-- **Gras** pour les concepts importants
-- *Italique* pour les termes techniques ou citations
-- `Code inline` pour les commandes, noms de fichiers, variables
-
-### Code blocks
-Toujours spécifier le langage :
-
-```markdown
-```javascript
-const example = "Hello";
-```
-```
-
-### Tableaux
-Pour les comparaisons et données structurées :
-
-```markdown
-| Colonne 1 | Colonne 2 |
-|-----------|-----------|
-| Valeur 1  | Valeur 2  |
-```
-
-### Citations
-Pour les insights ou références importantes :
-
-```markdown
-> Citation importante ou insight clé
-```
-
-## Style de rédaction
-
-### Ton
-- **Professionnel** : pas de familiarité excessive
-- **Direct** : pas de formules alambiquées
-- **Actionnable** : le lecteur sait quoi faire après avoir lu
-
-### Voix active vs passive
-- Préférer la voix active : "L'utilisateur clique" vs "Le bouton est cliqué"
-- La voix passive est acceptable pour les descriptions techniques
-
-### Formulations à éviter
-| Éviter | Préférer |
-|--------|----------|
-| "Il est important de noter que..." | Aller directement au point |
-| "Comme mentionné précédemment..." | Répéter l'info si nécessaire |
-| "En conclusion..." | Conclure directement |
-| "Etc." | Lister explicitement ou utiliser "..." |
-
-## Templates disponibles
-
-| Template | Description | Fichier |
-|----------|-------------|---------|
-| **Brief** | L'idée structurée (output Brainstormer) | [brief.md](templates/brief.md) |
-| **PRD** | Product Requirements Document (output Brainstormer PRD) | [prd.md](templates/prd.md) |
-| **Requirements** | Software Requirements Specification (output Specifier) | [requirements.md](templates/requirements.md) |
-| **Architecture** | Architecture technique (output Architect) | [architecture.md](templates/architecture.md) |
-| **Mapping** | Découpage en packages (output Splitter) | [mapping.md](templates/mapping.md) |
-| **Package** | Planification d'un package en scopes (output Shaper) | [package.md](templates/package.md) |
-| **Verification** | Critères de vérification par scope (output Shaper) | [verification.md](templates/verification.md) |
-
-## Structure des documents
-
-### Documentation technique
-```markdown
-# [Nom du composant/feature]
-
-## Description
-[Quoi et pourquoi]
-
-## Usage
-[Comment l'utiliser avec exemples]
-
-## API / Interface
-[Détails techniques]
-
-## Exemples
-[Code exemples]
-
-## Notes
-[Cas particuliers, limitations]
-```
-
-## Checklist de qualité
-
-Avant de finaliser un document :
-
-- [ ] Le titre reflète le contenu
-- [ ] La structure est logique et progressive
-- [ ] Pas de fautes d'orthographe/grammaire
-- [ ] Les listes sont cohérentes (même format)
-- [ ] Le code est correctement formaté
-- [ ] Les liens fonctionnent
-- [ ] Le document est actionnable (le lecteur sait quoi faire)
+---
+name: ship-writing
+description: "Guidelines de style pour la rédaction de documents markdown"
+user-invocable: false
+---
+
+# Skill: Writing
+
+Ce skill fournit des guidelines de style pour la rédaction de documents markdown cohérents et professionnels.
+
+## Principes généraux
+
+### Clarté avant tout
+- Une idée par phrase
+- Un sujet par paragraphe
+- Éviter le jargon inutile
+- Préférer les mots simples aux mots complexes
+
+### Structure hiérarchique
+- Utiliser les niveaux de titres (`#`, `##`, `###`) de manière logique
+- Ne pas sauter de niveau (pas de `###` après `#`)
+- Maximum 3-4 niveaux de profondeur
+
+### Concision
+- Aller droit au but
+- Supprimer les mots inutiles
+- "En raison du fait que" → "Parce que"
+- "Dans le but de" → "Pour"
+
+## Formatage markdown
+
+### Titres
+```markdown
+# Titre principal (un seul par document)
+
+## Section majeure
+
+### Sous-section
+
+#### Détail (utiliser avec parcimonie)
+```
+
+### Listes
+- Utiliser `-` pour les listes non ordonnées
+- Utiliser `1.` pour les listes ordonnées
+- Indenter avec 2 espaces pour les sous-listes
+
+```markdown
+- Premier item
+  - Sous-item
+  - Autre sous-item
+- Deuxième item
+
+1. Étape 1
+2. Étape 2
+3. Étape 3
+```
+
+### Emphase
+- **Gras** pour les concepts importants
+- *Italique* pour les termes techniques ou citations
+- `Code inline` pour les commandes, noms de fichiers, variables
+
+### Code blocks
+Toujours spécifier le langage :
+
+```markdown
+```javascript
+const example = "Hello";
+```
+```
+
+### Tableaux
+Pour les comparaisons et données structurées :
+
+```markdown
+| Colonne 1 | Colonne 2 |
+|-----------|-----------|
+| Valeur 1  | Valeur 2  |
+```
+
+### Citations
+Pour les insights ou références importantes :
+
+```markdown
+> Citation importante ou insight clé
+```
+
+## Style de rédaction
+
+### Ton
+- **Professionnel** : pas de familiarité excessive
+- **Direct** : pas de formules alambiquées
+- **Actionnable** : le lecteur sait quoi faire après avoir lu
+
+### Voix active vs passive
+- Préférer la voix active : "L'utilisateur clique" vs "Le bouton est cliqué"
+- La voix passive est acceptable pour les descriptions techniques
+
+### Formulations à éviter
+| Éviter | Préférer |
+|--------|----------|
+| "Il est important de noter que..." | Aller directement au point |
+| "Comme mentionné précédemment..." | Répéter l'info si nécessaire |
+| "En conclusion..." | Conclure directement |
+| "Etc." | Lister explicitement ou utiliser "..." |
+
+## Templates disponibles
+
+| Template | Description | Fichier |
+|----------|-------------|---------|
+| **Brief** | L'idée structurée (output Brainstormer) | [brief.md](templates/brief.md) |
+| **PRD** | Product Requirements Document (output Brainstormer PRD) | [prd.md](templates/prd.md) |
+| **Requirements** | Software Requirements Specification (output Specifier) | [requirements.md](templates/requirements.md) |
+| **Architecture** | Architecture technique (output Architect) | [architecture.md](templates/architecture.md) |
+| **Mapping** | Découpage en packages (output Splitter) | [mapping.md](templates/mapping.md) |
+| **Package** | Planification d'un package en scopes (output Shaper) | [package.md](templates/package.md) |
+| **Verification** | Critères de vérification par scope (output Shaper) | [verification.md](templates/verification.md) |
+
+## Structure des documents
+
+### Documentation technique
+```markdown
+# [Nom du composant/feature]
+
+## Description
+[Quoi et pourquoi]
+
+## Usage
+[Comment l'utiliser avec exemples]
+
+## API / Interface
+[Détails techniques]
+
+## Exemples
+[Code exemples]
+
+## Notes
+[Cas particuliers, limitations]
+```
+
+## Checklist de qualité
+
+Avant de finaliser un document :
+
+- [ ] Le titre reflète le contenu
+- [ ] La structure est logique et progressive
+- [ ] Pas de fautes d'orthographe/grammaire
+- [ ] Les listes sont cohérentes (même format)
+- [ ] Le code est correctement formaté
+- [ ] Les liens fonctionnent
+- [ ] Le document est actionnable (le lecteur sait quoi faire)