Geju

Geju

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

Overview

Open the design space during 方案讨论: recommend the right target model, not the smallest patch. The output is a 格局判断 — a sharp thesis plus a disciplined way to test it.

Core Principle

大胆假设，小心求证。

Geju does not produce a guaranteed-correct answer. It produces a high-leverage, provocative hypothesis that opens the design space. Treat the thesis as a strong hypothesis to test, not as an oracle: first make the bold call, then define the careful verification path.

Refactor difficulty, compatibility fear, existing implementation shape, and local details are constraints to price, not masters to obey. Do not let them decide the direction too early.

Ways To Open The Frame

The eight moves below are the skill's catalog. Use at least one whenever the discussion is trapped in local optimization.

1. End-State Backcasting

Ask: "If this system were already excellent six months from now, what would be true?" Work backward from that target — not from today's package layout, legacy names, or current partial implementation.

2. Zero-Legacy Thought Experiment

Ask: "If we started today with no old callers, what would we build?" Compare the clean target with the legacy-preserving path. This exposes which compatibility work is real and which is inertia.

3. Kill The Wrong Concept

Sometimes the right move is not to rename, split, or patch a concept — it is to delete the concept because it encodes the wrong model. Look for concepts that exist only because of history:

• Duplicate names for one lifecycle.
• Transitional wrappers with no real contract.
• "Manager", "service", "context", or "config" objects that hide responsibility.
• PRD sections or plan phases that exist only because the current document already has them.

4. Ten-Times Question

Ask: "If this had to support 10x more usage, complexity, teams, or product surface, what would obviously break?" Use this not to over-engineer, but to reveal the current design's weak axis.

5. Constraint Inversion

Instead of "how do we work around this constraint?", ask "what if this constraint were removed?" Then decide whether the constraint deserves to survive.

6. Non-Negotiable Principles

Before discussing implementation, name 2-4 principles the design must not violate, e.g.:

• The document is the source of truth.
• One concept has one lifecycle owner.
• Internal legacy names do not get compatibility shims.
• User-facing contracts need migration; internal callers get updated directly.

7. Tasteful Deletion

Deletion is a design act. If a feature, section, abstraction, config field, or compatibility path does not serve the target model, say so — do not hide deletion behind "maybe simplify later."

8. Hypothesis First, Verification Second

Say the bold hypothesis before overfitting to caveats. Then make it testable: What evidence would confirm this direction? What would disprove it? What is the cheapest proof point? What should we inspect before committing? What risk would make this take irresponsible?

What To Fight

These are the failure modes that keep an answer small. Each gets countered by the moves above and by the workflow — do not flatten them into a balanced non-answer.

Workflow

1. Reframe at the highest useful level. What is the real decision? What is the system trying to become? What would be obvious if we were not afraid of the current implementation, or if today's docs/code/package layout did not exist?

2. Name the inherited constraint. Compatibility, migration difficulty, existing naming, local implementation shape, organizational habit, vague product goal, local document structure, or fear of deleting existing work.

3. Decide whether the constraint is real. This is the operational heart of the skill — apply it in exactly this spot.

• Real: public API, persisted data, documented integration, user promise, deployment constraint, compliance, or explicit user instruction.
• Not enough: internal callers, stale naming, old package layout, existing partial implementation, "this will be a big diff."

4. Offer the high-格局 thesis. Say the clean direction plainly. Explain what to delete, preserve, merge, split, or rebuild. Include the tradeoff instead of softening the recommendation. Include the kill list (what should stop existing). Label the thesis as a hypothesis when evidence is incomplete.

5. Apply at least one move from Ways To Open The Frame.

6. Give 2-3 options only if they materially differ, using the canonical labels: Conservative path / Clean target / Staged clean path. Recommend one.

7. Bring it back to execution. Identify the first irreversible decision, the first proof point, what would falsify the thesis, and what not to spend time on.

Output

Produce a 格局判断 with these sections (see references/output-template.md for the copy-pasteable skeleton — read it before finalizing):

• Thesis — sharp, high-leverage, in 1-3 sentences; not presented as guaranteed truth.
• Confidence — level (high / medium / low) plus why not certain.
• The Trap — the inherited constraint, whether it is real, and why.
• High-格局 Direction — the clean target model.
• Frame-Opening Move — which move you used and what it reveals.
• Bold Takes — defensible bold claims; what to delete / merge / split / rename; what not to preserve.
• Options — the Conservative path / Clean target / Staged clean path table with a verdict per row.
• What Not To Do — local optimizations, shims, or detail traps to avoid.
• First Proof Point — the smallest artifact that proves the direction.
• Falsifier — what evidence would prove the thesis wrong.
• Payoff Ledger (收益账单) — the closing table that justifies the direction to the audience: each major move (drawn from the Bold Takes / kill list) with the price paid now, the concrete pain it removes or capability it unlocks, and when that payoff becomes visible. Generic benefits ("cleaner", "more maintainable") are banned — every row must name a specific pain or unlock, or the row gets cut.

Output discipline that the sections do not already enforce:

• Lead with the thesis, not a long caveat. Bold claims are allowed; pretending they are certain is not.
• Separate target design from migration path.
• Do not preserve backward compatibility by default — treat every shim as debt that must name a real contract to survive.
• Do not get stuck in code-level details unless the detail changes the direction.
• If the answer feels too safe, add one stronger thesis and name how to test it.

Use a different skill when

• The bold direction is chosen and now needs feasibility / landing pressure-testing — use goudi to make it executable and de-risk landing. geju and goudi are a paired stance: geju opens the frame, goudi puts it on the ground.
• The question is whether the idea is worth doing at all (do / kill / defer) — use hai-idea. geju assumes the work is worth doing and questions only its scope and altitude.
• The user wants implementation-quality review — use clean-code-reviewer.
• The user wants APoSD-level architecture critique (module boundaries, abstraction depth) — use hai-architecture.
• The output is a PRD — use hai-prd.

What this skill is NOT

• Not reckless implementation. Bold direction still needs evidence and validation.
• Not a correctness guarantee. The value is inspiration plus a disciplined way to test the hypothesis.

Geju Output Template

Use this template when the user wants the design space opened up and conservative local thinking challenged.

# 格局判断：<topic>

## Thesis
<Sharp, high-leverage hypothesis in 1-3 sentences. Do not present it as guaranteed truth.>

## Confidence
- **Confidence level**: high / medium / low
- **Why not certain**: <missing evidence, unresolved constraint, or assumption>

## The Trap
- **Inherited constraint**: <compatibility / migration / old name / local detail / partial implementation / vague goal>
- **Is it real?**: yes / no / partially
- **Why**: <named contract or reason it is only inertia>

## High-格局 Direction
<The clean target model if we were not overfitting to the current implementation.>

## Frame-Opening Move
- **Move used**: end-state backcasting / zero-legacy thought experiment / kill the wrong concept / ten-times question / constraint inversion / non-negotiable principles / tasteful deletion
- **What it reveals**: <the higher-level insight>

## Bold Takes
- <bold but defensible claim>
- <what should be deleted, merged, split, renamed, or reframed>
- <what should not be preserved just because it already exists>

## Options
| Option | What it optimizes | Cost | Verdict |
|--------|-------------------|------|---------|
| Conservative path | <compatibility/local safety> | <complexity cost> | reject / keep only if... |
| Clean target | <long-term clarity> | <migration/refactor cost> | recommended / not recommended |
| Staged clean path | <balanced route> | <extra sequencing> | recommended / fallback |

## What Not To Do
- <local optimization, compatibility shim, partial patch, or detail trap to avoid>
- <thing that feels safe but preserves the wrong model>

## First Proof Point
<The smallest artifact, test, doc change, trace, prototype, or decision that proves the direction.>

## Falsifier
<What evidence would prove this hypothesis wrong or force a different direction.>

## Payoff Ledger（收益账单）
<Closing table for the audience: why this direction is worth its price. Every row traces back to a Bold Take or kill-list item; rows with only generic benefits get cut.>

| Move | Price paid now | What it buys | When the payoff shows |
|------|----------------|--------------|-----------------------|
| <delete / merge / split / rebuild X> | <migration cost, diff size, relearning> | <specific pain removed or capability unlocked> | <the moment or signal where the gain becomes visible> |

Geju

中文读者请看本文件；英文 SKILL.md 是执行时的事实源。

概览

在方案讨论时打开设计空间：推荐正确的目标模型，而不是最小补丁。输出是一份格局判断——一个尖锐的 thesis，加上一套验证它的方法。

核心原则

大胆假设，小心求证。

geju 不是为了产出一个百分百正确的答案，而是产出一个有杠杆、有启发性、能打开设计空间的强假设。把 thesis 当作需要验证的强假设，而不是神谕：先大胆假设，再给出小心求证的路径。

重构困难、兼容性恐惧、既有实现形状和局部细节，都是需要定价的约束，而不是必须服从的主人。不要让它们过早决定方向。

打开格局的打法

下面八个打法是这个 skill 的打法库。当讨论陷入局部优化时，至少使用其中一个。

1. 从终局倒推

问：“如果六个月后这个系统已经变得很好，那个时候应该是什么样？”从那个目标往回推——不要从今天的包结构、历史命名或半成品实现开始推。

2. 零历史包袱假设

问：“如果今天从零开始，没有老调用方，我们会怎么设计？”把干净目标和保守兼容路线放在一起比较。这个问题能暴露哪些兼容是真约束，哪些只是惯性。

3. 杀掉错误概念

有时候正确动作不是改名、拆分或打补丁，而是删除一个概念，因为它承载的是错误模型。重点看这些因为历史而存在的概念：

• 同一个生命周期有两个名字。
• 没有真实契约的过渡 wrapper。
• 用 Manager、Service、Context、Config 掩盖职责。
• PRD 段落或计划阶段只是因为当前文档已有，所以继续存在。

4. 十倍问题

问：“如果使用量、复杂度、团队数量或产品面扩大十倍，哪里会明显崩？”这个问题不是为了过度设计，而是为了暴露当前设计最脆弱的轴。

5. 反向约束

不要只问“怎么绕过这个约束”，也要问：“如果这个约束不存在，我们会怎么做？”然后再判断这个约束是否值得保留。

6. 不可妥协原则

讨论实现前，先列 2-4 条设计不能违反的原则，例如：

• 文档是事实源。
• 一个概念只有一个生命周期 owner。
• 内部历史命名不保留兼容 shim。
• 用户可见契约需要迁移；内部调用方直接更新。

7. 有品位地删除

删除也是设计动作。如果一个功能、段落、抽象、配置字段或兼容路径不服务目标模型，就直接说——不要把删除藏在“以后再简化”里。

8. 先假设，再求证

先说大胆假设，不要一开始就被 caveat 淹没。然后让它可验证：什么证据能支持这个方向？什么证据能推翻它？最便宜的证明点是什么？真正投入前应该先检查什么？哪个风险会让这个判断变得不负责任？

要对抗的问题

下面这些是让答案变小的失败模式。每一个都由上面的打法和工作流来反制——不要把它们摊平成一个平衡的「不回答」。

工作流

1. 从最高但仍有用的层级重构问题。 真正的决策是什么？系统想变成什么？如果不害怕当前实现、或者当前文档/代码/包结构不存在，什么方向会很明显？

2. 点名继承来的约束。 兼容性、迁移困难、既有命名、局部实现形状、组织习惯、模糊的产品目标、当前文档结构，或害怕删除已有工作。

3. 判断约束是否真实。 这是这个 skill 的操作核心——只在这一步做这个判断。

• 真实约束：公开 API、持久化数据、已文档化集成、用户承诺、部署约束、合规要求、用户明确要求。
• 不充分理由：内部调用方、过时命名、旧包结构、已有半成品实现、“这个 diff 会很大”。

4. 给出高格局 thesis。 直接说干净方向。说明什么应该删除、保留、合并、拆分或重建。把 tradeoff 说清楚，不要为了温和而削弱判断。给出 kill list（哪些东西应该停止存在）。证据不完整时把 thesis 标成假设。

5. 至少使用一个「打开格局的打法」。

6. 只有在选项有实质差异时，才给 2-3 个方案，使用统一标签：保守路线 / 干净目标 / 分阶段抵达干净目标。明确推荐一个。

7. 回到执行。 找出第一个不可逆决策、第一个证明点、什么证据会推翻这个 thesis，以及不该花时间的事情。

输出

产出一份格局判断，包含以下各节（可直接复制的骨架见 references/output-template.md，最终输出前先读它）：

• Thesis——尖锐、有杠杆，1-3 句；不要当作定论呈现。
• Confidence——等级（high / medium / low）加上为什么不确定。
• The Trap——继承来的约束、它是否真实、为什么。
• High-格局 Direction——干净的目标模型。
• Frame-Opening Move——你用了哪个打法、它揭示了什么。
• Bold Takes——站得住的暴论；什么该删/合/拆/改名；什么不该仅因已存在就保留。
• Options——保守路线 / 干净目标 / 分阶段抵达干净目标的选项表，每行给结论。
• What Not To Do——要避免的局部优化、shim、细节陷阱。
• First Proof Point——能证明这个方向的最小产物。
• Falsifier——什么证据会证明这个 thesis 是错的。
• Payoff Ledger（收益账单）——收尾的表格，向观众讲清这个方向为什么值得它的代价：每个主要动作（取自 Bold Takes / kill-list）现在付出什么、消除哪个具体的痛点或解锁哪个能力、收益什么时候以什么信号兑现。禁止泛泛收益（"更干净""更好维护"）——每一行必须点名具体的痛或解锁，点不出来就删行。

各节本身没有强制、但仍要遵守的输出纪律：

• 先给 thesis，不要先铺一长串 caveat。允许暴论，但不能假装暴论就是定论。
• 把目标设计和迁移路径分开。
• 默认不保留向后兼容——把每一个 shim 都当作债务，它必须点出一条真实契约才能活下来。
• 不要卡在代码级细节里，除非这个细节会改变方向。
• 如果答案太安全，补一个更强的 thesis，并说明怎么验证。

什么时候改用别的 skill

• 大胆方向已经选定，现在需要可行性与落地压力测试——用 goudi 让它可执行、给落地降风险。geju 和 goudi 是一对配套姿态：geju 打开格局，goudi 把它踩到地上。
• 问题是这件事到底值不值得做（做 / 砍 / 延后）——用 hai-idea。geju 假定事情值得做，只质疑它的范围和高度。
• 用户想要实现质量审查——用 clean-code-reviewer。
• 用户想要 APoSD 级别的架构 critique（模块边界、抽象深度）——用 hai-architecture。
• 输出物是 PRD——用 hai-prd。

这个 skill 不是什么

• 不是鲁莽实现。大胆方向仍然需要证据和验证。
• 不是正确性担保。它的价值是启发性，加上一套严肃求证的方法。