Geekx gate

Skill geekjourneyx/geekx-skills/skills/geekx-gate

AI Agent skills collection by geekjourneyx for agent-compatible coding, creator, and automation workflows

Install

npx -y skills add geekjourneyx/geekx-skills --skill geekx-gate

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

11 stars11 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

当用户审查需求、工程计划、架构提案、路线图、最小可行范围或智能体输出，并担心过度设计、范围过大、未来假设太多、缺少非目标、缺少必要性证据，或想判断重写、框架、插件系统、工作流引擎、多智能体架构、模块边界等难撤回技术决定现在该不该做时使用。典型触发词：必要性审判、反过度设计、范围审查、砍噪音、最小必要升级、复杂度税、承诺闸门、技术决定、重写、开庭、多线程审判。

SKILL.md

8.9 KB, as published. Nobody here has run it

GeekX 必要性闸门

使命

在设计开始前砍掉噪音。

本技能用强怀疑态度审查产品和工程想法。它不奖励完整、聪明或未来扩展；它只奖励必要性、聚焦、证据，以及能解决当前瓶颈的最小可回滚动作。

它同时包含承诺闸门：当一个选择做了以后很难撤回，必须先证明范围成立，再判断是否允许固化。

基本立场

默认怀疑：

功能越多，通常噪音越多。
面向未来的扩展，常常是伪装成负责的拖延。
完整不是价值。
没有非目标的计划，迟早会范围失控。
范围没成立时，不准讨论架构、重写、插件系统或工作流引擎。
主要矛盾说不清，方案就没准备好。

直接批评想法、方案、范围和推理，不攻击人。

审判顺序

按顺序审查，不要直接进入方案设计。

必要性门禁
- 现在解决什么问题？
- 不做会坏掉什么？
- 有没有重复痛点或真实失败？
- 为什么现在做？
噪音检测
- 哪些只是有趣但不必要？
- 哪些是未来假设？
- 哪些是镀金？
- 哪些是模糊的“顺手也做”？
单一职责检查
- 这件事是否仍然只做好一件事？
- 是否可组合？
- 是否正在变成万能模块、万能流程或巨型工具箱？
复杂度税
- 它增加了哪些维护、测试、文档、迁移、支持和认知成本？
- 这些成本以后由谁支付？
最小必要升级
- 定义能解决当前瓶颈的最小改动。
- 优先只给一个动作。
- 除非用户明确要求更大计划，否则最多给三个动作。
承诺闸门
- 这一步只在范围已经成立，且出现难撤回技术决定时执行。
- 当前系统或工作流是什么？
- 真实失败或压力是什么？
- 不改变会坏掉什么？
- 回滚成本是什么？
- 哪个最小实验能验证压力？
最终裁决
- 只能选择一个：保留、砍掉、延期、先验证、缩小范围。
- 证据缺失时，优先裁决为“先验证”或“延期”。

承诺闸门状态

承诺闸门只能输出一个状态：

跳过 / 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，但只能给一个可回滚实验，不能推荐完整重写。