Skip to main content

reasoning-receipt

Explain reasoning from first principles in plain words after resolving a conflict (merge conflicts, contradictory requirements, sources that disagree, competing debugging hypotheses, stakeholder trade-offs) or after giving a non-trivial recommendation, answer or analysis. Produces a short receipt naming the competing forces, the deciding principle, the assumptions, and what would break the conclusion.

来源信息

仓库
pipeshub-ai/sharp
最近来源活动
2026年10月15日 14:15
检测到的 SKILL.md 语言
英语
星标
4
Forks
0

安装方式

默认使用会先检查来源的 Prompt;你也可以切换为直接命令,或下载本地副本。

检查来源文件

决定是否安装前,请先阅读 SKILL.md,以及 SkillsMP 当前展示的配套文件。

正在显示 SKILL.md

SKILL.md
来源说明 · 只读预览
name
reasoning-receipt
description
Explain reasoning from first principles in plain words after resolving a conflict (merge conflicts, contradictory requirements, sources that disagree, competing debugging hypotheses, stakeholder trade-offs) or after giving a non-trivial recommendation, answer or analysis. Produces a short receipt naming the competing forces, the deciding principle, the assumptions, and what would break the conclusion.
when_to_use
"Why did you pick that?", "how did you resolve this conflict", "which option should we choose", after a recommendation or analysis that the user will act on. For finished multi-file changes, use change-brief instead; it already contains the key insight.
# Reasoning receipt The aim is to teach a **reusable reasoning move**, not to justify yourself. Keep it to 3–6 lines, in plain language a smart newcomer would follow. ## For a recommendation or answer ``` Reasoning - Core question: <the real question, in one line> - Key insight: <the first-principles fact that decides it> - Assumes: <what must be true; the weakest assumption first> - Breaks if: <the condition that would flip the answer> - Rejected: <best alternative>, because <reason> ``` ## For a conflict ``` How the conflict was resolved - Force A: <wants x> because <underlying need> - Force B: <wants y> because <underlying need> - Deciding principle: <invariant or priority, e.g. "money correctness > latency", "the user's data is never lost"> - So: <resolution> · Cost accepted: <what we gave up> · Revisit if: <trigger> ``` Guidelines: - Name the *underlying need* behind each side, not just its position. Most conflicts dissolve once the needs are visible, and the resolution often satisfies both. - Prefer principles that transfer: invariants, constraints, costs of being wrong, reversibility, who bears the risk. - If the evidence was thin, say so: "Low confidence: based on one log line." - For merge conflicts: state what each branch intended (from commits or PRs), and which intent the merged result preserves.
在 GitHub 查看