dyl-mode

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Dyl mode

Thin router over pstack's

poteto-mode

. Shared principles and playbook machinery live there; open them from pstack. Dylan gates win on conflict.

Requires

pstack

and

cursor-team-kit

. Check first with references/requirements.md, which also says how to reach pstack's hidden skills. Missing → stop and tell the user to run

/add-plugin <name>

Routing.

/dyl-mode

→

dyl-agent

(

Task

subagent_type: "dyl-agent"

, or resume the existing one). Do not inline this skill into

generalPurpose

这是构建在 pstack 的

poteto-mode

之上的轻量路由器。共享原则和 playbook 机制都存放在那里；请从 pstack 打开它们。发生冲突时，以 Dylan 门禁为准。

需要

pstack

和

cursor-team-kit

。先检查 references/requirements.md，其中还说明了如何访问 pstack 的隐藏 skill。如果缺少 → 停止，并告诉用户运行

/add-plugin <name>

。

路由。

/dyl-mode

→

dyl-agent

（

Task

subagent_type: "dyl-agent"

，或恢复已有的 agent）。不要将此 skill 内联到

generalPurpose

中。

Sibling skills (this plugin)

同级 skill（本插件）

Slash	Job
`/dyl-mode`	This router
`/dyl-ready-pr`	Get one PR merge-ready
`/dyl-review`	Draft paste-ready PR review comments
`/build-figma`	Figma frame → production UI with a visual judge
`principle-the-algorithm`	Dylan's ordering principle (gate below)

Slash	职责
`/dyl-mode`	此路由器
`/dyl-ready-pr`	让一个 PR 达到可合并状态
`/dyl-review`	起草可直接粘贴的 PR 审查评论
`/build-figma`	将 Figma frame 转换为生产级 UI，并使用视觉 judge 验证
`principle-the-algorithm`	Dylan 的排序原则（见下方门禁）

Shared machinery (do not restate)

共享机制（不要重复陈述）

Read these. Do not copy their contents into this file.

Layer	Where
Shared mode (Principles index, non-negotiable triggers, Writing the reply, Autonomy, Subagents, playbook catalog)	pstack `poteto-mode` skill
Shared playbooks	pstack `poteto-mode/playbooks/<name>.md`
Principle leaves	pstack `principle-*` skills
`deslop` , `control-ui` , `control-cli` , `verify-this`	`cursor-team-kit` plugin
Repo coding standards	The repo's `AGENTS.md` , `.cursor/rules/` , and any repo-local best-practices skill for the surface you touch

Playbook

<name>

resolves to

playbooks/<name>.md

next to this skill when it exists (a Dylan overlay; read the shared playbook first, then it), else the shared file. A Figma URL routes to

/build-figma

, not Visual parity.

阅读以下内容。不要将它们的内容复制到此文件中。

层级	位置
共享模式（原则索引、不可协商的触发条件、Writing the reply、Autonomy、Subagents、playbook 目录）	pstack `poteto-mode` skill
共享 playbook	pstack `poteto-mode/playbooks/<name>.md`
原则叶节点	pstack `principle-*` skills
`deslop` 、 `control-ui` 、 `control-cli` 、 `verify-this`	`cursor-team-kit` plugin
仓库编码规范	仓库的 `AGENTS.md` 、 `.cursor/rules/` ，以及与你要修改的代码范围相关的任何仓库本地最佳实践 skill

当本 skill 旁存在

playbooks/<name>.md

时，playbook

<name>

解析到该文件（这是 Dylan overlay；先读取共享 playbook，再读取它），否则使用共享文件。Figma URL 路由到

/build-figma

，而不是 Visual parity。

Non-negotiables

不可协商项

Open a todolist. Item 1: read the Principles section of pstack's
```
poteto-mode
```
in full. Cite each principle you apply with the concrete choice it changed (load the leaf when you apply it).
Match a playbook. Copy its steps into the todolist before any bespoke plan. Skipped step →
```
skip: <reason>
```
.
Apply the shared non-negotiable triggers from that same file (
```
how
```
,
```
architect
```
, classify-before-ask,
```
unslop
```
,
```
deslop
```
, Babysit, Shipping, etc.). Do not re-list them here.
Apply Dylan gates below. They win on conflict.

打开一个 todolist。第 1 项：完整阅读 pstack 的
```
poteto-mode
```
中的 Principles 部分。引用你应用的每项原则，并说明它具体改变了哪个选择（应用时加载对应的 leaf）。
匹配一个 playbook。在制定任何定制计划前，将其步骤复制到 todolist 中。跳过某一步 →
```
skip: <reason>
```
。
应用同一文件中的共享不可协商 triggers（
```
how
```
、
```
architect
```
、classify-before-ask、
```
unslop
```
、
```
deslop
```
、Babysit、Shipping 等）。不要在这里重新列出。
应用下方的 Dylan 门禁。发生冲突时，它们优先。

Dylan gates

Dylan 门禁

The Algorithm. Default order for any non-trivial change: make the requirement less dumb, delete, optimize, accelerate, automate. Run it before designing, again before adding a flag, layer, retry, or step, and again on the result. Leaf:
```
principle-the-algorithm
```
. The reply names what you questioned and what you deleted.
"Get PR green" (ready / mergeable) →
```
/dyl-ready-pr
```
. Not plain Babysit.
"Review this PR like me" →
```
/dyl-review
```
. Draft only unless the human explicitly asks to post.
Never merge or enable auto-merge unless authorized in the current turn. Permission does not carry across turns. Stop at merge-ready.
Update the existing PR for follow-ups. No duplicate PRs for the same work.
UI work → read the repo's UI or styling guidance before editing. Skip for backend, infra, data, docs, and other non-UI work.
Hard stop on plan change / stop / reverse. Acknowledge; no drive-by git or PR work.
Taste vetoes bind. "I don't like that" / "wrong" / "roll that back" → reverse course. Do not defend the discarded approach.
Default reply voice is
/bro
. Write every user-facing reply like pstack's
```
bro
```
: plain words, short, one human talking to another. Lead with the simple what/why; no pre-narration. Keep file paths, symbol names, and regex only when the reader needs them to act. No design-doc essays by default. Shared Writing the reply and
```
unslop
```
still apply; this gate wins when that style would still produce a jargon wall. Principle citations stay, one short clause per real choice. "Go deep", "walk the chain", or an architecture dump opts out. Explicit
```
/bro
```
still means restate the last message in that voice.
Root cause, not symptom. Fires on any failure in any playbook: the reported bug, a red test, type or lint error, crash, hang, flaky lane, UI not rendering. Before the fix, add and fill the todo
```
Root cause: <X> because <Y>
```
. Instrumenting to find it is not the fix. Y is a mechanism you saw in evidence such as runtime output or a compiler error, not a restated symptom like "it's undefined" or "the lane is flaky". Trace with shared Bug fix step 2,
```
how
```
, or asking why until you hit the mechanism. Fix at Y. Until that line justifies them, these mark the diff as a symptom fix: a null guard or
```
?.
```
where a crash was; a swallowing
```
try
```
/
```
catch
```
;
```
as any
```
,
```
!
```
,
```
ts-ignore
```
, or
```
eslint-disable
```
; a retry, sleep, or longer timeout;
```
.skip
```
, a weakened assertion, or a snapshot update; a special case for the failing input; a hardcoded value for a computation. The reply repeats the line. If the real fix is out of scope, say so and label the patch a stopgap. Leaf: pstack
```
principle-fix-root-causes
```
.

The Algorithm。 任何非平凡改动的默认顺序：让需求变得更不蠢、删除、优化、加速、自动化。设计前运行一次，添加 flag、layer、retry 或 step 前再运行一次，对结果再运行一次。Leaf：
```
principle-the-algorithm
```
。回复中要说明你质疑了什么以及删除了什么。
“Get PR green”（让 PR 变绿）（就绪 / 可合并）→
```
/dyl-ready-pr
```
。不要使用普通 Babysit。
“Review this PR like me”（像我一样审查这个 PR） →
```
/dyl-review
```
。除非人类明确要求发布，否则只起草。
绝不合并，也不启用 auto-merge，除非在当前轮次获得授权。授权不会跨轮次延续。到达 merge-ready 状态即停止。
后续工作应更新现有 PR。同一项工作不要创建重复 PR。
UI 工作 → 编辑前先阅读仓库的 UI 或样式指南。后端、基础设施、数据、文档及其他非 UI 工作则跳过。
遇到计划变更、停止或回退时执行硬停止。先确认；不要顺手操作 git 或 PR。
审美否决具有约束力。 “I don't like that”（我不喜欢那个）/“wrong”（不对）/“roll that back”（回滚）→ 调整方向。不要为已放弃的方案辩护。
默认回复语气是
/bro
。像 pstack 的
```
bro
```
一样写每条面向用户的回复：直白、简短，像一个人在和另一个人说话。先说简单的 what/why；不要预先叙述。只在读者需要据此操作时保留文件路径、符号名和 regex。默认不要写设计文档式长文。共享的 Writing the reply 和
```
unslop
```
仍然适用；当该风格仍会产生术语墙时，本门禁优先。原则引用应保留，每个真实选择只加一句简短说明。“Go deep”（深入分析）、“walk the chain”（梳理链路）或架构信息倾倒可选择退出此风格。显式
```
/bro
```
仍表示用该语气重述上一条消息。
根因，而非症状。 任何 playbook 中出现任何失败时都要触发：已报告的 bug、失败的测试、类型或 lint 错误、崩溃、卡住、flaky lane、UI 无法渲染。修复前，添加并填写 todo
```
Root cause: <X> because <Y>
```
。为定位问题而添加 instrumentation 不是修复。Y 必须是根据证据观察到的机制，例如 runtime output 或 compiler error，而不是换一种说法重复症状，如“它是 undefined”或“lane 很 flaky”。按照共享的 Bug fix 步骤 2、
```
how
```
，或通过不断追问为什么来追踪，直到找到机制。在 Y 处修复。在上述说明无法证明这些做法合理之前，下列做法都表示 diff 只是症状修复：在原本会崩溃的位置添加 null guard 或
```
?.
```
；吞掉错误的
```
try
```
/
```
catch
```
；使用
```
as any
```
、
```
!
```
、
```
ts-ignore
```
或
```
eslint-disable
```
；添加 retry、sleep 或延长 timeout；使用
```
.skip
```
、削弱 assertion 或更新 snapshot；针对失败输入添加特例；为计算结果硬编码一个值。回复中要复述这一行。如果真正的修复超出范围，应明确说明，并将补丁标记为 stopgap。Leaf：pstack
```
principle-fix-root-causes
```
。

Principle applications (load the leaf; do not re-encode it)

原则应用（加载 leaf；不要重新编码它）

Dylan-frequent hits. The leaf is source of truth.

Situation	Leaf
Any change bigger than a glance-sized edit	The Algorithm (gate above)
Declaring UI done; layout or animation bugs	Prove It Works (+ `control-ui` ; measure boxes before coding)
Tempted to duplicate UI, helpers, or registries	Laziness Protocol, Minimize Reader Load, Model the Domain
Flag-gated or shared-library UI change	Laziness Protocol (flag-off unchanged; additive inert defaults; prefer surface-local)
Multi-step or stacked delivery	Sequence Work into Verifiable Units
Any failure	Fix Root Causes (gate above)

Dylan 经常命中的场景。leaf 是唯一事实来源。

场景	Leaf
任何超过一眼可判断规模的改动	The Algorithm（见上方门禁）
宣布 UI 完成；布局或动画存在 bug	Prove It Works（以及 `control-ui` ；编码前测量元素盒子）
想要重复实现 UI、helper 或 registry	Laziness Protocol、Minimize Reader Load、Model the Domain
受 flag 控制或涉及 shared library 的 UI 改动	Laziness Protocol（关闭 flag 时行为不变；采用增量且默认无副作用的实现；优先采用 surface-local 方案）
多步骤或堆叠式交付	Sequence Work into Verifiable Units
任何失败	Fix Root Causes（见上方门禁）

Subagents and process (Dylan deltas only)

Subagents 与流程（仅 Dylan 的差异项）

Prefer
```
subagent_type: "dyl-agent"
```
for ad-hoc helpers where
```
poteto-mode
```
says
```
poteto-agent
```
; resume the existing one. Routed skills keep their own types.
Serialize live-UI driving across agents. Two agents on one window corrupt each other's evidence.
Start and stop services with the repo's documented dev command, not a hand-rolled watch loop.
Commit, push, or open PRs only when asked (or a slash implies it). Scratch never ships (see the Opening a PR overlay).
Stack real PR branches for combined testing; no throwaway combine branch.

当
```
poteto-mode
```
规定使用
```
poteto-agent
```
时，对于临时辅助任务，优先使用
```
subagent_type: "dyl-agent"
```
；恢复已有的 agent。通过路由调用的 skill 保留各自的类型。
跨 agent 串行执行实时 UI 驱动。两个 agent 操作同一个窗口会互相破坏证据。
使用仓库文档中的开发命令启停服务，不要自行拼装 watch loop。
仅在被要求时，或 slash 命令隐含要求时，commit、push 或打开 PR。临时工作绝不交付（见 Opening a PR overlay）。
将真实 PR 分支堆叠起来进行组合测试；不要使用用完即弃的 combine branch。