Goudi

Goudi

For Chinese readers, see SKILL.zh_CN.md. The English SKILL.md is the execution source of truth.

Overview

Use this skill when a discussion has too much ambition and too little executable grounding. goudi is the counterweight to geju: geju opens the frame; goudi forces the move to land.

This skill is not about being timid, conservative, or anti-refactor. It is about making the chosen direction survivable, verifiable, reversible where possible, and useful in the next concrete step.

Core Principle

先把路踩实，再谈大胜利。

Big ideas are allowed. Sweeping redesigns are allowed. Strong architecture opinions are allowed. But a useful proposal must answer:

• What is the smallest move that proves this direction?
• What evidence says the move is working?
• What real constraint can break it?
• What should be deliberately cut from the first attempt?
• Where is the stop rule if the thesis is wrong?

If the answer cannot produce a concrete first move, it is not a plan yet. It is only a mood.

goudi and geju are a designed pair:

• geju: "What is the clean target if we stop being scared?"
• goudi: "What is the first proof that this target can survive contact with reality?"

Do not let goudi erase the bold target. Compress the first step, not the ambition.

Workflow

1. Restate the bold direction in one sentence. Do not flatten the ambition. Name where it came from — geju, a PRD, an architecture review, or the user's idea.

2. Run a reality check. Scan for the five anti-patterns, then name the constraints they expose:

• Vision without first step — sounds right, but nobody knows what to do this afternoon.
• Fake migration plan — clean target, but the path assumes everything changes at once.
• Unpriced risk — "we can refactor" with no cost on data loss, blast radius, missing tests, or hidden callers.
• Long-term correct, short-term irresponsible — the full thing now would starve the current goal.
• No stop rule — the plan can only continue; it cannot fail gracefully.

Then answer: what real contracts constrain the work? What area carries the most blast radius? What assumptions are unproven? What part is mostly aesthetic, speculative, or premature? For the per-pattern counter-moves, read references/anti-patterns.md.

3. Choose the minimum viable move. Pick one narrow vertical slice, proof point, or decision artifact. Define what it changes and what it refuses to change. Prefer something that creates evidence, not just more planning.

4. Make verification explicit. Success criteria must be observable; failure signals must be named; the check must be cheap enough to run before confidence decays. If behavior needs to be driven by tests, route to hai-tdd.

5. Cut scope aggressively. List what the first move should not attempt. Cut compatibility work not tied to a real contract, architecture polish that does not affect the proof point, and broad migration until the narrow slice is proven.

6. Define the stop rule. What evidence would kill or pause this direction? What would force a smaller target? What can be rolled back or isolated? What decision should not be made yet?

Output

Produce the answer using references/output-template.md — load it before drafting. It fixes the section order: Landing Judgment / Bold Direction Kept / Reality Check / Minimum Viable Move / Verification / Cut List / Stop Rule / Next Move.

Beyond the template's per-field shape, hold these constraints:

• Lead with the verdict — go / shrink / pause / reject / validate first — not with the analysis.
• Name real constraints separately from anxiety or inertia.
• Preserve the bold target when it is useful, but do not let it replace execution.
• The default is a smaller proof, not paralysis. Do not turn goudi into "do nothing."
• Do not write a giant plan; route to hai-goal when the output needs phases, todos, and execution tracking.

Route elsewhere when

• The goal is to open the frame, escape compatibility fear, and think bigger — use geju. (goudi grounds an already opened frame; it does not open one.)
• The question is whether the idea deserves doing at all — use hai-idea. goudi pressure-tests how to land a proposal, not whether it should exist.
• Behavior needs to be driven by tests — use hai-tdd.
• The output needs full phases, todos, and execution tracking — use hai-goal.

What This Skill Is Not

• Not generic project management. It is a pressure test for whether a proposal can land.
• Not anti-refactor and not timid. It rejects fantasy migrations, not clean targets — and the default is a smaller proof, not standing still.

Goudi Anti-Patterns and Counter-Moves

The five failure patterns goudi exists to catch. Step 2 of the Workflow scans a proposal for these; when one is present, apply its counter-move while choosing the minimum viable move and the stop rule.

1. Vision Without First Step

The proposal sounds right, but nobody knows what to do this afternoon.

Counter-move:

• Name the first concrete artifact: test, PRD patch, interface change, migration spike, prototype, benchmark, audit, or decision record.
• Define the exact scope of the first step.
• State what is intentionally out of scope.

2. Fake Migration Plan

The target model is clean, but the path assumes everything can be changed at once.

Counter-move:

• Identify existing contracts: persisted data, public API, user workflow, deployment, compliance, team ownership, or documented integration.
• Split target design from migration path.
• Prefer one narrow vertical slice over broad partial rewrites.
• Name the irreversible step and delay it until evidence exists.

3. Unpriced Risk

The answer says "we can refactor" without pricing data loss, behavior changes, blast radius, missing tests, or hidden callers.

Counter-move:

• List the top 3 risks by blast radius.
• Give each risk a verification method.
• Decide which risk must be retired before implementation.
• Reject work that cannot be validated inside a reasonable feedback loop.

4. Long-Term Correct, Short-Term Irresponsible

The direction may be right, but doing the full thing now would starve the current goal.

Counter-move:

• Separate the end-state from the next milestone.
• Ask whether the next milestone makes the system more correct even if the full target is not finished.
• Cut impressive but non-essential work.
• Preserve optionality when confidence is still low.

5. No Stop Rule

The plan can only continue; it cannot fail gracefully.

Counter-move:

• Define failure signals before starting.
• Define rollback or containment.
• Define when to pause and gather evidence.
• Make sunk-cost continuation unacceptable.

Goudi Output Template

Use this template when a proposal needs to be grounded, shrunk into a proof point, or pressure-tested for feasibility.

# 落地审判：<topic>

## Landing Judgment
<go / shrink / pause / reject / validate first>, because <one sharp reason>.

## Bold Direction Kept
<The larger target worth preserving. Do not erase the ambition if it is useful.>

## Reality Check
- **Real constraints**: <public API / persisted data / user workflow / deployment / compliance / ownership / documented integration>
- **Unproven assumptions**: <assumptions that need evidence>
- **Highest blast radius**: <area most likely to cause damage>
- **Most inflated part**: <part of the proposal that is too broad, speculative, or premature>

## Minimum Viable Move
- **Do this first**: <one concrete artifact, test, spike, doc patch, interface change, or vertical slice>
- **Scope**: <what changes>
- **Explicitly not doing**: <what is cut from the first move>
- **Why this move**: <what evidence it creates>

## Verification
- **Success criteria**: <observable pass condition>
- **Failure signals**: <observable fail condition>
- **Cheapest check**: <fastest way to gather evidence>
- **Required before scaling**: <risk or unknown that must be retired>

## Cut List
- <work to cut from the first attempt>
- <compatibility, polish, migration, or broad rewrite to defer>
- <decision that should not be made yet>

## Stop Rule
Stop, shrink, or change direction if <specific evidence or condition>.

## Next Move
<The next practical action, ideally small enough to do immediately.>

Goudi / 苟帝

中文版本用于阅读和文案打磨。执行规则以英文 SKILL.md 为准。

概览

这个 skill 用在方案讨论已经太宏大、太抽象、太想一步到位的时候。goudi 是 geju 的反面搭档：geju 负责把格局打开，goudi 负责把路踩实、逼方案落地。

它不是保守派，也不是反重构。它的作用是让一个大方向变得可执行、可验证、可止损，并且能在下一步产生真实进展。

核心原则

先把路踩实，再谈大胜利。

可以有大想法，可以有彻底重构，可以有强架构判断。但一个有用的方案必须回答：

• 最小证明动作是什么？
• 什么证据说明方向是对的？
• 哪些真实约束会把它打爆？
• 第一阶段应该主动砍掉什么？
• 如果判断错了，什么时候停？

如果一个方案说不清楚第一步怎么做，它还不是计划，只是一种情绪。

goudi 和 geju 是一对：

• geju 问："如果不害怕，我们真正应该做什么？"
• goudi 问："这个方向接触现实后的第一个证明点是什么？"

不要让 goudi 抹掉大目标。它压缩的是第一步，不是野心。

工作流

1. 用一句话复述大方向。不要把野心磨平。说明它来自 geju、PRD、架构审查还是用户想法。

2. 做现实检查。先扫描五种反模式，再点名它们暴露的约束：

• 有愿景，没有第一步 —— 听起来都对，但今天下午不知道该改哪个文件、写哪个测试。
• 假迁移计划 —— 目标很干净，但路径默认所有东西可以一次改完。
• 风险没有定价 —— 轻飘飘说"可以重构"，却没算数据丢失、影响面、测试缺口、隐藏调用方。
• 长期正确，短期不负责任 —— 现在全量做会拖垮当前目标。
• 没有止损规则 —— 计划只能继续，不能体面失败。

然后回答：哪些真实契约限制了这件事？哪个区域影响面最大？哪些假设还没被证明？方案里哪些部分只是好看、猜测或过早？每种反模式的具体反制动作见 references/anti-patterns.md。

3. 选择最小可行推进。只选一个窄切片、证明点或决策产物。定义它改什么，也定义它拒绝改什么。优先选择能产生证据的动作，而不是继续写更多计划。

4. 明确验证规则。成功标准必须可观察；失败信号必须提前命名；验证成本要低到在信心衰减前就能跑完。如果需要用测试驱动行为，交给 hai-tdd。

5. 激进砍范围。列出第一步不应该尝试的东西。砍掉没有真实契约支撑的兼容工作、不影响证明点的架构打磨，以及在窄切片证明前的大迁移。

6. 定义止损规则。什么证据会推翻或暂停这个方向？什么情况说明目标要缩小？什么东西可以回滚或隔离？哪个决策现在不要做？

输出

用 references/output-template.md 产出答案——动笔前先加载它。它固定了章节顺序：落地审判 / 保留的大方向 / 现实检查 / 最小可行推进 / 验证 / 砍掉清单 / 止损规则 / 下一步。

除了模板里的逐字段结构，还要守住这些约束：

• 开头先给判断结论——推进 / 缩小 / 暂停 / 拒绝 / 先验证——而不是先铺分析。
• 把真实约束和焦虑惯性分开。
• 有价值时保留大目标，但不要让大目标代替执行。
• 默认是缩小验证，不是原地瘫痪。不要把 goudi 变成"什么都别做"。
• 不要写巨大的计划；需要 phases、todos 和执行跟踪时交给 hai-goal。

什么时候改用别的 skill

• 目标是打开格局、摆脱兼容性恐惧、想得更大——用 geju。（goudi 落地的是已经打开的格局，它不负责打开格局。）
• 问题是这个想法本身值不值得做——用 hai-idea。goudi 压力测试的是方案怎么落地，不是它该不该存在。
• 需要用测试驱动行为——用 hai-tdd。
• 输出需要完整的 phases、todos 和执行跟踪——用 hai-goal。

它不是什么

• 不是通用项目管理。它专门审判方案能不能落地。
• 不是反重构，也不是胆小。它反对的是幻想迁移，不是干净目标——而且默认是缩小验证，不是原地不动。