4NK/cursor
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Initial: desk + ncantu placeholder + per-project cursor configs

Browse Source 
**Motivations:**
- Centraliser les fichiers Cursor (rules, skills, agents, commands, hooks) par user et par projet

**Root causes:**
- N/A

**Correctifs:**
- N/A

**Evolutions:**
- desk: rules, skills-cursor, agents, commands, hooks, argv/hooks/mcp.json
- ncantu: README placeholder
- 4NK_node, algo, builazoo, ia_local, lecoffre_ng, lecoffre_ng_pprod, lecoffre_ng_test: .cursor contents

**Pages affectées:**
- cursor/desk/, cursor/ncantu/, cursor/<project>/
This commit is contained in:
Nicolas Cantu
2026-03-03 23:29:29 +01:00
commit 785868b53b
114 changed files with 6455 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

34
desk/agents/README.md Normal file
View File

@@ -0,0 +1,34 @@
# Subagents Cursor (niveau utilisateur)
Les subagents dans `~/.cursor/agents/` sont disponibles pour tous les projets de l'utilisateur.
## Tâches de fond (background tasks)
Un subagent avec `is_background: true` dans son frontmatter YAML est une **tâche de fond**.
### Fonctionnement
- **Foreground** : Bloque jusqu'à la fin. Retourne le résultat immédiatement. Pour les tâches séquentielles où le résultat est nécessaire.
- **Background** : Retourne immédiatement. Le subagent travaille en parallèle. Pour les tâches longues ou le travail en parallèle.
### Comportement des tâches de fond
1. **Lancement** : L'agent parent lance le subagent et reçoit immédiatement une réponse (sans attendre la fin).
2. **Exécution** : Le subagent s'exécute dans son propre contexte, isolé de la conversation principale.
3. **Sortie** : Les subagents en arrière-plan écrivent leur état dans `~/.cursor/subagents/`.
4. **Reprise** : L'agent parent peut reprendre un subagent après sa complétion via son ID pour continuer avec le contexte préservé.
### Invocation
- **Explicite** : `/fix-lint` dans le chat, ou « Utilise le subagent fix-lint pour corriger les erreurs de lint ».
- **Automatique** : L'agent peut déléguer au subagent si la description correspond à la tâche.
### Avantages des tâches de fond
- **Non bloquant** : La conversation principale reste disponible.
- **Parallélisme** : Plusieurs subagents peuvent tourner en même temps.
- **Isolation** : Le contexte lourd (logs lint, refactors) reste dans le subagent.
### Hooks associés
Les hooks dans `~/.cursor/hooks/` journalisent les événements (sessionStart, subagentStart, subagentStop, etc.) dans `~/.cursor/logs/hooks.log`. Le hook `subagentStop` ajoute un message de suivi quand fix-lint se termine.

31
desk/agents/deploy.md Normal file
View File

@@ -0,0 +1,31 @@
---
name: deploy
description: Lance le déploiement (test, pprod, prod). Use when deploy is requested.
model: inherit
is_background: false
---
# Déployer (test, pprod, prod)
Lance le déploiement via `deploy/scripts_v2/deploy.sh`.
## Usage
Spécifier l'environnement : `test`, `pprod` ou `prod`.
## Processus
1. Le script deploy.sh exécute un hook pre-deploy qui arrête (SIGTERM) les processus concurrents (lint, fix-lint, typecheck, turbopack) dont le cwd est dans le projet. Après déploiement, suggérer de relancer /fix-lint si nécessaire.
2. Vérifier que les modifications sont commitées (règle projet)
3. Exécuter `./deploy/scripts_v2/deploy.sh <env>`
4. En cas d'erreur : ne pas contourner ; analyser la cause, corriger puis retenter
## Options
- `--skipSetupHost` : ignorer setup-host (idempotent)
- `--checkLint` : activer lint/typecheck/build avant déploiement
## Référence
- `deploy/scripts_v2/deploy.sh`
- `docs/DEPLOYMENT.md`

71
desk/agents/fix-lint.md Normal file
View File

@@ -0,0 +1,71 @@
---
name: fix-lint
description: Corrige les erreurs de lint backend, frontend et ressources partagées. Use when lint errors need to be fixed across the monorepo.
model: inherit
is_background: true
---
# Corriger les erreurs de lint (backend, frontend, ressources)
Vérifie que les règles de lint n'ont pas été réduites ou desactivées dans les configurations et dans le code.
Corrige toutes les erreurs de lint du projet sans contournement ni désactivation des règles.
## Contrainte absolue
**NE JAMAIS modifier ni ce fichier ni aucun fichier dans `~/.cursor/`.** Ta tâche est UNIQUEMENT de corriger les erreurs de lint dans le code du projet (lecoffre-back-main, lecoffre-front-main, lecoffre-ressources-dev). Ne pas modifier ni améliorer la définition de cet agent.
## Première action obligatoire
Exécuter immédiatement `npm run lint` dans chaque application pour lister les erreurs. Ne pas modifier de fichiers avant d'avoir la liste des erreurs.
## Périmètre
- **Backend** : `lecoffre-back-main` — `npm run lint`
- **Frontend** : `lecoffre-front-main` — `npm run lint`
- **Ressources partagées** : `lecoffre-ressources-dev` — `npm run lint`
## Concurrence
Ne pas lancer si un déploiement est en cours. Si un déploiement est demandé pendant l'exécution, s'arrêter proprement. Voir docs/WORKFLOWS_AND_COMPONENTS.md §10.2.1.
## Processus
1. Exécuter `npm run lint` dans chaque application pour lister les erreurs
2. Corriger par lots de 10 erreurs maximum
3. Entre chaque lot : lancer un test de build/typecheck pour valider
4. Ne jamais contourner : pas de `eslint-disable`, pas de désactivation de règles
5. Appliquer les patterns du projet : extraction de helpers, découpage de fichiers, objets de configuration pour réduire les paramètres
## Règles applicables (docs/CODE_STANDARDS.md)
- max-lines : 250
- max-lines-per-function : 40
- max-params : 4
- max-depth : 4
- complexity : 8
- max-nested-callbacks : 3
- Autres règles du projet
## Stratégies de correction
Dans l'ordre:
1. Autres règles du projet
2. - **max-params** : regrouper dans un objet de configuration typé
3. - **complexity** : extraire des branches dans des fonctions dédiées
4. - **max-depth** : aplatir les imbrications avec early return
5. - **max-lines / max-lines-per-function** : extraire des helpers, découper en sous-composants
## Finalisation
- Si des variables ont été préfixées de "_" les supprimer et mettre à jour le code
- Si des mutualisations/contralisations/simplifications sont possibles fait le
- Si du texte peut être passsé sous i18n fait le
- Supprime le code mort.
- Lance le subagent `/docupdate`
## Références
- `docs/CODE_STANDARDS.md`
- `docs/OPERATIONS.md` (section Transition ESLint 250/40)
- `.cursor/rules/rules.mdc`

20
desk/argv.json Normal file
View File

@@ -0,0 +1,20 @@
// This configuration file allows you to pass permanent command line arguments to VS Code.
// Only a subset of arguments is currently supported to reduce the likelihood of breaking
// the installation.
//
// PLEASE DO NOT CHANGE WITHOUT UNDERSTANDING THE IMPACT
//
// NOTE: Changing this file requires a restart of VS Code.
{
// Use software rendering instead of hardware accelerated rendering.
// This can help in cases where you see rendering issues in VS Code.
// "disable-hardware-acceleration": true,
// Allows to disable crash reporting.
// Should restart the app if the value is changed.
"enable-crash-reporter": true,
// Unique id used for correlating crash reports sent from this instance.
// Do not edit this value.
"crash-reporter-id": "838e5b2a-0c44-4e24-aa81-ef447b6f9680"
}

208
desk/commands/audit-security.md Normal file
View File

@@ -0,0 +1,208 @@
---
model: inherit
---
# audit-security
You are an expert security audit agent specialized in identifying vulnerabilities and security risks. Apply systematic reasoning following OWASP guidelines and security best practices.
## Security Audit Principles
Before reviewing any code for security, you must methodically analyze:
### 1) Attack Surface Analysis
1.1) Identify all entry points (APIs, forms, file uploads, webhooks)
1.2) Map data flows from input to storage to output
1.3) Identify trust boundaries
1.4) List all external dependencies and their versions
1.5) Identify privileged operations
### 2) OWASP Top 10 Review
2.1) **Injection** (SQL, NoSQL, Command, LDAP)
- Are all queries parameterized?
- Is user input ever concatenated into queries?
- Are ORM queries safe from injection?
- Is shell command execution avoided with user input?
2.2) **Broken Authentication**
- Are passwords hashed with strong algorithms (bcrypt, Argon2)?
- Is MFA available for sensitive operations?
- Are session tokens secure (HttpOnly, Secure, SameSite)?
- Is there account lockout after failed attempts?
2.3) **Sensitive Data Exposure**
- Is sensitive data encrypted at rest and in transit?
- Are API keys, secrets in environment variables (not code)?
- Is PII properly protected?
- Are error messages generic (no stack traces in production)?
2.4) **XML External Entities (XXE)**
- Is XML parsing configured to disable external entities?
- Are safer data formats (JSON) used when possible?
2.5) **Broken Access Control**
- Are all endpoints properly authorized?
- Is there IDOR (Insecure Direct Object Reference) protection?
- Are CORS policies properly configured?
- Is principle of least privilege followed?
2.6) **Security Misconfiguration**
- Are default credentials changed?
- Are unnecessary features disabled?
- Are security headers set (CSP, X-Frame-Options, etc.)?
- Is HTTPS enforced?
2.7) **Cross-Site Scripting (XSS)**
- Is all user input escaped before rendering?
- Is Content Security Policy in place?
- Are dangerous functions (innerHTML, eval) avoided?
- Is input validated on both client and server?
2.8) **Insecure Deserialization**
- Is untrusted data ever deserialized?
- Are safe alternatives used (JSON instead of pickle)?
2.9) **Using Components with Known Vulnerabilities**
- Are dependencies up to date?
- Is there a process for security updates?
- Are vulnerability scanners in CI/CD?
2.10) **Insufficient Logging & Monitoring**
- Are security events logged?
- Are logs protected from tampering?
- Is there alerting for suspicious activity?
### 3) Risk Assessment
For each vulnerability found:
3.1) Severity: Critical / High / Medium / Low
3.2) Likelihood: How easy is it to exploit?
3.3) Impact: What's the damage if exploited?
3.4) Priority: Severity × Likelihood
### 4) Remediation Recommendations
4.1) Provide specific fix recommendations
4.2) Include code examples when possible
4.3) Reference security standards (OWASP, CWE)
4.4) Suggest defense-in-depth approaches
4.5) Prioritize fixes by risk level
### 5) Security Headers Checklist
- [ ] Strict-Transport-Security (HSTS)
- [ ] Content-Security-Policy
- [ ] X-Content-Type-Options: nosniff
- [ ] X-Frame-Options: DENY
- [ ] X-XSS-Protection: 1; mode=block
- [ ] Referrer-Policy
- [ ] Permissions-Policy
## Vulnerability Report Format
**[SEVERITY] Vulnerability Title**
- **Location**: File:Line or Endpoint
- **Description**: What is the vulnerability?
- **Impact**: What can an attacker do?
- **Reproduction**: Steps to exploit
- **Remediation**: How to fix it
- **References**: CWE, OWASP links
ou are an expert security audit agent specialized in identifying vulnerabilities and security risks. Apply systematic reasoning following OWASP guidelines and security best practices.
## Security Audit Principles
Before reviewing any code for security, you must methodically analyze:
### 1) Attack Surface Analysis
1.1) Identify all entry points (APIs, forms, file uploads, webhooks)
1.2) Map data flows from input to storage to output
1.3) Identify trust boundaries
1.4) List all external dependencies and their versions
1.5) Identify privileged operations
### 2) OWASP Top 10 Review
2.1) **Injection** (SQL, NoSQL, Command, LDAP)
- Are all queries parameterized?
- Is user input ever concatenated into queries?
- Are ORM queries safe from injection?
- Is shell command execution avoided with user input?
2.2) **Broken Authentication**
- Are passwords hashed with strong algorithms (bcrypt, Argon2)?
- Is MFA available for sensitive operations?
- Are session tokens secure (HttpOnly, Secure, SameSite)?
- Is there account lockout after failed attempts?
2.3) **Sensitive Data Exposure**
- Is sensitive data encrypted at rest and in transit?
- Are API keys, secrets in environment variables (not code)?
- Is PII properly protected?
- Are error messages generic (no stack traces in production)?
2.4) **XML External Entities (XXE)**
- Is XML parsing configured to disable external entities?
- Are safer data formats (JSON) used when possible?
2.5) **Broken Access Control**
- Are all endpoints properly authorized?
- Is there IDOR (Insecure Direct Object Reference) protection?
- Are CORS policies properly configured?
- Is principle of least privilege followed?
2.6) **Security Misconfiguration**
- Are default credentials changed?
- Are unnecessary features disabled?
- Are security headers set (CSP, X-Frame-Options, etc.)?
- Is HTTPS enforced?
2.7) **Cross-Site Scripting (XSS)**
- Is all user input escaped before rendering?
- Is Content Security Policy in place?
- Are dangerous functions (innerHTML, eval) avoided?
- Is input validated on both client and server?
2.8) **Insecure Deserialization**
- Is untrusted data ever deserialized?
- Are safe alternatives used (JSON instead of pickle)?
2.9) **Using Components with Known Vulnerabilities**
- Are dependencies up to date?
- Is there a process for security updates?
- Are vulnerability scanners in CI/CD?
2.10) **Insufficient Logging & Monitoring**
- Are security events logged?
- Are logs protected from tampering?
- Is there alerting for suspicious activity?
### 3) Risk Assessment
For each vulnerability found:
3.1) Severity: Critical / High / Medium / Low
3.2) Likelihood: How easy is it to exploit?
3.3) Impact: What's the damage if exploited?
3.4) Priority: Severity × Likelihood
### 4) Remediation Recommendations
4.1) Provide specific fix recommendations
4.2) Include code examples when possible
4.3) Reference security standards (OWASP, CWE)
4.4) Suggest defense-in-depth approaches
4.5) Prioritize fixes by risk level
### 5) Security Headers Checklist
- [ ] Strict-Transport-Security (HSTS)
- [ ] Content-Security-Policy
- [ ] X-Content-Type-Options: nosniff
- [ ] X-Frame-Options: DENY
- [ ] X-XSS-Protection: 1; mode=block
- [ ] Referrer-Policy
- [ ] Permissions-Policy
## Vulnerability Report Format
**[SEVERITY] Vulnerability Title**
- **Location**: File:Line or Endpoint
- **Description**: What is the vulnerability?
- **Impact**: What can an attacker do?
- **Reproduction**: Steps to exploit
- **Remediation**: How to fix it
- **References**: CWE, OWASP links

24
desk/commands/banch-align-update.md Normal file
View File

@@ -0,0 +1,24 @@
---
model: inherit
---
# banch-align-update
`<env>` la branche passée en paramètre.
On on veut aligner la branche actuelle sur `<env>` sans modifier `<env>` et que la branche locale actuelle pointe sur la meme branche locale et la brnche locale de `<env>` sur la branche distantede `<env>`.
Stash et aligne toi sur la branche `<env>`, avant liste les modifications qui seront stash (sans le rétablir) et attend une confirmation.
la locale branche actuelle doit etre: alignée sur les commits de `<env>`
sans changer de branche.
`<env>` : doit rester inchangée.
A la fin :
- la branche locale a été remise sur origin/`<meme nom>`, puis `<env>` a été mergée dans la branche locale.
- la branche locale pointe toujours sur la branche `<meme nom>` (ref refs/heads/`<meme nom>`).
- `<env>` pointe toujours sur la branche `<env>` (ref refs/heads/`<env>`).
- la branche locale test pointe sur la branche distante test
- la branche locale pprod pointe sur la branche distante pprod
- la branche locale prod pointe sur la branche distante prod

28
desk/commands/banch-align.md Normal file
View File

@@ -0,0 +1,28 @@
---
model: inherit
---
# banch-align
avec en paramètre `<env>`
sans mofidier la branche de `<env>`, sans quiter la branche de`<env>` aligne test et pprod et prod (sauf `<env>`) sur cette branche de `<env>` (meme code) et les branches locales test et pprod et prod doivent toujours pointer sur les branches distantes test et pprod et prod.
Pour le merge en cas de conflit : `<env>` est prioritaire.
Stash sans rétablir les modifications en cours sur une branche si elle cause ds conflits avec `<env>`.
A la fin :
origin/test, origin/pprod et origin/prod doivent avoir été mis à jour pour pointer sur le même commit que `<env>`.
Les branches locales test, pprod et prod ont été mises à jour pour suivre origin/test, origin/pprod et origin/prod.
L'utilisateur doit êre resté sur la branche `<env>`, qui n’aura pas été modifiée.
test, pprod, prod (locales et distantes) devront être au même commit.
Vérifie que les 30 derniers commits sont strictement équivalents.
- la branche locale pointe toujours sur la branche `<meme nom>` (ref refs/heads/`<meme nom>`).
- `<env>` pointe toujours sur la branche `<env>` (ref refs/heads/`<env>`).
- la branche locale test pointe sur la branche distante test
- la branche locale pprod pointe sur la branche distante pprod
- la branche locale prod pointe sur la branche distante prod

28
desk/commands/deploy.md Normal file
View File

@@ -0,0 +1,28 @@
---
model: inherit
---
# Déployer (test, pprod, prod)
Lance le déploiement via `deploy/scripts_v2/deploy.sh`.
## Usage
Spécifier l'environnement : `test`, `pprod` ou `prod`.
Exemple : `/deploy test` ou « Déploie sur test ».
## Processus
1. Vérifier que les modifications sont commitées (règle projet)
2. Exécuter `./deploy/scripts_v2/deploy.sh <env>`
3. En cas d'erreur : ne pas contourner ; analyser la cause, corriger puis retenter
## Options
- `--skipSetupHost` : ignorer setup-host (idempotent)
- `--checkLint` : activer lint/typecheck/build avant déploiement
## Référence
- `deploy/scripts_v2/deploy.sh`
- `docs/DEPLOYMENT.md`

52
desk/commands/docupdate.md Normal file
View File

@@ -0,0 +1,52 @@
---
model: inherit
---
# docupdate
## docs/features extract
Dans l'ordre et pour tous les documents de docs/features :
1) Extrait toutes les données pertinente des documents de docs/features et intègre les dans la documentation existante dans docs/
2) Supprimer tous les fichiers dans docs/features
## docs/fixKnowledge extract
Dans l'ordre et pour tous les documents de docs/fixKnowledge :
1) Extrait toutes les données pertinente des documents de docs/fixKnowledge et intègre les dans la documentation existante dans docs/
2) Supprimer tous les fichiers dans docs/fixKnowledge
## docs/ cleanup
Dans l'ordre et pour tous les documents de docs :
Documents à ne pas suppirmer lors des étapes suivantes :
* docs/API_IA.md
* docs/API.md
* docs/ARCHITECTURE.md
* docs/CLIENT_FOLDERS.md
* docs/CONFIGURATION_DOCUMENTS_SCHEMA.md
* docs/CONFIGURATION.md
* docs/DATAROOM_FOLDERS.md
* docs/DEPANNAGE.md
* docs/FONCTIONNALITES_ATTENDUES.md
* docs/QUALITE.md
* docs/RULES.md
* docs/SETUP.md
* docs/UX_UI_SPECIFICATIONS.md
* docs/WORKFLOWS.md
* docs/sources/*
* docs/fixKnowledge/*
* docs/features/*
1) Réuni et optimise la documentation en maximum 20 documents markdown
2) Supprimer les informations fausses ou obsoletes
Ventille les infos de features dans la doc existante et ne créé pas de fichier FEATURES.md
Ventille les infos de fixknowledge dans la doc existante et ne créé pas de fichier FIXKNOWLEDGE.md

10
desk/commands/fix-lint.md Normal file
View File

@@ -0,0 +1,10 @@
---
model: inherit
---
# Corriger les erreurs de lint
Exécute le plan `~/.cursor/plans/workflow-fix-lint.plan.md`.
Lis le fichier plan. NE JAMAIS modifier les fichiers dans ~/.cursor/. Corriger UNIQUEMENT le code du projet (lecoffre-back-main, lecoffre-front-main, lecoffre-ressources-dev).
**Concurrence** : Ne pas lancer si un déploiement est en cours. Si un déploiement est demandé pendant l'exécution, s'arrêter proprement. Voir docs/WORKFLOWS_AND_COMPONENTS.md §10.2.1.

221
desk/commands/lintit.md Normal file
View File

@@ -0,0 +1,221 @@
---
model: inherit
---
# lintit
Vérifie toutes ces règles et liste les actions à mener.
## qualité du code
### Analyse préalable obligatoire et arbre des fichiers
Avant toute implémentation, une phase d’analyse est obligatoire et doit produire une représentation de l’arbre des fichiers pertinents.
Cette représentation sert à identifier :
* la documentations le plus souvent dans docs/
* le code à rutiliser et les héritages
* les modules déjà disponibles
* les points d’extension existants
* les abstractions en place
* les conventions d’architecture
* les zones attendues de factorisation
Aucun code nouveau ne doit être écrit tant que cette cartographie minimale n’a pas été produite et exploitée pour éviter toute duplication.
### Non-duplication et réutilisation systématique
Toute logique nouvelle déclenche une vérification explicite de réutilisation possible dans le code existant.
Sont considérés comme duplication à éviter :
* copier-coller de blocs
* variations mineures d’une même fonction
* traitements parallèles de cas similaires
* conversions de types répétées
* mappings répétés
* gestion d’erreurs répétée
* validations répétées
* constructions d’objets redondantes
Si un comportement est récurrent, il doit être refactoré dans une abstraction partagée : fonction utilitaire ciblée, service, composant, stratégie, adaptateur ou classe de base, selon l’architecture.
Toute extraction doit préserver la lisibilité et la cohésion, sans créer d’utilitaires génériques sans responsabilité claire. Une réutilisation ne doit ni introduire de dépendance circulaire ni dégrader la modularité.
### Généricité et isolation des exceptions sans duplication
Le comportement par défaut doit être modélisé de façon générique. Les cas particuliers doivent être isolés dans des unités dédiées, sans répliquer le flux principal.
Les exceptions métier ou techniques doivent être représentées par :
* des types d’erreurs explicites
* des branches clairement identifiées
* des stratégies remplaçables ou des adaptateurs selon le besoin
Les variations doivent être injectées par inversion de dépendance plutôt que codées sous forme de conditions dispersées.
La règle est de minimiser le nombre d’endroits où un cas particulier est connu, idéalement un seul point de spécialisation.
### Design patterns et héritage
Les patterns doivent être employés uniquement lorsqu’ils clarifient le découpage et réduisent effectivement la duplication.
Les patterns attendus selon le contexte incluent notamment :
* Factory et Abstract Factory pour instancier selon le contexte sans cascade de conditions
* Strategy pour encapsuler des variations comportementales
* Template Method pour définir un squelette d’algorithme stable avec points d’extension
* Adapter pour interfacer une dépendance externe sans contaminer le domaine
* Decorator pour enrichir un comportement sans abus d’héritage
* Command pour formaliser des actions et leurs paramètres
* Repository ou Gateway pour l’accès aux données ou services externes
L’héritage est autorisé lorsqu’il représente une relation stable de type est-un, avec un contrat clair, et qu’il évite une duplication réelle.
Il est interdit d’utiliser l’héritage pour partager des détails d’implémentation instables ou pour créer une hiérarchie artificielle.
La composition est privilégiée lorsque les variations sont nombreuses ou lorsque des comportements combinables sont requis.
Toute hiérarchie doit rester courte, compréhensible, testable, et ne pas masquer les dépendances.
### Gestion des erreurs, traçabilité et journalisation
Tout cas d’erreur doit être journalisé.
Sont inclus :
* erreurs de validation
* erreurs d’entrée-sortie
* erreurs réseau
* erreurs de parsing
* états impossibles
* erreurs de dépendances externes
* timeouts
* conflits
* violations d’invariants
La journalisation doit être structurée et inclure le niveau, le contexte, les identifiants pertinents, la cause, la stack lorsque disponible, et uniquement des données non sensibles.
Les messages doivent permettre un diagnostic en production sans reproduction systématique.
Aucune erreur ne doit être ignorée silencieusement.
Les erreurs doivent remonter avec un type explicite et, si nécessaire, être enrichies par un contexte supplémentaire sans perdre la cause originelle.
Les logs doivent respecter les conventions du projet, notamment l’usage d’un logger centralisé, les mécanismes de corrélation et les formats imposés. L’usage direct de `console.log` est interdit si un système de journalisation est déjà en place.
### Interdiction de fallback
Aucun mécanisme de fallback implicite ne doit être introduit.
Sont considérés comme fallback interdits :
* l’utilisation de valeurs par défaut pour masquer une erreur
* l’attrapage d’une erreur suivi d’une poursuite silencieuse
* le déclenchement d’une voie alternative non explicitement spécifiée
* toute dégradation silencieuse de la qualité, de la sécurité ou de la cohérence
tout fallback et placeholders doivent etre validés avant implémentation
Si un comportement alternatif est requis fonctionnellement, il doit être explicitement défini comme un chemin nominal, avec des conditions d’activation claires, un typage explicite et une observabilité complète.
En l’absence de spécification explicite d’alternative, l’erreur doit être remontée et journalisée.
### Interdiction de facilités pour l’IA et anti-optimisations artificielles
Aucune implémentation ne doit être simplifiée pour satisfaire uniquement la compilation ou un cas minimal.
Sont interdits :
* stubs durables et non validés
* hacks temporaires laissés en place et non validés
* branches mortes et non validés
* TODO structurants non résolus et non validés
* implémentations partielles non signalées et non validés
* comportements best effort non spécifiés et non validés
L’optimisation pour l’IA elle-même est interdite. Le code ne doit pas être réorganisé pour faciliter la génération automatique au détriment de la cohérence du projet.
L’optimisation de performance n’est pas un objectif par défaut. Elle n’est permise que si un goulot est identifié, mesurable, documenté, et si l’amélioration ne dégrade ni la clarté ni la sécurité.
### Corrige toutes les erreurs des tests de lint
Sans contournement, ni desactivation des règles : corrige toutes les erreurs des tests de lint.
### Corrige toutes les warnings des tests de lint
Sans contournement, ni desactivation des règles : corrige toutes les warnings des tests de lint.
### Règles de lint par défaut
'''mjs
export default [
{
ignores: [
"dist/**",
"node_modules/**",
"coverage/**",
"logs/**",
"tmp/**",
"prisma/migrations/**",
"scripts/**",
"src/scripts/**",
"src/tests/**",
"src/test/**",
"tests/**",
"*.js",
"*.mjs",
"*.d.ts",
"**/*.svg",
"**/proofTemplate.ts",
"**/seeders/**",
],
},
...compat.config({
extends: ["plugin:@typescript-eslint/recommended", "prettier"],
parser: "@typescript-eslint/parser",
parserOptions: {
project: "./tsconfig.json",
tsconfigRootDir: __dirname,
ecmaVersion: 2022,
sourceType: "module",
},
plugins: ["@typescript-eslint"],
env: {
node: true,
es2022: true,
},
rules: {
"@typescript-eslint/no-explicit-any": "error",
"@typescript-eslint/no-unused-vars": [
"error",
{
argsIgnorePattern: "^*",
varsIgnorePattern: "^*",
},
],
"@typescript-eslint/explicit-function-return-type": "error",
"@typescript-eslint/explicit-module-boundary-types": "error",
"@typescript-eslint/no-non-null-assertion": "error",
"@typescript-eslint/no-require-imports": "error",
"no-console": "off",
"max-lines": [
"error",
{
max: 400,
skipBlankLines: true,
skipComments: true,
},
],
"max-lines-per-function": [
"error",
{
max: 60,
skipBlankLines: true,
skipComments: true,
},
],
},
}),
];
'''

64
desk/commands/pousse.md Normal file
View File

@@ -0,0 +1,64 @@
---
model: inherit
---
# pousse
## When to use
- User asks to "commit", "push", "git add", or "save to git"
- After completing code changes and the user expects a commit
## Workflow
1. **Stage all changes**: `git add -A`
3. **Commit**: run `git commit -m "..."` with the approved message (use a single quoted multi-line string or `-F` with a temp file if the message is long).
4. **Push**: Run `git push` (or `git push origin <branch>` if the context specifies a branch). Do not trigger CI if the user's rules forbid it.
## Commit message format
Use this structure. Every commit must follow it. Sections can be omitted only when not applicable (e.g. no bug fix → no **Root causes:** or **Correctifs:**).
```text
Short descriptive title (one line)
**Motivations:**
- Reason for the change
**Root causes:**
- Root cause of the issue (if applicable, e.g. for fixes)
**Correctifs:**
- What was fixed
**Evolutions:**
- New features or improvements
**Pages affectées:**
- List of modified files or modules
```
- Prefer bullet points under each section; no need for totals (e.g. "X files modified").
- Write the body in the same language as the project (e.g. French if the repo uses French).
- Do not use `--no-verify` unless the user explicitly requests it and it is documented.
Important : je valide par avance le texte du commit ne le fait pas confirmer
## Commands (summary)
```bash
git add -A
git status # optional: show what will be committed
git commit -m "Title
**Motivations:**
- ...
**Correctifs:** / **Evolutions:** / **Pages affectées:** ..."
git push
```
## Notes
- On Windows, use Git Bash for shell commands when specified by the user.
- Do not run in background; run commands so the user sees the full output.
- If the user's rules say "do not trigger CI", use the push method that avoids triggering CI (e.g. push to a branch that does not run CI, or follow project docs).

14
desk/commands/science-redaction.md Normal file
View File

@@ -0,0 +1,14 @@
---
model: inherit
---
# science-redaction
dans /home/desk/code/algo/v0/conjoncture_collatz.md repasse sur toutes les règles suivantes sur tout le texte:
supprime les passages d'adressant au lecteur ou reformule les si il y a des informations pertinentes à la démonstration pour qu'ils soient plus correctes dans une démonstration scientifique et pas comme un discussion
de meme supprime les formules introspective de l'auteur ou reformule les si il y a des informations pertinentes à la démonstration pour qu'ils soient plus correctes dans une démonstration scientifique et pas comme un discussion ou un reflexion à soi meme
revoit les titres "## Introduction" pour être plus précis "## Introduction de ..."
revoit les titres "## Conclusion" pour être plus précis "## Conclusion de ..."
Vérifie que tous les Introduction et Conclusion ont bien le niveau "##" de titre
retire l'autosatisfaction et les phrase de type "@conjoncture_collatz.md (6351-6352) " comme si le chapitre ou la partie du texte était une réponse à une démande spécifique ou , les si il y a des informations pertinentes à la démonstration pour qu'ils soient plus correctes dans une démonstration scientifique
reformule par une introduction classique des étapes du chapitre en modifiant par exemple "La continuation “ainsi”..." c'est une réponse à "continue ainsi" qui n'a pas de sens dans la rédaction de la démonstration scientifique.
supprime les auto-satisfactions et reformule pour apporter strictement un apport utile à la démonstration.

227
desk/commands/scientifi-check.md Normal file
View File

@@ -0,0 +1,227 @@
---
model: inherit
---
# scientific-check
Vérifie toutes les règles suivantes :
Guide d’écriture scientifique — Démonstrations mathématiques (niveau recherche)
Périmètre : rédaction d’articles, preuves et travaux de recherche en mathématiques, avec un niveau d’exigence adapté à la recherche avancée.
---
## 1. Critères de validité et réfutabilité
Un cadre abstrait peut devenir invulnérable aux critiques s’il est trop flexible.
Trois critères sont adoptés :
- **Réfutabilité** : chaque affirmation doit pouvoir être contredite par un contre-exemple ou une condition explicite non remplie.
- **Indexation des conclusions** : toute conclusion quantitative doit être indexée par les choix qui la rendent possible (mesure de référence, coût, noyau de transition, quotient). Une conclusion « non indexée » n’est acceptée que si elle est invariantement structurelle.
- **Protocoles de robustesse** : lorsqu’une notion est sensible à des choix (par exemple la dominance d’un attracteur selon la mesure), la sensibilité devient un objet d’étude, au moyen de protocoles explicites (familles de mesures, familles de noyaux, variations contrôlées, comparaison multi-granularité).
---
## 2. Traçabilité des hypothèses
Chaque résultat doit indiquer les hypothèses exactes qui le rendent vrai : finitude, compacité, monotonie, existence d’une fermeture, présence d’un noyau probabiliste, choix d’une mesure.
### 2.1 Déclaration des dépendances
Toute conclusion quantitative doit être indexée par les choix qui la rendent possible (mesure de référence, coût, noyau de transition, quotient). Une conclusion « non indexée » n’est acceptée que si elle est invariantement structurelle.
### 2.2 Enchaînement hypothèses → résultat
- Avant chaque lemme, proposition ou théorème : énoncer explicitement les hypothèses utilisées dans la preuve.
- Dans la preuve : signaler à quel moment chaque hypothèse est utilisée (par renvoi à la numérotation ou au libellé).
- Éviter les hypothèses implicites ou « évidentes » non écrites.
---
## 3. Structure et forme du texte
### 3.1 Titres
- Les titres « Introduction » et « Conclusion » doivent être précisés : « Introduction de … », « Conclusion de … » (objet du chapitre ou de la section).
- Tous les titres d’Introduction et de Conclusion doivent être au niveau `##` (cohérence de la hiérarchie).
### 3.2 Ton et personne
- **Neutralité sémantique** : pas de phrases d’auto‑appréciation ni de jugement sur l’ouvrage, la méthode ou la qualité du travail. Pas d’auto‑promotion, pas d’auto‑évaluation, pas de justification éditoriale.
- **Pas d’adresse au lecteur** : supprimer les passages s’adressant au lecteur, ou les reformuler en énoncés factuels si l’information est pertinente pour la démonstration.
- **Pas de formules introspectives** : supprimer les formules où l’auteur parle de lui-même ou de sa démarche, ou les reformuler en énoncés neutres utiles à la preuve.
- **Pas d’auto-satisfaction** : supprimer les phrases du type « comme si le chapitre était une réponse à une demande spécifique » ou toute formulation auto-congratulante ; reformuler pour n’apporter que ce qui sert la démonstration.
### 3.3 Enchaînements
- Remplacer les enchaînements de type « La continuation “ainsi”… » (réponse à une injonction absente du texte) par une introduction classique des étapes du chapitre.
- Chaque paragraphe ou bloc doit s’enchaîner par le contenu mathématique (définition → lemme → application), pas par des formules méta (« continuons ainsi », « on poursuit de la même manière » sans précision).
### 3.4 Formulations autorisées
- Annonces factuelles et neutres : « On définit… », « On suppose… », « On montre… », « Il s’ensuit… ».
- Références structurelles si nécessaires : « voir Chapitre X », « d’après la Proposition Y », sans qualificatifs évaluatifs.
### 3.5 Formulations interdites
- Qualificatifs sur la qualité du texte : « contribution principale », « conceptuellement décisif », « important », « majeur », « robuste », « rigoureux », « ambitieux ».
- Justifications éditoriales : « le choix est volontairement… », « ce schéma est volontairement… », « cette section sert de verrou… », « priorité strictement… ».
- Toute phrase qui évalue le texte au lieu d’énoncer un fait mathématique.
---
## 4. Rédaction des preuves
### 4.1 Structure type d’une preuve
- Énoncé : hypothèses numérotées ou listées, énoncé du résultat.
- Preuve : étapes clairement séparées (par numérotation, sous-paragraphes ou symboles), avec renvoi aux définitions et résultats déjà établis.
- Pas de « il est facile de voir » ou « on laisse au lecteur » sans indication précise ; soit détailler, soit renvoyer à un lemme auxiliaire ou à la littérature avec référence.
### 4.2 Notation et définitions
- Chaque symbole ou notation non standard doit être défini avant usage.
- Réutiliser les conventions du domaine lorsqu’elles existent ; en cas d’écart, le signaler brièvement.
- Éviter les surcharges de notation : une même lettre ne doit pas désigner des objets différents dans un même bloc sans rappel.
### 4.3 Contrôle avant publication
- Relire la sortie et supprimer ou réécrire toute phrase qui (1) juge la qualité ou l’importance du texte, (2) qualifie un choix (« volontairement », « conservateur », etc.), (3) commente l’édition (« verrou », « discipline », etc.).
- En cas d’hésitation : reformuler en énoncé purement descriptif ou supprimer.
---
## 5. Protocole de relecture (application à un document)
Pour appliquer ce guide à un texte existant (ex. `v0/conjoncture_collatz.md`) :
1. **Parcourir tout le texte** en vérifiant chaque règle ci-dessus.
2. **Supprimer ou reformuler** :
- les passages s’adressant au lecteur (ou les reformuler en énoncés factuels utiles à la démonstration) ;
- les formules introspectives de l’auteur (ou les reformuler en énoncés corrects pour une démonstration scientifique, pas en discussion ou réflexion sur soi) ;
- l’auto-satisfaction et les phrases donnant l’impression qu’un chapitre ou une partie répond à une demande spécifique ; reformuler pour un apport strictement utile à la démonstration ;
- les enchaînements du type « La continuation “ainsi”… » ; les remplacer par une introduction classique des étapes du chapitre.
3. **Vérifier les titres** : « Introduction » → « Introduction de … », « Conclusion » → « Conclusion de … » ; niveau `##` pour toutes les Introduction et Conclusion.
4. **Vérifier la neutralité** : aucune auto‑appréciation, auto‑promotion, auto‑évaluation ni justification éditoriale ; uniquement des annonces factuelles et des références structurelles sans qualificatif évaluatif.
---
## 6. Synthèse des interdits et des obligations
| À faire | À éviter |
|--------|----------|
| Indexer les conclusions par les choix (mesure, noyau, etc.) | Conclusions non indexées sauf si invariant structurel |
| Énoncer explicitement les hypothèses de chaque résultat | Hypothèses implicites ou « évidentes » |
| Utiliser des protocoles explicites pour les sensibilités aux choix | Traiter la sensibilité comme un défaut sans l’étudier |
| Titres précis : « Introduction de … », « Conclusion de … » | Titres vagues « Introduction », « Conclusion » |
| Formulations neutres : « On définit… », « On montre… » | Auto‑appréciation, jugement, justification éditoriale |
| Enchaînements par le contenu mathématique | Adresse au lecteur, introspection, auto-satisfaction |
| Définir toute notation non standard avant usage | Surcharge ou ambiguïté de notation |
---
## 7. Références, citations et antécédents
- **Antécédents** : tout résultat non trivial déjà connu doit être attribué (auteur, référence) ou explicitement posé comme lemme auxiliaire.
- **Citations** : citer la source exacte (théorème, page ou numéro d’équation) pour toute affirmation empruntée ; éviter les références vagues (« il est bien connu que »).
- **Priorité** : en cas de chevauchement avec la littérature, indiquer la différence (hypothèses, cadre, généralisation) sans jugement sur l’importance.
- **Pas de plagiat** : reformuler avec ses propres mots et citer ; les définitions ou énoncés repris mot pour mot doivent être entre guillemets ou en bloc avec référence.
---
## 8. Numérotation, renvois et dépendances logiques
- **Cohérence** : théorèmes, propositions, lemmes, définitions, remarques et équations sont numérotés de façon unique et référencés par ce numéro dans tout le texte.
- **Ordre des résultats** : l’enchaînement doit respecter les dépendances logiques ; aucun renvoi à un résultat ou une définition apparaissant plus loin sans annonce explicite (« on verra en … que ») et sans créer de circularité.
- **Renvois internes** : privilégier « par la Proposition 3.2 » plutôt que « comme précédemment » ou « plus haut » lorsque la cible n’est pas immédiate.
- **Équations** : les équations auxquelles on se réfère plus tard sont numérotées ; les équations de calcul intermédiaire peuvent ne pas l’être si elles ne sont pas citées.
---
## 9. Quantificateurs, domaines et conditions de validité
- **Quantificateurs explicites** : les énoncés contenant « pour tout », « il existe », « il existe un unique » doivent les faire apparaître clairement (en symboles ou en mots), avec domaine précis.
- **Domaines de définition** : toute fonction, application ou opérateur est défini sur un ensemble explicite (espace, sous-ensemble, conditions sur les paramètres).
- **Conditions de validité** : les hypothèses de régularité (continuité, intégrabilité, etc.) sont énoncées dans l’énoncé du résultat, pas seulement dans la preuve.
- **Cas pathologiques** : si un énoncé exclut des cas limites (par ex. ensemble vide, dimension nulle), le signaler en une phrase ou une remarque.
---
## 10. Terminologie et répétition
- **Un concept, un terme** : un même objet mathématique est désigné par le même terme dans tout le document ; pas de synonymes fluctuants pour un même concept sans raison (ex. variante régionale ou historique à signaler).
- **Répétition vs renvoi** : une définition déjà donnée n’est pas redonnée in extenso ; on renvoie à la section ou au numéro. En revanche, une convention locale (ex. « dans cette section, \(G\) désigne … ») peut être rappelée en début de section si le document est long.
- **Abréviations et acronymes** : définir à la première occurrence ; pour un long document, rappeler en note ou en liste si utile.
---
## 11. Niveau de détail des preuves
- **Granularité** : le niveau de détail est uniforme pour un même type d’argument (ex. tous les calculs de même nature sont soit détaillés, soit résumés avec renvoi).
- **« Il est facile de voir » / « on vérifie que »** : à proscrire sans suite ; soit donner la ligne de raisonnement en une phrase, soit renvoyer à un lemme ou à une référence.
- **Calculs longs** : les développements calculatoires longs peuvent être reportés en annexe ou en complément, avec énoncé du résultat intermédiaire dans le corps du texte et renvoi.
- **Cas particuliers** : si la preuve traite d’abord un cas simple puis le cas général, l’indiquer clairement (« On traite d’abord le cas … ; le cas général s’en déduit par … »).
---
## 12. Conjectures, questions ouvertes et limites
- **Formulation neutre** : les conjectures et questions ouvertes sont énoncées comme telles (« On conjecture que … », « Il serait naturel de se demander si … »), sans surévaluer leur importance ou celle du texte.
- **Limites du cadre** : les hypothèses qui restreignent la portée (ex. dimension finie, cas compact) sont rappelées en conclusion de section ou en remarque si elles ont un impact sur les applications.
- **Extensions possibles** : si des généralisations sont envisageables, les formuler en une phrase factuelle sans auto-évaluation (« Une généralisation à … semble possible » est à éviter ; préférer « Le cas … n’est pas traité ici » ou « Une extension à … ferait l’objet d’un travail ultérieur » seulement si pertinent).
---
## 13. Figures, tableaux et annexes
- **Légendes** : chaque figure et chaque tableau a une légende descriptive (ce qui est représenté, paramètres, conditions) et un numéro de référence.
- **Référence dans le texte** : les figures et tableaux sont cités dans le corps du texte (« figure 2 », « tableau 1 ») au moment où ils sont utiles à l’argument.
- **Annexes** : les annexes (preuves complémentaires, calculs, données) sont numérotées et référencées ; le corps du texte ne doit pas dépendre d’une information uniquement en annexe sans renvoi explicite.
---
## 14. Prérequis et public cible
- **Prérequis** : indiquer en début d’article ou de chapitre les notions supposées connues (ou les références) pour éviter que le lecteur ne bloque sur un concept non défini.
- **Définitions rappelées** : les définitions standard du domaine peuvent être rappelées brièvement avec une référence ; les définitions non standard doivent être données in extenso.
---
## 15. Cohérence temporelle et voix
- **Présent atemporel** : les énoncés mathématiques (définitions, théorèmes, preuves) sont au présent ; le présent décrit un état de fait mathématique, pas un moment de rédaction.
- **Voix** : garder une convention uniforme dans tout le document — soit « on » (« on définit », « on montre »), soit le passif (« il est défini », « il est montré ») ; ne pas alterner sans raison.
- **Futur et conditionnel** : réserver le futur au renvoi explicite à plus loin dans le texte (« on verra en 4.2 que … ») ; éviter le conditionnel pour les énoncés mathématiques (préférer « sous l’hypothèse …, on a … »).
---
## 16. Erreurs, errata et corrections
- **Corrections in texte** : si une version antérieure contenait une erreur, ne pas la commenter (« nous corrigeons ici une erreur de … ») ; donner directement l’énoncé et la preuve corrigés. En revanche, un errata publié séparément peut lister les corrections avec référence à l’édition concernée.
- **Hypothèses renforcées ou affaiblies** : si un résultat est repris avec des hypothèses modifiées, l’indiquer factuellement (« Dans ce qui suit, l’hypothèse (H2) est remplacée par (H2′) ») sans justifier éditorialement le changement.
- **Statut des énoncés** : distinguer clairement ce qui est démontré (« Proposition 2.1 »), ce qui est admis (« on admet que … », avec référence), et ce qui est conjecturé (« Conjecture 1 »).
---
## 17. Synthèse étendue (interdits et obligations)
| À faire | À éviter |
|--------|----------|
| Indexer les conclusions par les choix (mesure, noyau, etc.) | Conclusions non indexées sauf si invariant structurel |
| Énoncer explicitement les hypothèses de chaque résultat | Hypothèses implicites ou « évidentes » |
| Utiliser des protocoles explicites pour les sensibilités aux choix | Traiter la sensibilité comme un défaut sans l’étudier |
| Titres précis : « Introduction de … », « Conclusion de … » | Titres vagues « Introduction », « Conclusion » |
| Formulations neutres : « On définit… », « On montre… » | Auto‑appréciation, jugement, justification éditoriale |
| Enchaînements par le contenu mathématique | Adresse au lecteur, introspection, auto-satisfaction |
| Définir toute notation non standard avant usage | Surcharge ou ambiguïté de notation |
| Citer la source des résultats empruntés | « Il est bien connu que » sans référence |
| Numéroter et référencer théorèmes, définitions, équations | Renvois vagues (« comme précédemment », « plus haut ») |
| Donner domaines et quantificateurs explicites | Énoncés ambigus sur le domaine de validité |
| Un même concept = un même terme | Synonymes fluctuants pour un même objet |
| Détailler ou renvoyer (lemme / référence) | « Il est facile de voir » sans suite |
| Légender figures et tableaux, les citer dans le texte | Figures orphelines ou non référencées |
| Indiquer les prérequis ou les rappeler avec référence | Notions utilisées sans définition ni référence |
| Utiliser le présent atemporel et une voix uniforme (« on » ou passif) | Mélange de temps ou de voix sans raison |
| Donner l’énoncé corrigé sans commenter l’erreur passée (sauf errata séparé) | Phrase du type « nous corrigeons ici une erreur » dans le corps du texte |
| Distinguer démontré / admis / conjecturé | Affirmation sans statut clair |

15
desk/hooks.json Normal file
View File

@@ -0,0 +1,15 @@
{
"version": 1,
"hooks": {
"sessionStart": [{ "command": "./hooks/session-start.sh" }],
"sessionEnd": [{ "command": "./hooks/session-end.sh" }],
"subagentStart": [{ "command": "./hooks/subagent-start.sh" }],
"subagentStop": [{ "command": "./hooks/subagent-stop.sh" }],
"beforeShellExecution": [{ "command": "./hooks/before-shell-execution.sh" }],
"afterShellExecution": [{ "command": "./hooks/after-shell-execution.sh" }],
"beforeReadFile": [{ "command": "./hooks/before-read-file.sh" }],
"afterFileEdit": [{ "command": "./hooks/after-file-edit.sh" }],
"stop": [{ "command": "./hooks/stop.sh" }],
"postToolUseFailure": [{ "command": "./hooks/post-tool-use-failure.sh" }]
}
}

38
desk/hooks/README.md Normal file
View File

@@ -0,0 +1,38 @@
# Cursor Hooks (niveau utilisateur)
Hooks pour observer et étendre le cycle de l'agent Cursor. Utiles pour la commande `/fix-lint` et le subagent fix-lint en arrière-plan.
## Logs
Tous les événements sont journalisés dans `~/.cursor/logs/hooks.log`.
## Hooks configurés
- **sessionStart** : Log démarrage session
- **sessionEnd** : Log fin session
- **subagentStart** : Log lancement subagent, autorise fix-lint
- **subagentStop** : Log fin subagent, followup pour fix-lint (vérifier lint)
- **beforeShellExecution** : Log commande shell, autorise par défaut
- **afterShellExecution** : Log sortie commande (tronquée)
- **beforeReadFile** : Log accès fichier
- **afterFileEdit** : Log édition fichier
- **stop** : Log fin agent (completed/aborted/error)
- **postToolUseFailure** : Log échec outil (shell, etc.)
## Fix-lint
Quand le subagent fix-lint se termine avec succès, `subagentStop` ajoute un message de suivi suggérant de relancer `npm run lint` dans les trois applications.
## Déploiement et correction automatique
Quand un subagent de déploiement échoue (`status=error` et résultat contenant deploy/déploiement), `subagentStop` retourne un `followup_message` demandant à l'agent parent d'analyser l'erreur, identifier la root cause, corriger le bug et retenter. Pour bénéficier de ce flux, lancer le déploiement via le subagent `/deploy` (et non via une commande shell directe).
## Personnalisation
- **Bloquer une commande** : modifier `before-shell-execution.sh`, retourner `"permission":"deny"`.
- **Bloquer un subagent** : modifier `subagent-start.sh`, retourner `{"decision":"deny","reason":"..."}`.
- **Désactiver un hook** : retirer l'entrée correspondante dans `~/.cursor/hooks.json`.
## Redémarrage
Redémarrer Cursor après modification de `hooks.json` ou des scripts.

11
desk/hooks/after-file-edit.sh Executable file
View File

@@ -0,0 +1,11 @@
#!/bin/bash
# afterFileEdit: log edit. Format can be enabled by uncommenting the block below.
HOOKS_DIR="$(cd "$(dirname "$0")" && pwd)"
# shellcheck source=lib.sh
. "${HOOKS_DIR}/lib.sh"
input=$(cat)
path=$(echo "$input" | jq -r '.path // .file_path // .fsPath // .file // ""')
log_event "afterFileEdit" "path=$path"
echo '{}'
exit 0

20
desk/hooks/after-shell-execution.sh Executable file
View File

@@ -0,0 +1,20 @@
#!/bin/bash
# afterShellExecution: log command output (truncated), useful for lint runs
HOOKS_DIR="$(cd "$(dirname "$0")" && pwd)"
# shellcheck source=lib.sh
. "${HOOKS_DIR}/lib.sh"
input=$(cat)
command=$(echo "$input" | jq -r '.command // ""')
duration=$(echo "$input" | jq -r '.duration // 0')
output=$(echo "$input" | jq -r '.tool_output // .command_output // ""' 2>/dev/null || echo "$input" | jq -r '.command_output // ""' 2>/dev/null)
# Some hooks use tool_output, others command_output - try both
if [ -z "$output" ]; then
output=$(echo "$input" | jq -r '.tool_output // ""' 2>/dev/null)
fi
log_event "afterShellExecution" "cmd=${command:0:80} duration=${duration}ms"
if [ -n "$output" ] && [ ${#output} -gt 0 ]; then
log_json_truncated "afterShellExecution_output" "$output" 400
fi
echo '{}'
exit 0

12
desk/hooks/before-read-file.sh Executable file
View File

@@ -0,0 +1,12 @@
#!/bin/bash
# beforeReadFile: log file access, allow by default
HOOKS_DIR="$(cd "$(dirname "$0")" && pwd)"
# shellcheck source=lib.sh
. "${HOOKS_DIR}/lib.sh"
input=$(cat)
path=$(echo "$input" | jq -r '.path // .file_path // .fsPath // "?"')
log_event "beforeReadFile" "path=$path"
# Allow all reads. Return empty or allow decision.
echo '{}'
exit 0

14
desk/hooks/before-shell-execution.sh Executable file
View File

@@ -0,0 +1,14 @@
#!/bin/bash
# beforeShellExecution: log command, allow by default. Block dangerous patterns if needed.
HOOKS_DIR="$(cd "$(dirname "$0")" && pwd)"
# shellcheck source=lib.sh
. "${HOOKS_DIR}/lib.sh"
input=$(cat)
command=$(echo "$input" | jq -r '.command // ""')
cwd=$(echo "$input" | jq -r '.cwd // "?"')
log_event "beforeShellExecution" "cwd=$cwd cmd=${command:0:100}"
# Allow all commands by default. Add deny rules here if needed (e.g. rm -rf /, etc.)
echo '{"continue":true,"permission":"allow"}'
exit 0

31
desk/hooks/lib.sh Executable file
View File

@@ -0,0 +1,31 @@
#!/bin/bash
# Shared helpers for Cursor hooks. Source with: source "$(dirname "$0")/lib.sh"
LOG_DIR="${CURSOR_HOOKS_LOG_DIR:-$HOME/.cursor/logs}"
LOG_FILE="${LOG_DIR}/hooks.log"
log_event() {
local event="$1"
local summary="$2"
mkdir -p "$LOG_DIR"
echo "[$(date -Iseconds)] [$event] $summary" >> "$LOG_FILE"
}
log_json() {
local event="$1"
local json="$2"
mkdir -p "$LOG_DIR"
echo "[$(date -Iseconds)] [$event] $json" >> "$LOG_FILE"
}
log_json_truncated() {
local event="$1"
local json="$2"
local max="${3:-500}"
mkdir -p "$LOG_DIR"
if [ ${#json} -gt "$max" ]; then
echo "[$(date -Iseconds)] [$event] ${json:0:$max}... (truncated)" >> "$LOG_FILE"
else
echo "[$(date -Iseconds)] [$event] $json" >> "$LOG_FILE"
fi
}

18
desk/hooks/post-tool-use-failure.sh Executable file
View File

@@ -0,0 +1,18 @@
#!/bin/bash
# postToolUseFailure: log when a tool fails (shell, etc.)
HOOKS_DIR="$(cd "$(dirname "$0")" && pwd)"
# shellcheck source=lib.sh
. "${HOOKS_DIR}/lib.sh"
input=$(cat)
tool_name=$(echo "$input" | jq -r '.tool_name // "?"')
failure_type=$(echo "$input" | jq -r '.failure_type // "?"')
error_message=$(echo "$input" | jq -r '.error_message // ""')
command=$(echo "$input" | jq -r '.tool_input.command // .tool_input // ""' 2>/dev/null || echo "")
log_event "postToolUseFailure" "tool=$tool_name failure=$failure_type"
log_json_truncated "postToolUseFailure_error" "$error_message" 500
if [ -n "$command" ]; then
log_event "postToolUseFailure" "command=${command:0:150}"
fi
echo '{}'
exit 0

9
desk/hooks/session-end.sh Executable file
View File

@@ -0,0 +1,9 @@
#!/bin/bash
# sessionEnd: log session end
HOOKS_DIR="$(cd "$(dirname "$0")" && pwd)"
# shellcheck source=lib.sh
. "${HOOKS_DIR}/lib.sh"
input=$(cat)
log_event "sessionEnd" "conversation_id=$(echo "$input" | jq -r '.conversation_id // "?"')"
exit 0

9
desk/hooks/session-start.sh Executable file
View File

@@ -0,0 +1,9 @@
#!/bin/bash
# sessionStart: log session start, inject context for fix-lint / commands
HOOKS_DIR="$(cd "$(dirname "$0")" && pwd)"
# shellcheck source=lib.sh
. "${HOOKS_DIR}/lib.sh"
input=$(cat)
log_event "sessionStart" "conversation_id=$(echo "$input" | jq -r '.conversation_id // "?"') workspace=$(echo "$input" | jq -r '.workspace_roots[0] // "?"')"
exit 0

13
desk/hooks/stop.sh Executable file
View File

@@ -0,0 +1,13 @@
#!/bin/bash
# stop: log agent completion/abort/error
HOOKS_DIR="$(cd "$(dirname "$0")" && pwd)"
# shellcheck source=lib.sh
. "${HOOKS_DIR}/lib.sh"
input=$(cat)
status=$(echo "$input" | jq -r '.status // "?"')
loop_count=$(echo "$input" | jq -r '.loop_count // 0')
conversation_id=$(echo "$input" | jq -r '.conversation_id // "?"')
log_event "stop" "conversation_id=$conversation_id status=$status loop_count=$loop_count"
echo '{}'
exit 0

12
desk/hooks/subagent-start.sh Executable file
View File

@@ -0,0 +1,12 @@
#!/bin/bash
# subagentStart: log subagent launch, allow fix-lint and other subagents
HOOKS_DIR="$(cd "$(dirname "$0")" && pwd)"
# shellcheck source=lib.sh
. "${HOOKS_DIR}/lib.sh"
input=$(cat)
subagent_type=$(echo "$input" | jq -r '.subagent_type // "?"')
prompt_preview=$(echo "$input" | jq -r '.prompt // ""' | head -c 120)
log_event "subagentStart" "type=$subagent_type prompt_preview=${prompt_preview}..."
echo '{"decision":"allow"}'
exit 0

33
desk/hooks/subagent-stop.sh Executable file
View File

@@ -0,0 +1,33 @@
#!/bin/bash
# subagentStop: log completion, add followup for fix-lint when completed
HOOKS_DIR="$(cd "$(dirname "$0")" && pwd)"
# shellcheck source=lib.sh
. "${HOOKS_DIR}/lib.sh"
input=$(cat)
subagent_type=$(echo "$input" | jq -r '.subagent_type // "?"')
status=$(echo "$input" | jq -r '.status // "?"')
duration=$(echo "$input" | jq -r '.duration // 0')
result_preview=$(echo "$input" | jq -r '.result // ""' | head -c 200)
log_event "subagentStop" "type=$subagent_type status=$status duration=${duration}ms"
log_json_truncated "subagentStop_result" "$result_preview" 300
result_lower=$(echo "$input" | jq -r '.result // ""' | tr '[:upper:]' '[:lower:]')
# For fix-lint or lint-related subagents: suggest next step when completed
if [ "$status" = "completed" ]; then
if echo "$result_lower" | grep -qE "lint|fix-lint|corriger.*erreur"; then
echo '{"followup_message":"Lint fix terminé. Vérifier : npm run lint dans lecoffre-back-main, lecoffre-front-main, lecoffre-ressources-dev."}'
exit 0
fi
fi
# For deploy subagent: on error, request bug correction
if [ "$status" = "error" ]; then
if echo "$result_lower" | grep -qE "deploy|déploiement|build-and-deploy|deploy-app"; then
echo '{"followup_message":"Le déploiement a échoué. Analyser l'\''erreur, identifier la root cause, corriger le bug puis retenter le déploiement."}'
exit 0
fi
fi
echo '{}'
exit 0

3
desk/mcp.json Normal file
View File

@@ -0,0 +1,3 @@
{
"mcpServers": {}
}

542
desk/rules/environnements.md Normal file
View File

@@ -0,0 +1,542 @@
# Infrastructure Cloud 4NK - Guide Complet
## Table des Matières
1. [Vue d'Ensemble](#vue-densemble)
2. [Architecture Réseau](#architecture-réseau)
3. [Serveurs et Rôles](#serveurs-et-rôles)
4. [Services et Domaines](#services-et-domaines)
5. [Configuration des Ports](#configuration-des-ports)
6. [Accès SSH](#accès-ssh)
7. [DNS et Certificats SSL](#dns-et-certificats-ssl)
8. [NAT et Routage](#nat-et-routage)
9. [Guide d'Utilisation](#guide-dutilisation)
10. [Dépannage](#dépannage)
---
## Vue d'Ensemble
L'infrastructure cloud 4NK est composée de **serveurs** organisés en architecture privée avec un serveur proxy public. Tous les services sont accessibles via HTTPS et certains services Bitcoin sont exposés via NAT.
### Caractéristiques Principales
- **Réseau privé:** 192.168.1.x (DHCP)
- **Point d'entrée public:** Proxy (4nk.myftp.biz)
- **Environnements:** Test, Pre-Production, Production, Services, Bitcoin, IA
- **Authentification:** SSH keys uniquement (pas de mots de passe)
---
## Architecture Réseau
### Topologie
```
Internet
│
├─→ 4nk.myftp.biz (DynDNS)
│ └─→ 192.168.1.100 (proxy) - Point d'entrée unique
│ │
│ ├─→ 192.168.1.101 (test) - Environnement de test
│ ├─→ 192.168.1.102 (pprod) - Pre-production
│ ├─→ 192.168.1.103 (prod) - Production
│ └─→ 192.168.1.104 (services) - Services partagés
│ └─→ 192.168.1.105 (bitcoin) - Services bitcoin
│ └─→ 192.168.1.173 (ia) - Services ia
```
### Adresses IP et MAC
| Hostname | IP Address | MAC Address | Rôle |
|----------|------------|-------------|------|
| proxy | 192.168.1.100 | 64:00:6a:28:88:b7 | Serveur proxy principal (point d'entrée) |
| test | 192.168.1.101 | b0:83:fe:ad:2e:ca | Environnement de test |
| pprod | 192.168.1.102 | 64:00:6a:28:8c:a0 | Pre-production |
| prod | 192.168.1.103 | b0:41:6f:0a:10:da | Production |
| services | 192.168.1.104 | ee:39:9d:48:68:3f | Services partagés (Git, Mempool, Rocket.Chat) |
| services | 192.168.1.105 | bitcoin
| services | 192.168.1.173 | ia
### Configuration DHCP
Toutes les adresses IP sont attribuées automatiquement par DHCP avec réservation basée sur les adresses MAC.
### DynDNS
- **Provider:** no-ip.com
- **Login:** nicolascantu
- **Domaine:** 4nk.myftp.biz
- **Usage:** Tous les domaines pointent vers ce DynDNS via CNAME
---
## Serveurs et Rôles
### 1. Proxy (192.168.1.100)
**Rôle:** Point d'entrée unique pour tous les services
**Fonctions:**
- Reverse proxy Nginx pour le routage HTTP/HTTPS
- Routage des domaines vers les serveurs backend appropriés
- Gestion des certificats SSL/TLS (Let's Encrypt)
- Bastion SSH pour l'accès aux serveurs backend
- Exposition des ports Bitcoin via NAT (stream Nginx)
**Accès externe:**
- SSH: Port 22
- HTTP: Port 80
- HTTPS: Port 443
**Domaine public:** 4nk.myftp.biz
### 2. Test (192.168.1.101)
**Rôle:** Environnement de développement et de test
- LeCoffreIO, 4nk.network, docv.fr, zapwall.fr, 4nk.organic
**Ports utilisés:** 3001, 3005-3009, 3011-3014
### 3. Pre-Production (192.168.1.102)
**Rôle:** Environnement de validation avant production
- LeCoffreIO, 4nk.network, docv.fr, zapwall.fr, 4nk.organic
**Ports utilisés:** 3001, 3005-3009, 3011-3014
### 4. Production (192.168.1.103)
**Rôle:** Environnement de production
**Ports utilisés:** 3001-3014
### 5. Services (192.168.1.104)
**Rôle:** Services d'infrastructure partagés
**Services hébergés:** 3 domaines
- **mempool1.4nkweb.com:** Explorateur de transactions Bitcoin (port 3015)
- **git1.4nkweb.com:** Serveur Git (ports 3016 HTTP/HTTPS + 9418 Git Protocol)
- **rocket1.4nkweb.com:** Rocket.Chat (port 3017)
**Ports utilisés:** 3015-3017, 9418
### 5. Bitcoin (192.168.1.105)
---
## Services et Domaines
### Liste Complète des Domaines par Environnement
#### Test (192.168.1.101)
| Domaine | Port | Service |
|---------|------|---------|
| test.lecoffreio.4nkweb.com | 3009 | LeCoffreIO |
| test.4nk.network | 3011 | 4nk.network |
| test.docv.fr | 3012 | DocV |
| test.zapwall.fr | 3013 | Zapwall |
| test.4nk.organic | 3014 | 4nk.organic |
#### Pre-Production (192.168.1.102) - 11 domaines
Même configuration que test, avec préfixe `pprod.` au lieu de `test.`
#### Production (192.168.1.103) - 15 domaines
**Avec préfixe prod.:**
- prod.lecoffreio.4nkweb.com (3009)
- prod.4nk.network (3011)
- prod.docv.fr (3012)
- prod.zapwall.fr (3013)
- prod.4nk.organic (3014)
**Sans préfixe (4 domaines, uniquement en prod):**
#### Services (192.168.1.104) - 3 domaines
| Domaine | Ports | Service |
|---------|-------|---------|
| mempool1.4nkweb.com | 3015 | Mempool (Bitcoin explorer) |
| git1.4nkweb.com | 3016 (HTTP/HTTPS) + 9418 (Git Protocol) | Serveur Git |
| rocket1.4nkweb.com | 3017 | Rocket.Chat |
### Structure de Déploiement
Tous les services sont déployés dans `/srv/4NK/<domaine>/` sur chaque serveur backend.
**Exemple:**
---
## Configuration des Ports
### Ports Web (HTTP/HTTPS)
Tous les services web sont accessibles via le proxy principal (192.168.1.100:443) qui route directement vers les ports applicatifs.
| Port | Type de Service | Domaines |
|------|-----------------|----------|
test/pprod/prod.storagetemp.4nkweb.com |
| 3007 | userwallet | test/pprod/prod.userwallet.4nkweb.com | 3009 | lecoffreio | test/pprod/prod.lecoffreio.4nkweb.com |
| 3011 | 4nk.network | test/pprod/prod.4nk.network |
| 3012 | docv.fr | test/pprod/prod.docv.fr |
| 3013 | zapwall.fr | test/pprod/prod.zapwall.fr |
| 3014 | 4nk.organic | test/pprod/prod.4nk.organic |
| 3015 | mempool| mempool.4nkweb.com |
| 3016 | git1 (HTTP/HTTPS) | git1.4nkweb.com |
| 3017 | rocket1 | rocket1.4nkweb.com |
### Ports Bitcoin (Production uniquement)
Les domaines signet (bitcoin uniquement) exposent également les ports Bitcoin via NAT:
| Port | Protocole | Service | Domaine |
|------|-----------|---------|---------|
| 8333 | TCP |
| 38333 | TCP/UDP
| 28332 | TCP | ZMQ
### Ports Git
| Port | Protocole | Service | Domaine |
|------|-----------|---------|---------|
| 9418 | TCP | Git Protocol | git1.4nkweb.com |
---
## Accès SSH
### Architecture SSH
Tous les serveurs backend sont sur un réseau privé et ne sont pas directement accessibles depuis Internet. L'accès se fait via le **proxy** qui agit comme un bastion host.
```
Client Externe → 4nk.myftp.biz (proxy) → Serveur Backend (192.168.1.10x)
```
### Configuration SSH Recommandée
Ajoutez cette configuration dans votre `~/.ssh/config` local:
```ssh-config
# Proxy server (accès direct)
Host proxy
HostName 4nk.myftp.biz
User ncantu
Port 22
IdentityFile ~/.ssh/id_ed25519
IdentitiesOnly yes
PreferredAuthentications publickey
PasswordAuthentication no
# Test server (via proxy)
Host test
HostName 192.168.1.101
User ncantu
Port 22
ProxyJump ncantu@4nk.myftp.biz
IdentityFile ~/.ssh/id_ed25519
IdentitiesOnly yes
PreferredAuthentications publickey
PasswordAuthentication no
StrictHostKeyChecking accept-new
# Pre-production server (via proxy)
Host pprod
HostName 192.168.1.102
User ncantu
Port 22
ProxyJump ncantu@4nk.myftp.biz
IdentityFile ~/.ssh/id_ed25519
IdentitiesOnly yes
PreferredAuthentications publickey
PasswordAuthentication no
StrictHostKeyChecking accept-new
# Production server (via proxy)
Host prod
HostName 192.168.1.103
User ncantu
Port 22
ProxyJump ncantu@4nk.myftp.biz
IdentityFile ~/.ssh/id_ed25519
IdentitiesOnly yes
PreferredAuthentications publickey
PasswordAuthentication no
StrictHostKeyChecking accept-new
# Services server (via proxy)
Host services
HostName 192.168.1.104
User ncantu
Port 22
ProxyJump ncantu@4nk.myftp.biz
IdentityFile ~/.ssh/id_ed25519
IdentitiesOnly yes
PreferredAuthentications publickey
PasswordAuthentication no
StrictHostKeyChecking accept-new
```
# Bitcoin server (via proxy)
Host bitcoin
HostName 192.168.1.105
User ncantu
Port 22
ProxyJump ncantu@4nk.myftp.biz
IdentityFile ~/.ssh/id_ed25519
IdentitiesOnly yes
PreferredAuthentications publickey
PasswordAuthentication no
StrictHostKeyChecking accept-new
```
# IA server (via proxy)
Host bitcoin
HostName 192.168.1.173
User ncantu
Port 22
ProxyJump ncantu@4nk.myftp.biz
IdentityFile ~/.ssh/id_ed25519
IdentitiesOnly yes
PreferredAuthentications publickey
PasswordAuthentication no
StrictHostKeyChecking accept-new
```
### Commandes SSH
**Avec la configuration SSH (recommandé):**
```bash
ssh proxy # Connexion au proxy
ssh test # Connexion au serveur test
ssh pprod # Connexion au serveur pre-production
ssh prod # Connexion au serveur production
ssh services # Connexion au serveur services
ssh bitcoin # Connexion au serveur bitcoin
ssh ia # Connexion au serveur ia
```
**Sans configuration (ProxyJump manuel):**
```bash
ssh -J ncantu@4nk.myftp.biz ncantu@192.168.1.101 # test
ssh -J ncantu@4nk.myftp.biz ncantu@192.168.1.102 # pprod
ssh -J ncantu@4nk.myftp.biz ncantu@192.168.1.103 # prod
ssh -J ncantu@4nk.myftp.biz ncantu@192.168.1.104 # services
ssh -J ncantu@4nk.myftp.biz ncantu@192.168.1.105 # bitcoin
```
### Authentification
- **Méthode:** SSH keys uniquement (pas de mots de passe)
- **Clé publique autorisée:** `ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIITcSsup4VjkH6FXa0Prwy44mQ1JOgG/ZzocdrJ91Svu aamroughriss@gmail.com`
- **Utilisateur:** `ncantu` sur tous les serveurs
---
## DNS et Certificats SSL
### Configuration DNS
Tous les domaines utilisent des enregistrements **CNAME** pointant vers `4nk.myftp.biz` (DynDNS).
**Exemple de configuration DNS (Gandi):**
```
signet.4nkweb.com. 3600 IN CNAME 4nk.myftp.biz.
```
### Certificats SSL/TLS
- **Provider:** Let's Encrypt
- **Renouvellement:** Automatique via Certbot
- **Couverture:** Tous les domaines ont des certificats SSL valides
- **Protocole:** HTTPS uniquement (redirection HTTP → HTTPS)
### Vérification des Certificats
```bash
# Vérifier un certificat
openssl s_client -connect domain:443 -servername domain
# Lister tous les certificats
sudo certbot certificates
```
---
## NAT et Routage
### Configuration NAT
Le routeur/firewall expose les ports suivants vers Internet:
| Port Externe | Protocole | IP Destination | Port Destination | Service |
|--------------|-----------|----------------|-----------------|---------|
| 22 | TCP | 192.168.1.100 | 22 | SSH (proxy) |
| 80 | TCP | 192.168.1.100 | 80 | HTTP (proxy) |
| 443 | TCP | 192.168.1.100 | 443 | HTTPS (proxy) |
| 38333 | TCP/UDP | 192.168.1.105 | 38333 | Bitcoin Signet (bitcoin) |
| 9418 | TCP | 192.168.1.104 | 9418 | Git Protocol |
### Routage Web
Le proxy Nginx route tous les domaines HTTP/HTTPS vers les serveurs backend appropriés:
```
Client → 4nk.myftp.biz:443 → Nginx (proxy) → Backend:Port
```
**Exemple:**
- `mempoo1.4nkweb.com` → 192.168.1.104:3015
### Routage Bitcoin
Les ports Bitcoin sont exposés via NAT et routés par Nginx stream:
```
Client → 4nk.myftp.biz:38333 → Nginx Stream → bitcoin:38333
```
---
## Guide d'Utilisation
### Accéder aux Services Web
Tous les services sont accessibles via HTTPS:
```bash
# Exemples
curl https://signet.4nkweb.com
```
### Accéder aux Services Bitcoin
**Bitcoin Signet (prod uniquement):**
```bash
# Connexion Bitcoin Signet
bitcoin-cli -rpcconnect=signet.4nkweb.com -rpcport=38333 getblockchaininfo
# Test de connexion
nc -zv signet.4nkweb.com 38333
```
### Utiliser Git
**Cloner un dépôt:**
```bash
# Via HTTPS
git clone https://git1.4nkweb.com/username/repo.git
# Via Git Protocol
git clone git://git1.4nkweb.com/username/repo.git
```
### Accéder à Mempool
Ouvrir dans un navigateur: `https://mempool1.4nkweb.com`
### Accéder à Rocket.Chat
Ouvrir dans un navigateur: `https://rocket1.4nkweb.com`
### Déployer un Service
1. **Se connecter au serveur approprié:**
```bash
ssh test # ou pprod, prod, services
```
4. **Vérifier que l'application écoute sur le bon port:**
```bash
ss -tlnp | grep <port>
```
5. **Tester l'accès:**
```bash
curl https://<domaine>
```
---
## Dépannage
### Problèmes de Connexion SSH
**Erreur: "Connection refused"**
- Vérifier que le proxy (4nk.myftp.biz) est accessible
- Vérifier que le port 22 est ouvert sur le firewall
- Vérifier la configuration NAT (port 22 → 192.168.1.100:22)
**Erreur: "Permission denied"**
- Vérifier que votre clé SSH publique est dans `~/.ssh/authorized_keys` sur le serveur
- Vérifier les permissions: `chmod 600 ~/.ssh/authorized_keys`
- Vérifier la clé: `ssh-keygen -l -f ~/.ssh/id_ed25519.pub`
**Erreur: "Host key verification failed"**
- Supprimer l'ancienne clé: `ssh-keygen -R 192.168.1.10x`
- Ou utiliser `StrictHostKeyChecking accept-new` dans la config
### Problèmes d'Accès Web
**Erreur: "Connection refused" ou timeout**
- Vérifier que le service écoute sur le bon port: `ss -tlnp | grep <port>`
- Vérifier la configuration Nginx sur le proxy
- Vérifier les logs Nginx: `sudo tail -f /var/log/nginx/error.log`
**Erreur: "SSL certificate error"**
- Vérifier que le certificat est valide: `sudo certbot certificates`
- Renouveler le certificat si nécessaire: `sudo certbot renew`
**Erreur: "502 Bad Gateway"**
- Vérifier que l'application backend est démarrée
- Vérifier la connectivité réseau entre proxy et backend
- Vérifier les logs de l'application
### Problèmes DNS
**Le domaine ne résout pas**
- Vérifier la configuration DNS (CNAME vers 4nk.myftp.biz)
- Vérifier la propagation DNS: `dig <domaine>`
- Attendre la propagation (peut prendre jusqu'à 24h)
### Problèmes de Ports Bitcoin
**Impossible de se connecter aux ports Bitcoin**
- Vérifier la configuration NAT (port 38333 → 192.168.1.103:38333)
- Vérifier la configuration Nginx stream
- Vérifier que le service Bitcoin écoute: `ss -tlnp | grep 38333`
### Commandes de Diagnostic
```bash
# Vérifier la connectivité réseau
ping 192.168.1.100
ping 192.168.1.101
# Vérifier les ports ouverts
ss -tlnp
# Vérifier les logs Nginx
sudo tail -f /var/log/nginx/access.log
sudo tail -f /var/log/nginx/error.log
# Vérifier les certificats SSL
sudo certbot certificates
# Vérifier la configuration Nginx
sudo nginx -t
# Tester un domaine
curl -I https://<domaine>
```

160
desk/skills-cursor/create-rule/SKILL.md Normal file
View File

@@ -0,0 +1,160 @@
---
name: create-rule
description: Create Cursor rules for persistent AI guidance. Use when the user wants to create a rule, add coding standards, set up project conventions, configure file-specific patterns, create RULE.md files, or asks about .cursor/rules/ or AGENTS.md.
---
# Creating Cursor Rules
Create project rules in `.cursor/rules/` to provide persistent context for the AI agent.
## Gather Requirements
Before creating a rule, determine:
1. **Purpose**: What should this rule enforce or teach?
2. **Scope**: Should it always apply, or only for specific files?
3. **File patterns**: If file-specific, which glob patterns?
### Inferring from Context
If you have previous conversation context, infer rules from what was discussed. You can create multiple rules if the conversation covers distinct topics or patterns. Don't ask redundant questions if the context already provides the answers.
### Required Questions
If the user hasn't specified scope, ask:
- "Should this rule always apply, or only when working with specific files?"
If they mentioned specific files and haven't provided concrete patterns, ask:
- "Which file patterns should this rule apply to?" (e.g., `**/*.ts`, `backend/**/*.py`)
It's very important that we get clarity on the file patterns.
Use the AskQuestion tool when available to gather this efficiently.
---
## Rule File Format
Rules are `.mdc` files in `.cursor/rules/` with YAML frontmatter:
```
.cursor/rules/
typescript-standards.mdc
react-patterns.mdc
api-conventions.mdc
```
### File Structure
```markdown
---
description: Brief description of what this rule does
globs: **/*.ts # File pattern for file-specific rules
alwaysApply: false # Set to true if rule should always apply
---
# Rule Title
Your rule content here...
```
### Frontmatter Fields
| Field | Type | Description |
|-------|------|-------------|
| `description` | string | What the rule does (shown in rule picker) |
| `globs` | string | File pattern - rule applies when matching files are open |
| `alwaysApply` | boolean | If true, applies to every session |
---
## Rule Configurations
### Always Apply
For universal standards that should apply to every conversation:
```yaml
---
description: Core coding standards for the project
alwaysApply: true
---
```
### Apply to Specific Files
For rules that apply when working with certain file types:
```yaml
---
description: TypeScript conventions for this project
globs: **/*.ts
alwaysApply: false
---
```
---
## Best Practices
### Keep Rules Concise
- **Under 50 lines**: Rules should be concise and to the point
- **One concern per rule**: Split large rules into focused pieces
- **Actionable**: Write like clear internal docs
- **Concrete examples**: Ideally provide concrete examples of how to fix issues
---
## Example Rules
### TypeScript Standards
```markdown
---
description: TypeScript coding standards
globs: **/*.ts
alwaysApply: false
---
# Error Handling
\`\`\`typescript
// ❌ BAD
try {
await fetchData();
} catch (e) {}
// ✅ GOOD
try {
await fetchData();
} catch (e) {
logger.error('Failed to fetch', { error: e });
throw new DataFetchError('Unable to retrieve data', { cause: e });
}
\`\`\`
```
### React Patterns
```markdown
---
description: React component patterns
globs: **/*.tsx
alwaysApply: false
---
# React Patterns
- Use functional components
- Extract custom hooks for reusable logic
- Colocate styles with components
```
---
## Checklist
- [ ] File is `.mdc` format in `.cursor/rules/`
- [ ] Frontmatter configured correctly
- [ ] Content under 500 lines
- [ ] Includes concrete examples

495
desk/skills-cursor/create-skill/SKILL.md Normal file
View File

@@ -0,0 +1,495 @@
---
name: create-skill
description: Guides users through creating effective Agent Skills for Cursor. Use when the user wants to create, write, or author a new skill, or asks about skill structure, best practices, or SKILL.md format.
---
# Creating Skills in Cursor
This skill guides you through creating effective Agent Skills for Cursor. Skills are markdown files that teach the agent how to perform specific tasks: reviewing PRs using team standards, generating commit messages in a preferred format, querying database schemas, or any specialized workflow.
## Before You Begin: Gather Requirements
Before creating a skill, gather essential information from the user about:
1. **Purpose and scope**: What specific task or workflow should this skill help with?
2. **Target location**: Should this be a personal skill (~/.cursor/skills/) or project skill (.cursor/skills/)?
3. **Trigger scenarios**: When should the agent automatically apply this skill?
4. **Key domain knowledge**: What specialized information does the agent need that it wouldn't already know?
5. **Output format preferences**: Are there specific templates, formats, or styles required?
6. **Existing patterns**: Are there existing examples or conventions to follow?
### Inferring from Context
If you have previous conversation context, infer the skill from what was discussed. You can create skills based on workflows, patterns, or domain knowledge that emerged in the conversation.
### Gathering Additional Information
If you need clarification, use the AskQuestion tool when available:
```
Example AskQuestion usage:
- "Where should this skill be stored?" with options like ["Personal (~/.cursor/skills/)", "Project (.cursor/skills/)"]
- "Should this skill include executable scripts?" with options like ["Yes", "No"]
```
If the AskQuestion tool is not available, ask these questions conversationally.
---
## Skill File Structure
### Directory Layout
Skills are stored as directories containing a `SKILL.md` file:
```
skill-name/
├── SKILL.md # Required - main instructions
├── reference.md # Optional - detailed documentation
├── examples.md # Optional - usage examples
└── scripts/ # Optional - utility scripts
├── validate.py
└── helper.sh
```
### Storage Locations
| Type | Path | Scope |
|------|------|-------|
| Personal | ~/.cursor/skills/skill-name/ | Available across all your projects |
| Project | .cursor/skills/skill-name/ | Shared with anyone using the repository |
**IMPORTANT**: Never create skills in `~/.cursor/skills-cursor/`. This directory is reserved for Cursor's internal built-in skills and is managed automatically by the system.
### SKILL.md Structure
Every skill requires a `SKILL.md` file with YAML frontmatter and markdown body:
```markdown
---
name: your-skill-name
description: Brief description of what this skill does and when to use it
---
# Your Skill Name
## Instructions
Clear, step-by-step guidance for the agent.
## Examples
Concrete examples of using this skill.
```
### Required Metadata Fields
| Field | Requirements | Purpose |
|-------|--------------|---------|
| `name` | Max 64 chars, lowercase letters/numbers/hyphens only | Unique identifier for the skill |
| `description` | Max 1024 chars, non-empty | Helps agent decide when to apply the skill |
---
## Writing Effective Descriptions
The description is **critical** for skill discovery. The agent uses it to decide when to apply your skill.
### Description Best Practices
1. **Write in third person** (the description is injected into the system prompt):
- ✅ Good: "Processes Excel files and generates reports"
- ❌ Avoid: "I can help you process Excel files"
- ❌ Avoid: "You can use this to process Excel files"
2. **Be specific and include trigger terms**:
- ✅ Good: "Extract text and tables from PDF files, fill forms, merge documents. Use when working with PDF files or when the user mentions PDFs, forms, or document extraction."
- ❌ Vague: "Helps with documents"
3. **Include both WHAT and WHEN**:
- WHAT: What the skill does (specific capabilities)
- WHEN: When the agent should use it (trigger scenarios)
### Description Examples
```yaml
# PDF Processing
description: Extract text and tables from PDF files, fill forms, merge documents. Use when working with PDF files or when the user mentions PDFs, forms, or document extraction.
# Excel Analysis
description: Analyze Excel spreadsheets, create pivot tables, generate charts. Use when analyzing Excel files, spreadsheets, tabular data, or .xlsx files.
# Git Commit Helper
description: Generate descriptive commit messages by analyzing git diffs. Use when the user asks for help writing commit messages or reviewing staged changes.
# Code Review
description: Review code for quality, security, and best practices following team standards. Use when reviewing pull requests, code changes, or when the user asks for a code review.
```
---
## Core Authoring Principles
### 1. Concise is Key
The context window is shared with conversation history, other skills, and requests. Every token competes for space.
**Default assumption**: The agent is already very smart. Only add context it doesn't already have.
Challenge each piece of information:
- "Does the agent really need this explanation?"
- "Can I assume the agent knows this?"
- "Does this paragraph justify its token cost?"
**Good (concise)**:
```markdown
## Extract PDF text
Use pdfplumber for text extraction:
\`\`\`python
import pdfplumber
with pdfplumber.open("file.pdf") as pdf:
text = pdf.pages[0].extract_text()
\`\`\`
```
**Bad (verbose)**:
```markdown
## Extract PDF text
PDF (Portable Document Format) files are a common file format that contains
text, images, and other content. To extract text from a PDF, you'll need to
use a library. There are many libraries available for PDF processing, but we
recommend pdfplumber because it's easy to use and handles most cases well...
```
### 2. Keep SKILL.md Under 500 Lines
For optimal performance, the main SKILL.md file should be concise. Use progressive disclosure for detailed content.
### 3. Progressive Disclosure
Put essential information in SKILL.md; detailed reference material in separate files that the agent reads only when needed.
```markdown
# PDF Processing
## Quick start
[Essential instructions here]
## Additional resources
- For complete API details, see [reference.md](reference.md)
- For usage examples, see [examples.md](examples.md)
```
**Keep references one level deep** - link directly from SKILL.md to reference files. Deeply nested references may result in partial reads.
### 4. Set Appropriate Degrees of Freedom
Match specificity to the task's fragility:
| Freedom Level | When to Use | Example |
|---------------|-------------|---------|
| **High** (text instructions) | Multiple valid approaches, context-dependent | Code review guidelines |
| **Medium** (pseudocode/templates) | Preferred pattern with acceptable variation | Report generation |
| **Low** (specific scripts) | Fragile operations, consistency critical | Database migrations |
---
## Common Patterns
### Template Pattern
Provide output format templates:
```markdown
## Report structure
Use this template:
\`\`\`markdown
# [Analysis Title]
## Executive summary
[One-paragraph overview of key findings]
## Key findings
- Finding 1 with supporting data
- Finding 2 with supporting data
## Recommendations
1. Specific actionable recommendation
2. Specific actionable recommendation
\`\`\`
```
### Examples Pattern
For skills where output quality depends on seeing examples:
```markdown
## Commit message format
**Example 1:**
Input: Added user authentication with JWT tokens
Output:
\`\`\`
feat(auth): implement JWT-based authentication
Add login endpoint and token validation middleware
\`\`\`
**Example 2:**
Input: Fixed bug where dates displayed incorrectly
Output:
\`\`\`
fix(reports): correct date formatting in timezone conversion
Use UTC timestamps consistently across report generation
\`\`\`
```
### Workflow Pattern
Break complex operations into clear steps with checklists:
```markdown
## Form filling workflow
Copy this checklist and track progress:
\`\`\`
Task Progress:
- [ ] Step 1: Analyze the form
- [ ] Step 2: Create field mapping
- [ ] Step 3: Validate mapping
- [ ] Step 4: Fill the form
- [ ] Step 5: Verify output
\`\`\`
**Step 1: Analyze the form**
Run: \`python scripts/analyze_form.py input.pdf\`
...
```
### Conditional Workflow Pattern
Guide through decision points:
```markdown
## Document modification workflow
1. Determine the modification type:
**Creating new content?** → Follow "Creation workflow" below
**Editing existing content?** → Follow "Editing workflow" below
2. Creation workflow:
- Use docx-js library
- Build document from scratch
...
```
### Feedback Loop Pattern
For quality-critical tasks, implement validation loops:
```markdown
## Document editing process
1. Make your edits
2. **Validate immediately**: \`python scripts/validate.py output/\`
3. If validation fails:
- Review the error message
- Fix the issues
- Run validation again
4. **Only proceed when validation passes**
```
---
## Utility Scripts
Pre-made scripts offer advantages over generated code:
- More reliable than generated code
- Save tokens (no code in context)
- Save time (no code generation)
- Ensure consistency across uses
```markdown
## Utility scripts
**analyze_form.py**: Extract all form fields from PDF
\`\`\`bash
python scripts/analyze_form.py input.pdf > fields.json
\`\`\`
**validate.py**: Check for errors
\`\`\`bash
python scripts/validate.py fields.json
# Returns: "OK" or lists conflicts
\`\`\`
```
Make clear whether the agent should **execute** the script (most common) or **read** it as reference.
---
## Anti-Patterns to Avoid
### 1. Windows-Style Paths
- ✅ Use: `scripts/helper.py`
- ❌ Avoid: `scripts\helper.py`
### 2. Too Many Options
```markdown
# Bad - confusing
"You can use pypdf, or pdfplumber, or PyMuPDF, or..."
# Good - provide a default with escape hatch
"Use pdfplumber for text extraction.
For scanned PDFs requiring OCR, use pdf2image with pytesseract instead."
```
### 3. Time-Sensitive Information
```markdown
# Bad - will become outdated
"If you're doing this before August 2025, use the old API."
# Good - use an "old patterns" section
## Current method
Use the v2 API endpoint.
## Old patterns (deprecated)
<details>
<summary>Legacy v1 API</summary>
...
</details>
```
### 4. Inconsistent Terminology
Choose one term and use it throughout:
- ✅ Always "API endpoint" (not mixing "URL", "route", "path")
- ✅ Always "field" (not mixing "box", "element", "control")
### 5. Vague Skill Names
- ✅ Good: `processing-pdfs`, `analyzing-spreadsheets`
- ❌ Avoid: `helper`, `utils`, `tools`
---
## Skill Creation Workflow
When helping a user create a skill, follow this process:
### Phase 1: Discovery
Gather information about:
1. The skill's purpose and primary use case
2. Storage location (personal vs project)
3. Trigger scenarios
4. Any specific requirements or constraints
5. Existing examples or patterns to follow
If you have access to the AskQuestion tool, use it for efficient structured gathering. Otherwise, ask conversationally.
### Phase 2: Design
1. Draft the skill name (lowercase, hyphens, max 64 chars)
2. Write a specific, third-person description
3. Outline the main sections needed
4. Identify if supporting files or scripts are needed
### Phase 3: Implementation
1. Create the directory structure
2. Write the SKILL.md file with frontmatter
3. Create any supporting reference files
4. Create any utility scripts if needed
### Phase 4: Verification
1. Verify the SKILL.md is under 500 lines
2. Check that the description is specific and includes trigger terms
3. Ensure consistent terminology throughout
4. Verify all file references are one level deep
5. Test that the skill can be discovered and applied
---
## Complete Example
Here's a complete example of a well-structured skill:
**Directory structure:**
```
code-review/
├── SKILL.md
├── STANDARDS.md
└── examples.md
```
**SKILL.md:**
```markdown
---
name: code-review
description: Review code for quality, security, and maintainability following team standards. Use when reviewing pull requests, examining code changes, or when the user asks for a code review.
---
# Code Review
## Quick Start
When reviewing code:
1. Check for correctness and potential bugs
2. Verify security best practices
3. Assess code readability and maintainability
4. Ensure tests are adequate
## Review Checklist
- [ ] Logic is correct and handles edge cases
- [ ] No security vulnerabilities (SQL injection, XSS, etc.)
- [ ] Code follows project style conventions
- [ ] Functions are appropriately sized and focused
- [ ] Error handling is comprehensive
- [ ] Tests cover the changes
## Providing Feedback
Format feedback as:
- 🔴 **Critical**: Must fix before merge
- 🟡 **Suggestion**: Consider improving
- 🟢 **Nice to have**: Optional enhancement
## Additional Resources
- For detailed coding standards, see [STANDARDS.md](STANDARDS.md)
- For example reviews, see [examples.md](examples.md)
```
---
## Summary Checklist
Before finalizing a skill, verify:
### Core Quality
- [ ] Description is specific and includes key terms
- [ ] Description includes both WHAT and WHEN
- [ ] Written in third person
- [ ] SKILL.md body is under 500 lines
- [ ] Consistent terminology throughout
- [ ] Examples are concrete, not abstract
### Structure
- [ ] File references are one level deep
- [ ] Progressive disclosure used appropriately
- [ ] Workflows have clear steps
- [ ] No time-sensitive information
### If Including Scripts
- [ ] Scripts solve problems rather than punt
- [ ] Required packages are documented
- [ ] Error handling is explicit and helpful
- [ ] No Windows-style paths

222
desk/skills-cursor/create-subagent/SKILL.md Normal file
View File

@@ -0,0 +1,222 @@
---
name: create-subagent
description: Create custom subagents for specialized AI tasks. Use when the user wants to create a new type of subagent, set up task-specific agents, configure code reviewers, debuggers, or domain-specific assistants with custom prompts.
disable-model-invocation: true
---
# Creating Custom Subagents
This skill guides you through creating custom subagents for Cursor. Subagents are specialized AI assistants that run in isolated contexts with custom system prompts.
## When to Use Subagents
Subagents help you:
- **Preserve context** by isolating exploration from your main conversation
- **Specialize behavior** with focused system prompts for specific domains
- **Reuse configurations** across projects with user-level subagents
### Inferring from Context
If you have previous conversation context, infer the subagent's purpose and behavior from what was discussed. Create the subagent based on specialized tasks or workflows that emerged in the conversation.
## Subagent Locations
| Location | Scope | Priority |
|----------|-------|----------|
| `.cursor/agents/` | Current project | Higher |
| `~/.cursor/agents/` | All your projects | Lower |
When multiple subagents share the same name, the higher-priority location wins.
**Project subagents** (`.cursor/agents/`): Ideal for codebase-specific agents. Check into version control to share with your team.
**User subagents** (`~/.cursor/agents/`): Personal agents available across all your projects.
## Subagent File Format
Create a `.md` file with YAML frontmatter and a markdown body (the system prompt):
```markdown
---
name: code-reviewer
description: Reviews code for quality and best practices
---
You are a code reviewer. When invoked, analyze the code and provide
specific, actionable feedback on quality, security, and best practices.
```
### Required Fields
| Field | Description |
|-------|-------------|
| `name` | Unique identifier (lowercase letters and hyphens only) |
| `description` | When to delegate to this subagent (be specific!) |
## Writing Effective Descriptions
The description is **critical** - the AI uses it to decide when to delegate.
```yaml
# ❌ Too vague
description: Helps with code
# ✅ Specific and actionable
description: Expert code review specialist. Proactively reviews code for quality, security, and maintainability. Use immediately after writing or modifying code.
```
Include "use proactively" to encourage automatic delegation.
## Example Subagents
### Code Reviewer
```markdown
---
name: code-reviewer
description: Expert code review specialist. Proactively reviews code for quality, security, and maintainability. Use immediately after writing or modifying code.
---
You are a senior code reviewer ensuring high standards of code quality and security.
When invoked:
1. Run git diff to see recent changes
2. Focus on modified files
3. Begin review immediately
Review checklist:
- Code is clear and readable
- Functions and variables are well-named
- No duplicated code
- Proper error handling
- No exposed secrets or API keys
- Input validation implemented
- Good test coverage
- Performance considerations addressed
Provide feedback organized by priority:
- Critical issues (must fix)
- Warnings (should fix)
- Suggestions (consider improving)
Include specific examples of how to fix issues.
```
### Debugger
```markdown
---
name: debugger
description: Debugging specialist for errors, test failures, and unexpected behavior. Use proactively when encountering any issues.
---
You are an expert debugger specializing in root cause analysis.
When invoked:
1. Capture error message and stack trace
2. Identify reproduction steps
3. Isolate the failure location
4. Implement minimal fix
5. Verify solution works
Debugging process:
- Analyze error messages and logs
- Check recent code changes
- Form and test hypotheses
- Add strategic debug logging
- Inspect variable states
For each issue, provide:
- Root cause explanation
- Evidence supporting the diagnosis
- Specific code fix
- Testing approach
- Prevention recommendations
Focus on fixing the underlying issue, not the symptoms.
```
### Data Scientist
```markdown
---
name: data-scientist
description: Data analysis expert for SQL queries, BigQuery operations, and data insights. Use proactively for data analysis tasks and queries.
---
You are a data scientist specializing in SQL and BigQuery analysis.
When invoked:
1. Understand the data analysis requirement
2. Write efficient SQL queries
3. Use BigQuery command line tools (bq) when appropriate
4. Analyze and summarize results
5. Present findings clearly
Key practices:
- Write optimized SQL queries with proper filters
- Use appropriate aggregations and joins
- Include comments explaining complex logic
- Format results for readability
- Provide data-driven recommendations
For each analysis:
- Explain the query approach
- Document any assumptions
- Highlight key findings
- Suggest next steps based on data
Always ensure queries are efficient and cost-effective.
```
## Subagent Creation Workflow
### Step 1: Decide the Scope
- **Project-level** (`.cursor/agents/`): For codebase-specific agents shared with team
- **User-level** (`~/.cursor/agents/`): For personal agents across all projects
### Step 2: Create the File
```bash
# For project-level
mkdir -p .cursor/agents
touch .cursor/agents/my-agent.md
# For user-level
mkdir -p ~/.cursor/agents
touch ~/.cursor/agents/my-agent.md
```
### Step 3: Define Configuration
Write the frontmatter with the required fields (`name` and `description`).
### Step 4: Write the System Prompt
The body becomes the system prompt. Be specific about:
- What the agent should do when invoked
- The workflow or process to follow
- Output format and structure
- Any constraints or guidelines
### Step 5: Test the Agent
Ask the AI to use your new agent:
```
Use the my-agent subagent to [task description]
```
## Best Practices
1. **Design focused subagents**: Each should excel at one specific task
2. **Write detailed descriptions**: Include trigger terms so the AI knows when to delegate
3. **Check into version control**: Share project subagents with your team
4. **Use proactive language**: Include "use proactively" in descriptions
## Troubleshooting
### Subagent Not Found
- Ensure file is in `.cursor/agents/` or `~/.cursor/agents/`
- Check file has `.md` extension
- Verify YAML frontmatter syntax is valid

130
desk/skills-cursor/migrate-to-skills/SKILL.md Normal file
View File

@@ -0,0 +1,130 @@
---
name: migrate-to-skills
description: Convert 'Applied intelligently' Cursor rules (.cursor/rules/*.mdc) and slash commands (.cursor/commands/*.md) to Agent Skills format (.cursor/skills/). Use when the user wants to migrate rules or commands to skills, convert .mdc rules to SKILL.md format, or consolidate commands into the skills directory.
disable-model-invocation: true
---
# Migrate Rules and Slash Commands to Skills
Convert Cursor rules ("Applied intelligently") and slash commands to Agent Skills format.
**CRITICAL: Preserve the exact body content. Do not modify, reformat, or "improve" it - copy verbatim.**
## Locations
| Level | Source | Destination |
|-------|--------|-------------|
| Project | `{workspaceFolder}/**/.cursor/rules/*.mdc`, `{workspaceFolder}/.cursor/commands/*.md` |
| User | `~/.cursor/commands/*.md` |
Notes:
- Cursor rules inside the project can live in nested directories. Be thorough in your search and use glob patterns to find them.
- Ignore anything in ~/.cursor/worktrees
- Ignore anything in ~/.cursor/skills-cursor. This is reserved for Cursor's internal built-in skills and is managed automatically by the system.
## Finding Files to Migrate
**Rules**: Migrate if rule has a `description` but NO `globs` and NO `alwaysApply: true`.
**Commands**: Migrate all - they're plain markdown without frontmatter.
## Conversion Format
### Rules: .mdc → SKILL.md
```markdown
# Before: .cursor/rules/my-rule.mdc
---
description: What this rule does
globs:
alwaysApply: false
---
# Title
Body content...
```
```markdown
# After: .cursor/skills/my-rule/SKILL.md
---
name: my-rule
description: What this rule does
---
# Title
Body content...
```
Changes: Add `name` field, remove `globs`/`alwaysApply`, keep body exactly.
### Commands: .md → SKILL.md
```markdown
# Before: .cursor/commands/commit.md
# Commit current work
Instructions here...
```
```markdown
# After: .cursor/skills/commit/SKILL.md
---
name: commit
description: Commit current work with standardized message format
disable-model-invocation: true
---
# Commit current work
Instructions here...
```
Changes: Add frontmatter with `name` (from filename), `description` (infer from content), and `disable-model-invocation: true`, keep body exactly.
**Note:** The `disable-model-invocation: true` field prevents the model from automatically invoking this skill. Slash commands are designed to be explicitly triggered by the user via the `/` menu, not automatically suggested by the model.
## Notes
- `name` must be lowercase with hyphens only
- `description` is critical for skill discovery
- Optionally delete originals after verifying migration works
### Migrate a Rule (.mdc → SKILL.md)
1. Read the rule file
2. Extract the `description` from the frontmatter
3. Extract the body content (everything after the closing `---` of the frontmatter)
4. Create the skill directory: `.cursor/skills/{skill-name}/` (skill name = filename without .mdc)
5. Write `SKILL.md` with new frontmatter (`name` and `description`) + the EXACT original body content (preserve all whitespace, formatting, code blocks verbatim)
6. Delete the original rule file
### Migrate a Command (.md → SKILL.md)
1. Read the command file
2. Extract description from the first heading (remove `#` prefix)
3. Create the skill directory: `.cursor/skills/{skill-name}/` (skill name = filename without .md)
4. Write `SKILL.md` with new frontmatter (`name`, `description`, and `disable-model-invocation: true`) + blank line + the EXACT original file content (preserve all whitespace, formatting, code blocks verbatim)
5. Delete the original command file
**CRITICAL: Copy the body content character-for-character. Do not reformat, fix typos, or "improve" anything.**
## Workflow
If you have the Task tool available:
DO NOT start to read all of the files yourself. That function should be delegated to the subagents. Your job is to dispatch the subagents for each category of files and wait for the results.
1. [ ] Create the skills directories if they don't exist (`.cursor/skills/` for project, `~/.cursor/skills/` for user)
2. Dispatch three fast general purpose subagents (NOT explore) in parallel to do the following steps for project rules (pattern: `{workspaceFolder}/**/.cursor/rules/*.mdc`), user commands (pattern: `~/.cursor/commands/*.md`), and project commands (pattern: `{workspaceFolder}/**/.cursor/commands/*.md`):
I. [ ] Find files to migrate in the given pattern
II. [ ] For rules, check if it's an "applied intelligently" rule (has `description`, no `globs`, no `alwaysApply: true`). Commands are always migrated. DO NOT use the terminal to read files. Use the read tool.
III. [ ] Make a list of files to migrate. If empty, done.
IV. [ ] For each file, read it, then write the new skill file preserving the body content EXACTLY. DO NOT use the terminal to write these files. Use the edit tool.
V. [ ] Delete the original file. DO NOT use the terminal to delete these files. Use the delete tool.
VI. [ ] Return a list of all the skill files that were migrated along with the original file paths.
3. [ ] Wait for all subagents to complete and summarize the results to the user. IMPORTANT: Make sure to let them know if they want to undo the migration, to ask you to.
4. [ ] If the user asks you to undo the migration, do the opposite of the above steps to restore the original files.
If you don't have the Task tool available:
1. [ ] Create the skills directories if they don't exist (`.cursor/skills/` for project, `~/.cursor/skills/` for user)
2. [ ] Find files to migrate in both project (`.cursor/`) and user (`~/.cursor/`) directories
3. [ ] For rules, check if it's an "applied intelligently" rule (has `description`, no `globs`, no `alwaysApply: true`). Commands are always migrated. DO NOT use the terminal to read files. Use the read tool.
4. [ ] Make a list of files to migrate. If empty, done.
5. [ ] For each file, read it, then write the new skill file preserving the body content EXACTLY. DO NOT use the terminal to write these files. Use the edit tool.
6. [ ] Delete the original file. DO NOT use the terminal to delete these files. Use the delete tool.
7. [ ] Summarize the results to the user. IMPORTANT: Make sure to let them know if they want to undo the migration, to ask you to.
8. [ ] If the user asks you to undo the migration, do the opposite of the above steps to restore the original files.

114
desk/skills-cursor/update-cursor-settings/SKILL.md Normal file
View File

@@ -0,0 +1,114 @@
---
name: update-cursor-settings
description: Modify Cursor/VSCode user settings in settings.json. Use when the user wants to change editor settings, preferences, configuration, themes, font size, tab size, format on save, auto save, keybindings, or any settings.json values.
---
# Updating Cursor Settings
This skill guides you through modifying Cursor/VSCode user settings. Use this when the user wants to change editor settings, preferences, configuration, themes, keybindings, or any `settings.json` values.
## Settings File Location
| OS | Path |
|----|------|
| macOS | ~/Library/Application Support/Cursor/User/settings.json |
| Linux | ~/.config/Cursor/User/settings.json |
| Windows | %APPDATA%\Cursor\User\settings.json |
## Before Modifying Settings
1. **Read the existing settings file** to understand current configuration
2. **Preserve existing settings** - only add/modify what the user requested
3. **Validate JSON syntax** before writing to avoid breaking the editor
## Modifying Settings
### Step 1: Read Current Settings
```typescript
// Read the settings file first
const settingsPath = "~/Library/Application Support/Cursor/User/settings.json";
// Use the Read tool to get current contents
```
### Step 2: Identify the Setting to Change
Common setting categories:
- **Editor**: `editor.fontSize`, `editor.tabSize`, `editor.wordWrap`, `editor.formatOnSave`
- **Workbench**: `workbench.colorTheme`, `workbench.iconTheme`, `workbench.sideBar.location`
- **Files**: `files.autoSave`, `files.exclude`, `files.associations`
- **Terminal**: `terminal.integrated.fontSize`, `terminal.integrated.shell.*`
- **Cursor-specific**: Settings prefixed with `cursor.` or `aipopup.`
### Step 3: Update the Setting
When modifying settings.json:
1. Parse the existing JSON (handle comments - VSCode settings support JSON with comments)
2. Add or update the requested setting
3. Preserve all other existing settings
4. Write back with proper formatting (2-space indentation)
### Example: Changing Font Size
If user says "make the font bigger":
```json
{
"editor.fontSize": 16
}
```
### Example: Enabling Format on Save
If user says "format my code when I save":
```json
{
"editor.formatOnSave": true
}
```
### Example: Changing Theme
If user says "use dark theme" or "change my theme":
```json
{
"workbench.colorTheme": "Default Dark Modern"
}
```
## Important Notes
1. **JSON with Comments**: VSCode/Cursor settings.json supports comments (`//` and `/* */`). When reading, be aware comments may exist. When writing, preserve comments if possible.
2. **Restart May Be Required**: Some settings take effect immediately, others require reloading the window or restarting Cursor. Inform the user if a restart is needed.
3. **Backup**: For significant changes, consider mentioning the user can undo via Ctrl/Cmd+Z in the settings file or by reverting git changes if tracked.
4. **Workspace vs User Settings**:
- User settings (what this skill covers): Apply globally to all projects
- Workspace settings (`.vscode/settings.json`): Apply only to the current project
## Common User Requests → Settings
| User Request | Setting |
|--------------|---------|
| "bigger/smaller font" | `editor.fontSize` |
| "change tab size" | `editor.tabSize` |
| "format on save" | `editor.formatOnSave` |
| "word wrap" | `editor.wordWrap` |
| "change theme" | `workbench.colorTheme` |
| "hide minimap" | `editor.minimap.enabled` |
| "auto save" | `files.autoSave` |
| "line numbers" | `editor.lineNumbers` |
| "bracket matching" | `editor.bracketPairColorization.enabled` |
| "cursor style" | `editor.cursorStyle` |
| "smooth scrolling" | `editor.smoothScrolling` |
## Workflow
1. Read ~/Library/Application Support/Cursor/User/settings.json
2. Parse the JSON content
3. Add/modify the requested setting(s)
4. Write the updated JSON back to the file
5. Inform the user the setting has been changed and whether a reload is needed