User Story

As an adopter relying on apexyard's role activation rules, I want the framework to mechanically detect when a role trigger fires AND remind the main agent to read the role file, so that role adoption isn't dependent on the agent remembering — it's enforced by the framework like every other governance rule.

Driver

Today's role activation is prose-only discipline. The trigger table in .claude/rules/role-triggers.md says "when a PR touches **/auth/**, Security Auditor activates" — but if the main agent doesn't remember to read roles/security/security-auditor.md before responding, the activation never actually happens. Silent rule-skip.

This is the same failure mode the framework already mechanically fixes for OTHER governance rules:

• Active-ticket requirement → require-active-ticket.sh hook
• Merge gate → block-unreviewed-merge.sh hook
• Migration ticket → require-migration-ticket.sh hook
• AgDR for arch changes → require-agdr-for-arch-pr.sh hook

Role activation should follow the same shape: detect the trigger condition mechanically, inject the role file as required context so the main agent can't avoid reading it.

Scope

A new hook (or extension of an existing one) that:

1. Detects role-trigger conditions per .claude/rules/role-triggers.md:
   • Ticket label changed → relevant role's trigger (e.g. qa label → QA Engineer)
   • PR diff touches a path pattern → relevant role's trigger (e.g. **/auth/** → Security Auditor)
   • Production-incident-mentioned in user prompt → SRE
   • New PRD drafted → Product Manager
2. When triggered, injects a system-reminder-style line into the assistant's context:

   ROLE TRIGGER: Security Auditor activates per .claude/rules/role-triggers.md
   (PR diff touches **/auth/**). Read roles/security/security-auditor.md
   and adopt the role before continuing.
   

3. The main agent reads the file (Read tool — visible in tool-call log) and then proceeds with the role identity adopted.

Mechanism options

Pick the simplest combination that covers the documented trigger table.

Out of scope of v1

• Enforcing that the role file is actually read after the reminder (would require monitoring Read tool calls — out of scope).
• Enforcing role boundaries (CAN / CANNOT) — separate concern, more complex.

Acceptance Criteria

• At least one new hook (or extension of an existing one) detects role-trigger conditions per the documented trigger table.
• When a trigger fires, a system-reminder-style line is injected into the main agent's context naming the role + the file to read.
• The reminder is non-blocking (doesn't refuse the underlying tool call) — same shape as the upstream-drift banner.
• Test coverage for at least 3 trigger conditions: label-based (QA), diff-based (Security Auditor on **/auth/**), and prompted (user says "act as the X").
• Doc note in .claude/rules/role-triggers.md § "Aspirational → Real" updated — this ticket closes the "real" gap.

Risks / Dependencies

• False positives — a PR that touches **/auth/** for trivial reasons (docs about auth, not auth code) would trigger Security Auditor. Acceptable: better to over-trigger than miss real cases; the security auditor can no-op cheaply.
• Couples with role-naming ticket — reminder line reads better with a persona name; ship independently though.
• Couples with role-activation-visibility ticket — the reminder line is the input; the activation marker the agent prints is the output. Both required for the loop to be visible.

Refs

• Sibling: role-naming consistency ticket
• Sibling: role-activation visibility ticket (the user-visible side of this loop)
• Pattern precedent: require-active-ticket.sh, block-unreviewed-merge.sh, require-agdr-for-arch-pr.sh — same "convert prose rule to mechanical enforcement" shape
• Related: .claude/rules/role-triggers.md § "Aspirational → Real"