Generate Skills from Knowledge Documents
Purpose
Convert existing knowledge docs (one or many) into discoverable, reusable Agent Skills that follow a consistent, lintable structure and progressive disclosure.
The generate-skills-from-knowledge skill is provider-agnostic: the output is plain folders + SKILL.md files and can be consumed by any agent runtime that discovers skills from the filesystem.
When to use
Use the generate-skills-from-knowledge skill when you have:
- •A set of Markdown/text docs that describe how work should be done, and you want to convert them into skills.
- •Legacy "how-to" docs that are too long or too project-specific and need to become portable skills.
- •Multiple docs with overlapping guidance and you want to split/merge them into capability-oriented skills.
Do not use the skill when:
- •The source material is confidential and cannot be copied into a work area.
- •You only need a quick summary; you do not need reusable procedures.
Inputs
You MUST provide:
- •Source documents: one or more file paths (prefer Markdown). If not Markdown, provide a plain-text export.
- •Output target:
- •
skills_root(directory where the generated skills will be written), OR - •a writable working directory to create a standalone skills bundle.
- •Portability constraints:
- •whether to remove provider-specific terms,
- •whether project paths/scripts should be generalized,
- •any allowed exceptions (for example, "dev-docs may keep repo-specific layout").
- •
You SHOULD provide:
- •Desired taxonomy (optional): up to two tiers (e.g.,
backend/common,frontend/components,workflows/common). - •Existing naming conventions for skill names (kebab-case verb + domain).
Outputs
The expected outputs are:
- •A set of skill directories, each containing:
- •
SKILL.md(required) - •
reference.md(optional, for deep details) - •
examples/(optional, scenario-specific examples) - •
templates/(optional, reusable snippets/skeletons)
- •
- •A
CONVERSION_REPORT.mdsummarizing:- •source documents
- •created/updated skills
- •split/merge operations
- •known limitations / follow-ups
- •A lint report (stdout) from
python3 ./scripts/skillgen.py lint ...(recommended)
Command working directory
All relative paths in commands (for example ./scripts/skillgen.py and ./templates/...) are relative to:
- •
.ai/skills/workflows/skill-operation/generate-skills-from-knowledge/
Steps
Scenario A: Convert docs into a skills bundle (recommended default)
- •Inventory the source docs (file list) and decide what is IN/OUT of scope.
- •Derive candidate skills:
- •one skill should map to one capability (not one file),
- •split long docs into multiple skills by trigger/intent,
- •merge overlapping docs when they solve the same intent.
- •Create a conversion plan using
./templates/conversion-plan.schema.json:- •define the skills to create,
- •map each skill to its source docs,
- •define which examples/templates to extract.
- •Review the plan and obtain approval before writing files:
- •confirm the skill taxonomy and naming
- •confirm portability constraints (remove provider/project specifics)
- •confirm what will be created vs updated
- •Run:
- •
python3 ./scripts/skillgen.py apply --plan <plan.json>to scaffold the skill directories.
- •
- •For each generated skill:
- •rewrite
SKILL.mdto be high-signal and short, - •move large examples into
examples/, - •move reusable snippets into
templates/, - •put deep rationale into
reference.md, - •remove cross-skill links ("See also", "Related docs").
- •rewrite
- •Run:
- •
python3 ./scripts/skillgen.py lint --skills-root <skills_root>and fix issues until clean.
- •
- •Package the bundle (optional):
- •
python3 ./scripts/skillgen.py package --skills-root <skills_root> --out <bundle.zip>
- •
Scenario B: Convert docs directly into a repository skills root
Follow Scenario A, but set skills_root to the repository's skills SSOT directory.
If your repo has additional syncing rules (provider stubs, monorepo layouts), treat those as outside the scope; the skill only produces the SSOT-format skills.
Boundaries
- •You MUST NOT include secrets, credentials, or internal-only URLs in generated skills.
- •You MUST NOT copy large logs or whole source documents verbatim into
SKILL.md. - •You SHOULD avoid hard-coded repository paths unless the target is explicitly a known repo-local convention (for example
dev-docs/) with an agreed layout. - •You MUST keep each
SKILL.md<= 500 lines by moving detail intoreference.md,examples/, andtemplates/.
Verification
Run the linter and confirm:
- •the conversion plan was reviewed and approved before applying
- •every skill directory contains
SKILL.mdwith valid YAML frontmatter - •
namematches the directory name - •no
resources/directories exist - •
SKILL.mdline count is within limits - •examples/templates live under
examples/andtemplates/rather than bloatingSKILL.md - •cross-skill relative links (e.g.,
../<other-skill>) are absent
Included assets
- •
./scripts/skillgen.py: plan/apply/lint/package helper - •
./scripts/init_skill.py: optional helper to scaffold a new skill directory - •
./templates/conversion-plan.schema.json: JSON Schema for a conversion plan - •
./templates/conversion-plan.example.json: example plan - •
./templates/skill-skeleton/SKILL.md: copy/pasteable skeleton for manual skill authoring - •
./examples/quickstart.md: end-to-end usage example - •
./examples/plan-writing-guide.md: how to write a good plan for an LLM