framework-release

Solid

判定通過之後把東西送出去的那一段:把分支併進 main、壓版號、視目的地同步到 template repo、把本機接回釋出後的狀態。它不判斷該不該出貨——那是 verify-ac 寫在交付紀錄裡的事。 某張單已經judged PASS、交付紀錄寫好了,要真的出貨的時候。例如「出貨吧」 「釋出」「壓版本」「同步到 template」,或剛從 verify-ac 交出來。 也用於:只想先看它打算做什麼(預設就是預覽,不加 --execute 不會動任何東西)。 不用於:還沒有交付紀錄(先走 verify-ac)、判定還沒過(那是 verify-ac 的事)。

AI & Automation 5 stars 0 forks Updated 4 days ago MIT

Install

View on GitHub

Quality Score: 83/100

Stars 20%
26
Recency 20%
100
Frontmatter 20%
70
Documentation 15%
100
Issue Health 10%
80
License 10%
100
Description 5%
100

Skill Content

# framework-release — 釋出尾段 `verify-ac` 判 PASS 之後就結束了。它留下的是一份交付紀錄,不是一句「可以出貨了」。這支 skill 讀那份紀錄,把它變成真的發生的事。 **這裡不做判斷。** 該不該出貨、出什麼、算不算達成,全都在交付紀錄裡由 `verify-ac` 決定。 這支只負責執行,而且執行之前會把那份紀錄再驗一次——紀錄釘��� commit 跟現在的 HEAD 對不上 就停,斷言被動過也停。 ## 先看它打算做什麼 ```bash bash .claude/skills/framework-release/scripts/spine-release.sh --issue {issue} ``` **預設是預覽,不會動任何東西。** 它會印出目的地、判定人、紀錄釘的 commit、現在的 HEAD、 以及接下來每一步打算做什麼。看過了再加 `--execute`。 ```bash bash .claude/skills/framework-release/scripts/spine-release.sh --issue {issue} --execute ``` ## 被打斷了:先問它走到哪 ```bash bash .claude/skills/framework-release/scripts/spine-release.sh --issue {issue} --status ``` **逐項問每一個系統,然後直接重跑 `--execute` 就好。** 每一步在做之前都會先問那個真的擁有 那件事的系統——`git ls-remote` 問 tag、`gh release view` 問 release、`merge-base` 問促進、 template checkout 自己問同步——所以做過的會被跳過,沒做的會被補上。 **沒有進度檔,這是刻意的。** 一份「做到第幾步」的本機紀錄是同一件事的第二個答案,而第一個 答案在 origin、在 GitHub、在 template checkout 上。兩份會漂,而漂掉的那一刻正好是有人被 打斷、最需要一句真話的時候。 問不到的那一項會說它問不到(例如 `gh` 不在、`origin/main` 的物件本機沒有),不會省略、 也不會猜一個——一個安靜的第三態,下一次就會被當成查過了。 ## 尾段做哪幾件事 1. **重驗** —— fence 與交付紀錄都要還成立。任一項不成立就停,這時候還沒有任何東西被送出去。 2. **壓版號** —— 讀 changeset 決定 patch / minor / major。**`.changeset/` 就是版號唯一的 宣告源**,交付紀錄裡沒有這件事也不該有:那份紀錄由可攜層寫,而版號是這條尾段自己的 模型。有 changeset 卻沒壓動的話這是矛盾,不是可以印一行 note 略過的事。 3. **促進 main** —— 找到這條 branch **已經開好**的 PR,過閘之後 fast-forward。不是直接推 main。 **這支不開 PR。** 它 `gh pr list --state open`;開 PR 是 SWE 的 definition of done,屬 `swe-knowledge`——PR 開出來就是實作完成,而這支是完成**之後**的事。 **但「沒有 open PR」有兩種原因,而它們要的下一步相反**:還沒...

Details

Author
HsuanYuLee
Repository
HsuanYuLee/polaris
Created
6 months ago
Last Updated
4 days ago
Language
Shell
License
MIT

Similar Skills

Semantically similar based on skill content — not just same category

AI & Automation Solid

swe-knowledge

軟體工程這一類工作「怎麼算 done」的通識:改動住在一條 branch 上、有一個 PR、判定過才 進預設分支、push 之前本機跑完跑得動的驗證。由 driving-work-to-done 在判定一件工作會改到 程式碼時載入。很少、扁平、不含任何一家公司或一個專案特有的東西。 driving-work-to-done 判定這件工作會改到程式碼、要進版控時載入。 不用於:不會產生程式碼變更的工作(報告、調查、文件、資料分析)——那些沒有這裡的 完成條件,走 `--pack none`。 不用於:某一家公司或某一個專案特有的規則(codecov 門檻、stage 部署流程、ticket 命名)。 那些在各自的公司 pack 裡,見〈跟公司 pack 的關係〉。

5 Updated 4 days ago
HsuanYuLee
AI & Automation Listed

driving-work-to-done

把一件工作從「有人說了一句話」帶到「judged 過的交付」:先判斷要不要立案,再決定現在 該在 refinement / engineering / verify-ac 哪一站、什麼時候換站,載入說明「這類工作怎麼算 done」的知識,然後一路推進到收斂或撞上四種已宣告的停點之一。任何會改變程式碼或行為的 請求都從這裡進,使用者不需要知道這個名字。唯讀的查詢與說明不走這裡。 有人帶著一件要做的事出現時的第一站,不論他有沒有說出任何指令名稱。例如 「幫我做 X」「這個壞了要修」「想重構 Y」「繼續」「接著推」。 也用於:不知道現在在哪、不知道下一步是什麼、手上有多張單不知道先做哪一張。 不用於:唯讀的查詢與說明(「這支腳本在幹嘛」「查一下 X」)——那些沒有「怎麼算成功」 要簽,直接回答。

5 Updated 4 days ago
HsuanYuLee
AI & Automation Listed

check-your-own-work

Before handing your own change over — opening a PR, asking for review, saying "done" — check it against eight questions that come from what reviewers actually caught: claims that do not match the diff, the repo's own rules not applied, half-done pattern changes, runtime behaviour asserted from reading source, last round's comments still unaddressed, assertions that cannot fail, a mechanism you removed whose jobs nobody carried over, and something you added that nothing runs or that this repo has no precedent for. Use when you are about to hand your own work over, or when someone asks you to self-check, double-check, or go over your change before submitting. 交出自己的改動之前——開 PR、找人 review、說「做完了」——先對一次自己寫的東西。 八問來自 review 真的抓到的東西,不是想像出來的清單。 不用於:看別人的 PR(那是 code review,主語是別人的改動)。 不用於:判定某個交付達不達標——這支不判紅、不擋人,它產出一份要被處置的清單。

5 Updated 4 days ago
HsuanYuLee