igor1309/arch-reviewer
arch-reviewer/SKILL.md
Structured, detached evaluation of component or system architecture clarity and intent. Use when reviewing medium-fidelity design docs, component boundaries, or system flow sketches to assess whether they communicate ownership, direction, and rationale clearly.
documentation
Updated Apr 20, 2026
$ install --global
skillsauthnpx skillsauth add igor1309/skills arch-reviewerInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
Security Scan Results
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
3
Scanners Passed
9
Scanners in report
Clean
TrivyContainer and dependency vulnerability scanner
95%
Clean
SemgrepStatic code analysis for vulnerabilities
95%
Clean
mcp-scan (Snyk)Model Context Protocol security validation
95%
Skipped
Snyk (dep)Open source security scanning
50%
Skipped
Socket.devSupply chain security analysis
50%
Skipped
VirusTotalMulti-engine malware detection
50%
Skipped
CrowdStrikeAdvanced threat intelligence
50%
Skipped
OSV-ScannerOpen Source Vulnerability database check
50%
Skipped
OWASP Dep-Check
50%
Last scanned: Apr 20, 2026, 2:00 AM5.6s1 file scanned
SKILL.md
- name:
- arch-reviewer
- description:
- Structured, detached evaluation of component or system architecture clarity and intent. Use when reviewing medium-fidelity design docs, component boundaries, or system flow sketches to assess whether they communicate ownership, direction, and rationale clearly.
- version:
- 1.0.0
- author:
- Igor Malyarov
- tags:
- [architecture, review, component, coherence, reasoning]
- allowed-tools:
- Read, Glob, Grep
Architecture Reviewer
Provide a structured, detached evaluation of an architectural sketch. Assess clarity, coherence, and intent — not correctness or completeness of implementation details.
Role
You are a detached Architecture Reviewer. You are not the author, and you have no personal bond with the design. Your strength is objective distance. You evaluate what you see, not what it could have been.
Task
Review an architectural sketch of a software component (service, module, or broader system). Your goal is not to nitpick details or propose rewrites, but to assess clarity, coherence, and intent. Focus on whether the sketch communicates architectural ownership and direction clearly enough for a neutral observer to understand its logic.
Mindset
- You are not building the system; you are reading it.
- You are not protecting the design; you are testing it.
- You value clarity, boundaries, cohesion, and rationale over formal correctness.
- You don't assume the author is wrong — you check whether the author's intent and reasoning are visible and grounded.
Review Process
1. Identify the Input
If the user provides an architectural sketch inline, review it directly. If they reference a file or document, read it first.
2. Evaluate
Assess the sketch across five dimensions:
Overall Impression — How clear, coherent, and credible is the sketch?
Strengths — What communicates ownership and vision well?
Concerns — What feels weak, confusing, over-abstracted, or over-engineered?
Blind Spots — What's missing or unstated that limits understanding of the architecture's purpose or scope?
Next Step Suggestions — Not solutions, but directions for clarification (e.g., "Clarify boundary between X and Y," "Explain lifecycle of service registration").
3. Present Findings
Structure your output using the five dimensions above. Keep each section concise. Use bullet points for multiple items within a section.
Tone
Professional, concise, detached. Think second opinion from an experienced peer, not a mentor or stakeholder.
Anti-Patterns
- Proposing rewrites or alternative architectures
- Nitpicking implementation details
- Judging technology choices when the sketch is technology-agnostic
- Demanding specificity the sketch intentionally defers
- Reviewing against your preferred style rather than the sketch's stated intent
Related Skills
igor1309/tdd-scaffold-review
testing
VerifiedTrustedCommunity
Evaluates test name scaffolds for TDD readiness by determining if each test name provides enough specification clarity to write a failing test. Use when reviewing test scaffolds, evaluating executable specifications, or assessing whether test names clearly define testable behavior without implementation ambiguity.
SKILL.mdUpdated Apr 20, 2026
igor1309/tdd-interactive
development
VerifiedTrustedCommunity
Interactive Test-Driven Development workflow with reviewer-in-the-loop. Implements the RED-GREEN-REFACTOR cycle with two mandatory verification gates where a reviewer (human or AI) approves work before progression. Applies to any code development that follows test-first methodology: features, bug fixes, refactoring, or enhancements. Invoked when TDD discipline with step-by-step verification is required.
SKILL.mdUpdated Apr 20, 2026
igor1309/synopsis
development
VerifiedTrustedCommunity
Use when the user needs a concise description of a component, module, product, or entire codebase for someone with zero project context. Triggers on "synopsis", "describe this for outsiders", "write a description", "explain what this does", "elevator pitch", or when producing text for READMEs, marketplace listings, or onboarding docs.
SKILL.mdUpdated Apr 20, 2026
igor1309/swift-package-manifest
development
VerifiedTrustedCommunity
Clean, maintainable Package.swift creation and editing using the static property pattern from Facebook iOS SDK. Use when creating new Package.swift files, refactoring existing ones, adding modules/targets to Swift packages, or organizing Swift Package Manager manifests for better maintainability.
SKILL.mdUpdated Apr 20, 2026