[workflow-style] Normalize report formatting for non-compliant workflows
Maintainers usually reply within 1 day
Nobody has claimed this yet.
Assessment
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Newbie friendliness
- 77/100
- Issue type
- Documentation
- Clarity
- Clearly specified
- Activity status
- Active
- Tech stack
- github-actions, markdown
- Domain
- ci-cd, documentation
Research direction
Read .github/workflows/daily-work-queues-report.md and .github/workflows/metrics-collector.md, then compare their report guidance with .github/workflows/daily-repo-chronicle.md and .github/workflows/audit-workflows.md. Update both workflow prompts to specify the required headings, collapsible details, report order, visible metrics and limitations, and run-link format. Done when both prompts state those requirements and a subsequent active run produces reports with visible conclusions and collapsed long evidence.
Written by the indexing model from the issue text.
Description
Summary
Two active reporting workflows need consistent Markdown output guidance so their reports are easier to scan and more trustworthy for readers.
Findings
| Workflow | Gaps |
|---|---|
.github/workflows/daily-work-queues-report.md |
Relies on the reporting import but does not explicitly require h3-or-lower report headers or <details> blocks for long queue details. Its output instructions describe useful content, but not a complete overview → key metrics → collapsible details → next actions structure. |
.github/workflows/metrics-collector.md |
Collects and summarizes metrics but does not specify h3-or-lower headers, progressive disclosure for long output, or a clear reader-facing report structure. |
Required Changes
For each workflow:
- State that generated report headers must use
###or lower; reserve h1/h2 for the surrounding GitHub page. - Require
<details><summary><b>...</b></summary>...</details>for long tables, item lists, raw evidence, and detailed findings. - Define a consistent report structure: overview → key metrics/issues → collapsible detail → next actions or limitations.
- Keep decision-relevant metrics and limitations visible before the collapsible sections.
- Use workflow run links in the standard
[§RUN_ID](https://github.com/owner/repo/actions/runs/RUN_ID)form where runs are referenced.
Example
### Overview
One-paragraph conclusion and the most important limitation.
### Key Metrics
| Metric | Value |
|---|---:|
| Queue items | 12 |
<details>
<summary><b>Detailed findings</b></summary>
Long tables, evidence, and item-level context belong here.
</details>
### Next Actions
- [ ] Confirm the highest-priority item.
Use .github/workflows/daily-repo-chronicle.md and .github/workflows/audit-workflows.md as reference patterns for concise, user-focused reports with visible conclusions and collapsed detail.
Acceptance Criteria
- Both workflow prompts explicitly document h3-or-lower headers.
- Both prompts explicitly document progressive disclosure with
<details>and bold summaries. - Both prompts define the overview → metrics/issues → detail → next-actions structure.
- A subsequent active run produces reports that preserve visible conclusions while collapsing long evidence.
This issue consolidates the findings from the daily workflow-style review for the last 24 hours.
Generated by 🔧 Workflow Normalizer · codex · gpt56 · ~4 AIC · ⌖ ~1 AIC · ⊞ 15.3K · ◷
- expires on Nov 6, 2026, 4:56 AM UTC-08:00
- Dominant language
- Go
- Stars
- 5.6k
- Forks
- 615
- Avg merge
- 5h 36m
- Merged PRs (30d)
- 805
Getting set up
Starts the project's dev container in your browser, under your own GitHub account.
- Ships a Dockerfile or Docker Compose file
- No pull request template
- Read the contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from github/gh-aw
-
agentic-workflows
Difficulty 1/5 Under an hour Newbie friendliness 82/100
Maintainers usually reply within 1 day
-
agentic-workflows
Difficulty 1/5 Under an hour Newbie friendliness 65/100
Maintainers usually reply within 1 day
-
automation cli cookie documentation
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
Maintainers usually reply within 1 day
-
automation observability optimization traces
Difficulty 2/5 1-3 hours Newbie friendliness 74/100
Maintainers usually reply within 1 day
-
cookie improvement refactoring shared-component
Difficulty 2/5 1-3 hours Newbie friendliness 83/100
Maintainers usually reply within 1 day
Similar issues
-
Logging into a locally started instance clears its container reference, causing stop to do nothingOpen
Difficulty 2/5 1-3 hours Newbie friendliness 79/100
microcks/microcks-cli#620 ·
Maintainers usually reply within 1 day
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 77/100
teradata-labs/loom#574 ·
Maintainers usually reply within 1 day
-
cli: name the CRID when saved link limits fail after publish; soften plain-republish mint warningOpenenhancement pr-polish-followup priority: low
Difficulty 2/5 1-3 hours Newbie friendliness 74/100
layervai/qurl-integrations#1994 ·
Maintainers usually reply within 1 day
-
bug needs-acceptance wg/router-models-inference-runtime
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
vllm-project/semantic-router#5891 ·
Maintainers usually reply within 1 day
-
bug needs triage
Difficulty 2/5 1-3 hours Newbie friendliness 74/100
Maintainers usually reply within 1 day