Bridgic LLMs
bitsky-tech/bridgic
LLM provider initialization for bridgic projects. An agent skill from bitsky-tech/bridgic.
A skill your agent uses when creating, writing, reviewing, annotating, repairing, refactoring, or validating readable Verilog RTL, including synthesizable Verilog-2001 .v files, existing-RTL…
Install Readable Verilog Generator
$ npx skills add Eriemon/verilog-generator --skill readable-verilog-generator -a claude-codeProject install by default; add -g for ~/.claude/skills/.
$ gh skill install Eriemon/verilog-generator readable-verilog-generator --agent claude-codeProject scope by default; add --scope user for a personal install. Needs GitHub CLI 2.90.0 or later (public preview).
Claude Code skills documentation · loads skills from .claude/skills/
Install the "readable-verilog-generator" agent skill from https://github.com/Eriemon/verilog-generator/tree/main into .claude/skills/readable-verilog-generator/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "readable-verilog-generator", then confirm the skill loads.Claude Code copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
$ npx skills add Eriemon/verilog-generator --skill readable-verilog-generator -a codexProject install goes to .agents/skills/; add -g for ~/.codex/skills/.
$ gh skill install Eriemon/verilog-generator readable-verilog-generator --agent codexProject scope by default (.agents/skills/); add --scope user for a personal install.
Codex skills documentation · loads skills from .agents/skills/
Install the "readable-verilog-generator" agent skill from https://github.com/Eriemon/verilog-generator/tree/main into .agents/skills/readable-verilog-generator/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "readable-verilog-generator", then confirm the skill loads.Codex copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
$ npx skills add Eriemon/verilog-generator --skill readable-verilog-generator -a cursorProject install goes to .agents/skills/; add -g for ~/.cursor/skills/.
$ gh skill install Eriemon/verilog-generator readable-verilog-generator --agent cursorProject scope by default (.agents/skills/); add --scope user for a personal install.
Cursor skills documentation · loads skills from .cursor/skills/, .agents/skills/, .claude/skills/, .codex/skills/
Install the "readable-verilog-generator" agent skill from https://github.com/Eriemon/verilog-generator/tree/main into .cursor/skills/readable-verilog-generator/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "readable-verilog-generator", then confirm the skill loads.Cursor copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
$ npx skills add Eriemon/verilog-generator --skill readable-verilog-generator -a gemini-cliProject install goes to .agents/skills/; add -g for ~/.gemini/skills/.
$ gh skill install Eriemon/verilog-generator readable-verilog-generator --agent gemini-cliProject scope by default (.agents/skills/); add --scope user for a personal install.
Gemini CLI skills documentation · loads skills from .gemini/skills/, .agents/skills/
Install the "readable-verilog-generator" agent skill from https://github.com/Eriemon/verilog-generator/tree/main into .gemini/skills/readable-verilog-generator/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "readable-verilog-generator", then confirm the skill loads.Gemini CLI copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
$ gh skill install Eriemon/verilog-generator readable-verilog-generatorInstalls for Copilot at project scope by default; add --scope user for a personal install. Preview a skill first with gh skill preview. Needs GitHub CLI 2.90.0 or later (public preview).
$ npx skills add Eriemon/verilog-generator --skill readable-verilog-generator -a github-copilotProject install goes to .agents/skills/; add -g for ~/.copilot/skills/.
GitHub Copilot skills documentation · loads skills from .github/skills/, .claude/skills/, .agents/skills/
Install the "readable-verilog-generator" agent skill from https://github.com/Eriemon/verilog-generator/tree/main into .github/skills/readable-verilog-generator/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "readable-verilog-generator", then confirm the skill loads.GitHub Copilot copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
$ npx skills add Eriemon/verilog-generator --skill readable-verilog-generator -a opencodeOpenCode documents no install command of its own. Project install goes to .agents/skills/; add -g for ~/.config/opencode/skills/.
$ gh skill install Eriemon/verilog-generator readable-verilog-generator --agent opencodeProject scope by default (.agents/skills/); add --scope user for a personal install.
OpenCode skills documentation · loads skills from .opencode/skills/, .claude/skills/, .agents/skills/
Install the "readable-verilog-generator" agent skill from https://github.com/Eriemon/verilog-generator/tree/main into .opencode/skills/readable-verilog-generator/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "readable-verilog-generator", then confirm the skill loads.OpenCode copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
Facts
- Skill name
readable-verilog-generator- GitHub stars
- 308
- Token cost
- ~5.4k tokens
- SKILL.md length
- 2,509 words
- Files
- 502 (incl. scripts, references, assets)
- Skills in repo
- 1
- Repo updated
- First seen
- Licence
- Apache-2.0
At a glance
A skill your agent uses when creating, writing, reviewing, annotating, repairing, refactoring, or validating readable Verilog RTL, including synthesizable Verilog-2001 .v files, existing-RTL…
- Works in 7 steps: Confirm module name, ports, clock/reset,… → Use regular by default; use deep_review… → Generate a Python semantic model before… → …
- Validating readable Verilog RTL
- SKILL.md covers Route, Install v2.0.0, Generate And Modify and Quality, plus 6 more sections
- Calls python
What it does
Readable Verilog Generator is an agent skill from Eriemon/verilog-generator. Use when creating, writing, reviewing, annotating, repairing, refactoring, or validating readable Verilog RTL, including synthesizable Verilog-2001 .v files, existing-RTL analysis, semantic comment annotation, testbench scaffold planning, ASIC-quality review, local or remote Vivado/xsim validation, evidence-backed repair, and workflow trace diagnosis.
Its SKILL.md is about 5.4k tokens, which your agent loads only when the skill is triggered. The skill folder holds 505 other files, including scripts, reference files and assets (for example `CONTRIBUTING.md`, `README-CN.md` and `README.md`).
It sits in Development, covering Refactoring. It works with DeepSeek, Google Gemini and Python. The repository describes itself as: Agent skill for Verilog-2001 RTL generation and FPGA design workflows. The licence is Apache-2.0.
When your agent uses it
- Validating readable Verilog RTL
- Including synthesizable Verilog-2001 .v files
- Existing-RTL analysis
- Semantic comment annotation
Example prompts
- “/readable-verilog-generator”
Requirements
- Python 3
Workflow steps
7 steps, taken from the first numbered list in SKILL.md.
- Confirm module name, ports, clock/reset, behavior, pipeline expectation, interface family, and verification cases.
- Use regular by default; use deep_review only when its extra review stage adds value; use agentic_repair only for existing RTL.
- Generate a Python semantic model before RTL in the staged workflow and use it as the testbench semantic contract.
- Select local interface and ADC/DAC family templates only when the confirmed design matches them; record every adaptation in the…
- Keep batch execution generation-only, with one run directory per confirmed spec. Do not use batch mode for existing-RTL mutation or…
- Treat streaming as provider interaction only. The finalized response artifact remains the extraction source of truth.
- Run the strict generated-deliverable gate before downstream use. Optional lint and testbench helpers never replace it.
What it can do on your machine
Read from SKILL.md and the folder at commit 007372f. It shows what the files ask for, not the result of running them.
Tool permissions
Pre-approves nothing: there is no allowed-tools line, so your agent's usual permission prompts apply.
From allowed-tools in the SKILL.md frontmatter.
Runs code
Ships 1 file in scripts/, which the agent can run.
Shell commands in SKILL.md call:
python
From the folder's file list and the shell code blocks in SKILL.md.
Network
No URLs in SKILL.md.
From URLs in SKILL.md, links to its own repository left out.
Credentials
Names no API keys, tokens, secrets or passwords.
From names ending in _API_KEY, _TOKEN, _SECRET, _KEY or _PASSWORD in SKILL.md.
Context cost
Readable Verilog Generator loads about 5.4k tokens when it runs, and up to ~55k if it reads all its reference files. Until then it costs about 95 tokens; SKILL.md has 2,509 words of instructions outside code blocks.
Estimates: characters ÷ 4, the usual rule of thumb; real counts depend on the model's tokenizer. Scripts and assets cost tokens only if the agent reads them.
Safety
Auto-check passed
The automated check found no risky patterns in SKILL.md.
Automated static check — not a guarantee. Review scripts before installing. It scans the text of SKILL.md for risky patterns (piping downloads into a shell, reading credential files, hidden Unicode, destructive commands); the scripts in this folder are not scanned.
SKILL.md
The full file from Eriemon/verilog-generator at commit 007372f, republished under its Apache-2.0 licence (© Eriemon). 2,509 words, ~5,408 tokens.
Download SKILL.mdSave it as
.claude/skills/readable-verilog-generator/SKILL.md (or your agent's skills folder). This skill also uses 501 other files; get the full folder from GitHub.- name
- readable-verilog-generator
- description
- Use when creating, writing, reviewing, annotating, repairing, refactoring, or validating readable Verilog RTL, including synthesizable Verilog-2001 .v files, existing-RTL analysis, semantic comment annotation, testbench scaffold planning, ASIC-quality review, local or remote Vivado/xsim validation, evidence-backed repair, and workflow trace diagnosis.
Readable Verilog Generator
Generate, analyze, improve, and verify readable Verilog-2001 RTL through the bundled runtime under scripts/python/. Keep design RTL and verification testbenches in .v files, use scripts/python/facade/verilog_api.py for host integration, and treat formatter-AST and external-tool evidence as stronger than model self-assessment.
Route
create/write: confirm the design contract, then userequirements -> codegen_plan -> spec_document -> python -> rtl.deep_review: insert a non-empty structured review between the Python semantic model and RTL; it must cover interface, reset, timing/pipeline, handshake or FSM behavior, width, synthesis, testbench coverage, and risks.review/analyze: remain read-only and report the eight public gate states before suggesting changes.annotate: preserve an immutable normalized baseline, change only//comments, prove token equivalence from that baseline, and rerun the final deliverable gate.repair/refactor: bind the task to real RTL, reproduce or validate the issue, and apply the smallest evidence-backed change.agentic_repair: use the existing-RTLverify_existing_verilog(...)loop with an explicitconservative,semi_auto, orauto_applychoice.validate: collect static or external evidence without implicitly editing RTL.Load
references/workflows/verilog_dispatcher.mdbefore routing. Existing assets, logs, waveform clues, and mixed inputs use its read-only entry decision before any generation, validation, backup, or remote action.
Install v2.0.0
The package root contains install.ps1, install.sh, and install.bat beside this SKILL.md. They share the package-local Python backend and read only the generated installer projection under assets/installer/ plus the same-level bootstrap descriptor. Platform IDs, root resolution, target templates, status text, exit codes, transaction policy, and verification cases are data-driven by config/installer/; do not add platform branches or current test values to code or comments.
Install only from a versioned payload with the configured RELEASE_RECEIPT.json. Use --DryRun/--dry-run to validate without creating transaction resources; use replacement flags only when the target and overwrite intent are explicit. A transaction handles one platform and one target, preserves unlisted target files, writes an install receipt, and attempts rollback on failure. Unknown IDs and source directories without a valid release receipt fail closed. See references/skill/installation.md for the complete contract and parameterized invocation templates.
Generate And Modify
- Confirm module name, ports, clock/reset, behavior, pipeline expectation, interface family, and verification cases.
- Use
regularby default; usedeep_reviewonly when its extra review stage adds value; useagentic_repaironly for existing RTL. - Generate a Python semantic model before RTL in the staged workflow and use it as the testbench semantic contract.
- Select local interface and ADC/DAC family templates only when the confirmed design matches them; record every adaptation in the requirements and codegen plan.
- Keep batch execution generation-only, with one run directory per confirmed spec. Do not use batch mode for existing-RTL mutation or decision resume.
- Treat streaming as provider interaction only. The finalized response artifact remains the extraction source of truth.
- Run the strict generated-deliverable gate before downstream use. Optional lint and testbench helpers never replace it.
Every module generated or modified by this skill must ship with a same-name <module>_spec.md companion. The canonical JSON contract accepts a single legacy module projection or a modules array, but each normalized module must declare a safe .v rtl_path, complete interface ports, clock/reset semantics, cycle behavior, constraints, corner cases, verification cases, and at least one timing_diagrams entry. A timing entry contains id, title, scenario, description, and WaveJSON with named signals. python -m scripts.python.workflow.cli write-spec --spec <spec.json> --out-dir <artifact-root> [--source <rtl.v>] --language <zh|en> writes spec/<feature>/<module>_spec.md plus sibling spec/<feature>/waveforms/<module>_<scenario>.json5 and .svg. The --source form fails closed when a module or port is undeclared; the no-source form validates and renders only the confirmed spec and never infers behavior from RTL. All waveform rendering goes through the renderer runtime declared by the settings authority and fails closed when its configured Node/npm prerequisites, package identity, version, or executable are unavailable. A render failure stages diagnostics without overwriting the previous valid bundle.
The default profile is erie_strict. Its authoritative naming, bilingual header, region, FSM, comment, port-order, runtime-message, and formatter-AST rules live in references/rules/verilog-code-comment-naming-standard.md, references/rules/erie-style.md, references/rules/verilog-comment-placement.md, and machine-readable assets. Do not duplicate those rule catalogs in this entry document.
Quality
Strict quality control is mandatory. ASIC quality review, independent static lint, and testbench scaffold are optional workflow steps selected only when the task needs their evidence. Optional helper tools are inside the workflow and never replace the generated-deliverable gate.
Generated deliverables must pass the formatter-backed gate with zero errors and zero strict warnings. The public result matrix is exactly compile, ast, readability, comment, naming, profile, testbench, and toolchain; static compile evidence does not imply that an external simulator, synthesis, or remote validation ran.
Verilog/SystemVerilog filenames must describe real function. Functional digits are valid; VG148 rejects only terminal version or meaningless numeric suffixes. A file recognized as a testbench by tb_, _tb, testbench, or an exact tb/testbench/sim directory must use the tb_<function>.v or tb_<function>.sv form; _tb is recognition evidence, not an allowed output name. When an ordinary design filename carries at least two independent testbench-content evidence groups, VG149 remains inconclusive until the user confirms design or testbench through file_role_confirmations. Confirming testbench does not waive the prefix rule: rename the file to the authority-selected tb_<function> form before it can pass. VG150 rejects configured workflow/evidence phrases on entity comments and high-confidence periodic unrelated tail families; it does not blacklist ordinary Chinese words or isolated functional descriptions. The full filename and comment contract lives in references/rules/verilog-code-comment-naming-standard.md, and gate/report semantics live in references/rules/verilog-quality-gates.md.
Use strict mode for new or modified deliverables. --non-strict --warn-only is limited to historical reference-corpus analysis and never approves generated output. The formatter backend under scripts/python/quality/formatter_backend/ is the parser source for quality checks; do not add a second Verilog parser.
For comment-only work, normalize the original RTL once, annotate a copy, run the comment-only verifier with a required delta, run the final gate, and compare the final file again against the immutable baseline. Comments must not change RTL tokens, modules, ports, lvalues, resets, always targets, or instance connections. Reused generic entity comments do not satisfy semantic-comment coverage.
When VG097 cannot see an external XPM, UNISIM primitive, or project-generated IP interface, first consult the exact-name AMD-Xilinx primitive catalog in assets/xilinx_primitive_semantics.json and its detailed contract in references/rules/xilinx-primitive-exemptions.md. Keep the result inconclusive until a governed pure-interface .v source is supplied through the repeatable --external-interface-source option when the name is not cataloged or the profile conflicts. Use the registered quality.external-interface-extract command for explicit vendor-source module whitelists and quality.external-interface-manifest for reviewed project-IP contracts. Never infer that an unknown width is a mismatch, and never use a stub or primitive profile as simulation, synthesis, implementation, or hardware evidence.
Generated RTL must remain synthesizable Verilog-2001. Prefer the governed interface templates for AXI-Stream, AXI4-Lite, AXI4, AHB, and APB; use complete combinational assignments and case defaults; avoid raw gated clocks; document CDC/reset assumptions; keep datapath and control timing-reviewable; and avoid generated function or task blocks when explicit logic is clearer for waveform debug. Every FSM must use three independent processes for the state register, procedural combinational next-state logic, and state output/task logic; a continuous assign to any next-state signal is forbidden. Every continuous or procedural combinational target must pass both the transitive source-cone limit and the configured real-operation budget, each defaulting to at most three. VG146/VG147 evaluate the complete source closure: formatter structured port associations bind child outputs into the parent cone, parameter/localparam specialization selects the materialized implementation, and each definition root, full instance path, specialization fingerprint, and static target remains an independent report identity. Output connections expand through known implementations; inout and unresolved-net boundaries never invent reverse ownership; all known wire/tri drivers are merged; and a clocked output Q cuts upstream expansion while its D input remains checked. The operation budget covers unary, binary, ternary, comparison, selector, control-decode, continuous-assign, combinational-process, clocked D-input, and elaborated for operations. Moving logic into always @(*) or directly into a clocked D expression does not bypass either gate. If loop_presence=unknown, VG146 and VG147 both apply and share the same lower-bound evidence: an over-limit known lower bound fails both, otherwise both remain inconclusive. When the operation budget fails, recommend pipeline registers, registered flags or predecode, or a multicycle FSM decomposition first, and disclose that these changes may alter visible latency; immutable-latency protocols require manual architecture review. Only an exact output bridge from an output port to a clocked internal _o reg is exempt from the source-cone rule. Detailed VG rules and ASIC review criteria remain authoritative in references/rules/verilog-quality-gates.md and references/rules/asic-verilog-quality.md.
VG151-VG155 provide module-independent structural contracts. Parameter constraints are selected automatically from the identifiers in each restricted expression; module, instance, hierarchy, and scope fields are invalid. VG152 reports large dynamically selected packed storage with a configurable positive threshold and offers structured case/FSM, inferred-memory, or vendor-memory alternatives. VG153/VG154 expose read-without-driver and unused declaration evidence, including reg/wire/function/task facts. VG155 uses explicit top-level ready-valid role facts and requires both valid and ready for a transfer consumer; no target module name is part of these contracts.
Before generating or repairing declarations, apply VG156-VG158 as design-time naming and comment constraints, not only as a final audit. VG156 checks every module/function/task variable declaration by underscore token: a token containing digits is valid only when its complete case-insensitive text appears in the governed protocol/algorithm/rate allowlist. VG157 forbids ordinary-comment version markers such as v2 or version 3; only the formatter-recognized fixed bilingual header and revision-history range is exempt. VG158 repeatedly removes the governed direction/type prefixes and _o, then requires at least one functional token outside the closed meaningless-token set; unknown domain terms pass. The formatter must assign each declaration to exactly one region using the shared conflict priority, place the first group comment directly below its banner, place later group comments after exactly one blank line, leave no empty group, keep one trailing blank line per non-empty region, and produce byte-identical output on the second pass.
Show full SKILL.md (914 more words)Show less
Existing RTL
analyze_existing_verilog(...)owns structural analysis and durable design explanation.improve_existing_verilog(...)owns controlled testbench, style, partition, merge, and optimization assist flows.compare_verilog_semantics(...)owns equivalence, QoR, and transform-validation evidence.verify_existing_verilog(...)owns log-driven verification, diagnosis, candidate patches, confirmation resume, and terminal closure.
optimize_assist and merge_assist are assist-only by default and never silently accept or rewrite source RTL. conservative is report-only; semi_auto requires confirmation before overwrite; auto_apply is valid only after explicit selection and still downgrades non-eligible patch classes to confirmation. Preserve source and testbench backups, diff and decision artifacts, diagnostics, and terminal status exactly as specified by references/workflows/workflow-contracts.md and references/integration/host-integration.md.
Existing-RTL diagnostic comment findings are advisory so compile, semantic, interface, and high-confidence lint failures remain visible. A report file being written is not success; blocker, warning, failed, toolchain, external-validation, or confirmation-blocked terminal states remain non-success.
Dependencies And External Evidence
Run dependency preflight before first use and before remote, Vivado, or Vitis work. Missing required dependencies require user approval before installation; if declined, continue only with self-contained static Verilog work and block remote/execute/implement claims. The required skill dependency remains erie-remote-ssh; the optional context-engineering group is the only recommended external skill group. No additional external skill suite is included. The required external renderer dependency, package identity, version, executable, and Node/npm floor are read from the settings authority; use scripts/python/toolchain/wavedrom_runtime.py with the check, install --yes, or render subcommand, never an ad-hoc package command. Prefer vivado-developer and vitis-developer for AMD-Xilinx, and pds-developer for PangoMicro. FPGA-Agent-Skills remains an explicit manual fallback.
Compile, execute, simulation, synthesis, or implement readiness requires actual external evidence. Remote validation is preferred and must use erie-remote-ssh, a user-confirmed server, local-only server selection/configuration, and the remote workdir's .settings/verilog.remote.json. A configured default is only a recommendation. Multiple Vivado settings candidates require user selection. Do not silently fall back to local tools and do not add direct SSH/SCP logic.
Remote validation runs are retained by default, including fixed remote-fixture reports. Cleanup occurs only when explicitly requested. Vivado xsim is the preferred simulator backend, followed by VCS+Verdi and then iverilog/vvp; yosys is implement-readiness evidence only. VCS+Verdi support is scripted backend invocation, not full GUI/session automation.
Document And Command Registry
Registration is enabled for this skill. Markdown remains the authoritative knowledge source. Editable command records live under config/registry/commands/; document responsibilities and search metadata have one owner in config/registry/documents/catalog.json; current duplicate and interface decisions live in config/registry/governance/reviews.json; config/registry/registry.sqlite3 is a generated local FTS5 trigram index at the location required by the agents-md-generator gate. The skill runtime is self-contained and must not import or call an external agents-md-generator registry implementation.
Document governance scans SKILL.md and every Markdown file below references/, recursively. It records one responsibility per document, knowledge pointers, exact and fuzzy duplicate adjudications, interface mappings, and content hashes. Remove only confirmed equivalent duplication; preserve structural repetition and every unique contract. Installed copies may query and check but must not mutate registry sources.
Detailed command syntax, examples, prerequisites, outputs, exit codes, risk warnings, and relations are retrieved from the local registry:
python -m scripts.python.registry.query_registry ask "<question>" [--kind <kind>] [--category <name>] [--limit 1..10] [--json]The query is read-only and never executes returned commands. Exit codes are 0 for hits, 1 for no match, 2 for request errors, and 3 for a missing, corrupt, stale, or incompatible index. After JSON source changes, use registry instruction registry.build; never edit SQLite by hand. See references/skill/script-guide.md for the compact registry lifecycle.
Verify
The first outer command group is the generated-deliverable gate:
python -m scripts.python.validation.generated_deliverable_gate <rtl-file-or-dir> --json <report.json> --markdown <report.md>When either report option is omitted, the CLI writes both reports under the caller's current working directory: reports/readable/deliverable_gate.json and reports/readable/deliverable_gate.md. The focused quality CLI follows the same policy with quality_gate.json and quality_gate.md. Supplying one explicit path only overrides that format; JSON and Markdown paths must resolve to different files. Runtime reports must never be written back to the source or installed skill root.
Both CLIs publish v3 reports and print compact [Python] finding lines containing the VG rule, status, confirmed location, concrete problem, and direct fix instruction. The JSON and Markdown files contain the full evidence, ordered repair steps, risk and human-review obligation, plus bad/good examples. Exit code 1 means the gate found RTL issues; exit code 2 means invocation, diagnostic-contract, or report-publication failure.
The second outer command group is package validation:
python -m scripts.python.validation.validate_verilog_skill --settings .\config\defaults.jsonRun the smallest relevant checks while editing, then the governed final chain. The extended repository-regression, external-audit, and remote variants live in references/integration/configuration.md and registry instruction validation.skill. Local success does not replace requested remote pytest, simulator, synthesis, or installed-copy evidence. Never claim an unrun check passed.
Resources
references/skill/script-guide.md: registry query, build, document-governance, and command-category contract.references/workflows/verilog_dispatcher.md: task classification, public gate matrix, and safe repair boundary.references/workflows/workflow-contracts.md: run artifacts, statuses, resume behavior, and trace semantics.references/integration/configuration.md: paths, dependencies, remote settings, and validation configuration.references/integration/host-integration.md: facade functions and host-owned execution boundaries.scripts/python/workflow/spec_document.py: strict module contract, source cross-check, Markdown and WaveDrom bundle writer.scripts/python/toolchain/wavedrom_runtime.py: pinned Node/npm/WaveDrom check, explicit install, and SVG renderer.references/rules/verilog-code-comment-naming-standard.md: canonical readable RTL rule text.references/rules/verilog-quality-gates.md: VG catalog and report semantics.references/rules/xilinx-primitive-exemptions.md: exact AMD-Xilinx UNISIM/XPM/project-IP primitive inventory and VG097/VG132/VG146/VG147 boundary contract.references/rules/asic-verilog-quality.md: ASIC quality review criteria and risk boundaries.references/rules/testbench-patterns.md: self-checking testbench scaffold patterns.references/checklists/lint-checklist.md: independent static lint review checklist.references/corpus/verilog-style-observations.md: empirical ideal/bad corpus observations that do not override normative rules.references/checklists/verilog-readability-gate.md: final human review.references/skill/skill-standards.md: skill packaging and progressive-disclosure requirements.
Boundaries
- Do not generate non-Verilog hardware flows, C/C++ kernels, or alternate RTL dialects.
- Do not invent source RTL, testbenches, logs, successful tool evidence, or repair confirmation.
- Do not store caller run artifacts inside the skill; use caller-selected directories such as
reports/. - Do not let optional helpers, model reviews, or registry query results replace actual quality or toolchain evidence.
© Eriemon, Apache-2.0. Rendered from Markdown: HTML in the file is shown as text, images as links, and headings moved down two levels. Raw file
Files
SKILL.md and 501 other files (scripts, references, assets) in the repository root of Eriemon/verilog-generator.
- SKILL.md
- CITATION.cff
- CONTRIBUTING.md
- LICENSE
- README-CN.md
- README.md
- RELEASE_RECEIPT.json
- SECURITY.md
- VERSION
- agents/openai.yaml
- assets/examples/existing_rtl/fsm_without_default.v
- assets/examples/existing_rtl/fsm_without_default_spec.md
- assets/examples/existing_rtl/leaf_counter.v
- assets/examples/existing_rtl/missing_output_register.v
- assets/examples/existing_rtl/missing_output_register_spec.md
- assets/examples/existing_rtl/ready_valid_slice.v
- assets/examples/existing_rtl/ready_valid_slice_spec.md
- … and 485 more
Open the folder on GitHubat commit 007372f
Compare with similar skills
Readable Verilog Generator next to the 5 skills that share the most tags, products or categories with it. Stars are the repository's; “used in” counts other GitHub owners with a copy.
| Skill | Stars | Used in | Tokens | Auto-check | Licence | Repo updated |
|---|---|---|---|---|---|---|
| Readable Verilog Generator this skillEriemon/verilog-generator | 308 | — | ~5.4k | Automated safety check: Pass | Apache-2.0 | |
| Bridgic LLMsbitsky-tech/bridgic | 155 | — | ~839 | Automated safety check: Notes | MIT | |
| Mmsp PythonPrism-Shadow/model-message-stream-protocol | 113 | — | ~1.4k | Automated safety check: Pass | Apache-2.0 | |
| Mmsp DevPrism-Shadow/model-message-stream-protocol | 113 | — | ~7.2k | Automated safety check: Pass | Apache-2.0 | |
| Dignified Python Standardsdocling-project/docling | 68k | — | ~1.5k | Automated safety check: Pass | Apache-2.0 | |
| Readable Pycrazyguitar/pysheeet | 8.2k | — | ~2.4k | Automated safety check: Pass | MIT |
Similar skills
Mmsp Python
Prism-Shadow/model-message-stream-protocol
Guidance for using the MMSP Python SDK (mmsp). An agent skill from Prism-Shadow/model-message-stream-protocol.
Mmsp Dev
Prism-Shadow/model-message-stream-protocol
Fixed workflow for developing MMSP itself — adding or updating model support, and changing its pages.
Dignified Python Standards
docling-project/docling
Applies opinionated production Python conventions chosen by the project's Python version: modern type syntax, pathlib, explicit checks and interface guidance.
Readable Py
crazyguitar/pysheeet
Readable Python code rules inspired by The Art of Readable Code.
Nexus Mapper
Haaaiawd/Nexus-skills
Generate a persistent .nexus-map/ knowledge base that lets any AI session instantly understand a codebase's architecture, systems, dependencies, and change hotspots.
Related
Works with
Categories
Questions about Readable Verilog Generator
What does Readable Verilog Generator do?
A skill your agent uses when creating, writing, reviewing, annotating, repairing, refactoring, or validating readable Verilog RTL, including synthesizable Verilog-2001 .v files, existing-RTL…. Readable Verilog Generator is an agent skill from Eriemon/verilog-generator.v files, existing-RTL analysis, semantic comment annotation, testbench scaffold planning, ASIC-quality review, local or remote Vivado/xsim validation, evidence-backed repair, and workflow trace diagnosis.
When should I use Readable Verilog Generator?
Readable Verilog Generator fits situations like: validating readable Verilog RTL; including synthesizable Verilog-2001 .v files; existing-RTL analysis; semantic comment annotation.
How do I install Readable Verilog Generator in Claude Code?
Run `npx skills add Eriemon/verilog-generator --skill readable-verilog-generator -a claude-code`. Or copy the skill folder (the Eriemon/verilog-generator repository) into .claude/skills/readable-verilog-generator in your project. Claude Code loads it when a task matches its description.
How do I install Readable Verilog Generator in Codex?
Run `npx skills add Eriemon/verilog-generator --skill readable-verilog-generator -a codex`. Or copy the skill folder (the Eriemon/verilog-generator repository) into .agents/skills/readable-verilog-generator in your project. Codex loads it when a task matches its description.
Can I use Readable Verilog Generator in Cursor, Gemini CLI or GitHub Copilot?
Cursor, Gemini CLI, GitHub Copilot and OpenCode also load SKILL.md folders. With the skills CLI, run `npx skills add Eriemon/verilog-generator --skill readable-verilog-generator -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/readable-verilog-generator, .gemini/skills/readable-verilog-generator, .github/skills/readable-verilog-generator and .opencode/skills/readable-verilog-generator in your project.
What does Readable Verilog Generator need to run?
Going by SKILL.md and its folder, Readable Verilog Generator needs the command-line tools its instructions call (python). Our summary lists: Python 3.
Does Readable Verilog Generator access the network?
SKILL.md contains no URLs. Any network use would come from the scripts or tools the agent runs. This is read from the text; nothing was executed.
Is Readable Verilog Generator safe to install?
Our automated static check of SKILL.md found no risky patterns, such as piping downloads into a shell, reading credential files or hidden Unicode. It is not a guarantee. The check reads SKILL.md only: the scripts in the folder are not scanned, so read them before running anything.
What licence does Readable Verilog Generator use?
Readable Verilog Generator is published under the Apache-2.0 licence (from the LICENSE file in the skill folder). It allows redistribution, so the full SKILL.md is shown on this page.
How many tokens does Readable Verilog Generator use?
About 5.4k tokens (SKILL.md is roughly 22k characters). Agents keep only the skill's name and description in context until a task matches; then they load SKILL.md in full. Its references folder adds about 49k tokens, read only when the agent opens those files.
What are the alternatives to Readable Verilog Generator?
Skills that share tags, products or a category with Readable Verilog Generator: Bridgic LLMs (bitsky-tech/bridgic, 155 stars), Mmsp Python (Prism-Shadow/model-message-stream-protocol, 113 stars), Mmsp Dev (Prism-Shadow/model-message-stream-protocol, 113 stars) and Dignified Python Standards (docling-project/docling, 68k stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.
Who maintains Readable Verilog Generator?
Eriemon (a GitHub user) maintains it in Eriemon/verilog-generator, which has 308 GitHub stars. The repository was last updated on August 25, 2026.
Source: Eriemon/verilog-generator on GitHub. Facts on this page come from the repository at the commit we read; the author's words are quoted as theirs.