Kb review
对话式 agent(Claude Code / Codex)驱动的本地知识库编译器:把 PDF/DOCX/PPTX/Markdown 增量编译进一个去重、互联、可复现的 Obsidian 学习知识库。
npx -y skills add Iabstergo1/pdf-to-study-kb --skill kb-reviewAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
Work the Review-Queue and review_proposals items one by one (lint failure lists, cross-domain promotion candidates, overwrite-protection-rejected change proposals), giving analysis and fix suggestions; the final accept/reject is the user's. Use when the user says "work the review queue / look at the pending items / what's in the Review-Queue / walk me through the review backlog".
SKILL.md
4.7 KB, as published. Nobody here has run it
kb-review — Review-Queue processing
Work wiki/Review-Queue/ and review_proposals items one by one. By default it only analyzes and
suggests; the final accept/reject is the user's. The execution layer is scripts/pipeline.py; this
skill only orchestrates, surfaces acceptance, and marks failure stops.
1. Triggers / Non-triggers
- Triggers: "work the review queue", "look at the pending items", "what's in the Review-Queue", "walk me through the review backlog", "handle the lint failures / cross-domain promotions / overwrite proposals".
- Non-triggers: ingesting a new source (use
ingest); read-only queries (usekb-query); saving a query result (usekb-save); a whole-vault semantic check (usewiki-lint-semantic); never accept a proposal or edit a human page without user confirmation.
2. Inputs
wiki/Review-Queue/*.md: lint failure lists,promotion-*.md,*-proposal.md, semantic-lint reports.- The machine ledger: the
review_proposalstable, viapython scripts/pipeline.py statusor related CLI state. - Relevant vault pages, the concept registry, source state.
3. Outputs
- For each item: a classification, the risk, a suggested fix, and whether a user decision is needed.
- After the user confirms, execute the matching fix/promotion/marking; without confirmation, do not edit the target.
- Append
> handled: <conclusion>to a processed Review-Queue item, or note that it still awaits the user.
4. Dependencies
- CLI:
status,lint,promote-concept,rebuild-registry; if needed, return toingestor the target source's lint loop. - Protocols:
docs/skill-runtime/schema.md,concept-resolution.md,save-back-policy.md. - Human-page protection stays top priority: a human page is edited by the user, never auto-overwritten by the skill.
5. Persisted artifacts
- The handled-markers on
wiki/Review-Queue/*.md. - If the user confirms a fix: the matching proposed page, the registry-derived rebuild, or a new proposal.
- The machine
review_proposalsstays the ledger; this skill does not hand-write the database.
6. CLI commands
python scripts/pipeline.py status
python scripts/pipeline.py lint --source <source_id>
python scripts/pipeline.py promote-concept --id <canonical_id>
python scripts/pipeline.py rebuild-registry
python scripts/pipeline.py proposals-resolve --signature <kind> [--source <src>] --all-matching --apply
Run vault-changing commands (e.g. promote-concept / page fixes / marking handled) only after user confirmation.
After a fix is verified, retire the matching review_proposals rows with proposals-resolve (dry-run
first, then --apply after user confirmation) so the skill-mine backlog stops counting fixed signals.
7. Workflow
| Sub-unit | Input | Output | Acceptance | Persisted | Failure stop |
|---|---|---|---|---|---|
| R1 collect queue | Review-Queue + status | pending list | files and ledger aligned | — | queue missing |
| R2 classify | one item | lint/promotion/coverage/semantic/overwrite class | class maps to a fix path | analysis draft | type unclear |
| R3 suggest | item + related pages | fix/reject/promote suggestion | states risk, affected pages, commands | chat output | evidence thin |
| R4 user confirm | user decision | execute or reject | no target edit without confirmation | Review-Queue mark | human-page conflict |
| R5 verify loop | fix result | lint/rebuild/check result | the command passes or re-enqueues on failure | new proposal/mark | verify fails |
8. Failure stops / recovery
User has not confirmed; target managed_by: human; cross-domain promotion semantics unclear; a homonym
promotion; a lint fix would exceed the write scope; promote-concept or rebuild-registry fails; an item
lacks evidence. Recovery: unresolved items stay in Review-Queue with their state; re-run the matching
lint after fixes.
9. Acceptance criteria
- Every pending item has a class, a suggestion, and a user-decision state.
- No target vault page edited without user confirmation.
- A promotion-candidate has been judged "semantic reuse vs homonym".
- After a confirmed promotion,
promote-concept+rebuild-registrywere run. - After a lint-violation fix, the matching
lintwas re-run; failures stay in Review-Queue. - No human page was auto-overwritten.
Gives 0 of the 12 instructions most review quality skills give
Counted across 1,048 of the 1,783 authors here whose files we hold, read 2026-08-06
- ask questions one at a timein 82 of 1048, across 54 files
- provide a recommended answer for each questionin 73 of 1048, across 45 files
- explore the codebase instead of asking answerable questionsin 66 of 1048, across 37 files
- resolve dependencies between decisions one-by-onein 42 of 1048, across 15 files
- interview the user relentlessly about the planin 39 of 1048, across 12 files
- order findings by severityin 29 of 1048
- resolve each branch of the decision treein 28 of 1048, across 5 files
- run a grilling sessionin 26 of 1048, across 5 files
- update CONTEXT.md immediately when a term is resolvedin 26 of 1048, across 9 files
- propose precise canonical terms for vague languagein 25 of 1048, across 6 files
- create documentation files lazilyin 24 of 1048, across 5 files
- use the domain-modeling skillin 22 of 1048, across 3 files
Said here and by no other author read
- work review queue items one by one
- classify each pending item
- state the risk and affected pages
- suggest a fix rejection or promotion
- require user confirmation before editing targets
- run vault-changing commands only after confirmation
Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once.