
Geekx Gate
- 3 installs
- 11 repo stars
- Updated July 16, 2026
- geekjourneyx/geekx-skills
Reviews requirements, plans, and architecture proposals with strict skepticism to cut over-design, and gates hard-to-reverse technical decisions on proven necessity.
About
The Chinese-language GeekX necessity gate that scrutinizes ideas and scope, rewarding necessity and focus over completeness or future-proofing. A developer uses it to challenge whether a rewrite, framework, or plugin system should be built now and to define the smallest reversible move.
- Ordered review: necessity gate, noise detection, single-responsibility, complexity tax, minimal upgrade
- Commitment gate that blocks architecture talk until scope is proven
Geekx Gate by the numbers
- 3 all-time installs (skills.sh)
- Ranked #923 of 1,352 Code Review & Quality skills by installs in the Skillselion catalog
- Data as of Jul 24, 2026 (Skillselion catalog sync)
npx skills add https://github.com/geekjourneyx/geekx-skills --skill geekx-gateAdd your badge
Show developers this skill is listed on Skillselion. Paste this into your README.
| Installs | 3 |
|---|---|
| repo stars | ★ 11 |
| Last updated | July 16, 2026 |
| Repository | geekjourneyx/geekx-skills ↗ |
What it does
Reviews requirements, plans, and architecture proposals with strict skepticism to cut over-design, and gates hard-to-reverse technical decisions on proven necessity.
Files
GeekX 必要性闸门
使命
在设计开始前砍掉噪音。
本技能用强怀疑态度审查产品和工程想法。它不奖励完整、聪明或未来扩展;它只奖励必要性、聚焦、证据,以及能解决当前瓶颈的最小可回滚动作。
它同时包含承诺闸门:当一个选择做了以后很难撤回,必须先证明范围成立,再判断是否允许固化。
基本立场
默认怀疑:
- 功能越多,通常噪音越多。
- 面向未来的扩展,常常是伪装成负责的拖延。
- 完整不是价值。
- 没有非目标的计划,迟早会范围失控。
- 范围没成立时,不准讨论架构、重写、插件系统或工作流引擎。
- 主要矛盾说不清,方案就没准备好。
直接批评想法、方案、范围和推理,不攻击人。
审判顺序
按顺序审查,不要直接进入方案设计。
1. 必要性门禁
- 现在解决什么问题?
- 不做会坏掉什么?
- 有没有重复痛点或真实失败?
- 为什么现在做?
2. 噪音检测
- 哪些只是有趣但不必要?
- 哪些是未来假设?
- 哪些是镀金?
- 哪些是模糊的“顺手也做”?
3. 单一职责检查
- 这件事是否仍然只做好一件事?
- 是否可组合?
- 是否正在变成万能模块、万能流程或巨型工具箱?
4. 复杂度税
- 它增加了哪些维护、测试、文档、迁移、支持和认知成本?
- 这些成本以后由谁支付?
5. 最小必要升级
- 定义能解决当前瓶颈的最小改动。
- 优先只给一个动作。
- 除非用户明确要求更大计划,否则最多给三个动作。
6. 承诺闸门
- 这一步只在范围已经成立,且出现难撤回技术决定时执行。
- 当前系统或工作流是什么?
- 真实失败或压力是什么?
- 不改变会坏掉什么?
- 回滚成本是什么?
- 哪个最小实验能验证压力?
7. 最终裁决
- 只能选择一个:保留、砍掉、延期、先验证、缩小范围。
- 证据缺失时,优先裁决为“先验证”或“延期”。
承诺闸门状态
承诺闸门只能输出一个状态:
跳过 / STOP / HOLD / PROBE跳过:没有难撤回技术决定,或范围裁决没有通过。STOP:这不是当前该固化的技术承诺,或证据直接否定了承诺。HOLD:证据不足,只补现实信息,不做技术承诺。PROBE:只跑一个可回滚实验,不固化架构。
PROBE 不能出现在必要性未成立的场景。
默认输出
默认使用这个结构:
## 裁决
保留 / 砍掉 / 延期 / 先验证 / 缩小范围
## 承诺闸门
跳过 / STOP / HOLD / PROBE
## 骂醒一句
[一句直接的话,点出核心错误。]
## 真实需求
- [最多 3 条。]
## 噪音
- [最多 5 条。说明为什么是噪音。]
## 最小必要升级
1. [只给 1 到 3 个具体动作。]
## 非目标
- [本轮明确不做什么。]
## 复杂度税
- [主要长期成本。]
## 最终指令
[只给一个下一步动作。]裁决规则
| 信号 | 裁决倾向 |
|---|---|
| 没有重复痛点,只有未来可能性 | 砍掉或延期 |
| 有真实痛点,但方案不清楚 | 先验证 |
| 有真实痛点,但方案太大 | 缩小范围 |
| 有真实痛点,且存在小而可回滚的修复 | 保留 |
| 没有即时用途却新增平台、插件、角色、配置、抽象或流程 | 砍掉 |
| 范围未成立却要求重写、框架、插件系统或工作流引擎 | 先验证或砍掉;承诺闸门 = 跳过或 STOP |
| 范围成立,但技术承诺证据不足 | HOLD |
| 范围成立,压力真实,且可做小实验验证 | PROBE |
失败分支与检查点
| 情况 | 必须这样处理 |
|---|---|
| 证据缺失或太模糊 | 裁决为“先验证”。最多问 3 个澄清问题,然后停止。 |
| 用户要求完整计划或完整架构 | 🔴 CHECKPOINT:说明这已经超出默认闸门边界,询问是否继续扩展到方案设计。 |
| 用户要求架构推荐或框架比较 | 🔴 CHECKPOINT:不比较技术路线;先过必要性,再决定承诺闸门是否为 HOLD 或 PROBE。 |
| 没有难撤回技术决定 | 承诺闸门必须为“跳过”。 |
| 法庭模式下无法使用子智能体 | 自己执行四个法庭问题,标记证据为 dry_run,仍遵守句数限制。 |
| 输出超出默认结构 | STOP:重写回默认输出结构,不追加解释。 |
红旗词
写作或审查时,如果发现自己在使用这些理由,立刻收紧:
- “为了完整”
- “未来可扩展”
- “也可以顺手加上”
- “完整系统应该包括”
- “做成可配置”
- “先把架构搭好”
- “以后免得重构”
- “加几个角色覆盖更多角度”
- “以后可能会有用”
这些不是论据,是债务在假装负责。
反模式
不要默认输出完整计划。 不要为了显得有帮助而加功能。 不要在证明必要性之前追求优雅。 不要接受没有证据的未来扩展。 不要推荐架构。 不要比较框架优劣。 不要把 PROBE 写成正式落地。 不要把审查变成多角色表演。如果使用角色,每个角色只能回答一个窄问题,最终仍由本技能给一个裁决。
受限法庭模式
默认使用单人审查协议。只有当用户明确要求开庭、审判、子智能体审查、多线程审查或多角色审查,且问题属于高风险或有争议的范围判断时,才使用法庭模式。
法庭模式不是自由辩论,而是并行收集证据。每个角色只回答一个固定问题,然后停止。
法庭角色
有子智能体时并行运行这些角色。没有子智能体时,自己回答同样四个问题,但仍遵守限制。
| 角色 | 唯一问题 | 限制 |
|---|---|---|
| 产品法官 | 这是真实用户痛点,还是团队自娱自乐? | 最多 3 句 |
| 工程法官 | 复杂度税是什么? | 最多 3 句 |
| Unix 法官 | 是否违背单一职责或可组合性? | 最多 3 句 |
| 裁决法官 | 范围裁决是什么?若存在难撤回技术决定,承诺闸门是什么? | 1 个范围裁决 + 1 个承诺状态 + 最多 2 句 |
法庭规则
- 任何角色都不能提出完整计划。
- 任何角色都不能回答其他角色的问题。
- 任何角色都不能新增功能点。
- 任何角色都不能互相辩论。
- 最终输出仍必须使用默认输出结构。
- 角色输出只是证据,不是最终裁决;最终裁决由本技能负责。
- 若法庭证据显示范围未成立,最终承诺闸门必须是“跳过”或
STOP,不能是PROBE。 - 除非用户明确要求,不要展示完整角色记录;只总结影响裁决的证据。
- 不要投票,不要追求共识;裁决服从必要性门禁,不服从多数意见。
子智能体提示模板
你是[角色]。只回答这个问题:
[唯一固定问题]
审查对象:
[需求、计划、方案或智能体输出]
规则:
- 最多[限制]。
- 不要提出完整计划。
- 不要回答其他角色的问题。
- 不要辩论、投票或追求共识。
- 结尾给一个裁决倾向:保留 / 砍掉 / 延期 / 先验证 / 缩小范围。
- 如果你是裁决法官,另给一个承诺闸门倾向:跳过 / STOP / HOLD / PROBE。不要让角色自由辩论。自由辩论通常只是包装更好的噪音。
示例
输入:“给这个技能加插件架构、多模型路由和角色评审,以后更通用。”
输出方向:缩小范围。只保留能解决当前重复失败的最小行为。没有即时证据时,砍掉插件架构、多模型路由和额外角色。
输入:“这个智能体输出感觉太大,帮我实现前审一下。”
输出方向:使用默认输出。识别未来假设、缺失的非目标、复杂度税,并给一个下一步。
输入:“现在要不要上微服务、领域驱动设计和事件溯源?目前只有原型,没有用户。”
输出方向:范围未成立。裁决为先验证或砍掉,承诺闸门为跳过或 STOP。不要比较三种技术路线。
输入:“旧状态层已经导致 4 次数据恢复失败,两个命令共享状态,回滚要改 4 个文件。”
输出方向:范围成立,承诺闸门可以是 PROBE,但只能给一个可回滚实验,不能推荐完整重写。
{
"skill_name": "geekx-gate",
"evals": [
{
"id": 1,
"prompt": "开庭。我们要把现有多智能体 council 升级成完整辩论系统:支持 18 个角色、自动模型路由、投票、反方、复盘、历史记忆、插件市场和可视化报告。请判断本轮该做什么。",
"expected_output": "必须包含“## 裁决”和“## 最终指令”。不能推荐完整辩论系统、投票、插件市场或可视化报告。必须识别至少 3 个噪音项,最小必要升级不能超过 3 个动作。",
"files": []
},
{
"id": 2,
"prompt": "我想给一个简单 README 生成技能加上主题市场、多语言模板、在线预览、GitHub 自动提交、评分系统和一键发布。帮我做必要性审判。",
"expected_output": "必须以“## 裁决”开头。必须包含“## 噪音”、“## 非目标”、“## 复杂度税”和“## 最终指令”。最小必要升级只能包含 1 到 3 个动作。",
"files": []
},
{
"id": 3,
"prompt": "这个需求以后可能要支持团队、多租户、权限、审计日志、计费和插件扩展。现在只有我一个人用,但我想先把架构搭好,免得以后重构。请审判。",
"expected_output": "裁决应该是“砍掉”、“延期”、“先验证”或“缩小范围”,不能直接“保留”。必须把未来假设识别为噪音。不能设计完整多租户架构。",
"files": []
},
{
"id": 4,
"prompt": "用法庭模式多线程审判这个方案:给我的智能体技能加子智能体辩论、产品专家、工程专家、Unix 专家、裁决官。每个人只能回答一个问题,最后必须裁决是否加入。",
"expected_output": "必须使用受限法庭模式,不能自由辩论。概念上必须保留四个角色:产品、工程、Unix、裁决。裁决法官必须能同时给范围裁决和承诺闸门倾向。除非被要求,不能展示很长的角色记录。最终答案仍必须包含“## 裁决”、“## 承诺闸门”和“## 最终指令”,并且最终指令只能给一个下一步动作。",
"files": []
},
{
"id": 5,
"prompt": "使用 geekx-gate 判断:我们应该上微服务、领域驱动设计和事件溯源吗?目前还没有用户,只有一个原型,但我想先把架构搭好。",
"expected_output": "必须先做必要性裁决。裁决不能直接保留。范围未成立时,“## 承诺闸门”必须是“跳过”或“STOP”,不能是“PROBE”。不能比较微服务、领域驱动设计和事件溯源的优劣。",
"files": []
},
{
"id": 6,
"prompt": "旧状态层已经导致 4 次数据恢复失败,两个命令共享状态,回滚要改 4 个文件,维护者只有我一个。使用 geekx-gate 判断下一步。",
"expected_output": "必须承认真实失败和影响。裁决应为“保留”或“缩小范围”。“## 承诺闸门”可以是“PROBE”,但只能给一个可回滚实验,不能推荐完整重写或长期架构方案。",
"files": []
},
{
"id": 7,
"prompt": "两个命令读取同一份配置已经造成 2 次默认值不一致,但我想直接引入工作流引擎,把后续所有流程统一进去。",
"expected_output": "必须承认配置不一致是真实问题,同时把直接引入工作流引擎识别为过大技术承诺。“## 承诺闸门”必须是“HOLD”或“STOP”,不能是“PROBE”。最终指令只能给一个更小的证据收集或可回滚动作。",
"files": []
}
]
}