@autocode-cli/autocode 0.1.12 → 0.1.14

package/templates/prompts/review-consistency.en.md

@@ -12,12 +12,8 @@ Verify code integrates harmoniously with existing project architecture.
 4. Check error handling (uniform try/catch)
 5. Verify correct Pinia store usage
 6. Fix inconsistencies
-7. If out of scope work detected:
-   - Slightly out of scope (minor improvement, edge case): `autocode new "<title>" "<description>" -p P2 -l "<labels>" -a "<criteria>" -s patch -c ready`
-   - Significantly out of scope (new feature, major change): `autocode new "<title>" "<description>" -p P2 -l "<labels>" -a "<criteria>" -s patch`
-   - In scope: handle directly in current ticket
-8. Document: `autocode comment <ticket-key> "Review consistency OK"`
-9. Advance: `autocode next <ticket-key>`
+7. Document: `autocode comment <ticket-key> "Review consistency OK"`
+8. Advance: `autocode next <ticket-key>`
 
 > Or return: `autocode move <ticket-key> <target-column-slug>`
 

package/templates/prompts/review-consistency.fr.md

@@ -12,12 +12,8 @@ Verifier que le code s'integre harmonieusement avec l'architecture existante du
 4. Controler la gestion d'erreurs (try/catch uniforme)
 5. Verifier l'usage correct des stores Pinia
 6. Corriger les incoherences
-7. Si travail hors scope detecte :
-   - Legerement hors scope (amelioration mineure, cas limite) : `autocode new "<titre>" "<description>" -p P2 -l "<labels>" -a "<criteres>" -s patch -c ready`
-   - Tres hors scope (nouvelle feature, changement majeur) : `autocode new "<titre>" "<description>" -p P2 -l "<labels>" -a "<criteres>" -s patch`
-   - Dans le scope : traiter directement dans le ticket actuel
-8. Documenter : `autocode comment <ticket-key> "Review consistency OK"`
-9. Avancer : `autocode next <ticket-key>`
+7. Documenter : `autocode comment <ticket-key> "Review consistency OK"`
+8. Avancer : `autocode next <ticket-key>`
 
 > Ou retour : `autocode move <ticket-key> <target-column-slug>`
 

package/templates/prompts/review-no-duplication.en.md

@@ -12,12 +12,8 @@ Identify and eliminate code duplication. Factor into reusable functions/composab
 4. Detect copy-pasted business logic
 5. Extract to composable/service/shared function if >2 usages
 6. Update all existing calls
-7. If out of scope work detected:
-   - Slightly out of scope (minor improvement, edge case): `autocode new "<title>" "<description>" -p P2 -l "<labels>" -a "<criteria>" -s patch -c ready`
-   - Significantly out of scope (new feature, major change): `autocode new "<title>" "<description>" -p P2 -l "<labels>" -a "<criteria>" -s patch`
-   - In scope: handle directly in current ticket
-8. Document: `autocode comment <ticket-key> "Review no duplication OK"`
-9. Advance: `autocode next <ticket-key>`
+7. Document: `autocode comment <ticket-key> "Review no duplication OK"`
+8. Advance: `autocode next <ticket-key>`
 
 > Or return: `autocode move <ticket-key> <target-column-slug>`
 

package/templates/prompts/review-no-duplication.fr.md

@@ -12,12 +12,8 @@ Identifier et eliminer la duplication de code. Factoriser en fonctions/composabl
 4. Detecter la logique metier copiee-collee
 5. Extraire en composable/service/fonction partagee si >2 usages
 6. Mettre a jour tous les appels existants
-7. Si travail hors scope detecte :
-   - Legerement hors scope (amelioration mineure, cas limite) : `autocode new "<titre>" "<description>" -p P2 -l "<labels>" -a "<criteres>" -s patch -c ready`
-   - Tres hors scope (nouvelle feature, changement majeur) : `autocode new "<titre>" "<description>" -p P2 -l "<labels>" -a "<criteres>" -s patch`
-   - Dans le scope : traiter directement dans le ticket actuel
-8. Documenter : `autocode comment <ticket-key> "Review no duplication OK"`
-9. Avancer : `autocode next <ticket-key>`
+7. Documenter : `autocode comment <ticket-key> "Review no duplication OK"`
+8. Avancer : `autocode next <ticket-key>`
 
 > Ou retour : `autocode move <ticket-key> <target-column-slug>`
 

package/templates/prompts/review-security.en.md

@@ -14,8 +14,8 @@ Security audit. Identify and fix potential vulnerabilities (OWASP Top 10).
 6. Audit API calls (injection, XSS)
 7. Fix vulnerabilities
 8. If out of scope work detected:
-   - Slightly out of scope (minor improvement, edge case): `autocode new "<title>" "<description>" -p P2 -l "<labels>" -a "<criteria>" -s patch -c ready`
-   - Significantly out of scope (new feature, major change): `autocode new "<title>" "<description>" -p P2 -l "<labels>" -a "<criteria>" -s patch`
+   - Slightly out of scope (minor improvement, edge case): `autocode new "<title>" "<description>" --priority P2 --labels "<labels>" --acceptance "<criteria>" --semver patch --column ready`
+   - Significantly out of scope (new feature, major change): `autocode new "<title>" "<description>" --priority P2 --labels "<labels>" --acceptance "<criteria>" --semver patch --column backlog`
    - In scope: handle directly in current ticket
 9. Document: `autocode comment <ticket-key> "Review security OK"`
 10. Advance: `autocode next <ticket-key>`

package/templates/prompts/review-security.fr.md

@@ -14,8 +14,8 @@ Audit securite. Identifier et corriger les vulnerabilites potentielles (OWASP To
 6. Auditer les appels API (injection, XSS)
 7. Corriger les vulnerabilites
 8. Si travail hors scope detecte :
-   - Legerement hors scope (amelioration mineure, cas limite) : `autocode new "<titre>" "<description>" -p P2 -l "<labels>" -a "<criteres>" -s patch -c ready`
-   - Tres hors scope (nouvelle feature, changement majeur) : `autocode new "<titre>" "<description>" -p P2 -l "<labels>" -a "<criteres>" -s patch`
+   - Legerement hors scope (amelioration mineure, cas limite) : `autocode new "<titre>" "<description>" --priority P2 --labels "<labels>" --acceptance "<criteres>" --semver patch --column ready`
+   - Tres hors scope (nouvelle feature, changement majeur) : `autocode new "<titre>" "<description>" --priority P2 --labels "<labels>" --acceptance "<criteres>" --semver patch --column backlog`
    - Dans le scope : traiter directement dans le ticket actuel
 9. Documenter : `autocode comment <ticket-key> "Review security OK"`
 10. Avancer : `autocode next <ticket-key>`

package/templates/prompts/security-audit.en.md

@@ -0,0 +1,20 @@
+# npm Security Audit
+
+## Role
+Check for security vulnerabilities in project dependencies.
+
+## Actions
+1. Run `npm audit` to list vulnerabilities
+2. Analyze severity level (low, moderate, high, critical)
+3. For critical/high vulnerabilities, run `npm audit fix`
+4. If vulnerabilities persist, evaluate:
+   - Manual dependency update
+   - Replacement with alternative
+   - Risk acceptance with justification
+5. Document accepted vulnerabilities
+
+## Validation Criteria
+- [ ] `npm audit` executed
+- [ ] No critical vulnerabilities
+- [ ] No unaddressed high vulnerabilities
+- [ ] Accepted vulnerabilities documented

package/templates/prompts/security-audit.fr.md

@@ -0,0 +1,20 @@
+# Audit de sécurité npm
+
+## Rôle
+Vérifier les vulnérabilités de sécurité dans les dépendances du projet.
+
+## Actions
+1. Exécuter `npm audit` pour lister les vulnérabilités
+2. Analyser le niveau de sévérité (low, moderate, high, critical)
+3. Pour les vulnérabilités critiques/high, exécuter `npm audit fix`
+4. Si des vulnérabilités persistent, évaluer:
+   - Mise à jour manuelle de la dépendance
+   - Remplacement par une alternative
+   - Acceptation du risque avec justification
+5. Documenter les vulnérabilités acceptées
+
+## Critères de validation
+- [ ] `npm audit` exécuté
+- [ ] Aucune vulnérabilité critique (critical)
+- [ ] Aucune vulnérabilité haute (high) non traitée
+- [ ] Vulnérabilités acceptées documentées

package/templates/prompts/security-secrets.en.md

@@ -0,0 +1,26 @@
+# Secrets Detection
+
+## Role
+Verify no secrets or credentials are present in source code.
+
+## Actions
+1. Install gitleaks if missing:
+   ```bash
+   # or use npx @secretlint/secretlint
+   ```
+2. Scan repository:
+   ```bash
+   npx @secretlint/secretlint "**/*"
+   ```
+3. Check sensitive files:
+   - .env (must not be committed)
+   - Configuration files
+   - Templates
+4. Verify .gitignore includes sensitive files
+5. Scan git history if needed
+
+## Validation Criteria
+- [ ] No secrets detected in src/
+- [ ] .env in .gitignore
+- [ ] No hardcoded tokens/API keys
+- [ ] Clean git history

package/templates/prompts/security-secrets.fr.md

@@ -0,0 +1,26 @@
+# Détection des secrets
+
+## Rôle
+Vérifier qu'aucun secret ou credential n'est présent dans le code source.
+
+## Actions
+1. Installer gitleaks si absent:
+   ```bash
+   # ou utiliser npx @secretlint/secretlint
+   ```
+2. Scanner le repository:
+   ```bash
+   npx @secretlint/secretlint "**/*"
+   ```
+3. Vérifier les fichiers sensibles:
+   - .env (ne doit pas être commité)
+   - Fichiers de configuration
+   - Templates
+4. Vérifier .gitignore inclut les fichiers sensibles
+5. Scanner l'historique git si nécessaire
+
+## Critères de validation
+- [ ] Aucun secret détecté dans src/
+- [ ] .env dans .gitignore
+- [ ] Pas de tokens/clés API hardcodés
+- [ ] Historique git propre

package/templates/prompts/specification.en.md

@@ -13,8 +13,8 @@ Write detailed technical specifications for the ticket. Define the implementatio
 5. Specify API contracts if applicable
 6. Document edge cases and error handling
 7. If out of scope work detected:
-   - Slightly out of scope (minor improvement, edge case): `autocode new "<title>" "<description>" -p P2 -l "<labels>" -a "<criteria>" -s patch -c ready`
-   - Significantly out of scope (new feature, major change): `autocode new "<title>" "<description>" -p P2 -l "<labels>" -a "<criteria>" -s patch`
+   - Slightly out of scope (minor improvement, edge case): `autocode new "<title>" "<description>" --priority P2 --labels "<labels>" --acceptance "<criteria>" --semver patch --column ready`
+   - Significantly out of scope (new feature, major change): `autocode new "<title>" "<description>" --priority P2 --labels "<labels>" --acceptance "<criteria>" --semver patch --column backlog`
    - In scope: handle directly in current ticket
 8. Document: `autocode comment <ticket-key> "Specification complete: <technical approach>"`
 9. Advance: `autocode next <ticket-key>`

package/templates/prompts/specification.fr.md

@@ -13,8 +13,8 @@ Rediger les specifications techniques detaillees pour le ticket. Definir clairem
 5. Specifier les contrats API si applicable
 6. Documenter les cas limites et la gestion d'erreurs
 7. Si travail hors scope detecte :
-   - Legerement hors scope (amelioration mineure, cas limite) : `autocode new "<titre>" "<description>" -p P2 -l "<labels>" -a "<criteres>" -s patch -c ready`
-   - Tres hors scope (nouvelle feature, changement majeur) : `autocode new "<titre>" "<description>" -p P2 -l "<labels>" -a "<criteres>" -s patch`
+   - Legerement hors scope (amelioration mineure, cas limite) : `autocode new "<titre>" "<description>" --priority P2 --labels "<labels>" --acceptance "<criteres>" --semver patch --column ready`
+   - Tres hors scope (nouvelle feature, changement majeur) : `autocode new "<titre>" "<description>" --priority P2 --labels "<labels>" --acceptance "<criteres>" --semver patch --column backlog`
    - Dans le scope : traiter directement dans le ticket actuel
 8. Documenter : `autocode comment <ticket-key> "Specification terminee : <approche technique>"`
 9. Avancer : `autocode next <ticket-key>`

package/templates/prompts/splitter.en.md

@@ -18,12 +18,11 @@ If the task is small enough to be completed in one go, proceed directly without
 2. Identify natural boundaries between features, layers, or responsibilities
 3. Define clear acceptance criteria for each sub-ticket
 4. Ensure each split ticket is independently testable and deployable
-5. Create sub-tickets: `autocode new "<title>" "<description>" -p P2 -l "<labels>" -a "<criteria>" -s patch`
+5. Create sub-tickets: `autocode new "<title>" "<description>" --priority P2 --labels "<labels>" --acceptance "<criteria>" --semver patch --column backlog`
 6. Verify no functionality has been forgotten or duplicated across tickets
 7. Create an integration ticket that references all sub-tickets to validate cohesion
-8. If out of scope work detected: `autocode new "<title>" "<description>" -p P2 -l "<labels>" -a "<criteria>" -s patch`
-9. Document: `autocode comment <ticket-key> "[summary]"`
-10. Advance: `autocode next <ticket-key>`
+8. Document: `autocode comment <ticket-key> "[summary]"`
+9. Advance: `autocode next <ticket-key>`
 
 > Or return: `autocode move <ticket-key> <target-column-slug>`
 

package/templates/prompts/splitter.fr.md

@@ -18,12 +18,11 @@ Si la tâche est suffisamment petite pour être complétée en une fois, procéd
 2. Identifier les frontières naturelles entre fonctionnalités, couches ou responsabilités
 3. Définir des critères d'acceptation clairs pour chaque sous-ticket
 4. S'assurer que chaque ticket découpé est testable et déployable indépendamment
-5. Créer les sous-tickets : `autocode new "<title>" "<description>" -p P2 -l "<labels>" -a "<criteria>" -s patch`
+5. Créer les sous-tickets : `autocode new "<title>" "<description>" --priority P2 --labels "<labels>" --acceptance "<criteria>" --semver patch --column backlog`
 6. Vérifier qu'aucune fonctionnalité n'a été oubliée ou dupliquée entre les tickets
 7. Créer un ticket d'intégration qui référence tous les sous-tickets pour valider la cohésion
-8. Si travail hors scope détecté : `autocode new "<title>" "<description>" -p P2 -l "<labels>" -a "<criteria>" -s patch`
-9. Documenter : `autocode comment <ticket-key> "[résumé]"`
-10. Avancer : `autocode next <ticket-key>`
+8. Documenter : `autocode comment <ticket-key> "[résumé]"`
+9. Avancer : `autocode next <ticket-key>`
 
 > Ou retourner : `autocode move <ticket-key> <target-column-slug>`
 

package/templates/prompts/template-validation.en.md

@@ -0,0 +1,23 @@
+# Template Validation
+
+## Role
+Verify project templates are correct and functional.
+
+## Actions
+1. List templates in templates/
+2. For each template:
+   - Verify YAML/Markdown syntax
+   - Check placeholders
+   - Test generation with `autocode init`
+3. Verify generated structure:
+   - .autocode/
+   - .autocode/tickets/
+   - .autocode/config.yml
+   - pipeline.yml
+4. Test different configurations
+
+## Validation Criteria
+- [ ] All templates parse without errors
+- [ ] `autocode init` generates correct structure
+- [ ] Generated files are valid
+- [ ] No unreplaced placeholders

package/templates/prompts/template-validation.fr.md

@@ -0,0 +1,23 @@
+# Validation des templates
+
+## Rôle
+Vérifier que les templates de projet sont corrects et fonctionnels.
+
+## Actions
+1. Lister les templates dans templates/
+2. Pour chaque template:
+   - Vérifier la syntaxe YAML/Markdown
+   - Vérifier les placeholders
+   - Tester la génération avec `autocode init`
+3. Vérifier la structure générée:
+   - .autocode/
+   - .autocode/tickets/
+   - .autocode/config.yml
+   - pipeline.yml
+4. Tester différentes configurations
+
+## Critères de validation
+- [ ] Tous les templates parsent sans erreur
+- [ ] `autocode init` génère la bonne structure
+- [ ] Fichiers générés sont valides
+- [ ] Pas de placeholder non remplacé

package/templates/prompts/testing-coverage.en.md

@@ -0,0 +1,20 @@
+# Code Coverage
+
+## Role
+Measure and validate code coverage by unit tests.
+
+## Actions
+1. Run `npx vitest run --coverage`
+2. Analyze generated coverage report
+3. Identify files with insufficient coverage (<80%)
+4. Check coverage of critical modules:
+   - src/core/ (ticket.ts, column.ts, workflow.ts)
+   - src/server/api.ts
+   - src/services/
+5. Add tests for uncovered areas if needed
+
+## Validation Criteria
+- [ ] Global coverage >= 70%
+- [ ] Core modules covered at >= 80%
+- [ ] No critical files with 0% coverage
+- [ ] Coverage report generated without errors

package/templates/prompts/testing-coverage.fr.md

@@ -0,0 +1,20 @@
+# Couverture de code
+
+## Rôle
+Mesurer et valider la couverture de code par les tests unitaires.
+
+## Actions
+1. Exécuter `npx vitest run --coverage`
+2. Analyser le rapport de couverture généré
+3. Identifier les fichiers avec couverture insuffisante (<80%)
+4. Vérifier la couverture des modules critiques:
+   - src/core/ (ticket.ts, column.ts, workflow.ts)
+   - src/server/api.ts
+   - src/services/
+5. Ajouter des tests pour les zones non couvertes si nécessaire
+
+## Critères de validation
+- [ ] Couverture globale >= 70%
+- [ ] Modules core couverts à >= 80%
+- [ ] Aucun fichier critique avec 0% couverture
+- [ ] Rapport de couverture généré sans erreur

package/templates/prompts/testing-cypress.en.md

@@ -12,10 +12,7 @@ Write AND execute E2E automated tests to prevent regressions.
 4. Describe tests clearly (describe/it)
 5. Execute tests: npx cypress run
 6. If failures: fix tests or code
-7. If out of scope work detected:
-   - Slightly out of scope (minor improvement, edge case): `autocode new "<title>" "<description>" -p P2 -l "<labels>" -a "<criteria>" -s patch -c ready`
-   - Significantly out of scope (new feature, major change): `autocode new "<title>" "<description>" -p P2 -l "<labels>" -a "<criteria>" -s patch`
-   - In scope: handle directly in current ticket
+7. Do not write tests for code outside the ticket scope
 8. Document: `autocode comment <ticket-key> "Cypress tests OK"`
 9. Advance: `autocode next <ticket-key>`
 

package/templates/prompts/testing-cypress.fr.md

@@ -12,10 +12,7 @@ Rediger ET executer des tests E2E automatises pour prevenir les regressions.
 4. Decrire les tests clairement (describe/it)
 5. Executer les tests : npx cypress run
 6. Si echecs : corriger les tests ou le code
-7. Si travail hors scope detecte :
-   - Legerement hors scope (amelioration mineure, cas limite) : `autocode new "<titre>" "<description>" -p P2 -l "<labels>" -a "<criteres>" -s patch -c ready`
-   - Tres hors scope (nouvelle feature, changement majeur) : `autocode new "<titre>" "<description>" -p P2 -l "<labels>" -a "<criteres>" -s patch`
-   - Dans le scope : traiter directement dans le ticket actuel
+7. Ne pas ecrire de tests pour du code hors scope du ticket
 8. Documenter : `autocode comment <ticket-key> "Tests Cypress OK"`
 9. Avancer : `autocode next <ticket-key>`
 

package/templates/prompts/testing-integration.en.md

@@ -13,10 +13,7 @@ Run integration tests to verify components work correctly together. Ensure syste
 5. Test database operations
 6. Test external service connections
 7. Fix any failing tests
-8. If out of scope work detected:
-   - Slightly out of scope (minor improvement, edge case): `autocode new "<title>" "<description>" -p P2 -l "<labels>" -a "<criteria>" -s patch -c ready`
-   - Significantly out of scope (new feature, major change): `autocode new "<title>" "<description>" -p P2 -l "<labels>" -a "<criteria>" -s patch`
-   - In scope: handle directly in current ticket
+8. Do not write tests for code outside the ticket scope
 9. Document: `autocode comment <ticket-key> "Integration tests passed"`
 10. Advance: `autocode next <ticket-key>`
 

package/templates/prompts/testing-integration.fr.md

@@ -13,10 +13,7 @@ Executer les tests d'integration pour verifier que les composants fonctionnent c
 5. Tester les operations base de donnees
 6. Tester les connexions aux services externes
 7. Corriger les tests en echec
-8. Si travail hors scope detecte :
-   - Legerement hors scope (amelioration mineure, cas limite) : `autocode new "<titre>" "<description>" -p P2 -l "<labels>" -a "<criteres>" -s patch -c ready`
-   - Tres hors scope (nouvelle feature, changement majeur) : `autocode new "<titre>" "<description>" -p P2 -l "<labels>" -a "<criteres>" -s patch`
-   - Dans le scope : traiter directement dans le ticket actuel
+8. Ne pas ecrire de tests pour du code hors scope du ticket
 9. Documenter : `autocode comment <ticket-key> "Tests d'integration OK"`
 10. Avancer : `autocode next <ticket-key>`
 

package/templates/prompts/testing-playwright.en.md

@@ -12,10 +12,7 @@ Live functional testing with Playwright. Manually verify feature works by naviga
 4. Test edge cases
 5. Verify error handling
 6. Capture screenshots if needed
-7. If out of scope work detected:
-   - Slightly out of scope (minor improvement, edge case): `autocode new "<title>" "<description>" -p P2 -l "<labels>" -a "<criteria>" -s patch -c ready`
-   - Significantly out of scope (new feature, major change): `autocode new "<title>" "<description>" -p P2 -l "<labels>" -a "<criteria>" -s patch`
-   - In scope: handle directly in current ticket
+7. Do not test functionality outside the ticket scope
 8. Document: `autocode comment <ticket-key> "Playwright tests OK"`
 9. Advance: `autocode next <ticket-key>`
 

package/templates/prompts/testing-playwright.fr.md

@@ -12,10 +12,7 @@ Test fonctionnel live avec Playwright. Verifier manuellement que la feature fonc
 4. Tester les cas limites
 5. Verifier la gestion d'erreurs
 6. Capturer des screenshots si necessaire
-7. Si travail hors scope detecte :
-   - Legerement hors scope (amelioration mineure, cas limite) : `autocode new "<titre>" "<description>" -p P2 -l "<labels>" -a "<criteres>" -s patch -c ready`
-   - Tres hors scope (nouvelle feature, changement majeur) : `autocode new "<titre>" "<description>" -p P2 -l "<labels>" -a "<criteres>" -s patch`
-   - Dans le scope : traiter directement dans le ticket actuel
+7. Ne pas tester de fonctionnalites hors scope du ticket
 8. Documenter : `autocode comment <ticket-key> "Tests Playwright OK"`
 9. Avancer : `autocode next <ticket-key>`
 

package/templates/prompts/testing-unit.en.md

@@ -13,10 +13,7 @@ Write and run unit tests for the implemented feature. Ensure code coverage and r
 5. Run all unit tests: `npm test` or equivalent
 6. Fix any failing tests
 7. Verify coverage meets project standards
-8. If out of scope work detected:
-   - Slightly out of scope (minor improvement, edge case): `autocode new "<title>" "<description>" -p P2 -l "<labels>" -a "<criteria>" -s patch -c ready`
-   - Significantly out of scope (new feature, major change): `autocode new "<title>" "<description>" -p P2 -l "<labels>" -a "<criteria>" -s patch`
-   - In scope: handle directly in current ticket
+8. Do not write tests for code outside the ticket scope
 9. Document: `autocode comment <ticket-key> "Unit tests passed: <coverage>%"`
 10. Advance: `autocode next <ticket-key>`
 

package/templates/prompts/testing-unit.fr.md

@@ -13,10 +13,7 @@ Ecrire et executer les tests unitaires pour la fonctionnalite implementee. Assur
 5. Executer tous les tests unitaires : `npm test` ou equivalent
 6. Corriger les tests en echec
 7. Verifier que la couverture respecte les standards du projet
-8. Si travail hors scope detecte :
-   - Legerement hors scope (amelioration mineure, cas limite) : `autocode new "<titre>" "<description>" -p P2 -l "<labels>" -a "<criteres>" -s patch -c ready`
-   - Tres hors scope (nouvelle feature, changement majeur) : `autocode new "<titre>" "<description>" -p P2 -l "<labels>" -a "<criteres>" -s patch`
-   - Dans le scope : traiter directement dans le ticket actuel
+8. Ne pas ecrire de tests pour du code hors scope du ticket
 9. Documenter : `autocode comment <ticket-key> "Tests unitaires OK : <couverture>%"`
 10. Avancer : `autocode next <ticket-key>`
 

package/templates/prompts/testing-vitest.en.md

@@ -0,0 +1,17 @@
+# Vitest Unit Tests
+
+## Role
+Run unit tests with Vitest and ensure sufficient coverage.
+
+## Actions
+1. Run `npm run test` or `npx vitest run`
+2. Verify all tests pass
+3. Analyze failed tests if any
+4. Check configuration in vitest.config.ts
+5. Identify modules not covered by tests
+
+## Validation Criteria
+- [ ] `npm run test` runs without errors
+- [ ] All tests pass (0 failures)
+- [ ] src/**/*.test.ts files are executed
+- [ ] No regressions introduced

package/templates/prompts/testing-vitest.fr.md

@@ -0,0 +1,17 @@
+# Tests unitaires Vitest
+
+## Rôle
+Exécuter les tests unitaires avec Vitest et s'assurer que la couverture est suffisante.
+
+## Actions
+1. Exécuter `npm run test` ou `npx vitest run`
+2. Vérifier que tous les tests passent
+3. Analyser les tests échoués le cas échéant
+4. Vérifier la configuration dans vitest.config.ts
+5. Identifier les modules non couverts par les tests
+
+## Critères de validation
+- [ ] `npm run test` s'exécute sans erreur
+- [ ] Tous les tests passent (0 échec)
+- [ ] Les fichiers src/**/*.test.ts sont exécutés
+- [ ] Aucune régression introduite

package/templates/prompts/typecheck.en.md

@@ -0,0 +1,17 @@
+# TypeScript Type Checking
+
+## Role
+Validate that TypeScript code compiles without errors with strict options enabled (strict, noImplicitAny, strictNullChecks, etc.).
+
+## Actions
+1. Run `npx tsc --noEmit` to check types without generating files
+2. Analyze compilation errors if any
+3. Verify tsconfig.json maintains strict options
+4. Identify unjustified `any` usages
+5. Fix detected type errors
+
+## Validation Criteria
+- [ ] `npx tsc --noEmit` runs without errors
+- [ ] No implicit `any` in code
+- [ ] All strict options enabled in tsconfig.json
+- [ ] Types properly defined in src/types/

package/templates/prompts/typecheck.fr.md

@@ -0,0 +1,17 @@
+# Vérification des types TypeScript
+
+## Rôle
+Valider que le code TypeScript compile sans erreur avec les options strictes activées (strict, noImplicitAny, strictNullChecks, etc.).
+
+## Actions
+1. Exécuter `npx tsc --noEmit` pour vérifier les types sans générer de fichiers
+2. Analyser les erreurs de compilation s'il y en a
+3. Vérifier que tsconfig.json maintient les options strictes
+4. Identifier les usages de `any` non justifiés
+5. Corriger les erreurs de types détectées
+
+## Critères de validation
+- [ ] `npx tsc --noEmit` s'exécute sans erreur
+- [ ] Aucun `any` implicite dans le code
+- [ ] Toutes les options strictes sont activées dans tsconfig.json
+- [ ] Les types sont correctement définis dans src/types/

package/templates/prompts/update-docs.en.md

@@ -11,12 +11,8 @@ Document changes for future developers and users.
 3. Document new features
 4. Update existing guides if impacted
 5. Verify doc consistency
-6. If out of scope work detected:
-   - Slightly out of scope (minor improvement, edge case): `autocode new "<title>" "<description>" -p P2 -l "<labels>" -a "<criteria>" -s patch -c ready`
-   - Significantly out of scope (new feature, major change): `autocode new "<title>" "<description>" -p P2 -l "<labels>" -a "<criteria>" -s patch`
-   - In scope: handle directly in current ticket
-7. Document: `autocode comment <ticket-key> "Documentation updated"`
-8. Advance: `autocode next <ticket-key>`
+6. Document: `autocode comment <ticket-key> "Documentation updated"`
+7. Advance: `autocode next <ticket-key>`
 
 > Or return: `autocode move <ticket-key> <target-column-slug>`
 

package/templates/prompts/update-docs.fr.md

@@ -11,12 +11,8 @@ Documenter les changements pour les futurs developpeurs et utilisateurs.
 3. Documenter les nouvelles features
 4. Mettre a jour les guides existants si impactes
 5. Verifier la coherence de la doc
-6. Si travail hors scope detecte :
-   - Legerement hors scope (amelioration mineure, cas limite) : `autocode new "<titre>" "<description>" -p P2 -l "<labels>" -a "<criteres>" -s patch -c ready`
-   - Tres hors scope (nouvelle feature, changement majeur) : `autocode new "<titre>" "<description>" -p P2 -l "<labels>" -a "<criteres>" -s patch`
-   - Dans le scope : traiter directement dans le ticket actuel
-7. Documenter : `autocode comment <ticket-key> "Documentation mise a jour"`
-8. Avancer : `autocode next <ticket-key>`
+6. Documenter : `autocode comment <ticket-key> "Documentation mise a jour"`
+7. Avancer : `autocode next <ticket-key>`
 
 > Ou retour : `autocode move <ticket-key> <target-column-slug>`
 

package/templates/prompts/version-semver.en.md

@@ -0,0 +1,20 @@
+# Semantic Versioning
+
+## Role
+Validate version follows semver format and is consistent.
+
+## Actions
+1. Check version in package.json (currently 0.1.13)
+2. Compare with latest git tag: `git describe --tags`
+3. Analyze changes since last version:
+   - Breaking changes → MAJOR (x.0.0)
+   - New features → MINOR (0.x.0)
+   - Bug fixes → PATCH (0.0.x)
+4. Verify consistency with CHANGELOG.md
+5. Use `just new-tag` to create tag if needed
+
+## Validation Criteria
+- [ ] package.json version in semver format
+- [ ] Git tag matches version
+- [ ] Bump type consistent with changes
+- [ ] CHANGELOG updated

package/templates/prompts/version-semver.fr.md

@@ -0,0 +1,20 @@
+# Versioning sémantique
+
+## Rôle
+Valider que la version suit le format semver et est cohérente.
+
+## Actions
+1. Vérifier la version dans package.json (actuellement 0.1.13)
+2. Comparer avec le dernier tag git: `git describe --tags`
+3. Analyser les changements depuis la dernière version:
+   - Breaking changes → MAJOR (x.0.0)
+   - Nouvelles fonctionnalités → MINOR (0.x.0)
+   - Corrections de bugs → PATCH (0.0.x)
+4. Vérifier cohérence avec CHANGELOG.md
+5. Utiliser `just new-tag` pour créer un tag si nécessaire
+
+## Critères de validation
+- [ ] Version package.json au format semver
+- [ ] Tag git correspond à la version
+- [ ] Type de bump cohérent avec les changements
+- [ ] CHANGELOG mis à jour

package/templates/prompts/websocket-test.en.md

@@ -0,0 +1,19 @@
+# WebSocket Test
+
+## Role
+Verify WebSocket connection works for real-time updates.
+
+## Actions
+1. Start server with WebSocket enabled
+2. Connect to WebSocket: `ws://localhost:3456/ws`
+3. Verify connection message received
+4. Create/modify a ticket via API
+5. Verify event received via WebSocket
+6. Test automatic reconnection
+7. Check performance with multiple clients
+
+## Validation Criteria
+- [ ] WebSocket connection established
+- [ ] Messages received in real-time
+- [ ] JSON event format correct
+- [ ] No memory leak on multiple connections