p2-arch-design-policy

Define Phase 2 architecture review criteria and hardware candidate evaluation methodology.

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

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Provides a formalized Phase 2 architecture review policy to ensure hardware candidate evaluation, memory and bandwidth feasibility, naming consistency, and convergent review outcomes so that architectural decisions are measurable, auditable, and aligned with upstream requirements.

Core Features & Use Cases

  • Structured Review Criteria: Gate checks for gate count, critical path, SRAM needs, external bandwidth, throughput, and implementation risk.
  • Dynamic Convergence Protocol: Iterative review rounds with mandatory reviewers, rebuttal workflow, convergence metrics, and escalation paths.
  • Memory & Bandwidth Analysis: Classification of local/cross-domain/external memory, latency assumptions, bandwidth_report.json consumption, and mitigation strategies.
  • Compliance & Traceability: OPEN-1* resolution, iron-requirements generation, ambiguity scoring, and automated compliance-checker integration with upstream Phase 1.
  • Artifact Requirements: Templates and required outputs like hw-candidate-review.md, wonder-log.md, per-round review artifacts, and ADRs for key decisions.
  • Use case: Evaluate multiple algorithmic candidates for a codec block, estimate PPA tradeoffs, select a candidate with documented rationale, and record compliance evidence for Phase 2 exit.

Quick Start

Use the p2-arch-design-policy skill to generate a Phase 2 architecture review checklist, classify memory and bandwidth requirements, and produce the initial wonder-log entry for the current design.

Frequently Asked Questions about p2-arch-design-policy

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

FAQPage Schema
What is a Phase 2 architecture review and when do I need it?

A Phase 2 architecture review evaluates hardware candidate selection, memory and bandwidth feasibility, and compliance against upstream Phase 1 requirements. You need it to ensure architectural decisions are measurable, auditable, and aligned before exiting the design phase.

How do I evaluate hardware design candidates for memory and bandwidth feasibility?

Evaluate hardware candidates by classifying local, cross-domain, and external memory, checking latency assumptions, and consuming bandwidth_report.json. This structured criteria also gates gate count, critical path, SRAM needs, throughput, and implementation risk.

What artifacts are required for a Phase 2 architecture compliance check?

Required artifacts include hw-candidate-review.md, wonder-log.md, per-round review artifacts, and ADRs for key decisions. These outputs provide the documented rationale and compliance evidence needed for Phase 2 exit.

Does the architecture review protocol support iterative convergence with rebuttals?

Yes, the dynamic convergence protocol mandates iterative review rounds with mandatory reviewers. It includes a rebuttal workflow, convergence metrics, and defined escalation paths to resolve open requirements and architectural ambiguity.

How do I track open requirements and resolve ambiguity during hardware design reviews?

Track open requirements using the wonder-log.md artifact and resolve them through the OPEN-1* resolution process. The review policy applies ambiguity scoring and automated compliance-checker integration to ensure upstream alignment.