菜单
Use when testing skill loading effectiveness, verifying subagent compliance with skill requirements, or conducting batch skill validation tests. Triggers when you need to validate that skills load correctly across multiple test cases.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Generate repository-ready ring bus topology Python and test driver files from a markdown architecture description, then optionally run the generated test script to produce build_logic RTL output and execute rtl_qc VCS compilation. Use when the user provides a .md ring bus architecture, wants MemTopo.py plus test_xxx.py, asks for markdown to rtl generation, ring_for_pd style topology generation, or wants an end-to-end markdown to build_logic to VCS flow.
Use when processing RTL modules at the microarchitecture level - including FIFO, state machines, counters, arbiters, decoders, or any Verilog/SystemVerilog hardware design. Load this skill immediately upon identifying RTL design tasks, before diving into brainstorming，planning or implementation.
verification_workflow 流水线的第 8 步。读取第 4 步输出的 verification-sim-tc-defines.md 中每条 TC 的 Checker 字段，编写两类检查代码：（1）在接口文件中实现 SVA assert property 捕获时序不变式；（2）若 tb-arch 规划了 Scoreboard，实现 Scoreboard 的数据比对逻辑。若存在 UVM/TB coding style 相关 skill，在开始编码前必须先加载。输出为接口文件中的 SVA 属性块 + tb/env/<dut>_scoreboard.sv。触发条件：由 verification_workflow 在第 8 步调用，或用户直接需要为已定义的 TC Checker 生成断言或 Scoreboard 代码时触发。
verification_workflow 流水线的第 7 步。读取第 4 步输出的 verification-sim-tc-defines.md 中每条 TC 的 Coverage 字段，结合第 5 步输出的 verification-tb-arch.md 中的 Monitor/Subscriber 分配，为每条 TC 编写 UVM 功能覆盖率代码（covergroup / coverpoint / bins）。若存在 UVM/TB coding style 相关 skill，在开始编码前必须先加载。输出为 tb/env/<dut>_func_cov.sv 覆盖率收集器文件。触发条件：由 verification_workflow 在第 7 步调用，或用户直接需要为已定义的 TC Coverage 生成功能覆盖率代码时触发。
verification_workflow 流水线的第 6 步。读取第 4 步输出的 verification-sim-tc-defines.md 中每条 TC 的 Stim 字段，结合第 5 步输出的 verification-tb-arch.md 中的 Agent/Sequencer 分配，为每条 TC 编写 UVM Sequence 激励代码。若存在 UVM/TB coding style 相关 skill，在开始编码前必须先加载。输出为 tb/sequences/ 目录下每条 TC 对应的 .sv 激励序列文件。触发条件：由 verification_workflow 在第 6 步调用，或用户直接需要为已定义的 TC Stim 生成 UVM Sequence 代码时触发。
verification_workflow 流水线的第 5 步。读取第 4 步输出的 verification-sim-tc-defines.md，分析所有测试用例三元组的 Stim/Coverage/Checker 需求，决策如何构建基于 UVM 的 Testbench 架构——包括需要哪些组件、组件间的连接关系、哪些组件可复用已有 VIP、哪些组件需要自行开发。输出为 verification-tb-arch.md，包含完整的 TB 组件清单、层次结构图、接口/VIP 决策以及开发任务分配。触发条件：由 verification_workflow 在第 5 步调用，或用户直接需要为一批 SIM 测试用例规划 UVM TB 架构时触发。
| name | dev-skill-load-test |
| description | Use when testing skill loading effectiveness, verifying subagent compliance with skill requirements, or conducting batch skill validation tests. Triggers when you need to validate that skills load correctly across multiple test cases. |
Batch-test whether a target skill is actually loaded by subagents under realistic task prompts.
Core insight: Subagents often load a skill without explicitly saying so. If AGENTS.md enforces skill call logs, read the log directly from the task output. Otherwise, resume the session and ask.
Cost insight: Each subagent session that runs to completion (full design, full implementation) wastes tokens and time. The test only needs the agent to reach the skill-loading decision point — not to finish the task.
digraph {
rankdir=TB;
node [shape=box];
prerequisite [label="0. Prerequisite check"];
design [label="1. Design test matrix"];
baseline [label="2. Baseline run (A)"];
experiment [label="3. Experiment run (B)"];
probe [label="4. Probe every session"];
compare [label="5. Compare A vs B"];
report [label="6. Write report"];
prerequisite -> design -> baseline -> experiment -> probe -> compare -> report;
}
Before any test, verify the target skill is visible to the system:
Ask a subagent: "List every skill name you can see in available_skills."
If the skill is missing, stop — no amount of testing will work. New skills require a session restart to appear in available_skills.
Pick N task prompts (recommend N >= 10) that should trigger the target skill.
Guidelines:
expected_skills: the skill name(s) the agent should load for each prompt.Early-stop constraint
The skill-loading decision happens in the first 1-2 replies (brainstorming phase). Everything after that (design, implementation, verification) is irrelevant to the test and wastes tokens. Append a stopping condition to every prompt:
在提出第一个澄清问题后停下来，等待用户回复。不要继续执行后续步骤。
Or in English:
Stop after asking your first clarifying question. Do not proceed further until the user replies.
This ensures the agent loads all relevant skills (which happens before or during the first reply), then halts — giving you a clean observable result without running the full task.
Example (target skill = rtl-coding-style):
| # | prompt | expected_skills |
|---|---|---|
| 1 | "Design a sync FIFO. Stop after asking your first clarifying question." | rtl-coding-style, design-microarch |
| 2 | "Design an edge detector. Stop after asking your first clarifying question." | rtl-coding-style, design-microarch |
| … | … | … |
Run N prompts without the modification you want to test (original skill version, or target skill absent).
Launch all N prompts in parallel in a single message (up to 100 concurrent task() calls). Collect all task_ids before proceeding.
Important: Do NOT ask about skills in the task prompt — let the agent behave naturally.
Apply the modification (e.g., new skill version, changed description, added flow step), then repeat the same N prompts.
If AGENTS.md enforces skill call logs (RULE #2):
Each task output already contains a --- skill call log --- block at the end. Read it directly — no probe needed. Extract the cumulative list and check whether the target skill appears.
累计调用:
#1. brainstorming
#2. rtl-coding-style
#3. design-microarch
← design-workflow missing → FAIL
The log also reveals call order, which is critical for diagnosing why a skill was missed (e.g., brainstorming loaded in the same batch as other skills, so its instructions arrived too late to influence that batch).
If skill call logs are not available:
Resume each session and ask directly:
task(
task_id = "<session_id>",
prompt = "请直接回答，不要执行任何操作：\n1. 你加载了哪些skill？列出完整名称。\n2. 是否加载了 <target_skill>？\n3. 如果没有，为什么？"
)
Why resume instead of a new session: The agent retains its tool-call history. It can truthfully report what it loaded. A new session has no memory.
Probe all sessions in parallel in a single message, same as execution.
Fill in the comparison table:
| # | prompt | A: loaded? | B: loaded? |
|---|--------|-----------|-----------|
| 1 | … | no | yes |
| 2 | … | no | yes |
Compute:
load_rate(group) = count(loaded) / N
lift = load_rate(B) - load_rate(A)
Save to test_results/skill_load_test_<skill_name>_<date>.md:
# Skill Load Test: <target_skill>
**Date**: … **Cases**: N
## Modification tested
<one-sentence description of what changed between A and B>
## Results
| Metric | A (baseline) | B (experiment) |
|--------|-------------|----------------|
| Load rate | X% | Y% |
| Lift | — | +Z% |
## Per-case detail
| # | prompt | A | B |
…
## Conclusion
…
These are general principles, not specific to any one skill:
Visibility is prerequisite — If a newly created skill is not in available_skills, load rate is always 0%. The system reads the skill list at startup; a session restart is required after adding skills.
Passive observation underestimates load rate — In one 20-case batch, only 60% of agents explicitly mentioned the loaded skill. After probing, actual load rate was 100%. Always probe.
Description wording matters, but only when visible — Changing a skill description from passive ("coding style guide") to imperative ("CRITICAL: Load immediately for ANY RTL task") had zero effect when the skill wasn't in available_skills, but worked once visible.
LLMs are process-oriented — Agents decide to load skills based on "what am I doing right now?" not "what domain is this task in?". A skill positioned as "design-phase guidance" loads earlier than one positioned as "coding-phase rules".
Upstream flow skills have leverage — Modifying a flow skill (e.g., brainstorming) to include a "load domain skills" step is more effective than relying on the target skill's own description to self-advocate.
One variable at a time — When multiple changes are applied simultaneously (new skill + modified description + flow change), a positive result doesn't tell you which change mattered. Prefer isolated A/B tests.
| Mistake | Why it's wrong | Fix |
|---|---|---|
| Judge by response text only | Agents load skills silently ~40% of the time | Read skill call log, or probe via resumed session |
| Let agents run to completion | Wastes tokens; skill loading happens in first reply | Add early-stop constraint to every prompt |
| Test 1-2 cases and conclude | Insufficient sample size | Minimum 10, recommend 20 |
| Skip prerequisite check | Invisible skills always show 0% | Verify visibility first |
| Change multiple things between A and B | Can't attribute causation | Isolate one variable |
| Forget to save task_ids | Can't probe later | Record every task_id immediately |
| Run all cases sequentially | Wastes time | Launch all in parallel (up to 100) |