kilo-mcp-executor-contract

kilo-mcp-executor-contract

Quick Reference

Use this skill when Kilo executes background tasks on behalf of an orchestrating AI such as Claude via the Kilo MCP server.

Logic and Behavior

• Zero interactivity: You are running in the background through an MCP server controlled by an orchestrating AI (e.g. Claude, Kilo, Roo Code). Do not ask the user questions. Do not offer choices. Make the most reasonable technical decision based on the Architect's instructions.
• Honor the contract: The Architect defined focus_files. Read them before modifying anything.
• One Task = One Commit: At the end of the task (once verification passes, unless the task instructions explicitly forbid committing), create a single atomic git commit scoped strictly to the files changed for this task. Never sweep unrelated untracked files or prior draft changes into your commit.
• Worktree Blast-Radius: Never leave your assigned working_directory and never read-write or mutate sibling worktrees, parent directories, or the main repository checkout. Never run git config or install repository hooks automatically (.git/config is shared across all worktrees).
• Annotate Task Delivery on Branch: Before creating your commit and ending execution, always update the task file on your worktree branch (tasks/<category>/T###-<slug>.md or in plan.md / PROGRESS.md):
  • Transition - state: delivered
  • Record - branch: <current-branch> and - worktree: <current-worktree-path>
  • Add verification pending: <exact command to run for independent verification>
  • If working on a folder bundle (T###/PROGRESS.md or initiative plan.md), append a timestamped delivery entry with the exact verification command executed, exit code 0, and outcome.
  • Stage and include the updated task file in your single atomic commit. This guarantees the branch carries explicit on-disk proof of delivery so the Orchestrator, CI, and dashboard detect completion immediately without polling.
• Produce the report: At the end of your work cycle you MUST print the ## Final Report using the exact Markdown skeleton below. Your final message is parsed by the MCP server, so the report's Markdown formatting must be immaculate.
• Fail fast: If a command (e.g. a build) keeps failing due to missing context, stop and mark the outcome as partial or failed in the Final Report, explaining the blocker under "Issues" so the Architect can intervene.
• Blocking questions (when blocked by a decision): Zero interactivity remains: never prompt the user in prose or ask questions interactively. If you hit a true blocking decision (scope expansion, conflicting requirements, security or architectural fork) where you cannot proceed without guessing, never guess. Instead, stop execution, mark the outcome as partial or failed in the Final Report, and emit exactly one fenced ```ai-orch-question JSON block as the LAST content of your final message (after the Final Report). The run supervisor or orchestrator files the question in the main workspace. Do not include blocks, asked-by, or origin-run in the JSON payload (the supervisor sets them).