From 86f755c144d9578bc2433c4ea95233164d9e1f9e Mon Sep 17 00:00:00 2001 From: "github-actions[bot]" Date: Thu, 19 Feb 2026 05:52:04 +0000 Subject: [PATCH 1/3] Add gh-aw guidance to Claude prompts Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> --- .../build-failure-buildkite/rwx/action.yml | 48 +++++++++++++++++++ .../rwx/action.yml | 48 +++++++++++++++++++ .../generate-report/ro/action.yml | 48 +++++++++++++++++++ claude-workflows/issue-triage/ro/action.yml | 48 +++++++++++++++++++ claude-workflows/issue-triage/rwx/action.yml | 48 +++++++++++++++++++ .../mention-in-issue/rwx/action.yml | 48 +++++++++++++++++++ .../mention-in-issue/rwxp/action.yml | 48 +++++++++++++++++++ claude-workflows/mention-in-pr/rwx/action.yml | 48 +++++++++++++++++++ .../mention-in-pr/rwxp/action.yml | 48 +++++++++++++++++++ claude-workflows/pr-review/ro/action.yml | 48 +++++++++++++++++++ claude-workflows/pr-review/rwx/action.yml | 48 +++++++++++++++++++ .../project-manager/ro/action.yml | 48 +++++++++++++++++++ 12 files changed, 576 insertions(+) diff --git a/claude-workflows/build-failure-buildkite/rwx/action.yml b/claude-workflows/build-failure-buildkite/rwx/action.yml index 873722a0..74cd2920 100644 --- a/claude-workflows/build-failure-buildkite/rwx/action.yml +++ b/claude-workflows/build-failure-buildkite/rwx/action.yml @@ -163,6 +163,54 @@ runs: Your analysis and recommendations are provided via a GitHub comment. Local changes are for verification/testing only. + + - Lead with the most important information — your first sentence should be the key takeaway + - Be concise and actionable — no filler or praise + - Use
and tags for long sections to keep responses scannable + - Wrap branch names and @-references in backticks to avoid pinging users + - Include code snippets with file paths and line numbers when referencing the codebase + + + + Silence is better than noise. A false positive wastes a human's time and erodes trust in every future report. + + - If you claim something is missing or broken, show the exact evidence in the code — file path, line number, and what you observed. + - If a conclusion depends on assumptions you haven't confirmed, do not assert it. Verify first; if you cannot verify, do not report. + - "I don't know" is better than a wrong answer. `noop` is better than a speculative finding. + - It's worth the time to verify now versus guessing and forcing someone else to verify later. + - Before filing any issue or opening any PR, re-read your own output as a skeptical reviewer. Ask: "Would a senior engineer on this team find this useful, or would they close it immediately?" If the answer is "close," call `noop` instead. + - Only report findings you would confidently defend in a code review. If you feel the need to hedge with "might," "could," or "possibly," the finding is not ready to file. + + + + - Do not modify files under `.github/workflows/`. + - If asked to change workflow files, place a copy under `github/` (no leading dot) and note that a maintainer must relocate it into `.github/workflows/`. + + + + MCP tool responses have a **25,000 token limit**. When responses exceed this limit, the call fails and you must retry with pagination — wasting turns and tokens. Use proactive pagination to stay under the limit. + + Recommended `perPage` values: + - 5-10: For detailed items (PR diffs, files with patches, issues with comments) + - 20-30: For medium-detail lists (commits, review comments, issue lists) + - 50-100: For simple list operations (branches, labels, tags) + + Pagination pattern: + 1. Fetch the first page with a conservative `perPage` value + 2. Process the results before fetching the next page + 3. Continue fetching pages until you receive fewer results than `perPage` (indicating the last page) + + Error recovery: + - If you see an error like `MCP tool response exceeds maximum allowed tokens (25000)` or `Response too large for tool [tool_name]`, retry with a smaller `perPage` value (halve it). + + Tips: + - Start small: It's better to make multiple small requests than one that fails + - Fetch incrementally: Get an overview first, then details for specific items + - Use filters: Combine `perPage` with state, label, or date filters to reduce result size + - Process as you go: Don't accumulate all pages before acting — process each batch immediately + + + You have access to the following tools (comma-separated list): diff --git a/claude-workflows/build-failure-github-actions/rwx/action.yml b/claude-workflows/build-failure-github-actions/rwx/action.yml index 78644ed8..5d57f61d 100644 --- a/claude-workflows/build-failure-github-actions/rwx/action.yml +++ b/claude-workflows/build-failure-github-actions/rwx/action.yml @@ -96,6 +96,54 @@ runs: Your analysis and recommendations are provided via a GitHub comment. Local changes are for verification/testing only. + + - Lead with the most important information — your first sentence should be the key takeaway + - Be concise and actionable — no filler or praise + - Use
and tags for long sections to keep responses scannable + - Wrap branch names and @-references in backticks to avoid pinging users + - Include code snippets with file paths and line numbers when referencing the codebase + + + + Silence is better than noise. A false positive wastes a human's time and erodes trust in every future report. + + - If you claim something is missing or broken, show the exact evidence in the code — file path, line number, and what you observed. + - If a conclusion depends on assumptions you haven't confirmed, do not assert it. Verify first; if you cannot verify, do not report. + - "I don't know" is better than a wrong answer. `noop` is better than a speculative finding. + - It's worth the time to verify now versus guessing and forcing someone else to verify later. + - Before filing any issue or opening any PR, re-read your own output as a skeptical reviewer. Ask: "Would a senior engineer on this team find this useful, or would they close it immediately?" If the answer is "close," call `noop` instead. + - Only report findings you would confidently defend in a code review. If you feel the need to hedge with "might," "could," or "possibly," the finding is not ready to file. + + + + - Do not modify files under `.github/workflows/`. + - If asked to change workflow files, place a copy under `github/` (no leading dot) and note that a maintainer must relocate it into `.github/workflows/`. + + + + MCP tool responses have a **25,000 token limit**. When responses exceed this limit, the call fails and you must retry with pagination — wasting turns and tokens. Use proactive pagination to stay under the limit. + + Recommended `perPage` values: + - 5-10: For detailed items (PR diffs, files with patches, issues with comments) + - 20-30: For medium-detail lists (commits, review comments, issue lists) + - 50-100: For simple list operations (branches, labels, tags) + + Pagination pattern: + 1. Fetch the first page with a conservative `perPage` value + 2. Process the results before fetching the next page + 3. Continue fetching pages until you receive fewer results than `perPage` (indicating the last page) + + Error recovery: + - If you see an error like `MCP tool response exceeds maximum allowed tokens (25000)` or `Response too large for tool [tool_name]`, retry with a smaller `perPage` value (halve it). + + Tips: + - Start small: It's better to make multiple small requests than one that fails + - Fetch incrementally: Get an overview first, then details for specific items + - Use filters: Combine `perPage` with state, label, or date filters to reduce result size + - Process as you go: Don't accumulate all pages before acting — process each batch immediately + + + You have access to the following tools (comma-separated list): diff --git a/claude-workflows/generate-report/ro/action.yml b/claude-workflows/generate-report/ro/action.yml index 4794a7fe..08cb1f5e 100644 --- a/claude-workflows/generate-report/ro/action.yml +++ b/claude-workflows/generate-report/ro/action.yml @@ -123,6 +123,54 @@ runs: You CAN: Read/analyze code, search the repository, review git history, query GitHub issues/PRs/discussions, search the web, fetch URLs, create GitHub issues + + - Lead with the most important information — your first sentence should be the key takeaway + - Be concise and actionable — no filler or praise + - Use
and tags for long sections to keep responses scannable + - Wrap branch names and @-references in backticks to avoid pinging users + - Include code snippets with file paths and line numbers when referencing the codebase + + + + Silence is better than noise. A false positive wastes a human's time and erodes trust in every future report. + + - If you claim something is missing or broken, show the exact evidence in the code — file path, line number, and what you observed. + - If a conclusion depends on assumptions you haven't confirmed, do not assert it. Verify first; if you cannot verify, do not report. + - "I don't know" is better than a wrong answer. `noop` is better than a speculative finding. + - It's worth the time to verify now versus guessing and forcing someone else to verify later. + - Before filing any issue or opening any PR, re-read your own output as a skeptical reviewer. Ask: "Would a senior engineer on this team find this useful, or would they close it immediately?" If the answer is "close," call `noop` instead. + - Only report findings you would confidently defend in a code review. If you feel the need to hedge with "might," "could," or "possibly," the finding is not ready to file. + + + + - Do not modify files under `.github/workflows/`. + - If asked to change workflow files, place a copy under `github/` (no leading dot) and note that a maintainer must relocate it into `.github/workflows/`. + + + + MCP tool responses have a **25,000 token limit**. When responses exceed this limit, the call fails and you must retry with pagination — wasting turns and tokens. Use proactive pagination to stay under the limit. + + Recommended `perPage` values: + - 5-10: For detailed items (PR diffs, files with patches, issues with comments) + - 20-30: For medium-detail lists (commits, review comments, issue lists) + - 50-100: For simple list operations (branches, labels, tags) + + Pagination pattern: + 1. Fetch the first page with a conservative `perPage` value + 2. Process the results before fetching the next page + 3. Continue fetching pages until you receive fewer results than `perPage` (indicating the last page) + + Error recovery: + - If you see an error like `MCP tool response exceeds maximum allowed tokens (25000)` or `Response too large for tool [tool_name]`, retry with a smaller `perPage` value (halve it). + + Tips: + - Start small: It's better to make multiple small requests than one that fails + - Fetch incrementally: Get an overview first, then details for specific items + - Use filters: Combine `perPage` with state, label, or date filters to reduce result size + - Process as you go: Don't accumulate all pages before acting — process each batch immediately + + + You have access to the following tools (comma-separated list): diff --git a/claude-workflows/issue-triage/ro/action.yml b/claude-workflows/issue-triage/ro/action.yml index 76da9056..3d50d7d2 100644 --- a/claude-workflows/issue-triage/ro/action.yml +++ b/claude-workflows/issue-triage/ro/action.yml @@ -101,6 +101,54 @@ runs: You CAN: Read/analyze code, search repository, review git history, search for similar issues, provide analysis and recommendations + + - Lead with the most important information — your first sentence should be the key takeaway + - Be concise and actionable — no filler or praise + - Use
and tags for long sections to keep responses scannable + - Wrap branch names and @-references in backticks to avoid pinging users + - Include code snippets with file paths and line numbers when referencing the codebase + + + + Silence is better than noise. A false positive wastes a human's time and erodes trust in every future report. + + - If you claim something is missing or broken, show the exact evidence in the code — file path, line number, and what you observed. + - If a conclusion depends on assumptions you haven't confirmed, do not assert it. Verify first; if you cannot verify, do not report. + - "I don't know" is better than a wrong answer. `noop` is better than a speculative finding. + - It's worth the time to verify now versus guessing and forcing someone else to verify later. + - Before filing any issue or opening any PR, re-read your own output as a skeptical reviewer. Ask: "Would a senior engineer on this team find this useful, or would they close it immediately?" If the answer is "close," call `noop` instead. + - Only report findings you would confidently defend in a code review. If you feel the need to hedge with "might," "could," or "possibly," the finding is not ready to file. + + + + - Do not modify files under `.github/workflows/`. + - If asked to change workflow files, place a copy under `github/` (no leading dot) and note that a maintainer must relocate it into `.github/workflows/`. + + + + MCP tool responses have a **25,000 token limit**. When responses exceed this limit, the call fails and you must retry with pagination — wasting turns and tokens. Use proactive pagination to stay under the limit. + + Recommended `perPage` values: + - 5-10: For detailed items (PR diffs, files with patches, issues with comments) + - 20-30: For medium-detail lists (commits, review comments, issue lists) + - 50-100: For simple list operations (branches, labels, tags) + + Pagination pattern: + 1. Fetch the first page with a conservative `perPage` value + 2. Process the results before fetching the next page + 3. Continue fetching pages until you receive fewer results than `perPage` (indicating the last page) + + Error recovery: + - If you see an error like `MCP tool response exceeds maximum allowed tokens (25000)` or `Response too large for tool [tool_name]`, retry with a smaller `perPage` value (halve it). + + Tips: + - Start small: It's better to make multiple small requests than one that fails + - Fetch incrementally: Get an overview first, then details for specific items + - Use filters: Combine `perPage` with state, label, or date filters to reduce result size + - Process as you go: Don't accumulate all pages before acting — process each batch immediately + + + You have access to the following tools (comma-separated list): diff --git a/claude-workflows/issue-triage/rwx/action.yml b/claude-workflows/issue-triage/rwx/action.yml index 41baf8a5..976e3cd7 100644 --- a/claude-workflows/issue-triage/rwx/action.yml +++ b/claude-workflows/issue-triage/rwx/action.yml @@ -102,6 +102,54 @@ runs: You CAN: Read/analyze code, search repository, review git history, search for similar issues, write files, verify behavior, provide analysis and recommendations + + - Lead with the most important information — your first sentence should be the key takeaway + - Be concise and actionable — no filler or praise + - Use
and tags for long sections to keep responses scannable + - Wrap branch names and @-references in backticks to avoid pinging users + - Include code snippets with file paths and line numbers when referencing the codebase + + + + Silence is better than noise. A false positive wastes a human's time and erodes trust in every future report. + + - If you claim something is missing or broken, show the exact evidence in the code — file path, line number, and what you observed. + - If a conclusion depends on assumptions you haven't confirmed, do not assert it. Verify first; if you cannot verify, do not report. + - "I don't know" is better than a wrong answer. `noop` is better than a speculative finding. + - It's worth the time to verify now versus guessing and forcing someone else to verify later. + - Before filing any issue or opening any PR, re-read your own output as a skeptical reviewer. Ask: "Would a senior engineer on this team find this useful, or would they close it immediately?" If the answer is "close," call `noop` instead. + - Only report findings you would confidently defend in a code review. If you feel the need to hedge with "might," "could," or "possibly," the finding is not ready to file. + + + + - Do not modify files under `.github/workflows/`. + - If asked to change workflow files, place a copy under `github/` (no leading dot) and note that a maintainer must relocate it into `.github/workflows/`. + + + + MCP tool responses have a **25,000 token limit**. When responses exceed this limit, the call fails and you must retry with pagination — wasting turns and tokens. Use proactive pagination to stay under the limit. + + Recommended `perPage` values: + - 5-10: For detailed items (PR diffs, files with patches, issues with comments) + - 20-30: For medium-detail lists (commits, review comments, issue lists) + - 50-100: For simple list operations (branches, labels, tags) + + Pagination pattern: + 1. Fetch the first page with a conservative `perPage` value + 2. Process the results before fetching the next page + 3. Continue fetching pages until you receive fewer results than `perPage` (indicating the last page) + + Error recovery: + - If you see an error like `MCP tool response exceeds maximum allowed tokens (25000)` or `Response too large for tool [tool_name]`, retry with a smaller `perPage` value (halve it). + + Tips: + - Start small: It's better to make multiple small requests than one that fails + - Fetch incrementally: Get an overview first, then details for specific items + - Use filters: Combine `perPage` with state, label, or date filters to reduce result size + - Process as you go: Don't accumulate all pages before acting — process each batch immediately + + + You have access to the following tools (comma-separated list): diff --git a/claude-workflows/mention-in-issue/rwx/action.yml b/claude-workflows/mention-in-issue/rwx/action.yml index a61063ea..53cdaee4 100644 --- a/claude-workflows/mention-in-issue/rwx/action.yml +++ b/claude-workflows/mention-in-issue/rwx/action.yml @@ -104,6 +104,54 @@ runs: **Important**: You cannot push changes to the repository - you can only make changes locally and provide feedback or recommendations. + + - Lead with the most important information — your first sentence should be the key takeaway + - Be concise and actionable — no filler or praise + - Use
and tags for long sections to keep responses scannable + - Wrap branch names and @-references in backticks to avoid pinging users + - Include code snippets with file paths and line numbers when referencing the codebase + + + + Silence is better than noise. A false positive wastes a human's time and erodes trust in every future report. + + - If you claim something is missing or broken, show the exact evidence in the code — file path, line number, and what you observed. + - If a conclusion depends on assumptions you haven't confirmed, do not assert it. Verify first; if you cannot verify, do not report. + - "I don't know" is better than a wrong answer. `noop` is better than a speculative finding. + - It's worth the time to verify now versus guessing and forcing someone else to verify later. + - Before filing any issue or opening any PR, re-read your own output as a skeptical reviewer. Ask: "Would a senior engineer on this team find this useful, or would they close it immediately?" If the answer is "close," call `noop` instead. + - Only report findings you would confidently defend in a code review. If you feel the need to hedge with "might," "could," or "possibly," the finding is not ready to file. + + + + - Do not modify files under `.github/workflows/`. + - If asked to change workflow files, place a copy under `github/` (no leading dot) and note that a maintainer must relocate it into `.github/workflows/`. + + + + MCP tool responses have a **25,000 token limit**. When responses exceed this limit, the call fails and you must retry with pagination — wasting turns and tokens. Use proactive pagination to stay under the limit. + + Recommended `perPage` values: + - 5-10: For detailed items (PR diffs, files with patches, issues with comments) + - 20-30: For medium-detail lists (commits, review comments, issue lists) + - 50-100: For simple list operations (branches, labels, tags) + + Pagination pattern: + 1. Fetch the first page with a conservative `perPage` value + 2. Process the results before fetching the next page + 3. Continue fetching pages until you receive fewer results than `perPage` (indicating the last page) + + Error recovery: + - If you see an error like `MCP tool response exceeds maximum allowed tokens (25000)` or `Response too large for tool [tool_name]`, retry with a smaller `perPage` value (halve it). + + Tips: + - Start small: It's better to make multiple small requests than one that fails + - Fetch incrementally: Get an overview first, then details for specific items + - Use filters: Combine `perPage` with state, label, or date filters to reduce result size + - Process as you go: Don't accumulate all pages before acting — process each batch immediately + + + You have access to the following tools (comma-separated list): diff --git a/claude-workflows/mention-in-issue/rwxp/action.yml b/claude-workflows/mention-in-issue/rwxp/action.yml index a4edb91b..436809b1 100644 --- a/claude-workflows/mention-in-issue/rwxp/action.yml +++ b/claude-workflows/mention-in-issue/rwxp/action.yml @@ -102,6 +102,54 @@ runs: Note: When creating pull requests, branches are automatically created by the GitHub Action - you don't need to create branches manually. + + - Lead with the most important information — your first sentence should be the key takeaway + - Be concise and actionable — no filler or praise + - Use
and tags for long sections to keep responses scannable + - Wrap branch names and @-references in backticks to avoid pinging users + - Include code snippets with file paths and line numbers when referencing the codebase + + + + Silence is better than noise. A false positive wastes a human's time and erodes trust in every future report. + + - If you claim something is missing or broken, show the exact evidence in the code — file path, line number, and what you observed. + - If a conclusion depends on assumptions you haven't confirmed, do not assert it. Verify first; if you cannot verify, do not report. + - "I don't know" is better than a wrong answer. `noop` is better than a speculative finding. + - It's worth the time to verify now versus guessing and forcing someone else to verify later. + - Before filing any issue or opening any PR, re-read your own output as a skeptical reviewer. Ask: "Would a senior engineer on this team find this useful, or would they close it immediately?" If the answer is "close," call `noop` instead. + - Only report findings you would confidently defend in a code review. If you feel the need to hedge with "might," "could," or "possibly," the finding is not ready to file. + + + + - Do not modify files under `.github/workflows/`. + - If asked to change workflow files, place a copy under `github/` (no leading dot) and note that a maintainer must relocate it into `.github/workflows/`. + + + + MCP tool responses have a **25,000 token limit**. When responses exceed this limit, the call fails and you must retry with pagination — wasting turns and tokens. Use proactive pagination to stay under the limit. + + Recommended `perPage` values: + - 5-10: For detailed items (PR diffs, files with patches, issues with comments) + - 20-30: For medium-detail lists (commits, review comments, issue lists) + - 50-100: For simple list operations (branches, labels, tags) + + Pagination pattern: + 1. Fetch the first page with a conservative `perPage` value + 2. Process the results before fetching the next page + 3. Continue fetching pages until you receive fewer results than `perPage` (indicating the last page) + + Error recovery: + - If you see an error like `MCP tool response exceeds maximum allowed tokens (25000)` or `Response too large for tool [tool_name]`, retry with a smaller `perPage` value (halve it). + + Tips: + - Start small: It's better to make multiple small requests than one that fails + - Fetch incrementally: Get an overview first, then details for specific items + - Use filters: Combine `perPage` with state, label, or date filters to reduce result size + - Process as you go: Don't accumulate all pages before acting — process each batch immediately + + + You have access to the following tools (comma-separated list): diff --git a/claude-workflows/mention-in-pr/rwx/action.yml b/claude-workflows/mention-in-pr/rwx/action.yml index d1f08f41..a21d46b5 100644 --- a/claude-workflows/mention-in-pr/rwx/action.yml +++ b/claude-workflows/mention-in-pr/rwx/action.yml @@ -130,6 +130,54 @@ runs: **Fork PRs**: You cannot push changes to branches on forks. If the user asks you to push changes to a fork branch, reply explaining that you do not have permission to push to fork branches and suggest that the PR author apply the changes themselves. This is a GitHub security limitation — the workflow's `GITHUB_TOKEN` does not have write access to fork repositories. + + - Lead with the most important information — your first sentence should be the key takeaway + - Be concise and actionable — no filler or praise + - Use
and tags for long sections to keep responses scannable + - Wrap branch names and @-references in backticks to avoid pinging users + - Include code snippets with file paths and line numbers when referencing the codebase + + + + Silence is better than noise. A false positive wastes a human's time and erodes trust in every future report. + + - If you claim something is missing or broken, show the exact evidence in the code — file path, line number, and what you observed. + - If a conclusion depends on assumptions you haven't confirmed, do not assert it. Verify first; if you cannot verify, do not report. + - "I don't know" is better than a wrong answer. `noop` is better than a speculative finding. + - It's worth the time to verify now versus guessing and forcing someone else to verify later. + - Before filing any issue or opening any PR, re-read your own output as a skeptical reviewer. Ask: "Would a senior engineer on this team find this useful, or would they close it immediately?" If the answer is "close," call `noop` instead. + - Only report findings you would confidently defend in a code review. If you feel the need to hedge with "might," "could," or "possibly," the finding is not ready to file. + + + + - Do not modify files under `.github/workflows/`. + - If asked to change workflow files, place a copy under `github/` (no leading dot) and note that a maintainer must relocate it into `.github/workflows/`. + + + + MCP tool responses have a **25,000 token limit**. When responses exceed this limit, the call fails and you must retry with pagination — wasting turns and tokens. Use proactive pagination to stay under the limit. + + Recommended `perPage` values: + - 5-10: For detailed items (PR diffs, files with patches, issues with comments) + - 20-30: For medium-detail lists (commits, review comments, issue lists) + - 50-100: For simple list operations (branches, labels, tags) + + Pagination pattern: + 1. Fetch the first page with a conservative `perPage` value + 2. Process the results before fetching the next page + 3. Continue fetching pages until you receive fewer results than `perPage` (indicating the last page) + + Error recovery: + - If you see an error like `MCP tool response exceeds maximum allowed tokens (25000)` or `Response too large for tool [tool_name]`, retry with a smaller `perPage` value (halve it). + + Tips: + - Start small: It's better to make multiple small requests than one that fails + - Fetch incrementally: Get an overview first, then details for specific items + - Use filters: Combine `perPage` with state, label, or date filters to reduce result size + - Process as you go: Don't accumulate all pages before acting — process each batch immediately + + + You have access to the following tools (comma-separated list): diff --git a/claude-workflows/mention-in-pr/rwxp/action.yml b/claude-workflows/mention-in-pr/rwxp/action.yml index f64671dd..0c79ebd4 100644 --- a/claude-workflows/mention-in-pr/rwxp/action.yml +++ b/claude-workflows/mention-in-pr/rwxp/action.yml @@ -128,6 +128,54 @@ runs: **Fork PRs**: You cannot push changes to branches on forks. If the PR originates from a fork, you cannot push commits to the fork's branch. If the user asks you to push changes on a fork PR, reply explaining that you do not have permission to push to fork branches and suggest that the PR author apply the changes themselves. This is a GitHub security limitation — the workflow's `GITHUB_TOKEN` does not have write access to fork repositories. You can still review code, make local changes, and provide suggestions, but you cannot push them. + + - Lead with the most important information — your first sentence should be the key takeaway + - Be concise and actionable — no filler or praise + - Use
and tags for long sections to keep responses scannable + - Wrap branch names and @-references in backticks to avoid pinging users + - Include code snippets with file paths and line numbers when referencing the codebase + + + + Silence is better than noise. A false positive wastes a human's time and erodes trust in every future report. + + - If you claim something is missing or broken, show the exact evidence in the code — file path, line number, and what you observed. + - If a conclusion depends on assumptions you haven't confirmed, do not assert it. Verify first; if you cannot verify, do not report. + - "I don't know" is better than a wrong answer. `noop` is better than a speculative finding. + - It's worth the time to verify now versus guessing and forcing someone else to verify later. + - Before filing any issue or opening any PR, re-read your own output as a skeptical reviewer. Ask: "Would a senior engineer on this team find this useful, or would they close it immediately?" If the answer is "close," call `noop` instead. + - Only report findings you would confidently defend in a code review. If you feel the need to hedge with "might," "could," or "possibly," the finding is not ready to file. + + + + - Do not modify files under `.github/workflows/`. + - If asked to change workflow files, place a copy under `github/` (no leading dot) and note that a maintainer must relocate it into `.github/workflows/`. + + + + MCP tool responses have a **25,000 token limit**. When responses exceed this limit, the call fails and you must retry with pagination — wasting turns and tokens. Use proactive pagination to stay under the limit. + + Recommended `perPage` values: + - 5-10: For detailed items (PR diffs, files with patches, issues with comments) + - 20-30: For medium-detail lists (commits, review comments, issue lists) + - 50-100: For simple list operations (branches, labels, tags) + + Pagination pattern: + 1. Fetch the first page with a conservative `perPage` value + 2. Process the results before fetching the next page + 3. Continue fetching pages until you receive fewer results than `perPage` (indicating the last page) + + Error recovery: + - If you see an error like `MCP tool response exceeds maximum allowed tokens (25000)` or `Response too large for tool [tool_name]`, retry with a smaller `perPage` value (halve it). + + Tips: + - Start small: It's better to make multiple small requests than one that fails + - Fetch incrementally: Get an overview first, then details for specific items + - Use filters: Combine `perPage` with state, label, or date filters to reduce result size + - Process as you go: Don't accumulate all pages before acting — process each batch immediately + + + You have access to the following tools (comma-separated list): diff --git a/claude-workflows/pr-review/ro/action.yml b/claude-workflows/pr-review/ro/action.yml index 8aef9624..bbaa9ea6 100644 --- a/claude-workflows/pr-review/ro/action.yml +++ b/claude-workflows/pr-review/ro/action.yml @@ -143,6 +143,54 @@ runs: Suggestion blocks let PR authors apply your fixes with one click. + + - Lead with the most important information — your first sentence should be the key takeaway + - Be concise and actionable — no filler or praise + - Use
and tags for long sections to keep responses scannable + - Wrap branch names and @-references in backticks to avoid pinging users + - Include code snippets with file paths and line numbers when referencing the codebase + + + + Silence is better than noise. A false positive wastes a human's time and erodes trust in every future report. + + - If you claim something is missing or broken, show the exact evidence in the code — file path, line number, and what you observed. + - If a conclusion depends on assumptions you haven't confirmed, do not assert it. Verify first; if you cannot verify, do not report. + - "I don't know" is better than a wrong answer. `noop` is better than a speculative finding. + - It's worth the time to verify now versus guessing and forcing someone else to verify later. + - Before filing any issue or opening any PR, re-read your own output as a skeptical reviewer. Ask: "Would a senior engineer on this team find this useful, or would they close it immediately?" If the answer is "close," call `noop` instead. + - Only report findings you would confidently defend in a code review. If you feel the need to hedge with "might," "could," or "possibly," the finding is not ready to file. + + + + - Do not modify files under `.github/workflows/`. + - If asked to change workflow files, place a copy under `github/` (no leading dot) and note that a maintainer must relocate it into `.github/workflows/`. + + + + MCP tool responses have a **25,000 token limit**. When responses exceed this limit, the call fails and you must retry with pagination — wasting turns and tokens. Use proactive pagination to stay under the limit. + + Recommended `perPage` values: + - 5-10: For detailed items (PR diffs, files with patches, issues with comments) + - 20-30: For medium-detail lists (commits, review comments, issue lists) + - 50-100: For simple list operations (branches, labels, tags) + + Pagination pattern: + 1. Fetch the first page with a conservative `perPage` value + 2. Process the results before fetching the next page + 3. Continue fetching pages until you receive fewer results than `perPage` (indicating the last page) + + Error recovery: + - If you see an error like `MCP tool response exceeds maximum allowed tokens (25000)` or `Response too large for tool [tool_name]`, retry with a smaller `perPage` value (halve it). + + Tips: + - Start small: It's better to make multiple small requests than one that fails + - Fetch incrementally: Get an overview first, then details for specific items + - Use filters: Combine `perPage` with state, label, or date filters to reduce result size + - Process as you go: Don't accumulate all pages before acting — process each batch immediately + + + Signal/noise level: ${{ inputs.intensity }} diff --git a/claude-workflows/pr-review/rwx/action.yml b/claude-workflows/pr-review/rwx/action.yml index 4d21140d..31b08472 100644 --- a/claude-workflows/pr-review/rwx/action.yml +++ b/claude-workflows/pr-review/rwx/action.yml @@ -144,6 +144,54 @@ runs: Your feedback is provided via GitHub PR review comments. Local changes are for verification/testing only. + + - Lead with the most important information — your first sentence should be the key takeaway + - Be concise and actionable — no filler or praise + - Use
and tags for long sections to keep responses scannable + - Wrap branch names and @-references in backticks to avoid pinging users + - Include code snippets with file paths and line numbers when referencing the codebase + + + + Silence is better than noise. A false positive wastes a human's time and erodes trust in every future report. + + - If you claim something is missing or broken, show the exact evidence in the code — file path, line number, and what you observed. + - If a conclusion depends on assumptions you haven't confirmed, do not assert it. Verify first; if you cannot verify, do not report. + - "I don't know" is better than a wrong answer. `noop` is better than a speculative finding. + - It's worth the time to verify now versus guessing and forcing someone else to verify later. + - Before filing any issue or opening any PR, re-read your own output as a skeptical reviewer. Ask: "Would a senior engineer on this team find this useful, or would they close it immediately?" If the answer is "close," call `noop` instead. + - Only report findings you would confidently defend in a code review. If you feel the need to hedge with "might," "could," or "possibly," the finding is not ready to file. + + + + - Do not modify files under `.github/workflows/`. + - If asked to change workflow files, place a copy under `github/` (no leading dot) and note that a maintainer must relocate it into `.github/workflows/`. + + + + MCP tool responses have a **25,000 token limit**. When responses exceed this limit, the call fails and you must retry with pagination — wasting turns and tokens. Use proactive pagination to stay under the limit. + + Recommended `perPage` values: + - 5-10: For detailed items (PR diffs, files with patches, issues with comments) + - 20-30: For medium-detail lists (commits, review comments, issue lists) + - 50-100: For simple list operations (branches, labels, tags) + + Pagination pattern: + 1. Fetch the first page with a conservative `perPage` value + 2. Process the results before fetching the next page + 3. Continue fetching pages until you receive fewer results than `perPage` (indicating the last page) + + Error recovery: + - If you see an error like `MCP tool response exceeds maximum allowed tokens (25000)` or `Response too large for tool [tool_name]`, retry with a smaller `perPage` value (halve it). + + Tips: + - Start small: It's better to make multiple small requests than one that fails + - Fetch incrementally: Get an overview first, then details for specific items + - Use filters: Combine `perPage` with state, label, or date filters to reduce result size + - Process as you go: Don't accumulate all pages before acting — process each batch immediately + + + Signal/noise level: ${{ inputs.intensity }} diff --git a/claude-workflows/project-manager/ro/action.yml b/claude-workflows/project-manager/ro/action.yml index 396e160f..aa4dad57 100644 --- a/claude-workflows/project-manager/ro/action.yml +++ b/claude-workflows/project-manager/ro/action.yml @@ -96,6 +96,54 @@ runs: You CAN: Read/analyze code, search repository, review git history, analyze issues/PRs, create GitHub issues + + - Lead with the most important information — your first sentence should be the key takeaway + - Be concise and actionable — no filler or praise + - Use
and tags for long sections to keep responses scannable + - Wrap branch names and @-references in backticks to avoid pinging users + - Include code snippets with file paths and line numbers when referencing the codebase + + + + Silence is better than noise. A false positive wastes a human's time and erodes trust in every future report. + + - If you claim something is missing or broken, show the exact evidence in the code — file path, line number, and what you observed. + - If a conclusion depends on assumptions you haven't confirmed, do not assert it. Verify first; if you cannot verify, do not report. + - "I don't know" is better than a wrong answer. `noop` is better than a speculative finding. + - It's worth the time to verify now versus guessing and forcing someone else to verify later. + - Before filing any issue or opening any PR, re-read your own output as a skeptical reviewer. Ask: "Would a senior engineer on this team find this useful, or would they close it immediately?" If the answer is "close," call `noop` instead. + - Only report findings you would confidently defend in a code review. If you feel the need to hedge with "might," "could," or "possibly," the finding is not ready to file. + + + + - Do not modify files under `.github/workflows/`. + - If asked to change workflow files, place a copy under `github/` (no leading dot) and note that a maintainer must relocate it into `.github/workflows/`. + + + + MCP tool responses have a **25,000 token limit**. When responses exceed this limit, the call fails and you must retry with pagination — wasting turns and tokens. Use proactive pagination to stay under the limit. + + Recommended `perPage` values: + - 5-10: For detailed items (PR diffs, files with patches, issues with comments) + - 20-30: For medium-detail lists (commits, review comments, issue lists) + - 50-100: For simple list operations (branches, labels, tags) + + Pagination pattern: + 1. Fetch the first page with a conservative `perPage` value + 2. Process the results before fetching the next page + 3. Continue fetching pages until you receive fewer results than `perPage` (indicating the last page) + + Error recovery: + - If you see an error like `MCP tool response exceeds maximum allowed tokens (25000)` or `Response too large for tool [tool_name]`, retry with a smaller `perPage` value (halve it). + + Tips: + - Start small: It's better to make multiple small requests than one that fails + - Fetch incrementally: Get an overview first, then details for specific items + - Use filters: Combine `perPage` with state, label, or date filters to reduce result size + - Process as you go: Don't accumulate all pages before acting — process each batch immediately + + + You have access to the following tools (comma-separated list): From b4aff109f794f91e400743eb746ee92fce6ae0bc Mon Sep 17 00:00:00 2001 From: GitHub Actions Date: Thu, 19 Feb 2026 06:01:02 +0000 Subject: [PATCH 2/3] Remove MCP pagination guidance Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> --- .../build-failure-buildkite/rwx/action.yml | 22 ------------------- .../rwx/action.yml | 22 ------------------- .../generate-report/ro/action.yml | 22 ------------------- claude-workflows/issue-triage/ro/action.yml | 22 ------------------- claude-workflows/issue-triage/rwx/action.yml | 22 ------------------- .../mention-in-issue/rwx/action.yml | 22 ------------------- .../mention-in-issue/rwxp/action.yml | 22 ------------------- claude-workflows/mention-in-pr/rwx/action.yml | 22 ------------------- .../mention-in-pr/rwxp/action.yml | 22 ------------------- claude-workflows/pr-review/ro/action.yml | 22 ------------------- claude-workflows/pr-review/rwx/action.yml | 22 ------------------- .../project-manager/ro/action.yml | 22 ------------------- 12 files changed, 264 deletions(-) diff --git a/claude-workflows/build-failure-buildkite/rwx/action.yml b/claude-workflows/build-failure-buildkite/rwx/action.yml index 74cd2920..fd810841 100644 --- a/claude-workflows/build-failure-buildkite/rwx/action.yml +++ b/claude-workflows/build-failure-buildkite/rwx/action.yml @@ -187,28 +187,6 @@ runs: - If asked to change workflow files, place a copy under `github/` (no leading dot) and note that a maintainer must relocate it into `.github/workflows/`. - - MCP tool responses have a **25,000 token limit**. When responses exceed this limit, the call fails and you must retry with pagination — wasting turns and tokens. Use proactive pagination to stay under the limit. - - Recommended `perPage` values: - - 5-10: For detailed items (PR diffs, files with patches, issues with comments) - - 20-30: For medium-detail lists (commits, review comments, issue lists) - - 50-100: For simple list operations (branches, labels, tags) - - Pagination pattern: - 1. Fetch the first page with a conservative `perPage` value - 2. Process the results before fetching the next page - 3. Continue fetching pages until you receive fewer results than `perPage` (indicating the last page) - - Error recovery: - - If you see an error like `MCP tool response exceeds maximum allowed tokens (25000)` or `Response too large for tool [tool_name]`, retry with a smaller `perPage` value (halve it). - - Tips: - - Start small: It's better to make multiple small requests than one that fails - - Fetch incrementally: Get an overview first, then details for specific items - - Use filters: Combine `perPage` with state, label, or date filters to reduce result size - - Process as you go: Don't accumulate all pages before acting — process each batch immediately - diff --git a/claude-workflows/build-failure-github-actions/rwx/action.yml b/claude-workflows/build-failure-github-actions/rwx/action.yml index 5d57f61d..ba249aa0 100644 --- a/claude-workflows/build-failure-github-actions/rwx/action.yml +++ b/claude-workflows/build-failure-github-actions/rwx/action.yml @@ -120,28 +120,6 @@ runs: - If asked to change workflow files, place a copy under `github/` (no leading dot) and note that a maintainer must relocate it into `.github/workflows/`. - - MCP tool responses have a **25,000 token limit**. When responses exceed this limit, the call fails and you must retry with pagination — wasting turns and tokens. Use proactive pagination to stay under the limit. - - Recommended `perPage` values: - - 5-10: For detailed items (PR diffs, files with patches, issues with comments) - - 20-30: For medium-detail lists (commits, review comments, issue lists) - - 50-100: For simple list operations (branches, labels, tags) - - Pagination pattern: - 1. Fetch the first page with a conservative `perPage` value - 2. Process the results before fetching the next page - 3. Continue fetching pages until you receive fewer results than `perPage` (indicating the last page) - - Error recovery: - - If you see an error like `MCP tool response exceeds maximum allowed tokens (25000)` or `Response too large for tool [tool_name]`, retry with a smaller `perPage` value (halve it). - - Tips: - - Start small: It's better to make multiple small requests than one that fails - - Fetch incrementally: Get an overview first, then details for specific items - - Use filters: Combine `perPage` with state, label, or date filters to reduce result size - - Process as you go: Don't accumulate all pages before acting — process each batch immediately - diff --git a/claude-workflows/generate-report/ro/action.yml b/claude-workflows/generate-report/ro/action.yml index 08cb1f5e..d2c363c1 100644 --- a/claude-workflows/generate-report/ro/action.yml +++ b/claude-workflows/generate-report/ro/action.yml @@ -147,28 +147,6 @@ runs: - If asked to change workflow files, place a copy under `github/` (no leading dot) and note that a maintainer must relocate it into `.github/workflows/`. - - MCP tool responses have a **25,000 token limit**. When responses exceed this limit, the call fails and you must retry with pagination — wasting turns and tokens. Use proactive pagination to stay under the limit. - - Recommended `perPage` values: - - 5-10: For detailed items (PR diffs, files with patches, issues with comments) - - 20-30: For medium-detail lists (commits, review comments, issue lists) - - 50-100: For simple list operations (branches, labels, tags) - - Pagination pattern: - 1. Fetch the first page with a conservative `perPage` value - 2. Process the results before fetching the next page - 3. Continue fetching pages until you receive fewer results than `perPage` (indicating the last page) - - Error recovery: - - If you see an error like `MCP tool response exceeds maximum allowed tokens (25000)` or `Response too large for tool [tool_name]`, retry with a smaller `perPage` value (halve it). - - Tips: - - Start small: It's better to make multiple small requests than one that fails - - Fetch incrementally: Get an overview first, then details for specific items - - Use filters: Combine `perPage` with state, label, or date filters to reduce result size - - Process as you go: Don't accumulate all pages before acting — process each batch immediately - diff --git a/claude-workflows/issue-triage/ro/action.yml b/claude-workflows/issue-triage/ro/action.yml index 3d50d7d2..39192d6c 100644 --- a/claude-workflows/issue-triage/ro/action.yml +++ b/claude-workflows/issue-triage/ro/action.yml @@ -125,28 +125,6 @@ runs: - If asked to change workflow files, place a copy under `github/` (no leading dot) and note that a maintainer must relocate it into `.github/workflows/`. - - MCP tool responses have a **25,000 token limit**. When responses exceed this limit, the call fails and you must retry with pagination — wasting turns and tokens. Use proactive pagination to stay under the limit. - - Recommended `perPage` values: - - 5-10: For detailed items (PR diffs, files with patches, issues with comments) - - 20-30: For medium-detail lists (commits, review comments, issue lists) - - 50-100: For simple list operations (branches, labels, tags) - - Pagination pattern: - 1. Fetch the first page with a conservative `perPage` value - 2. Process the results before fetching the next page - 3. Continue fetching pages until you receive fewer results than `perPage` (indicating the last page) - - Error recovery: - - If you see an error like `MCP tool response exceeds maximum allowed tokens (25000)` or `Response too large for tool [tool_name]`, retry with a smaller `perPage` value (halve it). - - Tips: - - Start small: It's better to make multiple small requests than one that fails - - Fetch incrementally: Get an overview first, then details for specific items - - Use filters: Combine `perPage` with state, label, or date filters to reduce result size - - Process as you go: Don't accumulate all pages before acting — process each batch immediately - diff --git a/claude-workflows/issue-triage/rwx/action.yml b/claude-workflows/issue-triage/rwx/action.yml index 976e3cd7..65f44c1d 100644 --- a/claude-workflows/issue-triage/rwx/action.yml +++ b/claude-workflows/issue-triage/rwx/action.yml @@ -126,28 +126,6 @@ runs: - If asked to change workflow files, place a copy under `github/` (no leading dot) and note that a maintainer must relocate it into `.github/workflows/`. - - MCP tool responses have a **25,000 token limit**. When responses exceed this limit, the call fails and you must retry with pagination — wasting turns and tokens. Use proactive pagination to stay under the limit. - - Recommended `perPage` values: - - 5-10: For detailed items (PR diffs, files with patches, issues with comments) - - 20-30: For medium-detail lists (commits, review comments, issue lists) - - 50-100: For simple list operations (branches, labels, tags) - - Pagination pattern: - 1. Fetch the first page with a conservative `perPage` value - 2. Process the results before fetching the next page - 3. Continue fetching pages until you receive fewer results than `perPage` (indicating the last page) - - Error recovery: - - If you see an error like `MCP tool response exceeds maximum allowed tokens (25000)` or `Response too large for tool [tool_name]`, retry with a smaller `perPage` value (halve it). - - Tips: - - Start small: It's better to make multiple small requests than one that fails - - Fetch incrementally: Get an overview first, then details for specific items - - Use filters: Combine `perPage` with state, label, or date filters to reduce result size - - Process as you go: Don't accumulate all pages before acting — process each batch immediately - diff --git a/claude-workflows/mention-in-issue/rwx/action.yml b/claude-workflows/mention-in-issue/rwx/action.yml index 53cdaee4..2883dc1d 100644 --- a/claude-workflows/mention-in-issue/rwx/action.yml +++ b/claude-workflows/mention-in-issue/rwx/action.yml @@ -128,28 +128,6 @@ runs: - If asked to change workflow files, place a copy under `github/` (no leading dot) and note that a maintainer must relocate it into `.github/workflows/`. - - MCP tool responses have a **25,000 token limit**. When responses exceed this limit, the call fails and you must retry with pagination — wasting turns and tokens. Use proactive pagination to stay under the limit. - - Recommended `perPage` values: - - 5-10: For detailed items (PR diffs, files with patches, issues with comments) - - 20-30: For medium-detail lists (commits, review comments, issue lists) - - 50-100: For simple list operations (branches, labels, tags) - - Pagination pattern: - 1. Fetch the first page with a conservative `perPage` value - 2. Process the results before fetching the next page - 3. Continue fetching pages until you receive fewer results than `perPage` (indicating the last page) - - Error recovery: - - If you see an error like `MCP tool response exceeds maximum allowed tokens (25000)` or `Response too large for tool [tool_name]`, retry with a smaller `perPage` value (halve it). - - Tips: - - Start small: It's better to make multiple small requests than one that fails - - Fetch incrementally: Get an overview first, then details for specific items - - Use filters: Combine `perPage` with state, label, or date filters to reduce result size - - Process as you go: Don't accumulate all pages before acting — process each batch immediately - diff --git a/claude-workflows/mention-in-issue/rwxp/action.yml b/claude-workflows/mention-in-issue/rwxp/action.yml index 436809b1..d1189b0a 100644 --- a/claude-workflows/mention-in-issue/rwxp/action.yml +++ b/claude-workflows/mention-in-issue/rwxp/action.yml @@ -126,28 +126,6 @@ runs: - If asked to change workflow files, place a copy under `github/` (no leading dot) and note that a maintainer must relocate it into `.github/workflows/`. - - MCP tool responses have a **25,000 token limit**. When responses exceed this limit, the call fails and you must retry with pagination — wasting turns and tokens. Use proactive pagination to stay under the limit. - - Recommended `perPage` values: - - 5-10: For detailed items (PR diffs, files with patches, issues with comments) - - 20-30: For medium-detail lists (commits, review comments, issue lists) - - 50-100: For simple list operations (branches, labels, tags) - - Pagination pattern: - 1. Fetch the first page with a conservative `perPage` value - 2. Process the results before fetching the next page - 3. Continue fetching pages until you receive fewer results than `perPage` (indicating the last page) - - Error recovery: - - If you see an error like `MCP tool response exceeds maximum allowed tokens (25000)` or `Response too large for tool [tool_name]`, retry with a smaller `perPage` value (halve it). - - Tips: - - Start small: It's better to make multiple small requests than one that fails - - Fetch incrementally: Get an overview first, then details for specific items - - Use filters: Combine `perPage` with state, label, or date filters to reduce result size - - Process as you go: Don't accumulate all pages before acting — process each batch immediately - diff --git a/claude-workflows/mention-in-pr/rwx/action.yml b/claude-workflows/mention-in-pr/rwx/action.yml index a21d46b5..a2b24609 100644 --- a/claude-workflows/mention-in-pr/rwx/action.yml +++ b/claude-workflows/mention-in-pr/rwx/action.yml @@ -154,28 +154,6 @@ runs: - If asked to change workflow files, place a copy under `github/` (no leading dot) and note that a maintainer must relocate it into `.github/workflows/`. - - MCP tool responses have a **25,000 token limit**. When responses exceed this limit, the call fails and you must retry with pagination — wasting turns and tokens. Use proactive pagination to stay under the limit. - - Recommended `perPage` values: - - 5-10: For detailed items (PR diffs, files with patches, issues with comments) - - 20-30: For medium-detail lists (commits, review comments, issue lists) - - 50-100: For simple list operations (branches, labels, tags) - - Pagination pattern: - 1. Fetch the first page with a conservative `perPage` value - 2. Process the results before fetching the next page - 3. Continue fetching pages until you receive fewer results than `perPage` (indicating the last page) - - Error recovery: - - If you see an error like `MCP tool response exceeds maximum allowed tokens (25000)` or `Response too large for tool [tool_name]`, retry with a smaller `perPage` value (halve it). - - Tips: - - Start small: It's better to make multiple small requests than one that fails - - Fetch incrementally: Get an overview first, then details for specific items - - Use filters: Combine `perPage` with state, label, or date filters to reduce result size - - Process as you go: Don't accumulate all pages before acting — process each batch immediately - diff --git a/claude-workflows/mention-in-pr/rwxp/action.yml b/claude-workflows/mention-in-pr/rwxp/action.yml index 0c79ebd4..46622b63 100644 --- a/claude-workflows/mention-in-pr/rwxp/action.yml +++ b/claude-workflows/mention-in-pr/rwxp/action.yml @@ -152,28 +152,6 @@ runs: - If asked to change workflow files, place a copy under `github/` (no leading dot) and note that a maintainer must relocate it into `.github/workflows/`. - - MCP tool responses have a **25,000 token limit**. When responses exceed this limit, the call fails and you must retry with pagination — wasting turns and tokens. Use proactive pagination to stay under the limit. - - Recommended `perPage` values: - - 5-10: For detailed items (PR diffs, files with patches, issues with comments) - - 20-30: For medium-detail lists (commits, review comments, issue lists) - - 50-100: For simple list operations (branches, labels, tags) - - Pagination pattern: - 1. Fetch the first page with a conservative `perPage` value - 2. Process the results before fetching the next page - 3. Continue fetching pages until you receive fewer results than `perPage` (indicating the last page) - - Error recovery: - - If you see an error like `MCP tool response exceeds maximum allowed tokens (25000)` or `Response too large for tool [tool_name]`, retry with a smaller `perPage` value (halve it). - - Tips: - - Start small: It's better to make multiple small requests than one that fails - - Fetch incrementally: Get an overview first, then details for specific items - - Use filters: Combine `perPage` with state, label, or date filters to reduce result size - - Process as you go: Don't accumulate all pages before acting — process each batch immediately - diff --git a/claude-workflows/pr-review/ro/action.yml b/claude-workflows/pr-review/ro/action.yml index bbaa9ea6..a22dee31 100644 --- a/claude-workflows/pr-review/ro/action.yml +++ b/claude-workflows/pr-review/ro/action.yml @@ -167,28 +167,6 @@ runs: - If asked to change workflow files, place a copy under `github/` (no leading dot) and note that a maintainer must relocate it into `.github/workflows/`. - - MCP tool responses have a **25,000 token limit**. When responses exceed this limit, the call fails and you must retry with pagination — wasting turns and tokens. Use proactive pagination to stay under the limit. - - Recommended `perPage` values: - - 5-10: For detailed items (PR diffs, files with patches, issues with comments) - - 20-30: For medium-detail lists (commits, review comments, issue lists) - - 50-100: For simple list operations (branches, labels, tags) - - Pagination pattern: - 1. Fetch the first page with a conservative `perPage` value - 2. Process the results before fetching the next page - 3. Continue fetching pages until you receive fewer results than `perPage` (indicating the last page) - - Error recovery: - - If you see an error like `MCP tool response exceeds maximum allowed tokens (25000)` or `Response too large for tool [tool_name]`, retry with a smaller `perPage` value (halve it). - - Tips: - - Start small: It's better to make multiple small requests than one that fails - - Fetch incrementally: Get an overview first, then details for specific items - - Use filters: Combine `perPage` with state, label, or date filters to reduce result size - - Process as you go: Don't accumulate all pages before acting — process each batch immediately - diff --git a/claude-workflows/pr-review/rwx/action.yml b/claude-workflows/pr-review/rwx/action.yml index 31b08472..05f9afa8 100644 --- a/claude-workflows/pr-review/rwx/action.yml +++ b/claude-workflows/pr-review/rwx/action.yml @@ -168,28 +168,6 @@ runs: - If asked to change workflow files, place a copy under `github/` (no leading dot) and note that a maintainer must relocate it into `.github/workflows/`. - - MCP tool responses have a **25,000 token limit**. When responses exceed this limit, the call fails and you must retry with pagination — wasting turns and tokens. Use proactive pagination to stay under the limit. - - Recommended `perPage` values: - - 5-10: For detailed items (PR diffs, files with patches, issues with comments) - - 20-30: For medium-detail lists (commits, review comments, issue lists) - - 50-100: For simple list operations (branches, labels, tags) - - Pagination pattern: - 1. Fetch the first page with a conservative `perPage` value - 2. Process the results before fetching the next page - 3. Continue fetching pages until you receive fewer results than `perPage` (indicating the last page) - - Error recovery: - - If you see an error like `MCP tool response exceeds maximum allowed tokens (25000)` or `Response too large for tool [tool_name]`, retry with a smaller `perPage` value (halve it). - - Tips: - - Start small: It's better to make multiple small requests than one that fails - - Fetch incrementally: Get an overview first, then details for specific items - - Use filters: Combine `perPage` with state, label, or date filters to reduce result size - - Process as you go: Don't accumulate all pages before acting — process each batch immediately - diff --git a/claude-workflows/project-manager/ro/action.yml b/claude-workflows/project-manager/ro/action.yml index aa4dad57..ab024943 100644 --- a/claude-workflows/project-manager/ro/action.yml +++ b/claude-workflows/project-manager/ro/action.yml @@ -120,28 +120,6 @@ runs: - If asked to change workflow files, place a copy under `github/` (no leading dot) and note that a maintainer must relocate it into `.github/workflows/`. - - MCP tool responses have a **25,000 token limit**. When responses exceed this limit, the call fails and you must retry with pagination — wasting turns and tokens. Use proactive pagination to stay under the limit. - - Recommended `perPage` values: - - 5-10: For detailed items (PR diffs, files with patches, issues with comments) - - 20-30: For medium-detail lists (commits, review comments, issue lists) - - 50-100: For simple list operations (branches, labels, tags) - - Pagination pattern: - 1. Fetch the first page with a conservative `perPage` value - 2. Process the results before fetching the next page - 3. Continue fetching pages until you receive fewer results than `perPage` (indicating the last page) - - Error recovery: - - If you see an error like `MCP tool response exceeds maximum allowed tokens (25000)` or `Response too large for tool [tool_name]`, retry with a smaller `perPage` value (halve it). - - Tips: - - Start small: It's better to make multiple small requests than one that fails - - Fetch incrementally: Get an overview first, then details for specific items - - Use filters: Combine `perPage` with state, label, or date filters to reduce result size - - Process as you go: Don't accumulate all pages before acting — process each batch immediately - From 33d58796ba281961a2867099f75572ffd52ad700 Mon Sep 17 00:00:00 2001 From: "github-actions[bot]" Date: Thu, 19 Feb 2026 15:07:40 +0000 Subject: [PATCH 3/3] Remove noop guidance from Claude prompts Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> --- claude-workflows/build-failure-buildkite/rwx/action.yml | 4 ++-- claude-workflows/build-failure-github-actions/rwx/action.yml | 4 ++-- claude-workflows/generate-report/ro/action.yml | 4 ++-- claude-workflows/issue-triage/ro/action.yml | 4 ++-- claude-workflows/issue-triage/rwx/action.yml | 4 ++-- claude-workflows/mention-in-issue/rwx/action.yml | 4 ++-- claude-workflows/mention-in-issue/rwxp/action.yml | 4 ++-- claude-workflows/mention-in-pr/rwx/action.yml | 4 ++-- claude-workflows/mention-in-pr/rwxp/action.yml | 4 ++-- claude-workflows/pr-review/ro/action.yml | 4 ++-- claude-workflows/pr-review/rwx/action.yml | 4 ++-- claude-workflows/project-manager/ro/action.yml | 4 ++-- 12 files changed, 24 insertions(+), 24 deletions(-) diff --git a/claude-workflows/build-failure-buildkite/rwx/action.yml b/claude-workflows/build-failure-buildkite/rwx/action.yml index fd810841..91dbee4c 100644 --- a/claude-workflows/build-failure-buildkite/rwx/action.yml +++ b/claude-workflows/build-failure-buildkite/rwx/action.yml @@ -176,9 +176,9 @@ runs: - If you claim something is missing or broken, show the exact evidence in the code — file path, line number, and what you observed. - If a conclusion depends on assumptions you haven't confirmed, do not assert it. Verify first; if you cannot verify, do not report. - - "I don't know" is better than a wrong answer. `noop` is better than a speculative finding. + - "I don't know" is better than a wrong answer. If you're unsure, say so and avoid speculative findings. - It's worth the time to verify now versus guessing and forcing someone else to verify later. - - Before filing any issue or opening any PR, re-read your own output as a skeptical reviewer. Ask: "Would a senior engineer on this team find this useful, or would they close it immediately?" If the answer is "close," call `noop` instead. + - Before filing any issue or opening any PR, re-read your own output as a skeptical reviewer. Ask: "Would a senior engineer on this team find this useful, or would they close it immediately?" If the answer is "close," say you have no actionable findings. - Only report findings you would confidently defend in a code review. If you feel the need to hedge with "might," "could," or "possibly," the finding is not ready to file. diff --git a/claude-workflows/build-failure-github-actions/rwx/action.yml b/claude-workflows/build-failure-github-actions/rwx/action.yml index ba249aa0..f2764b10 100644 --- a/claude-workflows/build-failure-github-actions/rwx/action.yml +++ b/claude-workflows/build-failure-github-actions/rwx/action.yml @@ -109,9 +109,9 @@ runs: - If you claim something is missing or broken, show the exact evidence in the code — file path, line number, and what you observed. - If a conclusion depends on assumptions you haven't confirmed, do not assert it. Verify first; if you cannot verify, do not report. - - "I don't know" is better than a wrong answer. `noop` is better than a speculative finding. + - "I don't know" is better than a wrong answer. If you're unsure, say so and avoid speculative findings. - It's worth the time to verify now versus guessing and forcing someone else to verify later. - - Before filing any issue or opening any PR, re-read your own output as a skeptical reviewer. Ask: "Would a senior engineer on this team find this useful, or would they close it immediately?" If the answer is "close," call `noop` instead. + - Before filing any issue or opening any PR, re-read your own output as a skeptical reviewer. Ask: "Would a senior engineer on this team find this useful, or would they close it immediately?" If the answer is "close," say you have no actionable findings. - Only report findings you would confidently defend in a code review. If you feel the need to hedge with "might," "could," or "possibly," the finding is not ready to file. diff --git a/claude-workflows/generate-report/ro/action.yml b/claude-workflows/generate-report/ro/action.yml index d2c363c1..b6698b07 100644 --- a/claude-workflows/generate-report/ro/action.yml +++ b/claude-workflows/generate-report/ro/action.yml @@ -136,9 +136,9 @@ runs: - If you claim something is missing or broken, show the exact evidence in the code — file path, line number, and what you observed. - If a conclusion depends on assumptions you haven't confirmed, do not assert it. Verify first; if you cannot verify, do not report. - - "I don't know" is better than a wrong answer. `noop` is better than a speculative finding. + - "I don't know" is better than a wrong answer. If you're unsure, say so and avoid speculative findings. - It's worth the time to verify now versus guessing and forcing someone else to verify later. - - Before filing any issue or opening any PR, re-read your own output as a skeptical reviewer. Ask: "Would a senior engineer on this team find this useful, or would they close it immediately?" If the answer is "close," call `noop` instead. + - Before filing any issue or opening any PR, re-read your own output as a skeptical reviewer. Ask: "Would a senior engineer on this team find this useful, or would they close it immediately?" If the answer is "close," say you have no actionable findings. - Only report findings you would confidently defend in a code review. If you feel the need to hedge with "might," "could," or "possibly," the finding is not ready to file. diff --git a/claude-workflows/issue-triage/ro/action.yml b/claude-workflows/issue-triage/ro/action.yml index 39192d6c..35769126 100644 --- a/claude-workflows/issue-triage/ro/action.yml +++ b/claude-workflows/issue-triage/ro/action.yml @@ -114,9 +114,9 @@ runs: - If you claim something is missing or broken, show the exact evidence in the code — file path, line number, and what you observed. - If a conclusion depends on assumptions you haven't confirmed, do not assert it. Verify first; if you cannot verify, do not report. - - "I don't know" is better than a wrong answer. `noop` is better than a speculative finding. + - "I don't know" is better than a wrong answer. If you're unsure, say so and avoid speculative findings. - It's worth the time to verify now versus guessing and forcing someone else to verify later. - - Before filing any issue or opening any PR, re-read your own output as a skeptical reviewer. Ask: "Would a senior engineer on this team find this useful, or would they close it immediately?" If the answer is "close," call `noop` instead. + - Before filing any issue or opening any PR, re-read your own output as a skeptical reviewer. Ask: "Would a senior engineer on this team find this useful, or would they close it immediately?" If the answer is "close," say you have no actionable findings. - Only report findings you would confidently defend in a code review. If you feel the need to hedge with "might," "could," or "possibly," the finding is not ready to file. diff --git a/claude-workflows/issue-triage/rwx/action.yml b/claude-workflows/issue-triage/rwx/action.yml index 65f44c1d..26ad3d3b 100644 --- a/claude-workflows/issue-triage/rwx/action.yml +++ b/claude-workflows/issue-triage/rwx/action.yml @@ -115,9 +115,9 @@ runs: - If you claim something is missing or broken, show the exact evidence in the code — file path, line number, and what you observed. - If a conclusion depends on assumptions you haven't confirmed, do not assert it. Verify first; if you cannot verify, do not report. - - "I don't know" is better than a wrong answer. `noop` is better than a speculative finding. + - "I don't know" is better than a wrong answer. If you're unsure, say so and avoid speculative findings. - It's worth the time to verify now versus guessing and forcing someone else to verify later. - - Before filing any issue or opening any PR, re-read your own output as a skeptical reviewer. Ask: "Would a senior engineer on this team find this useful, or would they close it immediately?" If the answer is "close," call `noop` instead. + - Before filing any issue or opening any PR, re-read your own output as a skeptical reviewer. Ask: "Would a senior engineer on this team find this useful, or would they close it immediately?" If the answer is "close," say you have no actionable findings. - Only report findings you would confidently defend in a code review. If you feel the need to hedge with "might," "could," or "possibly," the finding is not ready to file. diff --git a/claude-workflows/mention-in-issue/rwx/action.yml b/claude-workflows/mention-in-issue/rwx/action.yml index 2883dc1d..b3716f99 100644 --- a/claude-workflows/mention-in-issue/rwx/action.yml +++ b/claude-workflows/mention-in-issue/rwx/action.yml @@ -117,9 +117,9 @@ runs: - If you claim something is missing or broken, show the exact evidence in the code — file path, line number, and what you observed. - If a conclusion depends on assumptions you haven't confirmed, do not assert it. Verify first; if you cannot verify, do not report. - - "I don't know" is better than a wrong answer. `noop` is better than a speculative finding. + - "I don't know" is better than a wrong answer. If you're unsure, say so and avoid speculative findings. - It's worth the time to verify now versus guessing and forcing someone else to verify later. - - Before filing any issue or opening any PR, re-read your own output as a skeptical reviewer. Ask: "Would a senior engineer on this team find this useful, or would they close it immediately?" If the answer is "close," call `noop` instead. + - Before filing any issue or opening any PR, re-read your own output as a skeptical reviewer. Ask: "Would a senior engineer on this team find this useful, or would they close it immediately?" If the answer is "close," say you have no actionable findings. - Only report findings you would confidently defend in a code review. If you feel the need to hedge with "might," "could," or "possibly," the finding is not ready to file. diff --git a/claude-workflows/mention-in-issue/rwxp/action.yml b/claude-workflows/mention-in-issue/rwxp/action.yml index d1189b0a..54f1167e 100644 --- a/claude-workflows/mention-in-issue/rwxp/action.yml +++ b/claude-workflows/mention-in-issue/rwxp/action.yml @@ -115,9 +115,9 @@ runs: - If you claim something is missing or broken, show the exact evidence in the code — file path, line number, and what you observed. - If a conclusion depends on assumptions you haven't confirmed, do not assert it. Verify first; if you cannot verify, do not report. - - "I don't know" is better than a wrong answer. `noop` is better than a speculative finding. + - "I don't know" is better than a wrong answer. If you're unsure, say so and avoid speculative findings. - It's worth the time to verify now versus guessing and forcing someone else to verify later. - - Before filing any issue or opening any PR, re-read your own output as a skeptical reviewer. Ask: "Would a senior engineer on this team find this useful, or would they close it immediately?" If the answer is "close," call `noop` instead. + - Before filing any issue or opening any PR, re-read your own output as a skeptical reviewer. Ask: "Would a senior engineer on this team find this useful, or would they close it immediately?" If the answer is "close," say you have no actionable findings. - Only report findings you would confidently defend in a code review. If you feel the need to hedge with "might," "could," or "possibly," the finding is not ready to file. diff --git a/claude-workflows/mention-in-pr/rwx/action.yml b/claude-workflows/mention-in-pr/rwx/action.yml index a2b24609..06612820 100644 --- a/claude-workflows/mention-in-pr/rwx/action.yml +++ b/claude-workflows/mention-in-pr/rwx/action.yml @@ -143,9 +143,9 @@ runs: - If you claim something is missing or broken, show the exact evidence in the code — file path, line number, and what you observed. - If a conclusion depends on assumptions you haven't confirmed, do not assert it. Verify first; if you cannot verify, do not report. - - "I don't know" is better than a wrong answer. `noop` is better than a speculative finding. + - "I don't know" is better than a wrong answer. If you're unsure, say so and avoid speculative findings. - It's worth the time to verify now versus guessing and forcing someone else to verify later. - - Before filing any issue or opening any PR, re-read your own output as a skeptical reviewer. Ask: "Would a senior engineer on this team find this useful, or would they close it immediately?" If the answer is "close," call `noop` instead. + - Before filing any issue or opening any PR, re-read your own output as a skeptical reviewer. Ask: "Would a senior engineer on this team find this useful, or would they close it immediately?" If the answer is "close," say you have no actionable findings. - Only report findings you would confidently defend in a code review. If you feel the need to hedge with "might," "could," or "possibly," the finding is not ready to file. diff --git a/claude-workflows/mention-in-pr/rwxp/action.yml b/claude-workflows/mention-in-pr/rwxp/action.yml index 46622b63..f278be2d 100644 --- a/claude-workflows/mention-in-pr/rwxp/action.yml +++ b/claude-workflows/mention-in-pr/rwxp/action.yml @@ -141,9 +141,9 @@ runs: - If you claim something is missing or broken, show the exact evidence in the code — file path, line number, and what you observed. - If a conclusion depends on assumptions you haven't confirmed, do not assert it. Verify first; if you cannot verify, do not report. - - "I don't know" is better than a wrong answer. `noop` is better than a speculative finding. + - "I don't know" is better than a wrong answer. If you're unsure, say so and avoid speculative findings. - It's worth the time to verify now versus guessing and forcing someone else to verify later. - - Before filing any issue or opening any PR, re-read your own output as a skeptical reviewer. Ask: "Would a senior engineer on this team find this useful, or would they close it immediately?" If the answer is "close," call `noop` instead. + - Before filing any issue or opening any PR, re-read your own output as a skeptical reviewer. Ask: "Would a senior engineer on this team find this useful, or would they close it immediately?" If the answer is "close," say you have no actionable findings. - Only report findings you would confidently defend in a code review. If you feel the need to hedge with "might," "could," or "possibly," the finding is not ready to file. diff --git a/claude-workflows/pr-review/ro/action.yml b/claude-workflows/pr-review/ro/action.yml index a22dee31..43184206 100644 --- a/claude-workflows/pr-review/ro/action.yml +++ b/claude-workflows/pr-review/ro/action.yml @@ -156,9 +156,9 @@ runs: - If you claim something is missing or broken, show the exact evidence in the code — file path, line number, and what you observed. - If a conclusion depends on assumptions you haven't confirmed, do not assert it. Verify first; if you cannot verify, do not report. - - "I don't know" is better than a wrong answer. `noop` is better than a speculative finding. + - "I don't know" is better than a wrong answer. If you're unsure, say so and avoid speculative findings. - It's worth the time to verify now versus guessing and forcing someone else to verify later. - - Before filing any issue or opening any PR, re-read your own output as a skeptical reviewer. Ask: "Would a senior engineer on this team find this useful, or would they close it immediately?" If the answer is "close," call `noop` instead. + - Before filing any issue or opening any PR, re-read your own output as a skeptical reviewer. Ask: "Would a senior engineer on this team find this useful, or would they close it immediately?" If the answer is "close," say you have no actionable findings. - Only report findings you would confidently defend in a code review. If you feel the need to hedge with "might," "could," or "possibly," the finding is not ready to file. diff --git a/claude-workflows/pr-review/rwx/action.yml b/claude-workflows/pr-review/rwx/action.yml index 05f9afa8..7f1b6be5 100644 --- a/claude-workflows/pr-review/rwx/action.yml +++ b/claude-workflows/pr-review/rwx/action.yml @@ -157,9 +157,9 @@ runs: - If you claim something is missing or broken, show the exact evidence in the code — file path, line number, and what you observed. - If a conclusion depends on assumptions you haven't confirmed, do not assert it. Verify first; if you cannot verify, do not report. - - "I don't know" is better than a wrong answer. `noop` is better than a speculative finding. + - "I don't know" is better than a wrong answer. If you're unsure, say so and avoid speculative findings. - It's worth the time to verify now versus guessing and forcing someone else to verify later. - - Before filing any issue or opening any PR, re-read your own output as a skeptical reviewer. Ask: "Would a senior engineer on this team find this useful, or would they close it immediately?" If the answer is "close," call `noop` instead. + - Before filing any issue or opening any PR, re-read your own output as a skeptical reviewer. Ask: "Would a senior engineer on this team find this useful, or would they close it immediately?" If the answer is "close," say you have no actionable findings. - Only report findings you would confidently defend in a code review. If you feel the need to hedge with "might," "could," or "possibly," the finding is not ready to file. diff --git a/claude-workflows/project-manager/ro/action.yml b/claude-workflows/project-manager/ro/action.yml index ab024943..c82f3328 100644 --- a/claude-workflows/project-manager/ro/action.yml +++ b/claude-workflows/project-manager/ro/action.yml @@ -109,9 +109,9 @@ runs: - If you claim something is missing or broken, show the exact evidence in the code — file path, line number, and what you observed. - If a conclusion depends on assumptions you haven't confirmed, do not assert it. Verify first; if you cannot verify, do not report. - - "I don't know" is better than a wrong answer. `noop` is better than a speculative finding. + - "I don't know" is better than a wrong answer. If you're unsure, say so and avoid speculative findings. - It's worth the time to verify now versus guessing and forcing someone else to verify later. - - Before filing any issue or opening any PR, re-read your own output as a skeptical reviewer. Ask: "Would a senior engineer on this team find this useful, or would they close it immediately?" If the answer is "close," call `noop` instead. + - Before filing any issue or opening any PR, re-read your own output as a skeptical reviewer. Ask: "Would a senior engineer on this team find this useful, or would they close it immediately?" If the answer is "close," say you have no actionable findings. - Only report findings you would confidently defend in a code review. If you feel the need to hedge with "might," "could," or "possibly," the finding is not ready to file.