spec-coding-skills/.claude/skills/miaobao-issue-acceptance-closeout/SKILL.md

name, description

name	description
miaobao-issue-acceptance-closeout	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.