fix(#410): guard step 3f context assembly against unselected security sub-agent

[fullsend-ai-coder]

Summary

• Auto-include the security sub-agent in step 3c when step 3c-1 produces a non-empty security_critical_files list, ensuring triage-flagged security-critical files always receive dedicated security review even when domain classification (step 3b) did not independently trigger the security dimension.
• Add an explicit guard in step 3f so context modifications for the security sub-agent are only applied when it was selected in step 3c, making behavior deterministic rather than relying on implicit orchestrator reasoning.
• Split the re-review dispatch rule for security from cross-repo-contracts so the triage auto-inclusion is recognized as an independent qualification path during re-review (previously both were in a combined bullet that only referenced step 3b path criteria).

Context

The review agent identified a logic gap in the two-pass review strategy (PR #190) across 4 review cycles: step 3f unconditionally assembled context for the security sub-agent when triage results existed, but step 3c conditionally dispatched it based on domain classification. A large PR could trigger triage classifying files as security-critical without step 3c selecting the security sub-agent, causing step 3f to reference a context package for an unselected sub-agent.

Testing

• Verified the prerequisites-creates-allowed-issue test failure in post-triage-test.sh is pre-existing on main (unrelated to this change).
• All other tests pass. This is a Markdown-only change to a skill definition file — no production code or test code is affected.
• Validation criteria from the issue: on the next review of a PR where security triage classifies files as security-critical but the security sub-agent is not in the default dimension set, the orchestrator should auto-include the security sub-agent (Option 1).

---

Closes #410

Post-script verification

• Branch is not main/master (agent/410-guard-step3f-security-dispatch)
• Secret scan passed (gitleaks — e7a3660d8d2dffb418d747883540f78588c8c60f..HEAD)
• PR body secret scan passed (gitleaks — no-git)
• Pre-commit hooks passed (authoritative run on runner)
• Tests ran inside sandbox

[rh-hemartin]

/fs-review

[fullsend-ai-review]

🤖 Finished Review · ✅ Success · Started 6:43 AM UTC · Completed 6:56 AM UTC
Commit: 46a4a32 · View workflow run →

[fullsend-ai-review]

Review

Findings

Medium

• [protected-path] skills/pr-review/SKILL.md — This file is under the skills/ protected path, which covers governance and infrastructure files requiring human approval. The PR links to issue pr-review skill step 3f should guard context assembly against unselected security sub-agent #410 and the description explains the rationale for the change. Human approval is always required for protected-path changes, regardless of context.

Low

• [design-direction] skills/pr-review/SKILL.md:346 — Step 3c's "Security triage auto-inclusion" paragraph references step 3c-1's output (security_critical_files list), but the step numbering could be read as implying 3c runs before 3c-1. The sub-step naming convention (paralleling "3a-1" at line 278) makes the ordering reasonably clear when reading top-to-bottom, but a brief clarifying note that the auto-inclusion rule is evaluated after step 3c-1 completes could improve readability.
  Remediation: Consider adding a brief note to step 3c clarifying that the auto-inclusion rule is evaluated after step 3c-1 completes, if the sub-step naming convention is not considered self-evident.

---

Labels: PR modifies the review agent's orchestration skill definition (skills/pr-review/SKILL.md) and touches a protected path requiring manual review

[fullsend-ai-review]

See the review comment for full details.

[fullsend-ai-review]

[low] design-direction

Step 3c's "Security triage auto-inclusion" paragraph references step 3c-1's output (security_critical_files list), but the step numbering could be read as implying 3c runs before 3c-1. The sub-step naming convention (paralleling "3a-1" at line 278) makes the ordering reasonably clear when reading top-to-bottom, but a brief clarifying note that the auto-inclusion rule is evaluated after step 3c-1 completes could improve readability.

Suggested fix: Consider adding a brief note to step 3c clarifying that the auto-inclusion rule is evaluated after step 3c-1 completes, if the sub-step naming convention is not considered self-evident.