with one click
verify-design-a
// Architecture review in hindsight — what to question, dependency analysis, abstraction assessment
// Architecture review in hindsight — what to question, dependency analysis, abstraction assessment
[HINT] Download the complete skill directory including SKILL.md and all related files
| name | verify-design-a |
| type | action |
| description | Architecture review in hindsight — what to question, dependency analysis, abstraction assessment |
| user-invocable | false |
Action skill — Architecture review procedures: dependency analysis, abstraction assessment, output format.
Evaluating code architecture in hindsight — now that it's built, does the structure make sense?
Type and class design — Why does this class exist? Would functions suffice? Should these be separate types or one? Is inheritance justified?
Module structure — Why is this code in this package? Should modules be split or merged? Are boundaries in the right places? Does directory structure reflect architecture?
Dependencies — Why does A depend on B? Could it be inverted? Hidden coupling through shared state? Circular dependencies? Dependencies pointing toward stability?
Abstractions — Earning their complexity? More than one implementation? Interface premature? Would concrete code be clearer?
Diagrams first. Show module dependencies, data flow, layer structure. Reference diagrams in every finding.
Format findings as:
Not naming/formatting (that's style). Not fake code (that's larp). Sound architecture is the goal, not findings.
## Concern: {title}
DIAGRAM: {ASCII dependency or data flow diagram}
OBSERVATION: What the current design does
QUESTION: Why is it this way? What's the tradeoff?
ALTERNATIVE: Different approach to consider
IMPACT: What would change if refactored
Refactor candidates as prioritized list with FROM/TO/TRADEOFF for each.