Explain and Analyze Complex Code

Code Explanation and Analysis turns complex code, algorithms, design patterns, and system architectures into educational explanations. It starts by assessing structure, dependencies, and complexity hotspots, then explains the high-level flow before drilling into individual components. Progressive disclosure keeps the walkthrough organized around understanding the system before examining its details.

The explanation can use clear narratives, visual diagrams, pseudocode, or examples when those forms help communicate the code. It calls out key terminology, pitfalls, and edge cases alongside the main flow. The aim is to make difficult concepts understandable to developers with different levels of experience, including those learning how patterns work or following debugging reasoning.

Analysis remains static unless separate execution has been authorized in an isolated environment. AST and regex matches can suggest syntax or possible patterns, but those matches do not establish behavior, runtime call targets, security, or gaps in a learner's knowledge. Unknown metrics must stay unknown rather than being filled with plausible values.

Use this skill for code education, onboarding walkthroughs, learning materials, and step-by-step breakdowns of system behavior. It fits a request to understand an existing algorithm or architecture through an explanation with supporting visuals.

Choose a different workflow when the request is to implement features or perform refactors, when only API documentation or user documentation is needed, or when there is no code or design to analyze. The explanation also needs environment-specific validation, testing, or expert review where those are relevant; its educational output does not replace them. Missing required inputs, permissions, safety boundaries, or success criteria call for clarification before proceeding.

The input is the code or design to analyze together with the user's requirements. The output begins with a high-level summary of purpose and flow, continues through a step-by-step walkthrough of key parts, and can include a diagram or annotated snippet. It finishes with pitfalls, edge cases, and suggested next steps.

For detailed examples and templates, the skill points to resources/implementation-playbook.md. That playbook is a teaching scaffold: complexity, nesting, pattern, dependency, and difficulty helpers are omitted. Template fields such as {specific_use_in_code} and {code_analysis} need evidence-based substitution.

Its recursion diagram covers factorial(3) only. Its asynchronous fetch example simulates sleep and makes no HTTP request; task counts and concurrency need bounds when adapting it. Example timings are illustrative rather than measured results. Mermaid identifiers and labels need escaping and stable generated IDs. Call diagrams must accommodate external callees missing from the local function map, and name matching cannot justify a claim of complete call graphs. Untrusted labels must not be rendered as active markup.