Colin McDonnell
b6658ddbc1
* add workflows permission to git token and waitlist improvements - add `workflows` to `InstallationTokenPermissions` type in both action and API token routes - include `workflows: write` in the git token so agents can push workflow file changes - add `githubFollowers` field to WaitlistSignup schema with migration - add script to populate waitlist followers from GitHub API - add frog-green-square-border logo asset Co-authored-by: Cursor <cursoragent@cursor.com> * improve CI, agent logging, token permissions, and delegation guardrails - add format check and build step to root CI job - standardize agent model/effort log lines across all agents - fix GitHub App permissions types to match OpenAPI schema (workflows is write-only) - improve delegation error message to prevent subagent recursion - demote noisy OpenCode stderr to debug level - add subagent delegation rules to resolved instructions Co-authored-by: Cursor <cursoragent@cursor.com> * fix graphql partial error handling, update delegation message, add workflow_run fixtures Co-authored-by: Cursor <cursoragent@cursor.com> * remove module-level env var throws that break CI build Co-authored-by: Cursor <cursoragent@cursor.com> * fix logging bug and type hole from PR review - use batch-local notFound counter so per-batch log doesn't undercount - add workflows to WorkflowTokenPermissions so wire type matches what action sends Co-authored-by: Cursor <cursoragent@cursor.com> * lazy-init appOctokit to fix next build without env vars Co-authored-by: Cursor <cursoragent@cursor.com> * drop pnpm build from CI test workflow Co-authored-by: Cursor <cursoragent@cursor.com> * fix delegate-effort test regex to match actual log format, disable fail-fast for agnostic tests the test was matching `running \w+ with effort=auto` but the actual log line from shared.ts is `» effort: auto`. also temporarily set fail-fast: false on action-agnostic so all failures surface at once. Co-authored-by: Cursor <cursoragent@cursor.com> * disable fail-fast in action workflow too, relax ci.test.ts to match both workflow files now use fail-fast: false for agnostic tests so all matrix jobs run to completion. the ci consistency test now checks that the two workflows agree rather than requiring true. Co-authored-by: Cursor <cursoragent@cursor.com> * restore fail-fast: true now that all agnostic tests pass Co-authored-by: Cursor <cursoragent@cursor.com> * skip agent tests in CI when agent harness file didn't change adds action/test/changed-agents.sh which reads the PR diff (via dorny/paths-filter) and outputs only agents whose harness file was modified. the action-agents matrix now uses this dynamic list instead of a hardcoded array, so e.g. a PR touching only cursor.ts runs 6 jobs instead of 30. Co-authored-by: Cursor <cursoragent@cursor.com> * update ci.test.ts to validate dynamic agent matrix the test now checks that the matrix references the changes job output and that changed-agents.sh correctly discovers all agents. Co-authored-by: Cursor <cursoragent@cursor.com> * parallelize action jobs and use claude canary fallback for shared changes runs action-agents in parallel with action-agnostic after root/changes, and updates changed-agents logic so shared or non-harness action runtime changes run only claude while harness-specific edits run only those changed agents. Co-authored-by: Cursor <cursoragent@cursor.com> --------- Co-authored-by: Cursor <cursoragent@cursor.com>
gh_pullfrog MCP Tools
this directory contains the mcp (model context protocol) server tools for interacting with github.
available tools
check suite tools
get_check_suite_logs
get workflow run logs for a failed check suite with intelligent log analysis.
parameters:
check_suite_id(number): the id from check_suite.id in the webhook payload
replaces: gh run list and gh run view --log
returns: structured failure information for each failed job:
_instructions: explains how to use each fieldfailed_jobs[]: array of failed job results, each containing:job_id,job_name,job_url: job identificationfailed_steps: which CI steps failed (e.g., "Step 6: Run tests")log_index: array of interesting lines (errors, warnings, failures) with line numbersexcerpt: ~80 line curated window around the last errorfull_log_path: path to complete log file for deeper investigation
log_index types:
error: lines matching##[error],Error:,ERR_,exit code Nwarning: lines matching##[warning],WARNfailure: lines matchingN failed,FAIL,✕trace: stack trace lines (deduplicated)
workflow for using results:
- scan
log_indexto see where errors/warnings/failures are located in the log - read
excerptfor immediate context around the main error - if excerpt doesn't show what you need, read specific line ranges from
full_log_path - check
failed_stepsand read the workflow yml to understand what command failed
example:
// when handling a check_suite_completed webhook
const result = await mcp.call("gh_pullfrog/get_check_suite_logs", {
check_suite_id: check_suite.id
});
// result.failed_jobs[0].log_index shows:
// [
// { line: 181, content: "WARN Failed to create bin...", type: "warning" },
// { line: 1079, content: "Error: expect(received).toBe(expected)", type: "error" },
// ...
// ]
// use these line numbers to read specific sections from full_log_path
review tools
get_review_comments
get all line-by-line comments for a specific pull request review, including full thread context for replies.
parameters:
pull_number(number): the pull request numberreview_id(number): the id from review.id in the webhook payloadapproved_by(string, optional): only return comments this user gave a 👍 to
replaces: gh api repos/{owner}/{repo}/pulls/{pull_number}/reviews/{review_id}/comments
returns:
commentsPath: path to XML file with full comment detailsreviewer: github username of the review authorcount: number of comments to address
output format (XML):
<review_comments count="2" reviewer="colinmcd94">
<summary>
<comment id="67890" file="src/utils/auth.ts" line="42">Actually, can you use a type guard...</comment>
<comment id="67891" file="src/api/handler.ts" line="15">This should handle the error case</comment>
</summary>
<comment id="67890" file="src/utils/auth.ts" line="42" author="colinmcd94">
<thread>
<message id="12345" author="colinmcd94">Please add null checking here</message>
<message id="23456" author="octocat">What about using optional chaining?</message>
</thread>
<diff>
@@ -40,7 +40,7 @@
const user = getUser(id);
- return user.name;
+ return user?.name;
</diff>
<body>Actually, can you use a type guard instead?</body>
</comment>
</review_comments>
<summary>lists all comments to address with truncated preview<thread>shows parent comments (when replying to existing thread)<diff>contains the diff hunk around the commented line<body>is the actual comment text to address
example:
// when handling a pull_request_review_submitted webhook
await mcp.call("gh_pullfrog/get_review_comments", {
pull_number: 47,
review_id: review.id
});
list_pull_request_reviews
list all reviews for a pull request.
parameters:
pull_number(number): the pull request number
replaces: gh api repos/{owner}/{repo}/pulls/{pull_number}/reviews
returns: array of reviews with:
- review id, body, state (approved/changes_requested/commented)
- user, commit_id, submitted_at, html_url
example:
await mcp.call("gh_pullfrog/list_pull_request_reviews", {
pull_number: 47
});
reply_to_review_comment
reply to a PR review comment thread explaining how the feedback was addressed.
parameters:
pull_number(number): the pull request numbercomment_id(number): the ID of the review comment to reply tobody(string): the reply text explaining how the feedback was addressed
replaces: gh api repos/{owner}/{repo}/pulls/{pull_number}/comments/{comment_id}/replies
returns: the created reply comment including:
- comment id, body, html_url
- in_reply_to_id showing it's a reply to the specified comment
example:
// after addressing a review comment
await mcp.call("gh_pullfrog/reply_to_review_comment", {
pull_number: 47,
comment_id: 2567334961,
body: "removed the function as requested"
});
output tools
set_output
set the action output for consumption by subsequent workflow steps. useful when pullfrog is used as a step in a user-defined CI workflow (e.g., generating release notes).
parameters:
value(string): the output value to expose
returns:
success: true on success
the value will be available as the result output of the action, accessible via ${{ steps.<step-id>.outputs.result }}.
example:
// when generating content for downstream consumption
await mcp.call("gh_pullfrog/set_output", {
value: "## Release Notes\n\n- Added new feature X\n- Fixed bug Y"
});
usage in workflow:
- uses: pullfrog/pullfrog@v1
id: notes
with:
prompt: "Generate release notes for v2.0.0"
- uses: softprops/action-gh-release@v1
with:
body: ${{ steps.notes.outputs.result }}
other tools
see individual files for documentation on other tools:
comment.ts- create, edit, and update commentsissue.ts- create issuesoutput.ts- set action output for workflow consumptionpr.ts- create pull requestsprInfo.ts- get pull request informationreview.ts- create pull request reviewsdelegate.ts- delegate task to a subagent with a specific mode and effort level
usage in agents
agents should prefer using the mcp tools provided by this server. the gh cli is available as a fallback if needed, but mcp tools handle authentication and provide better integration.
the agent instructions automatically include guidance on using these tools.