saker-knowledge
Skill7 starsChanged 8 months agoMITView on GitHub
Use KnowHub domain knowledge through MCP before answering Saker architecture, product, operations, security, or agent-skill questions.
In this repositoryOne other file it gives its agents.
- skillhubSkill
The file
Show its rules and text
We split this skill into the rules it gives an agent
16 rules. About 0 are common, 10 are distinctive, and 6 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈10
Distinctive · estimate
This author's own choices. Worth a look.
6
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 11
Use this skill whenever a user asks about Saker platform architecture, module responsibilities, deployment, operations, security policy, …
- Distinctive: line 15
Before answering a Saker domain question, call:
- Very specific: line 21
Use another domain only when the question clearly belongs there or when knowledge.list_domains shows a better domain.
- Distinctive: line 28
If the first search returns weak or missing evidence, refine once with a narrower query or a more specific domain before answering.
- Very specific: line 30
Use knowledge.ask only when the caller explicitly wants a concise evidence-grounded answer facade from KnowHub.
- Very specific: line 36
Prefer evidence with a higher confidence, newer updated_at, and a source that matches the requested module or domain.
- Very specific: line 37
Use knowledge.get_source(source_id=...) when a search hit is ambiguous, truncated, or needs source-level context.
- Very specific: line 38
Do not expose tenant_id, permission labels, provider credentials, internal JWTs, API keys, OpenViking keys, DashScope AccessKeys, or …
- Distinctive: line 39
Do not call PandaWiki, DashScope, OpenViking, vector stores, or any provider directly.
- Distinctive: line 43
Use concise grounded answers:
- Distinctive: line 52
When citing multiple evidence chunks from one source, group them under the same source entry and mention the relevant section path when …
- Distinctive: line 54
If evidence is insufficient, say so directly:
- Distinctive: line 61
Do not fill gaps with speculation.
- Distinctive: line 65
When asked to review or import knowledge content, call:
- Very specific: line 75
When answers are unexpectedly empty, slow, or inconsistent, call knowledge.list_providers and report provider health only at status level:
- Distinctive: line 83
Never report provider secret configuration values.
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Saker Knowledge
Use this skill whenever a user asks about Saker platform architecture, module responsibilities, deployment, operations, security policy, agent behavior, skills, internal APIs, troubleshooting, or product capability claims that should be grounded in Saker-maintained knowledge.
Required Lookup
Before answering a Saker domain question, call:
knowledge.search(domain="saker-architecture", query=<user question>, top_k=8)Use another domain only when the question clearly belongs there or when knowledge.list_domains shows a better domain. Common domains:
saker-architecture: modules, service boundaries, protocols, auth, WebHub, KnowHub, SkillHub, ChatHub, AIHub, StockHub.saker-devops: deployment, configuration, recovery, local stack operation.security-compliance: permissions, audit, tenant isolation, token handling.ai-agent-skills: skill authoring, agent runtime rules, evidence use.
If the first search returns weak or missing evidence, refine once with a narrower query or a more specific domain before answering.
Use knowledge.ask only when the caller explicitly wants a concise evidence-grounded answer facade from KnowHub. For implementation decisions, reviews, or multi-step reasoning, prefer knowledge.search first so you can inspect evidence directly.
Evidence Rules
- Base the answer on KnowHub evidence, not memory.
- Cite the source for every factual claim that depends on retrieved knowledge.
- Prefer evidence with a higher
confidence, newerupdated_at, and a source that matches the requested module or domain. - Use
knowledge.get_source(source_id=...)when a search hit is ambiguous, truncated, or needs source-level context. - Do not expose
tenant_id, permission labels, provider credentials, internal JWTs, API keys, OpenViking keys, DashScope AccessKeys, or long-lived download URLs. - Do not call PandaWiki, DashScope, OpenViking, vector stores, or any provider directly. KnowHub is the only knowledge boundary.
Answer Format
Use concise grounded answers:
<answer>
Sources:
- <title> (<source_id>, <updated_at>)When citing multiple evidence chunks from one source, group them under the same source entry and mention the relevant section path when available.
If evidence is insufficient, say so directly:
KnowHub does not have enough evidence to answer this reliably. The closest evidence shows ...
Missing evidence: ...Do not fill gaps with speculation. If the user needs an implementation decision and evidence is incomplete, provide the decision as a recommendation and label it as an inference.
OKF Validation
When asked to review or import knowledge content, call:
knowledge.validate_okf(content=<markdown or bundle manifest text>)Report validation errors first, then warnings. Treat missing title, updated_at, or owner front matter as blocking errors. Treat missing citation links as a quality warning unless the caller explicitly requires citation-complete content.
Provider Health
When answers are unexpectedly empty, slow, or inconsistent, call knowledge.list_providers and report provider health only at status level:
- provider id
- type
- healthy/unhealthy
- latency
- last error
Never report provider secret configuration values.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

