holocron/plugins/kyberforge/.apm/skills/agent-author/references/create.md

source_keys

source_keys
context7-websites-code-claude claude-code-subagents-docs github-plugins-creating

Creating a new agent

Return to SKILL.md Step 4 once Step 3 below is done — validation and the version bump are shared with the improve flow and are not repeated here.

Prerequisites

Before touching the filesystem, confirm you have:

• Agent name (kebab-case, e.g. code-reviewer)
• Root directory — a path inside a package for plugin/APM scope, a project root, or ~ for user scope
• Agent purpose — one sentence describing the task this agent handles
• Trigger condition — when should the runtime delegate to this agent?

If any are missing, stop and ask before proceeding.

factory-audit runs the validation in SKILL.md Step 4. It ships with the kyberforge plugin and is co-installed with this skill; if it is unavailable, stop and ask the user to install kyberforge before continuing.

Design for one job per agent. An agent covering two jobs is delegated to for the wrong one.

Step 1 — Scaffold

bash scripts/new-agent.sh <name> <root>

Examples:

bash scripts/new-agent.sh code-reviewer packages/my-package/   # plugin/APM scope if packages/my-package/apm.yml has a type: field
bash scripts/new-agent.sh deploy-assistant .
bash scripts/new-agent.sh security-reviewer ~

The script resolves scope itself and prints which one it used and every path it wrote — read that output rather than predicting it. It walks up from <root> for the nearest ancestor apm.yml carrying a top-level type: field (instructions/skill/hybrid/prompts), which marks a package root and means plugin/APM scope. An apm.yml with no type: is a marketplace-only manifest: the walk skips it and keeps going. With no such manifest found, <root> being exactly ~ (checked directly, no walk-up) is user scope and anything else is project scope. A bare plugin.json no longer signals plugin scope — that path was replaced outright, not made dual-mode, and falls through to project scope.

The script is file-by-file no-op: it skips any file that already exists, so re-running it to complete a partial pair is safe.

If the script or a template under assets/templates/ has to change to support this agent — a new scope, a new scaffolded field, different output — read references/scripts.md first. Its conventions are asserted by tests/new-agent.bats, and an edit that ignores them fails the suite.

Step 2 — Fill in the file(s)

Take the scope the script reported and read the matching reference — SKILL.md Step 2 has the table. That file carries the field rules and the pre-audit checklist for this scope; the other one describes fields this run cannot use.

Every scaffolded file, at every scope:

1. Replace each FILL IN: placeholder.
2. Delete every <!-- ... --> template comment from the frontmatter. apm compile copies plugin frontmatter verbatim and HTML comments are not valid YAML, so a leftover comment breaks the file downstream on both harnesses.
3. Write the description against references/contract.md and the system prompt body against its Body section.

Step 3 — Populate or delete sources.md

Plugin/APM scope only — skip at project and user scope, which have no package root to hold the file.

The scaffold writes a commented sources.md skeleton at the package root, alongside apm.yml and not inside .apm/agents/, so that tooling scanning that directory for agent definitions does not treat it as an agent missing its frontmatter (ADR-0010).

If a research sources.md is present in the conversation context, filter it to entries with `extracted` status, work out which agent file each one contributed to, and fill in the skeleton following the commented format already in the file. Paths in Contributing files: are relative to the package root. Each slug must match an H2 heading and must also appear in the source_keys list of every file named under its Contributing files:.

If no research sources are in context, delete sources.md.

Then return to SKILL.md Step 4.