From maigo
Drafts or rewrites GitHub PR titles and descriptions with user-impact titles and structured Why/What/Test Plan body. Handles PR templates and branch context.
How this skill is triggered — by the user, by Claude, or both
Slash command
/maigo:github-title-descriptionThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
<!-- mkdocs-include-start -->
Owner Agent: Tomori(/maigo:describe-pr step 2——orchestrator 前置抓料後交給燈套用)
Consumers: /maigo:describe-pr
PR title / description 是 reviewer 對這次變更的第一印象。常見的失敗:
這個 skill 把這四件事變成有結構的 process。
main;caller 可覆寫)git log <base>..HEAD --pretty=format:'%h %s%n%b' --no-mergesgit diff <base>...HEAD --statgit diff <base>...HEAD(必要時 truncate)skills/commit-message
Inputs 第 3 條([tool.commitizen] / .cz.* / commitlint 設定檔 → Conventional Commits;皆無 → 自由格式)。
這只影響 commit message 風格參考;PR title 本身永不套 type: prefix。.github/PULL_REQUEST_TEMPLATE.md(含大小寫變體與 .github/PULL_REQUEST_TEMPLATE/ 目錄)找到的 template 內容。
feat: 、fix: )auth.py」← bad;「Reject empty emails before hashing」← good| Bad | Good |
|---|---|
feat: add email validator | Reject empty emails at signup |
update auth.py and tests | Block login when MFA token expired |
WIP fix | Stop retry storm on 5xx from upstream |
必填三段(順序固定:Why → What → Test Plan):
## Why
<為什麼要做:bug repro / 痛點 / 觸發場景。可以引用 issue / 對話 / log。1–3 句。>
## What
<2–4 句或 bullets:這個 PR 改了什麼行為。reviewer 讀完就知道要看什麼。>
## Test Plan
- <怎麼驗證:跑了哪些 test / 手動測了什麼 / 看了哪個 metric>
- <command + 預期結果>
可選段(有才加,不要為了塞而塞):
## Breaking changes
<API / config / behaviour 改了什麼會打破既有 caller。沒有就不加這段。>
## Related issues
- Closes #<n>
- Refs #<n>
若 repo 有 PR template(Inputs 第 6 條):
## Why / ## What section,也要把這兩段作為 prose 加在 template 開頭的自由描述區(通常在第一條 --- 分隔線之前)。Why/What 是 reviewer 理解改動的最低資訊,不能因 template 不含它們就省略。| 段落 | 訊號來源 |
|---|---|
| Why | commit body 裡的「why」段、PR 描述對話、issue link |
| What | branch commits 的主旨合併 + diff 摘要的 net effect |
| Test Plan | diff 裡新增 / 改動的 test 檔 + 推測的手動驗證 |
| Breaking changes | public API signature 改變、config key 改名、預設值翻轉 |
| Related issues | commit message 裡的 #<n> / Closes #<n> / Refs #<n> |
找不到 signal 不要編造——標記 <待補:...> 留給使用者填,不要 hallucinate。
skill 跑完直接給 caller 兩塊 markdown:
## Suggested PR title
<one line, user-impact>
## Suggested PR description
## Why
...
## What
...
## Test Plan
- ...
## Breaking changes <!-- 若無,整段刪 -->
...
## Related issues <!-- 若無,整段刪 -->
- Closes #...
上面兩塊是 skill 回給 caller 的結構化輸出。caller(/maigo:describe-pr orchestrator)
在印給使用者時,額外再附一份「可整段複製」的 description:
## Suggested PR description 底下的 body 原封放進單一 fenced code block。**Title:** <one line> 給 title,方便一起複製。<待補:...> 佔位符保留讓使用者替換。(skill 本身只負責產 body / title;組裝 copy-paste block 是 caller 的收尾步驟。)
caller 呈現最終 deliverable 給使用者時,遵守 skills/copyable-deliverable——把可複製的內容放進單一 fenced code block。
Verify every PR-state / API-signature / CLI-flag claim against live source before writing —
reference docs go stale silently; use gh pr view, git show HEAD:<path>, or
gh pr diff <n> to confirm. Details and a per-claim-type recipe in
references/verification-discipline.md.
gh pr create 或 GitHub UI)npx claudepluginhub lee-w/maigo --plugin maigoGuides creation, editing, and verification of skills for AI coding agents using test-driven development with subagent scenarios. Use when authoring or debugging skills.