Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx skills add phamcuong21478/rtl-skills --skill vflowgit clone --depth 1 https://github.com/phamcuong21478/rtl-skillsWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/skills/phamcuong21478/rtl-skills/vflow)<a href="https://agentmods.dev/skills/phamcuong21478/rtl-skills/vflow"><img src="https://agentmods.dev/badge/skills/phamcuong21478/rtl-skills/vflow/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/skills/phamcuong21478/rtl-skills/vflow"><img src="https://agentmods.dev/badge/skills/phamcuong21478/rtl-skills/vflow.svg" alt="Reviewed on agentmods" width="80" height="20"></a>What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5.1 | $0.00028 | $0.02981 |
| Opus 5 | $0.00014 | $0.01491 |
| Sonnet 5 | $0.00006 | $0.00596 |
| Haiku 4.5 | $0.00003 | $0.00298 |
Grade A, and why
vflow scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 12d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 178 lines — stays where its author put it; the contents beside it link to each section on GitHub.
RTL Flow Orchestrator
Overview
Two responsibilities:
- State scan — inspect project directories to determine each phase's completion for one IP, then write
./flow_status.md. - Flow execution — drive the flow by invoking the right skill at the right time, pausing at checkpoints, and looping the debug-fix-retest cycle.
Input is an IP name, optionally followed by a mode keyword.
Resolve the IP name before anything else — never guess across IPs. flow_status.md and every downstream skill operate on exactly one IP.
Single-IP-repo assumption. The bundled scanner assumes the repo holds one IP: its Phase 2 and Phase 3 checks scan all of ddoc/*_req.md and rtl/ rather than scoping to <ip>_top's hierarchy. With one IP this is exact. If a repo ever holds two IPs, those two phase counts would mix submodules across IPs — scope them to the <ip>_top instantiation hierarchy before relying on the scan (see the note in scan.sh).
- Name given → use it.
- Not given, exactly one candidate top-level requirement
.mdin the project root (a.mdthat is notCLAUDE.md,flow_status.md, or other generated/status doc) → use it. - Not given, two or more candidates → stop and ask the user which IP (list the candidates). No heuristic pick; never run more than one IP per invocation.
- Not given, no candidate → stop and report none found.
Invocation modes
| Invocation | Behavior |
|---|---|
vflow [<ip>] |
Scan and execute (default): Step 1 → Step 2 → Step 3. |
vflow [<ip>] status (also scan, --scan-only, --dry-run) |
Scan only: Step 1 → Step 2, present flow_status.md, then stop. Touch no file but flow_status.md; invoke no downstream skill. |
Step 1 - Scan Project State
Never Read a whole .md to compute a status symbol. All status comes from existence / mtime / grep/awk counts, which the bundled scanner already does. (Enumerating RTL_BUG locations for the Step 2 open-issues display is a targeted grep of debug_summary.md, not a whole-file read — that is allowed.) Run the scanner once from the project root; do not reissue per-check commands inline:
What ships with it
1 file beside SKILL.md in the same directory: the scripts, references and assets a skill reads on demand. Not counted in the per-session cost; read them before you install if any of them is executable.
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 12d ago First seen · 178 lines · 28 tokens per session scan A 03afcf54224c
vflow is a skill published in the GitHub repository phamcuong21478/rtl-skills (13 stars, last pushed 3mo ago), licensed Apache-2.0. It adds 28 tokens to every session and 2,981 once invoked, about $0.0001 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-31.
Other skills, from other repositories
simulation
Use when materializing and running a module's UVM TB from an approved verification plan (regression, coverage); not for plan authoring or RTL changes.
simulation-plan
Use when generating or evolving the verification plan, scaffold specification, testpoints, and power scenarios for a module; not for materializing UVM TB or running EDA tools.
synthesis
Use when running Design Compiler synthesis, analyzing timing/area/power reports, supplementing SDC exceptions, or re-synthesizing after RTL changes; not for power analysis or static timing.
design-flow
Use when progressing IC design through stages, checking module status, or routing rework decisions; not for single-stage execution or artifact authoring.
lint-cdc
Use when running SpyGlass lint or CDC checks, analyzing violations, adding waivers, supplementing SGDC annotations, or re-running after RTL changes; not for synthesis or simulation.
power-analysis
Use when running gate-level power simulation + PT-PX averaged power analysis (SAIF flow) for PPA gating; not for RTL functional simulation, static timing, or time-resolved waveforms.