用途：nuke-blitz 用于在会话内立即执行一个中等规模、单一交付物的任务，追求“流水线级质量、对话速度”。它位于 nuke-code（日常规模）与完整流水线（preflight、run_dir、waves、会话交接等仪式）之间的快车道，按 references/family-map.md 定位。
主要能力与流程：
- CALL：把需求重述为 2–5 条可证伪的完成标准、非目标与约束，读取项目说明文件而非凭记忆；做轻量侦察（如存在且新鲜的 .nuke/repo-map.md，否则只看任务触及的清单、结构与导出）；按泳道表判断规模。
- PLAN：先做一次复用扫描（grep 现有 helper、组件、工具，记录 reuse: <file:symbol> | none — searched: <terms>），再给出至少两种真正不同的实现形状、各自一行取舍，并写明选中理由；随后切分文件为互不重叠的批次并排人。打印 snap-plan 块后立即 GO（--ask 则先确认；plan 仅打印并停止）。
- GO：编辑前先跑一次已解析的闸门行建立基线；在 nuke-code BUILD 章程下构建，最小 diff，行为变更同 diff 内附行为测试。
- SEAL：重跑闸门（最窄优先、原样捕获输出），并交给一名全新验证者（独作→同层但全新会话；委派→比 worker 高一层；涉及公共 API、认证/安全、并发、数据迁移、新依赖等风险标记→最高层）。验证者按 roster 加载技能，逐条判定完成标准，依 references/lens-catalog.md 的四个章程包审查 diff 与影响面，并给出 fit 结论。确认的发现（任何严重度）都修复，每轮重新验证，最多 2 轮。
泳道边界（CALL 时检查）：内联规模（1 个文件且约 ≤30 行且无契约变更）走 nuke-code 内联模式；在道内（≤约 10 个触及文件、≤约 600 估计变更行、≤5 条完成标准、单一交付物）由 blitz 执行；超规模但清晰则停止并建议 nuke-exec；超规模且模糊或存在多个独立交付物则停止并建议 nuke-spec → exec。中途升级：困难设计决策 → 先 nuke-think；两次修复未证因的 bug → nuke-debug；涉及外观/设计或新 UI 面 → nuke-creative + nuke-design。
限制与规则：速度不得牺牲验证，基线、闸门与全新验证者不可省略，削减只针对仪式而非证据；澄清最多一轮（最多 3 个批量问题）；不得编造需求，也不得问文件读取即可回答的问题；不创建 run_dir、不写 .bak、不执行 git add / git commit / git stash，写入只触及任务自身文件；委派时主上下文保持精简，worker 只拿到路径与自己的批次；失败闸门、未满足标准或开放发现必须置于交接开头。降级情况：无子代理则独作并内联验证（显式角色切换、从磁盘 git diff 重读、标注 validator: inline (degraded)）；无按代理模型覆盖则所有角色继承会话模型，风险标记仍用平台最大努力档；Claude Code 用并行 Agent 调用，其他 CLI 顺序执行、每次全新上下文。
费用、价格、支持平台细节：资料暂未提供。