holocron/plugins/kyberforge/.apm/skills/forge/SKILL.md

name, description, metadata

name	description	metadata
forge	Use when the user wants to build or improve something without naming the artifact type ("not sure if this should be a skill or a plugin"). Not a named skill -> `skill-author`. Not a named agent -> `agent-author`. Not a named plugin -> `apm-workflow`.	version category source_keys 1.0.2 factory claude-code-subagents-docs agentskills-spec

Gotchas

• forge is an optional guided entry point, not a gate — skill-author, agent-author, factory-audit and apm-workflow all stay directly invokable, and forge never intercepts a direct call to one.

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 kyberforge does not declare as an apm dependency, so it 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 often overturns the assumed artifact type or splits one idea into several, so it runs before classification. Run it inline: 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
Always-on or path-scoped agent guidance in .apm/instructions/*.instructions.md	Instructions file	instructions-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.

An 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 owns it, and never bend it into a row.

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, instructions-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.