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.

설치로 이동

소스 정보

저장소
Cantara/knowledge-context-protocol
최근 소스 활동
2026년 6월 13일 07:54
감지된 SKILL.md 언어
영어
스타
31
포크
2

설치 방법

기본적으로 소스를 먼저 확인하는 Prompt가 선택됩니다. 직접 명령으로 전환하거나 로컬 사본을 다운로드할 수도 있습니다.

소스 파일 검토

설치 여부를 결정하기 전에 SKILL.md와 SkillsMP에 표시된 보조 파일을 읽어 보세요.

SKILL.md 표시 중

SKILL.md
소스 지침 · 읽기 전용 미리보기
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.
GitHub에서 보기