rtl-block-interface-policy

Enforce cross-block interface policies and timing contracts for RTL block-parallel development.

43|9|Updated Feb 25, 2026
One-click install
npx skills add https://github.com/babyworm/rtl-agent-team --skill rtl-block-interface-policy
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: rtl-block-interface-policy
Source: https://github.com/babyworm/rtl-agent-team/tree/main/skills/rtl-block-interface-policy
Command: npx skills add https://github.com/babyworm/rtl-agent-team --skill rtl-block-interface-policy

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Prevents interface drift, integration breakage, and timing mismatches when multiple RTL blocks are developed in parallel by defining clear, enforceable interface rules and a verification workflow for Phase 2–4 block-parallel projects.

Core Features & Use Cases

  • Defines file naming conventions and a shared package location for cross-block interface definitions.
  • Specifies a required timing contract format to be embedded in each interface and locks timing during microarchitecture work.
  • Declares which interface artifacts are frozen at Phase 2 exit and provides a hash-based verification command to detect freeze violations at merge time.
  • Establishes valid/ready handshake, backpressure, and multi-beat transfer rules plus a multi-step freeze-violation escalation protocol involving worker, coordinator, and leader roles.
  • Use case: a block worker detects a needed interface change during Phase 4, automatically verifies the freeze, and follows the escalation protocol to request a coordinated change.

Quick Start

Use the rtl-block-interface-policy skill to verify the Phase 2 interface freeze and report any freeze violations to the coordinator.

Frequently Asked Questions about rtl-block-interface-policy

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I prevent RTL interface drift during parallel block development?

To prevent RTL interface drift during parallel block development, enforce frozen interface contracts using hash-based verification at merge points and strict naming conventions for shared package files. This locks timing and interface definitions across Phase 2 through Phase 4 workflows.

What is a timing contract in RTL design and when is it needed?

A timing contract in RTL design is an embedded block specifying timing requirements within an interface file. It is needed during Phase 2 through Phase 4 parallel block development to lock microarchitecture timing and prevent integration mismatches at merge points.

How do I verify a frozen RTL interface at merge time?

Verify a frozen RTL interface at merge time by running a hash-based verification command that detects freeze violations. This checks shared interface artifacts against their declared Phase 2 exit state to ensure no unauthorized changes occurred during parallel development.

How do I handle needed interface changes after an RTL freeze is in place?

Handle needed interface changes after an RTL freeze by following a multi-step escalation protocol involving worker, coordinator, and leader roles. A block worker detects the needed change during Phase 4 and requests a coordinated update through this defined hierarchy.

Does this interface policy define valid-ready handshake and backpressure rules?

Yes, the interface policy defines valid-ready handshake, backpressure, and multi-beat transfer rules. It establishes these protocols alongside naming conventions and timing contract formats to ensure robust cross-block communication in parallel RTL development.