Impeccable 无参数路由基于 signals 与 detect 的上下文感知命令推荐机制【免费下载链接】impeccableThe design language that makes your AI harness better at design.项目地址: https://gitcode.com/GitHub_Trending/im/impeccable当用户只输入/impeccable而不带任何参数时Agent 面对的是一个开放问题我现在应该做什么。Impeccable 的设计答案是不要弹出一成不变的静态菜单而是先把项目的真实状态读出来——impeccable context是否已捕获产品上下文、impeccable signals报告了哪些信号、impeccable detect扫描出哪些质量问题——然后用 23 条指向性极强的命令推荐作为导语把完整命令表作为兜底菜单。本指南完整讲解这份 routing.md 的决策逻辑信号从哪来、每条信号如何映射到具体命令、哪些命令有平台限制、detect 命中结果如何被折叠进推荐以及工作流类问题应如何回答。读完你可以准确复现这套读信号 → 推理 → 给出 2-3 条建议的路由流程也能从源码层面理解 signals 与 detect 的底层实现。何时读取这份文档路由规则由 SKILL.md 的 Routing 一节统一定义routing.md只负责其中无参数这一种情况无参数调用用户输入/impeccable不带命令词读取本指南并给出上下文感知菜单绝不自动运行任何命令推荐只是建议必须由用户确认。显式或明显隐含的命令请求加载对应命令的 reference原生平台加载 native 变体两个命令都匹配时只问一次。工作流或命令选择类问题读取本指南的 Workflow questions 一节。其他情况视为普通设计任务按impeccable context的指示在既有实现上继续。无参数路由的核心原则菜单是兜底推荐是导语routing.md的开篇立场非常明确菜单要上下文感知而不是静态的。用户敲/impeccable想知道的不是你们有哪些命令而是以我当前这个项目、当前这次会话的状态最有价值的一步是什么。因此路由的第一步永远是先搞清楚Setup 有没有跑过Setup 阶段已经运行过impeccable context按 SKILL.md 的 Setup 步骤每会话一次。如果impeccable context报告了NO_PRODUCT_MD说明项目还没有被捕获任何产品上下文菜单应以/impeccable init作为首位推荐附一行理由同时仍然展示其余菜单项——不要静默直接跳进 init 流程init 涉及对用户的采访必须由用户确认。否则运行一次.kiro/skills/impeccable/scripts/impeccable signals读取其 JSON 输出然后以2-3 个最高价值的下一条命令领起每个命令带一行来自信号的推荐理由随后才是完整菜单SKILL.md 中按类别分组的 Commands 表。需要特别强调推荐永远不是执行。routing.md用一句话钉死了这条边界Never auto-run a command; the recommendation is a suggestion the user confirms.绝不自动运行命令推荐是需要用户确认的建议。关于NO_PRODUCT_MD分支的语义可以在源码中看到更完整的实现在 crates/context/src/context_cli.rs 中NO_PRODUCT_MD有两种措辞分支——项目已有既有视觉实现但没有 PRODUCT.md时init/teach/shape或任何新建 surface / 替换视觉世界的请求必须先去读 init.md 完成采访并写 PRODUCT.md而对已有代码的窄范围精修命令则可以不阻塞地继续把init作为后续建议抛出。signals路由推理的事实来源impeccable signals别名context-signals的输出是整个路由决策的核心输入。它的 Rust 实现位于 crates/context/src/signals.rsgather_signals()一次性聚合五大组信号输出为一个 JSON 对象信号组字段内容与来源setuphasProduct/productPath/hasDesign/designPath/hasCode/platform由load_context读取 PRODUCT.md、DESIGN.md 的解析结果platform从 PRODUCT.md 的## Platform提取web/ios/android/adaptivecritiquelatest含slug/score/p0/p1/timestamp/file读取.impeccable/critique/下最近一次 critique 快照没有则为nullgitisRepo/branch/base/changedFiles/changedCount通过git diff、git status --porcelain等获取工作区变更devServerrunning/ports探测常见开发端口连通性scantargets/via由 git 变更文件与源码目录推断出的可扫描目标setup产品上下文是否就位hasDesign为false而hasCode为true表示项目有代码但视觉系统从未被记录——这是 document 的典型触发场景从代码生成 DESIGN.md捕获当前的视觉设计系统。这一推理的直接来源就是 signals 里setup.hasDesign与setup.hasCode两个布尔值的组合。critique历史上是否被评审过、评审结果如何critique.latest是路由中最有信息量的信号之一其字段由 crates/context/src/signals.rs 从最近一次 critique 快照中归一化而来critique.latest为null→ 项目从未被评审过。对一个已 setup、且有真实 surface 的项目推荐/impeccable critique surface是一个强默认项。critique.latest存在但score低或p0/p1非零 → 推荐 polish。polish 会把那份 critique 快照当作自己的积压工作backlog来读取并且在快照过期或被清除时关闭它快照的关闭机制见 crates/context/src/critique_storage.rscritique-storage latest/close子命令。源码细节值得注意score会优先取total_scorep0/p1会优先取p0_count/p1_count新旧快照字段名的兼容性处理说明这套路由逻辑可以同时消费不同版本 critique 快照的输出。git变更文件指向作用域git.changedFiles指向单一 surface 时路由应把 audit 或polish的作用域收窄到这些具体文件并点名它们。git 信号的实现在 crates/context/src/signals.rs非 git 仓库直接返回空在分支上会尝试解析 baseupstream、develop、main/master、远端 HEAD再以git diff base...HEAD --name-only结合git status --porcelain生成变更清单最多 50 个文件。devServerlive 模式的可用性前置条件devServer.running为true时live浏览器内可视化变体迭代才可用为false就不要以live领起推荐。探测实现在dev_server_signals()signals.rs对[4321, 3000, 5173, 5174, 8080, 8000, 4200]这组常见开发端口逐一做 250ms 超时的 TCP 连接探测返回所有处于监听状态的端口。信号到命令的推理规则routing.md明确说明Reason over the signals; there is no score to obey——信号推理是规则驱动的不存在一个需要服膺的数值评分。核心规则如下信号条件推荐动作依据setup.hasDesign false 且setup.hasCode true/impeccable document捕获现有视觉系统critique.latest为null/impeccable critique surface从未评审过的已 setup 项目评审是强默认critique.latest的score低或p0/p1非零/impeccable polish把快照当 backlog 读取过期即关闭git.changedFiles指向单一 surface将audit或polish收窄到这些文件并点名作用域更精准devServer.running truelive可用于浏览器内迭代live 需要运行中的 dev server其他情况按意图分组新建 / 改进已有 / 视觉迭代贴合当前 surface 与setup.platform兜底推理最后一条否则分支意味着推理要落在用户意图分组上build newshape、craft、init、improve whats therecritique、audit、polish、extract、iterate visuallylive——具体命令清单可参考 SKILL.md 的 Commands 表Build / Evaluate / Refine / Enhance / Fix / Iterate 六类共二十余个命令以及 command-metadata.json 中各命令的触发语境描述。平台约束live 与 detect 仅限 Webrouting.md划出了一条硬边界live和内置的impeccable detect是 Web 专属。如果setup.platform是ios、android或adaptive两者都不应以领起项出现——浏览器 overlay 与 HTML 规则引擎对原生应用代码不适用。原生平台的设计工作应转向各自的 referenceios.md、android.mdadapt.native、audit.native也是同理见 SKILL.md 命令表中的 native 变体链接。detect 增强比猜测更真实的即时信号这是routing.md中操作感最强的一步。当scan.targets非空且setup.platform不是ios/android/adaptive时运行一次.kiro/skills/impeccable/scripts/impeccable detect --json scan.targets 以空格连接要点无需网络、无需 npx这是内置的本地检测器detector直接读 HTML/CSS 等文件因此对原生项目直接跳过。scan.via说明目标是什么git-changes脏工作区中的 markup/style 文件——最相关的目标集source-dir例如src、apphtml入口index.htmlroot整个项目根。把命中结果折叠进推荐大量 quality / contrast 命中 →audit或polish某个具体的 slop 家族 → 对应命令渐变文字或 eyebrow → quieter / typeset扁平或灰色调色板 → colorize依此类推。Its a real, current signal that beats guessing.这是真实的、即时的信号胜过猜测。失败不阻塞detect 出错或项目树过大过慢时跳过它改为建议用户自行运行audit绝不让 detect 阻塞整个推荐。scan.targets的来源逻辑在 signals.rs 的scan_targets()中实现决策优先级与scan.via一一对应git 仓库且有变更文件时过滤出可扫描扩展名.html、.htm、.css、.scss、.jsx、.tsx、.js、.ts、.vue、.svelte、.astro且非 vendored 路径node_modules、dist、build、隐藏目录等的文件取前 50 个 →via: git-changes否则取存在的源码目录src、app、components、pages、public→via: source-dir否则若存在index.html→via: html否则只要有代码迹象 → 目标为.→via: root都没有则targets为空、via为null。detect 命令本身在 crates/detect/src/cli.rs 中定义了完整参数面路由推荐时值得记住几个关键选项--json结构化输出路由脚本正是用它解析命中结果--scope name仅报告指定设计域如type、layout的规则逗号分隔--viewport WxHURL 扫描的浏览器视口默认1280x800例如--viewport 390x844做移动宽度扫描--no-config/--no-inline-ignores/--no-design-system分别跳过项目配置、行内 ignore 注释、DESIGN.md 设计系统上下文--no-advisory隐藏 advisory 类发现如 em-dash 滥用——advisory 不计入失败、不改变退出码。退出码约定0 无 primary 发现1 有目标无法扫描2 存在 primary 发现可用于在路由流程中快速判断是否有值得折叠进推荐的质量问题。输出格式2-3 条指向性建议 完整菜单兜底路由的最终产出形态是导语lede2-3 条指向性推荐每条给出可直接输入的确切命令和一行理由——理由必须来自信号或 detect 命中而不是泛泛而谈兜底菜单完整菜单SKILL.md 中按类别分组的 Commands 表保持可用推荐只是开场白。Keep it to 2-3 pointed picks with the exact command to type. The menu stays the fallback; the recommendation is the lede.——控制在 2-3 条指向性推荐并给出确切命令菜单保持兜底推荐是导语。Workflow questions工作流问题只建议不执行routing.md的第一节处理的是另一类请求用户问的是工作流问题我应该用什么命令做 X、audit 和 critique 的区别是什么。此时给出建议不执行命令——下方菜单只用于裸命令调用bare invocations按需查阅相关命令的 reference确认前置条件与作用域更全面的工作流指南由官方文档承担这里只需正确路由如果用户同时要求执行则遵循执行请求。也就是说只动嘴与动手是两种明确区分的情境routing 只在用户明确要求执行时才落到执行。小结一条可复现的路由链把整份routing.md压缩成一条可复现的决策链Setup 已跑过impeccable context输出含NO_PRODUCT_MD→ 以init为首位推荐附一行理由不静默执行运行.kiro/skills/impeccable/scripts/impeccable signals读 JSON非原生平台且scan.targets非空 → 运行.kiro/skills/impeccable/scripts/impeccable detect --json targets把命中折叠进推荐按上文的信号 → 命令规则表推理出 2-3 条最高价值推荐每条带确切命令与一行理由live/detect仅在 Web 平台领起ios/android/adaptive走原生 reference完整菜单兜底推荐等待用户确认——绝不自动执行。整条链路的每个事实输入setup、critique、git、devServer、scan都能在 signals.rs 的gather_signals()中找到一一对应的生成实现而 detect 命中的折叠则建立在 detect/src/cli.rs 的参数与退出码语义之上——这也正是上下文感知四个字在工程上的落点不是模板文案而是对项目真实状态的即时读取与推理。【免费下载链接】impeccableThe design language that makes your AI harness better at design.项目地址: https://gitcode.com/GitHub_Trending/im/impeccable创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考