Enhance /review-pr with software architecture review

Add software architecture review as a standard part of PR review process:
- Reference software-architecture skill for patterns and checklists
- Spawn software-architect agent for architectural analysis
- Add checks for pattern consistency, dependency direction, breaking changes,
  module boundaries, and error handling
- Structure review output with separate Code Review and Architecture Review
  sections

Closes #60

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>

commands/review-pr.md

@@ -1,20 +1,67 @@
 ---
-description: Review a Gitea pull request. Fetches PR details, diff, and comments.
+description: Review a Gitea pull request. Fetches PR details, diff, and comments. Includes both code review and software architecture review.
 argument-hint: <pr-number>
 ---
 
 # Review PR #$1
 
 @~/.claude/skills/gitea/SKILL.md
+@~/.claude/skills/software-architecture/SKILL.md
+
+## 1. Gather Information
 
 1. **View PR details** with `--comments` flag to see description, metadata, and discussion
-2. **Get the diff** to review the changes
+2. **Get the diff** to review the changes:
+   ```bash
+   tea pulls checkout <number>
+   git diff main...HEAD
+   ```
+
+## 2. Code Review
 
 Review the changes and provide feedback on:
-- Code quality
-- Potential bugs
+- Code quality and style
+- Potential bugs or logic errors
 - Test coverage
-- Documentation
+- Documentation updates
+
+## 3. Software Architecture Review
+
+Spawn the software-architect agent for architectural analysis:
+
+```
+Use the Task tool to spawn the software-architect agent:
+@~/.claude/agents/software-architect/agent.md
+
+Provide context:
+ANALYSIS_TYPE: pr-review
+TARGET: <pr-number>
+CONTEXT: [Include the PR diff and description]
+```
+
+The architecture review checks:
+- **Pattern consistency**: Changes follow existing codebase patterns
+- **Dependency direction**: Dependencies flow correctly (toward domain layer)
+- **Breaking changes**: API changes are flagged and justified
+- **Module boundaries**: Changes respect existing package boundaries
+- **Error handling**: Errors wrapped with context, proper error types used
+
+## 4. Present Findings
+
+Structure the review with two sections:
+
+### Code Review
+- Quality, bugs, style issues
+- Test coverage gaps
+- Documentation needs
+
+### Architecture Review
+- Summary of architectural concerns from agent
+- Pattern violations or anti-patterns detected
+- Dependency or boundary issues
+- Breaking change assessment
+
+## 5. User Actions
 
 Ask the user what action to take:
 - **Merge**: Post review summary as comment, then merge with rebase style