菜单
BEFORE presenting or finalizing a fix, especially layout, timing, configuration, serialization, or monitor-geometry logic. Activate when introducing a hardcoded number/timing, boolean behavior flag, special case, migration/compatibility shim, or scope beyond the request.
默认使用会先检查来源的 Prompt；你也可以切换为直接命令，或下载本地副本。
决定是否安装前，请先阅读 SKILL.md，以及 SkillsMP 当前展示的配套文件。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
直接命令不会经过审查 Prompt；运行前请先检查来源。
npx skills add https://github.com/apphane-dev/nehir --skill nehir-solution-robustness命令会保持在同一行。复制前请横向滚动并检查完整内容。
想先保存到本地？可下载 SkillsMP 当前能够提供的文件。
Run a trace-driven, source-backed bug discovery and produce a self-contained discovery document plus a proposed plan. Invoke explicitly with /nehir-bug-discovery when a runtime symptom needs investigation before any code change.
BEFORE writing fixed, works, resolved, bug found, confirmed, verified, root cause, or another success/root-cause claim in an answer, document, changeset, commit message, or worker handoff. Separates observed facts, hypotheses, mechanical validation, user testimony, and user-confirmed runtime behavior. Also activate when attributing a trace event to a code path or writing reproduction steps.
BEFORE writing or updating a discovery, plan, completed write-up, ticket, or other durable document that records a runtime bug, finding, or decision. Checks for ephemeral references, machine-specific paths, unanchored relative language, unsupported claims, stale status words, invented reproduction steps, and user testimony presented as fact.
基于 SOC 职业分类
正在显示 SKILL.md
| name | nehir-solution-robustness |
| description | BEFORE presenting or finalizing a fix, especially layout, timing, configuration, serialization, or monitor-geometry logic. Activate when introducing a hardcoded number/timing, boolean behavior flag, special case, migration/compatibility shim, or scope beyond the request. |
A solution should express the underlying invariant and remain correct across the relevant input space. A value or branch that happens to repair one repro is not sufficient evidence of a robust fix.
Every literal number or timing that controls behavior needs a source:
If a value was chosen by feel because it made one repro pass, stop and derive or measure it. Document genuinely empirical constants.
Before adding a boolean that switches behavior, ask whether the code is really modeling distinct strategies, states, or capabilities. Prefer composition, a small type, or a named policy when that expresses the concept more directly. A boolean is acceptable only when it genuinely models a binary fact rather than coordinating unrelated behavior through conditionals.
The visible symptom may be downstream of the fault. Check whether the proposed solution holds for other windows, monitors, workspaces, or input shapes that use the same mechanism. If it only benefits the one case examined, it is likely a symptom patch.
Migration and compatibility code are for schemas or behavior that users already have in shipped releases. If the state has never shipped, write the intended shape directly.
Preserve, break, or migrate existing behavior only when repository instructions or the user specify which is required. If the choice changes the implementation and no rule defines it, ask before proceeding.
Do not bundle unrelated refactors, renames, or logic changes into the task. Note valuable follow-up work separately.
For layout and geometry, reason through at least the boundary cases relevant to the algorithm: one item, multiple items, a larger count, and different monitor or window dimensions. For state/lifecycle logic, check entry, steady state, interruption, and cleanup.
The proposal states its invariant, explains its constants, covers relevant boundary cases, introduces no unjustified compatibility or migration behavior, and stays within scope. Otherwise report it as a draft or hypothesis rather than a completed solution.