For advanced use cases, you can define standalone 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’ll manage trigger conditions and prompts directly in your workflow files.
When to use manual setup
Use standalone workflows if you:
- Need trigger conditions the dashboard doesn’t support
- Want to customize the workflow beyond what the dashboard provides
- Prefer to manage workflows directly in version control
- Want complete separation between different agent tasks
Examples
Below are complete, self-contained workflow files for common use cases. Each workflow handles a specific task with a human-readable prompt.
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 your prompt, the better the results. Describe exactly what you want the agent to do.
- Scope permissions: Only grant the permissions 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 them.
