Knowledge Base vs AI Skill vs SOP Doc: Where Each One Should Live

A wiki answers “what is true right now?” A skill answers “how do we produce this specific deliverable, using these sources and checks?” The workflow should reference the wiki instead of copying its contents into instructions.

An SOP may describe roles, policy, and exceptions broadly. A skill turns one repeatable segment into ordered steps, output requirements, and a review gate. Keep the SOP as the human context when the job extends beyond the run.

A prompt can be a useful local instruction, but it is not a dependable home for policy, facts, ownership, or procedure history. Treat personal prompts as experiments until the job earns a shared package.

Put durable explanations, policies, product facts, decisions, and broad process documentation in the workspace where people can maintain and browse them. Give each document an owner and a clear canonical status.

Keep the trigger, input contract, procedure, output template, checks, refusal rules, small stable references, scripts, tests, and version notes in the skill package. These materials define how the job runs.

Account records, live tickets, call transcripts, project files, and current metrics belong in the systems that produce or own them. The skill should request them by reference or through an approved connection for the specific run.

Every copied policy or product fact creates a competing version that can go stale. Duplicate only when a stable snapshot is required for an audit or test; otherwise link to the canonical source and name its freshness rule.

List the allowed sources, their purpose, and precedence when they disagree. A good skill tells the operator what it may trust, how current it must be, and what to do when the source is missing.

If a skill uses a newer approved rule than the wiki, make the mismatch visible and assign an owner to reconcile it. Do not let a workflow quietly become the only accurate place where the team learns a policy.

If required data is unavailable, sources conflict, a decision is outside the defined job, or the task requires an authorized commitment, the skill should stop and state the escalation path.

Search helps someone find context or policy; routing decides that a defined job should run. A knowledge search result should not automatically become a workflow invocation without the required inputs and boundaries.

Document owners maintain facts and policy. Workflow owners maintain the procedure, tests, integration, and release notes. They coordinate when a source change affects output, but they do not need to be the same person.

Show operators where facts live, what the skill does, which inputs they must prepare, and who decides exceptions. Tool training alone encourages people to paste whatever they can find and hope the output is right.

Look for clusters of documents that all describe the same repeated deliverable. Preserve the reference material, then package the three repeatable jobs that actually consume it rather than converting every document into an instruction.

Group prompt variants by the job they attempt, identify the reliable source set and output standard, and turn the five recurring jobs into owned skills. Retire the variants only after the shared version has passed real-work tests.

Replace broad paste requests with an input checklist: which canonical sources, which run record, which date range, and which missing fields block the output. This reduces both cognitive load and accidental source mixing.

When a policy, product process, or source schema changes, evaluate affected skills, rerun relevant tests, and update their release notes. The version history should point to the source change that required it.

Installing a skill in several tools makes the procedure available where people work; it does not create an authoritative knowledge base. Continue to maintain canonical content in the system designed for it.

Use this mental model: source systems hold facts and live records; the skill package holds the procedure and checks; the target tool runs the job; the reviewer approves the outcome; the changelog records what changed.

Grokkit maps the sources a workflow may use, writes the rules that govern the job, and defines a reviewable outcome before testing. That keeps a skill narrow enough to trust and connected enough to be useful.