skills/architecture-compliance-review/SKILL.md
Use this skill to review compliance contract portfolio health. Validates all 10 contracts exist and are ≤6 months old, triggers regeneration for missing/expired contracts, and generates an interactive playground for exploring concept gaps across all contracts to understand what needs to be addressed to reach the auto-approve threshold (≥8.0/10).
npx skillsauth add shadowx4fox/solutions-architect-skills architecture-compliance-reviewInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
This skill acts as a compliance portfolio health reviewer. It validates that all 10 compliance contracts are present and fresh (≤6 months old), analyzes each contract's requirement gaps, and generates an interactive HTML playground for exploring the concept gaps across all contracts — helping you understand which areas of ARCHITECTURE.md fall short of the auto-approve threshold (≥8.0/10) and why.
Auto-Approve Threshold: ≥8.0/10 per contract.
Maximum Contract Age: 6 months. Any contract older than 6 months is considered EXPIRED and must be regenerated before review proceeds.
/skill architecture-compliance-reviewDo NOT invoke for:
architecture-compliance skillarchitecture-compliance skillarchitecture-docs skillarchitecture-peer-review skillarchitecture-readiness skill| File | Purpose |
|------|---------|
| SKILL.md | This file — entry point and workflow |
| PLAYGROUND_TEMPLATE.md | Playground template for the interactive compliance gap explorer HTML |
| # | Contract Type | Identifier Prefix |
|---|---------------|-------------------|
| 1 | SRE Architecture | SRE_ARCHITECTURE |
| 2 | Business Continuity | BUSINESS_CONTINUITY |
| 3 | Cloud Architecture | CLOUD_ARCHITECTURE |
| 4 | Data & AI Architecture | DATA_AI_ARCHITECTURE |
| 5 | Development Architecture | DEVELOPMENT_ARCHITECTURE |
| 6 | Process Transformation & Automation | PROCESS_TRANSFORMATION |
| 7 | Security Architecture | SECURITY_ARCHITECTURE |
| 8 | Platform & IT Infrastructure | PLATFORM_INFRASTRUCTURE |
| 9 | Enterprise Architecture | ENTERPRISE_ARCHITECTURE |
| 10 | Integration Architecture | INTEGRATION_ARCHITECTURE |
Search for compliance-docs/COMPLIANCE_MANIFEST.md at the project root.
If not found, abort with:
"No COMPLIANCE_MANIFEST.md found. Run
/skill architecture-complianceto generate compliance contracts first, then return here for the review."
Read compliance-docs/COMPLIANCE_MANIFEST.md. Extract:
Get today's date by running: bun [plugin_dir]/scripts/today.ts (cross-platform Bun helper; replaces date +%Y-%m-%d so the skill runs identically on Linux, macOS, Windows native, WSL, and Git Bash)
6-month cutoff rule: A contract is VALID only if its generation date is within 6 calendar months of today. Compute the cutoff date = today minus 6 months (e.g., if today is 2026-03-22, the cutoff is 2025-09-22).
For each of the 10 required contract types, determine:
compliance-docs/ using Glob.valid | missing | expiredBuild a coverage summary table and display it to the user:
| # | Contract Type | Status | Generation Date | Age | Score |
|---|-------------------------------|-----------|-----------------|----------|---------|
| 1 | SRE Architecture | ✅ Valid | 2025-12-27 | 2.8 mo | 7.69/10 |
| 2 | Business Continuity | ❌ Missing | — | — | — |
| 3 | Security Architecture | ⚠️ Expired | 2025-01-15 | 14.2 mo | 6.5/10 |
| … | … | … | … | … | … |
If all 10 contracts are valid, skip to Step 4.
If any contracts are missing or expired, present the user with a choice:
N contract(s) are missing or expired and cannot be included in this review.
[A] Regenerate now — invoke the
architecture-complianceskill for the affected contracts, then continue the review [B] Proceed with valid contracts only — review covers only the valid contracts; missing/expired will be marked as NOT REVIEWED [C] Cancel — stop here and regenerate contracts manually with/skill architecture-compliance
architecture-compliance skill specifying only the affected contract types. Wait for completion. Re-read the manifest. Proceed to Step 4./skill architecture-compliance.For each contract with contract_status = valid, read the actual file from compliance-docs/.
From each contract file, extract the following data:
Locate the Document Control section (table with | Field | Value | format) or the score summary. Extract:
7.69/10)Locate the requirement breakdown section. Extract counts for:
Locate the Compliance Summary Table — a 6-column table with headers:
| Code | Requirement | Category | Status | Source Section | Responsible Role |
Extract every row where Status = Non-Compliant OR Status = Unknown.
For each gap row, capture:
code: requirement code (e.g., SRE-B-023)requirement: full requirement textcategory: compliance categorystatus: Non-Compliant or UnknownsourceSection: ARCHITECTURE.md source section referencepriority: determine whether this is a Blocker or Desired requirement by checking which section heading precedes the row (e.g., "Blocker Requirements" or "Desired Requirements")Assign concept tags to each gap based on requirement text keywords:
["load-testing", "performance"]["chaos-engineering", "resilience"]["dr-rto-rpo", "business-continuity"]["iam", "access-control"]["observability", "monitoring"]["data-governance"]["cicd", "deployment"]["api-docs", "integration"]["encryption", "security"]["incident-management", "operations"]["capacity-planning", "scalability"]["regulatory-compliance"]For each valid contract, compute:
aboveThreshold: score ≥ 8.0gapToThreshold: max(0, 8.0 − score)Group all gaps across all contracts by concept (using the concept tags assigned in Step 4b).
For each concept cluster:
concept: human-readable concept name (e.g., "Load Testing Strategy")description: one-sentence explanation of what documentation is neededaffectedContracts: list of contract types that have gaps with this concept tagtotalGaps: total number of gap rows tagged with this conceptblockerGaps: count of gaps where priority = blockerdesiredGaps: count of gaps where priority = desiredimpactScore: (blockerGaps × 2 + desiredGaps × 1) × (number of affectedContracts)estimatedEffort: High (impactScore ≥ 8) | Medium (4–7) | Low (1–3)architectureSection: inferred ARCHITECTURE.md section(s) where gaps originate (based on source sections from gap rows)Sort concept clusters descending by impactScore. Clusters that affect more contracts with more Blocker gaps rank highest.
Read PLAYGROUND_TEMPLATE.md from this skill's directory (use the full path resolved via resolve-plugin-dir.ts or equivalent).
Invoke the playground skill using PLAYGROUND_TEMPLATE.md as the template.
Embed the following JSON in the generated HTML <script> block as const reviewData = { … }:
{
project: "<project name from manifest>",
reviewDate: "<today YYYY-MM-DD>",
autoApproveThreshold: 8.0,
coverage: {
valid: <count>,
missing: <count>,
expired: <count>,
total: 10
},
contracts: [
{
id: "<slug e.g. 'sre'>",
type: "<Contract Type>",
filename: "<filename or null>",
generationDate: "<YYYY-MM-DD or null>",
ageMonths: <float or null>,
contractStatus: "<valid|missing|expired>",
score: <float or null>,
aboveThreshold: <bool or null>,
gapToThreshold: <float or null>,
projectedScoreAfterFix: <float or null>,
requirements: {
blocker: { total: N, compliant: N, notApplicable: N, unknown: N, nonCompliant: N },
desired: { total: N, compliant: N, notApplicable: N, unknown: N, nonCompliant: N }
},
gaps: [
{
id: "<contract-slug>-gap-<n>",
code: "<requirement code>",
requirement: "<requirement text>",
category: "<category>",
priority: "<blocker|desired>",
status: "<Unknown|Non-Compliant>",
sourceSection: "<section reference>",
conceptTags: ["<tag>", ...]
}
]
}
],
conceptClusters: [
{
id: "<slug>",
concept: "<concept name>",
description: "<one-sentence description>",
affectedContracts: ["<contract type>", ...],
totalGaps: N,
blockerGaps: N,
desiredGaps: N,
impactScore: N,
estimatedEffort: "<High|Medium|Low>",
architectureSection: "<section(s) where gaps originate>"
}
]
}
Follow all core playground requirements:
open <filename>.htmlFilename convention: compliance-review-<YYYY-MM-DD>.html
Fallback — If the playground plugin is not installed, output the gap analysis as a structured plain-text report:
# Compliance Review Report
Date: <date>
Project: <name>
Coverage: <N>/10 contracts valid
## Portfolio Health
[table of 10 contracts with scores]
## Concept Clusters (Priority Order)
[ranked list with contract impact and fix guidance]
## Path to Full Auto-Approval
[per-contract projected scores]
The user interacts with the compliance gap explorer playground to:
| Skill | Relationship |
|-------|-------------|
| architecture-compliance | Prerequisite and regeneration target: this skill reads contracts generated by architecture-compliance. Triggers architecture-compliance if contracts are missing or expired. |
| architecture-docs | Next step after exploration: once gaps are understood from this review, use the architecture-docs skill to update ARCHITECTURE.md. |
| playground | External plugin dependency: generates the interactive HTML compliance gap explorer. |
| architecture-peer-review | Complementary: peer review validates architectural quality; this skill validates compliance contract health. Together they provide full quality assurance coverage. |
A successful compliance review produces:
development
Run risk and design-characteristics analyses over ARCHITECTURE.md documentation. Produces date-stamped reports in analysis/ covering ten lenses across two groups: HIGH-priority runtime/security — SPOF (single points of failure), Blast Radius (downstream cascade impact), Bottleneck (throughput chokepoints), Cost Hotspots (Pareto cost concentration), STRIDE (per-trust-boundary security threats); Strategic/sustainability — Vendor Lock-in (portability risk and exit cost), Latency Budget (per-hop SLO decomposition), Tech Debt/EOL (currency and deprecated tech), Coupling (fan-in/fan-out and cycles), Data Sensitivity (PII flow and encryption gaps). Each analysis can be requested individually, as a group, or all ten run in parallel. A consolidated Security Posture option (analysis 12) merges the STRIDE and Data Sensitivity reports into a single reviewer-fillable validation checklist of every security control to validate (markdown-only; exportable to a Word worksheet via architecture-docs-export). Output: analysis/<TYPE>-<YYYY-MM-DD>.md (default) OR analysis/<TYPE>-<YYYY-MM-DD>.html (interactive d3.js report; format is selected at runtime — Step 2.4). Requires ARCHITECTURE.md to exist (created by architecture-docs skill). Do NOT invoke for compliance contracts (use architecture-compliance), peer quality review (use architecture-peer-review), or ADR management (use architecture-definition-record).
development
On-demand export of architecture documents to professional Word (.docx) files. Exports are never automatic — invoke explicitly when ready to produce deliverables. Solution Architecture mode synthesizes an Executive Summary from docs/01-system-overview.md, the component index, and the compliance manifest (if present), then exports individual ADR docs. Handoff mode exports selected component development handoffs from handoffs/. Compliance mode exports selected compliance contracts from compliance-docs/. Security Posture mode exports the consolidated security validation checklist (analysis/SECURITY-POSTURE-<date>.md, from architecture-analysis) as a reviewer-fillable worksheet. IMPORTANT — this skill ONLY produces Word .docx files. It does NOT handle releasing, publishing, tagging, freezing, bumping, or finalizing an architecture version. For the Draft → Released lifecycle (git tag architecture-v{version}, archive snapshot, semver bump), use the `architecture-docs` skill (Workflow 10) instead. Do NOT invoke this skill when the user says "release my architecture", "release architecture", "publish architecture", "ship architecture", "tag architecture version", "freeze architecture", "bump architecture version", or "finalize architecture" — those route to `architecture-docs`.
testing
Generate Compliance Contracts (Contratos de Adherencia) from ARCHITECTURE.md files
testing
Use this skill whenever the user mentions deferred work, known compromises, shortcuts taken, "we'll fix this later," temporary workarounds, missing controls, or any architectural trade-off that should be made visible and tracked. Also trigger when arc42 Section 11 (Risks and Technical Debt) is being authored or updated, when a TDR / Technical Debt Record is requested by name, or when an ADR documents a decision that intentionally accepts debt. Do NOT use for general bug reports, feature requests, or backlog items — TDRs are for architectural or systemic compromises, not ordinary defects.