Modifications de la configuration des agents

Les profils d'agent sont rétrocompatibles — les configurations existantes continuent de fonctionner. Le harnais d'agent unifié ajoute de nouveaux champs facultatifs et une option de format Markdown.

.kiro/agents/my-agent.json :

{
  "name": "my-agent",
  "description": "A development agent",
  "prompt": "file://resources/MY_PROMPT.md",
  "model": "claude-sonnet-4",
  "tools": ["fs_read", "fs_write", "execute_bash", "grep", "glob", "code"],
  "toolsSettings": {
    "execute_bash": {
      "allowedCommands": ["^git status$", "^cargo build[^&;]*$"],
      "deniedCommands": ["^rm -rf"],
      "denyByDefault": false
    },
    "fs_read": {
      "allowedPaths": ["src/**", "docs/**"],
      "deniedPaths": [".env", "secrets/**"]
    },
    "fs_write": {
      "allowedPaths": ["src/**"],
      "deniedPaths": ["*.lock"]
    }
  },
  "resources": ["file://AGENTS.md"],
  "hooks": {
    "agentSpawn": [{ "command": "git status", "description": "Add git context" }]
  },
  "welcomeMessage": "Hello! How can I help?"
}

Les deux formats sont pris en charge. Utilisez Markdown lorsque votre requête système est longue ou profite d'une meilleure lisibilité humaine; JSON fonctionne bien pour les configurations générées de façon programmatique. Il n'y a aucune différence fonctionnelle — les champs sont identiques d'un format à l'autre.

.kiro/agents/backend-dev.md :

---
name: backend-dev
description: Backend development agent
model: claude-sonnet-4-20250514
tools: ["read", "write", "shell", "web"]
excludedTools: ["knowledge"]
includeMcpJson: true
includePowers: false
mcpServers:
  postgres:
    command: npx
    args: ["-y", "@modelcontextprotocol/server-postgres"]
    env:
      DATABASE_URL: "${DATABASE_URL}"
resources:
  - file://./ARCHITECTURE.md
  - skill://backend-patterns
permissions:
  rules:
    - capability: shell
      match: ["npm *", "node *"]
      effect: allow
welcomeMessage: "Ready to work on backend code."
---

You are a backend developer focused on Node.js and TypeScript.
Always use async/await. All database queries must be parameterized.

V3 sépare la visibilité des outils de leur autorisation en deux systèmes distincts.

Les étiquettes (dans le champ tools) contrôlent quels outils l'agent peut voir et invoquer. Utilisez des noms de catégorie courts — les nouveaux outils ajoutés à une catégorie deviennent automatiquement accessibles :

Les capacités (dans le champ permissions) contrôlent ce que ces outils peuvent faire au moment de l'invocation — approbation automatique, blocage ou confirmation requise. Elles utilisent des noms de capacité (fs_read, fs_write, shell, etc.) qui ne correspondent pas 1:1 aux étiquettes.

Exemple : tools: ["web"] donne à l'agent les outils web_fetch et web_search. Mais dans les permissions, ce sont des capacités distinctes — vous pouvez allow (autoriser) web_fetch pour la documentation tout en deny-ant (refusant) web_search.

Remarque : toolsSettings est retiré dans V3 — migrez les règles par outil vers le bloc permissions unifié. Consultez Migration des permissions →.

Prend en charge les transports stdio et HTTP. Les serveurs stdio acceptent un champ timeout (en millisecondes). Les serveurs HTTP acceptent des headers. Les deux résolvent les variables d'environnement au moment de l'exécution selon la syntaxe ${VAR}.

La migration de la configuration des agents est terminée. Si vos agents utilisaient des Hooks intégrés, poursuivez avec la migration des hooks →.