用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
直接命令不会经过审查 Prompt；运行前请先检查来源。
npx skills add https://github.com/XS-MLVP/UCAgent --skill test-case-implementation-in-batch命令会保持在同一行。复制前请横向滚动并检查完整内容。
想先保存到本地？可下载 SkillsMP 当前能够提供的文件。
UCAgent是基于大语言模型的自动化任务执行AI代理，支持通用工作流配置和执行。本技能提供配置文件编写规范、自定义Checker开发指南、--emulate-config配置校验工具使用方法，帮助用户快速创建、验证和运行各类任务工作流。
为正确失败测试确认的动态DUT Bug优先确定性维护BG、TC、ROOT和波形引用；支持幂等重复调用、受控格式恢复与跨阶段累计。
验证静态Bug候选并维护其与已完成动态Bug或BG-NA的LINK-BUG关联。
正在显示 SKILL.md
| name | test-case-implementation-in-batch |
| description | 分批测试用例实现与对应Bug分析阶段专属技能，用于依据测试模板注释、功能规格CK原文和覆盖约束实现针对性激励与断言，并完成测试执行、动态Bug分析和报告记录 |
Markdown 排版契约：本技能生成、维护或展示的任何 Markdown 中，每个 # 到 ###### 标题前后各保留一个空行；标题前置空行没有例外：文件开头的标题、Markdown 示例围栏内首个标题和 <a id="..."></a> 锚点后的目标标题都必须有前置空行。标题前不得直接连接正文、列表、表格、下一级标题、代码围栏或锚点；字段标题后的规范机器标记（例如 <BUG-*>、<ROOT-*> 和 <RELATED-BUGS>）可以继续与标题紧邻。
以当前批次已经生成的测试模板签名为准。实现测试逻辑时必须原样保留fixture参数及顺序，不得自行增加、删除、交换参数，也不得用dut或mock_dut替换env。
命名也是跨阶段契约：普通定向TC继续使用test_<scenario>，但不得以保留的test_api_、test_static_或test_random_开头；API、静态Bug和随机TC只能在各自专用文件中使用对应完整前缀。不要通过改名到其他阶段、移动文件或添加skip绕过命名检查。
动态 Bug 的唯一目标文件是{OUT}/{DUT}_bug_analysis.md，不得从可见标题派生另一个文件名。Markdown、record/Apply和中央YAML test_case使用函数级报告node（只删除源码行范围）。非参数化WaveInfo使用同一node；若报告含tests.test_case_instances，文档TC保持函数级node，WaveInfo选择一个实际FAILED参数化child，Apply验证其完整路径/类/函数父节点并在YAML executed_test_case记录该child。当前批次没有确认任何动态 Bug 时，保留唯一目标文件和三个空容器。
| 测试类别 | 参数契约 |
|---|---|
| 普通DUT测试 | 保留模板已有的def test_xxx(env):或def test_xxx(env, ref_model): |
| Mock组件独立测试 | def test_api_{DUT}_mock_xxx(mock_dut): |
ref_model时，必须保留为第二个参数并用于依据规格独立计算预期；不能读取DUT实际输出后返回同值，也不能为了匹配DUT而复制可疑RTL逻辑。env使用已集成的验证环境和外部组件。当前技能不实现test_api_{DUT}_mock_*测试，也不能把env改成mock_dut。env后重跑；不能作为DUT Bug保留Fail。{OUT}/tests/{DUT}_api.py和{OUT}/tests/{DUT}_function_coverage_def.py是当前批次的稳定输入，默认只编辑当前测试文件。不得为绕过setup、fake DUT、mark_function或覆盖率错误而重写API模板、替换fixture、伪造fc_cover、删除覆盖标记或改变coverage上报。接收当前批次测试用例后,按照以下步骤完成当前批次测试用例的实现与 Bug 分析任务：
对当前批次的每个测试用例依次完成：
TASK/TODO、已有mark_function和覆盖约束。这些内容定义模板的原始测试意图，不能跳过或只按文件名、函数名猜测。mark_function确定完整FG/FC/CK路径，在{OUT}/{DUT}_functions_and_checks.md中定位并阅读对应CK原文，提炼触发前提、输入组合、状态/时序、边界/异常行为和预期输出。{OUT}/tests/{DUT}_function_coverage_def.py中的对应检测点约束，将CK原文、模板意图和覆盖约束共同作为测试契约。注意:
lambda表达式,则测试激励必须满足该lambda表达式操作: 将测试激励实现为可执行代码,并添加断言检查输出是否符合预期,并将可执行代码填充到对应测试用例的空模板中
注意:
assert语句去判断输入端约束条件是否满足,直接通过充分的分析与设计测试激励的方式来确保输入端约束条件被满足assert actual == expected, error_msg）mark_function而没有实际验证CK行为mark_function本身不等于完成CK验证WaveInfo构建精确pattern；增加日志不能新增Step、改变callback顺序或改变测试时序Step顺序，确认输入在哪个边沿驱动、请求何时被DUT接受、输出何时有效。ready/valid只是常见形式，也可能是req/ack、enable、start/busy、固定延迟或其他自定义协议，不能按信号名称猜测Step(1)只推进仿真，不自动表示请求已接受或结果已有效。必须确认API内部是否已经执行Step/等待握手，并依据规格选择组合settle、指定采样边沿、固定N周期、out_valid/done/ack成立或busy清零等真实采样条件；禁止API调用后机械地只Step一次就读取结果并判错操作: 实现当前批次的所有测试用例后，用RunTestCases('{TEST_BATCH_RUN_ARGS}')执行测试(TEST_BATCH_RUN_ARGS的具体信息在阶段任务描述部分中)
注意:
操作: 只分析当前批次待实现TC及当前报告为这些TC关联的CK。报告中属于未来未实现批次、且未与当前TC关联的失败CK，不得在本批次为其创建无关TC/BG或追逐覆盖；留到所属批次驱动和分类。最终综合与Bug记录阶段仍必须满足全部失败CK的单向门禁。
对每个当前批次FAILED TC执行同一强制分类，不预设责任方：
specification_expected。不得直接相信模板注释、已有断言、静态Bug候选或可疑RTL。
输入经过取反、编码、掩码、分包或carry/borrow变换时，必须从实际驱动值和规格运算重新计算expected，不能使用变换前操作数的expected；a+(~b)+0是a-b-1，实现a-b需要a+(~b)+1。input | specification_expected | test_expected | actual | classification。若specification_expected != test_expected，立即修正测试并重跑到PASSED；禁止调用WaveInfo、创建/更新非零BG或引用静态候选。Step、采样边沿、有效条件和响应延迟，再核对fixture、参考模型、复位与环境。CovGroup.sample()是否执行以及采样时机是否正确。CK predicate或sample错误属于验证问题，必须修复并重跑，不能记录为DUT Bug。actual仍违反规格时，分类才是DUT Bug；此时才允许进入WaveInfo和非零BG流程，并保留正确断言自然触发的FAILED。其他分类全部修复并重跑到PASSED。TC与CK状态按以下规则解释：
FAILED TC关联的CK可以是PASSED：TC可能用断言发现DUT Bug，同时已经成功触发CK。不能由TC Fail反推CK Fail，也不要求每个Fail TC关联失败CK。FAILED CK适用独立的单向门禁：阶段结束时，它必须有当前报告关联到同一精确FG/FC/CK的正确Fail TC，并在该CK下完成非零BG/TC记录；但必须先排除CK predicate、coverage/check function和sample问题。PASSED TC与FAILED CK不是DUT Bug证据。先修正覆盖关联、predicate、sample时机或缺失的针对性驱动；禁止制造Fail。PASSED关联用例使其FAILED。正确修复predicate、覆盖关联、sample或驱动后CK可以变为PASSED，此时该CK不再需要Fail复现用例。PASSED只表示本次测试和覆盖结果正常，不证明其他行为没有缺陷。以下述结构生成测试用例的 Bug 骨架:
BG: 仅用于已动态复现的DUT设计Bug，格式为BG-NAME-NUM，NUM为1到100的置信度。示例：BG-CIN-OVERFLOW-98；BG-*-0不能解释失败用例TC: 测试用例标签。逐字复制本次报告 node ID，只删除:start-end或:line，再加TC-；示例中的目录不构成规范BD: DUT Bug的简要描述注意:
create_test_case_templates阶段生成空模板时必须使用assert False, "Not implemented"；当前实现阶段必须删除该占位断言，换成真实激励和严格预期检查assert False制造Fail，禁止修改正确预期或弱化断言来制造Pass，也禁止用BG-*-0保留测试/基础设施失败RunTestCases可能执行很多测试用例，但当前步骤只针对当前批次TC及报告为这些TC关联的CK进行分析；未来批次的未关联失败CK不得扩张本批次范围dynamic-bug-recording可用时，record_dynamic_bug.py通过-MODE bug确定性写入一个完整FG/FC/CK/BG/TC路径、三个BG字段、唯一<CAUSE-REF-ROOT-XXX>和ROOT反向链接，再通过-MODE root写入ROOT五字段；它不创建波形YAML，脚本成功后仍需真实WaveInfo和Apply证据。公共Skill不调用SetSkillUsage；Skill禁用、未复制或脚本不可用时使用文本工具完成相同结构WaveInfo取得最终receipt，再调用ApplyWaveInfoEvidence原子维护BG侧<WAVEFORM-REF>和中央<WAVEFORM-EVIDENCE>分区中的唯一<WAVEFORM-TC-...>记录。不要复制receipt字段或viewer token；BG内的波形关联只保留TC与引用，三个BG字段仍需填写，YAML和viewer只放在中央记录中Configured TC output directory读取实际TC目录；文档TC使用以该值开头的函数级报告node。非参数化WaveInfo只去掉TC-；参数化聚合时从tests.test_case_instances选择实际FAILED child，不能猜参数ID。child删除[...]后必须与文档TC的完整路径/类/函数逐字相同，不同路径绝不等价。RunTestCases target相对于配置TC目录，不得再次带该前缀；PYTEST_TARGET_DIRECTORY_PREFIX.correct_target是唯一重试值。inventory和相似节点只供定位/核对logged_cycle+clock_signal或完整start_step+end_step的调用属于探索调用；返回evidence_window_required时必须逐字使用recommended_evidence_call重调，不能把analysis_window.effective_*手工写入文档冒充原调用参数start_step和end_step。成功后使用真实receipt_id调用ApplyWaveInfoEvidence(target_file=..., bug_tag=..., test_case_tag=..., receipt_id=...)。随后完成TC共享的alignment_evidence，并在bug_evidence.<BG>下完成该Bug的required_signals、observed_behavior、source_correlationbug_tags和必须精确覆盖所有引用它的BGSkill启用且公共dynamic-bug-recording可用时，尽可能不直接编辑{OUT}/{DUT}_bug_analysis.md。参照Guide_Doc/dut_bug_analysis.md section 5.1确认字段语义，并优先通过RunSkillScript按以下顺序完成记录：对每个新BG路径的第一份精确FG/FC/CK/BG/TC关联调用-MODE bug一次，再对每个不同ROOT调用-MODE root一次；已有CK/BG仅新增兄弟TC时直接调用WaveInfo/Apply。BG机器锚点、ROOT容器、关闭标记或双向关系异常时调用一次-MODE repair重建全部生成式锚点和关系，不得按Checker逐条编辑缺失锚点；执行返回的next_action后若相同文档格式阻塞仍存在，才按error/details或返回的manual_edit_fallback最小编辑，并立即重跑-MODE repair和Check。公共Skill不调用SetSkillUsage。下方所有值必须替换为当前报告、功能检查文档、测试docstring和真实分析结论；不能传Markdown标题、机器标签、ROOT引用或代码围栏作为字段正文：
["unitytest/dynamic-bug-recording", "record_dynamic_bug.py", "-MODE bug -BG 'BG-CIN-OVERFLOW-98' -TC 'TC-{OUT}/tests/test_{DUT}_carry.py::test_carry' -BD '进位结果丢失' -CHECKPOINT 'FG-ARITHMETIC/FC-ADD/CK-CARRY' -ROOT-TAG 'ROOT-ADDER-CARRY-WIDTH' -ROOT-TITLE '加法进位位宽不足' -OVERVIEW '规格要求完整保留加法进位，实际结果在输出前被截断。' -SYMPTOMS '最大操作数组合稳定返回缺少最高进位位的错误结果。' -TRIGGER '两个操作数之和超出结果低位宽度时稳定触发。'"]
随后为每个不同ROOT调用：
["unitytest/dynamic-bug-recording", "record_dynamic_bug.py", "-MODE root -ROOT-TAG 'ROOT-ADDER-CARRY-WIDTH' -ROOT-TITLE '加法进位位宽不足' -ANALYSIS '中间结果在输出前按低位宽度截断，最高进位位因此丢失。' -SOURCE-LOCATION 'rtl/adder.sv:24-28' -FIRST-ERROR-LINE 25 -FIRST-ERROR-NOTE '首次丢失最高进位位。' -PROPAGATION-LINE 26 -PROPAGATION-NOTE '截断值进入结果赋值路径。' -OBSERVABLE-LINE 27 -OBSERVABLE-NOTE '错误结果到达测试断言。' -CAUSAL-CHAIN '合法输入被接受后，位宽不足先截断进位，截断值再传到结果输出。' -FIX '扩大中间结果与输出路径宽度并保留进位位。' -RETEST '重跑关联CK和边界用例并复核签名波形。'"]
没有可访问源码时，改用互斥的-SOURCE-UNAVAILABLE，不要传任何源码行参数。重复调用或跨stage追加、修订时重调对应MODE即可；脚本会幂等更新，不会删除历史TC/BG/ROOT。Skill禁用、未复制或脚本不可用时，才按Guide_Doc/dut_bug_analysis.md section 5.1使用文本工具完成相同结构。
骨架建立后，必须继续完成以下工作，不能结束当前任务：
input | specification_expected | test_expected | actual | classification，确认分类为DUT Bug；再读取事务上下文和对应CK原文，并阅读测试使用的API/driver、callback与Step顺序，确认真实驱动边沿、接受条件和输出采样窗口。分类记录缺失或任一验证项仍有疑问时停止Bug记录，返回步骤4，禁止调用WaveInfo。WaveInfo取得最终confirmed证据；signal_groups覆盖该TC关联的全部Bug所需信号并集。随后调用ApplyWaveInfoEvidence，由工具创建缺失的兄弟TC、引用和中央记录，不得手工创建另一套BG层级；同名BG跨CK时必须传精确checkpoint_path="FG-.../FC-.../CK-..."。打开viewer确认签名信号集合均已显示。目标TC已有不同真实receipt时显式传replace_existing=true，再重新完成被重置的语义结论。source_correlation。-MODE bug和-MODE root重调脚本替换字段正文；只有上述同一格式阻塞仍存在时，才用EditTextFile或ReplaceStringInFile做诊断限定的最小编辑。Skill禁用时直接使用文本工具。两条路径都必须完成Bug概述、现象与等级、触发条件与影响范围、根因分析、源码证据与逐行分析、动态因果链、修复建议、风险与复验计划，并清除全部<BUG-TODO>。<ROOT-SOURCE-EVIDENCE>中写不带L的真实path:起始行-结束行和完整HDL fenced代码块；<ROOT-SOURCE-FIRST-ERROR>、<ROOT-SOURCE-PROPAGATION>、<ROOT-SOURCE-OBSERVABLE>各出现一次并位于代码注释中。无源码时使用<ROOT-SOURCE-UNAVAILABLE>完成黑盒分析，两种分支互斥。WaveInfo 收据陈旧、缺失或无法重放时先调用 Check。严格重放会自动原子刷新精确 TC、timeline、信号值、窗口、候选、信号集合和测试/driver/HDL 源码上下文均等价的机器字段；若返回[Waveform Semantic Batch Review Required]，原样执行review_batch_call取得全部当前签名上下文，统一阅读changed_source_files后为全部items补齐review，再由ReviewWaveInfoEvidenceBatch一次原子提交，最后只运行一次Check；不要逐TC调用Apply或重复运行pytest/WaveInfo/Check。只有当前重放失败、波形缺失或精确 TC 身份变化时，才按诊断重跑/修复测试并重新调用 WaveInfo；相似路径和参数化候选只作提示。只要正确实现的测试仍 Fail，禁止删除 <TC-*>、<BG-*> 或整个 FG/FC/CK 分支来绕过验收。
动态条目容器使用独立行<DYNAMIC-BUGS>定位。每个BG只包含全部TC/引用、<BUG-OVERVIEW>、<BUG-SYMPTOMS>、<BUG-TRIGGER>和TRIGGER末尾的唯一<CAUSE-REF-ROOT-XXX>。每个ROOT使用唯一<ROOT-XXX>并依次包含<ROOT-CAUSE-ANALYSIS>、<ROOT-SOURCE-EVIDENCE>、<ROOT-CAUSAL-CHAIN>、<ROOT-FIX>、<ROOT-RETEST>、<RELATED-BUGS>。ROOT反向项内嵌完整BG路径；中央波形仍按TC唯一。
Skill启用时脚本优先生成并维护结构和字段，LLM只提供经过核对的参数正文；确定性恢复后相同格式阻塞仍存在时允许最小文本修复。Skill禁用时由LLM使用文本工具完成相同结构。根因、源码、因果链、修复和复验只在ROOT写一次，并用双向可点击链接关联一个或多个BG；BG只保留现象和触发作用域。
操作：完成当前批次的测试用例后，使用Check工具进行阶段检查.若未通过检查,则基于反馈信息修正测试用例后,直到阶段检查通过为止;若通过检查,则执行下一批次的测试用例实现,或者是使用Complete工具进入下一阶段
每次失败只把当前反馈中的第一个阻塞项作为修复目标，执行其明确next_action后立即复查，不同时猜测或修复未报告的问题。若当前错误只是确定的格式替换，不重跑WaveInfo、不重建BG/TC，也不重新分类Bug。
RunSkillScript工具时,若有10条命令要执行,前5条命令行执行正常,成功记录,但第6条命令执行失败时,根据反馈信息修改第6条命令以及后续命令中存在的相同问题,并且使用RunSkillScript工具重新执行第6条命令以及后续命令,已经成功的命令不需要重新执行,只需要执行未完成的命令,直至所有命令执行完毕unitytest/dynamic-bug-recording可用时，优先用record_dynamic_bug.py的-MODE bug和-MODE root完成每个新CK-scoped BG路径及ROOT字段；BG机器锚点或关系异常由一次-MODE repair全量重建，禁止逐个手工补锚点。执行一次Skill恢复后相同文档格式阻塞仍存在时，才按诊断范围最小编辑并立即重跑-MODE repair和Check。共享技能未复制、Skill整体禁用或脚本不可用时，使用文本编辑工具按Guide_Doc/dut_bug_analysis.md中的第 5.1 节完整标准案例建立相同中文路径。同一CK/BG内的后续兄弟TC、引用和中央记录由ApplyWaveInfoEvidence维护；同名BG跨CK时传checkpoint_path选择精确路径。随后完成共享alignment_evidence和逐Bug语义字段。不得跳过任何字段。def check_norm_bit24(x):
if x.op.value != 0:
return False
# 排除特殊值
if is_nan(x.a.value) or is_nan(x.b.value) or is_inf(x.a.value) or is_inf(x.b.value):
return False
# 检测同号相加产生进位的场景
# 条件：同号、正数（非零）、指数相同、尾数之和会产生进位到第24位
a_sign = get_sign(x.a.value)
b_sign = get_sign(x.b.value)
if a_sign != b_sign:
return False
if is_zero(x.a.value) or is_zero(x.b.value):
return False
exp_a = (x.a.value >> 23) & 0xFF
exp_b = (x.b.value >> 23) & 0xFF
if exp_a != exp_b:
return False
# 当两个尾数都>=0.5时，相加可能产生进位
mant_a = x.a.value & 0x7FFFFF
mant_b = x.b.value & 0x7FFFFF
return mant_a >= 0x400000 and mant_b >= 0x400000
对于上述check_函数,测试激励必须满足以下约束条件:
若是lambda表达式,例如:
lambda x: x.a.value == 0x7F800000
这表示测试激励必须满足 x.a.value == 0x7F800000 的条件,即 a 是正无穷的场景
bug_evidencesignal_groups必须暴露所有Bug所需信号的并集；新增Bug需要扩展信号时重新取得最终receipt，并传replace_existing=true。替换receipt会保留各Bug的required_signals，重置共享对齐结论和逐Bug语义结论signal_groups：时序DUT列出实际时钟，组合DUT声明combinational且不虚构时钟；同时列出当前功能相关输入数据/选择/使能、相关输出数据/状态/有效位、接口真实的请求接受与响应有效控制，以及至少一个能解释功能选择、状态或错误传播的关键外部/内部信号。所有路径必须来自signal_catalog，并由同一receipt签名后进入timeline和viewer；禁止只查看目标result就判Bugpattern只用于定位真实失败事件，signal_groups用于加载必要上下文；不要为了让viewer出现信号而把所有上下文都设成change。protocol只有在规格与接口确认不存在ready/valid/enable/start/busy/done/ack等控制时才可为空，不能根据控制信号名称猜测协议语义status: unavailable不能完成阶段WaveInfo匹配到事件只说明该波形片段可重放，不会自动判定Bug。LLM必须结合规格和测试驱动方式审查真实接受条件、backpressure/stall、pipeline或响应latency、事务ID/顺序以及输出有效窗口；pattern和timeline应包含ready/valid或DUT实际使用的等价协议锚点valid/enable=0、ready/accept=0、复位/空闲/过渡周期、尚未达到响应latency或协议声明data无效时看到的单点data mismatch只能作为调查线索，不能直接生成BG。若规格明确要求busy期间忽略请求或保持某值，则应引用该约束判断，而不是机械套用握手规则<BG-STATIC-*>只允许写在{DUT}_static_bug_analysis.md；一旦测试动态证实，必须在{DUT}_bug_analysis.md新建独立<BG-NAME-xx>并提供confirmed波形证据，再从静态文档用<LINK-BUG-*>关联WaveInfo返回的测试名称、最新session、.dat、SetWaveform、dut.Finish和文件损坏诊断逐项处理；不能改用旧session或其他测试的波形WaveInfo receipt；当前批次只运行部分用例时，不得删除历史TC/BG、手工改写有效receipt或重造viewer链接。最终记录阶段必须运行完整测试集合并严格重放全部动态Bug TC；Checker会一次原子刷新语义指纹不变的当前机器证据，语义变化时一次返回完整review_batch_call，由ReviewWaveInfoEvidenceBatch准备并原子提交全部复核项，不得逐TC调用Apply或重复运行pytest/WaveInfo/Check；TC身份变化或当前波形缺失才按精确恢复动作处理bug_document_viewer_link必须由ApplyWaveInfoEvidence直接写入；不得让LLM复制或修改标记、URL和tokenreceipt_test_mismatch或matching_final_receipt_not_found时，保持test_case_tag不变并原样执行details.recovery_call一次，再用新receipt_id和原标签重调Apply；不得猜测路径变体或手工写receipt YAML、anchor、viewer URL/token。同一tool+status+target连续同错后停止尝试相似参数；没有recovery_call或执行后仍同错时，停止修改当前Bug/波形记录并报告工具契约阻塞