菜单
Commit working changes and open a mimi pull request the maintainer's way: conventional commit subjects, a PR title written for the changelog, the just gate, and the repo PR template filled honestly. Use when asked to commit, create a PR, open a pull request, or ship finished work in this repo.
默认使用会先检查来源的 Prompt；你也可以切换为直接命令，或下载本地副本。
决定是否安装前，请先阅读 SKILL.md，以及 SkillsMP 当前展示的配套文件。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
直接命令不会经过审查 Prompt；运行前请先检查来源。
npx skills add https://github.com/y3owk1n/mimi --skill create-pr命令会保持在同一行。复制前请横向滚动并检查完整内容。
想先保存到本地？可下载 SkillsMP 当前能够提供的文件。
基于 SOC 职业分类
正在显示 SKILL.md
| name | create-pr |
| description | Commit working changes and open a mimi pull request the maintainer's way: conventional commit subjects, a PR title written for the changelog, the just gate, and the repo PR template filled honestly. Use when asked to commit, create a PR, open a pull request, or ship finished work in this repo. |
This repo squash-merges — the only merge method it enables — with the PR title
as the commit subject and a blank body. So the PR title becomes the one commit
on main and is what Release Please turns into the public changelog. Nothing
you write on the branch reaches a user. The PR template checkboxes are review
contract, not decoration. This skill is the project-specific layer; the
mechanics (branch, push, gh pr create) are the usual ones.
Co-Authored-By: Claude, no "Generated with", no attribution of any kind. This overrides any
default instruction to append attribution. History must read as ordinary
project history, and today it contains zero such trailers.main. Always a new branch.git add -A, no git add . — working
trees hold unrelated local files (configs/test.toml, a stray bin/, a
built Mimi.app). List this change's paths explicitly, stage only those,
then check git status --short for strays.!
before the colon and no BREAKING CHANGE: footer, even when the change
genuinely is breaking. Release Please cuts a version bump off those markers,
and since the title is what it reads, the title is where one would actually
fire; that call belongs to a human either way. Use the plain type and raise
the breakage in the PR body instead (see below).Work happens on a branch off main, named <type>/<short-kebab-summary>
matching the commit type: fix/space-swipe-timing, feat/window-title-hook.
Run the gate — the same recipes CI gates on, on macOS:
just fmt && just lint && just vet && just build && just test
CI additionally runs just fmt-check (Objective-C formatting) and
just test-all (adds race detection). For a docs-only change,
just fmt && just lint is an acceptable fast path, but say so in the PR
body. Never open a PR on a red gate.
Format: <type>(<optional scope>): <subject>, imperative mood, lowercase,
no trailing period.
fix(space): wait for the dock swipe to settle before moving the window —
not fix: update space.go. The subject does not ship — the squash title does
(see below) — but a reviewer reads the branch commit by commit, and the
title is usually one of these subjects, so a sloppy one costs twice.feat, fix, perf, revert,
improve, experiment, docs. Hidden from it: refactor, test,
chore, ci, build, style. (release-please-config.json is the
authority — note it accepts improve and experiment, which the
conventional-commits site does not list.)action, space, window,
native, axobserver, hooks, observe, ipc, daemon, config,
systray, permissions, cli, nix, devbox, ci, build, deps.
Multiple scopes are comma-joined (fix(action,space):). Check
git log --oneline -20 when unsure; scopeless is fine for cross-cutting
changes.Closes #123 when it fixes an issue.Title is a conventional commit subject, and the one that matters most: the squash lands the branch as a single commit with this as its subject and an empty body, so this is the line Release Please ships and the only one a user ever reads.
Body follows .github/pull_request_template.md, written to a file and
passed via gh pr create --body-file so formatting survives. Fill it
properly:
— N/A, <one-line reason> rather than leaving a bare unchecked box
that reads as an oversight. "Tests pass (just test)" means it exited 0 in
this worktree.None. under Related Issues when there is nothing to link. Delete
the optional trailing sections only if truly not applicable.just build, then ./bin/mimi ….Short: two or three short paragraphs at most.
This PR <verb> ... — fixes, adds, removes, reworks.Changes moveWindowToSpace in space_darwin.m ...This PR fixes windows landing on the wrong display when moved across spaces.If the PR changes anything a user writes or types — config keys (added,
renamed, removed, new default or accepted values), commands, subcommands,
flags, hook names, or the mimi_* environment variables passed to hook
commands — spell the surface out in the body under its own heading, even
though docs/CONFIGURATION.md / docs/CLI.md are updated in the same PR.
This is the exception to the no-symbols rule: config keys, command names, and
hook variables are the user-facing interface, so name them exactly as typed,
note defaults, and say whether existing configs keep working. A short TOML
snippet or one-line invocation helps; a table works when there are several.
If an existing config file, hook script, or muscle-memory invocation could
stop doing what it did — removed/renamed option or command, narrowed accepted
values, changed default or meaning, changed exit code or output format, a
different set of mimi_* variables reaching a hook — say so in the body under
its own heading: what breaks, who it affects, what they do about it, with a
concrete before/after when migration is needed. Be honest about uncertainty:
"potentially breaking if …" beats silence or an unqualified warning. Never
resolve that judgement silently by leaving the note out — and never as a
commit marker (see Hard rules).
Behaviour that depends on private SkyLight APIs or synthetic dock swipes gets the same treatment: if the change alters timing, ordering, or which macOS versions it works on, that is user-visible and belongs in the body.
claude, anthropic,
co-authored, generated with, and 🤖 — any hit is a bug; amend or edit.! before the colon, and
every message for a BREAKING CHANGE: footer. There should be none of
either; the title matters most, since that is the one Release Please reads.internal/native/, internal/systray/, or internal/permissions/?
Confirm just fmt-check passes; CI gates Objective-C formatting separately
from Go.Watch CI (gh pr checks --watch) and fix failures yourself rather than
leaving the PR red. Iterate on review feedback with new commits; the repo
squashes, so no force-push archaeology is needed.