Defame1297
f4bb1cf4e5
The previous round taught agent-audit's validator to permit disallowedTools but left the skill that writes agents still forbidding it, in six places. Running agent-author on any of the three fenced orchestrators would have stripped the fence, and nothing would have caught it: the validator's allowlist is a permit list, so an absent field passes. The template was the worst of them, since its comment is copied verbatim into every new plugin-scope agent. Where a list had to be restated it is now a pointer to field-inventory.md's apm-agent-allowlist instead -- the same data validate.sh reads -- because a roster copied into a template goes stale one step further out than the roster itself. Where the text has to teach something it teaches the shape rule rather than the exception: tools is an allowlist whose vocabulary differs per harness, so verbatim copy makes one value wrong on one target; disallowedTools is a denylist, where an unrecognised name denies nothing, so the worst case is a missing fence rather than a wrongly granted capability. ADR-0016's amendment claimed an unrecognised key is inert on Copilot while the same ADR's Context says that behaviour is unconfirmed by research -- asserting as settled the exact thing it flags as unknown, and justifying it with apm's compile-time behaviour, which says nothing about Copilot's runtime. It is rewritten into labelled tiers: confirmed for Claude Code with citations, inferred by analogy for Copilot with the analogy's limits stated, unverified where it is unverified, and the residual risk accepted explicitly with its blast radius. It also no longer claims to restore a write sandbox: the denylist does not deny Bash, which these agents inherit and legitimately need. docs/hooks.md called the old root hooks.json a stale sync artifact -- it was added in the plugin's creating commit and pointed at by main's Copilot manifest -- and claimed both ecosystems now resolve hooks/hooks.json. Copilot does not: its hooks field has no default and no compiled manifest declares one, so it resolves nothing. Recorded as the gap it is, with re-injection noted as a follow-up rather than asserted away. Its event list is marked partial. Also: new-agent.bats asserted a hardcoded four-field allowlist and would have rejected a scaffolded agent carrying the field the ADR now blesses; it reads field-inventory.md too. And ADR-0016's premise that Claude's tools: is space-separated was wrong -- it takes a comma-separated string or a YAML list. The incompatibility with Copilot is the vocabulary, not the punctuation. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01X7GvKuJfy2WrdBmUttV4DT
agent-author
Creates and improves agent definition files for Claude Code and GitHub Copilot CLI.
What it does
Scaffolds and fills in agent definition files at plugin/APM, project, or user scope. Project and user scope always generate a Claude Code + Copilot CLI file pair (.md + .agent.md) in one pass. Plugin/APM scope generates a single vendor-neutral .apm/agents/<name>.agent.md file instead — no separate Claude Code / Copilot split, since apm compile has no per-target field integrator (see ADR-0016). Also applies improvement signals — grill output, inline feedback, session context — to existing agent files. Bumps the version after every change: the resolved package's apm.yml at plugin/APM scope (minor for new agents, patch for improvements); project/user scope has no manifest to bump.
Before you start
Have ready: the agent's name (kebab-case), the root directory (plugin root, project root, or ~), a one-sentence purpose, and the triggering condition (when should the runtime delegate to this agent?).
Usage
/agent-author
Manual scaffold (human workflow):
bash scripts/new-agent.sh <agent-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 ~
Files
| File | Purpose |
|---|---|
SKILL.md |
Skill instructions for agents |
scripts/new-agent.sh |
Scaffolds agent definition file(s) from templates — a single .apm/agents/<name>.agent.md at plugin/APM scope, or a Claude Code + Copilot CLI pair at project/user scope |
references/deployment-modes.md |
Plugin/APM vs project vs user scope: restrictions, scoped identifiers, path conventions |
references/scripts.md |
Conventions for new-agent.sh and any future scripts: contract, template variables, file placement, error messages |
references/sources.md |
Research provenance — sources that informed this skill |
assets/templates/claude-code.md |
Annotated Claude Code agent definition template (project/user scope) |
assets/templates/copilot.agent.md.template |
Annotated Copilot CLI agent definition template (project/user scope) |
assets/templates/apm-agent.md |
Annotated vendor-neutral APM agent definition template (plugin/APM scope) |
tests/new-agent.bats |
(source-only) bats tests for scripts/new-agent.sh |
assets/README.md |
Directory meta-documentation for assets/ |
references/README.md |
Directory meta-documentation for references/ |
scripts/README.md |
Directory meta-documentation for scripts/ |
tests/README.md |
(source-only) bats dependency instructions and run command |
Rows marked (source-only) exist in the authoring source (.apm/skills/agent-author/) but are
not present in an installed plugin: scripts/sync-plugin-content.sh strips
<category>/<name>/tests when it generates the flat mirror, because these are dev-time fixtures no
plugin host needs to discover (ADR-0017). Run them from a repo checkout, not from an install. The
assets/templates/ rows above are unaffected — the exclusion is depth-scoped to
<category>/<name>/tests, so template trees that themselves contain a tests/ directory ship
intact.