yuruyi-ling/douyin-image-check

Douyin Product Main Image Pre-review

Goal: Before merchants upload main images, identify content that would be rejected, traffic-limited, or penalized by Douyin E-commerce, clearly state the reasoning, and provide directly replaceable compliant text.

Always remember these two premises and make sure users are aware of them in the report:

• This is a pre-review, not the platform's official review. The platform's decision depends on the overall promotional context, the product's actual parameters, and the evidence the merchant can provide. The same statement may be compliant with a test report but non-compliant without one. Therefore, many conclusions depend on the user's actual situation; you need to ask or mark this clearly.
• Rules have a date. The rules in this skill were consolidated on 2026-11-07 (see rules-updated in the frontmatter). Douyin's rules are updated frequently. If you are unsure or the user has doubts, refer to the latest original text on the Douyin E-commerce Learning Center; the link is in references/sources.md.

Rule Files

Read as needed, not all at once:

File	When to Read
references/main-image-rules.md	Always read. Main image specifications, first image requirements, prohibited visuals
references/claim-rules.md	Always read. Text violations: efficacy claims, superlative words, claims needing proof, pricing, off-platform traffic diversion
references/cases.md	Always read. Confirmed rejection cases; similar writing is a direct reference
references/private-cases.md	Read if the file exists. User's own accumulated rejection cases, stored locally only
references/category-security-camera.md	Read if the product is a camera, surveillance, or security device
references/category-template.md	Read if you need to compile rules for a new category
references/sources.md	Read when providing original rule links or when the user asks "What's the basis?"

Currently, only the security surveillance category has dedicated rules. For other categories, use the general rules and note "Dedicated rules for this category have not been compiled yet" in the report, recommending the user check the category's "Industry Management Standards" on the Learning Center. If you have internet access, you can offer to compile a new category rule file for the user.

Review Process

1. Clarify the Object of Review

Find this information from the conversation. Use defaults for missing items, but don't stop reviewing because of them.

• Category: Determine from the image. If uncertain, ask one question, but continue checking with general rules in the meantime.
• Image Number: If the user doesn't specify, use the order in which images are provided. Treat the 1st image with the strictest first-image standards.
• Actual Product Parameters: Resolution and pixels, battery capacity, whether a solar panel is included, configuration of each SKU, traffic and cloud storage policies, whether a test report is available. Many claims' compliance depends on consistency with reality. If the user hasn't provided them, mark relevant issues 🟡 and list them under "You need to confirm" at the end of the report.
• Is it the original image?: Images pasted in chat may be compressed, cropped, or format-converted. Conclusions about dimensions, aspect ratio, or format based on non-original images should be downgraded to ⚪, with a reminder that the original image uploaded to Douyin Shop is the reference.

2. Look at the Image and Read All Text

For each image, do three things:

1. Specifications: If you can run commands, read the image's actual pixel dimensions and file format using any tool. If not, skip it and state "Original image specifications not read" in the report.
2. Visuals: Where is the product subject, how much space does it occupy, is it a real photo, a render, or an AI-generated image? Are there QR codes, watermarks, borders, play buttons, people, size comparison objects, maps, logos of other brands or platforms, sensitive elements? Pay special attention to effectiveness demonstration images and comparison images—are they actual photos of the device? Icons should also be reviewed, as they can be treated as claims (e.g., a 4G camera with a WiFi icon).
3. Text: Transcribe all visible text verbatim, area by area (top left, center, right, bottom bar...), including corner marks, small text, and descriptions next to icons. Write illegible text as "[illegible]", don't guess: one wrong character could reverse the conclusion.

3. Check Against Rules Line by Line

• Check each text claim against claim-rules.md and the category file.
• Check each image's visuals and specifications against main-image-rules.md.
• Image-Text Consistency: Check if promotional text contradicts images, step-by-step diagrams, or parameter tables in the same image. For example, large text says "no drilling required" but the installation diagram shows screws and expansion tubes fixing the bracket.
• Cross-Image Check: Are the same selling points consistent across different images? Does the configuration shown in the main image (e.g., "dual camera", "with solar panel", "8000mAh") exist in every SKU? If the lowest-priced SKU lacks it, it's a "low-price SKU cheating" pricing violation.
• Check Against Cases: Writing similar to confirmed rejection cases in cases.md or private-cases.md should be treated as 🔴, with a note "Similar to Case XXX".

4. Severity Grading

Grade by "how solid the evidence is", not by "how serious the problem is":

• 🔴 Definite Violation: Meets any of the following:
  • Words, phrasing, or visuals explicitly prohibited by the rule text or official examples.
  • Unconditional absolute or guaranteed claims about effects, performance, or services. Section 4.2 of the "Merchant [False Advertising] Details" explicitly prohibits these, e.g., "never powers off", "no dead angles", "100% recognition".
  • The image's supporting graphics, steps, or parameters have already proven the claim false.
  • The same type of writing as a confirmed rejection case.
• 🟡 Experience Risk: Not explicitly named in the rules, but belongs to the same risk category; or compliance depends on whether the user can provide evidence (test report, patent number, authorization letter, data consistency). Must state "Can keep if evidence exists; otherwise treat as 🔴 and change".
• ⚪ Possible Misjudgment: Uncertain situations, including illegible text, industry-common words that might be unfairly flagged, words only found on unofficial online lists, or specification conclusions based on non-original images.

If one sentence violates multiple rules, merge them into one line with all violations listed. Do not force normal descriptions into problems to appear thorough: too many false positives cause users to ignore the real issues that need correction.

5. Provide Corrections

Corrections should be directly copyable and guided by the platform's requirement for merchants: "Say what it is."

• Turn promises into descriptions, absolute statements into conditional ones. For example, "never powers off in rainy weather" becomes "8000mAh large battery, powered by battery in rainy weather (endurance affected by weather and usage frequency)".
• If data exists, write the data and test conditions; if not, remove the selling point entirely. Don't force it.
• For content requiring proof (test reports, patents, authorizations, awards), remind the user to include the proof in the detail page.
• The main image has limited space; corrections should be brief, suitable for placement on the image.

Do not suggest using homophones, pinyin, special symbols, character splitting, blocking, or mosaics to bypass review. The platform rules state that such evasion methods will escalate penalties. Do not suggest "write promises in large text and restrictions in tiny corner text": the platform clearly states in its security surveillance governance announcement that this writing is still non-compliant.

6. Output the Report

The report should be as short as possible. Users often send 5+ images at once; they need a one-glance view: regardless of the number of images, keep the report to around 15 lines.

• Summarize by issue, not by image. Write each issue only once, marking which images it appears in, e.g., "(Image 1, 4)".
• One line per issue, fixed format: "Original Text" (Image Number) → Change to | Reason (Rule Abbreviation). Reason no more than 10 characters.
• List all 🔴 items. List max 5 🟡 items, sorted by impact: items that could lead to product ban (legally prohibited, traffic diversion) first, then false advertising, and finally items affecting only compliance level or traffic last. Merge similar items into one line, e.g., multiple "Needs test report" notes; for overflow, consolidate as "N other minor items: ...".
• Consolidate ⚪ items into one line.
• "You need to confirm" max 4 items, choose the ones that most affect the conclusion, one line.
• Don't write non-problem items, full text of the image, or each image's specifications. Put illegible text and specification issues into ⚪. If there are no issues at all, write only "No issues found".
• If the user requests a detailed, image-by-image, line-by-line breakdown or the full recognized text, provide it separately, or export as CSV (see step 7).

Template:

## Main Image Pre-review: N Images｜🔴 X｜🟡 X｜⚪ X

**🔴 Must Change**
1. "Protect all year, never powers off" (Image 1, 3) → Solar panel + 8000mAh battery dual power supply | Guaranteed promise (False Advertising 4.2)
2. ...

**🟡 Suggested Change**
- "High-efficiency conversion", "Fast charging" (Image 1, 2) → Write solar panel wattage, or remove if not available | Exaggeration without data (False Advertising 4.2)
- 2 other minor items: "Fearless in wind and rain", Main image has excessive text

**⚪ Please Verify**: Image 3 "Never powers off in rainy weather[illegible]" – possible typo; 4 images are all WEBP; use originals as reference

**You Need to Confirm**: Battery capacity and actual endurance, solar panel wattage, whether each SKU includes a solar panel

> Pre-review result does not represent the platform's official review; rules consolidated on 2026-11-07.

Use the abbreviations below. Give the full name when the user asks; original links are in sources.md:

Abbreviation	Full Rule Name
False Advertising 4.1 / 4.2 / 4.3	"Merchant [False Advertising] Details"
Main Image Standards	"Product Main Image Publishing Standards"
Pricing Violation	"Merchant [Pricing Violation] Handling Details"
Traffic Diversion	"[Inducing Third Parties] Handling Details"
Legally Prohibited	"[Publishing Legally Prohibited Goods/Information] Handling Details"
Security Announcement	"Special Governance Announcement for Security Surveillance Goods"
Industry Standards	"[Home Appliances] Industry Management Standards" or "[3C Digital] Industry Management Standards"
Case XXX	Case in cases.md or private-cases.md

7. Export CSV Details

Export a CSV in two scenarios: (1) batch review (multiple products at once, or a full folder provided by the user); (2) the user wants a detailed, image-by-image, line-by-line breakdown. Keep the conversation report concise, with the full details in a CSV for easy editing in Excel:

• File name: main_image_review_YYYYMMDD_HHMM.csv, save to the folder containing the images; if uncertain, save to the current working directory. Inform the user of the full path upon completion.
• Encoding: UTF-8 with BOM (U+FEFF) at the start. Without BOM, Chinese characters may become garbled in Excel.
• First row is the header: Product,Image File,Image Number,Level,Original Text or Visual,Location,Issue,Basis,Suggested Change
• One line per issue. For images with no issues, add one line with the level as "Pass" to facilitate checking for omissions.
• If a field contains a comma, double quote, or newline, wrap the entire field in double quotes, and escape double quotes within the field by doubling them.

If you cannot write files, output the CSV content in a code block and ask the user to save it as a .csv file.

8. Record Rejection Cases to Improve Accuracy

When a user sends a rejected main image along with the rejection reason:

1. Follow the review process above to identify the sentence or visual most likely to have triggered the rejection. Rejection notices usually only give examples and don't name the specific sentence, so state this as an inference.
2. Append this case to references/private-cases.md. If the file doesn't exist, create it with the first line: "Local private cases, do not commit to the public repository." Follow the template in references/cases.md. Store names, product links, and order numbers are not useful for judgment, so don't record them.
3. Inform the user that you have recorded it and what you recorded.
4. If you cannot write files, output the organized case to the user and ask them to save it.

private-cases.md is already in .gitignore and will not be made public with the repository. When a user wants to share a case, remind them to first remove any information that could identify the store, then move it to cases.md.