95 lines
3.9 KiB
Markdown
95 lines
3.9 KiB
Markdown
---
|
|
name: update-miaobao
|
|
description: Review completed Miaobao work and propose updates to Miaobao-related skills. Use when the user asks to reflect on a Miaobao task, update Miaobao workflows, improve miaobao-issue-acceptance, update_miaobao, up-miaobao, or maintain Miaobao skills after an acceptance, PR, or bug-capture run.
|
|
---
|
|
|
|
# Update Miaobao Skills
|
|
|
|
## Goal
|
|
|
|
Turn feedback from completed Miaobao work into high-signal updates for Miaobao
|
|
skills. This skill only manages skills. Do not update memory, docs, issue
|
|
comments, or scripts unless the user separately asks for that.
|
|
|
|
## Targets
|
|
|
|
- Default flagship:
|
|
`/Users/zfc/.codex/skills/miaobao-issue-acceptance/SKILL.md`
|
|
- Bug capture:
|
|
`/Users/zfc/.agents/skills/miaobao-capture-bug/SKILL.md`
|
|
- Future Miaobao skills under `/Users/zfc/.codex/skills/` or
|
|
`/Users/zfc/.agents/skills/`, only after the split gate below passes.
|
|
|
|
## Quick Start
|
|
|
|
1. Identify the completed Miaobao task, issue, PR, or bug-capture run.
|
|
2. Extract pits, wins, and target skills from the conversation/evidence.
|
|
3. Prefer updating an existing skill, especially `miaobao-issue-acceptance`.
|
|
4. Present target path, reason, and unified diff before writing.
|
|
5. Wait for explicit user confirmation before changing any skill file.
|
|
6. After writing, reread the changed file and report the exact path.
|
|
|
|
## Routing
|
|
|
|
Use `miaobao-issue-acceptance` for:
|
|
|
|
- worktree setup, runtime files, ports, Hocuspocus, startup, and cleanup
|
|
- Superpowers full workflow, TDD, root-cause debugging, verification, review,
|
|
PR preparation, merge, and issue closure
|
|
- dedicated browser/profile handoff, login state, Chrome plugin/control ports,
|
|
screenshots, console/network evidence, and manual acceptance
|
|
- AI media capability verification: image/video/audio/BGM model setup, real
|
|
task creation, generated assets, and media stream proof
|
|
- Gitea PR hygiene, especially `Closes #<issue>` and post-merge closure checks
|
|
|
|
Use `miaobao-capture-bug` for:
|
|
|
|
- turning vague user notes, screenshots, or recordings into Gitea issues
|
|
- evidence extraction, media upload, version lookup, labels, priority, and final
|
|
confirmation gates for issue create/update/comment/upload
|
|
- reproducing and publishing demo videos for bug reports
|
|
|
|
If feedback spans both, propose separate diffs per skill.
|
|
|
|
## Split Gate
|
|
|
|
Creating a new Miaobao skill, or proposing a skill-composition/DAG workflow, is
|
|
allowed only when all are true:
|
|
|
|
- The same friction or workflow pattern has repeated.
|
|
- The boundary is clear enough to say what the skill owns and does not own.
|
|
- The trigger is specific enough for a future agent to choose it reliably.
|
|
- It does not substantially overlap with an existing Miaobao skill.
|
|
- The workflow has concrete acceptance evidence or deterministic checks.
|
|
- It can cooperate with the flagship skill through an explicit sequence.
|
|
|
|
If any condition is weak, update the flagship skill instead and mention the
|
|
possible future split only as a note.
|
|
|
|
## Diff Gate
|
|
|
|
Never silently edit a Miaobao skill from reflection alone. Before writing, show:
|
|
|
|
- target skill path
|
|
- why this target is correct
|
|
- exact unified diff
|
|
- whether the change fixes a pit, preserves a win, or adds a split/DAG gate
|
|
- why the lesson is high confidence
|
|
|
|
Only apply the patch after explicit confirmation. A reply of `1` confirms only
|
|
the reviewed diff/action set, not additional unreviewed edits.
|
|
|
|
## Output
|
|
|
|
Keep output compact: summarize pits, wins, target skill, proposed diff, and any
|
|
new skill/DAG recommendation with confidence and trigger conditions.
|
|
|
|
## Common Mistakes
|
|
|
|
- Editing memory, docs, issues, or scripts from this skill.
|
|
- Creating a new skill from a one-off idea instead of repeated workflow pressure.
|
|
- Forgetting to preserve wins, such as PR closure or strong browser handoff.
|
|
- Asking generic update questions when the user already gave concrete feedback.
|
|
- Mixing bug-capture rules into acceptance workflow rules.
|
|
- Applying a patch before the user has reviewed the exact diff.
|