1. Architecture Design and Requirement Audit Workflow

This workflow covers the design review, requirement consistency checks, spec extraction and HAL documentation that precede verification work. Automated processing and static review of the original design documents produce an unambiguous specification before any verification environment or test plan is written. Separate review skills exist for the IP level and the SoC level.

---

Orchestration Skill: ic-audit-design-auto

ic-audit-design-auto orchestrates the review pipeline for this stage. It invokes ic-audit-prd-spec and then ic-audit-spec, pausing after each review stage to wait for user confirmation before continuing.

---

Skills in Detail

1. ic-docx2md — Word / PDF to Markdown Conversion

• What it does: converts a .docx or .pdf document into Markdown, extracts the embedded images and calls a vision model to describe their content, filtering out icons, rules and other uninformative graphics by size.
• Input: .docx or .pdf (PDFs go through pdf2md.py and produce the same output format).
• Output: the specified .md file plus a directory of extracted images.
• Usage: /ic-docx2md <input.docx|input.pdf> <output.md>

---

2. ic-audit-spec — Spec Quality Review

• What it does: runs an FSM logic review followed by an overall spec quality review. It scans for undefined exception transitions, deadlock states, uninitialized reset behavior and ambiguous wording.
• Input: a design specification in Markdown (.md).
• Output: two structured Markdown reports — an FSM logic review report and a spec quality review report.

---

3. ic-audit-prd-spec — PRD to Spec Consistency Check

• What it does: treats the product requirements document as the baseline and checks each IP requirement against the design spec, flagging missing features, register width mismatches and conflicting parameters.
• Input: the PRD (.md) and the design spec (.md).
• Output: a structured Markdown requirement verification report.

---

3b. ic-audit-soc-spec — SoC-Level Spec Quality Review

• What it does: checks, from three verification angles — IP level, connection level and system level — whether the SoC specification supplies the information verification needs. The question is not "is this document well written"; that is general document nitpicking, and on a specification of several hundred pages it produces a list nobody can act on.
• Input: $0 the SoC specification (.md); $1 a chip register description (.svd / IP-XACT .xml, optional); $2 the report output directory (optional).
• Output: three Markdown review reports, one per verification angle.
• Register-degraded mode: a missing $1 does not stop the review, but checkpoints marked "primary source A" lose their only second source; all three reports state that cost plainly at the top.
• Conflicts are not adjudicated: where the spec and the register description disagree, the report marks ⚠️ and lists both locations for a human to judge.

---

3c. ic-audit-soc-prd-spec — SoC-Level Requirement Verification

• What it does: takes the SoC PRD as the baseline and verifies, requirement by requirement, whether each system-level requirement is realized in the SoC integration spec and the chip register description. The question is not "did a given IP do it" — that belongs to the IP-level review, ic-audit-prd-spec.
• Input: $0 the SoC integration spec (.md); $1 the SoC PRD (.yaml); $2 a chip register description (optional); $3 the output path (optional).
• Output: soc_review_result.md.
• Sanity checks: swapped arguments ($0 is a .yaml, or $1 is a .md) prompt for confirmation, and a PRD whose scope is ip prompts you to use ic-audit-prd-spec instead.

---

4. ic-gen-hal — Hardware Abstraction Layer Documentation

• What it does: parses the IP spec (Markdown) and the register description file (.xml) and generates hardware abstraction layer documentation.
• Input: the IP spec (.md) and the register definition file (.xml).
• Output: HAL documentation (.md).

---

5. ic-audit-design-auto — Design Review Pipeline

• What it does: automates the design review pipeline by invoking ic-audit-prd-spec for PRD verification and then ic-audit-spec for spec quality and FSM review. It pauses after each stage so the results can be confirmed before execution continues.