skill-audit loaded roughly 4,268 words of rubric on every run, most of it criteria for findings a clean skill never triggers. The auditing guidance moves into finding-criteria.md, read only when a finding is actually raised, cutting a clean audit to about 999 words. The named-skill exemption is replaced with properties, so the rubric stops carrying a list that ages the moment a skill is renamed. apm-workflow's `type:` trap sat in one flow while biting several, so it is promoted to a common gate reachable from all of them; its claim to be self-contained was untrue once it started routing to apm-install. skill-author's contract had drifted from body-discipline.md and is realigned, and agent-audit's field inventory is brought in line with the same split.
4.2 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; "a skill for the gitea plugin, or an agent?". Routes to the matching author skill. Do not use when the type is already named — invoke `skill-author`, `agent-author` or `apm-workflow` directly. |
|
Gotchas
- forge is an optional guided entry point, not a gate —
skill-author,skill-audit,agent-author,agent-auditandapm-workflowall stay directly invokable, and forge never intercepts a direct call to one. - Claude Code's skill-level
context: forkfrontmatter field and the/forksubagent command are opposites despite the shared word:context: forkisolates (fresh context, no parent access), while/forkinherits the full conversation. The route reference each classification loads spends that distinction:references/author-routes.mdchooses between the two,references/apm-routes.mdrules 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.
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-authormoves only a skill's ownmetadata.version, which is not the packageapm.yml's number — so readreferences/version-bump.mdafter one.agent-authorand the apm routes bump the package themselves at plugin scope; after those, read it only when their output does not say they did.