---
name: line-sticker-creator
description: "製作LINE靜態人物貼圖並上傳Creators Market：先詢問想做的貼圖、審核文案動作大綱，一次生成合圖，再經使用者審圖後切割透明PNG、壓縮、打包與上傳；送審前確認販售設定及權利聲明。不用於動態貼圖。"
---

# LINE 貼圖製作與上傳

依「詢問需求 → 大綱審核 → 合圖生成 → 圖片審核 → 切割打包 → 上傳LINE → 確認送審 → 核對狀態」執行。新產物放使用者原專案的 Codex/；保留參考素材、各版提示詞、合圖及審核紀錄。

## 1. 先問使用者想製作什麼貼圖

先問：「這次想做什麼主題、給誰使用的貼圖？」再整合詢問尚缺的必要資料：人物／角色或logo、畫風與主色調、張數、必備文字、禁用或不能重複的內容。已有答案不重問；沒有參考圖可依文字建立角色，但不虛構已讀取的素材。

完整流程包含打包後上傳LINE。若使用者只要求素材或只要包檔，依其範圍停止；終點不清楚時在需求階段釐清。不要在單純討論需求時登入或操作帳號。

問題範例、合理預設及審核表格式見 [intake-and-review.md](references/intake-and-review.md)。以少量問題取得關鍵答案，能用提案補足的選項放到大綱給使用者決定。

## 2. 大綱必須先審核

建立可檢閱的大綱：主題、張數、人物與風格、色調、用語、排序，以及每張的編號／精確文字／表情／動作／道具／構圖。先比對舊貼圖，避免只換文案而沿用舊動作。使用者指定的必備文字可作重複例外，但要明白記錄。

預設將正式、日常實用放前面，網路口吻與玩笑放後面；排序可依當次要求調整。24張可用4欄×6列，其餘張數選擇合適配置，不能把本案24句或奕鈞老師角色套給所有人。

**大綱未取得使用者明確確認，不得生成圖片。**

將大綱和對應的 manifest 保存於 Codex/planning/。有修改則更新版本並供審；自然語言「OK」「確認」「照這個做」可確認目前展示的版本，不強迫特定通關句，也不把沉默當同意。

## 3. 一次生成合圖，然後審圖

先檢視參考圖，分清角色身分參考、畫風參考、避重對照及ZIP格式範例。使用可用的內建影像生成／編修工具，一次生成整張合圖，避免逐張生成拖長時間。工具與尺寸以實際支援為準；不擅自切換付費API或承諾工具未提供的解析度。

使用 [prompt-template.txt](references/prompt-template.txt)，把已核准每格內容與畫風合併為完整提示詞。要求由左至右、由上至下的明確欄列；每格完整分離、格間透明留白；人物、文字、手腳和道具不跨格；不畫編號、格線、水印或棋盤格。請求真正alpha透明背景，保留白襯衫、眼白及白邊。

鎖定使用者參考的外貌、Q版比例、上色、黑字白邊及指定配色。橘黃需求要具體說明金黃、淡黃及橘色的比例，不能擅自改成高飽和橘色。中文字逐字核對，特別注意人名。

合圖與實際提示詞保存於 Codex/images/，展示圖片和可開啟的原圖連結，讓使用者先審核。

**生成圖片後必須等待使用者明確確認；未確認前不得切割、去背、壓縮、打包或上傳LINE。**

修圖時只改指定格位和屬性；保留其餘文案、排序、風格與顏色。使用者已明確指定的局部修正可直接重生修正版，再次交圖審核。若變更張數、主題或新增文案而尚未獲確認，先回大綱階段。每次重生圖都要重新審圖，不能沿用舊版圖片的同意。

將目前大綱與圖片的版本、路徑及確認狀態記在 Codex/planning/workflow-state.json，跨回合接續時讀取；不要因更換聊天回合而重做已確認步驟。

## 4. 審圖通過後，切割、去背與打包

先核對實際alpha。已有透明則保留，不重做去背；沒有透明時使用可用影像編修工具，保護白襯衫、眼白及文字白邊，不以全域刪白或棋盤格冒充透明。

沿用 [package_sheet.py](scripts/package_sheet.py)。一般網格模式需Pillow；輪廓分離另需NumPy與OpenCV。先確認現有依賴，不重複安裝。參數、已驗證接點處理與限制見 [processing.md](references/processing.md)。

```powershell
python -X utf8 "<skill>/scripts/package_sheet.py" "<project>/Codex/images/approved_sheet.png" --manifest "<project>/Codex/planning/approved_manifest.json" --out "<project>/Codex/deliverables/release-v1" --columns 4 --rows 6 --budget 200000 --segment-components
```

每次使用新的輸出資料夾。manifest的items依序包含id（01起）及text；[example-manifest.json](references/example-manifest.json)是本案範例，不是固定文案。

不要假設生圖結果等距。連通圖案缺格、重疊或歧義時先目視定位，再用實圖人工邊界／分離接點；不可從舊圖盲目沿用座標。逐格查看深底及棋盤格預覽，確認文字、肢體、白邊完整、沒有隔壁碎片。

預設每張370×320透明PNG、四邊約10px留白、最多200000 bytes；main.png為240×240，tab.png為96×74。200KB是本使用者的交付目標，不是平台官方上限；當次另有要求則調整。母圖經重採樣時如實記錄實際像素。

ZIP沿用已驗證範例：stickers/資料夾內放01.png至最後一張、main.png、tab.png，不混入說明或預覽。腳本產生validation.json及預覽；核對PNG尺寸、alpha、檔案大小、ZIP路徑／CRC／雜湊。通過自動檢查仍要目視核對內容。

## 5. 上傳LINE與登錄資料

使用 [line-upload.md](references/line-upload.md)。先讀可用瀏覽器工具的文件，核對當前官方規格；瀏覽器頁面及登入步驟以實際畫面為準，不硬編帳號、商品ID或舊價格。由使用者自行完成登入／必要驗證，保留登入頁後接續。

完整流程已獲授權且審圖通過後，完成商品草稿、中英文名稱及說明、適切分類、AI標示、張數設定與ZIP上傳；不再額外要求一次「是否可以上傳」。若使用者本次只授權製圖，不能把審圖同意擴張為上傳授權。

沿用既有創意人名稱，不修改帳號層級資料；如實標示使用AI。含姓名的貼圖依平台要求分類；價格以平台當下選項為準，草稿可先沿用預設，送審前讓使用者確認。不要擅自加入促銷、超值方案、免費試用或創作者合作計畫；把實際地區、公開設定及開始販售方式列給使用者看。

確認平台已收到main、tab及全部貼圖，再檢視繁中預覽。儲存商品ID、後台網址及畫面證據，避免重複建立商品。

## 6. 送審與正式上架

先完成所有可獨立處理的登錄、上傳及檢查，再於實際送審視窗一次列出名稱、張數、價格、地區、AI標示及販售方式。讀取當下「同意事項」，用簡短文字說明權利聲明及已購買者／聊天紀錄的留存影響。

接受具法律效力的同意事項前，依瀏覽器操作規則取得使用者針對該視窗的當下確認；說清楚需要確認是因為會代表使用者接受LINE的權利聲明，不能只問籠統的「繼續嗎」。先前審圖同意不等於法律聲明同意。收到對這次條件的確認後直接勾選並送出，不重複詢問。

送出後確認平台顯示「已提出審核申請」「等待審核」等實際狀態；若進入頁面時已送審，不要再點一次。保存截圖與登錄進度到 Codex/listing/，回報「已送審」，不可寫成「已上架」。

審核通過後才可依已授權的價格、地區及販售方式正式上架；如果使用者只授權上傳或送審，先取得正式販售授權。無法在本回合取得審核結果時，交付商品ID、目前狀態及下一步，不擅自建立監控排程。實際上架後須核對可開啟的LINE STORE商品頁，再回報販售網址。未上架前不捏造商店網址。

## 官方入口

- [靜態貼圖製作準則](https://creator.line.me/zh-hant/guideline/sticker/)
- [使用方法與上架流程](https://creator.line.me/zh-hant/howto/)
- [AI生成商品說明](https://help.line.me/line/smartphone/?contentId=200001248&lang=zh-Hant)
