Steering

Le Steering donne à Kiro une connaissance persistante de votre projet grâce à des fichiers markdown. Plutôt que d'expliquer vos conventions dans chaque conversation, les fichiers de Steering veillent à ce que Kiro respecte toujours vos modèles, bibliothèques et normes établis.

Génération de code cohérente - Chaque composant, point de terminaison d'API ou test suit les modèles et conventions établis par votre équipe.

Répétition réduite - Plus besoin d'expliquer les normes du projet à chaque conversation. Kiro se souvient de vos préférences.

Alignement de l'équipe - Tous les développeurs travaillent selon les mêmes normes, qu'ils soient nouveaux dans le projet ou contributeurs expérimentés.

Connaissance évolutive du projet - Une documentation qui évolue avec votre code source, en consignant les décisions et les modèles au fil de l'évolution de votre projet.

Les fichiers de Steering peuvent être créés avec une portée d'espace de travail ou une portée globale.

Les fichiers de Steering d'espace de travail se trouvent dans le dossier racine de votre projet, sous .kiro/steering/, et ne s'appliquent qu'à cet espace de travail précis. Les fichiers de Steering d'espace de travail peuvent être utilisés pour informer Kiro des modèles, bibliothèques et normes propres à un espace de travail donné.

Les fichiers de Steering global se trouvent dans votre répertoire personnel, sous ~/.kiro/steering/, et s'appliquent à tous les espaces de travail. Les fichiers de Steering global peuvent être utilisés pour informer Kiro des conventions qui s'appliquent à tous vos espaces de travail.

En cas d'instructions contradictoires entre le Steering global et le Steering d'espace de travail, Kiro donnera priorité aux instructions du Steering d'espace de travail. Cela vous permet de définir des directives globales qui s'appliquent généralement à tous vos espaces de travail, tout en conservant la possibilité de les remplacer pour des espaces de travail précis.

La fonctionnalité de Steering global peut être utilisée pour définir des fichiers de Steering centralisés qui s'appliquent à des équipes entières. Les fichiers de Steering d'équipe peuvent être déployés sur les ordinateurs des utilisateurs via des solutions MDM ou des politiques de groupe, ou téléchargés par les utilisateurs sur leur ordinateur à partir d'un dépôt central, puis placés dans le dossier ~/.kiro/steering.

Kiro fournit des fichiers de Steering de projet pour établir le contexte de base du projet :

Aperçu du produit (product.md) - Définit l'objectif de votre produit, ses utilisateurs cibles, ses principales fonctionnalités et ses objectifs d'affaires. Cela aide Kiro à comprendre le « pourquoi » des décisions techniques et à proposer des solutions alignées sur les objectifs de votre produit.

Pile technologique (tech.md) - Documente les cadres, bibliothèques, outils de développement et contraintes techniques que vous avez choisis. Lorsque Kiro propose des implémentations, il privilégiera votre pile établie plutôt que des solutions de remplacement.

Structure du projet (structure.md) - Décrit l'organisation des fichiers, les conventions de nommage, les modèles d'importation et les décisions architecturales. Cela aide le code généré à s'intégrer à votre code source existant.

Ces fichiers de base sont inclus dans chaque interaction par défaut, et constituent la base de la compréhension du projet par Kiro.

Enrichissez la compréhension de Kiro grâce à des directives spécialisées adaptées aux besoins uniques de votre projet.

Lorsque vous utilisez des agents personnalisés, les fichiers de Steering ne sont pas inclus automatiquement. Vous devez les ajouter explicitement à la configuration resources de l'agent pour charger le contexte de Steering.

Pour inclure tous les fichiers de Steering dans un agent personnalisé, ajoutez ce qui suit à la configuration de votre agent :

{
  "resources": ["file://.kiro/steering/**/*.md"]
}

Ce modèle global fait en sorte que tous les fichiers markdown de votre répertoire de Steering soient chargés lors de l'utilisation de l'agent. Consultez la documentation sur les agents personnalisés pour un exemple de configuration complet.

Kiro prend en charge la fourniture de directives de Steering via la norme AGENTS.md. Les fichiers AGENTS.md sont en format markdown, semblable à celui des fichiers de Steering de Kiro; toutefois, les fichiers AGENTS.md ne prennent pas en charge les modes d'inclusion et sont toujours inclus.

Vous pouvez ajouter des fichiers AGENTS.md à l'emplacement des fichiers de Steering global (~/.kiro/steering/), ou au dossier racine de votre espace de travail, et ils seront pris en compte automatiquement par Kiro.

Les fichiers AGENTS.md sont également détectés dans les sous-répertoires de votre espace de travail. Cela vous permet de placer un fichier AGENTS.md à côté du code qu'il décrit — par exemple, un dans services/api/ et un autre dans packages/ui/ — et chacun est chargé comme contexte de Steering avec vos autres fichiers de Steering.

Les fichiers de Steering peuvent être configurés pour se charger à différents moments selon vos besoins. Cette flexibilité permet d'optimiser la performance et de garantir que le contexte pertinent est disponible au bon moment.

Configurez les modes d'inclusion en ajoutant un en-tête au tout début de vos fichiers de Steering. Cet en-tête utilise la syntaxe YAML et doit être placé au tout début du fichier, entre triples tirets (---).

---
inclusion: always
---

Ces fichiers sont chargés automatiquement dans chaque interaction avec Kiro. Utilisez ce mode pour les normes de base qui devraient influencer toute génération de code et toute suggestion. Par exemple, votre pile technologique, vos conventions de programmation et vos principes architecturaux fondamentaux.

Idéal pour : les normes à l'échelle de l'espace de travail, les préférences technologiques, les politiques de sécurité et les conventions de programmation qui s'appliquent universellement.

---
inclusion: fileMatch
fileMatchPattern: "components/**/*.tsx"
---

Les fichiers sont inclus automatiquement seulement lorsque vous travaillez sur des fichiers correspondant au modèle précisé. Cela permet de garder le contexte pertinent et de réduire le bruit en ne chargeant les directives spécialisées que lorsque nécessaire.

Vous pouvez aussi préciser plusieurs modèles à l'aide d'un tableau :

---
inclusion: fileMatch
fileMatchPattern: ["**/*.ts", "**/*.tsx", "**/tsconfig.*.json"]
---

Modèles courants :

• "*.tsx" - Composants React et fichiers JSX
• "app/api/**/*" - Routes d'API et logique de back-end
• "**/*.test.*" - Fichiers de test et utilitaires de test
• "src/components/**/*" - Directives propres aux composants
• "*.md" - Fichiers de documentation
• ["**/*.ts", "**/*.tsx"] - Tous les fichiers TypeScript
• ["*.js", "*.jsx", "*.ts", "*.tsx"] - Tous les fichiers JavaScript et TypeScript

Idéal pour : les normes propres à un domaine, comme les modèles de composants, les règles de conception d'API, les approches de test ou les procédures de déploiement qui ne s'appliquent qu'à certains types de fichiers.

---
inclusion: manual
---

Les fichiers sont accessibles sur demande en y faisant référence avec #nom-du-fichier-de-steering dans vos messages de clavardage. Cela vous donne un contrôle précis sur le moment où un contexte spécialisé est nécessaire, sans encombrer chaque interaction.

Utilisation : Tapez #troubleshooting-guide ou #performance-optimization dans le clavardage pour inclure ce fichier de Steering dans la conversation en cours. Les fichiers de Steering manuels apparaissent aussi comme commandes barre oblique - tapez / dans le clavardage pour les voir et les sélectionner.

Idéal pour : les flux de travail spécialisés, les guides de dépannage, les procédures de migration ou la documentation lourde en contexte qui n'est nécessaire qu'à l'occasion.

---
inclusion: auto
name: api-design
description: REST API design patterns and conventions. Use when creating or modifying API endpoints.
---

Les fichiers sont inclus automatiquement lorsque votre requête correspond à la description. Cela fonctionne de façon similaire aux Skills - Kiro utilise la description pour déterminer quand le fichier de Steering est pertinent.

Les fichiers de Steering à inclusion automatique apparaissent aussi comme commandes barre oblique dans le clavardage. Tapez / suivi du nom du fichier de Steering pour l'inclure explicitement, en plus de l'activation automatique basée sur la correspondance de la description.

Idéal pour : les directives lourdes en contexte qui ne devraient se charger que lorsque pertinentes - comme les connaissances spécialisées d'un domaine, les flux de travail complexes ou la documentation de référence détaillée qui surchargerait un Steering toujours actif.

Créez des liens vers des fichiers actifs de l'espace de travail pour garder le Steering à jour :

#[[file:<relative_file_name>]]

Exemples :

• Spécifications d'API : #[[file:api/openapi.yaml]]
• Modèles de composants : #[[file:components/ui/button.tsx]]
• Modèles de configuration : #[[file:.env.example]]

En plus des fichiers de Steering persistants, vous pouvez orienter Kiro en temps réel pendant une session en donnant des directives dans le clavardage :

• « Utilise le modèle de gestion des erreurs déjà existant dans le dépôt »
• « Suis la même approche que la classe UserService »
• « Assure-toi d'ajouter des tests d'intégration, pas seulement des tests unitaires »

Sur Kiro Web, vous pouvez orienter l'agent en laissant des commentaires sur les pull requests. Lorsque vous commentez une PR avec une directive comme « utilise toujours notre gestion standard des erreurs » ou « respecte nos conventions de nommage », l'agent apprend et applique ces modèles aux travaux futurs dans tous vos dépôts.

Seuls vos commentaires (l'utilisateur ayant créé la tâche) influencent l'apprentissage de l'agent. Les commentaires des autres réviseurs n'ont aucune incidence sur ce que l'agent apprend.

Gardez les fichiers ciblés - Un domaine par fichier - conception d'API, tests ou procédures de déploiement.

Utilisez des noms clairs :

• api-rest-conventions.md - Normes d'API REST
• testing-unit-patterns.md - Approches de tests unitaires
• components-form-validation.md - Normes des composants de formulaire

Incluez le contexte - Expliquez pourquoi les décisions ont été prises, pas seulement quelles sont les normes.

Fournissez des exemples - Utilisez des extraits de code et des comparaisons avant/après pour illustrer les normes.

Sécurité avant tout - N'incluez jamais de clés d'API, de mots de passe ou de données sensibles. Les fichiers de Steering font partie de votre code source.

Assurez un entretien régulier :

• Passez-les en revue lors de la planification de sprint et des changements d'architecture
• Testez les références de fichiers après une restructuration
• Traitez les changements de Steering comme des changements de code - exigez des revues

Normes d'API (api-standards.md) - Définissez les conventions REST, les formats de réponse d'erreur, les flux d'authentification et les stratégies de gestion des versions. Incluez les modèles de nommage des points de terminaison, l'utilisation des codes d'état HTTP et des exemples de requêtes/réponses.

Approche de test (testing-standards.md) - Établissez les modèles de tests unitaires, les stratégies de tests d'intégration, les approches de simulation et les attentes en matière de couverture. Documentez les bibliothèques de test privilégiées, les styles d'assertion et l'organisation des fichiers de test.

Style de code (code-conventions.md) - Précisez les modèles de nommage, l'organisation des fichiers, l'ordre des importations et les décisions architecturales. Incluez des exemples de structures de code privilégiées, de modèles de composants et d'anti-modèles à éviter.

Directives de sécurité (security-policies.md) - Documentez les exigences d'authentification, les règles de validation des données, les normes d'assainissement des entrées et les mesures de prévention des vulnérabilités. Incluez des pratiques de programmation sécurisées propres à votre application.

Processus de déploiement (deployment-workflow.md) - Décrivez les procédures de compilation, les configurations d'environnement, les étapes de déploiement et les stratégies de retour en arrière. Incluez les détails du pipeline CI/CD et les exigences propres à chaque environnement.

• Skills - Ensembles d'instructions modulaires à la demande pour les flux de travail spécialisés
• Hooks - Automatisez les actions de l'agent en fonction d'événements
• Custom Agents - Créez des agents spécialisés avec un Steering adapté