Defame1297
4aab9d327c
Description 648 -> 387 chars, body 1093 -> 541 words. This was the last body FAIL in the 39-skill corpus. The body was not trimmed to fit. forge routes four artifact types that a single invocation classifies between, so the contract requires a dispatch table plus the gates common to every route, with each route self-contained in references/. Adds references/author-routes.md (skill and agent), references/apm-routes.md (plugin and marketplace entry) and references/version-bump.md. Skill and agent share one file: they differ on one axis only, which audit skill verifies the result. Fixes three defects the first pass introduced or relocated: - references/apm-routes.md claimed `apm audit` "already runs inside apm-workflow's own flow" and told the agent to confirm it ran clean. apm-workflow dispatches audit as its own row; the configure and marketplace rows never reach it. That was the only completion check these routes had, and it could never be satisfied. Replaced with a manual read-back the agent performs itself. - "Read only the reference file" forbade the multi-artifact case the same body documents two lines later, and ADR-0011 records eight artifacts authored in one pass. - The announce gate became a closing gate, reachable only after the invocation it was meant to precede. Moved to the end of Step 2. Also restores the artifact enumeration to the plugin row, normalises to bare unnamespaced skill names per AGENTS.md, adds a dispatch fallback for artifacts matching no row, and corrects three provenance entries -- one asserted a contribution that did not happen. Refs #99 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01MWb5RQgCL1ye7cGp2RPb2u
3.9 KiB
name, description, metadata
| name | description | metadata | |||||||
|---|---|---|---|---|---|---|---|---|---|
| forge | Use when the user wants to build, add, 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?". Grills the intent, classifies the artifact, then 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. Every routing branch below turns on that distinction.
Step 1 — Grill the intent
Call bin: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. If the finished route's completion message carries no evidence of a package version bump, read
references/version-bump.md.