Use when the learner wants to practise reviewing existing code, a diff, or a pull request through guided questioning — discovering and justifying findings one concern at a time instead of receiving a dumped list or a rewrite. The first non-DSA skill in this suite. Not for chasing an already-observed concrete failure…
Use when the learner has a working approach or code and wants to determine or justify its time and space complexity. Focuses purely on Big-O derivation — nested-loop counting, recurrences, amortized cost — not on designing or debugging the algorithm itself. A standalone drill, and a deeper version of the single…
Use when the learner wants to build understanding of a general programming, software-engineering, systems, or architecture concept — references, recursion, closures, coupling, dependency injection, caching, concurrency, queues, consistency, and similar — through Socratic coaching from their current mental model, with…
Use when the learner already has written code or pseudocode, knows what it should do, and it isn't doing that — and they want the bug isolated without receiving a rewritten solution. Not for choosing an approach (use dsa-tutor), not for tracing an approach that has no code yet (use dry-run-coach), and not for plain…
Use when the learner already has an approach or algorithm in mind and needs to manually trace it, step by step, on a concrete input to verify or debug their mental model. Not for choosing an approach or writing code — use dsa-tutor for those. Teaches the actual mechanics of tracing, which dsa-tutor only names as a…
Use when the user is working through a DSA or LeetCode-style problem and wants to build real problem-solving ability instead of receiving a finished solution. Guides through questions, withholds solutions until genuine struggle has happened, and logs mistakes with root causes instead of surface symptoms.
Use when the learner explicitly wants a timed, realistic technical-interview simulation for a DSA problem rather than incremental learning support. Minimizes proactive hints during the attempt and gives structured rubric feedback only at the end. This is the opposite interaction mode from dsa-tutor — do not blend the…
Use after the learner has solved or substantially completed a DSA problem and wants to turn it into transferable knowledge — abstracting the structure away from the story, naming signals that suggest or rule out the pattern, and adapting it to exactly one cousin problem. Not for solving the original problem…
Use when the learner has a raw DSA or LeetCode-style problem statement and needs to pin down exactly what is being asked — inputs, outputs, constraints, and edge cases — before any solving begins. Not for hints, approach design, or debugging; hand off to dsa-tutor once the problem is fully understood.
Use when the learner has a vague feature request, issue, change request, or agent task and wants to turn it into an implementation-ready specification through guided questioning — clarifying observable behaviour, scope, non-goals, constraints, failure behaviour, acceptance criteria, and the smallest verifiable slice…
Use when the learner already has an approach or implementation and wants help designing a compact, justified test suite — finding missing cases, boundary values, or adversarial inputs that stress the algorithm's assumptions. Not for decoding a raw problem statement's implied edge cases (problem-decoder), not for…