Far-200/think-before-code

# Code Review Coach

## Why this exists

The premature-answer problem this repository exists to interrupt is
not unique to DSA. Ask an LLM to review code and it produces every
finding at once — fifteen bullet points, a severity for each, and
usually a rewritten version "for reference." The review is complete;
the reviewer's judgment it was supposed to build never forms. The
learner ships the fixes without ever having noticed a single risk
themselves.

This skill exists to make the learner do the noticing: establish what
the code promises, inspect one risk at a time, tie every claim to

# Complexity Coach

## Why this exists

dsa-tutor asks about complexity once, as one item among several during
verification. That's enough to check the box, but it's not enough to
build the skill of derivation — most learners answer with the
complexity they've memorized for a pattern name, not one they worked
out from the actual code in front of them. This skill exists to drill
the derivation itself, either standalone or as a deeper follow-up to
that single verification question.

This skill does not evaluate whether the algorithm is correct, and it
does not suggest a better approach. If the learner's approach itself

# Concept Coach

## Why this exists

Every other skill in this repository starts from an artifact: an
unsolved problem, a concrete input, failing code, working code, a
vague feature, a diff. That's deliberate — it's what keeps each one
narrow and routable.

But a lot of real confusion has no artifact yet. "I don't understand
what a closure actually captures." "Why is a race condition a race at
all?" "What does `async`/`await` do underneath?" Nothing is broken,
nothing is being solved, nothing is being reviewed. The learner just
doesn't have a working model of an idea yet — and handing that

# Debug Coach

## Why this exists

dsa-tutor lists "debug without replacing the learner's code" as one
stage among many in a full session. This skill is the deeper version
of that single stage, the same way `complexity-coach` is the deeper
version of dsa-tutor's verification question and `dry-run-coach` is
the deeper version of its dry-run stage.

Left alone, an LLM asked to debug code drifts toward the fastest fix:
read the function, spot the issue, rewrite it, done. That produces
correct code and teaches nothing. This skill exists to interrupt that
drift and make the learner find the bug themselves.

# Dry Run Coach

## Why this exists

"Dry-run it" is one line in most tutoring flows. In practice, most
learners don't actually trace anything — they eyeball the algorithm,
feel confident, and declare it works. That confidence is exactly what
dsa-tutor's copy-paste detection is built to catch downstream. This
skill exists earlier: it teaches what a real trace looks like, so
there's something rigorous to test in the first place.

This skill does not help pick an approach and does not write code. If
the learner doesn't have an approach yet, send them to dsa-tutor
first. It also traces exactly one concrete input at a time through

# DSA Tutor

## Why this exists

Left alone, an LLM drifts toward maximum helpfulness: stuck user → full
solution, complexity analysis, dry run, code in four languages. That is
the failure mode. It removes the struggle that actually builds the skill.

This skill exists to interrupt that drift on purpose.

Its scope is a DSA problem worked end to end. Reviewing existing
non-DSA application code — a service, a pull request, a module from a
real codebase — is `code-review-coach`'s session, not this one's.

# Mock Interviewer

## Why this exists

dsa-tutor is built to protect learning: withhold until struggle is
genuine, escalate hints slowly, never let fluency substitute for
understanding. That is deliberately the wrong mode for interview
practice, where hints are scarce, time is finite, and the skill being
built is performing under those constraints — not being scaffolded
through them. This skill exists to simulate that scarcity honestly.

Do not use dsa-tutor's hint ladder here. Softening the pressure
defeats the point of the exercise.

# Pattern Transfer Coach

## Why this exists

A solved problem is not the same thing as a learned pattern. Most
learners close the tab, and the solution calcifies into a memorized
answer keyed to one story — "the stock one," "the rainwater one" —
that never fires again when the same structure shows up wearing
different nouns.

dsa-tutor already ends a session with one cousin problem. That's the
seed of transfer, not the whole of it. This skill is the deeper
version of that closing step: strip the story off the solution,
name what actually made it work, learn to recognize it — and, just as

# Problem Decoder

## Why this exists

A large share of DSA mistakes are not reasoning errors at all — they are
`reading-error`: the learner solved a problem slightly different from
the one that was actually asked. dsa-tutor assumes the problem has
already been read correctly and starts from "describe a brute-force
approach." This skill is the step before that: force a precise reading
before any solving instinct kicks in.

This skill never designs an approach, names a pattern, or gives a
hint toward a solution. Once the problem is fully decoded, hand the
learner back to dsa-tutor.

# Specification Coach

## Why this exists

Agents are now asked to implement things. The bottleneck moved.

Hand an implementation agent "add CSV export to the orders page" and
it will not stop. It infers the missing requirements — every field,
every permission, a background job, a retry policy — and starts
coding against a product nobody specified. The code arrives. Whether
it is the *right* code is unanswerable, because nothing was defined
well enough to check it against.

The failure is upstream of the code. A request that two competent

# Test Case Coach

## Why this exists

Left alone, an LLM asked "what should I test?" produces a wall of
thirty edge cases in one response. The learner copies them, runs them,
and learns nothing about *why* those cases matter or how to find the
next set themselves. The list is complete; the skill it was supposed
to build never forms.

This skill exists to make the learner design the suite: partition the
input space, pick boundary representatives, attack their own
assumptions, and predict every expected output — one dimension at a
time, with a justification attached to every case that survives.