STORE.md 慣例把這些內容全部放進專案根目錄下一個納入版本控制的檔案，重新提交時不必再從頭整理。
這個檔案還有第二個用途。支援該慣例的商店工具會在提交時讀取它：extension.dev 的 MCP 工具 extension_submit sync-listing 依據它填寫 Chrome Web Store、Firefox Add-ons、Edge Add-ons 和 Mac App Store 的商店資訊，它的商店預檢也會檢查這個檔案。只能在商店自己後台填寫的內容（Chrome 的宣傳圖塊與資料使用答卷，Edge 的標誌、圖塊和屬性，Apple 的 App 隱私權與年齡分級）仍需手動完成，檔案會在各商店小節下列出這些項目，讓你一次看到完整清單，而不是每失敗一項檢查才發現一項。
extension.dev 是 Extension.js 的贊助者，可以在同一個專案裡完成發佈、商店提交和分享。它的文件涵蓋
extension build 之後的步驟。什麼時候建立它
在第一次提交之前、也就是剛出現發佈意圖的那一刻，就寫好STORE.md。提交工具讀取這個檔案時是靜默的：檔案不存在時，提交會在沒有審查備註、版本說明和認證備註的情況下送出，而且不會有任何警告。這個檔案的價值在於隨著程式碼變化持續維護，而不是最後關頭匆忙補寫。圍繞它的完整提交流程請參閱發佈到瀏覽器商店。
結構
共用材料在前（先## Listing，再 ## Privacy and data use），接著每個商店一個 ## 小節，最後是 ## Version history。商店小節依標題文字比對，因此 ## Firefox Add-ons、## firefox-amo 和 ## AMO 都有效。Chrome、Edge 和 Safari（## Safari (Mac App Store)）同理。
每一行都遵循三條讀取規則：
- 仍以
TODO開頭的值會被略過，不會送出。檔案只呈現缺少什麼，從不編造商店文案。 - 清單項目只有在續行保持縮排時才會帶上這些續行。從第 0 欄開始的段落會結束該清單項目。
- HTML 註解寫明每個欄位的格式和上限，讀取工具會把它們去掉。
Listing
每一行都來自一次失敗的檢查或一次商店拒絕，所以每一行都有固定格式。Privacy and data use
- Privacy policy URL:只寫在這裡。讀取工具會取這一行中第一個 http 或 https 地址，所以不要在TODO裡留範例地址。Apple 要求每個 App 都有隱私權政策，Chrome 和 Edge 在處理任何資料時也要求提供。- Data collected:列出擴充功能收集、儲存或傳送的每一類資料，或寫none。Chrome（資料使用核取方塊和三項認證）、Edge（九個資料類別和三項認證）以及 Apple（App 隱私權，「未收集資料」）都會在各自後台再問一次同樣的問題，這一行就是答卷。- Firefox data collection:對應 manifest 中的browser_specific_settings.gecko.data_collection_permissions。AMO 讀取的是 manifest，所以兩者必須一致。必填鍵請參閱 Firefox 商店審核的資料收集權限。
商店小節
Chrome Web Store
### Single purpose：一句話，最多 1,000 個字元。### Permissions justification：manifest 要求的每個權限、主機權限和內容腳本比對各寫一個清單項目。冒號前是權限，冒號後是理由，仍以TODO開頭的理由不會送出。單獨一行寫明遠端程式碼的回答（Remote code: none）。Edge 的隱私權頁面會逐項問同樣的問題，並接受同樣的文字。### Test instructions：審查者要執行的步驟，需要登入時附上測試帳號。
Firefox Add-ons
### Reviewer notes：先寫測試步驟，再寫審查者重新建置所用的確切工具鏈：Node 和 npm 版本、安裝與建置指令，以及輸出資料夾。對於打包過的擴充功能，Mozilla 需要可重現的建置。開啟 Firefox 原始碼封存設定後，平台會附上建置所在提交的儲存庫，因此不需要另外上傳原始碼 zip。### Release notes：這個版本真實的說明。指向其他小節的文字會原樣到達 AMO。
Edge Add-ons
### Certification notes：認證團隊測試擴充功能所需的內容。大多數情況下 Firefox 審查備註同樣適用：直接貼上，而不是寫一句指向它。- 擴充功能套件裡不能有任何壓縮檔。Partner Center 會拒絕套件內的任何
.gz、.zip或其他封存檔，所以這類資源要以未壓縮形式放入。 ### Dashboard checklist：發佈 API 無法設定、需要在 Partner Center 填寫一次的內容：300x300 商店標誌、440x280 和 1400x560 宣傳圖塊、屬性頁上關於個人資訊和成人內容的回答、隱私權頁上的類別與認證，以及選用的 YouTube URL。
Safari (Mac App Store)
- Bundle identifier:在第一個建置到達 App Store Connect 後就不能再改。- Review contact name:、- Review contact email:和- Review contact phone:是 App 審查的聯絡人。### Reviewer notes：如何在 Safari 設定裡啟用擴充功能，以及測試帳號。### Release notes：即「新功能」，從第二個版本起必填。### Age rating：每個問題一個清單項目，除非另有說明都寫none。Apple 的問卷還會問家長監護、年齡驗證、不受限制的網頁存取、使用者產生的內容、社群媒體、訊息、廣告和戰利品箱，推送時會送出完整的一組回答。- App 隱私權，以及目前的年齡分級和全部 175 個地區的上架範圍，都要在 App Store Connect 裡手動確認。
- 在本機執行轉換後的 App：
npx extension build --browser safari --bundle-id <id> --development-team <TEAM>。沒有團隊的臨時簽署建置在 Safari 重新啟動後就不再回應。
Version history
每個版本、每次商店提交寫一行，附上結果，最新的在最前面：0.1.0: Chrome draft uploaded 2026-10-21, AMO upload refused 401 bad key pair, Edge draft pending。商店拒絕及其修正也寫在這裡，下次提交就不會重蹈覆轍。
每個商店讀取什麼
sync-listing 把下列欄位送給各商店，並回答哪些有變化、商店資訊還缺什麼。超出上限或格式不符合商店要求（地址、http 或 https URL）的欄位，會連同需要修改的 STORE.md 行一起指出。
推送到 Safari 時還會從 Safari 小節讀取副標題、Bundle 識別碼、審查聯絡人、版本說明和年齡分級清單項目。Chrome Web Store 小節與代理工具期望在
CHROMEWEBSTORE.md 檔案裡找到的小節一致，所以尋找這些小節的代理可以在這裡找到它們。
範本中的初始檔案
每個 Extension.js 範本都附有一個依據自身 manifest 產生的初始STORE.md：每個權限、主機權限和內容腳本比對各有一個 TODO reason 清單項目，Firefox 資料收集行從 manifest 讀取，其餘事實都標為 TODO。extension create 會把專案名稱寫到 Name 行，把建立日期寫到 Last updated:。從範本建立專案，第一個提交裡就已具備這套慣例：
保持最新
在讓STORE.md 過時的同一次變更裡更新它：
- manifest 變了（
permissions、host_permissions、content_scripts）：為每一項新增或重新檢視說明清單項目。每個權限都需要一個具體、直白的理由。「擴充功能運作所需」在所有商店都過不了審查。 - 面向使用者的行為變了：更新商店文案和螢幕截圖。
- 新版本：新增一行版本歷史，並重寫 Firefox 和 App Store 的版本說明。
- 資料處理方式變了：同時更新隱私小節、它連結的政策，以及 manifest 中 Firefox 的
data_collection_permissions宣告。三者必須一致。 - 商店拒絕：在版本歷史裡記下原因和修正，下次提交就不會重蹈覆轍。
衛生習慣
- 用 git 追蹤這個檔案。它是專案的一部分，不是草稿。
- 不要把它打包進擴充功能 zip。正式建置只打包
dist/<browser>/，所以根目錄下的STORE.md永遠不會送到使用者手上。 - 永遠不要在裡面放真實使用者的憑證。審查用的測試帳號本來就是拋棄式的。