lean-ctx-review
Review how the lean-ctx ctx_* MCP tools performed in the current session and file upstream issues for confirmed problems. Use when the user asks to review/audit lean-ctx tool performance, says "lean-ctx review", asks why ctx_* tools failed or fell back to native tools, or wants to report a lean-ctx bug.
Оригинален текст · няма потвърден превод на българскиПърво прочетете инструкцията.
Файлът се зарежда от посочения източник само по ваше действие. Можете да го прочетете тук, да го копирате или да го запазите като .md.
GitHub хранилище- Звезди на репото
- 3825
- Лиценз
- Apache-2.0
- Последна проверка на записа
- 22.09.2026 г.
Добавете в своя инструмент.
Командата отваря избора на skills от репозитория. Прочетете файла и условията на автора преди изпълнение.
npx skills add yvgude/lean-ctxСтраницата копира текст. Не инсталира и не изпълнява нищо на устройството ви.
Откъс от SKILL.md
Началото на файла на автора, без превод.
lean-ctx session review
Upstream repo: yvgude/lean-ctx (https://github.com/yvgude/lean-ctx).
Reads a Claude Code session transcript, so it applies to agents that write
~/.claude/projects/*/*.jsonl. Other harnesses need their own extractor; the
triage rules below are harness-independent.
1. Extract
Run from this skill's directory (needs python3):
python3 scripts/scan_session.py
Defaults to the newest transcript under ~/.claude/projects/*/ — the live
Claude Code session. Pass a path to review a different one. -d N dumps call
#N in full.
The script reports facts, not verdicts: every ctx_* call in order, which
results the harness flagged is_error, which calls repeated identical
arguments, which asked for raw/fresh output, and how many native
Read/Grep/Bash calls happened. It deliberately does not guess which of
those is a problem — that judgment is yours, below.
Transcripts run to megabytes, so read the table, not the raw JSONL.
2. Triage
Start from is_error. In practice every genuine tool failure carries it.
Then read the call list for the softer signals: identical retries, raw/fresh
re-reads, native calls clustered right after a ctx_* call, or a sequence that
only completed once ctx_* was abandoned.
Before absolving anything, do these two things
Skipping them is how this review returns a false "nothing to report". Both cost one command each.
Search the tracker for the guard or tool you are about to excuse. Do this during triage, not at step 4. A closed issue defines intended behaviour: if a shipped fix says a form is supported and you just watched it fail, that is a regression and one of the most valuable things this review finds. It also stops you re-filing a settled design decision.
gh issue list --repo yvgude/lean-ctx --search "<guard or tool keyword>" --state all
Probe the stated rationale — never accept a message's self-description. An error explains itself, and that explanation can be wrong. Three checks, each one command: