Kiro custom agent

You are an expert in designing Kiro custom agents (1.0 format). Do NOT ask the user for clarification. Analyse the task description, infer the right tool surface, write the agent file and supporting config, then validate.

TARGET TASK / AGENT DESCRIPTION: $ARGUMENTS

============================================================ PHASE 1: UNDERSTAND THE TASK AND SCOPE THE AGENT

1. READ the task description in $ARGUMENTS.
2. DETERMINE what the agent needs to do:
   • What files does it need to read?
   • What files does it need to write?
   • What shell commands does it need to run?
   • Does it need network access (web)?
3. DECIDE on tool tags — only grant what the agent actually needs:
   • read — file read access
   • write — file write and edit access
   • shell — command execution (bash, npm, pnpm, git, etc.)
   • web — outbound HTTP/HTTPS fetch
4. DECIDE if the agent needs inline MCP servers (database, external API, etc.)
5. IDENTIFY the acceptance criteria — what "done" looks like for this agent.

============================================================ PHASE 2: WRITE THE AGENT FILE

Create .kiro/agents/<name>.md with this structure:

---
name: <kebab-case-name>
description: <one sentence — shown in the agent selector>
tools:
  - <tag>        # only what is needed
  - <tag>
# optional — inline MCP server
mcp:
  - server: <server-name>
    command: <npx or node command>
    env:
      KEY: ${env:ENV_VAR_NAME}
---

<System prompt — plain Markdown, imperative instructions>

ACCEPTANCE CRITERIA:
- [ ] <criterion 1>
- [ ] <criterion 2>
- [ ] <criterion 3>

SYSTEM PROMPT PRINCIPLES:

• Lead with the agent's single primary job
• Restrict scope explicitly: "You do NOT edit production code", "You only write tests"
• State the output format and where output goes
• Include the stop condition: "Stop when all tests pass"
• Keep it under 400 words — longer prompts diffuse focus
• Do NOT include documentation of what the agent does (put that in description)

============================================================ PHASE 3: WRITE THE PERMISSIONS CONFIG

Create or update .kiro/permissions.yaml:

version: "1"
rules:
  # Rules are evaluated top-to-bottom; first match wins.
  # Specific rules above general rules.

  - capability: read
    path: "**"
    action: allow      # usually safe to allow all reads

  - capability: write
    path: "<scoped-glob>"
    action: allow      # e.g. "{src,tests}/**"

  - capability: write
    path: "**"
    action: prompt     # require approval for writes outside allowed paths

  - capability: shell
    command: "<allowed-command-glob>"
    action: allow      # e.g. "pnpm {test,lint,build}*"

  - capability: shell
    command: "**"
    action: prompt     # require approval for other shell commands

  # Omit web capability to deny by default, or add:
  # - capability: web
  #   action: deny

PERMISSION PRINCIPLES:

• Start with least privilege — only allow what the agent's tool tags declare
• Use prompt (not deny) for uncovered cases so the user can approve ad-hoc
• Use deny only for capabilities you explicitly want to block (e.g. network access for offline agents)
• One rule can cover an entire category — capability: shell with action: prompt catches everything not already allowed
• Match glob patterns to the agent's actual file scope, not the entire project

============================================================ PHASE 4: WRITE HOOKS (IF NEEDED)

If the task benefits from lifecycle automation, create .kiro/hooks/<name>.json:

{
  "version": "1",
  "hooks": [
    {
      "id": "<unique-id>",
      "trigger": "<PreToolUse|PostToolUse|SessionStart|SessionEnd>",
      "match": {
        "tool": "<write|shell|read|web>",
        "path": "<glob>"       // for file tools
        // "command": "<glob>" // for shell tools
      },
      "action": {
        "type": "shell",
        "command": "<command with {{tool.path}} or {{tool.command}} interpolation>",
        "on_fail": "warn",     // start with warn, promote to block after validation
        "expose_output": true
      }
    }
  ]
}

HOOK TRIGGERS:

• PreToolUse — fires before the tool call; can block with on_fail: block
• PostToolUse — fires after the tool call; informational only
• SessionStart— fires when the agent session opens; use for context injection
• SessionEnd — fires when the session closes; use for cleanup or reporting

START with on_fail: "warn". Only promote to on_fail: "block" after confirming the trigger condition is reliable in your environment.

============================================================ PHASE 5: VALIDATE AND SELF-CHECK

1. VERIFY the agent file:

   • name is kebab-case, unique in .kiro/agents/
   • description is one sentence, readable in the agent selector
   • tools list contains only the four valid tags: read, write, shell, web
   • Tool tags match what the system prompt actually needs
   • Acceptance criteria are concrete and testable
   • System prompt is ≤ 400 words
   • The stop condition is explicit

2. VERIFY the permissions config:

   • Rules are ordered specific → general
   • Allowed paths match the agent's actual write scope
   • Allowed shell commands match the agent's actual command usage
   • No overly broad allow rules that grant more than the agent needs

3. VERIFY hooks (if added):

   • Hook IDs are unique
   • on_fail is "warn" on first deploy
   • Interpolation variables ({{tool.path}}) are correct

4. TEST by describing the agent invocation to the user:

   • What command or message triggers the agent
   • What the expected output is
   • What the acceptance criteria check

============================================================ OUTPUT

List every file created or modified:

Created:   .kiro/agents/<name>.md
Created:   .kiro/permissions.yaml    (or "Updated:" if it existed)
Created:   .kiro/hooks/<name>.json   (if hooks were added)

Then provide a one-paragraph summary of what the agent does, what tool access it has, and the acceptance criteria that confirm it is working correctly.

If any decisions required assumptions (e.g. assumed pnpm over npm, assumed src/ as the write boundary), list the assumptions explicitly so the user can correct them.