Skip to content

Add design-pcb-layout interactive template#189

Merged
Alan-Jowett merged 6 commits intomicrosoft:mainfrom
Alan-Jowett:add-design-pcb-layout-template
Apr 6, 2026
Merged

Add design-pcb-layout interactive template#189
Alan-Jowett merged 6 commits intomicrosoft:mainfrom
Alan-Jowett:add-design-pcb-layout-template

Conversation

@Alan-Jowett
Copy link
Copy Markdown
Member

Summary

Add a \design-pcb-layout\ interactive template that guides users through complete PCB layout — from requirements gathering through placement, automated routing (FreeRouting), and DRC validation. This is Step 6 of 9 in the hardware design workflow.

New Components

Type Name Path Description
Template (interactive) design-pcb-layout templates/design-pcb-layout.md PCB layout with automated routing and schematic feedback loop

Design Decisions

  • Schematic feedback loop: Phase 7 explicitly handles the case where layout reveals issues requiring schematic changes (different package, bus split, additional decoupling). The user updates the schematic, runs Update PCB from Schematic, and returns to Phase 3.
  • **\ ormat: null**: Interactive template pattern, consistent with \design-schematic\ and \�ngineering-workflow.
  • Input contract: Requires a populated .kicad_pcb\ from the schematic (not a blank board).
  • PASS/FAIL verdict: Layout audit uses explicit verdict (learned from \design-schematic\ PR review).
  • Python script with configuration section: Component positions are in a user-adjustable config block at the top.
  • Max 5 DRC iterations: Automated fix loop before escalating to user.

Checklist

  • All files have SPDX license headers
  • YAML frontmatter is valid and complete
  • Component names match file names (kebab-case)
  • manifest.yaml updated
  • Template has input/output contracts
  • Template has a quality checklist section
  • Template references its persona, protocols correctly
  • CI validation passes (\python tests/validate-manifest.py)

Add an interactive template that guides users through complete PCB
layout — from layout requirements through placement, automated
routing, and DRC validation. This is Step 6 of 9 in the hardware
design workflow.

The template composes 4 protocols into an 8-phase workflow:
1. Layout requirements gathering (interactive — board size,
   connector edges, mechanical constraints)
2. Board definition and design rules (stackup, net classes, fab
   minimums)
3. Component placement (Python pcbnew script generation)
4. User review of placement (gate — loop back if REVISE)
5. Routing and DRC loop (FreeRouting + kicad-cli DRC, max 5
   iterations)
6. Layout audit (layout-design-review protocol, PASS/FAIL verdict)
7. User review of layout (gate — loop back to 3, 5, or SCHEMATIC
   FEEDBACK)
8. Deliver artifacts (routed .kicad_pcb, Python script, DRC report)

Key design decisions:
- Schematic feedback loop: Phase 7 can trigger schematic revisions
  when layout reveals issues (different package needed, bus split,
  additional decoupling). User updates schematic, runs Update PCB,
  then returns to Phase 3.
- format: null (interactive template pattern, consistent with
  design-schematic and engineering-workflow)
- Input contract requires a populated .kicad_pcb from schematic
- Python script with configuration section for user adjustability

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Copilot AI review requested due to automatic review settings April 6, 2026 20:16
Copy link
Copy Markdown
Contributor

Copilot AI left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

Adds a new interactive hardware-design template that guides users through end-to-end PCB layout in KiCad, composing the existing pcb-layout-design (generation) and layout-design-review (audit) protocols as the next step after design-schematic.

Changes:

  • Introduces templates/design-pcb-layout.md interactive workflow (requirements → placement → autorouting/DRC → audit → deliverables) including a schematic-feedback loop.
  • Registers the new template in the hardware-design category in manifest.yaml.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.

File Description
templates/design-pcb-layout.md New interactive PCB layout template composing routing + DRC loop and an audit gate.
manifest.yaml Adds the new template entry under templates.hardware-design.

1. Split ambiguous schematic_path into separate schematic_path and
   board_path params so scripts have concrete file paths.

2. Added Phase 1 (Input Validation) applying pcb-layout-design
   protocol Phase 1 — verifies ERC, footprint assignments, board
   population, fab service. Prevents starting layout on an
   incomplete board.

3. Renumbered all phases (1-9) and updated all internal cross-
   references in transition rules to match.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Copy link
Copy Markdown
Contributor

Copilot AI left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.

1. Phase 1: Added component footprint inventory step (protocol
   Phase 1 item 2) which was missing. Covers footprint confirmation,
   physical dimensions, mounting type, and layout carry-forward
   notes.

2. Phase 7: Added findings summary step (protocol Phase 7) which
   was omitted. Documents each finding with severity classification
   and produces a coverage summary. PASS/FAIL verdict now gates on
   Critical/High findings specifically rather than vague 'blocking
   issues'.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Copy link
Copy Markdown
Contributor

Copilot AI left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.

1. Phase 4 cited 'pcb-layout-design protocol Phases 5-7' but only
   covers placement (Phase 5) and script generation (Phase 7).
   Routing strategy (Phase 6) is applied in the template's Phase 6.
   Fixed reference to cite Phases 5 and 7 specifically.

2. Schematic feedback loop returned to Phase 4 but should return to
   Phase 3 (Board Definition) since package/footprint changes from
   schematic revisions may affect board dimensions, stackup, or
   design rules.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Copy link
Copy Markdown
Contributor

Copilot AI left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

Copilot reviewed 2 out of 2 changed files in this pull request and generated 3 comments.

1. Updated applicable_to on pcb-layout-design (was []) and
   layout-design-review (was [review-layout]) to include
   design-pcb-layout, per CONTRIBUTING.md convention that
   applicable_to lists templates that always include the protocol.
   Removed standalone composition note from pcb-layout-design.

2. Separated template-specific PASS/FAIL verdict gate from the
   layout-design-review protocol steps. The verdict is a template
   addition, not part of the protocol itself.

3. Quality checklist items for USB differential pairs and antenna
   keepout zones were unconditional but not all boards have these.
   Added '(if any)' / '(if used)' qualifiers matching the style
   used in review-layout.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Copy link
Copy Markdown
Contributor

Copilot AI left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

Copilot reviewed 4 out of 4 changed files in this pull request and generated 2 comments.

1. Phase 6 skipped protocol Phase 6 (Routing Strategy) — pre-routing
   critical nets, autorouter config, and ground/power strategy. Added
   as the first step before automated routing. Protocol reference
   updated to 'Phases 6, 8-9'.

2. DRC automated fix loop allowed placement changes without user
   approval, bypassing the Phase 5 gate. Scoped to routing and
   design-rule changes only. Placement changes now route back
   through Phase 4 -> Phase 5 for user re-approval.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
@Alan-Jowett Alan-Jowett merged commit 0b7f308 into microsoft:main Apr 6, 2026
3 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants