diff --git a/.github/workflows/issue-triage-agent.lock.yml b/.github/workflows/issue-triage-agent.lock.yml index 5727b97711..afcb8449cf 100644 --- a/.github/workflows/issue-triage-agent.lock.yml +++ b/.github/workflows/issue-triage-agent.lock.yml @@ -19,6 +19,10 @@ # gh aw compile # For more information: https://github.com/githubnext/gh-aw/blob/main/.github/aw/github-agentic-workflows.md # +# +# Resolved workflow manifest: +# Imports: +# - shared/reporting.md name: "Issue Triage Agent" "on": @@ -526,6 +530,76 @@ jobs: PROMPT_EOF cat << 'PROMPT_EOF' >> "$GH_AW_PROMPT" + ## Report Structure Guidelines + + ### 1. Header Levels + **Use h3 (###) or lower for all headers in your issue report to maintain proper document hierarchy.** + + When creating GitHub issues or discussions: + - Use `###` (h3) for main sections (e.g., "### Test Summary") + - Use `####` (h4) for subsections (e.g., "#### Device-Specific Results") + - Never use `##` (h2) or `#` (h1) in reports - these are reserved for titles + + ### 2. Progressive Disclosure + **Wrap detailed test results in `
Section Name` tags to improve readability and reduce scrolling.** + + Use collapsible sections for: + - Verbose details (full test logs, raw data) + - Secondary information (minor warnings, extra context) + - Per-item breakdowns when there are many items + + Always keep critical information visible (summary, critical issues, key metrics). + + ### 3. Report Structure Pattern + + 1. **Overview**: 1-2 paragraphs summarizing key findings + 2. **Critical Information**: Show immediately (summary stats, critical issues) + 3. **Details**: Use `
Section Name` for expanded content + 4. **Context**: Add helpful metadata (workflow run, date, trigger) + + ### Design Principles (Airbnb-Inspired) + + Reports should: + - **Build trust through clarity**: Most important info immediately visible + - **Exceed expectations**: Add helpful context like trends, comparisons + - **Create delight**: Use progressive disclosure to reduce overwhelm + - **Maintain consistency**: Follow patterns across all reports + + ### Example Report Structure + + ```markdown + ### Summary + - Key metric 1: value + - Key metric 2: value + - Status: ✅/⚠️/❌ + + ### Critical Issues + [Always visible - these are important] + +
+ View Detailed Results + + [Comprehensive details, logs, traces] + +
+ +
+ View All Warnings + + [Minor issues and potential problems] + +
+ + ### Recommendations + [Actionable next steps - keep visible] + ``` + + ## Workflow Run References + + - Format run IDs as links: `[§12345](https://github.com/owner/repo/actions/runs/12345)` + - Include up to 3 most relevant run URLs at end under `**References:**` + - Do NOT add footer attribution (system adds automatically) + # Issue Triage Agent List open issues in __GH_AW_GITHUB_REPOSITORY__ that have no labels. For each unlabeled issue, analyze the title and body, then add one of the allowed labels: `bug`, `feature`, `enhancement`, `documentation`, `question`, `help-wanted`, or `good-first-issue`. @@ -534,7 +608,48 @@ jobs: - Already have any of these labels - Have been assigned to any user (especially non-bot users) - After adding the label to an issue, mention the issue author in a comment explaining why the label was added. + After adding the label to an issue, mention the issue author in a comment using this format (follow shared/reporting.md guidelines): + + **Comment Template**: + ```markdown + ### 🏷️ Issue Triaged + + Hi @{author}! I've categorized this issue as **{label_name}** based on the following analysis: + + **Reasoning**: {brief_explanation_of_why_this_label} + +
+ View Triage Details + + #### Analysis + - **Keywords detected**: {list_of_keywords_that_matched} + - **Issue type indicators**: {what_made_this_fit_the_category} + - **Confidence**: {High/Medium/Low} + + #### Recommended Next Steps + - {context_specific_suggestion_1} + - {context_specific_suggestion_2} + +
+ + **References**: [Triage run §{run_id}](https://github.com/githubnext/gh-aw/actions/runs/{run_id}) + ``` + + **Key formatting requirements**: + - Use h3 (###) for the main heading + - Keep reasoning visible for quick understanding + - Wrap detailed analysis in `
` tags + - Include workflow run reference + - Keep total comment concise (collapsed details prevent noise) + + ## Batch Comment Optimization + + For efficiency, if multiple issues are triaged in a single run: + 1. Add individual labels to each issue + 2. Add a brief comment to each issue (using the template above) + 3. Optionally: Create a discussion summarizing all triage actions for that run + + This provides both per-issue context and batch visibility. PROMPT_EOF - name: Substitute placeholders diff --git a/.github/workflows/issue-triage-agent.md b/.github/workflows/issue-triage-agent.md index 8965f9b493..03add672f5 100644 --- a/.github/workflows/issue-triage-agent.md +++ b/.github/workflows/issue-triage-agent.md @@ -13,6 +13,8 @@ safe-outputs: add-labels: allowed: [bug, feature, enhancement, documentation, question, help-wanted, good-first-issue] add-comment: {} +imports: + - shared/reporting.md --- # Issue Triage Agent @@ -23,4 +25,45 @@ Skip issues that: - Already have any of these labels - Have been assigned to any user (especially non-bot users) -After adding the label to an issue, mention the issue author in a comment explaining why the label was added. +After adding the label to an issue, mention the issue author in a comment using this format (follow shared/reporting.md guidelines): + +**Comment Template**: +```markdown +### 🏷️ Issue Triaged + +Hi @{author}! I've categorized this issue as **{label_name}** based on the following analysis: + +**Reasoning**: {brief_explanation_of_why_this_label} + +
+View Triage Details + +#### Analysis +- **Keywords detected**: {list_of_keywords_that_matched} +- **Issue type indicators**: {what_made_this_fit_the_category} +- **Confidence**: {High/Medium/Low} + +#### Recommended Next Steps +- {context_specific_suggestion_1} +- {context_specific_suggestion_2} + +
+ +**References**: [Triage run §{run_id}](https://github.com/githubnext/gh-aw/actions/runs/{run_id}) +``` + +**Key formatting requirements**: +- Use h3 (###) for the main heading +- Keep reasoning visible for quick understanding +- Wrap detailed analysis in `
` tags +- Include workflow run reference +- Keep total comment concise (collapsed details prevent noise) + +## Batch Comment Optimization + +For efficiency, if multiple issues are triaged in a single run: +1. Add individual labels to each issue +2. Add a brief comment to each issue (using the template above) +3. Optionally: Create a discussion summarizing all triage actions for that run + +This provides both per-issue context and batch visibility. diff --git a/.github/workflows/security-alert-burndown.campaign.lock.yml b/.github/workflows/security-alert-burndown.campaign.lock.yml index 891055e70d..0abccd72ba 100644 --- a/.github/workflows/security-alert-burndown.campaign.lock.yml +++ b/.github/workflows/security-alert-burndown.campaign.lock.yml @@ -112,12 +112,11 @@ jobs: run: mkdir -p ./.gh-aw - env: GH_AW_CAMPAIGN_ID: security-alert-burndown - GH_AW_CURSOR_PATH: /tmp/gh-aw/repo-memory/campaigns/security-alert-burndown/cursor.json - GH_AW_DISCOVERY_REPOS: githubnext/gh-aw + GH_AW_CURSOR_PATH: "" GH_AW_MAX_DISCOVERY_ITEMS: "100" GH_AW_MAX_DISCOVERY_PAGES: "5" GH_AW_PROJECT_URL: https://github.com/orgs/githubnext/projects/134 - GH_AW_TRACKER_LABEL: z_campaign_security-alert-burndown + GH_AW_TRACKER_LABEL: "" GH_AW_WORKFLOWS: code-scanning-fixer,security-fix-pr,dependabot-bundler,secret-scanning-triage id: discovery name: Run campaign discovery precomputation @@ -898,9 +897,6 @@ jobs: This workflow orchestrates the 'Security Alert Burndown' campaign. - Associated workflows: code-scanning-fixer, security-fix-pr, dependabot-bundler, secret-scanning-triage - - Memory paths: memory/campaigns/security-alert-burndown/** - - Metrics glob: `memory/campaigns/security-alert-burndown/metrics/*.json` - - Cursor glob: `memory/campaigns/security-alert-burndown/cursor.json` - Project URL: https://github.com/orgs/githubnext/projects/134 - Governance: max new items per run: 3 - Governance: max discovery items per run: 100 @@ -1224,35 +1220,9 @@ jobs: - On throttling (HTTP 429 / rate-limit 403), do not retry aggressively; back off and end the run after reporting what remains. - **Cursor file (repo-memory)**: `memory/campaigns/security-alert-burndown/cursor.json` - **File system path**: `/tmp/gh-aw/repo-memory/campaigns/security-alert-burndown/cursor.json` - - If it exists: read first and continue from its boundary. - - If it does not exist: create it by end of run. - - Always write the updated cursor back to the same path. - **Metrics snapshots (repo-memory)**: `memory/campaigns/security-alert-burndown/metrics/*.json` - **File system path**: `/tmp/gh-aw/repo-memory/campaigns/security-alert-burndown/metrics/*.json` - - Persist one append-only JSON metrics snapshot per run (new file per run; do not rewrite history). - - Use UTC date (`YYYY-MM-DD`) in the filename (example: `metrics/2025-12-22.json`). - - Each snapshot MUST include ALL required fields (even if zero): - - `campaign_id` (string): The campaign identifier - - `date` (string): UTC date in YYYY-MM-DD format - - `tasks_total` (number): Total number of tasks (>= 0, even if 0) - - `tasks_completed` (number): Completed task count (>= 0, even if 0) - - Optional fields (include only if available): `tasks_in_progress`, `tasks_blocked`, `velocity_per_day`, `estimated_completion` - - Example minimum valid snapshot: - ```json - { - "campaign_id": "security-alert-burndown", - "date": "2025-12-22", - "tasks_total": 0, - "tasks_completed": 0 - } - ``` - - **Read budget**: max discovery items per run: 100 @@ -1381,8 +1351,6 @@ jobs: 1) Read the precomputed discovery manifest: `./.gh-aw/campaign.discovery.json` - This manifest contains all discovered worker outputs with normalized metadata - PROMPT_EOF - cat << 'PROMPT_EOF' >> "$GH_AW_PROMPT" - Schema version: v1 - Fields: campaign_id, generated_at, discovery (total_items, cursor info), summary (counts), items (array of normalized items) @@ -1413,6 +1381,8 @@ jobs: - `start_date`: format `created_at` as `YYYY-MM-DD` - `end_date`: - if closed/merged → format `closed_at`/`merged_at` as `YYYY-MM-DD` + PROMPT_EOF + cat << 'PROMPT_EOF' >> "$GH_AW_PROMPT" - if open → **today's date** formatted `YYYY-MM-DD` (required for roadmap view) **Why use today for open items?** - GitHub Projects requires end_date for roadmap views. Using today's date shows the item is actively tracked and updates automatically each run until completion.