diff --git a/.claude/skills/miaobao-issue-acceptance-closeout/SKILL.md b/.claude/skills/miaobao-issue-acceptance-closeout/SKILL.md new file mode 100644 index 0000000..8983c0a --- /dev/null +++ b/.claude/skills/miaobao-issue-acceptance-closeout/SKILL.md @@ -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. diff --git a/.claude/skills/miaobao-nightly-ci-report/SKILL.md b/.claude/skills/miaobao-nightly-ci-report/SKILL.md new file mode 100644 index 0000000..047fd7a --- /dev/null +++ b/.claude/skills/miaobao-nightly-ci-report/SKILL.md @@ -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//logs//` +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//` 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. diff --git a/.codex/skills/miaobao-issue-acceptance-closeout/SKILL.md b/.codex/skills/miaobao-issue-acceptance-closeout/SKILL.md new file mode 100644 index 0000000..8983c0a --- /dev/null +++ b/.codex/skills/miaobao-issue-acceptance-closeout/SKILL.md @@ -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. diff --git a/.codex/skills/miaobao-nightly-ci-report/SKILL.md b/.codex/skills/miaobao-nightly-ci-report/SKILL.md new file mode 100644 index 0000000..047fd7a --- /dev/null +++ b/.codex/skills/miaobao-nightly-ci-report/SKILL.md @@ -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//logs//` +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//` 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. diff --git a/README.md b/README.md index 7c6fd5a..2165a3e 100644 --- a/README.md +++ b/README.md @@ -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: