Publish a shareable (non-private) variant of the AI Moderator workflow

[salmanmkc]

Summary

ai-moderator.md is marked private: true, so it cannot be installed into other repositories via gh aw add. It would be valuable as a shareable workflow — it is one of the more compelling demonstrations of what an agentic workflow can do, and it is currently only usable by copying the file by hand (which loses the source: provenance field and therefore gh aw update support).

Current behaviour

$ gh aw add github/gh-aw/ai-moderator
✗ workflow 'github/gh-aw/.github/workflows/ai-moderator.md@main' is private and cannot be added to other repositories

This is working as designed — the guard lives in pkg/cli/add_workflow_resolution.go:

if ExtractWorkflowPrivate(content) {
    return nil, fmt.Errorf("workflow '%s' is private and cannot be added to other repositories", spec.String())
}

and .github/workflows/ai-moderator.md sets private: true on line 2.

Motivation

I would like to contribute an AI Moderator entry to actions/starter-workflows (see actions/starter-workflows#3402) so that people setting up a new repository can adopt it in one click.

The only way to do that today is to copy the markdown into the starter-workflows repo and strip private: true. That is undesirable because:

1. It routes around an explicit "do not share this" signal from the workflow's authors.
2. The copy has no source: field, so consumers cannot run gh aw update to pick up fixes.
3. The two definitions will silently drift as this repo's version evolves.

A first-class shareable version solves all three.

Proposal

Publish a shareable variant of the AI Moderator workflow, following the pattern already used by the ~60 non-private workflows in .github/workflows/ (e.g. auto-triage-issues.md, ci-doctor.md, breaking-change-checker.md).

Concretely, one of:

• Option A — drop private: true from ai-moderator.md, if nothing in it is actually specific to this repository.
• Option B — add a generic sibling (e.g. ai-moderator-shared.md) with repo-specific configuration removed, and keep the private one as this repo's own instance.

Option B is likely safer if the current workflow encodes any gh-aw-specific labels, paths, or repository assumptions.

Acceptance criteria

• gh aw add github/gh-aw/<name> succeeds from an unrelated repository.
• The added workflow compiles cleanly with gh aw compile.
• The installed copy carries a source: field so gh aw update works.
• No repository-specific configuration (labels, paths, secrets, org names) is required for it to run.

Notes

Happy to do the work if you would rather take a PR than an issue — I mainly want to confirm the private: true was intentional for this workflow before proposing any change to it.