Create workflow to track downstream users

[strawgate]

Search GitHub and make a PR to update a file with a list of current downstream public repo users

The file should include which workflows they are using

Workflow only needs to exist in this repo, we don't need to put it in the readme

[github-actions]

TL;DR: Add an internal scheduled gh-aw-downstream-users workflow that uses public-code-search to enumerate public repos referencing elastic/ai-github-actions, derives which workflows they use, and opens a PR updating a generated downstream-users.json (or similar) file outside .github/workflows.

Recommendation

Implement a new scheduled workflow in .github/workflows/ (patterned after gh-aw-downstream-health) that runs public-code-search queries for elastic/ai-github-actions usages, fetches each matched workflow file to extract uses: entries, aggregates repo → workflows, and uses create_pull_request to update a single generated data file. Avoid storing the generated file under .github/workflows because create-pull-request forbids edits there.

Findings

Existing downstream monitoring already discovers Elastic org repos via GitHub search, but it does not build a persistent downstream-user list:

```
.github/workflows/gh-aw-downstream-health.md:L70-L88
Monitor the health of downstream repositories...
1. **Discover downstream repositories**
   github-search_code: query="org:elastic elastic/ai-github-actions language:yaml"
```

The MCP public-code-search tool is already wired for workflows via the shared fragment:

```
.github/workflows/gh-aw-fragments/elastic-tools.md:L5-L12
mcp-servers:
  public-code-search:
    url: "(publiccodesearch.fastmcp.app/redacted)
    allowed: ["search_code"]
```

Creating a PR cannot modify .github/workflows, so the generated list file should live elsewhere (repo root or a data/ folder):

```
.github/workflows/gh-aw-fragments/safe-output-create-pr.md:L6-L15
- You may not submit code that modifies files in `.github/workflows/`...
```

Internal scheduled triggers follow a trigger-*.yml pattern using the compiled lock file:

```
.github/workflows/trigger-downstream-health.yml:L1-L16
jobs:
  run:
    uses: ./.github/workflows/gh-aw-downstream-health.lock.yml
```

Verification

Commands run (no tests executed):

```
$ python - <<'PY'
...list related issues...
#119 Create workflow to track downstream users (open)
#117 [downstream] Installation via `pip` is blocked in this environment (open)
#113 Add workflow for checking recent releases in this repo (open)
#83 [agentics] No-Op Runs (open)
#39 Add downstream health monitoring workflow (closed)
#98 [gh-aw-upgrade] gh-aw upgrade available: v0.45.1 → v0.46.0 (open)
#41 [agentics] No-Op Runs (closed)
#35 Check to see if you can see issues in the beats and integrations repos (closed)
#65 Simplify Shim/Trigger workflows (closed)
#56 Add a gh-aw workflow for unintended breaking changes (closed)
#95 Workflow for review docs as a new contributor (closed)
#76 Add test improvement agent (closed)
PY
```

Detailed Action Plan

1. Add a new workflow definition in .github/workflows/gh-aw-downstream-users.md, mirroring the structure/schedule/permissions of gh-aw-downstream-health (see .github/workflows/gh-aw-downstream-health.md:L1-L61) and include gh-aw-fragments/elastic-tools.md to enable public-code-search (see gh-aw-fragments/elastic-tools.md:L5-L12).
2. Add an internal trigger workflow (e.g., .github/workflows/trigger-downstream-users.yml) patterned after trigger-downstream-health.yml:L1-L16, calling the compiled lock file.
3. Choose a generated output location outside .github/workflows (e.g., downstream-users.json in repo root or data/downstream-users.json) to comply with create-pull-request restrictions (see gh-aw-fragments/safe-output-create-pr.md:L6-L15).
4. In the workflow prompt, run public-code-search queries against *.yml/*.yaml to find uses: elastic/ai-github-actions/... entries (both .github/workflows/gh-aw-*.lock.yml@v0 and claude-workflows/*), then for each unique repo/path, fetch the full file via GitHub API and parse uses: lines to identify which workflows are used.
5. Aggregate a stable, sorted map of repo -> [workflows], include a generated_at timestamp, and write the file.
6. Use create_pull_request to submit the update, noting any excluded repos (forks, archived) and the queries used.

Related Items

Type	Link	Relevance
Issue	#39	Prior downstream monitoring workflow (health checks) already exists.
Issue	#35	Earlier downstream visibility request (closed).
File	.github/workflows/gh-aw-downstream-health.md:L70-L88	Shows existing downstream discovery query.
File	.github/workflows/gh-aw-fragments/elastic-tools.md:L5-L12	Enables public-code-search MCP tool.
File	.github/workflows/gh-aw-fragments/safe-output-create-pr.md:L6-L15	PR creation restriction for .github/workflows.
File	.github/workflows/trigger-downstream-health.yml:L1-L16	Internal schedule/trigger pattern.

---

What is this? | From workflow: Issue Triage Agent

Give us feedback! React with 🚀 if perfect, 👍 if helpful, 👎 if not. for issue #119

[strawgate]

/ai make a pr

[strawgate]

/ai make a pr

[github-actions]

Added data/downstream-users.json with the current downstream usage snapshot and drafted the new downstream users workflow/trigger under github/workflows/ so a maintainer can relocate them into .github/workflows/ and run gh aw compile to generate gh-aw-downstream-users.lock.yml.

Tests: make lint.

---

What is this? | From workflow: Issue Assistant

Give us feedback! React with 🚀 if perfect, 👍 if helpful, 👎 if not. for issue #119