/hld-review
Evaluate a High-Level Design (HLD) note against linked ADRs, requirements, and architecture principles. Produces a structured review with scoring across six dimensions, severity-rated findings, and actionable next steps.
Usage
/hld-review <HLD note title>
/hld-review HLD - Remote Vault Access Architecture
/hld-review HLD - SecureTransfer Azure Files to S3 Mirroring
Arguments
- $ARGUMENTS: The title of the HLD note to review (required). Must match an existing
HLD - *.md file in the vault root.
Review Dimensions
| Dimension |
What Is Checked |
| ADR Coverage |
Does each significant design choice have a corresponding ADR? Are referenced ADRs accepted? |
| Requirements Traceability |
Are all referenced requirements (from relatedTo, project notes, linked concepts) addressed in the design? |
| Principle Compliance |
Does the design align with vault architecture principles (Concept notes with conceptType: principle)? |
| Security Architecture |
Are threat mitigations documented? Are security boundaries, encryption, and access controls explicit? |
| Integration Clarity |
Are system interfaces, data flows, protocols, and error handling paths clearly defined? |
| Operational Readiness |
Are monitoring, deployment strategy, runbook considerations, and rollback plans addressed? |
Instructions
Phase 1: Load the HLD
- Parse the command — extract the HLD note title from
$ARGUMENTS
- Find the HLD file — search for the file at the vault root matching the title
- If not found, search using Grep for partial title matches across
HLD - *.md files
- If still not found, report the error and list available HLD notes
- Read the HLD note — load the full content including frontmatter and body
- Extract metadata:
relatedTo wiki-links from frontmatter
tags for domain context
confidence, freshness, verified quality indicators
- Any inline wiki-links in the body text (
[[...]] references)
Phase 2: Gather Context
Read linked notes — for each wiki-link found in relatedTo and body text:
- Read each linked note (ADRs, Systems, Concepts, Projects, Patterns)
- Categorise by type: ADR, System, Concept (principle/capability), Project, Pattern, Threat, other
- Note the status of each ADR (draft/proposed/accepted/deprecated/superseded)
Query for architecture principles — find all Concept notes with conceptType: principle:
node .claude/scripts/graph-query.js --type=Concept --tag=conceptType/principle
If the graph query returns no results, fall back to:
grep -rl "conceptType: principle" *.md
Read each principle note to extract:
statement — the principle itself
implications — what follows from the principle
domain — which domain it applies to
Query for related threats — search for Threat notes relevant to the HLD's domain:
- Check tags on the HLD for domain indicators (e.g.,
domain/security, domain/cloud, domain/integration)
- Search:
node .claude/scripts/graph-query.js --type=Threat
- Match threats by
affectedSystems and domain overlap
Check for related ADRs not yet linked — search for ADRs whose relatedTo or project fields reference the same systems or projects as the HLD:
node .claude/scripts/graph-query.js --type=Adr --tag=status/accepted
Phase 3: Evaluate Each Dimension
Score each dimension as PASS, PARTIAL, or FAIL using the criteria below.
3.1 ADR Coverage
| Score |
Criteria |
| PASS |
Every significant design choice (technology selection, architectural pattern, integration approach) has a corresponding accepted ADR |
| PARTIAL |
Some design choices have ADRs but others are undocumented, or ADRs exist but are still in draft/proposed status |
| FAIL |
Major design choices lack ADR coverage entirely |
How to assess:
- Identify each significant design choice in the HLD (technology selections, architectural patterns, protocol choices)
- Check whether an ADR exists for each choice (via
relatedTo links or vault search)
- Note any ADRs that are
draft or proposed rather than accepted
- Flag design choices that contradict accepted ADRs
3.2 Requirements Traceability
| Score |
Criteria |
| PASS |
All requirements referenced in linked project/concept notes are explicitly addressed in the HLD |
| PARTIAL |
Most requirements are addressed but some are missing or only implicitly covered |
| FAIL |
Significant requirements gaps — linked requirements not addressed in the design |
How to assess:
- Extract requirements from linked Project notes (goals, constraints, scope)
- Extract requirements from linked Concept notes (capabilities, principles)
- Verify each requirement has a corresponding design element in the HLD
- Check for orphaned requirements (mentioned in links but not in design)
3.3 Principle Compliance
| Score |
Criteria |
| PASS |
Design explicitly aligns with all applicable architecture principles; no contradictions |
| PARTIAL |
Design is broadly consistent but some principles are not explicitly addressed |
| FAIL |
Design contradicts one or more architecture principles, or ignores critical principles |
How to assess:
- For each principle note loaded in Phase 2, check whether the HLD design aligns with the principle's
statement and implications
- Focus on principles whose
domain matches the HLD's domain tags
- Flag any contradictions between the design and established principles
3.4 Security Architecture
| Score |
Criteria |
| PASS |
Security boundaries, encryption (in-transit and at-rest), authentication, authorisation, and threat mitigations are all explicitly documented |
| PARTIAL |
Some security aspects are covered but gaps exist (e.g., encryption mentioned but no auth model) |
| FAIL |
Security is not meaningfully addressed in the HLD |
How to assess:
- Check for explicit security boundaries (network isolation, trust zones)
- Verify encryption is specified for data in transit and at rest
- Look for authentication and authorisation mechanisms
- Cross-reference with Threat notes — are relevant threats mitigated?
- Check for data classification and GDPR considerations if personal data is involved
3.5 Integration Clarity
| Score |
Criteria |
| PASS |
All system interfaces are documented with protocols, data formats, error handling, and SLAs |
| PARTIAL |
Interfaces are identified but details are incomplete (missing protocols, no error handling) |
| FAIL |
System interfaces are vague or missing — unclear how components communicate |
How to assess:
- Identify all system boundaries and interfaces in the HLD
- Check each interface for: protocol, data format, authentication method, error handling
- Verify data flow direction is explicit (which system initiates, which responds)
- Look for SLA/latency/throughput specifications where applicable
- Check for retry and failure handling strategies
3.6 Operational Readiness
| Score |
Criteria |
| PASS |
Monitoring, alerting, deployment strategy, rollback plan, and operational runbook considerations are documented |
| PARTIAL |
Some operational aspects are covered but the design lacks deployment or monitoring detail |
| FAIL |
No operational considerations — the HLD focuses only on functional architecture |
How to assess:
- Check for monitoring and alerting strategy
- Look for deployment approach (blue/green, rolling, canary)
- Verify rollback/recovery procedures are considered
- Check for logging and observability mentions
- Look for capacity planning and scaling considerations
- Check for runbook or operational handover references
Phase 4: Compile Findings
Categorise each finding by severity:
| Severity |
Definition |
Action Required |
| BLOCKING |
Fundamental gap that must be resolved before the design can proceed to implementation |
Rework required |
| ADVISORY |
Gap that should be addressed but does not prevent progress |
Address before go-live |
| INFORMATIONAL |
Observation or suggestion for improvement |
Consider in future iterations |
Phase 5: Determine Review Status
Based on the dimension scores and finding severities:
| Status |
When Applied |
| APPROVED |
All dimensions PASS, no BLOCKING findings |
| APPROVED WITH CONDITIONS |
No dimensions FAIL, but PARTIAL scores exist or ADVISORY findings need attention |
| NEEDS REWORK |
Any dimension scores FAIL, or any BLOCKING findings exist |
Phase 6: Generate Review Output
Output the review directly to the console. Use the template below.
Output Template
# HLD Review: [HLD Title]
**Reviewed:** [today's date]
**HLD Created:** [created date from frontmatter]
**Last Reviewed:** [reviewed date from frontmatter]
**Confidence:** [confidence from frontmatter]
---
## Review Status: [APPROVED / APPROVED WITH CONDITIONS / NEEDS REWORK]
---
## Scoring Summary
| Dimension | Score | Evidence | Gaps |
|---|---|---|---|
| ADR Coverage | [PASS/PARTIAL/FAIL] | [what ADRs exist and cover] | [what design choices lack ADRs] |
| Requirements Traceability | [PASS/PARTIAL/FAIL] | [requirements addressed] | [requirements not addressed] |
| Principle Compliance | [PASS/PARTIAL/FAIL] | [principles aligned with] | [principles not addressed or contradicted] |
| Security Architecture | [PASS/PARTIAL/FAIL] | [security measures documented] | [security aspects missing] |
| Integration Clarity | [PASS/PARTIAL/FAIL] | [interfaces documented] | [interfaces lacking detail] |
| Operational Readiness | [PASS/PARTIAL/FAIL] | [operational aspects covered] | [operational aspects missing] |
---
## Findings
### BLOCKING
[If none: "No blocking findings."]
1. **[Finding Title]** — [Description of the gap, which dimension it affects, and why it blocks progress]
- **Dimension:** [affected dimension]
- **Recommendation:** [specific action to resolve]
### ADVISORY
[If none: "No advisory findings."]
1. **[Finding Title]** — [Description and recommendation]
- **Dimension:** [affected dimension]
- **Recommendation:** [specific action to resolve]
### INFORMATIONAL
[If none: "No informational findings."]
1. **[Finding Title]** — [Observation or suggestion]
---
## Conditions
[Only include if status is APPROVED WITH CONDITIONS]
The following conditions must be addressed before implementation:
- [ ] [Condition 1 — specific, actionable item]
- [ ] [Condition 2]
---
## Context Analysed
### Linked ADRs
| ADR | Status | Relevance |
|-----|--------|-----------|
| [[ADR - Title]] | accepted | [how it relates to the HLD] |
### Architecture Principles Assessed
| Principle | Domain | Compliance |
|-----------|--------|------------|
| [[Concept - Principle Name]] | [domain] | [aligned/not addressed/contradicted] |
### Threat Coverage
| Threat | Severity | Mitigated? |
|--------|----------|------------|
| [[Threat - Name]] | [severity] | [yes/partial/no] |
### Systems Referenced
[List of System notes referenced in the HLD with their status]
---
## Next Steps
- [ ] [Action item based on findings — e.g., "Create ADR for Docker orchestration choice"]
- [ ] [Action item — e.g., "Add monitoring section to HLD"]
- [ ] [Action item — e.g., "Link Threat - Denial of Service and document mitigation"]
- [ ] Update HLD `reviewed` date to today
- [ ] Update HLD `verified` to `true` once conditions are met
Examples
Example 1: Quick Review
/hld-review HLD - Remote Vault Access Architecture
Reviews the HLD against all six dimensions, checking linked ADRs, vault principles, relevant threats, and operational completeness.
Example 2: Review After ADR Changes
/hld-review HLD - SecureTransfer Azure Files to S3 Mirroring
Useful after new ADRs are accepted to verify the HLD still aligns with the latest decisions.
Error Handling
- HLD not found: List all available HLD notes in the vault and ask the user to confirm
- No linked notes: Report that the HLD has an empty
relatedTo field — this is itself a finding (ADVISORY: "HLD lacks cross-references to ADRs, systems, and requirements")
- Graph index unavailable: Fall back to Grep-based search for principles and threats
- No principles found: Note this as INFORMATIONAL — the vault may not yet have principle notes established
Related Skills
/nfr-review — Review an HLD against NFR requirements (complementary to this skill)
/diagram-review — Analyse architecture diagrams for readability and quality
/adr — Create new ADRs for design choices identified as gaps
/diagram — Generate architecture diagrams referenced in the HLD
/impact-analysis — Analyse the impact of changes to systems in the HLD
Related Notes
.claude/rules/naming-conventions.md — HLD naming patterns
.claude/context/frontmatter-reference.md — HLD frontmatter schema
.claude/context/architecture.md — Architecture governance context
1---2name: hld-review3description: Evaluate an HLD note against linked ADRs, requirements, and architecture principles across six dimensions4---56# /hld-review78Evaluate a High-Level Design (HLD) note against linked ADRs, requirements, and architecture principles. Produces a structured review with scoring across six dimensions, severity-rated findings, and actionable next steps.910## Usage1112```13/hld-review <HLD note title>14/hld-review HLD - Remote Vault Access Architecture15/hld-review HLD - SecureTransfer Azure Files to S3 Mirroring16```1718## Arguments1920- **$ARGUMENTS**: The title of the HLD note to review (required). Must match an existing `HLD - *.md` file in the vault root.2122## Review Dimensions2324| Dimension | What Is Checked |25|---|---|26| **ADR Coverage** | Does each significant design choice have a corresponding ADR? Are referenced ADRs accepted? |27| **Requirements Traceability** | Are all referenced requirements (from `relatedTo`, project notes, linked concepts) addressed in the design? |28| **Principle Compliance** | Does the design align with vault architecture principles (`Concept` notes with `conceptType: principle`)? |29| **Security Architecture** | Are threat mitigations documented? Are security boundaries, encryption, and access controls explicit? |30| **Integration Clarity** | Are system interfaces, data flows, protocols, and error handling paths clearly defined? |31| **Operational Readiness** | Are monitoring, deployment strategy, runbook considerations, and rollback plans addressed? |3233## Instructions3435### Phase 1: Load the HLD36371. **Parse the command** — extract the HLD note title from `$ARGUMENTS`382. **Find the HLD file** — search for the file at the vault root matching the title39 - If not found, search using Grep for partial title matches across `HLD - *.md` files40 - If still not found, report the error and list available HLD notes413. **Read the HLD note** — load the full content including frontmatter and body424. **Extract metadata:**43 - `relatedTo` wiki-links from frontmatter44 - `tags` for domain context45 - `confidence`, `freshness`, `verified` quality indicators46 - Any inline wiki-links in the body text (`[[...]]` references)4748### Phase 2: Gather Context49501. **Read linked notes** — for each wiki-link found in `relatedTo` and body text:51 - Read each linked note (ADRs, Systems, Concepts, Projects, Patterns)52 - Categorise by type: ADR, System, Concept (principle/capability), Project, Pattern, Threat, other53 - Note the status of each ADR (draft/proposed/accepted/deprecated/superseded)54552. **Query for architecture principles** — find all `Concept` notes with `conceptType: principle`:56 ```bash57 node .claude/scripts/graph-query.js --type=Concept --tag=conceptType/principle58 ```59 If the graph query returns no results, fall back to:60 ```bash61 grep -rl "conceptType: principle" *.md62 ```63 Read each principle note to extract:64 - `statement` — the principle itself65 - `implications` — what follows from the principle66 - `domain` — which domain it applies to67683. **Query for related threats** — search for Threat notes relevant to the HLD's domain:69 - Check tags on the HLD for domain indicators (e.g., `domain/security`, `domain/cloud`, `domain/integration`)70 - Search: `node .claude/scripts/graph-query.js --type=Threat`71 - Match threats by `affectedSystems` and domain overlap72734. **Check for related ADRs not yet linked** — search for ADRs whose `relatedTo` or `project` fields reference the same systems or projects as the HLD:74 ```bash75 node .claude/scripts/graph-query.js --type=Adr --tag=status/accepted76 ```7778### Phase 3: Evaluate Each Dimension7980Score each dimension as **PASS**, **PARTIAL**, or **FAIL** using the criteria below.8182#### 3.1 ADR Coverage8384| Score | Criteria |85|---|---|86| **PASS** | Every significant design choice (technology selection, architectural pattern, integration approach) has a corresponding accepted ADR |87| **PARTIAL** | Some design choices have ADRs but others are undocumented, or ADRs exist but are still in draft/proposed status |88| **FAIL** | Major design choices lack ADR coverage entirely |8990**How to assess:**91- Identify each significant design choice in the HLD (technology selections, architectural patterns, protocol choices)92- Check whether an ADR exists for each choice (via `relatedTo` links or vault search)93- Note any ADRs that are `draft` or `proposed` rather than `accepted`94- Flag design choices that contradict accepted ADRs9596#### 3.2 Requirements Traceability9798| Score | Criteria |99|---|---|100| **PASS** | All requirements referenced in linked project/concept notes are explicitly addressed in the HLD |101| **PARTIAL** | Most requirements are addressed but some are missing or only implicitly covered |102| **FAIL** | Significant requirements gaps — linked requirements not addressed in the design |103104**How to assess:**105- Extract requirements from linked Project notes (goals, constraints, scope)106- Extract requirements from linked Concept notes (capabilities, principles)107- Verify each requirement has a corresponding design element in the HLD108- Check for orphaned requirements (mentioned in links but not in design)109110#### 3.3 Principle Compliance111112| Score | Criteria |113|---|---|114| **PASS** | Design explicitly aligns with all applicable architecture principles; no contradictions |115| **PARTIAL** | Design is broadly consistent but some principles are not explicitly addressed |116| **FAIL** | Design contradicts one or more architecture principles, or ignores critical principles |117118**How to assess:**119- For each principle note loaded in Phase 2, check whether the HLD design aligns with the principle's `statement` and `implications`120- Focus on principles whose `domain` matches the HLD's domain tags121- Flag any contradictions between the design and established principles122123#### 3.4 Security Architecture124125| Score | Criteria |126|---|---|127| **PASS** | Security boundaries, encryption (in-transit and at-rest), authentication, authorisation, and threat mitigations are all explicitly documented |128| **PARTIAL** | Some security aspects are covered but gaps exist (e.g., encryption mentioned but no auth model) |129| **FAIL** | Security is not meaningfully addressed in the HLD |130131**How to assess:**132- Check for explicit security boundaries (network isolation, trust zones)133- Verify encryption is specified for data in transit and at rest134- Look for authentication and authorisation mechanisms135- Cross-reference with Threat notes — are relevant threats mitigated?136- Check for data classification and GDPR considerations if personal data is involved137138#### 3.5 Integration Clarity139140| Score | Criteria |141|---|---|142| **PASS** | All system interfaces are documented with protocols, data formats, error handling, and SLAs |143| **PARTIAL** | Interfaces are identified but details are incomplete (missing protocols, no error handling) |144| **FAIL** | System interfaces are vague or missing — unclear how components communicate |145146**How to assess:**147- Identify all system boundaries and interfaces in the HLD148- Check each interface for: protocol, data format, authentication method, error handling149- Verify data flow direction is explicit (which system initiates, which responds)150- Look for SLA/latency/throughput specifications where applicable151- Check for retry and failure handling strategies152153#### 3.6 Operational Readiness154155| Score | Criteria |156|---|---|157| **PASS** | Monitoring, alerting, deployment strategy, rollback plan, and operational runbook considerations are documented |158| **PARTIAL** | Some operational aspects are covered but the design lacks deployment or monitoring detail |159| **FAIL** | No operational considerations — the HLD focuses only on functional architecture |160161**How to assess:**162- Check for monitoring and alerting strategy163- Look for deployment approach (blue/green, rolling, canary)164- Verify rollback/recovery procedures are considered165- Check for logging and observability mentions166- Look for capacity planning and scaling considerations167- Check for runbook or operational handover references168169### Phase 4: Compile Findings170171Categorise each finding by severity:172173| Severity | Definition | Action Required |174|---|---|---|175| **BLOCKING** | Fundamental gap that must be resolved before the design can proceed to implementation | Rework required |176| **ADVISORY** | Gap that should be addressed but does not prevent progress | Address before go-live |177| **INFORMATIONAL** | Observation or suggestion for improvement | Consider in future iterations |178179### Phase 5: Determine Review Status180181Based on the dimension scores and finding severities:182183| Status | When Applied |184|---|---|185| **APPROVED** | All dimensions PASS, no BLOCKING findings |186| **APPROVED WITH CONDITIONS** | No dimensions FAIL, but PARTIAL scores exist or ADVISORY findings need attention |187| **NEEDS REWORK** | Any dimension scores FAIL, or any BLOCKING findings exist |188189### Phase 6: Generate Review Output190191Output the review directly to the console. Use the template below.192193---194195## Output Template196197```markdown198# HLD Review: [HLD Title]199200**Reviewed:** [today's date]201**HLD Created:** [created date from frontmatter]202**Last Reviewed:** [reviewed date from frontmatter]203**Confidence:** [confidence from frontmatter]204205---206207## Review Status: [APPROVED / APPROVED WITH CONDITIONS / NEEDS REWORK]208209---210211## Scoring Summary212213| Dimension | Score | Evidence | Gaps |214|---|---|---|---|215| ADR Coverage | [PASS/PARTIAL/FAIL] | [what ADRs exist and cover] | [what design choices lack ADRs] |216| Requirements Traceability | [PASS/PARTIAL/FAIL] | [requirements addressed] | [requirements not addressed] |217| Principle Compliance | [PASS/PARTIAL/FAIL] | [principles aligned with] | [principles not addressed or contradicted] |218| Security Architecture | [PASS/PARTIAL/FAIL] | [security measures documented] | [security aspects missing] |219| Integration Clarity | [PASS/PARTIAL/FAIL] | [interfaces documented] | [interfaces lacking detail] |220| Operational Readiness | [PASS/PARTIAL/FAIL] | [operational aspects covered] | [operational aspects missing] |221222---223224## Findings225226### BLOCKING227228[If none: "No blocking findings."]2292301. **[Finding Title]** — [Description of the gap, which dimension it affects, and why it blocks progress]231 - **Dimension:** [affected dimension]232 - **Recommendation:** [specific action to resolve]233234### ADVISORY235236[If none: "No advisory findings."]2372381. **[Finding Title]** — [Description and recommendation]239 - **Dimension:** [affected dimension]240 - **Recommendation:** [specific action to resolve]241242### INFORMATIONAL243244[If none: "No informational findings."]2452461. **[Finding Title]** — [Observation or suggestion]247248---249250## Conditions251252[Only include if status is APPROVED WITH CONDITIONS]253254The following conditions must be addressed before implementation:255256- [ ] [Condition 1 — specific, actionable item]257- [ ] [Condition 2]258259---260261## Context Analysed262263### Linked ADRs264| ADR | Status | Relevance |265|-----|--------|-----------|266| [[ADR - Title]] | accepted | [how it relates to the HLD] |267268### Architecture Principles Assessed269| Principle | Domain | Compliance |270|-----------|--------|------------|271| [[Concept - Principle Name]] | [domain] | [aligned/not addressed/contradicted] |272273### Threat Coverage274| Threat | Severity | Mitigated? |275|--------|----------|------------|276| [[Threat - Name]] | [severity] | [yes/partial/no] |277278### Systems Referenced279[List of System notes referenced in the HLD with their status]280281---282283## Next Steps284285- [ ] [Action item based on findings — e.g., "Create ADR for Docker orchestration choice"]286- [ ] [Action item — e.g., "Add monitoring section to HLD"]287- [ ] [Action item — e.g., "Link Threat - Denial of Service and document mitigation"]288- [ ] Update HLD `reviewed` date to today289- [ ] Update HLD `verified` to `true` once conditions are met290```291292---293294## Examples295296### Example 1: Quick Review297298```299/hld-review HLD - Remote Vault Access Architecture300```301302Reviews the HLD against all six dimensions, checking linked ADRs, vault principles, relevant threats, and operational completeness.303304### Example 2: Review After ADR Changes305306```307/hld-review HLD - SecureTransfer Azure Files to S3 Mirroring308```309310Useful after new ADRs are accepted to verify the HLD still aligns with the latest decisions.311312## Error Handling313314- **HLD not found:** List all available HLD notes in the vault and ask the user to confirm315- **No linked notes:** Report that the HLD has an empty `relatedTo` field — this is itself a finding (ADVISORY: "HLD lacks cross-references to ADRs, systems, and requirements")316- **Graph index unavailable:** Fall back to Grep-based search for principles and threats317- **No principles found:** Note this as INFORMATIONAL — the vault may not yet have principle notes established318319## Related Skills320321- `/nfr-review` — Review an HLD against NFR requirements (complementary to this skill)322- `/diagram-review` — Analyse architecture diagrams for readability and quality323- `/adr` — Create new ADRs for design choices identified as gaps324- `/diagram` — Generate architecture diagrams referenced in the HLD325- `/impact-analysis` — Analyse the impact of changes to systems in the HLD326327## Related Notes328329- `.claude/rules/naming-conventions.md` — HLD naming patterns330- `.claude/context/frontmatter-reference.md` — HLD frontmatter schema331- `.claude/context/architecture.md` — Architecture governance context