Adding ht-github-issue-rollout to hermes-talaria — Separating API Visibility from Administrative Coverage and Not Substituting Markdown Links for Native Sub-Issues

I added ht-github-issue-rollout to hermes-talaria, a skill that scans every repository in a GitHub organization or every organization and repository in an enterprise, assesses a shared request such as vulnerability remediation, and creates an approved native epic/sub-issue hierarchy. Emergency CVE responses increasingly need a coordinated bulk ask across the whole organization, and hand-wiring epics and sub-issues on a tight deadline stops being a reasonable operator task. GitHub's native sub-issue API requires parent and child repositories to share an owner, so substituting Markdown links turns it from a native hierarchy into something the platform does not aggregate. This post records the design decisions I settled during PR review: how the skill keeps the same-owner constraint, separates API visibility from administrative coverage, keeps applicable / not_applicable / unknown as distinct states, and recovers from partial failure through hidden markers.