[FEATURE] trigger or priority: blocking field in agent frontmatter, equivalent to the blocking-requirement behavior skills already have

Preflight Checklist

• [x] I have searched existing requests and this feature hasn't been requested yet
• [x] This is a single feature request (not multiple features)

Problem Statement

• Problem: Agent invocation is judgment-based; skill invocation is blocking-requirement. This means a skill with a matching trigger description fires before a specialized agent is evaluated, bypassing the agent's guardrails and pipeline.

• Concrete example: uipath-selector-engineer agent should be the sole entry point for selector work, but uipath-selector-library skill can currently be invoked directly by the main session, bypassing the allowlist enforcement, lint pass, and confidence labeling the agent applies.

Proposed Solution

• Proposed: A trigger: or priority: blocking field in agent frontmatter, equivalent to the blocking-requirement behavior skills already have. Agent-as-trigger-block would make the hierarchy coherent — skills become internal tools of agents, not competing entry points.

Alternative Solutions

Session start → CLAUDE.md rule loaded (highest authority)
└── ask arrives → agent description matches → uipath-selector-engineer spawned
└── agent invokes uipath-selector-library internally
└── skill description confirms "I am agent-only"

Why this workaround: CLAUDE.md is loaded before skill or agent evaluation happens. It's the closest equivalent to a blocking requirement because it's a persistent user instruction — not a description that Claude interprets with judgment, but a rule it's told to follow. The three layers together mean the routing has to fail at all three points simultaneously to break down, which is unlikely in practice.

The remaining gap: It's still not architecturally enforced the way a native priority: blocking field would be. The problem is the workaround requires awkward multi-layer compensation for what could be a single frontmatter field.

Priority

Medium - Would be very helpful

Feature Category

Configuration and settings

Use Case Example

Example Scenario:

Use Case: Agent-as-Trigger-Block for Specialized Selector Engineering

• A personal agent (uipath-selector-engineer) exists at ~/.claude/agents/uipath-selector-engineer.md as the sole entry point for all UiPath selector generation work
• It applies a strict pipeline: webctrl attribute allowlist enforcement, selector lint pass, confidence labeling (candidate-low/medium/high/validated), duplicate-match risk estimation, and a security boundary that prevents credential values from being written into selectors or XAML
• The underlying capability is provided by a skill (uipath-selector-library) at ~/.claude/skills/uipath-selector-library/SKILL.md, which the agent loads internally via its skills: frontmatter declaration
• Because skills carry a blocking-requirement trigger and agents are only judgment-based, the main session can invoke uipath-selector-library directly when the ask matches the skill's description — bypassing the agent entirely
• When the skill fires directly, none of the agent's guardrails apply: unsupported <webctrl> attributes may be emitted, selectors are not linted, confidence labels are not assigned, and the security boundary is not enforced
• The workaround — rewriting the skill's description to say "delegate to agent" and adding TRIGGER — invoke BEFORE any other response to the agent's description — approximates the desired behavior but is not enforceable; it relies on Claude's judgment rather than a hard architectural guarantee
• Desired behavior: a trigger: or priority: blocking field in agent frontmatter that gives agents the same blocking-requirement status skills currently have, so the agent is always evaluated and spawned first, with skills functioning exclusively as internal tools of the agent rather than competing entry points accessible to the main session

Additional Context

_No response_