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.
|
||||
@@ -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:
|
||||
|
||||
Reference in New Issue
Block a user