Summary

Add notification actions (Slack, Discord, optional email) so consuming repos can report CI/CD events with consistent formatting.

Priority: low — kept open but not scheduled for near-term work. Most adopters currently rely on GitHub-native PR checks/notifications, so this is a convenience layer rather than a blocker.

Problem

• No built-in notification support; each repo hand-rolls webhooks or pulls an unpinned third-party action.
• Inconsistent notification formatting across projects.

Proposed Solution

notify-slack

- uses: ./.github/actions/notify-slack
  if: failure()
  with:
    webhook-url: \${{ secrets.SLACK_WEBHOOK }}
    status: failure
    title: \"Build Failed\"
    message: \"Build failed on \${{ github.ref }}\"

Block Kit support, status-based colors, workflow-context auto-injection.

notify-discord

- uses: ./.github/actions/notify-discord
  with:
    webhook-url: \${{ secrets.DISCORD_WEBHOOK }}
    status: success
    title: \"Deployment Complete\"

Discord embeds, rich formatting, mention support.

notify-email (future)

SendGrid / SES / SMTP provider with templated body.

Common interface

inputs:
  status:  { description: 'success | failure | cancelled' }
  title:   { description: 'Notification title' }
  message: { description: 'Notification body' }
  fields:  { description: 'Additional fields (YAML)' }

Implementation Notes

• Use curl for webhook delivery (no extra deps); add retry for transient failures.
• Shared formatting/template helpers under scripts/ci/lib/notify/.
• Dry-run mode for testing; BATS coverage for message formatting.
• Files: .github/actions/notify-slack/, .github/actions/notify-discord/, scripts/ci/actions/notify-*.sh, scripts/ci/lib/notify/.

Benefits

• Consistent, pinned notification layer instead of per-repo webhook scripts.
• Status-based styling and shared templates across the org.

References

• feat(workflows): standardize reusable workflows as drop-in CI for all lgtm-hq repos #168 — drop-in CI contract (optional notification layer)