name

stop-notify-external-failure

description

When an external dependency (tool, binary, package) cannot be downloaded or installed from its canonical source (GitHub Releases, PyPI, npm registry, etc.), STOP immediately and notify the user instead of improvising workarounds. Use when Kimi is asked to download, install, or use an external tool and the download/install step fails for any reason (network timeout, 404, DNS failure, rate limit, proxy issue, etc.). Also use when Kimi is tempted to write a homemade replacement, try brute-force alternatives, or proceed without the requested tool.

Stop and Notify on External Dependency Failure

Core Principle

When a required external tool cannot be obtained, STOP and notify the user.

Do NOT:

Try alternative download mirrors without explicit user permission
Write homemade replacements (e.g., re-implementing a format parser in Python)
Try brute-force approaches (e.g., brute-forcing decryption keys, trying random XOR values)
Proceed with a different tool than the one explicitly requested
Silently downgrade to a less capable alternative
Make network/architecture assumptions without confirming with the user

Why This Matters

Respect user intent — The user asked for a specific tool (e.g., "the most-starred GitHub project for X"). Substituting it defeats their purpose.
Avoid wasted effort — Writing a replacement that fails later wastes both the agent's and user's time.
Prevent silent failures — Homemade implementations may produce subtly wrong output that the user only discovers later.
Preserve trust — Users need to know when a dependency is missing so they can provide it or grant workarounds.

Workflow

When instructed to download/install/use an external tool:

1. Attempt download from canonical source (GitHub Release, official package manager, etc.)
   ├── Success → Continue with the task
   └── Failure → GO TO STEP 2

2. STOP. Do not attempt any workaround.

3. Notify the user with:
   - What was attempted (URL, command, tool name)
   - What failed (error message, timeout, 404, etc.)
   - What you need from them (specific filename, proxy config, manual download, etc.)

4. Wait for user response before proceeding.

Examples of Prohibited Workarounds

Failure	What NOT to do
GitHub Release 404	Try random filename variations
GitHub timeout	Switch to an unverified mirror (ghproxy, etc.) without asking
Binary download fails	Write a Python script that "should do the same thing"
Package not on PyPI	Re-implement the package's functionality from scratch
Network unreachable	Make assumptions about user's proxy/VPN configuration
Format parser unavailable	Attempt reverse-engineering the binary format manually

Example Notification

下载失败，已停止

我尝试从 GitHub Release 下载 taurusxin/ncmdump 的 Windows 预编译版本，但失败了：

直接下载：连接超时

镜像下载：同样超时

PowerShell：返回 404（不确定准确的文件名）

请您选择下一步：

如果您能访问 GitHub，请手动下载并放到 D:\tools，我继续配置

如果您使用代理，请提供代理地址，我重试

如果您知道准确的 Release 文件名，请告诉我

Stop and Notify on External Dependency Failure

Core Principle

When a required external tool cannot be obtained, STOP and notify the user.

Do NOT:

Try alternative download mirrors without explicit user permission

Write homemade replacements (e.g., re-implementing a format parser in Python)

Try brute-force approaches (e.g., brute-forcing decryption keys, trying random XOR values)

Proceed with a different tool than the one explicitly requested

Silently downgrade to a less capable alternative

Make network/architecture assumptions without confirming with the user

Why This Matters

Respect user intent — The user asked for a specific tool (e.g., "the most-starred GitHub project for X"). Substituting it defeats their purpose.

Avoid wasted effort — Writing a replacement that fails later wastes both the agent's and user's time.

Prevent silent failures — Homemade implementations may produce subtly wrong output that the user only discovers later.

Preserve trust — Users need to know when a dependency is missing so they can provide it or grant workarounds.

Workflow

When instructed to download/install/use an external tool:

1. Attempt download from canonical source (GitHub Release, official package manager, etc.) ├── Success → Continue with the task └── Failure → GO TO STEP 2 2. STOP. Do not attempt any workaround. 3. Notify the user with: - What was attempted (URL, command, tool name) - What failed (error message, timeout, 404, etc.) - What you need from them (specific filename, proxy config, manual download, etc.) 4. Wait for user response before proceeding.

Examples of Prohibited Workarounds

Failure

What NOT to do

GitHub Release 404

Try random filename variations

GitHub timeout

Switch to an unverified mirror (ghproxy, etc.) without asking

Binary download fails

Write a Python script that "should do the same thing"

Package not on PyPI

Re-implement the package's functionality from scratch

Network unreachable

Make assumptions about user's proxy/VPN configuration

Format parser unavailable

Attempt reverse-engineering the binary format manually

Example Notification

下载失败，已停止

我尝试从 GitHub Release 下载 taurusxin/ncmdump 的 Windows 预编译版本，但失败了：

直接下载：连接超时
镜像下载：同样超时
PowerShell：返回 404（不确定准确的文件名）

请您选择下一步：

如果您能访问 GitHub，请手动下载并放到 D:\tools，我继续配置
如果您使用代理，请提供代理地址，我重试
如果您知道准确的 Release 文件名，请告诉我