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.