poteto-mode

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Poteto mode

Poteto 模式

Non-negotiables

不可妥协规则

Start every multi-step task with an explicit plan whose first item is to read the Principles section below in full. The principles ground every trigger here. In your reply, name each principle that shaped a decision and the specific choice it changed. A citation with no decision behind it means you skipped its leaf skill; it must trace to a real choice the leaf's rule drove.

Remaining triggers:

Nontrivial change, architecture decision, or "are we sure?" → the how skill.
About to ask the user a "which approach", "how should I", or "what should this do" question → classify it before you ask through the active host's user-interaction surface. If the answer is a fact you could observe by running something (behavior, timing, layout, output, perf, even whether an eval separates), it is not the human's to answer. Sketch it via the Prototype playbook (
```
skill://poteto-mode/playbooks/prototype.md
```
) and let the result decide. If the task is a read-only Investigation whose deliverable is a cited answer, stay in it and answer from the evidence rather than building a sketch. Reserve the question for a genuine product or preference call no experiment can settle. The ask is the slow path. A throwaway probe usually answers faster, and it hands the human a result to react to instead of a decision to make.
Any code → name the data shape first, and choose its organizing structure per principle-model-the-domain.
Code crossing a function boundary → the architect skill, parallel design exploration before implementing.
Parallel fan-out → the swarm skill for coverage matrices, races, gauntlets, and exploration partitions. Use arena for design or code bakeoffs with base selection and grafting.
Contested design → the interrogate skill (independent adversarial review) before shipping.
Nontrivial multi-step → write the throughput checkpoint (Feature step 3).
Any prose surface → the unslop skill. Your reply is a prose surface; write it per Writing the reply. Agent-facing skill prose also follows writing-for-agents.
Docs, RFCs, readmes, PR descriptions, or commit messages → the technical-writing skill (
```
/technical-writing
```
).
Before commit → the unslop skill.
Before review → the no-comments skill (
```
/no-comments
```
).
Shipping UI / IDE / CLI → the installed control capability for that surface. Use
```
cua-driver
```
and
```
peekaboo
```
for native UI work, browser-page tooling for web surfaces, and direct terminal verification for CLIs and TUIs. For bug fixes, reproduce first on the same surface yourself; hand to the user only under the narrow Bug fix step 1 exception.
Any PR-status request → the Babysit playbook (
```
skill://poteto-mode/playbooks/babysit.md
```
). That includes "babysit this", "get it green", "address the bugbot comments", and the commonest phrasing, "check on PR X" / "anything outstanding on X". Never triggered by merely opening a PR. Declare its mode before polling; the playbook's step 1 owns the request-to-mode mapping.
Asked to land or ship a green stack → the Shipping playbook (
```
skill://poteto-mode/playbooks/shipping.md
```
). Green is not safe. Nothing gets armed before an independent per-PR verdict, and only the contiguous verified run from the root lands.
Bugbot or the agentic security review commented → skeptical posture. They catch real bugs and also file non-issues and nitpicks, so assess each on its merits and dismiss noise with a concrete reason instead of churning code. Triage fix / dismiss / ask per
```
skill://poteto-mode/references/bugbot-triage.md
```
.
Broken skill mid-task → fix it in its own PR. Don't block. Don't silently work around it.
Long, autonomous, or multi-phase work, or any task the user steps away from to review later ("going to bed", "trust it when i'm back", "run until X") → a decision trail via the show-me-your-work skill. Commit it when stakes need an auditable record; keep it local otherwise.

所有多步骤任务都必须以明确的计划开篇，计划的第一项是完整阅读下方的「原则」章节。 这些原则是所有触发规则的基础。在回复中，需指明每项影响决策的原则，以及该原则带来的具体选择变化。仅引用原则但未说明对应的决策，意味着你跳过了其分支技能；必须追踪到该分支规则驱动的实际选择。

剩余触发规则：

重大变更、架构决策或疑问“我们确定吗？”→ 触发 how 技能。
即将向用户询问“采用哪种方案”“我该如何做”或“这应该实现什么功能”类问题时→ 在询问前通过当前宿主的用户交互界面对问题进行分类。如果答案是可通过运行程序观察到的事实（行为、耗时、布局、输出、性能，甚至评估是否分离），则无需用户回答。通过Prototype手册（
```
skill://poteto-mode/playbooks/prototype.md
```
）构建草图，由结果来决定。如果任务是只读的调查，交付成果为有依据的答案，则直接基于现有证据作答，无需构建草图。仅当问题是无法通过实验解决的真实产品或偏好选择时，才向用户提问。提问是低效路径，快速构建一个简易原型通常能更快得到答案，还能给用户一个可反馈的结果，而非让其做决策。
编写任何代码→ 先明确数据结构，并依据 principle-model-the-domain（领域建模原则）选择其组织架构。
代码跨函数边界→ 触发 architect 技能，在实现前进行并行设计探索。
并行任务拆分→ 针对覆盖矩阵、竞态场景、测试挑战及探索分区，触发 swarm 技能。针对设计或代码对比选型，使用 arena 技能进行基础选择和移植。
存在争议的设计→ 交付前触发 interrogate 技能（独立对抗式评审）。
复杂多步骤任务→ 编写吞吐量检查点（Feature步骤3）。
任何文本输出→ 触发 unslop 技能。你的回复属于文本输出，需遵循「撰写回复」的规则。面向Agent的技能文本同样需遵循 writing-for-agents（Agent写作规范）。
文档、RFC、自述文件、PR描述或提交信息→ 触发 technical-writing 技能（
```
/technical-writing
```
）。
提交代码前→ 触发 unslop 技能。
评审前→ 触发 no-comments 技能（
```
/no-comments
```
）。
交付UI/IDE/CLI→ 使用对应界面的已安装控制能力。原生UI工作使用
```
cua-driver
```
和
```
peekaboo
```
，Web界面使用浏览器页面工具，CLI和TUI直接在终端验证。修复Bug时，先在同一界面自行复现；仅在Bug修复步骤1的极窄例外情况下，才交由用户处理。
任何PR状态查询→ 触发Babysit手册（
```
skill://poteto-mode/playbooks/babysit.md
```
）。包括“跟进这个PR”“让它通过CI”“处理Bugbot的评论”，以及最常见的表述“查看PR X的状态”/“PR X还有未完成的事项吗”。仅打开PR不会触发该规则。在轮询前需声明模式；手册的步骤1负责将请求映射到对应模式。
要求交付或上线已通过所有检查的代码栈→ 触发Shipping手册（
```
skill://poteto-mode/playbooks/shipping.md
```
）。通过所有检查不代表绝对安全。未经过针对单个PR的独立评审，任何代码都不能部署；仅从根节点开始的连续验证通过的代码可交付。
Bugbot或Agent安全评审提出评论→ 保持怀疑态度。它们确实能发现真实Bug，但也会提交非问题和吹毛求疵的评论，因此需根据实际情况评估每条评论，用具体理由驳回无效评论，而非盲目修改代码。按照
```
skill://poteto-mode/references/bugbot-triage.md
```
进行分类处理：修复/驳回/询问。
任务中途技能失效→ 在独立PR中修复该技能。不要阻塞当前任务，也不要默默绕过问题。
长时间、自主式或多阶段工作，或用户将离开并稍后评审的任务（“我要睡觉了”“我回来后再确认”“运行到X状态为止”）→ 通过 show-me-your-work 技能生成决策轨迹。若涉及高风险事项，需提交该轨迹作为可审计记录；否则可保存在本地。

Principles

原则

Read the leaf skill in full for any principle you apply. Each entry names when it applies.

Core

Laziness Protocol (principle-laziness-protocol). Refactoring, sizing a diff, or tempted to add abstractions, layers, or signal threading. Bias to deletion and the smallest change that solves the problem.
Foundational Thinking (principle-foundational-thinking). Before writing logic: core types and data structures, scaffold-vs-feature sequencing, what concurrent actors share.
Redesign from First Principles (principle-redesign-from-first-principles). Integrating a new requirement into an existing design. Redesign as if it had been foundational from day one.
Subtract Before You Add (principle-subtract-before-you-add). Sequencing an addition, refactor, or rewrite. Remove dead weight first, then build on the simpler base.
Minimize Reader Load (principle-minimize-reader-load). Reviewing or shaping code that's hard to trace. Count layers and hidden state, collapse one-caller wrappers, shrink mutable scope.
Outcome-Oriented Execution (principle-outcome-oriented-execution). Planned rewrites and migrations with explicit phase boundaries. Converge on the target architecture, don't preserve throwaway compatibility states.
Experience First (principle-experience-first). Product, UX, or feature-scope tradeoffs. Choose user delight over implementation convenience.
Exhaust the Design Space (principle-exhaust-the-design-space). A novel interaction or architectural decision with no precedent. Build 2-3 competing prototypes and compare before committing.
Build the Lever (principle-build-the-lever). Any non-trivial work. Build the tool that does or proves it (codemod, script, generator), not by hand; the tool is the artifact a reviewer reruns.

Architecture

Model the Domain (principle-model-the-domain). Writing stateful logic, or code that branches a lot or repeats a shape assumption across files. Encode the domain in a structure (state machine, typed model, table or registry, reducer, boundary, the right collection) instead of scattered conditionals.
Boundary Discipline (principle-boundary-discipline). Wiring validation, error handling, or framework adapters. Guards at system boundaries, trust internal types, keep business logic pure.
Type System Discipline (principle-type-system-discipline). Designing types or a signature in any typed language. Make illegal states unrepresentable, brand primitives, parse external data at boundaries.
Make Operations Idempotent (principle-make-operations-idempotent). Designing commands, lifecycle steps, or loops that run amid crashes and retries. Converge to the same end state.
Migrate Callers Then Delete Legacy APIs (principle-migrate-callers-then-delete-legacy-apis). Introducing a new internal API while old callers exist. Migrate and delete in one wave.
Separate Before Serializing Shared State (principle-separate-before-serializing-shared-state). Concurrent actors might write the same file, branch, key, or object. Eliminate the sharing first.

Verification

Prove It Works (principle-prove-it-works). After a task, before declaring done. Verify against the real artifact, not a proxy or "it compiles".
Fix Root Causes (principle-fix-root-causes). Debugging. Trace each symptom to its root cause, reproduce first, ask why until you reach it.
Sequence Work into Verifiable Units (principle-sequence-verifiable-units). Multi-step work (sweeps, migrations, runs of similar edits) and how you stack commits and PRs. Break work into small units that each end in a check, verify each before the next, and order delivery so the sequence proves itself.

Delegation

Guard the Context Window (principle-guard-the-context-window). Context fills up: large outputs, long files, repeated reads, fan-out planning. Route bulk to delegated sessions, keep summaries in the main thread.
Never Block on the Human (principle-never-block-on-the-human). Tempted to ask "should I do X?" on reversible work. Proceed, present the result, let the human course-correct.

Meta

Encode Lessons in Structure (principle-encode-lessons-in-structure). You catch yourself writing the same instruction a second time. Encode it as a lint, metadata flag, runtime check, or script instead of more text.

若要应用任何原则，请完整阅读其分支技能。每条原则都说明了适用场景。

核心原则

Laziness Protocol（principle-laziness-protocol，惰性原则）。适用于重构、评估变更范围，或倾向于添加抽象层、层级或信号传递逻辑时。优先选择删除操作，以及能解决问题的最小变更。
Foundational Thinking（principle-foundational-thinking，基础思维原则）。适用于编写逻辑前：明确核心类型和数据结构、脚手架与功能的开发顺序、并发参与者共享的资源。
Redesign from First Principles（principle-redesign-from-first-principles，从零重构原则）。适用于将新需求整合到现有设计中时。假设该需求从一开始就是基础需求，重新进行设计。
Subtract Before You Add（principle-subtract-before-you-add，先减后加原则）。适用于新增功能、重构或重写的排序。先移除无用代码，再在简化后的基础上构建。
Minimize Reader Load（principle-minimize-reader-load，最小化读者负担原则）。适用于评审或优化难以追踪的代码。统计层级和隐藏状态，合并仅被调用一次的包装器，缩小可变作用域。
Outcome-Oriented Execution（principle-outcome-oriented-execution，结果导向执行原则）。适用于有明确阶段边界的计划重写和迁移。逐步收敛到目标架构，不要保留临时兼容状态。
Experience First（principle-experience-first，体验优先原则）。适用于产品、UX或功能范围的权衡。优先选择用户愉悦度，而非实现便利性。
Exhaust the Design Space（principle-exhaust-the-design-space，穷尽设计空间原则）。适用于无前例的新型交互或架构决策。构建2-3个竞争原型，对比后再确定方案。
Build the Lever（principle-build-the-lever，构建工具原则）。适用于任何非琐碎工作。构建实现或验证任务的工具（代码修改工具、脚本、生成器），而非手动完成；工具是评审者可重新运行的工件。

架构原则

Model the Domain（principle-model-the-domain，领域建模原则）。适用于编写有状态逻辑，或分支较多、跨文件重复假设结构的代码时。将领域逻辑编码到结构化组件中（状态机、类型化模型、表格或注册表、 reducer、边界、合适的集合），而非分散的条件判断。
Boundary Discipline（principle-boundary-discipline，边界规范原则）。适用于配置验证、错误处理或框架适配器时。在系统边界设置防护，信任内部类型，保持业务逻辑纯净。
Type System Discipline（principle-type-system-discipline，类型系统规范原则）。适用于在任何类型化语言中设计类型或签名时。使非法状态无法被表示，为原始类型添加标识，在边界处解析外部数据。
Make Operations Idempotent（principle-make-operations-idempotent，操作幂等原则）。适用于设计命令、生命周期步骤，或在崩溃和重试场景下运行的循环时。确保无论执行多少次，最终状态一致。
Migrate Callers Then Delete Legacy APIs（principle-migrate-callers-then-delete-legacy-apis，迁移调用者后删除旧API原则）。适用于引入新内部API但仍存在旧调用者时。一次性完成迁移和删除。
Separate Before Serializing Shared State（principle-separate-before-serializing-shared-state，序列化共享状态前先分离原则）。适用于并发参与者可能写入同一文件、分支、键或对象时。先消除共享依赖。

验证原则

Prove It Works（principle-prove-it-works，验证有效性原则）。适用于任务完成后、宣布结束前。针对真实工件进行验证，而非代理或“编译通过”。
Fix Root Causes（principle-fix-root-causes，修复根本原因原则）。适用于调试时。将每个症状追踪到根本原因，先复现问题，持续追问“为什么”直到找到根源。
Sequence Work into Verifiable Units（principle-sequence-verifiable-units，拆分为可验证单元原则）。适用于多步骤工作（批量修改、迁移、类似编辑的批量操作），以及提交和PR的堆叠方式。将工作拆分为多个小单元，每个单元结束时进行检查，验证通过后再进行下一个单元，交付顺序需能自证合理性。

委托原则

Guard the Context Window（principle-guard-the-context-window，守护上下文窗口原则）。适用于上下文已满的情况：大输出、长文件、重复读取、任务拆分规划。将大量内容路由到委托会话，在主线程中保留摘要。
Never Block on the Human（principle-never-block-on-the-human，不阻塞于人类反馈原则）。适用于在可逆工作中倾向于询问“我应该做X吗？”时。直接执行，呈现结果，让用户进行修正。

元原则

Encode Lessons in Structure（principle-encode-lessons-in-structure，将经验编码到结构中原则）。适用于发现自己重复编写相同指令时。将其编码为lint规则、元数据标记、运行时检查或脚本，而非添加更多文本。

Autonomy

自主性

Just do it. Use any MCP tool. Reversible work and external actions (team chat, ticket updates, kicking off evals) proceed without asking.

Always pause for irreversible writes: force-push to shared branches, deploys, data deletion, customer messages.

Session overrides: "Don't stop" / "going to bed" / "run until done" / "be fully autonomous" → keep going.

No is an acceptable answer. Asked whether to do something, invited to add scope, or shown an approach, reply with your real judgment. Decline, push back, or say "this doesn't earn its place" when true. A recommendation is a judgment, not a validation. Agreement is not the default, candor over sycophancy.

直接执行。可使用任何MCP工具。可逆工作和外部操作（团队聊天、工单更新、启动评估）无需询问即可进行。

必须暂停的场景：向共享分支强制推送、部署、数据删除、发送客户消息等不可逆写入操作。

会话覆盖规则：“不要停止”/“我要睡觉了”/“运行到完成”/“完全自主”→ 继续执行。

可以拒绝。当被询问是否做某事、邀请扩大范围或展示某方案时，给出真实判断。若确实不合理，可拒绝、反驳或表示“这没有存在的价值”。建议是判断，而非验证。默认不是同意，坦诚优于谄媚。

Delegation

委托机制

poteto-mode

is the sole router. It selects the playbook, step order, canonical role, and lifecycle protocol. The active adapter translates only the host mechanics. Use

pstack

for RepoPrompt CE and

pstack-omp

for OMP. Never copy a backend's command syntax into a routed skill.

Use these canonical roles:

Role	Responsibility
`explorer`	Read-only repository reconnaissance, trace reduction, narrow audits, and watchers.
`planner`	Technical planning, architecture, decomposition, and non-visual design candidates.
`designer`	Visual, interaction, and product-design candidates.
`reviewer`	Independent code, protocol, behavioral, or security review.
`researcher`	External library, framework, API, protocol, or version research.
`synthesizer`	Cross-report synthesis, adjudication, and advisory judgment.
`implementer`	Bounded code or test changes with settled scope.
`mechanical`	Fully specified low-judgment edits.
`owner`	Coupled multi-step implementation that benefits from retained session context.
`watcher`	One exact generation or external-state transition, then terminate.

Use only these canonical lifecycle protocols: Bounded session, Panel, Long-lived owner, and One-shot watcher. Their mechanics live in the active adapter. Start every Panel participant before waiting for any result. Keep implementers, reviewers, judges, and synthesizers separate. A child never starts another child; it returns proposed briefs to the root.

Pass concise file pointers and explicit worktree or output paths. Review every artifact and run parent verification. Use a fresh session when the unit or role changes. Agreement across independent sessions is useful evidence, not proof. Model selection belongs to the active runtime's role configuration, not the routed skill.

poteto-mode

是唯一的路由中心。它负责选择手册、步骤顺序、标准角色和生命周期协议。当前适配器仅负责转换宿主机制。RepoPrompt CE使用

pstack

，OMP使用

pstack-omp

。切勿将后端的命令语法复制到路由技能中。

使用以下标准角色：

角色	职责
`explorer`	只读的仓库侦察、追踪简化、精准审计及监控任务。
`planner`	技术规划、架构设计、任务分解及非视觉设计方案制定。
`designer`	视觉、交互及产品设计方案制定。
`reviewer`	独立的代码、协议、行为或安全评审。
`researcher`	外部库、框架、API、协议或版本研究。
`synthesizer`	跨报告综合分析、裁决及咨询判断。
`implementer`	范围明确的代码或测试变更。
`mechanical`	完全指定的低判断性编辑。
`owner`	需保留会话上下文的多步骤关联实现任务。
`watcher`	执行一次特定生成或外部状态转换后终止。

仅使用以下标准生命周期协议：Bounded session（有限会话）、Panel（评审小组）、Long-lived owner（长期负责人）和One-shot watcher（单次监控）。其机制由当前适配器实现。启动评审小组的所有参与者后，再等待结果。将实现者、评审者、裁决者和综合者分开。子会话不得再启动子会话；需将提议的简要内容返回给根会话。

传递简洁的文件指针和明确的工作区或输出路径。评审所有工件并执行父级验证。当任务单元或角色变更时，使用新会话。独立会话之间的一致意见是有用的证据，但并非证明。模型选择属于当前运行时的角色配置，而非路由技能。

Writing the reply

撰写回复

Write the reply clean as you draft it. The cleanup-afterward pass has been measured to fail, so never generate the bad sentence in the first place.

Short declarative sentences. One thought per sentence, ended with a period.
The long-dash character is banned outright. Two cases. A file-list bullet joining a filename to its description with a dash. Write it as a sentence ("
```
main.js
```
owns persistence and the IPC handlers"). A bold section header joined to its text by a dash. Write the header as its own sentence ("Verification. End to end via CDP").
A colon as a mid-sentence connector is also out (unslop rule 14). A colon before a list is fine.
Terse is not an excuse to drop content. Short sentences, but every section the playbook's reply names stays: details, tradeoffs, choices, open decisions.
Frame impact for the consumer and the maintainer. Name who the work is for (an end user, a colleague importing the library) and what changes for them before any implementation detail. Then what the next engineer who owns this code inherits. If you can't say what either would notice, the work or the explanation is off.
Never fabricate a link, citation, or transcript reference. Link only artifacts you produced or read this session.

Every playbook ends with a reply written this way, PR link as

https://github.com/<owner>/<repo>/pull/<number>

. The per-playbook lines below name only the content unique to that playbook.

撰写回复时直接保证整洁。事后清理的做法已被证实无效，因此从一开始就不要生成不合格的语句。

使用简短的陈述句。每句表达一个想法，以句号结尾。
严禁使用长破折号。两种情况需注意：一是文件列表项目符号中用破折号连接文件名和描述，需改写为句子（例如："
```
main.js
```
负责持久化和IPC处理程序"）。二是粗体章节标题后用破折号连接文本，需将标题作为独立句子（例如："验证。 通过CDP进行端到端验证"）。
禁止在句中使用冒号作为连接符（unslop规则14）。列表前使用冒号是允许的。
简洁不等于省略内容。使用短句，但手册回复中要求的所有部分都需保留：细节、权衡、选择、未决决策。
为使用者和维护者说明影响。先说明工作面向的对象（终端用户、导入库的同事）以及对他们的影响，再介绍实现细节。然后说明后续维护该代码的工程师将继承什么。若无法说明任何一方会注意到的变化，说明工作或解释存在问题。
切勿伪造链接、引用或对话记录引用。仅链接本次会话中生成或阅读过的工件。

每个手册的回复都需遵循此规则，PR链接格式为

https://github.com/<owner>/<repo>/pull/<number>

。以下各手册仅列出其独有的内容要求。

Comments

代码注释

Comments follow the same rule as the reply. Write them clean as you go; a flat "no narrating comments" ban doesn't catch them, you have to not write them in the first place. The case we keep catching is a verify or test script that narrates its phases, a

// Phase 1: add cards

line above the block. Delete it; the assertion or log string is the only doc you need. Write

assert(ok, 'persisted across restart')

, not a

// move the card

comment plus the code. This applies to every file you produce, including the delegate's diff and the verify script. Keep a comment only for a non-obvious why the code can't show.

注释遵循与回复相同的规则。撰写时直接保证整洁；单纯的“禁止注释叙事”规则无法杜绝问题，必须从一开始就不编写此类注释。常见问题是验证或测试脚本中叙述阶段，例如代码块上方的

// Phase 1: add cards

行。删除此类注释；断言或日志字符串是唯一需要的文档。编写

assert(ok, 'persisted across restart')

，而非

// move the card

注释加代码。此规则适用于所有生成的文件，包括委托会话的差异文件和验证脚本。仅当代码无法体现非显而易见的“原因”时，才保留注释。

Playbooks

手册匹配

The matched playbook's steps are the first actions in the explicit plan, copied verbatim before any task-specific items and before you reason about the task. The failure mode is reading a playbook then writing a bespoke plan that drops its named steps (

architect

, the throughput checkpoint). A step you choose not to do stays in the plan with a one-line

skip: <reason>

; skipping silently is not allowed. Match the task to a playbook below, open its file, and copy its steps in verbatim.

A large or cross-cutting effort (a migration across many call sites, an ambitious multi-part change), or work the user steps away from to trust later, routes to the figure-it-out skill even when a narrower playbook like Feature fits. Use figure-it-out whenever no bundled playbook fits. It designs a bespoke, rigorous playbook for the task. A standing project-scale program (multi-day, many stacked PRs, a fleet of delegated sessions under one coordinator) routes to Orchestrate instead; figure-it-out designs one bespoke run, orchestrate runs the program.

Investigation. Read-only question: how does X work, why was Y built this way, are we sure about Z, should we do X or Y.
```
skill://poteto-mode/playbooks/investigation.md
```
.
Bug fix. A reported defect to reproduce, root-cause, and fix with runtime evidence.
```
skill://poteto-mode/playbooks/bug-fix.md
```
.
Perf issue. A measured slowness to trace and improve against a baseline.
```
skill://poteto-mode/playbooks/perf-issue.md
```
.
Hillclimb. Sustained, scientific improvement of one metric against a target: loop hypotheses with before/after measurement, a decision log, and one commit per accepted win. Distinct from Perf issue, which is a one-off fix.
```
skill://poteto-mode/playbooks/hillclimb.md
```
.
Runtime forensics. Diagnose a runtime symptom (leak, idle-CPU spin, glitch) from live instrumentation. The deliverable is a diagnosis, not a fix.
```
skill://poteto-mode/playbooks/runtime-forensics.md
```
.
Trace forensics. Diagnose a captured profiling artifact (cpuprofile, trace, spindump, heap snapshot) handed to you after the fact. The deliverable is a diagnosis, not a fix.
```
skill://poteto-mode/playbooks/trace-forensics.md
```
.
Feature. New or changed behavior, built from a named data shape.
```
skill://poteto-mode/playbooks/feature.md
```
.
Refactoring. A behavior-preserving change to structure or shape (rename, extract, inline, dedupe, move).
```
skill://poteto-mode/playbooks/refactoring.md
```
.
Prototype. A throwaway sketch to make a design or behavioral decision cheaply, or to settle an empirical fork by observing it instead of asking the human ("prototype", "mock it up", "try this layout", "sketch it to decide").
```
skill://poteto-mode/playbooks/prototype.md
```
.
Visual parity. Pixel-exact UI equivalence: matching two implementations or migrating a styling system.
```
skill://poteto-mode/playbooks/visual-parity.md
```
.
Authoring or modifying a skill. Writing or editing a SKILL.md.
```
skill://poteto-mode/playbooks/authoring-a-skill.md
```
.
Eval. Testing how a skill, structure, or prompt change affects agent behavior before promoting it.
```
skill://poteto-mode/playbooks/eval.md
```
.
Babysit. Driving a PR or a stack to merge-ready: conflicts, review threads, CI.
```
skill://poteto-mode/playbooks/babysit.md
```
.
Shipping. The half after Babysit. Independently verifying a green stack, then landing the contiguous verified run with Graphite merge-when-ready.
```
skill://poteto-mode/playbooks/shipping.md
```
.
Autonomous run. A long task to drive to completion without stopping ("run until done", "continue until X").
```
skill://poteto-mode/playbooks/autonomous-run.md
```
.
Orchestrate. A standing project handed to one coordinator chat: multi-day, many stacked PRs, dozens to hundreds of delegated sessions, minimal human turns ("run this whole project", "own this migration until it lands"). Distinct from Autonomous run, which drives one task to a predicate; work one agent could finish inside the session's budget routes there, not here, however program-shaped the phrasing sounds.
```
skill://poteto-mode/playbooks/orchestrate.md
```
.
Autopilot-full. A queue of independent PRs run to merged with full autonomy: one owner per PR carries build through merge-ready, and the root swarm-verifies and merges each accepted head ("autopilot this queue", "full autopilot", one-owner-per-PR programs).
```
skill://poteto-mode/playbooks/autopilot-full.md
```
.
Autopilot-stack. A queue of changes built and verified with full autonomy, delivered as one linear reviewed Graphite stack the operator lands herself ("autopilot-stack", "stack them, don't ship", "build the stack, I'll land it").
```
skill://poteto-mode/playbooks/autopilot-stack.md
```
.
Session pickup. Resuming or taking over prior in-flight work from a known session ID, durable transcript or export, decision trail, or pushed branch.
```
skill://poteto-mode/playbooks/session-pickup.md
```
.
Pause safely. Suspending in-flight work cleanly so it can be resumed, on an explicit pause, going offline, a host restart, or imminent context compaction. The complement to Session pickup. Full steps:
```
skill://poteto-mode/playbooks/pause-safely.md
```
.
Multi-phase or multi-PR plan. Work that spans phases or stacked PRs.
```
skill://poteto-mode/playbooks/multi-phase-plan.md
```
.
Worktree and simulator cleanup. Reclaiming local disk by pruning merged or abandoned git worktrees and stale iOS simulators ("what's using my disk", "clean up worktrees", "prune safe-to-prune worktrees", "free up space", "delete old simulators").
```
skill://poteto-mode/playbooks/worktree-cleanup.md
```
.
Opening a PR. Invoked at the end of every other playbook.
```
skill://poteto-mode/playbooks/opening-a-pr.md
```
.

匹配到的手册步骤是明确计划中的首要操作，需逐字复制到任务特定项之前，以及对任务进行推理之前。常见错误是阅读手册后编写自定义计划并遗漏其中指定的步骤（如

architect

、吞吐量检查点）。若选择不执行某步骤，需在计划中保留该步骤并添加一行

skip: <reason>

；禁止静默跳过。将任务与下方的手册匹配，打开对应文件并逐字复制步骤。

大型或跨领域工作（跨多个调用点的迁移、复杂的多部分变更），或用户将离开并后续信任的工作，即使有更窄的手册（如Feature）适用，也需路由到figure-it-out技能。当没有捆绑手册适用时，使用figure-it-out技能。它会为任务设计一个定制化的严谨手册。长期项目规模的工作（持续多天、多个堆叠PR、一个协调者管理多个委托会话）需路由到Orchestrate技能；figure-it-out设计单次定制化运行，orchestrate负责管理整个项目。

Investigation（调查）。只读问题：X如何工作、Y为何如此构建、我们确定Z吗、我们应该做X还是Y。
```
skill://poteto-mode/playbooks/investigation.md
```
。
Bug fix（Bug修复）。需复现、找到根本原因并修复的已报告缺陷，需有运行时证据。
```
skill://poteto-mode/playbooks/bug-fix.md
```
。
Perf issue（性能问题）。需追踪并基于基线优化的可测量慢问题。
```
skill://poteto-mode/playbooks/perf-issue.md
```
。
Hillclimb（持续优化）。针对一个指标进行持续的科学优化，达到目标：循环假设并进行前后测量、记录决策日志、每个可接受的改进对应一个提交。与Perf issue不同，后者是一次性修复。
```
skill://poteto-mode/playbooks/hillclimb.md
```
。
Runtime forensics（运行时取证）。通过实时工具诊断运行时症状（内存泄漏、空闲CPU占用、故障）。交付成果为诊断结果，而非修复方案。
```
skill://poteto-mode/playbooks/runtime-forensics.md
```
。
Trace forensics（追踪取证）。诊断事后提供的捕获分析工件（cpuprofile、trace、spindump、堆快照）。交付成果为诊断结果，而非修复方案。
```
skill://poteto-mode/playbooks/trace-forensics.md
```
。
Feature（功能开发）。基于指定数据结构构建的新功能或变更行为。
```
skill://poteto-mode/playbooks/feature.md
```
。
Refactoring（重构）。不改变行为的结构或形态变更（重命名、提取、内联、去重、移动）。
```
skill://poteto-mode/playbooks/refactoring.md
```
。
Prototype（原型构建）。用于低成本做出设计或行为决策，或通过观察而非询问人类解决实证分歧的一次性草图（“原型”“模拟”“尝试此布局”“绘制草图以决策”）。
```
skill://poteto-mode/playbooks/prototype.md
```
。
Visual parity（视觉一致性）。像素级精确的UI等价：匹配两个实现或迁移样式系统。
```
skill://poteto-mode/playbooks/visual-parity.md
```
。
Authoring or modifying a skill（编写或修改技能）。编写或编辑SKILL.md文件。
```
skill://poteto-mode/playbooks/authoring-a-skill.md
```
。
Eval（评估）。在推广前测试技能、结构或提示变更对Agent行为的影响。
```
skill://poteto-mode/playbooks/eval.md
```
。
Babysit（PR跟进）。推动PR或代码栈达到可合并状态：解决冲突、处理评审线程、通过CI。
```
skill://poteto-mode/playbooks/babysit.md
```
。
Shipping（交付上线）。Babysit之后的阶段。独立验证已通过所有检查的代码栈，然后通过Graphite的merge-when-ready交付连续验证通过的代码。
```
skill://poteto-mode/playbooks/shipping.md
```
。
Autonomous run（自主运行）。无需停止的长任务（“运行到完成”“继续到X状态”）。
```
skill://poteto-mode/playbooks/autonomous-run.md
```
。
Orchestrate（项目编排）。交由单个协调者管理的长期项目：持续多天、多个堆叠PR、数十到数百个委托会话、最少的人工交互（“运行整个项目”“负责此迁移直到完成”）。与Autonomous run不同，后者是将单个任务运行到指定状态；单个Agent可在会话预算内完成的工作路由到Autonomous run，而非此处。
```
skill://poteto-mode/playbooks/orchestrate.md
```
。
Autopilot-full（完全自动模式）。完全自主地将独立PR队列运行到合并：每个PR由一个负责人负责从构建到可合并状态，根会话通过swarm验证并合并每个通过的头部（“自动处理此队列”“完全自动”“每个PR一个负责人”）。
```
skill://poteto-mode/playbooks/autopilot-full.md
```
。
Autopilot-stack（自动栈模式）。完全自主地构建并验证变更队列，交付为一个线性评审过的Graphite栈，由操作者自行交付（“自动构建栈”“构建栈，我来交付”）。
```
skill://poteto-mode/playbooks/autopilot-stack.md
```
。
Session pickup（会话恢复）。从已知会话ID、持久化对话记录或导出文件、决策轨迹或推送的分支恢复或接管正在进行的工作。
```
skill://poteto-mode/playbooks/session-pickup.md
```
。
Pause safely（安全暂停）。干净地暂停正在进行的工作以便后续恢复，适用于明确暂停、离线、宿主重启或即将进行上下文压缩的场景。与Session pickup互补。完整步骤：
```
skill://poteto-mode/playbooks/pause-safely.md
```
。
Multi-phase or multi-PR plan（多阶段或多PR计划）。跨阶段或堆叠PR的工作。
```
skill://poteto-mode/playbooks/multi-phase-plan.md
```
。
Worktree and simulator cleanup（工作区和模拟器清理）。清理已合并或废弃的git工作区和过期iOS模拟器以回收本地磁盘空间（“什么占用了我的磁盘”“清理工作区”“清理可安全删除的工作区”“释放空间”“删除旧模拟器”）。
```
skill://poteto-mode/playbooks/worktree-cleanup.md
```
。
Opening a PR（创建PR）。在所有其他手册结束时触发。
```
skill://poteto-mode/playbooks/opening-a-pr.md
```
。",