Skip to main content

kcp-author

Write or improve units in a KCP knowledge.yaml manifest — effective intents, triggers, relationships, audience targeting, negative-space (not_for), and temporal validity — and validate them. Use when editing a knowledge.yaml, when an agent keeps loading the wrong unit for a task, or when manifest queries return poor matches.

Ir para a instalação

Informações da origem

Repositório
Cantara/knowledge-context-protocol
Última atividade na origem
13 de junho de 2026 às 07:54
Idioma detectado do SKILL.md
inglês
Estrelas
31
Forks
2

Opções de instalação

Por padrão, está selecionado o prompt que primeiro revisa a origem. Você pode mudar para um comando direto ou baixar uma cópia local.

Revise os arquivos de origem

Leia o SKILL.md e os arquivos complementares exibidos pelo SkillsMP antes de decidir se vai instalar.

Exibindo SKILL.md

SKILL.md
Instruções da origem · Visualização somente leitura
name
kcp-author
description
Write or improve units in a KCP knowledge.yaml manifest — effective intents, triggers, relationships, audience targeting, negative-space (not_for), and temporal validity — and validate them. Use when editing a knowledge.yaml, when an agent keeps loading the wrong unit for a task, or when manifest queries return poor matches.
# Author effective KCP units A manifest is only as good as its routing. The job is to make the right unit win for the right question and never load for the wrong one. ## When to use Someone is editing a `knowledge.yaml`, query results are off (wrong unit, or no match), or a manifest needs richer metadata (relationships, negative space, validity windows). ## What makes a unit route well - **`intent` is the question, not the title.** "How do I authenticate a request?" beats "Auth docs". Agents match against this in natural language. - **`triggers` are the words that question contains.** Include synonyms and the domain terms a user would actually type (`auth, login, oauth, token, sso`). Keep each ≤ 60 chars, ≤ 20 per unit. - **`not_for` prevents misfires** (RFC-0015, §4.20). If a unit is tempting but wrong for a class of task, say so: `not_for: ["billing questions", "frontend routing"]`. Add `not_for_strict: true` for a hard exclusion rather than a soft demotion. - **`scope` and `audience` narrow the field.** `audience: [agent]` for agent-only entry points; `[human]` for content agents should not surface. - **`content_structure`** (RFC-0016, §4.19) lets RAG route before fetching: `primary: table | prose | code | …`, `density: sparse | normal | dense`. ## Relationships and ordering - `depends_on: [id]` — load these first (reading order). - A `relationships` block expresses typed edges: `enables`, `context`, `supersedes`, `contradicts`, `depends_on`, `governs`. ## Temporal validity (when knowledge changes over time) Use a `temporal` block (RFC-0010, §4.22) for policies and runbooks that expire or are future-dated: ```yaml temporal: valid_from: "2026-04-01" # activates on this date (future-dating is fine) valid_until: "2026-06-30" # null = open-ended superseded_by: deploy-v2 # successor unit id; keeps an audit trail ``` `superseded_by` must not form a cycle, and an expired `valid_until` should name a `superseded_by` — the validator warns otherwise. ## Always finish by validating ```bash kcp validate # fix errors; warnings are advisory kcp query "<a real user question>" # confirm routing ``` Iterate until each obvious question returns the unit you intended. See `SPEC.md` for the full field set; `guides/` for worked examples.
Ver no GitHub