STORE.md 慣例把這些內容全部放進專案根目錄下一個納入版本控制的檔案，重新提交時不必再從頭整理。
這個檔案還有第二個用途。支援該慣例的部署工具會在提交時讀取它，並附上各商店 API 接受的欄位。其餘內容則作為商店後台表單的複製貼上參考。
結構
每個商店一個## 小節，共享材料放在商店小節之上。商店小節按標題文字比對，因此 ## Firefox Add-ons、## firefox-amo 和 ## AMO 都有效；Chrome 與 Edge 同理。
各商店讀取什麼
Firefox 與 Edge 的提交 API 接受面向審查者的備註，支援STORE.md 的工具可以替你送出：
Chrome Web Store 的 API 不接受任何商店頁中繼資料，因此整個 Chrome 小節是開發者後台的參考材料。它的結構與 agent 工具在
CHROMEWEBSTORE.md 檔案中期望的小節一致，尋找那些小節的 agent 在這裡就能找到。
每個範本都自帶起步檔案
每個 Extension.js 範本都附帶一個由自身 manifest 產生的起步STORE.md。權限說明已經與範本請求的權限一一對應，佔位行標註為 TODO。從任何範本建立專案，這個慣例從第一次提交起就已就位：
保持內容最新
在讓它過期的同一個改動裡更新STORE.md：
- manifest 變了（
permissions、host_permissions、content_scripts）：重新檢查每條權限說明。每個權限都需要具體、直白的理由。「擴充功能運作需要」在每個商店都過不了審。 - 使用者可見行為變了：更新商店文案並刷新最後更新日期。
- 發佈新版本：追加版本歷史條目並重寫版本說明。
- 資料處理變了：同時更新隱私小節、它連結的隱私權政策，以及 manifest 中 Firefox 的
data_collection_permissions宣告。三者必須一致。必填的 manifest 鍵參見 Firefox 商店審核的資料收集權限。 - 被商店拒絕：在版本歷史中記錄原因與修復方式，下次提交不再重蹈覆轍。
衛生守則
- 把檔案納入 git。它是專案的一部分，不是草稿。
- 別把它打進擴充功能 zip。正式建置只打包
dist/<browser>/，根目錄的STORE.md永遠不會隨擴充功能發佈。 - 絕不放真實使用者憑證。審查用測試帳號從設計上就應該是一次性的。