From formal-verify
Ruthlessly analyze architectural seams—the interfaces, boundaries, and contracts between system components—to expose coupling problems, abstraction leaks, and design failures. Use when asked to review architecture, analyze coupling, find interface problems, improve module boundaries, audit dependencies, or redesign system structure. Produces uncompromising redesign proposals that prioritize correctness over backwards compatibility.
npx claudepluginhub petekp/agent-skills --plugin literate-guideThis skill uses the workspace's default tool permissions.
Systematically dissect a codebase's internal architecture to expose where it's wrong and propose what's right.
Guides Next.js Cache Components and Partial Prerendering (PPR) with cacheComponents enabled. Implements 'use cache', cacheLife(), cacheTag(), revalidateTag(), static/dynamic optimization, and cache debugging.
Guides building MCP servers enabling LLMs to interact with external services via tools. Covers best practices, TypeScript/Node (MCP SDK), Python (FastMCP).
Generates original PNG/PDF visual art via design philosophy manifestos for posters, graphics, and static designs on user request.
Systematically dissect a codebase's internal architecture to expose where it's wrong and propose what's right.
No sacred cows. Existing patterns are evidence of past decisions, not correct ones.
Seams reveal truth. How components connect exposes what the system actually is, not what documentation claims.
Backwards compatibility is not a constraint. The goal is correct architecture. Migration is a separate problem.
Complexity is guilt until proven innocent. Every abstraction, indirection, and interface must justify its existence.
Build a complete picture of the system's internal structure before judging it.
Output a dependency map showing:
For every boundary identified, answer these questions:
Interface Clarity
Dependency Direction
Coupling Assessment
Abstraction Integrity
Contract Stability
Look for these systemic problems:
| Pattern | Symptoms | What's Actually Wrong |
|---|---|---|
| God Module | Everything imports it, huge public API | Missing domain boundaries |
| Shotgun Surgery | One change requires edits across many modules | Responsibility scattered |
| Feature Envy | Module A constantly reaches into Module B's data | Wrong ownership of data/behavior |
| Inappropriate Intimacy | Two modules share private details | Should be one module or have explicit contract |
| Middle Man | Module just delegates to another | Unnecessary indirection |
| Parallel Hierarchies | Adding X requires adding Y in another module | Missing abstraction |
| Speculative Generality | Interfaces for flexibility never used | Premature abstraction |
| Dead Abstraction | Interface with one implementation forever | Abstraction without purpose |
For each significant problem, provide:
1. The Indictment State clearly what is wrong and why it matters. Be specific:
core but has fields only used by billing"2. The Correct Architecture Describe what it should look like:
3. The Transformation Concrete steps to get from wrong to right:
4. The Evidence Explain why this is better:
# Seam Analysis: [System/Area Name]
## Dependency Map
[Visual or textual representation of module dependencies]
## Critical Findings
### Finding 1: [Problem Name]
**Location:** [modules/files involved]
**Severity:** Critical | High | Medium
**Pattern:** [which failure pattern]
**Evidence:**
[Specific code/structure references]
**Indictment:**
[Clear statement of what's wrong]
**Redesign:**
[Proposed correct architecture]
**Transformation:**
1. [Step]
2. [Step]
...
### Finding 2: ...
## Recommended Architecture
[Overall vision for how the system should be structured]
## Transformation Sequence
[Ordered list of changes, grouped by logical phases]
Refuse to:
Always: