feat(skills): add miaobao workflows
This commit is contained in:
@@ -0,0 +1,72 @@
|
||||
---
|
||||
name: miaobao-issue-acceptance-closeout
|
||||
description: Complete a Miaobao issue or PR acceptance closeout when CI is green, a PR is ready to merge, or bookkeeping remains; includes local verification, Gitea/Drone truth, Feishu Base reconciliation, explicit confirmation, read-back, and cleanup.
|
||||
---
|
||||
|
||||
# Miaobao Issue Acceptance Closeout
|
||||
|
||||
Use this when a Miaobao issue fix has reached PR/CI/merge-closeout state and the missing work is bookkeeping, verification, or cleanup.
|
||||
|
||||
Do not use this for initial debugging or feature implementation.
|
||||
|
||||
## Inputs / Context
|
||||
|
||||
1. Confirm the target issue, PR, worktree, and branch.
|
||||
2. Check whether the task belongs to:
|
||||
- requirements pool table `tblvIEDIu5WDWbn9`
|
||||
- dev-task table `tblSbtRSb6L6EaPB`
|
||||
3. Check the current truth surfaces:
|
||||
- local verification output
|
||||
- Gitea PR state
|
||||
- linked issue state
|
||||
- Drone build state
|
||||
- existing Feishu/Base record or absence of one
|
||||
4. Verify whether `lark-cli` is callable; on this Mac it may live at `/Users/zfc/.npm-global/bin/lark-cli`.
|
||||
|
||||
## Procedure
|
||||
|
||||
1. Reconfirm the local result before touching bookkeeping.
|
||||
- Prefer exact focused tests plus the repo's normal gate: `typecheck`, `lint`, `format:check`, build/test as appropriate.
|
||||
2. Reconfirm remote state.
|
||||
- Check latest PR head, Drone result, mergeability, and whether the linked issue is already closed.
|
||||
3. Find the Feishu/Base row before writing anything.
|
||||
- Use `+record-search` by issue number, title, or PR number.
|
||||
4. Prepare the record draft and show it to the user before writing.
|
||||
- Keep identifier columns simple:
|
||||
- `Gitea工单`: bare digits like `1631`
|
||||
- `PR` or `PR编号`: bare digits like `1731`
|
||||
- Put links, CI evidence, and notes in narrative fields such as `备注` or `验收标准`.
|
||||
5. After explicit confirmation, write with `lark-cli`.
|
||||
6. Read the record back and verify the exact written state.
|
||||
7. Clean the local acceptance environment only after the record is verified.
|
||||
- Worktree removal
|
||||
- Local branch cleanup if appropriate
|
||||
- Port cleanup
|
||||
- Screenshot/temp artifact cleanup if they were acceptance-only
|
||||
|
||||
## Efficiency
|
||||
|
||||
1. Route by issue/PR number first; avoid broad repo scans.
|
||||
2. Reuse one authoritative Base/table/view target instead of guessing from older links.
|
||||
3. Prefer one final reconciliation pass:
|
||||
- local evidence
|
||||
- PR/issue state
|
||||
- Feishu record-search
|
||||
- cleanup
|
||||
4. Stop once all of these agree; do not keep rechecking unrelated browser/UI state.
|
||||
|
||||
## Pitfalls
|
||||
|
||||
- If the PR is merged but the task still is not actually done, check Feishu/Base update and read-back before closeout.
|
||||
- If Feishu fields look noisy or sort badly, keep ID fields as bare digits and move narrative evidence elsewhere.
|
||||
- If browser login looks wrong, do not assume Feishu is inaccessible; test the actual `lark-cli` path and cached identity directly.
|
||||
- If CI says `Build was killed` or a long test step fails without code evidence, inspect step-level Drone state before changing product code.
|
||||
|
||||
## Verification Checklist
|
||||
|
||||
- Local verification outputs exist and match the task scope.
|
||||
- Latest Drone/build state is green or the exact non-code blocker is documented.
|
||||
- PR state is correct and linked issue state is correct.
|
||||
- Feishu/Base record exists or was created intentionally.
|
||||
- Written record was read back and matches the intended status.
|
||||
- Local acceptance worktree/env cleanup is complete.
|
||||
@@ -0,0 +1,83 @@
|
||||
---
|
||||
name: miaobao-nightly-ci-report
|
||||
description: 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.
|
||||
Reference in New Issue
Block a user