Skip to content

feat: waza check support for custom agents (.agent.md) #313

Description

@brendanlapuma

Summary

waza check validates SKILL.md readiness (compliance score, token budget, agentskills.io spec compliance, advisory checks), but there is no equivalent readiness/lint command for custom agents (.agent.md). Waza already treats .agent.md as a first-class evaluation target for waza run (per the custom agents guide and #225), so it would be natural to extend waza check to lint agent files too.

Problem

Today waza check is hardcoded to require a SKILL.md. As a result, teams that ship custom agents have to maintain a separate, homegrown validator for .agent.md frontmatter and conventions, duplicating logic that waza check already provides for skills.

Proposed solution

Teach waza check to recognise and validate .agent.md files, mirroring the skill flow:

  • If a target directory (or path) resolves to an .agent.md instead of SKILL.md, run an agent check rather than erroring.
  • Reuse the existing check framework (compliance scoring, token budget, advisory checks) with an agent-aware spec checker.

Suggested agent-specific checks (based on the fields documented in the custom agents guide):

  • Frontmatter present & parseable, with required name and description.
  • name matches filename (e.g. security-reviewersecurity-reviewer.agent.md), consistent with how the guide describes agent naming.
  • Allowed/known frontmatter fields: name, description, tools, model, handoffs, mcp-servers, agents — warn on unknown keys.
  • tools shape validation (array of tool names) when present.
  • Token budget / body-size check for the agent system prompt (the markdown body), analogous to the SKILL.md token budget, with .waza.yaml override support.
  • Advisory checks for description quality, etc.

Open question / options for the maintainers:

  1. Auto-detect agent vs. skill from the file/dir contents within waza check (preferred — keeps one command), or
  2. Add a dedicated subcommand/flag (e.g. waza check --agent <path> or waza check agent <path>).

Why this matters

  • Removes the need for downstream homegrown agent validators.
  • Gives agent authors the same pre-submission confidence skills already get.
  • Keeps agent and skill governance consistent under a single waza check entry point/CI step.

Metadata

Metadata

Labels

No labels
No labels

Type

No type

Fields

No fields configured for issues without a type.

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions