Submitting for review
Two things get checked, for two different reasons
A submission is reviewed along two lines that do not substitute for each other:
| What it looks at | Who it protects | |
|---|---|---|
| Your template's contents | The pages that land on a buyer's site | The buyer |
| Your repository | Your source: dependencies, known vulnerabilities | You, and the buyer |
A clean repository says nothing about whether the template is safe to install, and a clean template says nothing about a compromised dependency in your toolchain. Both run every time.
What you provide
The listing details — name, summary, description, industry, license, and which CSS framework the design targets. These are what a buyer reads before deciding.
A GitHub repository containing the full source. This is required, not optional. Review reads it, and it means neither you nor your buyers can be locked out of work they depend on later. It is never shipped to buyers — they receive the installable template, not your working files.
Give the repository's own HTTPS URL, not a link to a branch or a file. And never paste a
URL with a token in it (https://user:token@github.com/…) — that is rejected rather than
quietly cleaned, because stripping it would teach the habit.
A commit SHA, optionally but worth doing. It pins review to exactly what you submitted, so a later force-push is visible rather than silent.
A support contact — a person on your team, plus the name and email a buyer sees. The
person is who is accountable; the name and email are published, so a shared address like
support@yourstudio.com is usually better than a personal inbox.
What the automated checks look at
On your template's contents:
- every block is one of the platform's own
- images and files are ones you uploaded, not links to another host
- no external stylesheet imports, and no tracking references hidden in styles or data
- connected blocks arrive unbound, ready to attach to the buyer
- a trial install, to confirm it lands cleanly on a real site
On your repository:
- dependencies checked against known-malicious package intelligence
- dependency and static analysis for known vulnerabilities
- critical and high-severity findings must be fixed before review. Lower-severity ones are passed to the reviewer alongside your submission rather than blocking it
Nothing is approved automatically
The best an automated run can reach is ready for review. There is no path to "published" without a person.
What the automation is for is not approving things — it is making sure a reviewer never opens a submission that could not have passed, and that you find out about a problem while you are still looking at the thing you built.
A blocking failure means the submission stops and comes back to you with the specific list. It is not a rejection of the template; it is the parts to fix.
Before the repository scan has run, its checks report as skipped rather than passed. A scan that has not happened is never counted as a clean one.
While you wait
Your draft stays private the whole time. You can keep editing it — though edits after submission start a new version, because the thing a reviewer looked at should not change underneath them.