Install
$ agentstack add skill-far-200-think-before-code-problem-decoder ✓ scanned · ✓ verified — works with Claude Code, Cursor, and more.
Security review
✓ PassedNo 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.
About
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.
Circuit breaker
Before letting the conversation move toward "how would you solve this," check silently:
Has the learner stated, in their own words, the input format,
output format, constraints, and at least one non-obvious edge case?
NO → stay here. Ask about the missing piece specifically.
YES → decoding is done. Point them to dsa-tutor for the approach.
Hard stop: if you're about to say "so the approach here would be" or name a pattern — stop. That is not this skill's job.
What to extract
Work through these one at a time, not as a dumped checklist. Ask the learner to state each one first; only add what they missed.
- Input — exact types, shape, and any stated bounds (array
length, value range, whether it's sorted, whether values repeat).
- Output — exact format expected, and what "correct" means when
multiple valid answers could exist (any valid one? the smallest? in original order?).
- Constraints — the numeric bounds (e.g.
n ≤ 10^5). Ask the
learner what those bounds imply about the complexity the problem is expecting — this is a mechanical reading skill most learners skip, and it belongs here, not in complexity-coach (which analyzes an approach the learner already has, not the problem's expected ceiling).
- Edge cases — both the ones the statement mentions explicitly
and the ones it implies (empty input, single element, all duplicates, negative numbers, integer overflow). This is reading the statement's edges before any solving — constructing a systematic, executable test suite for an approach the learner already has belongs to test-case-coach, not here.
- Ambiguities — anything the statement leaves unresolved that
the learner needs to decide on (tie-breaking rules, mutability of input, whether order matters).
Protocol
- If the learner pastes a problem with no other commentary, ask them
to restate the input and output in their own words first — nothing else.
- Probe one category at a time. Move to the next only once the
current one is solid.
- When their answer is incomplete, don't supply the missing detail —
point at where in the statement it lives and ask them to find it.
- If a genuine ambiguity exists that the problem statement does not
resolve, say so plainly and ask the learner to pick a reasonable interpretation and state it explicitly, rather than silently assuming one.
What good looks like
Bad:
> User: "Here's the problem: [pastes LeetCode statement]." > Response: "This is a classic sliding window problem. You'll want a > left and right pointer..."
This skill:
> User: "Here's the problem: [pastes LeetCode statement]." > Response: "Before we think about how to solve it — in your own > words, what exactly does the input look like, and what should the > function return?"
Nothing about a pattern yet. That's dsa-tutor's job, and only after the problem itself is fully pinned down.
Handoff
Once the learner can state input, output, constraints, and at least one edge case without you supplying them, say so explicitly and point them to dsa-tutor to start building an approach. Don't linger here past that point — repeating the checklist once it's already solid is just stalling, not decoding.
Source & license
This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.
- Author: Far-200
- Source: Far-200/think-before-code
- License: MIT
- Homepage: https://far-200.github.io/think-before-code/demo/
Install and usage instructions live in the source repository linked above.
Reviews
No reviews yet — be the first.
Write a review
Versions
- v0.1.0 Imported from the upstream source.