Three related half-applied changes from #130, each leaving the corpus in a state its own documentation contradicts. Why: - `assets/templates/SKILL.md` shipped `metadata:` fully commented out, and `new-skill.sh` only substitutes SKILL_NAME. Every scaffolded skill therefore lacked the `metadata.version` ADR-0022 made mandatory and was blocked at first commit by the very hook this PR added. The commented example also read `"1.0"` — neither the `0.1.0` new-skill seed nor valid semver. - `agent-audit/references/scope-project-user.md` still joined `disable-model-invocation` and `user-invocable` with a slash — #125's defect verbatim — while pointing the reader at the file this PR had just corrected to say the opposite. - ADR-0022 required the "when present" bump conditional dropped and `metadata.version` moved into create.md's required list. It was dropped from SKILL.md but left in README.md, and the field was edited in place under a heading that still authorises removing it entirely. Implementation notes: - The template emits `metadata: version: "0.1.0"` live, captioned as required, with the optional keys left commented. `new-skill.bats` gains a case asserting a live key and three-part semver, so this cannot regress. - `description-quality.md` now asserts only what the vendored Copilot research supports: two fields with opposite defaults, and the retired `infer` replaced by the pair rather than by either alone. The unsupported negative it previously stated as fact is gone. - The `1.0.0` retrofit seed is stated in improve.md and retrofit.md, which the retrofit flow actually reads — create.md, where it lived, is unreachable from that path. The compression item moved out of the file-churn checklist, whose preamble excluded the wording-only change it covers. - Executable git commands in these three skills now carry the ADR-0023 rtk prefix. Refs: #125, #127 ADR: 0022, 0023 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01EeH8SCbcrCAQrtymkNuhKP
8.7 KiB
source_keys
| source_keys | |||||
|---|---|---|---|---|---|
|
Creating a new skill
Return to SKILL.md Step 4 once Step 6 below is done — validation, versioning and commit
verification are shared with the improve flow and are not repeated here.
Prerequisites
Run /grill-me on the skill's design and research the target domain first. Share those outputs
in this conversation: grill context, research docs, examples, constraints.
Design for one coherent user intent — skills too narrow force multiple loads per task; too broad are hard to activate precisely.
Before touching the filesystem, verify you have:
- A clear purpose — what specific task will this skill handle?
- Trigger scenarios — when should an agent activate it?
- Skill name (kebab-case) and destination path
If any are missing, stop and ask the user before proceeding.
Requires /skill-audit — used in SKILL.md Step 4 for final validation. Both skills ship in
the kyberforge plugin and are co-installed. If /skill-audit is unavailable, stop and ask the
user to install the kyberforge plugin before continuing.
Package-intent gate
Judge whether the destination is meant to be inside an APM package before running the scaffold script — the script cannot tell "no package here" apart from "package not scaffolded yet":
- Package intent but no
type:-bearingapm.ymlfound at or above the destination (e.g. "add to my apm package", or a sibling.apm//apm.ymlexists nearby) → stop, tell the user to run/apm-workflow configure(apm plugin init, from inside the package directory) first, then retry. Do not fall through to standalone mode. - Otherwise (a
~/-rooted destination, or no package context implied) → continue to Step 1.
Step 1 — Scaffold
Run the copy script with the skill name and a path inside or at the target:
bash scripts/new-skill.sh <skill-name> <path>
The script walks up from <path> for a package boundary: an ancestor apm.yml with a top-level
type: field (instructions/skill/hybrid/prompts) means package mode — scaffolds into
<package-root>/.apm/skills/<skill-name>/, not under <path> (a subdirectory of the package
works fine as <path>). A type:-less apm.yml is a marketplace-only manifest, skipped. Hitting
.git or the filesystem root first means standalone mode — scaffolds directly into
<path>/<skill-name>/.
Examples:
# Package mode — packages/my-pkg/apm.yml already has `type: skill`
bash scripts/new-skill.sh my-tool packages/my-pkg/
# Standalone mode — no apm.yml/.git above ~/.agents/skills/
bash scripts/new-skill.sh my-tool ~/.agents/skills/
The script prints which mode it used and where the skill landed — read its output.
In package mode, read references/deployment-modes.md before adding any file references to
SKILL.md.
Step 2 — Update apm.yml includes (package mode only)
Skip in standalone mode. In package mode, check the resolved package's apm.yml: if includes:
is an explicit list (not auto), append .apm/skills/<skill-name>/ to it if not already present,
preserving YAML formatting. If includes: auto or the field is absent, do nothing — auto
already covers the new skill. Use Read/Edit directly on apm.yml; this is not part of
scripts/new-skill.sh.
Step 3 — Fill in SKILL.md
Open the new skill's SKILL.md (the path Step 1 printed) and replace every FILL IN:
placeholder. The scaffold template carries the ADR-0020 body skeleton and the two frontmatter
fields that cannot be left as placeholders — name, substituted by the script, and
metadata.version, seeded live at "0.1.0" — so fill the template in rather than restructuring
it.
name — already set by the scaffold script. Must exactly match the directory name. Format:
1–64 characters, lowercase letters, numbers and hyphens only; no leading, trailing or consecutive
hyphens (--).
description — carries the entire triggering burden and is preloaded every session. Write it
against references/contract.md, which holds the three-part shape, the banned content, the
boundary-clause form and the length tiers. A hand-invoked skill (SKILL.md Step 2) takes one
plain sentence and disable-model-invocation: true instead.
metadata.version — required on every skill (ADR-0022), not a per-skill or per-plugin choice,
and enforced by the skill-frontmatter pre-commit hook. The scaffold seeds a new skill at
"0.1.0"; leave that value alone here and let SKILL.md Step 4 bump it. ("1.0.0" is the seed
for a pre-existing skill retrofitted into the rule, and never applies to a skill created here.)
Optional frontmatter — uncomment and fill in, or remove entirely:
license— include when distributing the skill externallycompatibility— include if the skill requires specific tools, runtimes, or network access (max 500 characters)metadata— the rest of the map, all of it optional:authorandcategory, plussource_keysnow (Step 6) if research sources are in contextallowed-tools— space-separated pre-approved tools; reduces permission prompts (experimental — support varies by client)disable-model-invocation— hand-invoked skills only
metadata.source_keys — if research sources are in context, list the relevant slugs as you
write the body; do not defer this to Step 6. Agents that fill in source_keys late tend to omit
it entirely. Example:
metadata:
source_keys:
- my-source-slug
- another-slug
Body — write the decision procedure only, following the body rules and patterns in
references/contract.md. Rename the placeholder section headings to ones that fit the skill's
structure.
Step 4 — Add scripts (if needed)
Place executable scripts in scripts/. Critical rule: no interactive prompts — agents run
non-interactive, and blocking on TTY input hangs indefinitely. Accept all input via flags, env
vars, or stdin.
If adding a script, read references/scripts.md first — it covers the full contract: structured
output, pinned versions, self-contained deps, idempotency, exit codes, dry-run, error messages,
and output size limits.
If no scripts are needed, delete scripts/README.md and the scripts/ directory.
Step 5 — Add references, assets, and tests (if needed)
references/ — additional documentation loaded on demand. One topic per file, named in
kebab-case after the topic. Reference conditionally from SKILL.md with the literal form
If <condition>, read `references/<file>.md` .
Two hops from SKILL.md, never three. A flow file may route on to a shared contract or
sub-topic file — that is the shipped pattern here (SKILL.md → references/create.md → this
file's own pointers to contract.md, scripts.md and deployment-modes.md). What does not work
is a third hop: a file reachable only through two intermediates is rarely loaded at the moment it
is needed. Every hop past the first also needs the same literal conditional form, so the agent
knows when to take it.
assets/ — static resources: templates, schemas, lookup tables. Reference by relative path
from SKILL.md.
tests/ — test files for scripts in scripts/. Use when scripts are complex enough to break
silently. Test infrastructure (.bats, *_test.*) belongs here, not in scripts/. See
tests/README.md for setup instructions.
If not needed, delete the placeholder READMEs and their directories.
Step 6 — Populate or delete references/sources.md
If a research sources.md is present in the conversation context:
- Read it and filter to entries with
`extracted`status only. - For each entry, determine which skill files it contributed to (SKILL.md and any files in
references/that drew from it). UpdateContributing filesaccordingly — list skill files, not research topic files. - Write the updated content to
references/sources.md. For each entry, include- **Research doc:** <path>where<path>is the relative path from the repo root to the plugin-level research sources file this entry was drawn from (e.g.plugins/myplugin/docs/research/docs/<topic>/sources.md). This field is required on every entry — it makes the provenance chain explicit and is validated by/skill-audit. - Add
source_keysto the frontmatter ofSKILL.md(undermetadata) listing the slugs of sources that informed it. - For each file in
references/that was informed by research sources, addsource_keysfrontmatter (same format as research topic files) listing the relevant slugs.
If no research sources.md is in context, delete references/sources.md.
Then return to SKILL.md Step 4.