Stats
Actions
Tags
From thinking-frameworks-skills
Breaks complex systems into atomic components, maps relationships, and reconstructs optimized configurations to identify bottlenecks, critical failure points, and redesign opportunities.
How this skill is triggered — by the user, by Claude, or both
Slash command
/thinking-frameworks-skills:decomposition-reconstructionThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
Copy this checklist and track your progress:
Copy this checklist and track your progress:
Decomposition & Reconstruction Progress:
- [ ] Step 1: Define the system and goal
- [ ] Step 2: Decompose into components and relationships
- [ ] Step 3: Analyze component properties and interactions
- [ ] Step 4: Reconstruct for insight or optimization
- [ ] Step 5: Validate and deliver recommendations
Step 1: Define the system and goal
Ask user to describe the system (what are we analyzing), current problem or goal (what needs improvement, understanding, or redesign), boundaries (what's in scope vs out of scope), and success criteria (what would "better" look like). Clear boundaries prevent endless decomposition. See Scoping Questions for clarification prompts.
Step 2: Decompose into components and relationships
Break system into atomic parts that can't be meaningfully subdivided further. Identify relationships (dependencies, data flow, control flow, temporal ordering). Choose decomposition strategy based on system type. See Decomposition Strategies and resources/template.md for structured process.
Step 3: Analyze component properties and interactions
For each component, identify key properties (cost, time, complexity, reliability, etc.). Map interactions (which components depend on which). Identify critical paths, bottlenecks, or vulnerable points. For complex analysis → See resources/methodology.md for dependency mapping and critical path techniques.
Step 4: Reconstruct for insight or optimization
Based on goal, either: (a) Identify critical components (bottleneck, single point of failure, highest cost driver), (b) Redesign configuration (reorder, parallelize, eliminate, combine components), or (c) Simplify (remove unnecessary components). See Reconstruction Patterns for common approaches.
Step 5: Validate and deliver recommendations
Self-assess using resources/evaluators/rubric_decomposition_reconstruction.json (minimum score ≥ 3.5). Present decomposition-reconstruction.md with clear component breakdown, analysis findings (bottlenecks, dependencies), and actionable recommendations with expected impact.
To define the system:
To clarify the goal:
To understand constraints:
Choose based on system type:
When: Business processes, software features, workflows Approach: Break down by function or task Example: E-commerce checkout → Browse products | Add to cart | Enter shipping | Payment | Confirmation
When: Architecture, organizations, physical systems Approach: Break down by component or module Example: Web app → Frontend (React) | API (Node.js) | Database (PostgreSQL) | Cache (Redis)
When: Pipelines, ETL processes, information systems Approach: Break down by data transformations Example: Analytics pipeline → Ingest raw events | Clean & validate | Aggregate metrics | Store in warehouse | Visualize in dashboard
When: Processes with sequential stages, timelines, user journeys Approach: Break down by time or sequence Example: Customer onboarding → Day 1: Signup | Day 2-7: Tutorial | Day 8-30: First value moment | Day 31+: Retention
When: Budget analysis, resource allocation, optimization Approach: Break down by cost center or resource type Example: AWS bill → Compute ($5K) | Storage ($2K) | Data transfer ($1K) | Other ($500)
Depth guideline: Stop decomposing when further breakdown doesn't reveal useful insights or actionable opportunities.
After decomposition, map relationships:
1. Dependency (A requires B):
2. Data flow (A sends data to B):
3. Control flow (A triggers B):
4. Temporal ordering (A before B in time):
5. Resource sharing (A and B compete for C):
Goal: Find what limits system throughput or speed Approach: Measure component properties (time, cost, capacity), identify critical path or highest value Example: DB query takes 80% of request time → Optimize DB query first
Goal: Reduce complexity by removing unnecessary parts Approach: Question necessity of each component, eliminate redundant or low-value parts Example: Workflow has 5 approval steps, 3 are redundant → Remove 3 steps
Goal: Improve efficiency by changing sequence Approach: Identify dependencies, move independent tasks earlier or parallel Example: Run tests parallel to build instead of sequential → Reduce CI time
Goal: Increase throughput by doing work concurrently Approach: Find independent components, execute simultaneously Example: Fetch user data and product data in parallel instead of serial → Cut latency in half
Goal: Replace weak component with better alternative Approach: Identify underperforming component, find replacement Example: Replace synchronous API call with async message queue → Improve reliability
Goal: Reduce overhead by combining similar components Approach: Find redundant or overlapping components, merge them Example: Consolidate 3 microservices doing similar work into 1 → Reduce operational overhead
Goal: Improve maintainability by separating concerns Approach: Identify tightly coupled components, separate with clear interfaces Example: Extract auth logic from monolith into separate service → Enable independent scaling
Skip decomposition-reconstruction if:
Use instead:
Software Architecture:
Business Processes:
Problem Solving:
Cost Optimization:
User Experience:
System Reliability:
Process:
Decomposition strategies:
Reconstruction patterns:
Resources:
Deliverable: decomposition-reconstruction.md with component breakdown, analysis, and recommendations
npx claudepluginhub lyndonkl/claude --plugin thinking-frameworks-skillsMaps, analyzes, and redesigns product systems—service blueprints, ecosystem maps, process architecture, and dependency diagrams. Use when investigating structural issues behind user experiences.
Break complex systems into bounded contexts with DDD. Map business capabilities to service boundaries, define ubiquitous language, assess cohesion/coupling. Use when refactoring monoliths or designing new architectures.
Decompose projects or tracks into modules with dependency mapping. Updates architecture.md and generates HLD/LLD artifacts to drive implement, deploy-checklist, and upload sign-off workflows.