saker-knowledge

name	saker-knowledge
description	Use KnowHub domain knowledge through MCP before answering Saker architecture, product, operations, security, or agent-skill questions.
allowed-tools	knowledge.list_domains, knowledge.search, knowledge.ask, knowledge.get_source, knowledge.list_providers, knowledge.validate_okf
keywords	["saker","knowhub","knowledge","architecture","operations","evidence","citations"]
user-invocable	true

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, newer updated_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.