gstack /autoplan Phase 3.5 开发者体验审查指南双模型共识、8 维 DX 评分卡与自动决策【免费下载链接】gstackUse Garry Tans exact Claude Code setup: 23 opinionated tools that serve as CEO, Designer, Eng Manager, Release Manager, Doc Engineer, and QA项目地址: https://gitcode.com/GitHub_Trending/gs/gstack导读本文面向希望将开发者体验DX审查流水线化的 AI 工程团队与 Claude Code 技能作者。gstack 的/autoplan是一条自动审查流水线把 CEO、设计、工程、DX 四个评审阶段串成顺序执行的决策树每个阶段都由**覆盖规则Override Rules 双模型独立评审Dual Voices 必产物清单Required Outputs**构成。autoplan/sections/dx-phase.md正是其中Phase 3.5DX 审查的条件化阶段骨架当待评审计划检测到开发者向暴露面API、CLI、SDK、文档、Claude Code Skill 等时才加载执行。读完本文你将掌握DX 阶段何时触发、覆盖规则如何把 6 条决策原则映射到 DX 场景、Claude 子代理与 Codex 双声部如何并行并以共识表收敛、8 个维度的 Pass 审查如何评分、以及阶段结束时必须产出的 5 类工件。背景dx-phase.md 在 autoplan 流水线中的位置从模板自动生成的分节文件autoplan/sections/dx-phase.md的头部注释明确了两点它是AUTO-GENERATED产物源文件为 dx-phase.md.tmpl改模板后需通过bun run gen:skill-docs重新生成该再生成链路由 test/gen-skill-docs.test.ts 等测试守护模板与产物的一致性。因此读者若发现该文件与模板的差异应以模板为修改入口。分区注册表何时读取该节autoplan/sections/manifest.json 是一份PASSIVE registry只做字段登记不做决策它记录了每个分节的id、file、title与triggeridfile触发时机ceo-phaseceo-phase.mdPhase 1CEO 审查总是运行在 Phase 0.5 预检后design-phasedesign-phase.mdPhase 2设计审查仅当 Phase 0 检测到 UI 范围eng-phaseeng-phase.mdPhase 3工程审查总是运行dx-phasedx-phase.mdPhase 3.5DX 审查仅当检测到开发者向范围否则完全跳过读取tasks-aggregatortasks-aggregator.mdPhase 4最终批准门聚合 $AGGREGATED_TASKSmanifest 的 note 字段还强调了设计哲学Phase 2 与 Phase 3.5 是条件化阶段范围不存在时必须不读取其分节required-reads存活于 E2E fixtures 中决策逻辑只留在骨架与各技能文件里。这条纪律由测试守护test/skill-e2e-autoplan-chain.test.ts 专门验证条件化阶段Design、DX在范围缺失时被跳过且各阶段绝不并行执行——回归到模板把阶段并发接线会立即被该测试抓住。顺序执行骨架与从哪里加载技能autoplan/SKILL.md 是总控骨架四阶段必须严格串行CEO → Design → Eng → DX每阶段完成后必须先输出阶段过渡摘要并核验上一阶段产物齐备才能进入下一阶段。Phase 3.5 的实际评审方法学并不存在于 dx-phase.md 内部而是按引用加载独立交互版plan-devex-review/SKILL.md全 8 维、完整深度的方法来源分 Pass 执行细则位于 plan-devex-review/sections/review-sections.md每个 Pass 的金标准参考片段按需从 plan-devex-review/dx-hall-of-fame.md 读取对应章节。dx-phase.md 的核心职责是给出自动化改写层同样深度执行这些内容但把每个 AskUserQuestion 用 6 条决策原则自动拍板只在最后批准门向人类呈现品味决策Taste Decision与用户挑战User Challenge。Phase 3.5 的加载门DX 范围检测Phase 3.5 不是无条件运行的。总控在 Phase 0 对计划文本做关键词扫描见 autoplan/SKILL.md Step 2: Read context命中以下类别即判定存在开发者向范围API 面关键词API、endpoint、REST、GraphQL、gRPC、webhookCLI 面关键词CLI、command、flag、argument、terminal、shellSDK/库面关键词SDK、library、package、npm、pip、import、require技能/Agent 面关键词SKILL.md、skill template、Claude Code、MCP、agent、OpenClaw、action文档/上手面关键词developer docs、getting started、onboarding、integration、debug、implement、error message。规则要求命中 2 个以上才算通过且带排除项如单独的 page、缩写中的 UI 视为误报。另有两种直通触发计划描述的产品本身就是开发者工具开发者要安装、集成或在它之上构建的东西或者AI Agent 是主要用户OpenClaw actions、Claude Code skills、MCP servers。一旦判定通过Phase 3.5 即依序读取 dx-phase.md 并全深度执行否则打印 Phase 3.5 skipped — no developer-facing scope detected. 并整体跳过。这与manifest.json中dx-phase的 trigger 描述完全一致也与 test/skill-e2e-autoplan-chain.test.ts 中对**Phase 3.5 complete.标记为可选、无 DX 范围时跳过的断言相互印证。覆盖规则把 6 条决策原则投影到 DX 评审dx-phase.md 的第二段是Override rules即把所有本应问用户的决策点改由6 条决策原则自动裁决。6 原则定义在 autoplan/SKILL.md The 6 Decision Principles是P1 Choose completeness、P2 Boil lakes、P3 Pragmatic、P4 DRY、P5 Explicit over clever、P6 Bias toward action。dx 阶段的投影如下表决策点覆盖规则含原则依据模式选择固定为DX POLISH不扩范围、把每个触点打磨到无懈可击开发者画像Persona从 README/docs 推断取最常见开发者类型标注P6竞品基准WebSearch 可用就跑真搜索否则用内置参考基准如 Stripe 30s、Vercel 2min、Firebase 3min、Docker 5min标注P1魔法时刻Magical Moment选交付成本最低、又能达到竞品档位的载体标注P5上手摩擦永远向更少步骤优化P5简单胜过巧妙错误消息质量强制满足问题 原因 修复三段式P1完整性API/CLI 命名一致性优先于聪明P5DX 品味决策如独断默认 vs 灵活显式标记TASTE DECISION双声部只要 Codex 可用就同时跑Claude 子代理与 CodexP6这套映射的含义模式选择、画像选择这类在交互版里需要人回答的问题在 /autoplan 语境里被降级为机械可拍而合理之人可能各执一词的品味问题则被精确打标流向最终批准门。dx-phase.md 同时规定分类口径若 Codex 用合理开发者共情理由反对某个 DX 决策 → TASTE DECISION两个模型一致认同的范围变更 → USER CHALLENGE。USER CHALLENGE 永不自动拍板——用户的原方向是默认值模型必须论证为何要改详见 autoplan/SKILL.md Decision Classification。双声部Codex DX Voice 与 Claude DX Subagent为什么需要两个独立评审者DX 审查中单一模型可能带着同一种品味偏好系统性看漏问题。Phase 3.5 因此强制双声部独立运行Claude 子代理先行前台阻塞、Codex 随后两者都完成后才能构建共识表。缺一声部时按降级矩阵处理见下文错误处理与降级。Codex DX Voice经 Bashdx-phase.md 给出了可直接复制的调用骨架_REPO_ROOT$(git rev-parse --show-toplevel) || { echo ERROR: not in a git repo 2; exit 1; } _gstack_codex_timeout_wrapper 600 codex exec IMPORTANT: Do NOT read or execute any SKILL.md files or files in skill definition directories (paths containing skills/gstack). These are AI assistant skill definitions meant for a different system. Stay focused on repository code only. Read the plan file at plan_path. Evaluate this plans developer experience. Also consider these findings from prior review phases: CEO: insert CEO consensus summary Eng: insert Eng consensus summary You are a developer who has never seen this product. Evaluate: 1. Time to hello world: how many steps from zero to working? Target is under 5 minutes. 2. Error messages: when something goes wrong, does the dev know what, why, and how to fix? 3. API/CLI design: are names guessable? Are defaults sensible? Is it consistent? 4. Docs: can a dev find what they need in under 2 minutes? Are examples copy-paste-complete? 5. Upgrade path: can devs upgrade without fear? Migration guides? Deprecation warnings? Be adversarial. Think like a developer who is evaluating this against 3 competitors. -C $_REPO_ROOT -s read-only -c web_searchcached /dev/null _CODEX_EXIT$? if [ $_CODEX_EXIT 124 ]; then _gstack_codex_log_event codex_timeout 600 _gstack_codex_log_hang autoplan 0 echo [codex stalled past 10 minutes — tagging as [codex-unavailable] for this phase and proceeding with Claude subagent only] fi这段骨架体现了 /autoplan 全流水线共用的若干关键设计文件系统边界指令提示词首行强制要求 Codex 不得读取/执行任何 SKILL.md 或技能定义目录内容防止它发现磁盘上的 gstack 技能文件后转而去执行技能指令而不是评审计划。同一约束在 autoplan/SKILL.md Filesystem Boundary — Codex Prompts 中被规定为发给 Codex 的所有提示的固定前缀。提示词始终以对抗语气收尾Be adversarial. Think like a developer who is evaluating this against 3 competitors.——DX 评审的价值在于挑毛病而非确认。前序阶段上下文被注入CEO/Eng 的共识摘要作为输入使 DX 评审能建立在前面阶段的发现之上但 Claude 子代理恰恰相反被禁止携带前序上下文见下。超时与挂死处理_gstack_codex_timeout_wrapper 600设置 10 分钟壳层超时退出码 124 意味着超时此时记事件codex_timeout/codex_hang并把本阶段 Codex 声部自动降级为[codex-unavailable]仅以 Claude 子代理继续。dx-phase.md 明确超时预算为10 分钟shell-wrapper 12 分钟Bash 外层闸门。运行方式为-C $_REPO_ROOT -s read-only -c web_searchcached在仓库根目录执行、只读沙箱、Web 搜索用缓存这对应于 autoplan/SKILL.md Phase 0.5 中对 Codex 认证与模型的四步预检codex_reviewsdisabled→ 二进制缺失 → 认证失败 → 模型被拒任一环节失败都令_CODEX_AVAILABLEfalse随后各阶段自动切到[codex-unavailable]路径。Claude DX Subagent经 Agent 工具dx-phase.md 给出的子代理提示词强调真正独立性Read the plan file at plan_path. You are an independent DX engineer reviewing this plan. You have NOT seen any prior review. Evaluate:Getting started: how many steps from zero to hello world? Whats the TTHW?API/CLI ergonomics: naming consistency, sensible defaults, progressive disclosure?Error handling: does every error path specify problem cause fix docs link?Documentation: copy-paste examples? Information architecture? Interactive elements?Escape hatches: can developers override every opinionated default? For each finding: whats wrong, severity (critical/high/medium), and the fix.它与 Codex 提示的最大差别是NO prior-phase context — subagent must be truly independent这是刻意的对抗设计。Codex 看到 CEO/Eng 摘要倾向于在既有发现上深化Claude 子代理被隔离在真空里专门负责捕捉前序评审的盲区。两条声部各自的评估重点也不同Codex 偏首次使用者的冷启动体验与竞品对抗Claude 子代理偏命名一致性、渐进披露、错误路径完备性与逃生舱escape hatch。两者互为独立盲检。呈现格式与共识表两条声部的结果须分别挂在CODEX SAYS (DX — developer experience challenge)与CLAUDE SUBAGENT (DX — independent review)两个标题下随后产出 DX 双声部共识表DX DUAL VOICES — CONSENSUS TABLE: ═══════════════════════════════════════════════════════════════ Dimension Claude Codex Consensus ──────────────────────────────────── ─────── ─────── ───────── 1. Getting started 5 min? — — — 2. API/CLI naming guessable? — — — 3. Error messages actionable? — — — 4. Docs findable complete? — — — 5. Upgrade path safe? — — — 6. Dev environment friction-free? — — — ═══════════════════════════════════════════════════════════════ CONFIRMED both agree. DISAGREE models differ (→ taste decision). Missing voice N/A (not CONFIRMED). Single critical finding from one voice flagged regardless.共识表对缺失/分歧的语义有精确规定CONFIRMED 仅在双方一致时成立DISAGREE 项进入品味决策流程在对应 Pass 中带着双方视角再次提出单一声部缺失记 N/A不算确认而哪怕只有一声部抛出单个 critical 级发现也必须标记——critical 发现不因另一声部缺席而静默。这张表是跨模型一致性的最小可核对载体也是后续 Pass 评分时哪项分歧需要在相关 Pass 双视角复议的索引。错误处理与降级矩阵dx-phase.md 注明 DX 阶段的错误处理 same as Phase 1CEO两条声部都前台阻塞运行但存在明确降级矩阵。可推断的完整行为模式与 ceo-phase.md 中 CEO 声部的矩阵同构Codex 因认证/超时/空响应失败 → 仅以 Claude 子代理继续并打[single-model]标记子代理也失败 → Outside voices unavailable — continuing with primary review.两败 → single-reviewer mode仅 Codex 成功 →[codex-only]仅子代理成功 →[subagent-only]。缺失的声部在共识表中以 N/A 呈现、不冒充 CONFIRMED这是 /autoplan 对评审证据必须诚实标注的总体纪律的一部分。必执行检查清单Step 0 → Step 0.5 → Pass 1-8 → Scorecarddx-phase.md 给出四步必执行清单构成 DX 阶段的推进管线Step 0DX 范围评估自动检测产品类型绘制开发者旅程图Developer Journey为初始 DX 完备度打 0-10 分评估 TTHWTime to Hello World。对应独立交互版 plan-devex-review/SKILL.md 中 0A-0G 的完整调查阶段画像质询、共情叙事、竞品基准、魔法时刻设计、模式选择、旅程摩擦追踪、首见开发者角色扮演的自动化收编。Step 0.5双声部先跑 Claude 子代理前台再跑 Codex产出上文共识表。Passes 1-8从已加载技能即plan-devex-review相关文件逐一运行 8 个 Pass逐项 0-10 评分并自动决策共识表中 DISAGREE 项在对应 Pass内带双方视角提出。这 8 个 Pass 的完整定义见 review-sections.md每个 Pass 都附有反跳过规则任何计划类型都不得压缩或跳过任一 Pass与证据回召要求评分必须引用 Step 0 的画像/竞品/摩擦证据而非凭感觉打分。8 维如下Pass维度核心评估问题1Getting Started零摩擦从零到 hello world 能否在 5 分钟内完成安装是否一条命令2API/CLI/SDK 设计命名是否可猜、默认值是否合理、全程是否一致、是否渐进披露3错误消息与调试每条错误路径是否给出问题 原因 修复 文档链接4文档与学习2 分钟内能否找到所需示例是否可复制即用5升级与迁移路径升级是否有恐惧弃用警告、迁移指南、codemod 是否齐备6开发环境与工具链编辑器集成、CI/CD、跨平台、本地可复现性如何7社区与生态代码是否开源、渠道是否有人应答、示例是否真实可跑8DX 度量与反馈环TTHW 是否可测量、流失点能否定位、评审能否回旋镖复查Pass 3 内部还会引用 Hall of Fame 的三层错误消息体系做对照Tier 1 Elm 式对话化直述定位、Tier 2 Rust 式错误码链教程、Tier 3 Stripe 式结构化 JSON 带type/code/message/param/doc_url若产品类型含 Claude Code skill还要额外执行附录的Claude Code Skill DX Checklistgstack 自身 DX 沉淀的已验证模式清单不计分只核对。DX Scorecard产出覆盖全部 8 个维度的完整评分卡。独立交互版评分卡的最终形态含 Dimension/Score/Prior/Trend 表、TTHW、Competitive Rank、Magical Moment、Product Type、Mode、Overall DX以及 DX 原则覆盖区Zero Friction / Learn by Doing / Fight Uncertainty / Opinionated Escape Hatches / Code in Context / Magical Moments。其解读规则可复用于自动化语境全部 Pass ≥ 8 视为 DX plan is solid任一 Pass 6 标记为关键 DX 债TTHW 10 分钟标记为阻塞问题。Phase 3.5 的必产物与阶段过渡dx-phase.md 明确列出Phase 3.5 Mandatory outputs缺一不可总控的 Pre-Gate Verification 会在进入 Phase 4 前逐一核验见 autoplan/SKILL.md Pre-Gate VerificationDeveloper journey map9 阶段表覆盖 Discover → Evaluate → Install → Hello World → Integrate → Debug → Upgrade → Scale → Migrate 的完整旅程。9 阶段来自开发者旅程整体性认知模式——每个缺口都可能丢一个开发者plan-devex-review/SKILL.md 的 Journey wholeness。Developer empathy narrative第一人称视角以目标画像口吻、逐文件逐命令地重走真实上手路径落到 I open the README. The first heading is [actual heading]…不得虚构。DX Scorecard8 维全评分所有 Pass 分数汇总。DX Implementation Checklist把评审结论压成可勾选的落地清单如 Time to hello world target、Installation is one command、Every error message has: problem cause fix docs link、Escape hatches exist。TTHW assessment with target当前 TTHW 实测/估计值与目标值target 来自竞品基准选定的档位如 Champion 2min / Competitive 2-5min / Needs Work 5-10min / Red Flag 10min见 plan-devex-review/SKILL.md TTHW Benchmarks。阶段完成时输出过渡摘要其固定模板为Phase 3.5 complete.DX overall: [N]/10. TTHW: [N] min → [target] min. Codex: [N concerns]. Claude subagent: [N issues]. Consensus: [X/6 confirmed, Y disagreements → surfaced at gate]. Passing to Phase 4 (Final Gate).这一模板同时是自动化测试的锚点test/skill-e2e-autoplan-chain.test.ts 用**Phase 3.5 complete.**正则作为阶段标记验证阶段顺序、条件化跳过与不并行约束。模板中的 X/6 confirmed 正是双声部共识表的 6 个维度Y disagreements → surfaced at gate 明确了分歧的出口——品味分歧不在阶段内硬裁决而是升入 Phase 4 最终批准门呈现给用户。把 dx-phase.md 放到更大的图景中理解 dx-phase.md 还需要两处上下文均可在仓库中核实上游交互版plan-devex-review提供方法学与校准基线。dx-phase.md 第一句就是 Follow plan-devex-review/SKILL.md — all 8 DX dimensions, full depth.。这个交互版技能版本 2.0.0frontmatter 见 plan-devex-review/SKILL.md贡献了 8 条DX First Principles零摩擦 T0、增量步骤、做中学、替我决定但允许我推翻、对抗不确定性、展示真实上下文代码、速度即特性、创造魔法时刻、Seven DX CharacteristicsUsable/Credible/Findable/Useful/Valuable/Accessible/Desirable 及金标准参照、DX Scoring Rubric0-10 分校准9-10 一流、5-6 可容忍但有摩擦、1-2 开发者首次尝试即弃、0 完全未考虑与优先级层级Step 0 画像 共情叙事 竞品基准 魔法时刻 TTHW 错误质量 上手 API/CLI 人体工学 其余。/autoplan 的 DX 阶段相当于把这一整套方法学以 P6 原则静默代答所有中间问题地跑一遍。下游任务聚合与批准门。DX 阶段的必产物与其它阶段一起被 Pre-Gate Verification 校验各阶段发现最终由 tasks-aggregator 汇总为 $AGGREGATED_TASKS进入 Phase 4 最终批准门autoplan/SKILL.md Phase 4: Final Approval Gate。人类在这一步看到的是N 个自动决策的审计轨迹每行写入计划文件的 Decision Audit Trail、品味决策清单含推荐与反向后果、以及可能存在的 User Challenge附What the user said / What both models recommend / Why / What context we might be missing / If were wrong, the cost is五段式论据。换言之dx-phase.md 不是把审查结论交给用户的终点而是把模型已尽力、人类只裁最后分歧的自动化审查哲学落到 DX 维度上的一个条件化节点。关键要点速查触发条件DX 范围由 Phase 0 关键词扫描判定≥2 命中或产品即开发者工具 / AI Agent 为主要用户直通范围缺失时整个 Phase 3.5 与 dx-phase.md 的读取一并跳过。方法学来源dx-phase.md 是覆盖层方法学本体在plan-devex-review/SKILL.md与sections/review-sections.md金标准参考按 Pass 分段存放于dx-hall-of-fame.md。双声部Claude 子代理先行、无前序上下文、负责独立盲检Codex 随后、携带 CEO/Eng 共识、负责对抗性冷启动评审超时/失败按矩阵降级并如实打标。共识口径CONFIRMED 需双一致DISAGREE 进品味决策缺声部记 N/A单声部 critical 发现不静默。覆盖决策每类 AskUserQuestion 都有明确的 6 原则投影与 TASTE DECISION / USER CHALLENGE 分类后者永不自动拍板。必产物9 阶段旅程图、第一人称共情叙事、8 维 DX Scorecard、DX Implementation Checklist、TTHW 评估与目标缺一会被 Pre-Gate 拦回。【免费下载链接】gstackUse Garry Tans exact Claude Code setup: 23 opinionated tools that serve as CEO, Designer, Eng Manager, Release Manager, Doc Engineer, and QA项目地址: https://gitcode.com/GitHub_Trending/gs/gstack创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
gstack /autoplan Phase 3.5 开发者体验审查指南：双模型共识、8 维 DX 评分卡与自动决策
gstack /autoplan Phase 3.5 开发者体验审查指南双模型共识、8 维 DX 评分卡与自动决策【免费下载链接】gstackUse Garry Tans exact Claude Code setup: 23 opinionated tools that serve as CEO, Designer, Eng Manager, Release Manager, Doc Engineer, and QA项目地址: https://gitcode.com/GitHub_Trending/gs/gstack导读本文面向希望将开发者体验DX审查流水线化的 AI 工程团队与 Claude Code 技能作者。gstack 的/autoplan是一条自动审查流水线把 CEO、设计、工程、DX 四个评审阶段串成顺序执行的决策树每个阶段都由**覆盖规则Override Rules 双模型独立评审Dual Voices 必产物清单Required Outputs**构成。autoplan/sections/dx-phase.md正是其中Phase 3.5DX 审查的条件化阶段骨架当待评审计划检测到开发者向暴露面API、CLI、SDK、文档、Claude Code Skill 等时才加载执行。读完本文你将掌握DX 阶段何时触发、覆盖规则如何把 6 条决策原则映射到 DX 场景、Claude 子代理与 Codex 双声部如何并行并以共识表收敛、8 个维度的 Pass 审查如何评分、以及阶段结束时必须产出的 5 类工件。背景dx-phase.md 在 autoplan 流水线中的位置从模板自动生成的分节文件autoplan/sections/dx-phase.md的头部注释明确了两点它是AUTO-GENERATED产物源文件为 dx-phase.md.tmpl改模板后需通过bun run gen:skill-docs重新生成该再生成链路由 test/gen-skill-docs.test.ts 等测试守护模板与产物的一致性。因此读者若发现该文件与模板的差异应以模板为修改入口。分区注册表何时读取该节autoplan/sections/manifest.json 是一份PASSIVE registry只做字段登记不做决策它记录了每个分节的id、file、title与triggeridfile触发时机ceo-phaseceo-phase.mdPhase 1CEO 审查总是运行在 Phase 0.5 预检后design-phasedesign-phase.mdPhase 2设计审查仅当 Phase 0 检测到 UI 范围eng-phaseeng-phase.mdPhase 3工程审查总是运行dx-phasedx-phase.mdPhase 3.5DX 审查仅当检测到开发者向范围否则完全跳过读取tasks-aggregatortasks-aggregator.mdPhase 4最终批准门聚合 $AGGREGATED_TASKSmanifest 的 note 字段还强调了设计哲学Phase 2 与 Phase 3.5 是条件化阶段范围不存在时必须不读取其分节required-reads存活于 E2E fixtures 中决策逻辑只留在骨架与各技能文件里。这条纪律由测试守护test/skill-e2e-autoplan-chain.test.ts 专门验证条件化阶段Design、DX在范围缺失时被跳过且各阶段绝不并行执行——回归到模板把阶段并发接线会立即被该测试抓住。顺序执行骨架与从哪里加载技能autoplan/SKILL.md 是总控骨架四阶段必须严格串行CEO → Design → Eng → DX每阶段完成后必须先输出阶段过渡摘要并核验上一阶段产物齐备才能进入下一阶段。Phase 3.5 的实际评审方法学并不存在于 dx-phase.md 内部而是按引用加载独立交互版plan-devex-review/SKILL.md全 8 维、完整深度的方法来源分 Pass 执行细则位于 plan-devex-review/sections/review-sections.md每个 Pass 的金标准参考片段按需从 plan-devex-review/dx-hall-of-fame.md 读取对应章节。dx-phase.md 的核心职责是给出自动化改写层同样深度执行这些内容但把每个 AskUserQuestion 用 6 条决策原则自动拍板只在最后批准门向人类呈现品味决策Taste Decision与用户挑战User Challenge。Phase 3.5 的加载门DX 范围检测Phase 3.5 不是无条件运行的。总控在 Phase 0 对计划文本做关键词扫描见 autoplan/SKILL.md Step 2: Read context命中以下类别即判定存在开发者向范围API 面关键词API、endpoint、REST、GraphQL、gRPC、webhookCLI 面关键词CLI、command、flag、argument、terminal、shellSDK/库面关键词SDK、library、package、npm、pip、import、require技能/Agent 面关键词SKILL.md、skill template、Claude Code、MCP、agent、OpenClaw、action文档/上手面关键词developer docs、getting started、onboarding、integration、debug、implement、error message。规则要求命中 2 个以上才算通过且带排除项如单独的 page、缩写中的 UI 视为误报。另有两种直通触发计划描述的产品本身就是开发者工具开发者要安装、集成或在它之上构建的东西或者AI Agent 是主要用户OpenClaw actions、Claude Code skills、MCP servers。一旦判定通过Phase 3.5 即依序读取 dx-phase.md 并全深度执行否则打印 Phase 3.5 skipped — no developer-facing scope detected. 并整体跳过。这与manifest.json中dx-phase的 trigger 描述完全一致也与 test/skill-e2e-autoplan-chain.test.ts 中对**Phase 3.5 complete.标记为可选、无 DX 范围时跳过的断言相互印证。覆盖规则把 6 条决策原则投影到 DX 评审dx-phase.md 的第二段是Override rules即把所有本应问用户的决策点改由6 条决策原则自动裁决。6 原则定义在 autoplan/SKILL.md The 6 Decision Principles是P1 Choose completeness、P2 Boil lakes、P3 Pragmatic、P4 DRY、P5 Explicit over clever、P6 Bias toward action。dx 阶段的投影如下表决策点覆盖规则含原则依据模式选择固定为DX POLISH不扩范围、把每个触点打磨到无懈可击开发者画像Persona从 README/docs 推断取最常见开发者类型标注P6竞品基准WebSearch 可用就跑真搜索否则用内置参考基准如 Stripe 30s、Vercel 2min、Firebase 3min、Docker 5min标注P1魔法时刻Magical Moment选交付成本最低、又能达到竞品档位的载体标注P5上手摩擦永远向更少步骤优化P5简单胜过巧妙错误消息质量强制满足问题 原因 修复三段式P1完整性API/CLI 命名一致性优先于聪明P5DX 品味决策如独断默认 vs 灵活显式标记TASTE DECISION双声部只要 Codex 可用就同时跑Claude 子代理与 CodexP6这套映射的含义模式选择、画像选择这类在交互版里需要人回答的问题在 /autoplan 语境里被降级为机械可拍而合理之人可能各执一词的品味问题则被精确打标流向最终批准门。dx-phase.md 同时规定分类口径若 Codex 用合理开发者共情理由反对某个 DX 决策 → TASTE DECISION两个模型一致认同的范围变更 → USER CHALLENGE。USER CHALLENGE 永不自动拍板——用户的原方向是默认值模型必须论证为何要改详见 autoplan/SKILL.md Decision Classification。双声部Codex DX Voice 与 Claude DX Subagent为什么需要两个独立评审者DX 审查中单一模型可能带着同一种品味偏好系统性看漏问题。Phase 3.5 因此强制双声部独立运行Claude 子代理先行前台阻塞、Codex 随后两者都完成后才能构建共识表。缺一声部时按降级矩阵处理见下文错误处理与降级。Codex DX Voice经 Bashdx-phase.md 给出了可直接复制的调用骨架_REPO_ROOT$(git rev-parse --show-toplevel) || { echo ERROR: not in a git repo 2; exit 1; } _gstack_codex_timeout_wrapper 600 codex exec IMPORTANT: Do NOT read or execute any SKILL.md files or files in skill definition directories (paths containing skills/gstack). These are AI assistant skill definitions meant for a different system. Stay focused on repository code only. Read the plan file at plan_path. Evaluate this plans developer experience. Also consider these findings from prior review phases: CEO: insert CEO consensus summary Eng: insert Eng consensus summary You are a developer who has never seen this product. Evaluate: 1. Time to hello world: how many steps from zero to working? Target is under 5 minutes. 2. Error messages: when something goes wrong, does the dev know what, why, and how to fix? 3. API/CLI design: are names guessable? Are defaults sensible? Is it consistent? 4. Docs: can a dev find what they need in under 2 minutes? Are examples copy-paste-complete? 5. Upgrade path: can devs upgrade without fear? Migration guides? Deprecation warnings? Be adversarial. Think like a developer who is evaluating this against 3 competitors. -C $_REPO_ROOT -s read-only -c web_searchcached /dev/null _CODEX_EXIT$? if [ $_CODEX_EXIT 124 ]; then _gstack_codex_log_event codex_timeout 600 _gstack_codex_log_hang autoplan 0 echo [codex stalled past 10 minutes — tagging as [codex-unavailable] for this phase and proceeding with Claude subagent only] fi这段骨架体现了 /autoplan 全流水线共用的若干关键设计文件系统边界指令提示词首行强制要求 Codex 不得读取/执行任何 SKILL.md 或技能定义目录内容防止它发现磁盘上的 gstack 技能文件后转而去执行技能指令而不是评审计划。同一约束在 autoplan/SKILL.md Filesystem Boundary — Codex Prompts 中被规定为发给 Codex 的所有提示的固定前缀。提示词始终以对抗语气收尾Be adversarial. Think like a developer who is evaluating this against 3 competitors.——DX 评审的价值在于挑毛病而非确认。前序阶段上下文被注入CEO/Eng 的共识摘要作为输入使 DX 评审能建立在前面阶段的发现之上但 Claude 子代理恰恰相反被禁止携带前序上下文见下。超时与挂死处理_gstack_codex_timeout_wrapper 600设置 10 分钟壳层超时退出码 124 意味着超时此时记事件codex_timeout/codex_hang并把本阶段 Codex 声部自动降级为[codex-unavailable]仅以 Claude 子代理继续。dx-phase.md 明确超时预算为10 分钟shell-wrapper 12 分钟Bash 外层闸门。运行方式为-C $_REPO_ROOT -s read-only -c web_searchcached在仓库根目录执行、只读沙箱、Web 搜索用缓存这对应于 autoplan/SKILL.md Phase 0.5 中对 Codex 认证与模型的四步预检codex_reviewsdisabled→ 二进制缺失 → 认证失败 → 模型被拒任一环节失败都令_CODEX_AVAILABLEfalse随后各阶段自动切到[codex-unavailable]路径。Claude DX Subagent经 Agent 工具dx-phase.md 给出的子代理提示词强调真正独立性Read the plan file at plan_path. You are an independent DX engineer reviewing this plan. You have NOT seen any prior review. Evaluate:Getting started: how many steps from zero to hello world? Whats the TTHW?API/CLI ergonomics: naming consistency, sensible defaults, progressive disclosure?Error handling: does every error path specify problem cause fix docs link?Documentation: copy-paste examples? Information architecture? Interactive elements?Escape hatches: can developers override every opinionated default? For each finding: whats wrong, severity (critical/high/medium), and the fix.它与 Codex 提示的最大差别是NO prior-phase context — subagent must be truly independent这是刻意的对抗设计。Codex 看到 CEO/Eng 摘要倾向于在既有发现上深化Claude 子代理被隔离在真空里专门负责捕捉前序评审的盲区。两条声部各自的评估重点也不同Codex 偏首次使用者的冷启动体验与竞品对抗Claude 子代理偏命名一致性、渐进披露、错误路径完备性与逃生舱escape hatch。两者互为独立盲检。呈现格式与共识表两条声部的结果须分别挂在CODEX SAYS (DX — developer experience challenge)与CLAUDE SUBAGENT (DX — independent review)两个标题下随后产出 DX 双声部共识表DX DUAL VOICES — CONSENSUS TABLE: ═══════════════════════════════════════════════════════════════ Dimension Claude Codex Consensus ──────────────────────────────────── ─────── ─────── ───────── 1. Getting started 5 min? — — — 2. API/CLI naming guessable? — — — 3. Error messages actionable? — — — 4. Docs findable complete? — — — 5. Upgrade path safe? — — — 6. Dev environment friction-free? — — — ═══════════════════════════════════════════════════════════════ CONFIRMED both agree. DISAGREE models differ (→ taste decision). Missing voice N/A (not CONFIRMED). Single critical finding from one voice flagged regardless.共识表对缺失/分歧的语义有精确规定CONFIRMED 仅在双方一致时成立DISAGREE 项进入品味决策流程在对应 Pass 中带着双方视角再次提出单一声部缺失记 N/A不算确认而哪怕只有一声部抛出单个 critical 级发现也必须标记——critical 发现不因另一声部缺席而静默。这张表是跨模型一致性的最小可核对载体也是后续 Pass 评分时哪项分歧需要在相关 Pass 双视角复议的索引。错误处理与降级矩阵dx-phase.md 注明 DX 阶段的错误处理 same as Phase 1CEO两条声部都前台阻塞运行但存在明确降级矩阵。可推断的完整行为模式与 ceo-phase.md 中 CEO 声部的矩阵同构Codex 因认证/超时/空响应失败 → 仅以 Claude 子代理继续并打[single-model]标记子代理也失败 → Outside voices unavailable — continuing with primary review.两败 → single-reviewer mode仅 Codex 成功 →[codex-only]仅子代理成功 →[subagent-only]。缺失的声部在共识表中以 N/A 呈现、不冒充 CONFIRMED这是 /autoplan 对评审证据必须诚实标注的总体纪律的一部分。必执行检查清单Step 0 → Step 0.5 → Pass 1-8 → Scorecarddx-phase.md 给出四步必执行清单构成 DX 阶段的推进管线Step 0DX 范围评估自动检测产品类型绘制开发者旅程图Developer Journey为初始 DX 完备度打 0-10 分评估 TTHWTime to Hello World。对应独立交互版 plan-devex-review/SKILL.md 中 0A-0G 的完整调查阶段画像质询、共情叙事、竞品基准、魔法时刻设计、模式选择、旅程摩擦追踪、首见开发者角色扮演的自动化收编。Step 0.5双声部先跑 Claude 子代理前台再跑 Codex产出上文共识表。Passes 1-8从已加载技能即plan-devex-review相关文件逐一运行 8 个 Pass逐项 0-10 评分并自动决策共识表中 DISAGREE 项在对应 Pass内带双方视角提出。这 8 个 Pass 的完整定义见 review-sections.md每个 Pass 都附有反跳过规则任何计划类型都不得压缩或跳过任一 Pass与证据回召要求评分必须引用 Step 0 的画像/竞品/摩擦证据而非凭感觉打分。8 维如下Pass维度核心评估问题1Getting Started零摩擦从零到 hello world 能否在 5 分钟内完成安装是否一条命令2API/CLI/SDK 设计命名是否可猜、默认值是否合理、全程是否一致、是否渐进披露3错误消息与调试每条错误路径是否给出问题 原因 修复 文档链接4文档与学习2 分钟内能否找到所需示例是否可复制即用5升级与迁移路径升级是否有恐惧弃用警告、迁移指南、codemod 是否齐备6开发环境与工具链编辑器集成、CI/CD、跨平台、本地可复现性如何7社区与生态代码是否开源、渠道是否有人应答、示例是否真实可跑8DX 度量与反馈环TTHW 是否可测量、流失点能否定位、评审能否回旋镖复查Pass 3 内部还会引用 Hall of Fame 的三层错误消息体系做对照Tier 1 Elm 式对话化直述定位、Tier 2 Rust 式错误码链教程、Tier 3 Stripe 式结构化 JSON 带type/code/message/param/doc_url若产品类型含 Claude Code skill还要额外执行附录的Claude Code Skill DX Checklistgstack 自身 DX 沉淀的已验证模式清单不计分只核对。DX Scorecard产出覆盖全部 8 个维度的完整评分卡。独立交互版评分卡的最终形态含 Dimension/Score/Prior/Trend 表、TTHW、Competitive Rank、Magical Moment、Product Type、Mode、Overall DX以及 DX 原则覆盖区Zero Friction / Learn by Doing / Fight Uncertainty / Opinionated Escape Hatches / Code in Context / Magical Moments。其解读规则可复用于自动化语境全部 Pass ≥ 8 视为 DX plan is solid任一 Pass 6 标记为关键 DX 债TTHW 10 分钟标记为阻塞问题。Phase 3.5 的必产物与阶段过渡dx-phase.md 明确列出Phase 3.5 Mandatory outputs缺一不可总控的 Pre-Gate Verification 会在进入 Phase 4 前逐一核验见 autoplan/SKILL.md Pre-Gate VerificationDeveloper journey map9 阶段表覆盖 Discover → Evaluate → Install → Hello World → Integrate → Debug → Upgrade → Scale → Migrate 的完整旅程。9 阶段来自开发者旅程整体性认知模式——每个缺口都可能丢一个开发者plan-devex-review/SKILL.md 的 Journey wholeness。Developer empathy narrative第一人称视角以目标画像口吻、逐文件逐命令地重走真实上手路径落到 I open the README. The first heading is [actual heading]…不得虚构。DX Scorecard8 维全评分所有 Pass 分数汇总。DX Implementation Checklist把评审结论压成可勾选的落地清单如 Time to hello world target、Installation is one command、Every error message has: problem cause fix docs link、Escape hatches exist。TTHW assessment with target当前 TTHW 实测/估计值与目标值target 来自竞品基准选定的档位如 Champion 2min / Competitive 2-5min / Needs Work 5-10min / Red Flag 10min见 plan-devex-review/SKILL.md TTHW Benchmarks。阶段完成时输出过渡摘要其固定模板为Phase 3.5 complete.DX overall: [N]/10. TTHW: [N] min → [target] min. Codex: [N concerns]. Claude subagent: [N issues]. Consensus: [X/6 confirmed, Y disagreements → surfaced at gate]. Passing to Phase 4 (Final Gate).这一模板同时是自动化测试的锚点test/skill-e2e-autoplan-chain.test.ts 用**Phase 3.5 complete.**正则作为阶段标记验证阶段顺序、条件化跳过与不并行约束。模板中的 X/6 confirmed 正是双声部共识表的 6 个维度Y disagreements → surfaced at gate 明确了分歧的出口——品味分歧不在阶段内硬裁决而是升入 Phase 4 最终批准门呈现给用户。把 dx-phase.md 放到更大的图景中理解 dx-phase.md 还需要两处上下文均可在仓库中核实上游交互版plan-devex-review提供方法学与校准基线。dx-phase.md 第一句就是 Follow plan-devex-review/SKILL.md — all 8 DX dimensions, full depth.。这个交互版技能版本 2.0.0frontmatter 见 plan-devex-review/SKILL.md贡献了 8 条DX First Principles零摩擦 T0、增量步骤、做中学、替我决定但允许我推翻、对抗不确定性、展示真实上下文代码、速度即特性、创造魔法时刻、Seven DX CharacteristicsUsable/Credible/Findable/Useful/Valuable/Accessible/Desirable 及金标准参照、DX Scoring Rubric0-10 分校准9-10 一流、5-6 可容忍但有摩擦、1-2 开发者首次尝试即弃、0 完全未考虑与优先级层级Step 0 画像 共情叙事 竞品基准 魔法时刻 TTHW 错误质量 上手 API/CLI 人体工学 其余。/autoplan 的 DX 阶段相当于把这一整套方法学以 P6 原则静默代答所有中间问题地跑一遍。下游任务聚合与批准门。DX 阶段的必产物与其它阶段一起被 Pre-Gate Verification 校验各阶段发现最终由 tasks-aggregator 汇总为 $AGGREGATED_TASKS进入 Phase 4 最终批准门autoplan/SKILL.md Phase 4: Final Approval Gate。人类在这一步看到的是N 个自动决策的审计轨迹每行写入计划文件的 Decision Audit Trail、品味决策清单含推荐与反向后果、以及可能存在的 User Challenge附What the user said / What both models recommend / Why / What context we might be missing / If were wrong, the cost is五段式论据。换言之dx-phase.md 不是把审查结论交给用户的终点而是把模型已尽力、人类只裁最后分歧的自动化审查哲学落到 DX 维度上的一个条件化节点。关键要点速查触发条件DX 范围由 Phase 0 关键词扫描判定≥2 命中或产品即开发者工具 / AI Agent 为主要用户直通范围缺失时整个 Phase 3.5 与 dx-phase.md 的读取一并跳过。方法学来源dx-phase.md 是覆盖层方法学本体在plan-devex-review/SKILL.md与sections/review-sections.md金标准参考按 Pass 分段存放于dx-hall-of-fame.md。双声部Claude 子代理先行、无前序上下文、负责独立盲检Codex 随后、携带 CEO/Eng 共识、负责对抗性冷启动评审超时/失败按矩阵降级并如实打标。共识口径CONFIRMED 需双一致DISAGREE 进品味决策缺声部记 N/A单声部 critical 发现不静默。覆盖决策每类 AskUserQuestion 都有明确的 6 原则投影与 TASTE DECISION / USER CHALLENGE 分类后者永不自动拍板。必产物9 阶段旅程图、第一人称共情叙事、8 维 DX Scorecard、DX Implementation Checklist、TTHW 评估与目标缺一会被 Pre-Gate 拦回。【免费下载链接】gstackUse Garry Tans exact Claude Code setup: 23 opinionated tools that serve as CEO, Designer, Eng Manager, Release Manager, Doc Engineer, and QA项目地址: https://gitcode.com/GitHub_Trending/gs/gstack创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
