Back to Details

autopilot

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Autopilot

Autopilot

Overview

概述

Autopilot drives a dictated idea through the mattpocock/skills pipeline — grill → spec → tickets → implement — in one dialogue, without making the user approve each stage. The user answers questions once at the start and receives a working project at the end. Core principle: the order is the product — code is written only in the last phase, and every ticket is implemented by a separate subagent with a fresh, isolated context.
This skill only orchestrates — the phases below invoke the pipeline skills and follow their rules; nothing here restates them. What Autopilot adds: which human gates to remove, and how to run implementation hands-free.
Prerequisite: the pipeline skills must be installed — 
grilling
, 
to-spec
, 
to-tickets
, 
implement
(mattpocock/skills pack). If any is missing, install first:
bash
npx skills add mattpocock/skills
Autopilot 可将用户提出的想法通过 mattpocock/skills 流水线——grill（需求深挖）→ spec（规格文档）→ tickets（任务工单）→ implement（代码实现）——在一次对话中完成，无需用户逐一确认每个阶段。用户只需在初始阶段回答问题，最终即可获得可运行的项目。核心原则：流程即产品——仅在最后阶段编写代码，每个工单由独立的子Agent在全新隔离的上下文环境中实现。
本技能仅负责流程编排——以下阶段会调用流水线技能并遵循其规则；此处不再赘述这些规则。Autopilot 的新增特性在于：移除哪些人工审核环节，以及如何全自动执行实现流程。
前置条件： 必须安装流水线技能——
grilling
、
to-spec
、
to-tickets
、
implement
（属于 mattpocock/skills 技能包）。若缺少任意一项，请先执行安装：
bash
npx skills add mattpocock/skills

When to Use

使用场景

  • User dictates what to build and expects the finished thing, not a collaboration on process.
  • User is non-technical: will not read specs, judge ticket granularity, or review code.
  • "Собери под ключ", "just build it", "не задавай лишних вопросов".
When NOT to use: the user wants to co-design step by step (use the underlying skills manually); the task is a small single-file change (just do it); the idea is huge and foggy — bigger than one project, destination unclear (run 
/wayfinder
first, then return here).
  • 用户明确要求构建某产品，并期望直接获得成品，而非参与流程协作。
  • 用户为非技术人员：不会阅读规格文档、判断工单粒度或审查代码。
  • 类似“一站式搭建”“直接帮我建好”“不要问多余的问题”这类需求。
不适用于： 用户希望逐步协同设计（请手动使用底层技能）；任务仅为单个文件的小改动（直接处理即可）；想法过于庞大模糊——超出单个项目范围，目标不明确（先运行 
/wayfinder
，再返回使用本技能）。

The Pipeline

执行流程

Phase 1 — Grill (the only human gate)

阶段1——Grill（唯一的人工交互环节）

Run 
/grilling
on the dictated idea. Autopilot adds three rules:
  • Blocking unknowns first. Anything the build depends on but the user hasn't decided (payment provider, hosting, API keys, accounts) goes into the first three questions — never the finish line.
  • Never answer for the user. No silent assumptions, no fabricated content. Forced to proceed past an unknown → mark it 
    PLACEHOLDER — уточнить у пользователя
    .
  • Cap: 5–8 questions. Record answers verbatim — Phase 2 synthesizes from this transcript.
对用户提出的想法运行 
/grilling
。Autopilot 新增三条规则：
  • 优先处理阻塞性未知项。任何构建过程依赖但用户尚未确定的内容（如支付提供商、托管服务、API密钥、账户信息）需放在前三个问题中——绝不能留到最后。
  • 绝不替用户作答。不得默认假设，不得编造内容。若必须跳过某未知项，则标记为 
    PLACEHOLDER — 待向用户确认
    。
  • 上限：5-8个问题。如实记录用户回答——阶段2将基于此记录生成规格文档。

Phase 2 — Spec

阶段2——Spec（规格文档）

Run 
/to-spec
on the grilling transcript. No new questions to the user — anything still open becomes a PLACEHOLDER in the spec, not an interview.
基于Grill阶段的记录运行 
/to-spec
。不再向用户提出新问题——任何未明确的内容将在规格文档中标记为PLACEHOLDER，而非再次询问用户。

Phase 3 — Tickets

阶段3——Tickets（任务工单）

Run 
/to-tickets
, with one override: skip the user quiz — a vibecoder cannot judge granularity or blocking edges. Validate the breakdown yourself against the skill's own slicing rules, then show the user one screen of plain-language lines (what each ticket delivers, no technical detail) with a default: «Запускаю через 60 секунд, если не скажешь стоп». Do not wait for explicit approval — waiting is the failure mode this skill exists to remove.
运行 
/to-tickets
，并覆盖一项规则：跳过用户问卷——即兴编码用户无法判断工单粒度或阻塞点。需自行根据技能的拆分规则验证工单分解结果，然后向用户展示一页通俗易懂的内容（说明每个工单的交付成果，无技术细节），并默认提示：«若未收到停止指令，将在60秒后启动»。无需等待用户明确确认——等待正是本技能要解决的失效模式。

Phase 4 — Implement (subagent per ticket)

阶段4——Implement（代码实现：每个工单对应一个子Agent）

One ticket = one subagent = one fresh context. Each subagent runs 
/implement
on a single ticket and gets: the ticket body, the relevant spec sections, and paths to existing code. Never two tickets in one context — context pollution is exactly what breaks naive vibecoding.
  • No git repo yet → 
    git init
    at the start of this phase.     One commit per ticket — commits are the user's rollback points.
  • Unblocked tickets may run in parallel only when they touch disjoint files; same files → serialize.
  • After each ticket, report one plain-language line («Можно загрузить клиентов из файла — 3 из 8 готово»). No diffs, no jargon.
  • Ticket failed → retry once in a fresh context with the error attached. Second failure → stop, tell the user in plain language what is blocking and what you need.
一个工单 = 一个子Agent = 一个全新上下文。每个子Agent针对单个工单运行 
/implement
，并获取：工单内容、相关规格文档章节、现有代码路径。绝不能将两个工单放在同一上下文环境中——上下文污染正是导致即兴编码失效的关键原因。
  • 若尚未创建git仓库→在本阶段开始时执行 
    git init
    。每个工单对应一次提交——提交记录为用户提供回滚节点。
  • 非阻塞工单仅在涉及互不关联的文件时可并行执行；若涉及同一文件→需串行执行。
  • 每个工单完成后，向用户汇报一条通俗易懂的内容（如«已实现从文件导入客户功能——8项任务完成3项»）。无需展示代码差异，避免使用专业术语。
  • 工单执行失败→在全新上下文环境中重试一次，并附带错误信息。若再次失败→停止执行，用通俗易懂的语言告知用户阻塞点及所需信息。

Phase 5 — Finish

阶段5——Finish（收尾）

Full test suite once, then a final report in the user's language: what was built and the exact command to run it; what was NOT built (the spec's Out of Scope list); open items — placeholders, keys to add, manual steps left.
运行完整测试套件一次，然后用用户使用的语言生成最终报告：已完成的功能及启动项目的具体命令；未完成的内容（规格文档中的“超出范围”列表）；未解决的事项——占位符、需添加的密钥、剩余的手动步骤。

Rationalizations — STOP

常见误区——停止错误做法

ExcuseReality
«Пользователь сказал не задавать вопросов»Он сказал не задавать ЛИШНИХ. Решающие вопросы — часть работы, не обсуждение процесса.
«KISS — просто собери»Простой результат даёт порядок, а не пропуск этапов. Без спеки каждая правка — «а я имел в виду другое».
«Сделаю заглушку, уточнит потом»Блокирующие неизвестные (оплата, ключи, хостинг) решаются в grilling, до билда.
«И так понятно, что делать»Понятно тебе — не зафиксировано. Спека — единственная точка сверки.
«Быстрее всё сделать в одном контексте»Быстрее в первый час. Дальше модель ходит кругами и ломает работавшее.
借口实际情况
«用户说不要问问题»用户说的是不要问多余的问题。关键问题是工作的一部分，而非流程讨论。
«KISS原则——直接搭建即可»简洁的成果源于有序流程，而非跳过阶段。没有规格文档，每一次修改都会引发“我指的不是这个”的争议。
«先做个占位符，之后再确认»阻塞性未知项（支付、密钥、托管）需在Grill阶段解决，而非构建之后。
«该做什么很明显»你觉得明显，但并未记录下来。规格文档是唯一的校验依据。
«在同一个上下文环境中完成更快»前一小时可能更快，但之后模型会陷入循环并破坏已正常运行的代码。

Red Flags — start the phase over

危险信号——需重新启动当前阶段

  • Writing code before the spec exists.
  • Asking the user to review tickets, granularity, or code.
  • Two tickets in one subagent context.
  • Parallel subagents editing the same files.
  • Silent assumption not marked as PLACEHOLDER.
  • Payment/keys/hosting first mentioned at the finish line.
Violating the letter of these rules is violating their spirit.
  • 在规格文档生成前就编写代码。
  • 要求用户审查工单、粒度或代码。
  • 将两个工单放在同一个子Agent上下文环境中。
  • 并行执行的子Agent编辑同一文件。
  • 未将默认假设标记为PLACEHOLDER。
  • 支付/密钥/托管相关内容在收尾阶段才首次提及。
违反这些规则的字面要求，即违背其设计初衷。