Agent skill

L3 Core
the hundred problems that count

This repo indexes 3,270 problems and has solved every one on Blind 75 and NeetCode 150. The practice log's latest verdict on Blind 75 is ok for 14 of 75. More problems cannot move that; a fixed set, measured the same way every month, can. /l3-core pins the set — Blind 75 plus the NeetCode 150 problems marked MUST, 99 in all — reports where each one stands, and picks the next five.

Install it See the pipeline Read the source

/l3-core next 5

1  check      data/l3_core.json is up to date (98 problems)

2  status     L3 core: 98 problems (blind75 | (neetcode150 & readme:must))
              latest log verdict   ok 39 (40%)   again 24   no verdict 35
              chronic (again, 8+ attempts): 139, 91, 5, 128, 39, 206, 1143 …
              Backtracking  11   ok 0   again 5   none 6
              String         7   ok 0   again 2   none 5

3  next       371  Sum of Two Integers      Bit Manip   attempted 3×, no verdict
              217  Contains Duplicate       Hash Table  attempted 4×, no verdict
              242  Valid Anagram            String      attempted 3×, no verdict
               78  Subsets                  Backtrack   attempted 4×, no verdict
               56  Merge Intervals          Array       attempted 10×, no verdict

4  owed       /lc-log 371(ok|again), 217(ok|again), 242(ok|again),
                      78(ok|again), 56(ok|again)

A real run, 2026-09-23. Every pick came from the no-verdict bucket: 35 of the 98 have been attempted and never given an ok or an again, which is the cheapest number on the page to move.

Why a fixed set

A percentage needs a denominator that does not move

The September 2026 review found the loop that is not closing is solved → solid, and that nothing in the repo measured it on a set that stays still.

98problems on the set

40%latest log verdict is ok

24latest verdict is again

35attempted, never given a verdict

18chronic: again after 8+ attempts

Coverage is finished

Blind 75, NeetCode 150 and 250 and Top 100 Liked are 100% indexed and solved. The readiness script scores Volume and Breadth at A and says more problems cannot move the grade.

So: the planners that pick from all 3,270 are answering a question that is already answered.

The record that moves is the log

data/progress.txt is written daily. README's status column is updated when needed, so it lags — and it is what the landing page counts.

So: the verdict here is the log's latest annotation, with README quoted beside it.

Attempts without verdicts

A third of Blind 75 has been logged as a bare number or a todo — practised, but never told the schedule how it went.

Rule: every pick is handed back in the /lc-log shape, so the gap stops growing.

One pass, no branches

Six steps, in order

Pick one to see what it does and the rule that step exists to enforce.

What the set is

One rule, one file, one verdict per problem

The rule is code; the result is a committed file the roadmap reads; the verdict is whatever the log said last.

blind75 | (neetcode150 & readme:must)        -> 99 problems, Sep 2026

Half	Why
Blind 75	Every interviewer has seen it. The universal denominator.
NeetCode 150 ∩ MUST	`MUST` in README's status or Note column is the owner's own must-know verdict, so this half adds the NeetCode problems this preparation already decided matter — and nothing else.
not `google`	Tried first and rejected. The tag marks 37% of the index, so NeetCode 150 ∩ google came out at 147 — NeetCode 150 with three problems missing.

The result is data/l3_core.json — ids only. Titles, difficulty and links come from README at build time, the way every other roadmap list works, and the build fails if an id there is not in README.

The log's last word on it	Reported as
`139(ok)`, `70(ok*, o(1) space!!)`	`ok`
`139(again)`, `907(again!!)`, `(ok, but again)`	`again` — it beats `ok` when a note says both
`139(todo)`, a bare `139`, `139(mono stack)`	`none` — attempted, no verdict
not in the log	`never`

The log is parsed with the same helpers script/suggest_review.py uses — the label stripping, the top-level split, the classifier — so the two planners cannot disagree about what a line means. README's cell and its star run are shown beside the verdict as the slower-moving view.

1  never logged
2  attempted, no verdict          oldest first
3  latest verdict: again          oldest first
4  latest verdict: ok, 30+ days   stalest first

   a fresh ok            never offered
   logged in last 3 days never offered   --exclude-recent DAYS
   then round-robin across README sections

Sections are visited in the order of their best candidate, one problem each, until the session is full — the same shape as suggest_review.py's balanced pick, applied to a hundred problems instead of three thousand.

Arguments are inferred, not interrogated

How to call it

Ask for the state, ask for a session, or ask for the set to be rebuilt.

/l3-core
/l3-core next 5
/l3-core status --only again
/l3-core refresh

what should I drill today?
how is the core set looking?
which Blind 75 are still again?

Left out	What happens
A subcommand	`status` — the table and the summary.
The session size	Five. `next 3` or `next 8` to change it.
The recency window	Three days. `--exclude-recent 0` to allow today's problems back in.
The rule	Never an argument. It lives in `script/l3_core.py`, and changing it is a commit with a reason.

The guardrails

What it will not do

It reads two records and picks from one set. Everything that would make the number easier to move is out of bounds.

Change the rule to improve the number.The rule is code and the file is committed. The review names the rule it replaced and why; the next change gets the same treatment.
Report README's OK/AGAIN as the verdict.The log is the record. README is quoted beside it — useful, slower, never the answer.
Write the log or a README cell.That is /lc-log and /lc-again. This skill says what is owed to each.
Offer a fresh ok, or yesterday's problem.The set is for closing gaps. Re-proving what is solid is a different exercise, and today's session should not be tomorrow's.
Fill a session from one section.Round-robin is the whole point of picking five rather than the top five.
Store titles or links in the set file.Ids only. README is the source at build time, so the two can never disagree about a problem's name.

One markdown file and one script

Install

SKILL.md is the recipe; the commands it runs are in script/l3_core.py, which needs this repo's README.md, data/progress.txt and data/problem_lists.json. Pick your agent.

Drop the skill directory into your user-level skills folder and it loads in every repo:

git clone --depth 1 https://github.com/yennanliu/CS_basics.git /tmp/cs_basics
mkdir -p ~/.claude/skills
cp -r /tmp/cs_basics/.claude/skills/l3-core ~/.claude/skills/

Already installed inside this repo at .claude/skills/l3-core/, so a clone of CS_basics needs no setup at all. Claude Code matches it on the description, or you can call /l3-core by name — the directory name is the command.

Zip the directory, then Customize → Skills → + → + Create skill → Upload a skill:

cd .claude/skills && zip -r l3-core.zip l3-core

Leave the YAML frontmatter in SKILL.md intact. description is what Claude matches your request against when deciding to load the skill on its own.

Codex reads AGENTS.md at the repo root automatically. Point it at the skill:

## The L3 core set

When asked what to drill, how ready the core set is, or which Blind 75
problems are still coming back, follow `.claude/skills/l3-core/SKILL.md`.

A pointer, not a copy — one source of truth means a fix reaches every agent at once.

Same shape in GEMINI.md, or point at it for a single session:

gemini -p "Follow the recipe in .claude/skills/l3-core/SKILL.md. \
What should I drill today, and how is the set looking?"

Paste SKILL.md in as the system prompt. For Cursor or Windsurf, put the Codex pointer above into a rule file (.cursor/rules/l3-core.mdc or the editor's equivalent).

curl -sL https://raw.githubusercontent.com/yennanliu/CS_basics/master/.claude/skills/l3-core/SKILL.md

One caveat away from this repo: every step runs script/l3_core.py against this repo's log and index. The rule and the pick order are what transfer anywhere.

Under the hood

What is inside

The steps live in one file and nowhere else; the commands they run live in one script.

SKILL.md The recipe — why a fixed set, what the set is and the rule it replaced, where the verdict comes from, the five prime directives, the six steps, the do-not list, and the 2026-09-23 worked example.
script/l3_core.py status, next, refresh. Imports suggest_review.py's README and log parsers rather than carrying its own; unit-tested by script/test_l3_core.py, which also pins data/l3_core.json to the rule.
data/l3_core.json The generated set — rule, count, ids. Read by site/build-roadmap.js as the roadmap's L3 core list, which fails the build if an id is not in README.

Gated in CI by check_skills.py — frontmatter every host can parse, the directory name pinned to the command name, the read-only commands actually executed, and whether the links on this page still resolve.

The rest of the loop

Where it fits

The roadmap shows the same set as its L3 core list. /l3-core picks the session; /lc-log records how it went; /lc-again moves README when a problem finally stuck; LC Coach scores the attempt the way an interviewer would. The review plan and suggest review still plan over everything — this is the narrow one.

L3 Corethe hundred problems that count