Skip to content

Spec naming convention assumes a subject the model no longer has #82

Description

@edonadei

skills/grill-skill/REFERENCE.md teaches that a spec is named after the skill it tests and lives beside it:

skills/my-skill/SKILL.md
skills/my-skill/my-skill.eval.yaml   ← generated here

That convention predates #18, where skill: path: became skills: — a set of peers with no designated subject (ADR 0014: positional subjecthood was rejected, and activates: always names skills explicitly).

With one declared skill the convention is still right. With three, commit-writer.eval.yaml silently reasserts that commit-writer is the one under test, which the model explicitly denies. And it is visible on every report: the run header prints RunMeta.spec, which is that filename stem.

── CALIPER — commit-writer (claude-code) · judge claude-code — 2026-06-19 14:23 ──

Nothing breaks; it is a filename. But the convention and the domain model now disagree, and the docs still teach the old one.

Options

  • Name multi-skill specs for the scenario, not a member: release-flow.eval.yaml, commit-vs-changelog.eval.yaml. Honest about there being no subject; costs a convention that is currently one line to state.
  • Keep naming after the first-listed skill as a pure convention, and say in the docs that it carries no semantics. Cheapest, but it re-teaches the intuition ADR 0014 removed.
  • Say nothing and let authors choose. Then grill-skill needs to stop generating the name automatically, or it picks a subject on the author's behalf.

Whichever lands, grill-skill/REFERENCE.md needs updating, since that is where the convention is taught and where the generator reads it from.

Related: #18, ADR 0014 (peers, no subject).

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or request

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions