impeccable 命令路由指南用信号驱动的上下文感知菜单精准选择下一个设计命令【免费下载链接】impeccableThe design language that makes your AI harness better at design.项目地址: https://gitcode.com/GitHub_Trending/im/impeccable导读本文基于 impeccable 的 routing.md 路由规范深入讲解当用户仅输入/impeccable无参数时Agent 应如何把你应该做什么这个问题从一份静态菜单升级为基于项目实时信号的上下文感知推荐。你将掌握impeccable context与impeccable signals的前置流程、五组决策信号的完整 JSON 字段与判定规则、detect本地扫描结果的融合方式以及2-3 个精准建议 全量菜单兜底、永不自动执行的交互原则——并结合仓库源码看清每条信号背后的真实实现。路由的两大入口工作流问题与无参数调用/impeccable的路由行为分为两种截然不同的场景见 SKILL.md 的 Routing 章节入口行为显式或明确隐含的命令请求加载对应命令的 reference 文档原生平台加载 native 变体若两个命令都合适则只问一次无参数调用/impeccable读取 routing.md 并呈现上下文感知菜单绝不自动执行任何命令工作流 / 命令选择类问题只给建议、不执行命令参见 routing.md 的 Workflow questions 一节工作流问题的边界只建议不执行当用户询问我接下来该做什么这类工作流问题时Agent 应只给出建议而不执行任何命令文档列出的命令菜单仅用于裸调用bare invocations。必要时按需查阅相关命令的 reference 以确认前置条件与作用范围更完整的工作流指南可参考仓库内文档体系。如果用户同时明确要求执行才跟随该请求去执行。无参数路由先看信号再给建议无参数调用的完整流程如下前置检查Setup 阶段已经运行过impeccable context。判断 NO_PRODUCT_MD如果 context 输出NO_PRODUCT_MD说明项目尚未捕获任何上下文此时菜单要把/impeccable init作为置顶推荐附一行理由其余菜单项仍展示在下方——不要静默跳过 init 直接进入别的命令。读取信号否则先运行一次.pi/skills/impeccable/scripts/impeccable signals并读取其 JSON 输出。给出推荐以信号为依据置顶2-3 个最高价值的下一步命令每个都附上一行来自信号的理由随后才是完整菜单SKILL.md 中按类别分组的 Commands 表。永不自动执行推荐只是用户确认前的建议Agent 不得擅自运行命令。为什么有 NO_PRODUCT_MD 这个分支NO_PRODUCT_MD不是普通日志而是一条带指令的上下文诊断。在 context_cli.rs 中可以看到它的两种形态项目已有既有视觉实现但没有 PRODUCT.md对init、teach、shape或任何新建 surface / 替换视觉世界的请求必须先加载 init.md 创建 PRODUCT.md其他窄范围细化命令可以基于代码继续而不阻塞随后建议运行 init。项目完全没有PRODUCT.md 也无既有实现从零构建类请求必须走 init 完成人工或模拟用户访谈并写出 PRODUCT.md 后才能开始设计对已有代码的局部命令则用代码作上下文继续把 init 作为建议不阻塞。这条指令正是 routing 规则中NO_PRODUCT_MD → 置顶 init决策的底层依据。signals 信号五个命名空间与真实 JSON 结构impeccable signals别名context-signals由 signals.rs 实现其gather_signals函数把散落在各模块的信息汇聚为一个 JSON 对象包含五个顶层命名空间。routing.md 的每条决策规则都直接消费这些字段{ setup: { hasProduct: true, productPath: PRODUCT.md, hasDesign: false, designPath: null, hasCode: true, platform: web }, critique: { latest: null }, git: { isRepo: true, branch: feature/x, base: main, changedFiles: [src/hero.tsx], changedCount: 1 }, devServer: { running: false, ports: [] }, scan: { targets: [], via: null } }各命名空间的来源与判定逻辑均有源码支撑setup由load_context与has_code汇总。hasDesign/hasProduct来自上下文加载结果hasCode的实现signals.rs检查package.json是否存在或src/app/pages/site/public/components/lib任一目录是否存在platform由 PRODUCT.md 内容提取extract_platform可能为ios/android/adaptive等。critique读取最近一次 critique 快照跨 target 读取最新快照归一化输出slug、score、p0、p1、timestamp、file。从未评审过则为null——这正是从未被 critique 过的项目默认推荐/impeccable critique surface的信号来源。git通过git_run包装的 git 命令获取仓库状态signals.rs。非仓库时isRepofalse且其余字段为空仓库内会解析分支、比较基准优先 upstream其次develop/main/master等集成分支并产出变更文件列表最多 50 个。devServer并发探测[4321, 3000, 5173, 5174, 8080, 8000, 4200]这 7 个常见开发端口signals.rs任一端口可连接即runningtrue并列出开放的端口。scan按优先级链生成可扫描目标signals.rsgit-changes工作树中可扫描的 markup/style 文件最相关→source-dirsrc/app/components/pages/public→html根目录index.html→root仅当有代码时指向.。决策规则五条核心信号 意图分组兜底routing.md 强调基于信号进行推理没有需要服从的分数。具体规则如下信号条件推荐命令理由setup.hasDesignfalse且setup.hasCodetruedocument项目有代码但缺视觉系统文档捕获视觉系统critique.latestnull且是已 setup 且有真实 surface 的项目critique surface项目从未被评审过这是强默认critique.latest分数低或p0/p1非零polishpolish 会把该快照当作待办清单并在过期或被清空时关闭它git.changedFiles指向单一 surfaceaudit/polish限定到这些文件并点名缩小审查范围到实际改动devServer.runningtruelive浏览器内迭代可用为 false 时不要置顶 live平台边界live 与 detect 仅限 Weblive和内置的impeccable detect仅适用于 Web 项目。若setup.platform是ios、android或adaptive不要置顶这两者——浏览器 overlay 与 HTML 规则引擎对原生应用代码不适用。这是 routing.md 明确划出的红线。意图分组兜底当以上信号都不命中时按用户意图分组给出建议构建新东西Build/ 改进已有内容Refine/ 视觉迭代Enhance/Iterate并贴合当前 surface 与setup.platform定制。融合 detect 扫描用真实、当前的信号替代猜测routing.md 要求当scan.targets非空且setup.platform不是ios/android/adaptive时运行一次.pi/skills/impeccable/scripts/impeccable detect --json scan.targets 以空格连接--json参数在 detect 的 CLI 定义 中有明确声明Output results as JSON用法示例即impeccable detect --json .见 cli.rs。这是内置的本地文件检测器无网络、无 npx直接读取 HTML/CSS因此对原生项目跳过。scan.via告知目标的来历git-changes脏工作树中的 markup/style 文件最相关、source-dir如src、app、html或root。命中结果的折叠方式大量quality / contrast 命中→audit或polish某个具体的slop 家族设计偷懒模式→ 对应命令渐变文字或 eyebrow 眉标 →quieter/typeset扁平或灰扑扑的调色板 →colorize依此类推。detect 是真实、当前的信号胜过猜测。但若 detect 报错或目录树太大扫描缓慢跳过它改为建议用户自己运行audit绝不让 detect 阻塞推荐。菜单兜底SKILL.md 的 Commands 表完整菜单即 SKILL.md 中的 Commands 表按类别分组作为推荐的兜底。推荐置顶后菜单保持可用Build构建shape先规划 UX/UI、init捕获 PRODUCT.md、document从代码生成 DESIGN.md、extract抽取 token 与组件进设计系统Evaluate评估critique启发式 UX 评分、audit可访问性/性能/响应式技术质量检查Refine细化polish发布前最终质量关卡、bolder、quieter、distill、harden、onboardEnhance增强animate、colorize、typeset、layout、delight、overdriveFix修复clarify、adapt、optimizeIterate迭代live浏览器视觉变体模式每个命令都有对应的 reference 文档位于 .pi/skills/impeccable/reference/ 目录下原生的adapt/audit有.native变体。运行机制补充signals 与 detect 如何被调用impeccable signals与impeccable detect都通过.pi/skills/impeccable/scripts/impeccable这个 POSIX shell 启动器调用Windows 下用同目录的impeccable.cmd。启动器impeccable遵循如下解析顺序$IMPECCABLE_BIN环境变量 → 随脚本分发同平台的二进制 →~/.impeccable/bin/impeccable经 engine-probe 握手校验→ 版本固定缓存 → PATH 上的impeccable同样先 probe 校验防止误命中已退役的 3.x npm CLI→ 最后才从发布渠道按版本下载并做 SHA-256 校验。整个过程不需要 Node 或任何其他运行时——这是 routing 流程可以在任意干净环境中稳定执行的前提。交互铁律推荐是 lede菜单是 fallback无论信号如何最终输出都应克制在2-3 个针对性建议给出用户可直接照抄的命令原文每个附一行理由完整菜单始终作为后备展示在下方。推荐是文章的标题lede菜单是兜底——而绝不自动运行命令是贯穿始终的红线Agent 的任务是告诉用户该做什么、为什么执行与否由用户确认。小结一条可复现的路由链路把整条链路串起来就是impeccable contextSetup 判定 NO_PRODUCT_MD 与否→ 有上下文则impeccable signals取回 setup/critique/git/devServer/scan 五组信号 → 按平台与信号折叠出 2-3 个推荐document / critique / polish / 定向 audit / live / detect 融合→ 输出推荐 全量菜单等待用户确认。这条链路完全由 routing.md 定义、由 signals.rs 提供数据、由 detect CLI 提供本地扫描佐证从决策到执行的每个环节都可审计、可复现。【免费下载链接】impeccableThe design language that makes your AI harness better at design.项目地址: https://gitcode.com/GitHub_Trending/im/impeccable创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
impeccable 命令路由指南：用信号驱动的上下文感知菜单精准选择下一个设计命令
impeccable 命令路由指南用信号驱动的上下文感知菜单精准选择下一个设计命令【免费下载链接】impeccableThe design language that makes your AI harness better at design.项目地址: https://gitcode.com/GitHub_Trending/im/impeccable导读本文基于 impeccable 的 routing.md 路由规范深入讲解当用户仅输入/impeccable无参数时Agent 应如何把你应该做什么这个问题从一份静态菜单升级为基于项目实时信号的上下文感知推荐。你将掌握impeccable context与impeccable signals的前置流程、五组决策信号的完整 JSON 字段与判定规则、detect本地扫描结果的融合方式以及2-3 个精准建议 全量菜单兜底、永不自动执行的交互原则——并结合仓库源码看清每条信号背后的真实实现。路由的两大入口工作流问题与无参数调用/impeccable的路由行为分为两种截然不同的场景见 SKILL.md 的 Routing 章节入口行为显式或明确隐含的命令请求加载对应命令的 reference 文档原生平台加载 native 变体若两个命令都合适则只问一次无参数调用/impeccable读取 routing.md 并呈现上下文感知菜单绝不自动执行任何命令工作流 / 命令选择类问题只给建议、不执行命令参见 routing.md 的 Workflow questions 一节工作流问题的边界只建议不执行当用户询问我接下来该做什么这类工作流问题时Agent 应只给出建议而不执行任何命令文档列出的命令菜单仅用于裸调用bare invocations。必要时按需查阅相关命令的 reference 以确认前置条件与作用范围更完整的工作流指南可参考仓库内文档体系。如果用户同时明确要求执行才跟随该请求去执行。无参数路由先看信号再给建议无参数调用的完整流程如下前置检查Setup 阶段已经运行过impeccable context。判断 NO_PRODUCT_MD如果 context 输出NO_PRODUCT_MD说明项目尚未捕获任何上下文此时菜单要把/impeccable init作为置顶推荐附一行理由其余菜单项仍展示在下方——不要静默跳过 init 直接进入别的命令。读取信号否则先运行一次.pi/skills/impeccable/scripts/impeccable signals并读取其 JSON 输出。给出推荐以信号为依据置顶2-3 个最高价值的下一步命令每个都附上一行来自信号的理由随后才是完整菜单SKILL.md 中按类别分组的 Commands 表。永不自动执行推荐只是用户确认前的建议Agent 不得擅自运行命令。为什么有 NO_PRODUCT_MD 这个分支NO_PRODUCT_MD不是普通日志而是一条带指令的上下文诊断。在 context_cli.rs 中可以看到它的两种形态项目已有既有视觉实现但没有 PRODUCT.md对init、teach、shape或任何新建 surface / 替换视觉世界的请求必须先加载 init.md 创建 PRODUCT.md其他窄范围细化命令可以基于代码继续而不阻塞随后建议运行 init。项目完全没有PRODUCT.md 也无既有实现从零构建类请求必须走 init 完成人工或模拟用户访谈并写出 PRODUCT.md 后才能开始设计对已有代码的局部命令则用代码作上下文继续把 init 作为建议不阻塞。这条指令正是 routing 规则中NO_PRODUCT_MD → 置顶 init决策的底层依据。signals 信号五个命名空间与真实 JSON 结构impeccable signals别名context-signals由 signals.rs 实现其gather_signals函数把散落在各模块的信息汇聚为一个 JSON 对象包含五个顶层命名空间。routing.md 的每条决策规则都直接消费这些字段{ setup: { hasProduct: true, productPath: PRODUCT.md, hasDesign: false, designPath: null, hasCode: true, platform: web }, critique: { latest: null }, git: { isRepo: true, branch: feature/x, base: main, changedFiles: [src/hero.tsx], changedCount: 1 }, devServer: { running: false, ports: [] }, scan: { targets: [], via: null } }各命名空间的来源与判定逻辑均有源码支撑setup由load_context与has_code汇总。hasDesign/hasProduct来自上下文加载结果hasCode的实现signals.rs检查package.json是否存在或src/app/pages/site/public/components/lib任一目录是否存在platform由 PRODUCT.md 内容提取extract_platform可能为ios/android/adaptive等。critique读取最近一次 critique 快照跨 target 读取最新快照归一化输出slug、score、p0、p1、timestamp、file。从未评审过则为null——这正是从未被 critique 过的项目默认推荐/impeccable critique surface的信号来源。git通过git_run包装的 git 命令获取仓库状态signals.rs。非仓库时isRepofalse且其余字段为空仓库内会解析分支、比较基准优先 upstream其次develop/main/master等集成分支并产出变更文件列表最多 50 个。devServer并发探测[4321, 3000, 5173, 5174, 8080, 8000, 4200]这 7 个常见开发端口signals.rs任一端口可连接即runningtrue并列出开放的端口。scan按优先级链生成可扫描目标signals.rsgit-changes工作树中可扫描的 markup/style 文件最相关→source-dirsrc/app/components/pages/public→html根目录index.html→root仅当有代码时指向.。决策规则五条核心信号 意图分组兜底routing.md 强调基于信号进行推理没有需要服从的分数。具体规则如下信号条件推荐命令理由setup.hasDesignfalse且setup.hasCodetruedocument项目有代码但缺视觉系统文档捕获视觉系统critique.latestnull且是已 setup 且有真实 surface 的项目critique surface项目从未被评审过这是强默认critique.latest分数低或p0/p1非零polishpolish 会把该快照当作待办清单并在过期或被清空时关闭它git.changedFiles指向单一 surfaceaudit/polish限定到这些文件并点名缩小审查范围到实际改动devServer.runningtruelive浏览器内迭代可用为 false 时不要置顶 live平台边界live 与 detect 仅限 Weblive和内置的impeccable detect仅适用于 Web 项目。若setup.platform是ios、android或adaptive不要置顶这两者——浏览器 overlay 与 HTML 规则引擎对原生应用代码不适用。这是 routing.md 明确划出的红线。意图分组兜底当以上信号都不命中时按用户意图分组给出建议构建新东西Build/ 改进已有内容Refine/ 视觉迭代Enhance/Iterate并贴合当前 surface 与setup.platform定制。融合 detect 扫描用真实、当前的信号替代猜测routing.md 要求当scan.targets非空且setup.platform不是ios/android/adaptive时运行一次.pi/skills/impeccable/scripts/impeccable detect --json scan.targets 以空格连接--json参数在 detect 的 CLI 定义 中有明确声明Output results as JSON用法示例即impeccable detect --json .见 cli.rs。这是内置的本地文件检测器无网络、无 npx直接读取 HTML/CSS因此对原生项目跳过。scan.via告知目标的来历git-changes脏工作树中的 markup/style 文件最相关、source-dir如src、app、html或root。命中结果的折叠方式大量quality / contrast 命中→audit或polish某个具体的slop 家族设计偷懒模式→ 对应命令渐变文字或 eyebrow 眉标 →quieter/typeset扁平或灰扑扑的调色板 →colorize依此类推。detect 是真实、当前的信号胜过猜测。但若 detect 报错或目录树太大扫描缓慢跳过它改为建议用户自己运行audit绝不让 detect 阻塞推荐。菜单兜底SKILL.md 的 Commands 表完整菜单即 SKILL.md 中的 Commands 表按类别分组作为推荐的兜底。推荐置顶后菜单保持可用Build构建shape先规划 UX/UI、init捕获 PRODUCT.md、document从代码生成 DESIGN.md、extract抽取 token 与组件进设计系统Evaluate评估critique启发式 UX 评分、audit可访问性/性能/响应式技术质量检查Refine细化polish发布前最终质量关卡、bolder、quieter、distill、harden、onboardEnhance增强animate、colorize、typeset、layout、delight、overdriveFix修复clarify、adapt、optimizeIterate迭代live浏览器视觉变体模式每个命令都有对应的 reference 文档位于 .pi/skills/impeccable/reference/ 目录下原生的adapt/audit有.native变体。运行机制补充signals 与 detect 如何被调用impeccable signals与impeccable detect都通过.pi/skills/impeccable/scripts/impeccable这个 POSIX shell 启动器调用Windows 下用同目录的impeccable.cmd。启动器impeccable遵循如下解析顺序$IMPECCABLE_BIN环境变量 → 随脚本分发同平台的二进制 →~/.impeccable/bin/impeccable经 engine-probe 握手校验→ 版本固定缓存 → PATH 上的impeccable同样先 probe 校验防止误命中已退役的 3.x npm CLI→ 最后才从发布渠道按版本下载并做 SHA-256 校验。整个过程不需要 Node 或任何其他运行时——这是 routing 流程可以在任意干净环境中稳定执行的前提。交互铁律推荐是 lede菜单是 fallback无论信号如何最终输出都应克制在2-3 个针对性建议给出用户可直接照抄的命令原文每个附一行理由完整菜单始终作为后备展示在下方。推荐是文章的标题lede菜单是兜底——而绝不自动运行命令是贯穿始终的红线Agent 的任务是告诉用户该做什么、为什么执行与否由用户确认。小结一条可复现的路由链路把整条链路串起来就是impeccable contextSetup 判定 NO_PRODUCT_MD 与否→ 有上下文则impeccable signals取回 setup/critique/git/devServer/scan 五组信号 → 按平台与信号折叠出 2-3 个推荐document / critique / polish / 定向 audit / live / detect 融合→ 输出推荐 全量菜单等待用户确认。这条链路完全由 routing.md 定义、由 signals.rs 提供数据、由 detect CLI 提供本地扫描佐证从决策到执行的每个环节都可审计、可复现。【免费下载链接】impeccableThe design language that makes your AI harness better at design.项目地址: https://gitcode.com/GitHub_Trending/im/impeccable创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
