用途
kiro-validate-impl 用于在某个功能的全部任务标记完成后，执行功能级集成验证。单个任务通常在实现过程中已被评审，本技能的目标是发现只有把所有任务放在一起审视时才会暴露的问题，例如跨任务的边界违规、接口不匹配、数据流断裂、需求覆盖缺口以及设计漂移。它不替代 $kiro-impl 期间的任务本地评审，不重新逐个检查每个任务验收标准或每个文件的现实性，除非具体的集成发现要求这样做。其核心问题是：把已完成的任务放在一起看时，它们是否仍遵守设计所规定的边界接缝与依赖方向。
主要能力
技能从对话历史中解析 $kiro-impl <feature> [tasks] 命令，按功能汇总已实现任务；若无历史则扫描 {{KIRO_DIR}}/specs/ 下含已完成任务 [x] 的功能。也支持显式指定功能与任务进行定向验证。
验证维度可并行分派为子代理，每个子代理返回结构化发现摘要，以保持主上下文干净；若不可用多代理，则在主上下文中顺序执行。典型维度包括：测试执行（运行完整测试套件并报告通过/失败）、需求覆盖（建立需求到实现矩阵并报告缺口）、设计对齐（验证架构与 design.md 一致并报告漂移与依赖违规）、跨任务集成（验证数据流、API 契约、共享状态一致性）。
验证分为机械检查与判断检查。机械检查：A. 运行发现到的规范完整测试命令并使用退出码，失败即 NO-GO，无法识别规范测试命令则 MANUAL_VERIFY_REQUIRED；B. 在功能边界内文件中搜索 TBD/TODO/FIXME/HACK/XXX，若由本功能引入则标记为 Warning；C. 搜索硬编码密钥（password、api_key、secret、token 赋值，不区分大小写），若非环境变量引用则标记为 Critical；D. 运行时冒烟启动，运行能证明构建产物确实启动并达到首个可用状态的规范冒烟命令，若启动时出现运行时崩溃、未处理异常、模块加载失败、原生 ABI 不匹配或缺失必需环境/配置则 NO-GO。
判断检查：E. 跨任务集成，识别任务共享的接口、数据模型或 API 契约，验证 Task A 的输出格式匹配 Task B 的期望输入，检查命名约定、错误码、数据形状等假设冲突，验证共享状态一致，并确认集成发生在预期接缝而非把某边界行为泄漏到另一边界；F. 需求覆盖缺口，将 requirements.md 每个章节映射到至少一个已完成任务，识别无单个任务完整覆盖的横切需求，使用原始章节编号而非虚构 REQ-* 别名；G. 设计端到端对齐，验证组件图、集成模式、依赖方向（禁止向上导入）、文件结构计划与实际布局是否匹配，识别架构漂移，使用 design.md 原始编号；G.5 边界审计，对照设计的 Boundary Commitments、Out of Boundary、Allowed Dependencies 与 Revalidation Triggers，识别跨界溢出、为便于集成而嵌入上游的下游变通、未声明的隐藏依赖或共享所有权，并验证已触发的重新验证是否真正执行；H. 检查仍标记 Blocked: 的任务并评估影响，审阅 tasks.md 的 ## Implementation Notes 中的横切洞察。
使用方式
如果未提供参数，解析对话历史中的 $kiro-impl <feature> [tasks] 命令并汇总；若无历史，扫描 {{KIRO_DIR}}/specs/ 中含已完成任务的功能。若提供功能名（$1 存在、$2 为空），使用指定功能并检测其 tasks.md 中所有已完成任务。若功能与任务都提供，则仅验证指定功能与任务。
加载上下文：读取各功能的 spec.json 元数据、requirements.md、design.md、tasks.md（任务列表与实现说明），以及核心引导上下文 product.md、tech.md、structure.md；仅在直接相关时读取额外引导文件。发现规范验证命令时按顺序检查仓库本地事实来源：项目脚本/清单（package.json、pyproject.toml、go.mod、Cargo.toml、应用清单）、任务运行器（Makefile、justfile）、CI/工作流文件、现有 e2e/集成配置，然后 README*，据此推导 TEST_COMMANDS、BUILD_COMMANDS 与 SMOKE_COMMANDS，优先使用仓库自动化已用的命令。SMOKE_COMMANDS 选择最轻量可信的运行时存活检查（如根 URL 加载、Electron 启动、CLI --help、服务健康端点、移动模拟器/e2e 测试台）。
返回 GO 前应用 kiro-verify-completion 协议，证据需包含完整套件、运行时存活、覆盖、集成、设计对齐与阻塞任务状态。具体失败按归属分类：LOCAL（缺陷属于被验证功能）、UPSTREAM（根因属于依赖、基础、共享平台或更早规格）、UNCLEAR（无法从现有证据确定归属）。若归属为 UPSTREAM，不将其并入本功能的本地补救，而是指出所属上游规格并说明哪些依赖规格需在该上游修复后重新验证。
报告与决策
按 spec.json 指定语言输出 Validation Report，字段包括：DECISION（GO | NO-GO | MANUAL_VERIFY_REQUIRED）、MECHANICAL_RESULTS（Tests 的命令与退出码、TBD/TODO 搜索结果、Secrets 搜索结果、Smoke boot 状态）、INTEGRATION（跨任务契约、共享状态一致性、边界审计状态）、COVERAGE（需求映射 X/Y 章节覆盖、覆盖缺口列表）、DESIGN（架构漂移、依赖方向违规、文件结构计划与实际匹配情况）、OWNERSHIP、UPSTREAM_SPEC、BLOCKED_TASKS、REMEDIATION。若 NO-GO，REMEDIATION 为必填，须指出确切问题与所需变更。
约束：严格最终门禁，仅当所有集成检查通过时返回 GO，具体失败返回 NO-GO，无法完成强制验证时返回 MANUAL_VERIFY_REQUIRED；边界完整性优先于便利性，若功能仅靠把职责抹散到各边界才能工作，即使测试通过也不返回 GO。错误场景：未发现实现时报告 "No implementations detected"；测试命令未知时返回 MANUAL_VERIFY_REQUIRED 并说明缺失哪个验证命令，不返回 GO；缺失 spec 文件时停止并报错。后续步骤：GO 表示功能端到端验证通过，可部署或进入下一功能；NO-GO 表示需处理集成问题，重新运行 $kiro-impl <feature> [tasks] 做定向修复，再用 $kiro-validate-impl [feature] 重新验证；会话中断可安全重跑，因为验证是只读且幂等的；MANUAL_VERIFY_REQUIRED 时不得视为功能完成，需提供缺失的确切验证步骤或环境前提。
适用场景与限制
适用于采用规格驱动开发、任务已全部实现并需要功能级集成把关的项目。限制：不替代任务本地评审，不重新逐个核查任务验收标准；依赖仓库中可识别的规范测试与冒烟命令，缺失时只能返回 MANUAL_VERIFY_REQUIRED。具体支持的代理运行环境、安装方式、收费模式、价格与平台信息，资料中暂未提供。