| name | architecture-review |
| version | 1.2.0 |
| description | Multi-role architecture review (a.k.a. HC-Party) with weighted decision matrices, conflict resolution, and cost estimation. |
| category | software-development |
| source | hermes-cortex (ported from AgentKore) |
| author | Hermes Agent |
| license | MIT |
| platforms | ["linux","macos","windows"] |
| metadata | {"hermes":{"tags":["architecture","design-review","decision-matrix","cost-estimation","conflict-resolution","party","hc-party"],"aliases":["hc-party","party"],"trigger_phrases":["architecture review","design review","evaluate approach","hc party","arch party"],"related_skills":["plan","writing-plans","spike","change-test-loop","codebase-design","root-cause-debugging"]}} |
architecture-review: Architecture Review
Overview
A structured, multi-role architecture review process designed for complex design decisions (formerly known as HC-Party). It assembles a panel of six expert personas, each evaluating the architecture from their unique vantage point using a weighted decision matrix. Conflicts are surfaced and resolved systematically, and cost estimates ground every recommendation in reality.
Origin: Ported from AgentKore into the Hermes Cortex skill set.
When to Trigger
This skill activates when the user says one of the following phrases (or an equivalent):
- "architecture review"
- "design review"
- "evaluate approach"
- "arch review"
- "compare architectures"
- "which approach should I choose"
- "trade-off analysis"
If the user asks for a quick opinion on a small design decision, they might not need a full Party. Use your judgment — when the decision is costly, complex, or irreversible, run the party.
How It Works
The review runs in five phases:
Phase 1: Scoping
Before roles deliberate, establish the bounds of the review.
- What system or component is under review?
- What is the primary goal? (performance, maintainability, cost, time-to-market, security, etc.)
- What are the constraints? (team size, budget, timeline, compliance, existing infra)
- How many approaches/options are being compared? (generally 2–4)
- Any non-negotiables (e.g., must run on AWS, must be PCI-compliant, must use PostgreSQL)
Phase 2: Role Panel Assembly
Six roles are activated. Each role receives the scope document and any proposed approaches, then produces an independent evaluation.
| # | Role | Focus Area | Key Questions |
|---|
| 1 | Architect | System structure, scalability, modularity, tech fit | Is this architecture coherent? Does it scale? Are there coupling issues? |
| 2 | Security Engineer | Threat model, vulnerabilities, compliance, data protection | What attack surfaces exist? Are secrets handled safely? Is this auditable? |
| 3 | SRE | Reliability, observability, deployment, incident response |
