architectural-analysis
From the author
Performs deep architectural analysis of a specified module, directory, or feature area by examining structural coupling, data flow, concurrency patterns, risk, and SOLID alignment. Use when the user wants to assess, evaluate, or review the architecture, design quality, dependency structure, coupling, cohesion, or technical debt of an existing part of the codebase. Not for investigating specific bugs, runtime errors, or failures — use investigate. Not for test planning — use automated-test-planning. Not for file-level code review — use code-review. Not for researching open-ended options, prior art, or how something works — use research. Not for designing a new interface or contract — use design-an-api. Not for planning the change its findings imply — use plan-a-change. Not for discovering bounded contexts, ubiquitous language, or where code boundaries diverge from domain boundaries — use ddd-analysis. Not for writing documentation or architectural decision records.
Install
npx skills add testdouble/han --skill architectural-analysis -a claude-code
Installs to .claude/skills/architectural-analysis/ · Each command fetches the skill straight from GitHub with the open skills CLI.
Byte-identical to the scanned commit, with the repository’s licence and a SOURCE.txt.
Want your agent to suggest skills while you type? See how to use skills from your IDE.
Safety checks on SKILL.md
No warnings.
Why 85
aiqbench computes the trust score from public signals. It is not a security audit, so read a skill before you install it.
Similar skills
Closest to this one by what they do and when they are used.
- investigatetestdouble/hanEvidence-based investigation of issues, bugs, API calls, integrations, and other aspects of software development that need a deep dive to find the root cause and solutions. Use when you need to debug, troubleshoot, diagnose, or figure out why something is broken. Does not review code for quality or style — use code-review for auditing changes or post-code-review-to-pr for posting review feedback to GitHub. Does not assess architectural health or structural risk — use architectural-analysis for architectural concerns. Does not research open-ended options, prior art, or how something works when nothing is broken — use research for that. Does not plan the structural change a root cause calls for — use plan-a-change. Does not map bounded contexts or domain boundaries — use ddd-analysis. Does not capture feedback on Han's own skills — use han-feedback for that.Finance★ 320
- ddd-analysistestdouble/hanAnalyzes an existing codebase using strategic Domain-Driven Design to discover bounded contexts, surface ubiquitous language and semantic collisions, find places where code boundaries diverge from domain boundaries, and produce an evidence-backed domain and context map. Use when the goal is DDD-specific: bounded context discovery, ubiquitous language analysis, domain model discovery, or mapping contested ownership and responsibility. The entire repository is a valid scope; no module or directory must be named first. Does not assess architectural coupling, cohesion, or technical debt — use architectural-analysis. Does not design service communication, integration patterns, or deployment topology — use architectural-analysis or plan-a-feature. Does not refactor code, diagnose bugs, or review code quality — use refactor, investigate, or code-review.DevOps★ 320
- architecture-designerJeffallan/claude-skillsUse when designing new high-level system architecture, reviewing existing designs, or making architectural decisions. Invoke to create architecture diagrams, write Architecture Decision Records (ADRs), evaluate technology trade-offs, design component interactions, and plan for scalability. Use for system design, architecture review, microservices structuring, ADR authoring, scalability planning, and infrastructure pattern selection — distinct from code-level design patterns or database-only design tasks.Planning★ 12K
- plan-a-changetestdouble/hanPlans an architecture-driven change to code that already exists: module boundaries, type responsibilities, layering, coupling, and the public surface a revision moves. Produces a buildable change plan that names the types, modules, and methods involved and records the surface delta each change makes. Use when the user wants to plan, scope, or sequence a restructure, extraction, split, consolidation, responsibility shift, or API revision of existing code, including "these responsibilities are wrong, plan the fix". Does not assess an area and stop at findings — use architectural-analysis. Does not specify new behavior — use plan-a-feature. Does not diagnose a bug — use investigate. Does not write the code — use refactor to restructure it or tdd to build it.Planning★ 320
- architecture-researchmajiayu000/spellbookEvidence-driven architecture research for understanding real systems and making technical decisions. Use when doing architecture landscape studies, source-backed system archaeology, build-vs-buy or adopt/adapt/build decisions, open-source and commercial comparisons, revisiting an earlier architecture choice, or handling requests such as 架构调研, 架构选型, 竞品架构, 技术尽调, 同类方案, 开源替代, how is X built, and what should we learn from X. Do not use for small mechanical changes, market-only discovery, or detailed design after the technology direction is already fixed.Science★ 288
- architecture-reviewathola/claude-night-marketAssesses architecture decisions, ADR compliance, and coupling. Use when evaluating design changes or validating structural decisions before merging.Planning★ 343
Ratings & reviews
—
no reviews
Tried this skill? Rate it to help others. Sign in
Discussion
Join the discussion. Sign in