---
name: what-does-model-think
description: Use What Does Khimba Think? — AI Second Opinions to ask a selected, different AI model for an independent, paid review through Khimba. Trigger when the user asks what Claude, Kimi, DeepSeek or another model thinks; wants a second opinion on code, a plan, document or decision; or requests an independent critique.
---

# What Does Khimba Think? — AI Second Opinions

## Setup and account questions

Treat installation, MCP authorisation and a Khimba account as separate states. Never infer one from another:

- **Complete plugin:** the Codex or Claude Code package contains both this skill and the remote MCP configuration.
- **Direct MCP:** the Khimba tools are connected, but the companion skill is not installed by that command.
- **MCP authorisation:** the host has a working OAuth credential. OAuth offers two explicit choices: **Sign in to Khimba** for a permanent account with stable reconnect, or **Continue as guest** for a temporary unclaimed identity.
- **Account:** `guest_unclaimed` can use the temporary promotion and may be claimed; `claimed` is attached to an interactive Khimba identity and can be selected again during a later OAuth login. Report `unknown` when the tools cannot verify it.

For “is this installed?”, inspect the host-visible skill/plugin and MCP tool state. Report both explicitly. Until a verified public marketplace listing exists, say that the complete Codex plugin is packaged but not publicly listed; describe `codex mcp add` as the available tools-only route.

For “am I logged in?”, “check my balance” or similar account questions, call `account_status` when available. State OAuth authorisation separately from `kind` and `claimed`. Report the currency, spendable/available balance, reserved balance, paid and promotional portions, promotion expiry and remaining calls when returned; do not imply displayed promotional credit is spendable if it is expired or exhausted.

For “how do I log in?”, explain the verified current state. For a fresh or disconnected session, start the host-supported MCP OAuth flow and tell the user to choose **Sign in to Khimba** for a permanent account and stable reconnect, or **Continue as guest** for temporary access. If the caller already has an unclaimed guest session and wants to preserve it, account claiming is the relevant next step; reconnecting OAuth as a guest does not claim it.

For “claim my Khimba account”, call `start_account_claim` only for an unclaimed guest. Return the short-lived URL and say that opening it does not complete the claim: the user must finish interactive sign-in, then the agent must call `account_status` again before reporting success. Never say a claim succeeded from URL creation alone.

Use these status labels in setup answers: `plugin_complete`, `mcp_tools_only`, `oauth_authorised`, `oauth_required`, `guest_unclaimed`, `claimed`, and `unknown`. Include only labels supported by observed host state or tool results.

Describe the guest promotion completely wherever it affects a decision: up to USD 0.10, limited to three successful calls and expiring 24 hours after guest creation. The usable promotion ends when any one of the credit, call or time limits is reached. Do not call it an unrestricted balance or imply that every displayed promotional amount remains spendable.

## Opinion workflow

1. Infer the requested model, subject and focus from the conversation. Do not ask for information already supplied.
2. Call `prepare_model_opinion`. Ask exactly the clarification it returns. Never silently replace an unavailable or ambiguous model; present the returned enabled alternatives and prices.
3. When context is required, resolve this skill's directory and run `node <skill-directory>/scripts/collect-context.mjs --root <repository> --subject-kind <kind> [--files <paths...>]`. Treat the output as local and sensitive. Do not upload it yet. Never assume a global collector is installed.
4. Show one concise confirmation containing the exact model, subject, focus, file paths and count, estimated tokens, maximum charge and available balance. Explain that confirmation sends the listed evidence to Khimba. Stop without upload or reservation if the user declines.
5. After confirmation, call `what_does_model_think` with the confirmed specification, manifest and artifacts. If the manifest changes or the server reports a higher price, reconfirm.
6. Poll `get_opinion` while queued or running. Return the opinion, assumptions, risks, recommendations, charge and remaining balance. Preserve partial results and their measured charge when reported.
7. Write report Markdown to disk only when the user explicitly asks for a file.
8. If and only if the user explicitly asks to send Khimba product feedback, show the exact rating, category, message and linked opinion request before calling `submit_feedback`. Never infer, auto-submit or silently submit feedback.

Use MCP elicitation when available. Otherwise render the server's machine-readable `questions` and `choices` naturally. If credit is insufficient, explain the guest allowance and call `create_top_up` only after the user chooses an amount.

Third-party model names identify requested provider models; Khimba is not affiliated with those providers unless explicitly stated by the service.
