For advanced use cases, you can define standalone GitHub Actions workflows that call pullfrog/pullfrog@v0 directly instead of using the dashboard. This gives you full control over when and how Pullfrog runs.
Custom workflows bypass dashboard configuration. You manage trigger conditions and prompts entirely in your workflow files.
When to use this
Standalone workflows make sense when you:
- Need trigger conditions the dashboard doesn’t support (e.g., triggering on specific labels, paths, or schedules)
- Want to customize the workflow beyond what the dashboard provides
- Prefer to manage everything in version control
- Want complete separation between different agent tasks
Examples
Below are complete, self-contained workflow files for common use cases. Copy them into .github/workflows/ and adjust the prompt to fit your project.
PR review
Automatically review new pull requests:
# .github/workflows/pullfrog-pr-review.yml
name: PR Review
on:
pull_request:
types: [opened, ready_for_review]
permissions:
id-token: write
contents: read
pull-requests: write
jobs:
review:
runs-on: ubuntu-latest
if: github.event.pull_request.draft == false
steps:
- uses: actions/checkout@v6
with:
fetch-depth: 1
- uses: pullfrog/pullfrog@v0
with:
prompt: |
Review this PR. Focus on:
- Code correctness and potential bugs
- Security issues
- Performance concerns
- Adherence to project conventions
Be constructive and specific. Approve if the changes look good,
or request changes with actionable feedback.
env:
ANTHROPIC_API_KEY: ${{ secrets.ANTHROPIC_API_KEY }}
Issue enrichment
Automatically enrich new issues with context and implementation suggestions:
# .github/workflows/pullfrog-issue-enrichment.yml
name: Issue Enrichment
on:
issues:
types: [opened]
permissions:
id-token: write
contents: read
issues: write
jobs:
enrich:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v6
with:
fetch-depth: 1
- uses: pullfrog/pullfrog@v0
with:
prompt: |
A new issue was opened. Please:
1. Analyze the issue and identify relevant code in the repository
2. Link to any related issues or PRs if they exist
3. Suggest an implementation approach if this is a feature request
4. Identify potential complexity or blockers
Add your analysis as a comment on the issue. Be helpful and concise.
env:
ANTHROPIC_API_KEY: ${{ secrets.ANTHROPIC_API_KEY }}
Issue auto-labeling
Automatically label new issues based on their content:
# .github/workflows/pullfrog-issue-labeling.yml
name: Issue Labeling
on:
issues:
types: [opened]
permissions:
id-token: write
contents: read
issues: write
jobs:
label:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v6
with:
fetch-depth: 1
- uses: pullfrog/pullfrog@v0
with:
prompt: |
Analyze this new issue and apply appropriate labels.
Consider labels like:
- bug, feature, documentation, question
- priority:high, priority:medium, priority:low
- area:frontend, area:backend, area:api (based on what code would change)
Only apply labels that already exist in the repository.
Do not create new labels. Add 1-3 relevant labels maximum.
env:
ANTHROPIC_API_KEY: ${{ secrets.ANTHROPIC_API_KEY }}
Required permissions
| Permission | Purpose |
|---|
id-token: write | Authentication with Pullfrog |
contents: write | Create branches and commits |
pull-requests: write | Create and update PRs, submit reviews |
issues: write | Create and update issues |
actions: read | Read workflow status |
checks: read | Read CI check results |
Tips
- Use specific prompts — the more specific, the better. Describe exactly what you want the agent to do.
- Scope permissions — only grant what each workflow actually needs.
- Add conditions — use
if: conditions to prevent unnecessary runs (e.g., skip draft PRs, filter by label).
- Separate concerns — create separate workflow files for different tasks rather than combining everything into one.
