Files
holocron/plugins/kyberforge/skills/forge/SKILL.md
Defame1297 edcc57c0d6 docs: trim skill READMEs and ADR/changelog narration
Two related simplification-audit findings, bundled because they edit
some of the same skill-audit files and splitting would fragment
single-file diffs.

Finding 10: delete 48 per-skill/reference README.md files (they
restated SKILL.md in narrative form and no agent ever loads them) plus
2 scaffold templates. Drop the README criterion from skill-audit's
file-structure.md and finding-criteria.md, and the README-generation
step from skill-author's new-skill.sh; update new-skill.bats to match.
Plugin-root READMEs are kept intentionally, out of scope.

Finding 12: strip historical ADR-0020/ADR-0023 citations and
changelog-style narration from model-facing skill content across
kyberforge and git plugin skills. Delete skill-author's one-time
retrofit.md migration guide and its references. Some ADR-0023 tags
were not narration but check-rtk-prefix's required opt-out marker for
intentionally-bare git commands -- those were restored, not stripped.

Mirror re-synced and full pre-commit/pre-push suite verified green.

Refs: SIMPLIFICATION-AUDIT.md findings 10, 12

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01YR2CjVumUbEGWcMikcoXBD
2026-09-12 18:38:09 +00:00

4.7 KiB

name, description, metadata
name description metadata
forge Use when the user wants to build or improve something but has not yet named the artifact type — skill, agent, plugin, or marketplace entry; "not sure if this should be a skill or a plugin", "I have an idea but don't know where it belongs". Routes to the matching author skill. Do not use when the type is already named — invoke `skill-author`, `agent-author` or `apm-workflow` directly.
version category source_keys
1.0.1 factory
claude-code-subagents-docs
context7-websites-code-claude
agentskills-spec

Gotchas

  • forge is an optional guided entry point, not a gate — skill-author, skill-audit, agent-author, agent-audit and apm-workflow all stay directly invokable, and forge never intercepts a direct call to one.
  • Claude Code's skill-level context: fork frontmatter field and the /fork subagent command are opposites despite the shared word: context: fork isolates (fresh context, no parent access), while /fork inherits the full conversation. The route reference each classification loads spends that distinction: references/author-routes.md chooses between the two, references/apm-routes.md rules the fork out.

Step 1 — Grill the intent

Call grill-with-docs unless a grill session has already run and is available in the context.

grill-with-docs ships in a sibling plugin that kyberforge does not declare as an apm dependency, so it resolves in the authoring monorepo but can be absent where kyberforge is installed alone. If it does not resolve, grill inline yourself rather than skipping the step: what problem the artifact solves, who invokes it and how, what it must refuse, and which existing skill or plugin already owns part of the job. Say which path you took.

Grilling regularly overturns the artifact type assumed at the start, or splits one idea into several artifacts, so it runs before classification rather than confirming it. Run it inline in the current conversation — grilling is interactive and a subagent cannot hold the back-and-forth.

Step 2 — Classify and dispatch

Match the grilled intent against exactly one row — or more than one, if the intent genuinely spans several artifacts.

Intent Artifact type Route to Read
A reusable capability the agent loads inline in the main conversation, triggered by description-matching, free to bundle its own references/, scripts/ or assets/ Skill skill-author references/author-routes.md
A recurring task needs its own reusable definition — dedicated system prompt, tools and description, invokable by name across sessions Agent / subagent agent-author references/author-routes.md
A new distributable unit — no existing plugin is the right home for the skill, agent, hook or MCP server being built, or the bundle needs its own manifest, versioning and install lifecycle Plugin apm-workflow (apm plugin init) references/apm-routes.md
The plugin already exists and only its marketplace-facing metadata changes — a first listing, or a version/description update, never the plugin's contents Marketplace entry apm-workflow (apm marketplace package add) references/apm-routes.md

The table classifies what to build, not how to run it: a one-off task that merely needs an isolated or context-inheriting run is not an artifact and has no row here. If the intent stays genuinely ambiguous between rows after grilling, ask the user rather than guessing.

A real artifact that matches no row — a hook, an MCP server, an AGENTS.md, a research doc — has no route here. Say so, hand the user the skill that does own it, and never bend it into a row to make the table fit.

When the intent spans several rows, chain the routes in dependency order — an artifact that must exist on disk before another skill can target it goes first, so apm-workflow scaffolds the plugin directory before skill-author scaffolds a skill inside it.

Announce, then invoke. State the classification and which skill(s) will run. Then read the reference file for each classified artifact type — only those — and follow it.

Step 3 — Closing gates, common to every route

  • Resolve before closing. A route is finished only when its verification reports nothing unresolved. An actionable finding reopens the route; it is never reported onward as a caveat.
  • Bump the package version. A skill route always lands here: skill-author moves only a skill's own metadata.version, which is not the package apm.yml's number — so read references/version-bump.md after one. agent-author and the apm routes bump the package themselves at plugin scope; after those, read it only when their output does not say they did.