Référence IDE 0.x

Cette page documente le comportement de l'IDE 0.x pour les utilisateurs qui n'ont pas encore migré vers la version 1.0. Pour le format actuel, consultez la documentation Features.

Dans l'IDE 0.x, les Hooks étaient stockés dans des fichiers .kiro.hook. Dans l'IDE 1.0, les Hooks ont déménagé vers des fichiers .kiro/hooks/*.json utilisant un schéma JSON versionné.

Dans l'IDE 0.x, les Hooks étaient créés grâce à un formulaire dédié :

1. Accédez à la section Agent Hooks dans le panneau Kiro
2. Cliquez sur le bouton + pour créer un nouveau Hook
3. Choisissez comment vous voulez créer le Hook :
   • Créer manuellement un Hook — ouvre un formulaire avec des champs pour Title, Description, Event, Tool name, File pattern, Action type et Instructions/Command
   • Demander à Kiro de créer un Hook — décrivez un Hook en langage naturel, examinez la configuration générée, puis cliquez sur Save Hook

Les champs du formulaire étaient :

• Title — un nom court pour le Hook
• Description — ce que fait le Hook
• Event — le type de déclencheur (p. ex., File Save, Post Tool Use, Pre Task Execution)
• Tool name — pour les Hooks Pre/Post Tool Use, précisez quels outils doivent correspondre
• File pattern — pour les Hooks d'événement de fichier, précisez quels fichiers doivent correspondre
• Action — choisissez Ask Kiro (requête à l'agent) ou Run Command (commande shell)
• Instructions ou Command — la requête ou la commande shell à exécuter

Vous pouviez également ouvrir l'interface utilisateur des Hooks depuis la Palette de commandes en appuyant sur Cmd + Shift + P (Mac) ou Ctrl + Shift + P (Windows/Linux), puis en tapant Kiro: Open Kiro Hook UI.

Dans l'IDE 1.0, ce formulaire a été remplacé par un flux conversationnel — cliquer sur + préremplit maintenant une requête dans le clavardage et vous travaillez avec l'agent pour configurer le Hook.

• Les fichiers de Hook sont passés de .kiro.hook à .kiro/hooks/*.json
• Nouveau schéma JSON version: "v1" avec des champs structurés when/then
• Les noms et le comportement des déclencheurs restent les mêmes
• Nouveaux champs : name, description, enabled, timeout

{
  "version": "v1",
  "hooks": [
    {
      "name": "format-on-save",
      "description": "Run Prettier on saved TypeScript files",
      "enabled": true,
      "when": {
        "type": "fileEdited",
        "patterns": ["\\.ts$"]
      },
      "then": {
        "type": "command",
        "command": "prettier --write {{filePath}}"
      },
      "timeout": 10
    }
  ]
}

• command — Exécute une commande shell, reçoit le contexte JSON sur stdin
• agent — Injecte une requête dans le contexte de l'agent au moment du déclenchement

Pour tous les détails de la migration, consultez Nouveautés de l'IDE 1.0 — Hooks.

Dans l'IDE 0.x, la bascule Autopilot/Supervised était le seul mécanisme de contrôle du comportement de l'agent. Dans la version 1.0, une couche permissions.yaml basée sur les capacités a été ajoutée en dessous pour un contrôle fin.

L'IDE avait deux modes accessibles via Settings → Agent → Agent Autonomy :

• Autopilot — l'agent procédait à toutes les opérations sans demander de confirmation
• Supervised — l'agent demandait une confirmation avant chaque action

Il n'y avait aucun moyen de permettre certaines opérations tout en bloquant d'autres — c'était tout ou rien.

La bascule Autopilot/Supervised existe toujours et fonctionne comme avant. Ce qui est nouveau, c'est une couche permissions.yaml qui s'applique après le mode d'autonomie :

• Autopilot + permissions — l'agent procède de façon autonome, mais les règles de permissions.yaml peuvent toujours deny (refuser) ou ask (demander) pour des capacités précises
• Supervised + permissions — l'agent demande une confirmation pour tout comme avant, mais les règles allow dans permissions.yaml peuvent préapprouver des opérations fiables afin qu'elles ne déclenchent pas de demande

Cela signifie que vous pouvez utiliser le mode Autopilot sans donner à l'agent un accès sans restriction — refusez les opérations dangereuses tout en permettant aux opérations routinières de se dérouler silencieusement.

Pour la référence complète des permissions, consultez Permissions. Pour les détails de la migration, consultez Nouveautés de l'IDE 1.0 — Permissions.

Dans l'IDE 0.x, l'approbation des commandes de terminal était contrôlée par deux paramètres : Trusted Commands et Command Denylist. Dans la version 1.0, ceci est remplacé par les règles de capacité shell de permissions.yaml.

Configurées dans Settings → Kiro Agent: Trusted Commands au niveau de l'utilisateur ou de l'espace de travail. Utilisait la correspondance de préfixe avec des caractères génériques * :

• ["npm install"] — correspondance exacte seulement
• ["npm install *"] — caractère générique partiel (npm install avec n'importe quels arguments)
• ["npm *", "git *"] — caractère générique complet (n'importe quelle commande npm/git)
• ["*"] — confiance universelle (toutes les commandes approuvées automatiquement)

Règles de correspondance :

• Correspondance de chaîne basée sur le préfixe
• * correspond à tous les caractères après le préfixe
• Les commandes chaînées (&&, |) étaient fiables si la première commande correspondait

Configurée dans Settings → Kiro Agent: Command Denylist. Utilisait la correspondance de sous-chaîne — si un motif refusé apparaissait n'importe où dans la commande, une approbation était requise, quels que soient les paramètres de confiance.

Motifs de liste de refus recommandés :

{
  "kiroAgent.commandDenylist": [
    "rm -rf",
    "sudo",
    "chmod 777",
    "eval",
    "curl | sh",
    "wget | sh",
    "> /dev/",
    "mkfs",
    "dd if="
  ]
}

1. Vérification de la liste de refus (priorité la plus élevée) — si la commande contient un motif refusé, une approbation est requise
2. Vérification de la confiance — si la commande correspond à un motif fiable, approbation automatique
3. Par défaut — approbation manuelle requise

Ces paramètres sont remplacés par les règles de capacité shell de permissions.yaml :

# Equivalent of trustedCommands: ["npm *", "git *"]
rules:
  - capability: shell
    match: ["npm *", "git *"]
    effect: allow

# Equivalent of commandDenylist: ["rm -rf", "sudo"]
  - capability: shell
    match: ["rm -rf *", "sudo *"]
    effect: deny

Principales différences :

• Des motifs génériques (glob) au lieu de la correspondance de préfixe/sous-chaîne
• Le refus a toujours préséance dans tous les champs d'application (pas seulement une prévérification)
• Configurable par espace de travail et par utilisateur dans des fichiers YAML
• L'interface utilisateur des paramètres (kiroAgent.trustedCommands, kiroAgent.commandDenylist) n'est plus utilisée

Pour la référence complète des permissions, consultez Permissions.

Dans l'IDE 0.x, lorsque la fenêtre de contexte atteignait 80 % de la limite du modèle, Kiro résumait tous les messages de la conversation pour ramener la longueur du contexte sous la limite. Un indicateur d'utilisation du contexte dans le panneau de clavardage affichait le pourcentage actuel.

• Renommé de « Summarization » à « Compaction »
• La compaction automatique se produit désormais dans la même session (aucune nouvelle session créée)
• Utilise des résumés structurés basés sur des points de contrôle (tâches, fichiers, décisions, prochaines étapes) plutôt qu'un résumé plat
• L'agent continue dans la même fenêtre de clavardage après la compaction, ce qui maintient la continuité
• Déclenchement manuel via la commande /compact

Pour le comportement actuel, consultez Compaction.

Dans la version 0.x, l'agent disposait d'un outil autonome diagnostics qui lisait la détection d'erreurs en temps réel, la validation syntaxique et les résultats du lint provenant de vos extensions de langage installées pendant l'exécution. L'installation d'extensions de langage et l'ouverture d'un fichier l'activaient automatiquement.

L'outil autonome a été supprimé. L'agent fonctionne toujours avec la connaissance du langage de votre code grâce aux outils d'analyse de code intégrés (read_code, renommage sémantique), et vous pouvez partager explicitement les résultats du serveur de langage avec l'agent en utilisant la clé de contexte #Problems dans le clavardage. Sur la CLI, l'outil code fournit des diagnostics basés sur le LSP en plus de ses autres opérations.

Dans l'IDE 0.x, les configurations d'agent étaient uniquement en JSON et prenaient en charge les mêmes champs que la CLI 2.x.

.kiro/agents/my-agent.json :

{
  "name": "my-agent",
  "description": "A development agent",
  "prompt": "You are a senior developer",
  "model": "claude-sonnet-4",
  "tools": ["fs_read", "fs_write", "execute_bash"],
  "resources": ["file://AGENTS.md"]
}

• Format Markdown ajouté (fichiers .md avec en-tête YAML + corps comme requête système)
• Nouveaux champs : excludedTools, includeMcpJson, includePowers, resources (avec des URI skill://), permissions, welcomeMessage
• Système d'étiquettes — les noms d'outils simplifiés en courtes catégories (read, write, shell, web, @mcp, @builtin, *)
• Les profils d'agent sont rétrocompatibles — les configurations JSON existantes continuent de fonctionner sans modification
• Le champ hooks est réservé à la CLI; l'IDE l'ignore

Pour la référence du format actuel, consultez Agents personnalisés.

Dans l'IDE 0.x, vous choisissiez entre deux types de session au démarrage d'un nouveau clavardage :

• Mode Vibe — programmation conversationnelle libre. L'agent travaillait sans structure, gérant les questions, les modifications et les tâches exploratoires.
• Mode Spec — développement structuré. L'agent vous guidait à travers les phases d'exigences, de conception et de tâches avec des points d'approbation entre chaque phase.

Vous sélectionniez le mode via un sélecteur de mode au lancement d'une nouvelle session.

Le sélecteur de mode Vibe/Spec a été supprimé. À la place :

• Agent par défaut — toutes les sessions commencent avec un agent conversationnel à usage général (équivalent au mode Vibe)
• Sélecteur de flux de travail — à l'ouverture d'une nouvelle session, l'écran « Let's build » propose des flux de travail intégrés (Spec, Plan, Bug Fix, Quick Spec). En sélectionner un change l'agent actif pour cette session.
• Changement en cours de session — changez d'agent à tout moment via le sélecteur d'agent dans la barre de saisie du clavardage. Aucun besoin de décider à l'avance.
• Agents personnalisés — créez des agents spécialisés pour différents flux de travail plutôt que de changer de mode

Cela signifie que vous n'avez plus besoin de décider à l'avance si une session sera « vibe » ou « spec » — vous pouvez commencer de façon conversationnelle et invoquer des flux de travail structurés dès que nécessaire, dans la même session.

Pour l'approche actuelle, consultez Démarrer une session, Agents intégrés et Specs.