القائمة
Multi-role architecture review (a.k.a. HC-Party) with weighted decision matrices, conflict resolution, and cost estimation.
يُحدَّد Prompt الذي يراجع المصدر أولًا بشكل افتراضي. يمكنك التبديل إلى أمر مباشر أو تنزيل نسخة محلية.
اقرأ SKILL.md وأي ملفات مرافقة يعرضها SkillsMP قبل أن تقرر التثبيت.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
يتجاوز الأمر المباشر Prompt المخصّص للمراجعة. افحص المصدر قبل تشغيله.
npx skills add https://github.com/lukemcqueen/hermes-cortex --skill architecture-reviewيبقى الأمر في سطر واحد. مرّر أفقيًا لمراجعته كاملًا قبل النسخ.
تفضّل نسخة محلية؟ نزّل الملفات المتاحة حاليًا لدى SkillsMP.
Cross-server agent health monitoring using binary status vectors — deploy health endpoints on each agent, poll from orchestrator, alert on state transitions.
Wire a self-hosted Langfuse instance to Hermes Agent — generate API keys, configure env vars, enable the bundled plugin, install SDK, and verify traces flow.
Use before enforcement code changes or shared-repo commits.
استنادا إلى تصنيف SOC المهني
عرض SKILL.md
| 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"]}} |
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.
This skill activates when the user says one of the following phrases (or an equivalent):
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.
The review runs in five phases:
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)
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 |
| Can this be operated 24/7? What's the blast radius of a failure? How do we debug it? |
| 4 | Domain Expert | Business logic, domain model correctness, edge cases | Does this model the real-world domain correctly? What edge cases are missed? |
| 5 | Product | User value, roadmap alignment, delivery timeline, trade-offs | Does this ship value faster? What's the MVP? What's the opportunity cost? |
| 6 | QA | Testability, risk areas, integration strategy, regression coverage | How do we verify correctness? What's hard to test? What's the test pyramid? |
Each role produces a structured output:
All scores are assembled into a weighted matrix. The Architect role drives this phase.
Default weights (can be adjusted per review):
| Criteria | Default Weight |
|---|---|
| Architectural soundness | 20% |
| Security posture | 20% |
| Operational reliability | 15% |
| Domain correctness | 15% |
| Product & business value | 15% |
| Testability & quality | 15% |
Matrix format:
| Approach | Architect (20%) | Security (20%) | SRE (15%) | Domain (15%) | Product (15%) | QA (15%) | Weighted Total |
|----------|----------------|----------------|-----------|--------------|---------------|----------|---------------|
| Option A | 8 | 6 | 7 | 9 | 8 | 7 | 7.45 |
| Option B | 6 | 9 | 8 | 6 | 7 | 8 | 7.20 |
Weighted Total = Σ (score × weight). The matrix makes trade-offs explicit and prevents any single perspective from dominating.
When roles disagree sharply (score gap ≥ 3 on the same approach), a conflict resolution protocol is triggered:
Conflict resolution rules:
Every recommendation must include three cost axes:
| Axis | Description | Example Output |
|---|---|---|
| Dev Effort | Engineering hours to build | "~6 engineer-weeks (240 hours) with 2 developers" |
| Infra Cost | Ongoing operational cost | "~$400/mo on AWS (ECS + RDS + Redis + ALB)" |
| Maintenance Burden | Ongoing maintenance overhead | "~4 hours/week for updates, monitoring, security patching" |
Cost estimates should be bracketed (optimistic / likely / pessimistic) and include confidence level.
After all five phases, produce a final summary like this:
# Architecture Review — Review: [System/Decision Name]
## Recommendation
**Option [X]** — [1-sentence recommendation]
## Weighted Scores
[Matrix table]
## Key Tensions
- [Conflict 1 and resolution]
- [Conflict 2 and resolution]
## Cost Estimate
| Approach | Dev Effort | Infra/Month | Maintenance |
|----------|-----------|-------------|-------------|
| Option A | 4-6 weeks | ~$300-500 | 3-5 hrs/wk |
| Option B | 8-12 weeks| ~$200-400 | 6-8 hrs/wk |
## Action Items
1. [Item]
2. [Item]
3. [Item]
Persist the review as a durable markdown document in the repo, committed so the whole fleet benefits. Route by review type:
| Review type | Output path | Example |
|---|---|---|
| Decision party (choosing between approaches, ADR-style) | docs/design/YYYY-MM-DD-<decision-slug>.md | docs/design/2026-08-06-task-workflow-decision.md |
| Elicitation-combined party (scoping/requirements discovery) | docs/elicit/YYYY-MM-DD_<feature>-party.md | docs/elicit/2026-06-29_offline-code-party.md |
If the runtime provides a specific target path, use that exact path; otherwise
create the timestamped filename above under the appropriate docs/ subdir.
Scope: Choosing between a modular monolith and microservices for a new billing system.
Option A: Modular monolith (shared database, API modules) Option B: Event-driven microservices (per-service DBs, message broker)
After scoring by all 6 roles:
| Approach | Architect (20%) | Security (20%) | SRE (15%) | Domain (15%) | Product (15%) | QA (15%) | Weighted |
|-----------|----------------|----------------|-----------|--------------|---------------|----------|----------|
| Monolith | 9 | 8 | 9 | 9 | 9 | 8 | 8.65 |
| Microserv | 6 | 7 | 5 | 8 | 5 | 6 | 6.20 |
Key Tension: SRE (9 vs 5) and Product (9 vs 5) strongly favor the monolith — operational complexity and slower delivery are dealbreakers for microservices given the 2-person team.
Cost Estimate:
| Approach | Dev Effort | Infra/Month | Maintenance |
|---|---|---|---|
| Monolith | 3-5 weeks | ~$200-300 | 2 hrs/wk |
| Microserv | 10-16 weeks | ~$600-1000 | 8-12 hrs/wk |
Recommendation: Modular monolith. Matches team size, reduces operational burden, delivers faster. Evaluate microservices only if traffic exceeds 10K req/s on the monolith.