nw-sar-critique-dimensions
Architecture quality critique dimensions for peer review. Load when performing architecture document reviews.
Best use case
nw-sar-critique-dimensions is best used when you need a repeatable AI agent workflow instead of a one-off prompt.
Architecture quality critique dimensions for peer review. Load when performing architecture document reviews.
Teams using nw-sar-critique-dimensions should expect a more consistent output, faster repeated execution, less prompt rewriting.
When to use this skill
- You want a reusable workflow that can be run more than once with consistent structure.
When not to use this skill
- You only need a quick one-off answer and do not need a reusable workflow.
- You cannot install or maintain the underlying files, dependencies, or repository context.
Installation
Claude Code / Cursor / Codex
Manual Installation
- Download SKILL.md from GitHub
- Place it in
.claude/skills/nw-sar-critique-dimensions/SKILL.mdinside your project - Restart your AI agent — it will auto-discover the skill
How nw-sar-critique-dimensions Compares
| Feature / Agent | nw-sar-critique-dimensions | Standard Approach |
|---|---|---|
| Platform Support | Not specified | Limited / Varies |
| Context Awareness | High | Baseline |
| Installation Complexity | Unknown | N/A |
Frequently Asked Questions
What does this skill do?
Architecture quality critique dimensions for peer review. Load when performing architecture document reviews.
Where can I find the source code?
You can find the source code on GitHub using the link provided at the top of the page.
SKILL.md Source
# Architecture Quality Critique Dimensions
## Dimension 1: Architectural Bias Detection
### Technology Preference Bias
Pattern: tech chosen by preference, not requirements. Detection: ADR lacks comparison matrix, choice not mapped to requirements, justified only as "best practice." Severity: HIGH.
### Resume-Driven Development
Pattern: complex/trendy tech without requirement justification. Examples: microservices for 3-person team, Kafka for 100 req/day, service mesh without complexity. Detection: complexity exceeds team size/requirements, tech adds resume value not solves problem. Severity: CRITICAL.
### Latest Technology Bias
Pattern: unproven tech (<6 months, small community) for production. Detection: check maturity, community, LTS, fallback plan. Severity: HIGH.
## Dimension 2: ADR Quality Validation
### Missing Context
ADR lacks business problem, technical constraints, or quality attribute requirements. Future maintainers cannot validate. Severity: HIGH.
### Missing Alternatives Analysis
No alternatives (min 2 required). Each must be evaluated against requirements with rejection rationale. Severity: HIGH.
### Missing Consequences
Omits positive/negative consequences and trade-offs. Quality attribute impact not analyzed. Severity: MEDIUM.
## Dimension 3: Completeness Validation
### Missing Quality Attributes
Architecture doesn't address required attributes. Verify: performance (latency, throughput) | scalability | security (auth, data protection) | maintainability (modularity, testability) | reliability (fault tolerance, recovery) | observability (logging, monitoring, alerting). Severity: CRITICAL.
### Missing Performance Architecture
Performance requirements exist but no optimization strategy (caching, indexing, rate limiting, CDN). Severity: CRITICAL.
## Dimension 4: Implementation Feasibility
### Team Capability Mismatch
Requires expertise team lacks. Verify learning curve reasonable, training plan exists. Severity: HIGH.
### Budget Constraints
Infrastructure costs exceed budget. Verify cost estimate exists and aligns. Severity: HIGH.
### Testability Validation
Architecture prevents effective testing. Components must enable isolated testing with ports/adapters. Severity: CRITICAL.
## Dimension 5: Priority Validation
Validate roadmap addresses largest bottleneck.
**Q1**: Largest bottleneck? (timing data must confirm primary problem)
**Q2**: Simpler alternatives considered? (rejected alternatives required)
**Q3**: Constraint prioritization correct? (quantified by impact, constraint-free first)
**Q4**: Data-justified? (key decision with quantitative data)
Failure: Q1=NO (wrong problem) | Q2=MISSING (no alternatives) | Q3=INVERTED (>50% solution for <30% problem) | Q4=NO_DATA for performance
## Review Output Format
```yaml
review_id: "arch_rev_{timestamp}"
reviewer: "solution-architect-reviewer"
artifact: "docs/product/architecture/brief.md, docs/product/architecture/adr-*.md"
iteration: {1 or 2}
strengths:
- "{Positive decision with ADR reference}"
issues_identified:
architectural_bias:
- issue: "{pattern detected}"
severity: "critical|high|medium|low"
location: "{ADR or section}"
recommendation: "{actionable fix}"
decision_quality:
- issue: "{ADR quality issue}"
severity: "high"
location: "ADR-{number}"
recommendation: "{add missing section}"
completeness_gaps:
- issue: "{quality attribute not addressed}"
severity: "critical"
recommendation: "{add architecture section}"
implementation_feasibility:
- issue: "{capability, budget, testability concern}"
severity: "high"
recommendation: "{simplify or add mitigation}"
priority_validation:
q1_largest_bottleneck:
evidence: "{data or NOT PROVIDED}"
assessment: "YES|NO|UNCLEAR"
q2_simple_alternatives:
assessment: "ADEQUATE|INADEQUATE|MISSING"
q3_constraint_prioritization:
assessment: "CORRECT|INVERTED|NOT_ANALYZED"
q4_data_justified:
assessment: "JUSTIFIED|UNJUSTIFIED|NO_DATA"
approval_status: "approved|rejected_pending_revisions|conditionally_approved"
critical_issues_count: {number}
high_issues_count: {number}
```
## Severity Classification
- **Critical**: resume-driven dev, missing critical quality attributes, untestable, wrong problem
- **High**: technology bias, incomplete ADRs, feasibility concerns, missing data
- **Medium**: missing consequences, minor completeness gaps
- **Low**: documentation improvements, naming consistencyRelated Skills
nw-sc-review-dimensions
Reviewer critique dimensions for peer review - implementation bias detection, test quality validation, completeness checks, and priority validation
nw-sa-critique-dimensions
Architecture quality critique dimensions for peer review. Load when invoking solution-architect-reviewer or performing self-review of architecture documents.
nw-rr-critique-dimensions
Critique dimensions and scoring for research document reviews
nw-po-review-dimensions
Requirements quality critique dimensions for peer review - confirmation bias detection, completeness validation, clarity checks, testability assessment, and priority validation
nw-par-critique-dimensions
Platform design review critique dimensions and severity levels. Load when reviewing CI/CD pipelines, infrastructure, deployment strategies, observability, or security designs.
nw-ad-critique-dimensions
Review dimensions for acceptance test quality - happy path bias, GWT compliance, business language purity, coverage completeness, walking skeleton user-centricity, priority validation, observable behavior assertions, traceability coverage, and walking skeleton boundary proof
nw-abr-critique-dimensions
Review dimensions for validating agent quality - template compliance, safety, testing, and priority validation
nw-ab-critique-dimensions
Review dimensions for validating agent quality - template compliance, safety, testing, and priority validation
nw-ux-web-patterns
Web UI design patterns for product owners. Load when designing web application interfaces, writing web-specific acceptance criteria, or evaluating responsive designs.
nw-ux-tui-patterns
Terminal UI and CLI design patterns for product owners. Load when designing command-line tools, interactive terminal applications, or writing CLI-specific acceptance criteria.
nw-ux-principles
Core UX principles for product owners. Load when evaluating interface designs, writing acceptance criteria with UX requirements, or reviewing wireframes and mockups.
nw-ux-emotional-design
Emotional design and delight patterns for product owners. Load when designing onboarding flows, empty states, first-run experiences, or evaluating the emotional quality of an interface.