pr-architecture-check

You perform an advisory architecture review of a pull request against the project's documented architecture constraints. Your output is informational only — it helps contributors and reviewers spot structural issues early.

This check is advisory only — not a merge gate. Per FND-003 §6.4: "AI belongs in the development loop, not the merge gate." Human reviewers make the final call. This skill does not block merges, does not approve or request changes, and does not modify labels.

---

Invocation

arch-check #1234
architecture check #1234

---

Workflow

Step 1 — Fetch PR data

Run these in parallel:

gh pr diff <N> --repo zeroclaw-labs/zeroclaw

gh pr view <N> --repo zeroclaw-labs/zeroclaw --json files,title,baseRefName,labels,number

Step 2 — Load architecture references

Always load (unconditionally):

• AGENTS.md — repository map, core constraints, risk tiers, anti-patterns
• docs/book/src/foundations/fnd-001-intentional-architecture.md — the canonical architecture RFC: dependency direction rule, crate responsibilities, two-layer model, phased roadmap

Load conditionally based on files changed:

Files touched	Also load
crates/zeroclaw-api/	Extension examples: docs/book/src/developing/extension-examples.md
crates/zeroclaw-runtime/	FND-001 §Phase 2 (runtime extraction)
crates/zeroclaw-gateway/	FND-001 §Phase 3 (gateway separation)
crates/zeroclaw-plugins/	FND-001 §Phase 4 (plugin platform)
crates/zeroclaw-channels/ or crates/zeroclaw-tools/	Extension examples doc
crates/zeroclaw-config/ or crates/zeroclaw-macros/	Config schema conventions in AGENTS.md
.github/workflows/	FND-003 governance, CI risk tier (high risk per AGENTS.md)

Step 3 — Analyze

Apply the full checklist from references/arch-checklist.md. For each category, determine one of:

• Pass — no issues found
• Advisory — potential concern worth reviewer attention
• Flag — likely violation of a documented constraint

Step 4 — Write artifact

Write the analysis to tmp/arch-review-<N>.md with this structure:

# Architecture Review — PR #<N>: <title>

> Advisory only — not a merge gate (FND-003 §6.4)

## Summary
<1-3 sentence overview of architectural impact>

## Findings

### Dependency Direction
<pass/advisory/flag + explanation>

### Trait Boundary Compliance
<pass/advisory/flag + explanation>

### Extension Pattern Conformance
<pass/advisory/flag + explanation>

### Crate Placement
<pass/advisory/flag + explanation>

### Core Constraints
<pass/advisory/flag per constraint, only list those relevant to the diff>

## Files Analyzed
<list of files from the diff>

Step 5 — Show the artifact and wait for approval

The artifact is generated advisory output. Do not post it automatically. Show it to the human first and get explicit approval, exactly as the PR-review, PR-submission, and issue-filing skills do before any public-state mutation.

1. Show the human the generated artifact — prefer a link to tmp/arch-review-<N>.md plus a short summary of the findings; if the full text needs to be inline, paste it as regular text rather than a fenced block.
2. Ask the reviewer to review it and confirm before anything is posted, for example: "Here's the advisory architecture review for #<N>. Review it and say 'post' to comment it on the PR, or tell me what to change." Iterate on edits until they approve.
3. Wait for explicit approval. Do not run gh pr comment until the human has approved posting. If they decline, leave the artifact in tmp/ and stop — posting is optional and reviewer-owned.

Step 6 — Post advisory comment (only after approval)

Once, and only once, the human has explicitly approved, post the artifact as a PR comment. The comment must include the advisory header.

gh pr comment <N> --repo zeroclaw-labs/zeroclaw \
  --body-file tmp/arch-review-<N>.md

Step 7 — Label policy

This skill does not add, remove, or modify any labels. Label management is the responsibility of triage and review skills.

---

Execution Rules

1. Always load AGENTS.md and FND-001. These are the authoritative architecture references. Do not skip them.
2. Always write to tmp/arch-review-<N>.md before posting. The artifact is consumed by github-pr-review-session if it exists.
3. Always show the artifact to the human and wait for explicit approval before posting. Never run gh pr comment automatically. Posting is optional and reviewer-owned — same human-approval checkpoint the PR-review, PR-submission, and issue-filing skills use before any public-state mutation. If the reviewer declines, leave the artifact in tmp/ and stop.
4. Always include the advisory header in the posted comment and the artifact file. Per FND-003 §6.4, this output is advisory only.
5. Never approve, request changes, or use gh pr review. This skill posts a comment, not a formal review verdict.
6. Never modify labels. No label additions, removals, or changes.
7. Never block a merge. If the analysis finds issues, they are reported as advisory findings for the human reviewer to evaluate.
8. Be specific. Reference the exact file, line range, crate, and constraint. Vague findings waste reviewer time.
9. Skip irrelevant checks. If a PR only touches docs, do not flag dependency direction. Only report checks relevant to the diff.