decomposition-reconstruction
$
npx mdskill add lyndonkl/claude/decomposition-reconstructionReconstructs complex systems to reveal bottlenecks and redesign opportunities.
- Identifies critical failure points in overwhelming or interconnected problems.
- Requires clear system boundaries and defined success criteria upfront.
- Maps atomic components and their interactions to find optimization paths.
- Delivers actionable recommendations after validating reconstructed configurations.
SKILL.md
.github/skills/decomposition-reconstructionView on GitHub ↗
--- name: decomposition-reconstruction description: Breaks complex systems into atomic components, maps their relationships, and reconstructs them in optimized configurations to identify bottlenecks, critical failure points, and redesign opportunities. Use when dealing with complex systems that need simplification, identifying bottlenecks or critical failure points, redesigning architecture or processes for better performance, breaking down problems that feel overwhelming, analyzing dependencies to understand ripple effects, or when optimization requires understanding how parts interact. --- # Decomposition & Reconstruction ## Workflow 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](#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](#decomposition-strategies) and [resources/template.md](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](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](#reconstruction-patterns) for common approaches. **Step 5: Validate and deliver recommendations** Self-assess using [resources/evaluators/rubric_decomposition_reconstruction.json](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. ## Scoping Questions **To define the system:** - What is the system we're analyzing? (Be specific: "checkout flow" not "website") - Where does it start and end? (Boundaries) - What's in scope vs out of scope? (Prevents endless decomposition) **To clarify the goal:** - What problem are we solving? (Slow performance, high cost, complexity, unreliability) - What would success look like? (Specific target: "reduce latency to <500ms", "cut costs by 30%") - Are we optimizing, understanding, or redesigning? **To understand constraints:** - What can't we change? (Legacy systems, budget limits, regulatory requirements) - What's the time horizon? (Quick wins vs long-term redesign) - Who are the stakeholders? (Engineering, business, customers) ## Decomposition Strategies Choose based on system type: ### Functional Decomposition **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 ### Structural Decomposition **When:** Architecture, organizations, physical systems **Approach:** Break down by component or module **Example:** Web app → Frontend (React) | API (Node.js) | Database (PostgreSQL) | Cache (Redis) ### Data Flow Decomposition **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 ### Temporal Decomposition **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 ### Cost/Resource Decomposition **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. ## Component Relationship Types After decomposition, map relationships: **1. Dependency (A requires B):** - API service depends on database - Frontend depends on API - Critical for: Identifying cascading failures, understanding change impact **2. Data flow (A sends data to B):** - User input → Validation → Database → API response - Critical for: Tracing information, finding transformation bottlenecks **3. Control flow (A triggers B):** - Button click triggers form submission - Payment success triggers order fulfillment - Critical for: Understanding execution paths, identifying race conditions **4. Temporal ordering (A before B in time):** - Authentication before authorization - Compile before deploy - Critical for: Sequencing, finding parallelization opportunities **5. Resource sharing (A and B compete for C):** - Multiple services share database connection pool - Teams share budget - Critical for: Identifying contention, resource constraints ## Reconstruction Patterns ### Pattern 1: Bottleneck Identification **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 ### Pattern 2: Simplification **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 ### Pattern 3: Reordering **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 ### Pattern 4: Parallelization **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 ### Pattern 5: Substitution **Goal:** Replace weak component with better alternative **Approach:** Identify underperforming component, find replacement **Example:** Replace synchronous API call with async message queue → Improve reliability ### Pattern 6: Consolidation **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 ### Pattern 7: Modularization **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 ## When NOT to Use This Skill **Skip decomposition-reconstruction if:** - System is already simple (3-5 obvious components, no complex interactions) - Problem is not about system structure (purely execution issue, not design issue) - You need creativity/ideation (not analysis) - use brainstorming instead - System is poorly understood (need discovery/research first, not decomposition) - Changes are impossible (no point analyzing if you can't act on findings) **Use instead:** - Simple system → Direct analysis or observation - Execution problem → Project management, process improvement - Need ideas → Brainstorming, design thinking - Unknown system → Discovery interviews, research - Unchangeable → Workaround planning, constraint optimization ## Common Patterns by Domain **Software Architecture:** - Decompose: Modules, services, layers, data stores - Reconstruct for: Microservices migration, performance optimization, reducing coupling **Business Processes:** - Decompose: Steps, decision points, handoffs, approvals - Reconstruct for: Cycle time reduction, automation opportunities, removing waste **Problem Solving:** - Decompose: Sub-problems, dependencies, unknowns, constraints - Reconstruct for: Task sequencing, identifying blockers, finding parallelizable work **Cost Optimization:** - Decompose: Cost centers, line items, resource usage - Reconstruct for: Identifying biggest cost drivers, finding quick wins **User Experience:** - Decompose: User journey stages, interactions, pain points - Reconstruct for: Simplifying flows, removing friction, improving conversion **System Reliability:** - Decompose: Components, failure modes, dependencies - Reconstruct for: Identifying single points of failure, improving resilience ## Quick Reference **Process:** 1. Define system and goal → Set boundaries 2. Decompose → Break into components and relationships 3. Analyze → Measure properties, map interactions 4. Reconstruct → Optimize, simplify, or redesign 5. Validate → Check against rubric, deliver recommendations **Decomposition strategies:** - Functional (by task), Structural (by component), Data flow, Temporal, Cost/Resource **Reconstruction patterns:** - Bottleneck ID, Simplification, Reordering, Parallelization, Substitution, Consolidation, Modularization **Resources:** - [resources/template.md](resources/template.md) - Structured decomposition process with templates - [resources/methodology.md](resources/methodology.md) - Advanced techniques (dependency graphs, critical path analysis, hierarchical decomposition) - [resources/evaluators/rubric_decomposition_reconstruction.json](resources/evaluators/rubric_decomposition_reconstruction.json) - Quality checklist **Deliverable:** `decomposition-reconstruction.md` with component breakdown, analysis, and recommendations
More from lyndonkl/claude
- abstraction-concrete-examplesBuilds structured abstraction ladders that translate high-level principles into concrete, actionable examples across 3-5 levels. Bridges communication gaps, reveals hidden assumptions, and tests whether abstract ideas work in practice. Use when explaining concepts at different expertise levels, moving between abstract principles and concrete implementation, identifying edge cases by testing ideas against scenarios, designing layered documentation, decomposing complex problems into actionable steps, or bridging strategy-execution gaps.
- academic-letter-architectGuides the creation of evidence-based academic recommendation letters, reference letters, and award nominations that combine concrete examples, meaningful comparisons, and genuine enthusiasm. Use when writing recommendation letters for students, postdocs, or colleagues, or when user mentions recommendation letter, reference, nomination, letter of support, endorsement, or needs help with strong advocacy and comparative statements.
- adr-architectureDocuments significant architectural and technical decisions with full context, alternatives considered, trade-offs analyzed, and consequences understood. Creates a decision trail that helps teams understand why decisions were made. Use when choosing between technology options, making infrastructure decisions, establishing standards, migrating systems, or when user mentions ADR, architecture decision, technical decision record, or decision documentation.
- adverse-selection-priorProduces a Bayesian prior probability that an offered transaction is +EV for the recipient, given that the counterparty chose to propose it. Applies Akerlof market-for-lemons logic -- if they offered it, they believe it is +EV for them, so the prior that it is +EV for us is materially below 50%. Reusable across trade evaluation, waiver drops (another team dropping a player is also adverse selection), job-offer analysis, M&A, and any "someone offered me this" situation. Use when you receive an unsolicited trade/offer/proposal, analyzing incoming trade prior, evaluating why a counterparty proposed a deal, or when user mentions adverse selection, market for lemons, why did they offer this, incoming trade prior, they proposed it, Bayesian adjustment on received offer.
- alignment-values-north-starCreates actionable alignment frameworks that give teams a shared North Star (direction), values (guardrails), and decision tenets (behavioral standards). Enables autonomous decision-making while maintaining organizational coherence. Use when starting new teams, scaling organizations, defining culture, establishing product vision, resolving misalignment, creating strategic clarity, or when user mentions North Star, team values, mission, principles, guardrails, decision framework, or cultural alignment.
- analogy-weight-checkFor every analogy in a substacker draft, verifies it carries mechanical weight — the analogy does real work explaining the mechanism, not merely decorates it. Cross-references analogy-catalog.md for novelty (is this analogy reused from a prior post?) and domain fit (biology > organizational > sports preferred; physics/military disfavored). Use whenever an analogy appears in the draft. Trigger keywords: analogy weight, decorative, mechanical weight, reused analogy, catalog check, metaphor check.
- answer-uncomfortable-questionTakes one strategic question about substacker ("should we launch paid?", "is this section dead?", "are we writing for the wrong audience?") and produces the mandatory evidence + reasoning + downside triad plus a recommendation. Used 3 times per Growth Strategist review. Trigger keywords: uncomfortable question, strategic question, evidence reasoning downside, triad.
- attribute-performanceFor each substacker post that materially over- or under-performs the rolling baseline (|z| ≥ 1.0), produces a plain-English attribution paragraph with calibrated confidence (high / medium / low / unexplained). Considers subject-line effect, topic zeitgeist, external share, day-of-week, length effect, and audience-notes signals. Labels unexplained outliers explicitly rather than fabricating a story. Use after compute-baseline when outlier posts exist. Trigger keywords: attribution, why did this post work, outlier explanation, performance analysis.
- auction-first-price-shadingComputes the optimal shaded bid for a first-price sealed-bid auction given a true private value, an estimate of the number of competing bidders N, and a value-distribution assumption. Implements the `(N-1)/N` equilibrium shading rule for uniform private values, adjusts for log-normal or empirical value distributions, layers a risk-aversion adjustment, and caps output against the bidder's remaining budget. Domain-neutral auction theory reusable across fantasy sports (baseball FAAB, NBA/NHL waiver auctions), prediction-market limit sizing, sealed procurement bids, and any blind-bid context. Use when user mentions "first-price auction bid", "sealed bid shading", "(N-1)/N", "FAAB bid amount", "auction shading", "optimal bid first-price", "bid for sealed-bid", "blind bid sizing", or when downstream logic needs a principled shade factor rather than an ad-hoc heuristic.
- auction-winners-curse-haircutApplies a Bayesian haircut to a bid valuation for common-value auctions where winning is itself evidence the bidder over-estimated. Takes a raw valuation, a value-type classification (common_value / private_value / mixed), the number of informed bidders N, and a signal-dispersion estimate, and returns an adjusted valuation. Domain-neutral and reusable across fantasy FAAB, prediction markets, M&A bids, ad-auction budgets, and any generic bidding context. Use when user mentions "winner's curse", "common value auction", "valuation haircut", "adverse valuation", "Bayesian bid adjustment", or "over-paying in auction".