spec-coding-skills/.codex/skills/miaobao-nightly-ci-report/SKILL.md

name, description

name	description
miaobao-nightly-ci-report	Produce the Miaobao nightly or mainline Drone CI digest when the user asks for recent failing CI, nightly CI reports, or main health; enforce fixed Chinese headings, exact build-step-error evidence, and no speculation.

Miaobao Nightly CI Report

Use this in /Users/zfc/code/real_product/miaobao when the task is a nightly/mainline CI digest for Drone and the user wants a short Chinese conclusion built only from real build/log evidence.

Do not use this for fixing the failing code, broad PR closeout, or speculative CI triage without Drone access.

Inputs / Context

1. Confirm the repo is intelligrow/miaobao.
2. Confirm DRONE_SERVER and DRONE_TOKEN exist in the environment.
3. Resolve how many recent failed builds to inspect; default to 10 if the user does not specify a count.
4. Group target builds by branch type:
   • refs/heads/main
   • PR builds
   • tag builds if they matter for "谁被挡住"

Procedure

1. Fetch the latest build list from Drone.
2. Identify recent failed builds in recency order.
3. For each cited build:
   • fetch build detail first
   • read stages / steps
   • derive the exact log path /api/repos/intelligrow/miaobao/builds/<build>/logs/<stage>/<step>
4. Do not guess log URLs from step names.
5. Extract only concrete evidence needed for the report:
   • build number
   • branch / PR / commit when available
   • failing step name
   • failing test file or exact error text
6. Separate failure buckets before summarizing:
   • shared mainline code/test/lint problem
   • PR-only clone/setup issue
   • stale/expired failure already superseded by later green builds
   • tag-line health if the user cares about release blockage
7. Write the result in this exact order:
   • 今日结论：
   • main 是否健康：
   • 最新失败：
   • 谁被挡住：
   • 问题分类：
   • 证据：
   • 建议动作：
8. Keep the wording Chinese-only, short, and plain.
9. If any required field cannot be proven from Drone, write 证据不够.
10. End with one shortest action, for example:
    • 修代码
    • 修测试
    • 修 CI
    • 重跑确认
    • 开 issue
    • 关闭旧 PR
    • 暂时不用处理

Efficiency

1. Start from build list -> build detail -> exact failing step log.
2. Reuse one evidence packet per build; do not reopen the same logs repeatedly.
3. Prefer the newest meaningful blocker first.
4. Stop once the shared failure signature is proven and the fixed report shape is complete.
5. Do not spend time on browser/UI checks for this workflow.

Pitfalls

• If the report becomes speculative, cite only build detail plus the exact failing step log; otherwise write 证据不够.
• If guessed log URLs fail, derive /logs/<stage>/<step> from build detail every time.
• If an old red build looks active, compare newest main, PR, and tag states before summarizing "谁被挡住".
• If PR clone/setup noise appears, classify it separately from product code/test/lint failures.

Verification Checklist

• Output is fully in Chinese.
• Output uses the fixed heading order exactly.
• Every conclusion is backed by real Drone evidence or explicitly says 证据不够.
• The report names exact build numbers and step names.
• Error text or failing test file is included when available.
• Main, PR, and tag states are not collapsed together incorrectly.
• The final action is one short recommendation, not a long remediation list.