feat(skills): add miaobao workflows

2026-06-29 14:00:25 +08:00
parent e702d69779
commit 160a4f2fb4
5 changed files with 326 additions and 0 deletions
@@ -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.
@@ -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.
@@ -52,6 +52,8 @@ RequirementsDoc ──▶ PRD ──▶ FeatureSummary ──▶ DevelopmentPlan
 | | `issue` | `/issue` | `/issue` | Gitea issue 只读专用入口（支持当前仓库自动识别） |
 | | `issue-drive` | `/issue-drive` | `/issue-drive` | Gitea issue 拆单与批量创建专用入口 |
 | | `changelog` | `/changelog` | `/changelog` | 一键发版（日志 + commit + tag） |
 | **Miaobao** | `miaobao-nightly-ci-report` | `/miaobao-nightly-ci-report` | `/miaobao-nightly-ci-report` | Miaobao Drone nightly/main CI 证据报告 |
 | | `miaobao-issue-acceptance-closeout` | `/miaobao-issue-acceptance-closeout` | `/miaobao-issue-acceptance-closeout` | Miaobao issue/PR 验收、Feishu 回写与清理 |
 > Codex 兼容历史 `$skill` 写法，但本文档统一以 `/skill` 作为主入口。
@@ -161,8 +163,22 @@ Codex:
 请用 gitea skill 给当前分支开 PR 到 main
 请用 gitea skill push 当前分支到远端
 请用 issue-drive skill 把当前 bug 拆成两张 Gitea issue
 请用 miaobao-nightly-ci-report skill 看最近 10 个 Miaobao CI 失败
 请用 miaobao-issue-acceptance-closeout skill 收尾 Miaobao #1906 / PR #1910
 ```
 ### Miaobao 专项
 另一台机器要吃到最新 Miaobao skill，直接在目标项目根目录执行安装命令即可：
 ```bash
 bash <(curl -sL https://git.internal.intelligrow.cn/zhangfucai/spec-coding-skills/raw/branch/main/install.sh) both
 ```
 - `miaobao-nightly-ci-report` 依赖 Drone 访问环境：`DRONE_SERVER`、`DRONE_TOKEN`
 - `miaobao-issue-acceptance-closeout` 依赖当前 Miaobao worktree、Gitea/Drone 状态，以及可用的 `lark-cli`
 - Codex 新会话会重新扫描 skill；如果刚安装后当前会话没有看到新 skill，开一个新会话最稳
 ### 复刻一次成功经验
 Claude Code: