kimi-challenge

kimi:challenge

Forward an adversarial challenge-review request to the shared companion runtime and return the markdown output verbatim. The framing is "is this approach right?" not "are there bugs?".

Context: The user says, "Have Kimi challenge this design before I commit it." Why this triggers: The user is explicitly asking for adversarial pushback on the chosen approach. Context: The user says, "Get Kimi to argue the other side — what would break this?" Why this triggers: The user is asking for the alternative-perspective framing, not a defect review. Context: The main Claude thread has just made a non-obvious design choice and the user says, "Stress test this." Why this triggers: Design-level stress testing is the canonical kimi-challenge target.

Runtime instructions

When invoked:

• decide whether the task belongs to adversarial challenge review rather than ordinary defect review (see kimi-review)
• preserve any focus text the user supplies after the flags — the user's framing is what steers the challenge
• call the shared companion runtime with exactly one Bash invocation: ${CLAUDE_PLUGIN_ROOT}/scripts/companion.sh task challenge <args>
• if the companion reports CHALLENGE_HOOK_NOT_INSTALLED, surface the refusal and tell the user to run /kimi:setup; do not reach for KIMI_PLUGIN_CC_SKIP_HOOK_CHECK
• the companion accepts a strict allowlist of flags: --base <ref>, -m/--model <name>. Everything else is trailing focus text — adversarial framing, not a content channel. Kimi's extended reasoning is always on; the parser hard-rejects --thinking/--no-thinking
• do not invent flags (--file, --context, --path, etc.). The runtime hard-fails with INVALID_ARGS on unknown flag-shaped tokens. If you need to attach file content or extended context, switch to kimi-ask or paste a brief summary into the focus text — challenge's payload is the git diff, not arbitrary file content
• do not pass --background or --wait to the companion — the runtime rejects both with INVALID_FLAGS for review and challenge
• if the user wants fire-and-forget behavior on a broad challenge, detach the Bash call itself with run_in_background: true instead of reaching for a companion flag; after launching, tell the user to check /kimi:status for progress
• /kimi:result <jobId> --json returns a structured envelope with metadata plus the artifact body.

When challenge completes:

• return the companion stdout verbatim — do not soften the adversarial framing or rewrite findings into defect form
• if Kimi returns no findings, surface that explicitly rather than implying the challenge was skipped
• treat an empty companion stdout as a hard failure and surface it (challenge output is pass-through prose; the runtime only fails on empty final text)

Do not inspect the repository yourself, do not implement the alternatives Kimi raises, and do not turn challenge into a planning agent. If the user wants edits, switch to the kimi-rescue agent or /kimi:rescue.