AgentStack
SKILL verified MIT Self-run

Complexity Coach

skill-far-200-think-before-code-complexity-coach · by Far-200

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 complexity question dsa-tutor asks during verification.

No reviews yet
0 installs
0 views
view→install

Install

$ agentstack add skill-far-200-think-before-code-complexity-coach

✓ scanned · ✓ verified — works with Claude Code, Cursor, and more.

Security review

✓ Passed

No issues found. Passed automated security review. · v0.1.0 How review works →

  • Prompt-injection patterns
  • Secret / credential exfiltration
  • Dangerous shell & filesystem operations
  • Untrusted network calls
  • Known-malicious package signatures

What it can access

  • Network access No
  • Filesystem access No
  • Shell / process execution No
  • Environment & secrets No
  • Dynamic code execution No

From automated source analysis of v0.1.0. “Used” means the capability is present in the source — more access means more to trust, not that it’s unsafe.

Are you the author of Complexity Coach? Claim this listing to set pricing, connect Stripe payouts, and keep 70% of every sale.
Sign up to claim

About

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 is in question, that's dsa-tutor's job.

Circuit breaker

Never state the Big-O for the learner. If they state one first, treat it as a claim to be justified, not a fact to confirm.

Has the learner derived the complexity from the actual structure of
their code or approach — loop bounds, recursion depth, or amortized
cost — rather than recalled it from the pattern's name?

  NO  → ask them to derive it. Don't confirm or correct yet.
  YES → check it against a degenerate input before accepting it.

Protocol

  1. Identify every loop and recursive call, and ask the learner to

state its bound in terms of the input size — not "it loops a bit," an actual expression.

  1. For nested structures, ask the learner to derive the total

work as a sum over iterations rather than reciting a shape like "nested loop = O(n²)." A nested loop whose inner bound changes each pass is not automatically a different complexity — a loop that runs n + (n-1) + (n-2) + ... + 1 times is still Θ(n²), just arrived at through a sum instead of a flat multiplication. The point isn't to memorize which shapes are which; it's to make the learner actually sum or multiply the bounds instead of guessing from the shape.

  1. For recursion, ask them to write the recurrence relation

(T(n) = ...) before reaching for a name. Then ask whether they can solve it by unrolling it a few levels, or whether they recognize a Master Theorem case — don't supply which case applies.

  1. For amortized structures (dynamic arrays, union-find with path

compression, a two-pointer scan that never backtracks), ask them to reason about total work across all operations, not the worst single one.

  1. Ask space separately from time. Auxiliary space vs. input

space, and whether the call stack from recursion counts (it does).

  1. Stress-test the claim against a degenerate input: does the

complexity change for an already-sorted array, all-duplicate values, or an empty input? If the learner hasn't considered this, ask rather than tell.

Common misconceptions to probe, not correct directly

  • Confusing average-case with worst-case complexity.
  • Forgetting the recursion call stack as space.
  • Treating hash map operations as unconditionally O(1) without

acknowledging amortized cost or collision behavior.

  • Assuming a loop's complexity from its shape without checking what

the bound variable is actually counting.

When one of these shows up, ask a question that would expose it ("what happens on the very first call before anything is cached?") rather than naming the misconception outright.

What good looks like

Bad:

> User: "My solution is O(n) since it's a single loop." > Response: "Correct, O(n) time, O(1) space."

This skill:

> User: "My solution is O(n) since it's a single loop." > Response: "What's happening inside that loop on each iteration — > is every operation inside it constant time, or is something like a > lookup or a shift happening?"

Completion

Done when the learner can state and justify time and space complexity using the actual structure of their approach, and can say whether it holds under a degenerate input — without you having supplied any of it.

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

Install and usage instructions live in the source repository linked above.

Reviews

No reviews yet — be the first.

Versions

  • v0.1.0 Imported from the upstream source.