Define implied vs user-triggered skills as control-flow mechanics

[JRichlen]

Problem

Skill descriptions currently carry several different control-flow meanings:

• implied trigger — routing selects a skill from task shape
• user trigger — a user explicitly invokes or requests a skill
• dependency trigger — one protocol invokes another skill
• state/risk gate — a workflow transition activates a guard or requires confirmation
• always-on invariant — guidance applies inline without taking over the workflow
• offer-only — a capability may be suggested but must not run automatically

Encoding these distinctions mainly in prose blurs discovery, routing, authorization, and workflow ownership. Broad implied triggers can overlap, consume context, or hijack control flow; user-trigger-only skills can miss useful intervention points.

Goal

Define a portable trigger and control-flow model for skills across supported agent harnesses.

Description compression

Descriptions should be compact routing indexes, not miniature instruction sets. Trigger semantics, precedence, authorization, and workflow transitions should live in structured metadata or the skill body, then compile into the smallest harness-compatible routing description.

The recent Red Gate pass reduced its always-resident trigger surface from 1,869 to 1,458 characters (about 22%), but manual prose compression will not scale across the fleet.

The design should establish:

• separate human-facing summaries, routing signals, and full instructions where harnesses permit it
• character/token budgets per skill and for the always-resident skill roster
• routing quality per token as an evaluation target
• generated harness-specific descriptions from one canonical trigger declaration
• deduplication of repeated trigger prose across manifests, rosters, and documentation
• CI checks for description growth, personal wording, drift, and lost discriminating trigger phrases

Questions to resolve

• Which trigger classes are first-class, and which are policy variants?
• Where should classification live: skill frontmatter, plugin manifests, a registry/compiler, or prose?
• How are collisions and precedence resolved?
• Does an implied trigger load the full skill or only routing metadata first?
• How do explicit invocation, opt-out, and user confirmation override implied behavior?
• How are dependency calls and stateful workflow transitions represented?
• How should interactive-question and approval gates degrade on harnesses without native UI support?
• Should display summaries and router descriptions be distinct fields?
• Can platform-specific descriptions be generated without creating multiple sources of truth?
• How do we test false positives, false negatives, workflow takeover, context cost, and routing quality per token?

Acceptance criteria

• Publish a concise trigger taxonomy with normative semantics.
• Define precedence and override rules, including explicit user intent.
• Separate routing eligibility from authorization and workflow ownership.
• Map representative skills: Red Gate, criteria-contract, reconcile, diagnosing-bugs, grill-me, egress-gate, and second-opinion.
• Propose a portable machine-readable representation with graceful fallback.
• Define description budgets and a canonical-to-platform generation strategy.
• Add routing evals for collisions, negative controls, explicit overrides, dependency calls, confirmation gates, and compressed-description regressions.
• Track routing accuracy and context cost before and after compression.
• Add CI checks that prevent description bloat, personal wording, duplication, and generated-description drift.
• Document a migration path that avoids inflating descriptions solely for trigger matching.

[JRichlen]

Deferred into the single adaptive-behavior plan: #117. Trigger semantics remain future marketplace work; this closure does not mark them implemented. Original requirements are preserved here.