Agent skill

Physical Design

by hdl-tools in hdl-tools/digital-chip-design-agents

Full physical design flow — floorplan, placement, clock tree synthesis, routing, timing optimisation, power optimisation, area optimisation, and tape-out sign-off.

MITAuto-check: notes

Install Physical Design

skills CLI
$ npx skills add hdl-tools/digital-chip-design-agents --skill physical-design -a claude-code

Project install by default; add -g for ~/.claude/skills/.

GitHub CLI
$ gh skill install hdl-tools/digital-chip-design-agents physical-design --agent claude-code

Project scope by default; add --scope user for a personal install. Needs GitHub CLI 2.90.0 or later (public preview).

Manual copy
$ git clone --depth 1 https://github.com/hdl-tools/digital-chip-design-agents.git skills-src && mkdir -p .claude/skills && cp -r skills-src/plugins/pd/skills/physical-design .claude/skills/physical-design && rm -rf skills-src

Use ~/.claude/skills/ instead of .claude/skills for a personal install. The folder must contain SKILL.md.

Claude Code skills documentation · loads skills from .claude/skills/

Facts

Skill name
physical-design
GitHub stars
213
Token cost
~3.8k tokens
SKILL.md length
1,661 words
Files
1
Skills in repo
17
Repo updated
First seen
Licence
MIT

At a glance

Full physical design flow — floorplan, placement, clock tree synthesis, routing, timing optimisation, power optimisation, area optimisation, and tape-out sign-off.

  • Works in 2 steps: memory/pd/knowledge.md — known failure… → memory/pd/run_state.md — current run…
  • Implementing a gate-level netlist through to GDS-II
  • SKILL.md covers Invocation, Pre-run Context, Purpose and Supported EDA Tools, plus 6 more sections
  • Calls make and python3

What it does

Physical Design is an agent skill from hdl-tools/digital-chip-design-agents. Full physical design flow — floorplan, placement, clock tree synthesis, routing, timing optimisation, power optimisation, area optimisation, and tape-out sign-off. Use when implementing a gate-level netlist through to GDS-II, closing timing and power, or performing any individual PD stage analysis.

Its SKILL.md is about 3.8k tokens, which your agent loads only when the skill is triggered. It is a single SKILL.md file with no bundled scripts.

The repository describes itself as: Digital HDL Design Full-stack Agents. The licence is MIT.

When your agent uses it

  • Implementing a gate-level netlist through to GDS-II
  • Closing timing and power
  • Performing any individual PD stage analysis

Example prompts

  • “/physical-design”

Requirements

  • Python 3
  • Pre-approved tools (allowed-tools): Read, Write, Bash

Workflow steps

2 steps, taken from the first numbered list in SKILL.md.

  1. memory/pd/knowledge.md — known failure patterns, successful tool flags, PDK quirks.
  2. memory/pd/run_state.md — current run identity (run_id, design_name, pdk,

What it can do on your machine

Read from SKILL.md and the folder at commit 38736b1. It shows what the files ask for, not the result of running them.

  • Tool permissions

    Pre-approves these tools, so the agent can use them without asking each time:

    • Read
    • Write
    • Bash

    From allowed-tools in the SKILL.md frontmatter.

  • Runs code

    Shell commands in SKILL.md call:

    • make
    • python3

    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

Physical Design loads about 3.8k tokens when it runs. Until then it costs about 79 tokens; SKILL.md has 1,661 words of instructions outside code blocks.

Always · name and description, kept in context so the agent knows when to use it
~79
When it runs · the whole SKILL.md, loaded when a task matches
~3.8k

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: notes

The automated check noted patterns worth knowing about, such as sudo or a known installer.

  • NotePre-approves every shell command (allowed-tools: Bash)SKILL.md
    allowed-tools: Read, Write, Bash

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); files beside SKILL.md are not scanned.

SKILL.md

The full file from hdl-tools/digital-chip-design-agents at commit 38736b1, republished under its MIT licence (© hdl-tools). 1,661 words, ~3,754 tokens.

Download SKILL.mdSave it as .claude/skills/physical-design/SKILL.md (or your agent's skills folder).
name
physical-design
description
Full physical design flow — floorplan, placement, clock tree synthesis, routing, timing optimisation, power optimisation, area optimisation, and tape-out sign-off. Use when implementing a gate-level netlist through to GDS-II, closing timing and power, or performing any individual PD stage analysis.
allowed-tools
Read, Write, Bash
version
1.0.0
author
chuanseng-ng
license
MIT

Skill: Physical Design

Invocation

  • If invoked by a user presenting a physical design task: immediately spawn the digital-chip-design-agents:physical-design-orchestrator agent and pass the full user request and any available context. Do not execute stages directly.
  • If invoked by the physical-design-orchestrator mid-flow: do not spawn a new agent. Treat this file as read-only — return the requested stage rules, sign-off criteria, or loop-back guidance to the calling orchestrator.

Spawning the orchestrator from within an active orchestrator run causes recursive delegation and must never happen.

Pre-run Context

Before executing or advising on any stage, read the following files if they exist:

  1. memory/pd/knowledge.md — known failure patterns, successful tool flags, PDK quirks. Incorporate its guidance into every stage decision. If absent, proceed without it.
  2. memory/pd/run_state.md — current run identity (run_id, design_name, pdk, last_stage). Use this to resume correctly after interruption. If absent, a new run is starting; the orchestrator will create this file before the first stage.

This pre-run read applies whether this skill is loaded by a user or called by the orchestrator mid-flow. It ensures the fix database is consulted before any diagnosis step.

Purpose

Guide the complete physical implementation flow from gate-level netlist to tape-out-ready GDS-II. Eight stages with explicit QoR gates and loop-back criteria enforced by the physical-design orchestrator.


Supported EDA Tools

Open-Source
  • OpenROAD / ORFS (make DESIGN_CONFIG=./designs/<platform>/<design>/config.mk) — full PD pipeline; executes sequentially (see sequential flow note below)
  • LibreLane / OpenLane 2 (openlane <config.json>) — sequential PD pipeline built on OpenROAD; (see sequential flow note below)
  • KLayout (klayout) — DRC, LVS, and GDS-II viewing/editing; used for signoff DRC in open-source flows
Proprietary
  • Cadence Innovus (innovus, dialect cadence) — floorplan through signoff; interactive and batch modes
  • Synopsys IC Compiler 2 (icc2_shell, dialect synopsys) — hierarchical PD with Fusion technology
  • Siemens Aprisa (dialect siemens) — physical implementation for advanced nodes
Sequential Flow Log Review (OpenROAD / LibreLane)

OpenROAD Flow Scripts (ORFS) and LibreLane execute the entire PD pipeline in a single invocation. Stages run sequentially without pausing for agent intervention. After the run completes (or fails mid-stage), the agent must read the per-stage log files to evaluate QoR and apply loop-back logic.

ORFS log layout:

logs/<platform>/<design>/
  1_1_yosys.log         # synthesis (Yosys)
  2_1_floorplan.log     # floorplan (OpenROAD)
  3_1_place.log         # global placement (OpenROAD)
  3_4_resizer.log       # resizer / timing-driven placement
  4_1_cts.log           # clock tree synthesis (OpenROAD)
  5_1_route.log         # global routing (OpenROAD)
  5_3_fillcell.log      # filler cell insertion
  6_1_finishing.log     # signoff: DRC (KLayout/Magic), LVS (Netgen), final STA

Invocation: make DESIGN_CONFIG=./designs/<platform>/<design>/config.mk Resume from stage: make do-<stage> (e.g. make do-3_2_place)

LibreLane (OpenLane 2) log layout:

runs/<design>/<run_tag>/logs/
  synthesis/            # Yosys synthesis logs
  floorplan/            # OpenROAD floorplan logs
  placement/            # OpenROAD placement logs (global + detail)
  cts/                  # OpenROAD CTS logs
  routing/              # OpenROAD global + detailed routing (DRT) logs
  signoff/              # Magic/Netgen DRC+LVS, OpenSTA final timing

Invocation: openlane <config.json> (or python3 -m openlane <config.json>) Resume from step: openlane --from <step_name> <config.json>

Agent procedure after run:

  1. Identify the last successfully completed stage from log timestamps or exit codes
  2. Read the log for each completed stage and extract the relevant QoR metrics (WNS, DRC count, congestion, IR drop) defined in the ## Stage: sections below
  3. Apply loop-back rules from this skill; correct the input config or constraints
  4. Re-invoke from the failed stage using the resume command above

Stage: floorplan

Domain Rules
  1. Core utilisation target: design_state.constraints.area.utilization_pct_target% (default: 75%) — leave margin for routing congestion
  2. Macros: place at die edges or corners with halos (typically 5–10 μm)
  3. IO pads: distribute evenly; match package pin assignment
  4. Power grid: VDD/VSS straps every N rows (technology-node specific)
  5. Blockages: hard blockages around analog/RF macros
  6. Aspect ratio: keep close to 1:1 unless package constrains otherwise
  7. Voltage island boundaries must align to row boundaries
QoR Metrics to Evaluate
  • Estimated congestion (H and V): flag if > 80%
  • Estimated WNS from floorplan-stage STA: flag if < −2 ns
  • IR drop estimate: flag if > 2× design_state.constraints.power.ir_drop_pct_max% of VDD (default threshold: 10%)
Output Required
  • Floorplan DEF (floorplan.def)
  • Power grid DEF or script
  • Macro placement report
  • Estimated congestion map

Stage: placement

Domain Rules
  1. Sequence: global → legalise → detailed → pre-CTS optimisation
  2. Pre-CTS timing: ideal clocks; uncertainty = skew + jitter estimate
  3. Max utilisation per partition: 80%
  4. High-fanout nets: buffer before placement or apply constraints
  5. Timing-critical paths: co-locate related cells with placement constraints
  6. Scan chains: re-order after placement for minimum wirelength
QoR Metrics to Evaluate
  • Pre-CTS WNS: > −0.3 ns (early stage gate; sign-off target is constraints.timing.wns_ns_target, default: 0)
  • Cell density hotspots: flag if any region > 90%
  • Max utilisation per partition: design_state.constraints.area.utilization_pct_max% (default: 85%); flag if exceeded
  • Estimated routing congestion overflow: flag if > 1%
Output Required
  • Placed DEF
  • Pre-CTS timing report (setup and hold)
  • Cell density and congestion report

Stage: cts

Domain Rules
  1. Target skew: < design_state.constraints.timing.skew_ps_max ps (default: 100 ps, or per SDC set_clock_uncertainty)
  2. Max transition on clock nets: per technology DRC rule (design_state.constraints.timing.transition_ps_max ps, default: 200 ps)
  3. Max fanout per clock buffer: per library (design_state.constraints.timing.fanout_max, default: 16–32)
  4. Useful skew: only with explicit sign-off approval
  5. Clock gating: integrate into CTS; verify enable pin timing
  6. Multi-clock: handle each domain independently; check CDC after CTS
QoR Metrics to Evaluate
  • Global skew per domain: flag if > 1.5× design_state.constraints.timing.skew_ps_max ps (default threshold: 150 ps)
  • Max insertion delay: flag if > design_state.constraints.timing.insertion_delay_ps_max ps (default: 500 ps)
  • Post-CTS WNS (setup): flag if < −0.2 ns
  • Post-CTS hold slack: must be ≥ 0 before routing
Output Required
  • Post-CTS DEF
  • Clock tree report (skew, insertion delay per domain)
  • Post-CTS timing report (setup and hold)

Stage: routing

Domain Rules
  1. Sequence: global → track assignment → detailed → search-and-repair
  2. Follow foundry DRC deck (spacing, width, via enclosure)
  3. Shield critical clock and analog nets
  4. Upper metals for power, lower metals for signals
  5. Antenna rules: insert diodes or use jump-via strategy
  6. Double/multi-patterning (7 nm and below): resolve same-colour violations
QoR Metrics to Evaluate
  • DRC violations: 0 at sign-off
  • LVS errors: 0 at sign-off
  • Post-route WNS: flag if < 0
  • Routing overflow: 0
Output Required
  • Routed DEF
  • DRC report
  • LVS report
  • Post-route timing report

Stage: timing_optimization

Domain Rules
  1. Multi-corner: SS (setup), FF (hold), TT (typical)
  2. Setup: upsize drivers, insert repeaters, retime registers
  3. Hold: insert HVT delay buffers
  4. Vt swapping: SVT/LVT for speed-critical; HVT for power-insensitive paths
  5. ECO: formal ECO → place in reserved sites → re-route ECO nets
  6. Do not modify scan chain order without DFT approval
  7. Apply POCV/AOCV per foundry sign-off agreement
QoR Metrics to Evaluate
  • WNS: ≥ design_state.constraints.timing.wns_ns_target (default: 0) all corners
  • TNS: = design_state.constraints.timing.tns_ns_target (default: 0) all corners
  • Hold slack: ≥ 0 after fixing
  • ECO cell count: flag if > 2% of total cells
Output Required
  • Timing closure report (all corners)
  • ECO change list
  • SPEF
  • Updated routed DEF (post-ECO)

Show full SKILL.md (659 more words)Show less

Stage: power_optimization

Domain Rules
  1. Dynamic: clock gating insertion, operand isolation, multi-Vt swapping
  2. Leakage: swap non-critical cells to HVT; verify timing after each batch
  3. Power domains: validate UPF (isolation, level-shifters, retention regs)
  4. Voltage islands: verify IR drop per domain
  5. Always-on logic: verify correct library cells
  6. Power gating: verify wakeup/shutdown sequences before routing changes
QoR Metrics to Evaluate
  • Total power: within design_state.constraints.power.power_mw budget
  • Leakage: flag if > design_state.constraints.power.leakage_pct_max% of total at TT corner (default: 15%)
  • IR drop: < design_state.constraints.power.ir_drop_pct_max% VDD across all domains (default: 5%)
  • Post-power-opt WNS: must remain ≥ design_state.constraints.timing.wns_ns_target (default: 0)
Output Required
  • Power analysis report (dynamic + static, per domain)
  • IR drop report
  • Updated DEF (post-power-opt)
  • UPF compliance report

Stage: area_optimization

Domain Rules
  1. Remove redundant buffers and inverter pairs
  2. Downsize non-timing-critical cells to minimum drive strength
  3. Reclaim unused standard cell sites
  4. Do not drop WNS margin below 50 ps buffer
  5. Re-run DRC after any area ECO
QoR Metrics to Evaluate
  • Core utilisation: target design_state.constraints.area.utilization_pct_target% (default: 75%); hard limit design_state.constraints.area.utilization_pct_max% (default: 85%)
  • WNS: must remain ≥ design_state.constraints.timing.wns_ns_target (default: 0)
  • DRC: must remain clean
Output Required
  • Area utilisation report (pre vs post)
  • Updated DEF
  • Cell count breakdown

Stage: signoff

Sign-off Pass Criteria (all must pass)
CheckCriterion
Setup WNS≥ design_state.constraints.timing.wns_ns_target (default: 0) all corners
Setup TNS= design_state.constraints.timing.tns_ns_target (default: 0) all corners
Hold WNS≥ design_state.constraints.timing.wns_ns_target (default: 0) all corners
DRC violations= 0
LVS errors= 0
Antenna violations= 0
IR drop< design_state.constraints.power.ir_drop_pct_max% VDD (default: 5%)
Metal densityWithin foundry window
Domain Rules
  1. STA sign-off: run all required PVT corners with POCV/AOCV
  2. DRC: foundry-approved deck — zero violations
  3. LVS: netlist vs layout — zero errors
  4. ERC: electromigration and IR drop sign-off
  5. Final GDS: merge all layers, add seal ring, chip-level DRC
Failure Escalation
  • Timing fail → timing_optimization
  • DRC/LVS fail → routing
  • Power/EM fail → power_optimization
Output Required
  • Sign-off STA report (all corners)
  • DRC clean report
  • LVS clean report
  • Final GDS-II
  • Completed tape-out checklist

Constraint Validation

See plugins/meta/skills/pipeline-orchestration/SKILL.md §Constraints Schema for the authoritative schema and stage-entry validation rule.

Required at entry (floorplan) — hard-fail if missing:

  • constraints.clock.clk_mhz — target clock frequency
  • constraints.area.area_um2 — die area budget
  • constraints.power.power_mw — total power budget
  • constraints.pvt_corners — at least one entry with non-null voltage_v and temp_c

Optional (schema defaults apply when absent):

  • constraints.timing.wns_ns_target (default: 0) — WNS sign-off threshold
  • constraints.timing.tns_ns_target (default: 0) — TNS sign-off threshold
  • constraints.timing.skew_ps_max (default: 100) — CTS skew target
  • constraints.timing.transition_ps_max (default: 200) — clock transition limit
  • constraints.timing.insertion_delay_ps_max (default: 500) — max clock insertion delay
  • constraints.timing.fanout_max (default: 32) — max clock buffer fanout
  • constraints.area.utilization_pct_target (default: 75) — target core utilisation %
  • constraints.area.utilization_pct_max (default: 85) — hard utilisation ceiling %
  • constraints.power.leakage_pct_max (default: 15) — leakage as % of total power
  • constraints.power.ir_drop_pct_max (default: 5) — IR drop limit as % of VDD

Memory

Run state (write before first stage, update after each stage)

Write memory/pd/run_state.md as the first action before launching any tool:

markdown
run_id:      pd_<YYYYMMDD>_<HHMMSS>
design_name: <design>
pdk:         <pdk or unknown>
tool:        <primary tool>
start_time:  <ISO-8601>
last_stage:  null

Update last_stage to the completed stage name only after each stage finishes successfully. This file allows wakeup-loop prompts and resumed sessions to identify the correct run directory without relying on in-memory state.

Write on stage completion

After each stage completes (regardless of whether an orchestrator session is active), upsert one JSON record in memory/pd/experiences.jsonl keyed by run_id — do not append a second line for the same run. Write with the stages completed so far and signoff_achieved: false; overwrite to true only when signoff passes.

Use run_id = pd_<YYYYMMDD>_<HHMMSS> (set once at flow start; reuse on each stage update). Every JSON record written to experiences.jsonl must include a top-level "run_id" field (string) inside the record itself — upsert behavior is keyed by this field. Do not rely on external metadata; the "run_id" property must be present in the JSON object. Records should be written with stages completed and signoff_achieved: false, and only overwritten to true when signoff passes. Create the file and parent directories if they do not exist.

Optional: claude-mem index

If mcp__plugin_ecc_memory__add_observations is available in this session, also emit each new fix as an observation to entity chip-design-pd-fixes after writing to experiences.jsonl. Skip this step silently if the tool is absent — the JSONL file is the canonical record.

© hdl-tools, MIT. Rendered from Markdown: HTML in the file is shown as text, images as links, and headings moved down two levels. Raw file

Files

Just SKILL.md in plugins/pd/skills/physical-design of hdl-tools/digital-chip-design-agents.

Open the folder on GitHubat commit 38736b1

Compare with similar skills

Physical Design 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.

Physical Design compared with similar skills
SkillStarsUsed inTokensAuto-checkLicenceRepo updated
Physical Design this skillhdl-tools/digital-chip-design-agents213—~3.8kAutomated safety check: NotesMIT
More Trees AutomationComposioHQ/awesome-claude-skills77k3 repos~742Automated safety check: PassNone
Physical Addressthedaviddias/Front-End-Checklist74k—~574Automated safety check: PassMIT
Pierre Trees File Treepierrecomputer/pierre6.3k—~473Automated safety check: PassApache-2.0
Tree Ring Memorysickn33/agentic-awesome-skills47k1 repos~2.2kAutomated safety check: PassMIT
Esign Field Placementaffaan-m/ECC276k—~2.6kAutomated safety check: PassMIT

Similar skills

  • More Trees Automation

    ComposioHQ/awesome-claude-skills

    Automate More Trees tasks via Rube MCP (Composio). An agent skill from ComposioHQ/awesome-claude-skills.

    77k GitHub starsUsed in 3 repos~742 tokens
    Productivity & AutomationAuto-check passed
  • Physical Address

    thedaviddias/Front-End-Checklist

    A skill your agent uses when auditing local business websites, e-commerce sites, or any site where a physical presence affects trust or local search visibility.

    74k GitHub stars~574 tokensUpdated 3 days ago
    Marketing & SEOAuto-check passed
  • Pierre Trees File Tree

    pierrecomputer/pierre

    Use when an app uses @pierre/trees to render or control a file tree, including React, vanilla JavaScript, SSR, web components, selection, search, rename, drag…

    6.3k GitHub stars~473 tokensUpdated today
    Frontend & DesignAuto-check passed
  • Tree Ring Memory

    sickn33/agentic-awesome-skills

    Use Tree Ring Memory for local-first AI-agent memory lifecycle work: recall, evidence, audit, forgetting, and consolidation without transcript dumping.

    47k GitHub starsUsed in 1 repo~2.2k tokens
    Agent WorkflowsAuto-check passed
  • Deterministic method for placing signature, date, and text fields in a web e-signature composer through a browser automation session, using a fixed signature page, numeric Location panel coordinates…

    276k GitHub stars~2.6k tokensUpdated 4 days ago
    Productivity & AutomationAuto-check passed
  • Builds attack trees that map how an attacker could reach a goal, with AND and OR nodes and cost, time, skill and detection ratings, to find defense gaps.

    40k GitHub starsUsed in 8 repos~623 tokens
    SecurityAuto-check passed

More from hdl-tools/digital-chip-design-agents

All 17 skills in this repo
  • Architecture

    hdl-tools/digital-chip-design-agents

    Microarchitecture exploration, PPA estimation, risk assessment, and architecture sign-off for digital chip design.

    213 GitHub stars~3.7k tokensUpdated 5 days ago
    Auto-check: notes
  • Compiler Toolchain

    hdl-tools/digital-chip-design-agents

    Compiler toolchain development for custom processor ISAs — LLVM/GCC backend, assembler, linker scripts, runtime libraries, and regression validation.

    213 GitHub stars~2.8k tokensUpdated 5 days ago
    Auto-check: notes
  • Dft

    hdl-tools/digital-chip-design-agents

    Design for Test — scan architecture planning, scan insertion, ATPG pattern generation, MBIST for embedded memories, and JTAG boundary scan.

    213 GitHub stars~3.3k tokensUpdated 5 days ago
    Auto-check: notes
  • Embedded Firmware

    hdl-tools/digital-chip-design-agents

    Embedded firmware and device drivers — BSP development, peripheral driver implementation (UART, SPI, I2C, GPIO, DMA, Timer), RTOS integration (FreeRTOS, Zephyr), and system validation.

    213 GitHub stars~2.6k tokensUpdated 5 days ago
    Auto-check: notes
  • Formal Verification

    hdl-tools/digital-chip-design-agents

    Formal property verification (FPV) and logical equivalence checking (LEC).

    213 GitHub stars~3.4k tokensUpdated 5 days ago
    Auto-check: notes
  • Fpga Emulation

    hdl-tools/digital-chip-design-agents

    FPGA prototyping — ASIC-to-FPGA RTL adaptation, multi-FPGA partitioning, synthesis and timing closure on FPGA, hardware bring-up, and software validation on the prototype.

    213 GitHub stars~3.4k tokensUpdated 5 days ago
    Auto-check: notes

Questions about Physical Design

What does Physical Design do?

Full physical design flow — floorplan, placement, clock tree synthesis, routing, timing optimisation, power optimisation, area optimisation, and tape-out sign-off. Physical Design is an agent skill from hdl-tools/digital-chip-design-agents. Full physical design flow — floorplan, placement, clock tree synthesis, routing, timing optimisation, power optimisation, area optimisation, and tape-out sign-off.

When should I use Physical Design?

Physical Design fits situations like: implementing a gate-level netlist through to GDS-II; closing timing and power; performing any individual PD stage analysis.

How do I install Physical Design in Claude Code?

Run `npx skills add hdl-tools/digital-chip-design-agents --skill physical-design -a claude-code`. Or copy the skill folder (plugins/pd/skills/physical-design in hdl-tools/digital-chip-design-agents) into .claude/skills/physical-design in your project. Claude Code loads it when a task matches its description.

How do I install Physical Design in Codex?

Run `npx skills add hdl-tools/digital-chip-design-agents --skill physical-design -a codex`. Or copy the skill folder (plugins/pd/skills/physical-design in hdl-tools/digital-chip-design-agents) into .agents/skills/physical-design in your project. Codex loads it when a task matches its description.

Can I use Physical Design 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 hdl-tools/digital-chip-design-agents --skill physical-design -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/physical-design, .gemini/skills/physical-design, .github/skills/physical-design and .opencode/skills/physical-design in your project.

What does Physical Design need to run?

Going by SKILL.md and its folder, Physical Design needs the command-line tools its instructions call (make and python3). Our summary lists: Python 3. Its frontmatter pre-approves these tools: Read, Write, Bash.

Does Physical Design 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 Physical Design safe to install?

Our automated static check of SKILL.md found notes only (pre-approves every shell command (allowed-tools: bash)), nothing it rates as a warning. It is not a guarantee. Review the folder before installing.

What licence does Physical Design use?

Physical Design is published under the MIT licence (declared in SKILL.md). It allows redistribution, so the full SKILL.md is shown on this page.

How many tokens does Physical Design use?

About 3.8k tokens (SKILL.md is roughly 15k characters). Agents keep only the skill's name and description in context until a task matches; then they load SKILL.md in full.

What are the alternatives to Physical Design?

Skills that share tags, products or a category with Physical Design: More Trees Automation (ComposioHQ/awesome-claude-skills, 77k stars), Physical Address (thedaviddias/Front-End-Checklist, 74k stars), Pierre Trees File Tree (pierrecomputer/pierre, 6.3k stars) and Tree Ring Memory (sickn33/agentic-awesome-skills, 47k stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.

Who maintains Physical Design?

hdl-tools (a GitHub organization) maintains it in hdl-tools/digital-chip-design-agents, which has 213 GitHub stars. The repository holds 17 skills in this directory. The repository was last updated on October 3, 2026.

Source: hdl-tools/digital-chip-design-agents on GitHub. Facts on this page come from the repository at the commit we read; the author's words are quoted as theirs.