AB kb-keyword-graph
Keyword-graph reader for a knowledge base. Trigger when the user wants to understand a KB — "what's in it / what does it cover / knowledge structure / topic distribution / main themes / how do these materials relate", or explicitly says keyword graph / knowledge graph / word cloud / 关键词图谱 / 知识结构 / 主题分布. It pulls the KB's three-level keyword tree and interprets it four ways: ① structure (knowledge outline) ② graph (progressive interactive ring chart) ③ topics (topic distribution) ④ relate (how two keywords relate in the tree). Covers even when the user doesn't say "graph" (e.g. "what's in this library"). Current backend: 2brain (locate a library by base_id). Read-only — it never ingests, builds, edits, or Q&A-chats a KB, and does not route to Feishu/Lark Wiki or cloud docs.
Keyword-graph reader for a knowledge base.
As a process B 65/100 · Nearly there — weak spots: result and completion, running it twice
How to improve
- Your own cases (evals/evals.json, 4–6 real requests with expected answers): the full check would then run those instead of a model-drafted suite.
- A spec.yaml with trigger phrases and assertions — a behaviour contract for CI; `skilltest init` writes a template.
Guard findings · 0
✓ No critical or high findings
Files scanned: 9. Evidence is masked. Grey chips explain why severity was lowered.
Against the Agent Skills spec
✓ No remarks against the Agent Skills spec
Process rating: all ten parameters 65/100
- 0Result and completion. Does not say what the result is
- 30Running it twice. 4 mutating operations with no state check
- 60Tools and files. Uses tools (bash, web, python, node) that frontmatter does not declare
- 60Failures and branches. 2 branches
- 70When it triggers. States when to use, but not when not to
- 70Inputs and preconditions. Inputs and preconditions are listed
- 100Steps. 16 steps
- 100Consistency. Name and required fields are in place
- 100Execution cost. Instruction body is 2236 tokens
- 100Progress reporting. Reports progress
- medium Safety rules and hard prohibitions inside a skill: they belong in the system prompt, here they protect nothing
Everything here is measured from the skill text rather than judged by a model, so the numbers are checkable. A parameter weighs more when it is a more common reason for the process to stall.
Quality signals
- +5Description has no quoted example phrases that should trigger the skill
- +4Description does not say when NOT to use the skill (false activations)
- +3Output format is not stated: the model decides each time
- -2localhost URLs: will not work for another user
- +2Single-language instructions
- +3Description length 783: enough signal without eating the budget
- +4Structure: 9 headings
- +3Step-by-step instructions: 16 items
- +4Has examples (4 code blocks)
- +4Reference files are cited in the instructions (2 of 4)
- +3All 2 scripts are documented
- +1License stated
Quality base 70; lint remarks subtract, signals add up to 100. Result: 90.