You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Use the gh-aw inlined-imports frontmatter flag (v0.67.3) to embed
all imported content at compile time. This produces self-contained
lock files with zero runtime-import directives, fixing the cross-repo
workflow_call failure while keeping fragments for reuse.
- Add inlined-imports: true to both workflow .md sources
- Restore gh-aw-fragments/ with formatting, rigor, mcp-pagination,
messages-footer, and safe-output-add-comment
- Move shared content back into fragments, out of workflow prompts
- Update DEVELOPING.md to document inlined-imports convention
- Update create-agentic-workflow skill to use imports + inlined-imports
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
-`.github/workflows/gh-aw-issue-triage.md` — triage pattern with pre-steps
67
67
68
-
Generate `.github/workflows/gh-aw-<name>.md` with all content inlined. **Do NOT use `imports:`** — the gh-aw runtime import mechanism does not work for cross-repo `workflow_call`, which is how consumer repos invoke these workflows. All prompt content, safe-output constraints, and MCP server docs must be directly in the `.md` file.
68
+
Generate `.github/workflows/gh-aw-<name>.md`. Read the available fragments in `.github/workflows/gh-aw-fragments/` and import those relevant to the workflow. **Always include `inlined-imports: true`** — this embeds all imported content at compile time, which is required for cross-repo `workflow_call` invocation.
69
69
70
70
```yaml
71
71
---
72
72
description: |
73
73
<one-line description>
74
74
75
+
inlined-imports: true
76
+
imports:
77
+
- gh-aw-fragments/formatting.md
78
+
- gh-aw-fragments/rigor.md
79
+
- gh-aw-fragments/mcp-pagination.md
80
+
- gh-aw-fragments/messages-footer.md
81
+
- gh-aw-fragments/safe-output-<type>.md
75
82
engine:
76
83
id: copilot
77
84
on:
@@ -116,8 +123,6 @@ network:
116
123
- "www.elastic.co"
117
124
strict: false
118
125
safe-outputs:
119
-
messages:
120
-
footer: "${{ inputs.messages-footer || '---\n[Docs automation](https://github.com/elastic/docs-actions) | [From workflow: {workflow_name}]({run_url})\n\nReact with 👍 if helpful, 👎 if not.' }}"
121
126
noop:
122
127
<output-type>:
123
128
timeout-minutes: 30
@@ -130,22 +135,17 @@ steps:
130
135
---
131
136
```
132
137
133
-
Follow the frontmatter with the agent prompt in markdown. Structure it as:
138
+
Follow the frontmatter with the agent prompt in markdown. The imported fragments provide formatting guidelines, rigor standards, MCP pagination tips, safe-output limitations, and the message footer note — so you don't need to repeat those. Structure the workflow-specific prompt as:
134
139
1.**Role statement** — who the agent is and what it does
135
-
2.**Formatting guidelines** — lead with key info, be concise, use `<details>` tags
4.**MCP pagination** — token limit guidance if the workflow uses MCP tools
138
-
5.**Data gathering** — what to read, search, or fetch
139
-
6.**Analysis** — what to look for, how to evaluate findings
140
-
7.**What to skip** — explicit exclusions to reduce noise
141
-
8.**Quality gate** — when to noop vs. when to report (noop is the expected outcome)
142
-
9.**Safe output limitations** — max body size, mention limits, allowed HTML for the output type
143
-
10.**Message footer note** — "A footer is automatically appended to all comments and reviews. Do not add your own footer or sign-off — the runtime handles this."
144
-
11.**Output format** — exact format for the issue body, PR body, or comment
140
+
2.**Data gathering** — what to read, search, or fetch
141
+
3.**Analysis** — what to look for, how to evaluate findings
142
+
4.**What to skip** — explicit exclusions to reduce noise
143
+
5.**Quality gate** — when to noop vs. when to report (noop is the expected outcome)
144
+
6.**Output format** — exact format for the issue body, PR body, or comment
145
145
146
146
End with `${{ inputs.additional-instructions }}` so callers can inject repo-specific guidance.
147
147
148
-
Not every section is needed for every workflow — include what's relevant. Read the existing workflows for examples of what to include.
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.
4
+
5
+
### Recommended `perPage` Values
6
+
7
+
-**5-10**: For detailed items (PR diffs, files with patches, issues with comments)
8
+
-**20-30**: For medium-detail lists (commits, review comments, issue lists)
9
+
-**50-100**: For simple list operations (branches, labels, tags)
10
+
11
+
### Pagination Pattern
12
+
13
+
When you need all results from a paginated API:
14
+
15
+
1. Fetch the first page with a conservative `perPage` value
16
+
2. Process the results before fetching the next page
17
+
3. Continue fetching pages until you receive fewer results than `perPage` (indicating the last page)
18
+
19
+
If you see `MCP tool response exceeds maximum allowed tokens`, retry with a smaller `perPage` value (halve it).
**Silence is better than noise. A false positive wastes a human's time and erodes trust in every future report.**
4
+
5
+
- If you claim something is missing or broken, show the exact evidence in the code — file path, line number, and what you observed.
6
+
- If a conclusion depends on assumptions you haven't confirmed, do not assert it. Verify first; if you cannot verify, do not report.
7
+
- "I don't know" is better than a wrong answer. `noop` is better than a speculative finding.
8
+
- It's worth the time to verify now versus guessing and forcing someone else to verify later.
9
+
- 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.
10
+
- 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.
0 commit comments