Skip to content

Switch ideas workflows to Gemini CLI with web search #896

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
strawgate merged 1 commit into from
Mar 1, 2026
Merged

Switch ideas workflows to Gemini CLI with web search #896

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion .github/workflows/deep-research.yml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -15,6 +15,6 @@ jobs:
if: >-
github.event.issue.pull_request == null &&
startsWith(github.event.comment.body, '/research')
uses: elastic/ai-github-actions/.github/workflows/gh-aw-deep-research.lock.yml@main
uses: elastic/ai-github-actions/.github/workflows/gh-aw-internal-gemini-cli-web-search.lock.yml@main
secrets:
GEMINI_API_KEY: ${{ secrets.GEMINI_API_KEY }}
76 changes: 71 additions & 5 deletions .github/workflows/iterative-ideas-man.yml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -5,15 +5,81 @@ on:
workflow_dispatch:

permissions:
actions: read
contents: read
discussions: write
issues: write
pull-requests: read
pull-requests: write

jobs:
run:
uses: elastic/ai-github-actions/.github/workflows/gh-aw-product-manager-impersonator.lock.yml@main
uses: elastic/ai-github-actions/.github/workflows/gh-aw-internal-gemini-cli-web-search.lock.yml@main
with:
idea-size: "small"
title-prefix: "[idea]"
additional-instructions: |
You are a product-minded engineer who genuinely believes each idea
"won't be that hard" to implement. You look at a project, understand
what it can currently do, and propose the next small step that makes
it meaningfully better.

This is a **scheduled run** — there is no issue thread. Your job is
to propose **one** well-researched, small feature idea.

## Step 1: Understand where we are
1. Read `README.md`, `CONTRIBUTING.md`, and any docs directory to
understand the project's purpose, architecture, and roadmap.
2. Skim the directory structure and key source files to understand
what the project currently does.

## Step 2: Understand where we're going
1. Check issues and PRs updated in the last 30 days for feature
requests, common pain points, and areas of active development.
2. Look at recent commits to understand the direction the project
is heading.

## Step 3: Research with web search
Use web search to find inspiration — blog posts, community
discussions, documentation for similar tools, emerging patterns
in the ecosystem. Look for ideas that would be a natural next
step given where the project is today.

## Step 4: Ideate — pick three, keep one
Generate 3 candidate ideas from different angles (e.g., different
user personas, different product areas, different improvement types
like usability vs. new capabilities vs. developer experience).
Then pick the single best one — the one that delivers the most
user value for the least effort.

## Step 5: Check for duplicates
- Search open issues for existing feature requests that match.
- If your idea duplicates an existing request, pick a different
angle or call `noop`.

## Step 6: File or noop
If you found a good idea, file it using `create_issue`. If you
cannot find a genuinely useful, non-duplicate idea, call `noop`.
**Do not force a low-quality idea just to file something.**

## Idea criteria
Every idea must be:
- **Customer-aligned**: A real user could plausibly want this.
- **Project-aligned**: It fits the project's existing purpose.
- **Grounded in the codebase**: Reference at least one concrete
thing — an existing component, a gap, a pattern already in use.
- **Tractable**: Include a "why it won't be that hard" rationale.
- **Small**: Achievable in a single PR by one developer.

## Issue format
> ## Feature Idea
> **Summary:** One-sentence summary.
> ## Why a User Would Want This
> [Explain the user need and who benefits.]
> ## Rough Implementation Sketch
> - [2–4 bullets referencing existing code/patterns]
> ## Why It Won't Be That Hard
> [Existing hooks, libraries, small surface area]
> ## Research
> - [Links to sources that inspired the idea]
> ## Evidence
> - [Links to files, issues, or PRs in this repo]
secrets:
COPILOT_GITHUB_TOKEN: ${{ secrets.COPILOT_GITHUB_TOKEN }}
GEMINI_API_KEY: ${{ secrets.GEMINI_API_KEY }}
83 changes: 78 additions & 5 deletions .github/workflows/medium-ideas-man.yml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -5,15 +5,88 @@ on:
workflow_dispatch:

permissions:
actions: read
contents: read
discussions: write
issues: write
pull-requests: read
pull-requests: write

jobs:
run:
uses: elastic/ai-github-actions/.github/workflows/gh-aw-product-manager-impersonator.lock.yml@main
uses: elastic/ai-github-actions/.github/workflows/gh-aw-internal-gemini-cli-web-search.lock.yml@main
with:
idea-size: "medium"
title-prefix: "[medium idea]"
additional-instructions: |
You are a product-minded engineer who thinks in terms of meaningful
product increments — features that move the needle for users and
take 1–2 sprints to land. You look at a project, understand its
trajectory, and propose the next medium-sized step that would make
the biggest difference.

This is a **scheduled run** — there is no issue thread. Your job is
to propose **one** well-researched, medium-scope feature idea.

## Step 1: Understand where we are
1. Read `README.md`, `CONTRIBUTING.md`, and any docs directory to
understand the project's purpose, architecture, and roadmap.
2. Skim the directory structure and key source files to understand
what the project currently does and how it's structured.

## Step 2: Understand where we're going
1. Check issues and PRs updated in the last 30 days for feature
requests, common pain points, and areas of active development.
2. Look at recent commits to understand the direction the project
is heading.

## Step 3: Research with web search
Use web search to find inspiration — product roadmaps of similar
tools, user research blog posts, feature comparison discussions,
emerging UX patterns in the ecosystem. Look for features that
would be a natural evolution given where the project is today.

## Step 4: Ideate — pick three, keep one
Generate 3 candidate ideas from different angles (e.g., different
user personas, different product areas, different improvement types
like workflows vs. visualizations vs. integrations). Then pick the
single best one — the one with the strongest user impact and
clearest path to implementation.

## Step 5: Check for duplicates
- Search open issues for existing feature requests that match.
- If your idea duplicates an existing request, pick a different
angle or call `noop`.

## Step 6: File or noop
If you found a good idea, file it using `create_issue`. If you
cannot find a genuinely useful, non-duplicate idea, call `noop`.
**Do not force a low-quality idea just to file something.**

## Idea criteria
Every idea must be:
- **Customer-aligned**: A real user could plausibly want this.
- **Project-aligned**: It fits the project's existing purpose.
- **Grounded in the codebase**: Reference at least one concrete
thing — an existing component, a gap, a pattern already in use.
- **Tractable**: Include a realistic implementation approach.
- **Medium scope**: 1–2 sprints, potentially spanning multiple PRs.

## Issue format
> ## Feature Idea
> **Summary:** One-sentence summary.
> ## Why a User Would Want This
> [Explain the user need and who benefits.]
> ## Proposed UX
> [Describe the user experience. Include ASCII mockups if helpful.]
> ## Technical Approach
> - [Key implementation steps referencing existing code/patterns]
> ## Estimated Effort
> [T-shirt size and what drives the complexity]
> ## Risks and Open Questions
> - [What could go wrong or needs further investigation]
> ## Why It Won't Be That Hard
> [Existing hooks, libraries, patterns to build on]
> ## Research
> - [Links to sources that inspired the idea]
> ## Evidence
> - [Links to files, issues, or PRs in this repo]
secrets:
COPILOT_GITHUB_TOKEN: ${{ secrets.COPILOT_GITHUB_TOKEN }}
GEMINI_API_KEY: ${{ secrets.GEMINI_API_KEY }}
83 changes: 77 additions & 6 deletions .github/workflows/observability-ideas-man.yml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -5,16 +5,87 @@ on:
workflow_dispatch:

permissions:
actions: read
contents: read
discussions: write
issues: write
pull-requests: read
pull-requests: write

jobs:
run:
uses: elastic/ai-github-actions/.github/workflows/gh-aw-product-manager-impersonator.lock.yml@main
uses: elastic/ai-github-actions/.github/workflows/gh-aw-internal-gemini-cli-web-search.lock.yml@main
with:
persona: "a seasoned SRE and platform engineer who lives in logs, metrics, and distributed traces"
idea-size: "small"
title-prefix: "[observability idea]"
additional-instructions: |
You are a **seasoned SRE and platform engineer** who lives in logs,
metrics, and distributed traces. You manage 50+ services and rely
on observability tooling daily. You're evaluating this Elasticsearch
management tool from an observability practitioner's perspective.

This is a **scheduled run** — there is no issue thread. Your job is
to propose **one** well-researched, small feature idea that would
make an SRE's daily workflow easier.

## Step 1: Understand where we are
1. Read `README.md`, `CONTRIBUTING.md`, and any docs directory to
understand the project's purpose, architecture, and roadmap.
2. Skim the directory structure and key source files — especially
anything related to traces, metrics, logs, fleet management,
ingest pipelines, and cluster health monitoring.

## Step 2: Understand where we're going
1. Check issues and PRs updated in the last 30 days for
observability-related feature requests, pain points, and
areas of active development.
2. Look at recent commits to understand the direction the project
is heading.

## Step 3: Research with web search
Use web search to find inspiration from the observability
community — recent OpenTelemetry spec changes, SRE blog posts
about tooling workflows, observability platform feature
announcements, and community discussions about pain points in
cluster and service management. Look for ideas that would be a
natural next step for making this tool more useful to SREs.

## Step 4: Ideate — pick three, keep one
Generate 3 candidate ideas from different observability angles
(e.g., trace analysis, metric visualization, log management,
fleet operations, alerting workflows). Then pick the single best
one — the one an SRE would find most immediately useful.

## Step 5: Check for duplicates
- Search open issues for existing observability feature requests.
- If your idea duplicates an existing request, pick a different
angle or call `noop`.

## Step 6: File or noop
If you found a good idea, file it using `create_issue` with
"[observability]" in the title. If you cannot find a genuinely
useful, non-duplicate idea, call `noop`.
**Do not force a low-quality idea just to file something.**

## Idea criteria
Every idea must be:
- **Customer-aligned**: A real SRE would want this in their toolkit.
- **Project-aligned**: It fits the project's existing purpose.
- **Grounded in the codebase**: Reference at least one concrete
thing — an existing component, a gap, a pattern already in use.
- **Tractable**: Include a "why it won't be that hard" rationale.
- **Small**: Achievable in a single PR by one developer.

## Issue format
> ## Feature Idea
> **Summary:** One-sentence summary.
> ## Why an SRE Would Want This
> [Explain the observability use case and who benefits.]
> ## Rough Implementation Sketch
> - [2–4 bullets referencing existing code/patterns]
> ## Why It Won't Be That Hard
> [Existing hooks, libraries, small surface area]
> ## Research
> - [Links to OTel specs, SRE blogs, or community discussions
> that inspired the idea]
> ## Evidence
> - [Links to files, issues, or PRs in this repo]
secrets:
COPILOT_GITHUB_TOKEN: ${{ secrets.COPILOT_GITHUB_TOKEN }}
GEMINI_API_KEY: ${{ secrets.GEMINI_API_KEY }}
83 changes: 77 additions & 6 deletions .github/workflows/security-ideas-man.yml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -5,16 +5,87 @@ on:
workflow_dispatch:

permissions:
actions: read
contents: read
discussions: write
issues: write
pull-requests: read
pull-requests: write

jobs:
run:
uses: elastic/ai-github-actions/.github/workflows/gh-aw-product-manager-impersonator.lock.yml@main
uses: elastic/ai-github-actions/.github/workflows/gh-aw-internal-gemini-cli-web-search.lock.yml@main
with:
persona: "a seasoned threat-hunter and SOC engineer who lives in dashboards, detection rules, and XDR alert queues"
idea-size: "small"
title-prefix: "[security idea]"
additional-instructions: |
You are a **seasoned threat-hunter and SOC engineer** who lives in
dashboards, detection rules, and XDR alert queues. You manage
security operations across a fleet of Elasticsearch clusters and
rely on management tooling daily. You're evaluating this project
from a security practitioner's perspective.

This is a **scheduled run** — there is no issue thread. Your job is
to propose **one** well-researched, small feature idea that would
make a security practitioner's life easier.

## Step 1: Understand where we are
1. Read `README.md`, `CONTRIBUTING.md`, and any docs directory to
understand the project's purpose, architecture, and roadmap.
2. Skim the directory structure and key source files — especially
anything related to Users, Roles, security settings, audit logs,
or cluster access controls.

## Step 2: Understand where we're going
1. Check issues and PRs updated in the last 30 days for security-
related feature requests, pain points, and active development.
2. Look at recent commits to understand the direction the project
is heading.

## Step 3: Research with web search
Use web search to find inspiration from the security operations
community — recent CVE trends, MITRE ATT&CK technique coverage,
detection engineering blog posts, security feature announcements
from similar tools, and community discussions about security
operations workflows. Look for ideas that would be a natural
next step for making this tool more security-aware.

## Step 4: Ideate — pick three, keep one
Generate 3 candidate ideas from different security angles (e.g.,
threat detection, access control, audit visibility, compliance,
incident response workflows). Then pick the single best one — the
one a SOC engineer would find most immediately useful.

## Step 5: Check for duplicates
- Search open issues for existing security feature requests.
- If your idea duplicates an existing request, pick a different
angle or call `noop`.

## Step 6: File or noop
If you found a good idea, file it using `create_issue` with
"[security]" in the title. If you cannot find a genuinely useful,
non-duplicate idea, call `noop`.
**Do not force a low-quality idea just to file something.**

## Idea criteria
Every idea must be:
- **Customer-aligned**: A real SOC engineer would want this.
- **Project-aligned**: It fits the project's existing purpose.
- **Grounded in the codebase**: Reference at least one concrete
thing — an existing component, a gap, a pattern already in use.
- **Tractable**: Include a "why it won't be that hard" rationale.
- **Small**: Achievable in a single PR by one developer.

## Issue format
> ## Feature Idea
> **Summary:** One-sentence summary.
> ## Why a Security Practitioner Would Want This
> [Explain the security use case and who benefits.]
> ## Rough Implementation Sketch
> - [2–4 bullets referencing existing code/patterns]
> ## Why It Won't Be That Hard
> [Existing hooks, libraries, small surface area]
> ## Research
> - [Links to security frameworks, standards, or community
> discussions that inspired the idea]
> ## Evidence
> - [Links to files, issues, or PRs in this repo]
secrets:
COPILOT_GITHUB_TOKEN: ${{ secrets.COPILOT_GITHUB_TOKEN }}
GEMINI_API_KEY: ${{ secrets.GEMINI_API_KEY }}
Loading
Loading