Agent skill

OpenROAD Module Test Adder

by The-OpenROAD-Project in The-OpenROAD-Project/OpenROAD

Adds integration or unit tests to an OpenROAD module: writes the Tcl test, generates golden files and registers it in both CMake and Bazel.

BSD-3-ClauseAuto-check passedTesting & QA

Install OpenROAD Module Test Adder

skills CLI
$ npx skills add The-OpenROAD-Project/OpenROAD --skill add-test -a claude-code

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

GitHub CLI
$ gh skill install The-OpenROAD-Project/OpenROAD add-test --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/The-OpenROAD-Project/OpenROAD.git skills-src && mkdir -p .claude/skills && cp -r skills-src/.agents/skills/add-test .claude/skills/add-test && 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
add-test
GitHub stars
3.2k
Token cost
~1.8k tokens
SKILL.md length
471 words
Files
1
Skills in repo
4
Repo updated
First seen
Licence
BSD-3-Clause

At a glance

Adds integration or unit tests to an OpenROAD module: writes the Tcl test, generates golden files and registers it in both CMake and Bazel.

  • Works in 7 steps: Identify the module and scope → Write the integration test (Tcl) → Generate golden files → …
  • Adding a regression test for a bug fix in an OpenROAD module
  • SKILL.md covers 1. Identify the module and scope, 2. Write the integration test…, 3. Generate golden files and 4. Register in BOTH build…, plus 4 more sections
  • Calls git

What it does

The agent takes a module name such as rsz, drt or gpl plus what to test, studies the module's existing tests to learn its conventions, and writes a Tcl integration test. Existing design data is reused where possible, and new LEF or DEF files are created only for a specific geometry or edge case. Naming follows a fixed pattern: the test script, a golden log with an ok extension, optional golden output files for results such as DEF, and shared test data.

It then runs the test with openroad to produce the golden log and output, and registers the test in both build systems. Bazel registration is flagged as the most common mistake, because a test added only to CMake passes locally but is missing from Bazel CI. In CMake the name goes into the module's or_integration_tests call; in Bazel it goes into the TESTS list that feeds regression_test, and some modules also keep separate PASSFAIL_TESTS or BIG_TESTS lists.

When your agent uses it

  • Adding a regression test for a bug fix in an OpenROAD module
  • Improving test coverage for a module that has missing tests
  • Checking that a new test is registered in both CMake and Bazel
  • Generating the golden log for a new Tcl test

Example prompts

  • “Add a regression test for the buffer insertion bug in rsz.”
  • “Write an integration test for global placement density settings in gpl and register it everywhere.”
  • “My new drt test passes locally but is missing from Bazel CI, so fix the registration.”

Requirements

  • An OpenROAD source checkout with a built openroad binary
  • CMake and Bazel build files in the module's test folder

Workflow steps

7 steps, taken from the step headings in SKILL.md.

  1. Identify the module and scope
  2. Write the integration test (Tcl)
  3. Generate golden files
  4. Register in BOTH build systems
  5. Write unit tests (C++, if applicable)
  6. Run and verify
  7. Format and commit

What it can do on your machine

Read from SKILL.md and the folder at commit 22b7c53. 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

    Shell commands in SKILL.md call:

    • git

    From the folder's file list and the shell code blocks in SKILL.md.

  • Network

    No URLs in SKILL.md. Its commands use git, which can reach the network depending on how they are called.

    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

OpenROAD Module Test Adder loads about 1.8k tokens when it runs. Until then it costs about 152 tokens; SKILL.md has 471 words of instructions outside code blocks.

Always · name and description, kept in context so the agent knows when to use it
~152
When it runs · the whole SKILL.md, loaded when a task matches
~1.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 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); files beside SKILL.md are not scanned.

SKILL.md

The full file from The-OpenROAD-Project/OpenROAD at commit 22b7c53, republished under its BSD-3-Clause licence (© The-OpenROAD-Project). 471 words, ~1,827 tokens.

Download SKILL.mdSave it as .claude/skills/add-test/SKILL.md (or your agent's skills folder).
name
add-test
description
Add integration or unit tests to an OpenROAD module. Handles the complete workflow: writing the Tcl/C++ test, generating golden files, and registering the test in BOTH CMake and Bazel build systems (the most common mistake is forgetting Bazel registration). Use when asked to add tests, improve test coverage, create regression tests, or write unit tests for any OpenROAD module (ant, cts, dpl, drt, gpl, grt, mpl, odb, pad, pdn, psm, rcx, rsz, sta, stt, tap, upf, utl, etc.). Also triggers on: "add test", "write test", "test coverage", "missing tests", "create regression test", "add unit test".
argument-hint
<module> [test-description]

Add Test to OpenROAD Module

You are adding tests for: $ARGUMENTS

1. Identify the module and scope

Parse $ARGUMENTS to determine:

  • Module name (e.g., rsz, drt, gpl)
  • What to test (specific feature, edge case, or general coverage)

Explore existing tests to understand conventions:

bash
ls src/MODULE/test/*.tcl | head -20

Read a representative test for the module's style:

bash
# Good reference for integration test patterns:
cat src/rsz/test/repair_tie12_hier.tcl

2. Write the integration test (Tcl)

Create src/MODULE/test/TEST_NAME.tcl:

tcl
# Brief description of what this test verifies
set test_name TEST_NAME
source "helpers.tcl"

# Read design files
read_lef "TECH.lef"
read_lef "CELLS.lef"
read_def "DESIGN.def"

# ... test operations ...

# Use make_result_file for temporary output
set def_filename "${test_name}.def"
set out_def [make_result_file $def_filename]
write_def $out_def

# Compare against golden file
diff_file ${test_name}.defok $out_def
Test design files

Prefer reusing existing test data in src/MODULE/test/. Only create new LEF/DEF files when testing a specific geometry or edge case that existing files don't cover. Keep test data minimal.

Naming conventions
  • Test files: src/MODULE/test/TEST_NAME.tcl
  • Golden log: src/MODULE/test/TEST_NAME.ok
  • Golden output: src/MODULE/test/TEST_NAME.{defok,vok,spefok,...}
  • Test data: src/MODULE/test/*.{lef,def,lib,sdc,v}

3. Generate golden files

Run the test and capture output:

bash
cd src/MODULE/test

# Run with openroad to generate output
openroad -no_splash -no_init -exit TEST_NAME.tcl > TEST_NAME.ok 2>&1

# Remove the openroad banner from the .ok file if present
# The .ok file should contain only the test's stdout

If the test uses diff_file, also generate the golden output file (e.g., TEST_NAME.defok) by running once and copying the result file.

4. Register in BOTH build systems

This is the most common mistake. Every test must be in both CMake AND Bazel. CMake-only tests silently pass locally but are missing from Bazel CI.

CMake -- src/MODULE/test/CMakeLists.txt

Find the or_integration_tests() call. The first positional argument is the module name, followed by the TESTS keyword and the list:

cmake
or_integration_tests(
  "MODULE"           # <-- module name (e.g. "rsz")
  TESTS
    existing_test1
    existing_test2
    TEST_NAME        # <-- add here
)

Some modules also have a PASSFAIL_TESTS section after TESTS -- add to the appropriate list. Look at the module's existing CMakeLists.txt before editing.

Bazel -- src/MODULE/test/BUILD

The typical pattern is a TESTS list consumed by a list comprehension that calls regression_test() for each name:

python
TESTS = [
    "buffer_ports1",
    "buffer_ports10",
    "buffer_ports11",
    "TEST_NAME",     # <-- add here, in the existing sort order
    # (other tests omitted)
]

[
    regression_test(
        name = test_name,
    )
    for test_name in TESTS
]

Some modules split tests across multiple lists (TESTS, PASSFAIL_TESTS, BIG_TESTS, etc.) and define a combined ALL_TESTS = TESTS + PASSFAIL_TESTS + ... that the comprehension iterates over. Read the existing BUILD to find which list to extend, and insert the new test name in whatever sort order that file already uses (most modules are alphabetical).

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

5. Write unit tests (C++, if applicable)

Prefer C++ unit tests over Tcl for testing internal logic, algorithms, and data structure operations. Use Tcl integration tests for command-level behavior and end-to-end flows.

Test file

Create src/MODULE/test/cpp/TestName.cpp:

cpp
#include "gtest/gtest.h"
#include "odb/db.h"

// Simple test (no fixture)
namespace module {
namespace {

TEST(ModuleTest, TestDescription) {
  // ARRANGE - ACT - ASSERT
  EXPECT_EQ(expected, actual);
}

}  // namespace
}  // namespace module
Using test fixtures

OpenROAD provides a fixture hierarchy for tests that need database or tool setup. Choose the simplest one that covers your needs:

FixtureUse when
tst::FixtureNeed bare dbDatabase + STA, load LEFs manually
tst::Nangate45FixtureNeed pre-loaded Nangate45 tech/lib
tst::Sky130FixtureNeed pre-loaded Sky130 tech/lib
tst::IntegratedFixtureNeed full tool integration (STA, DPL, GRT, RSZ)
cpp
#include "gtest/gtest.h"
#include "tst/nangate45_fixture.h"

class TestFeature : public tst::Nangate45Fixture
{
 protected:
  void SetUp() override { /* additional setup */ }
};

TEST_F(TestFeature, HandlesEdgeCase) {
  // block_, lib_ are available from the fixture
  EXPECT_TRUE(condition);
}
CMake registration -- src/MODULE/test/cpp/CMakeLists.txt
cmake
add_executable(TestName TestName.cpp)
target_link_libraries(TestName
    MODULE_lib
    GTest::gtest
    GTest::gtest_main
    tst
    odb
)
gtest_discover_tests(TestName
    WORKING_DIRECTORY ${CMAKE_CURRENT_SOURCE_DIR}/..
)
add_dependencies(build_and_test TestName)
Bazel registration -- src/MODULE/test/BUILD

Add the cc_test target alongside the existing regression_test entries. Most modules keep C++ tests in the same BUILD file:

python
load("@rules_cc//cc:cc_test.bzl", "cc_test")

cc_test(
    name = "TestName",
    srcs = ["cpp/TestName.cpp"],
    deps = [
        "//src/MODULE",
        "//src/tst",
        "//src/tst:nangate45_fixture",  # if using Nangate45Fixture
        "@googletest//:gtest",
        "@googletest//:gtest_main",
    ],
)

6. Run and verify

./regression is a thin ctest wrapper that filters by module label, so the standard ctest flags apply. Use -R to match a single test by name:

bash
cd src/MODULE/test
./regression -R TEST_NAME

# Verify test is discoverable in both systems
cd ../../../build
ctest -N | grep MODULE.*TEST_NAME

7. Format and commit

bash
# Format any C++ files (NEVER format src/sta/* or *.i files)
clang-format -i <changed-cpp-files>

git add src/MODULE/test/TEST_NAME.tcl \
        src/MODULE/test/TEST_NAME.ok \
        src/MODULE/test/CMakeLists.txt \
        src/MODULE/test/BUILD
git commit -s -m "MODULE: add TEST_NAME test

Test for DESCRIPTION."

Checklist

  • Test runs successfully: ./regression -R TEST_NAME
  • Golden file generated and committed
  • Registered in CMake CMakeLists.txt
  • Registered in Bazel BUILD
  • Test data is minimal (reuse existing files when possible)
  • C++ files formatted with clang-format
  • Commit is signed off (-s)

© The-OpenROAD-Project, BSD-3-Clause. 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 .agents/skills/add-test of The-OpenROAD-Project/OpenROAD.

Open the folder on GitHubat commit 22b7c53

Compare with similar skills

OpenROAD Module Test Adder 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.

OpenROAD Module Test Adder compared with similar skills
SkillStarsUsed inTokensAuto-checkLicenceRepo updated
OpenROAD Module Test Adder this skillThe-OpenROAD-Project/OpenROAD3.2k—~1.8kAutomated safety check: PassBSD-3-Clause
Write Testsgrafana/synthetic-monitoring-app171—~1.2kAutomated safety check: PassAGPL-3.0
Test Specialistailabs-393/ai-labs-claude-skills454—~3.4kAutomated safety check: PassMIT
Memstack Development Test Writercwinvestments/memstack423—~3.7kAutomated safety check: PassProprietary
Test Case ReducerArabelaTso/Skills-4-SE253—~2.5kAutomated safety check: PassApache-2.0
Test Experteinverne/dotfiles121—~2.3kAutomated safety check: PassGPL-3.0

Similar skills

  • Write Tests

    grafana/synthetic-monitoring-app

    Official

    Write Jest integration and unit tests for the Grafana Synthetic Monitoring app using React Testing Library, MSW, and src/test helpers.

    171 GitHub stars~1.2k tokensUpdated today
    Testing & QAAuto-check passed
  • Test Specialist

    ailabs-393/ai-labs-claude-skills

    This skill should be used when writing test cases, fixing bugs, analyzing code for potential issues, or improving test coverage for JavaScript/TypeScript applications.

    454 GitHub stars~3.4k tokensUpdated 11 mo ago
    Testing & QAAuto-check passed
  • Memstack Development Test Writer

    cwinvestments/memstack

    A skill your agent uses when the user says 'write tests', 'add tests', 'test coverage', 'unit tests', 'integration tests', 'component tests', 'mocking', 'edge cases', or needs to generate tests with…

    423 GitHub stars~3.7k tokensUpdated 12 days ago
    Testing & QAAuto-check passed
  • Test Case Reducer

    ArabelaTso/Skills-4-SE

    Automatically reduces bug-triggering test cases to minimal form while preserving the failure.

    253 GitHub stars~2.5k tokensUpdated 1 mo ago
    Testing & QAAuto-check passed
  • Test Expert

    einverne/dotfiles

    Testing methodologies, test-driven development (TDD), unit and integration testing, and testing best practices across multiple frameworks.

    121 GitHub stars~2.3k tokensUpdated 1 mo ago
    Testing & QAAuto-check passed
  • Scenario Testing

    aiskillstore/marketplace

    This skill should be used when writing tests, validating features, or needing to verify code works.

    430 GitHub starsUsed in 1 repo~830 tokens
    Testing & QAAuto-check passed

More from The-OpenROAD-Project/OpenROAD

  • OpenROAD Bug Fixer

    The-OpenROAD-Project/OpenROAD

    Fixes an OpenROAD bug from a GitHub issue or error code: finds the root cause, implements the fix, adds a regression test and prepares a signed-off commit.

    3.2k GitHub stars~784 tokensUpdated today
    Auto-check passed
  • OpenROAD PR Review

    The-OpenROAD-Project/OpenROAD

    Reviews an OpenROAD pull request in the project's priority order and prints draft review notes for a human reviewer to inspect and post.

    3.2k GitHub stars~1.4k tokensUpdated today
    Auto-check passed
  • OpenROAD Issue Triage

    The-OpenROAD-Project/OpenROAD

    Reproduces an OpenROAD GitHub bug from an attached tarball and shrinks the failing design with whittle.py so maintainers get a minimal test case.

    3.2k GitHub stars~842 tokensUpdated today
    Auto-check passed

Works with

Categories

Questions about OpenROAD Module Test Adder

What does OpenROAD Module Test Adder do?

Adds integration or unit tests to an OpenROAD module: writes the Tcl test, generates golden files and registers it in both CMake and Bazel. The agent takes a module name such as rsz, drt or gpl plus what to test, studies the module's existing tests to learn its conventions, and writes a Tcl integration test. Existing design data is reused where possible, and new LEF or DEF files are created only for a specific geometry or edge case.

When should I use OpenROAD Module Test Adder?

OpenROAD Module Test Adder fits situations like: adding a regression test for a bug fix in an OpenROAD module; improving test coverage for a module that has missing tests; checking that a new test is registered in both CMake and Bazel; generating the golden log for a new Tcl test.

How do I install OpenROAD Module Test Adder in Claude Code?

Run `npx skills add The-OpenROAD-Project/OpenROAD --skill add-test -a claude-code`. Or copy the skill folder (.agents/skills/add-test in The-OpenROAD-Project/OpenROAD) into .claude/skills/add-test in your project. Claude Code loads it when a task matches its description.

How do I install OpenROAD Module Test Adder in Codex?

Run `npx skills add The-OpenROAD-Project/OpenROAD --skill add-test -a codex`. Or copy the skill folder (.agents/skills/add-test in The-OpenROAD-Project/OpenROAD) into .agents/skills/add-test in your project. Codex loads it when a task matches its description.

Can I use OpenROAD Module Test Adder 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 The-OpenROAD-Project/OpenROAD --skill add-test -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/add-test, .gemini/skills/add-test, .github/skills/add-test and .opencode/skills/add-test in your project.

What does OpenROAD Module Test Adder need to run?

Going by SKILL.md and its folder, OpenROAD Module Test Adder needs the command-line tools its instructions call (git). Our summary lists: An OpenROAD source checkout with a built openroad binary; CMake and Bazel build files in the module's test folder.

Does OpenROAD Module Test Adder access the network?

SKILL.md contains no URLs. Its commands use git, which can reach the network depending on how they are called. This is read from the text; nothing was executed.

Is OpenROAD Module Test Adder 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. Review the folder before installing.

What licence does OpenROAD Module Test Adder use?

OpenROAD Module Test Adder is published under the BSD-3-Clause licence (the repository's licence). It allows redistribution, so the full SKILL.md is shown on this page.

How many tokens does OpenROAD Module Test Adder use?

About 1.8k tokens (SKILL.md is roughly 7.3k 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 OpenROAD Module Test Adder?

Skills that share tags, products or a category with OpenROAD Module Test Adder: Write Tests (grafana/synthetic-monitoring-app, 171 stars), Test Specialist (ailabs-393/ai-labs-claude-skills, 454 stars), Memstack Development Test Writer (cwinvestments/memstack, 423 stars) and Test Case Reducer (ArabelaTso/Skills-4-SE, 253 stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.

Who maintains OpenROAD Module Test Adder?

The-OpenROAD-Project (a GitHub organization) maintains it in The-OpenROAD-Project/OpenROAD, which has 3,159 GitHub stars. The repository holds 4 skills in this directory. The repository was last updated on October 9, 2026.

Source: The-OpenROAD-Project/OpenROAD on GitHub. Facts on this page come from the repository at the commit we read; the author's words are quoted as theirs.