diff --git a/docs.json b/docs.json
index c44335a27..49cd07b20 100644
--- a/docs.json
+++ b/docs.json
@@ -115,7 +115,8 @@
                             ]
                           },
                           "en/use-dify/publish/publish-mcp",
-                          "en/use-dify/publish/developing-with-apis"
+                          "en/use-dify/publish/developing-with-apis",
+                          "en/use-dify/publish/partner-template-submission-guide"
                         ]
                       },
                       {
@@ -7459,4 +7460,4 @@
       "linkedin": "https://www.linkedin.com/company/langgenius"
     }
   }
-}
+}
\ No newline at end of file
diff --git a/en/use-dify/publish/partner-template-submission-guide.mdx b/en/use-dify/publish/partner-template-submission-guide.mdx
new file mode 100644
index 000000000..19059f8d0
--- /dev/null
+++ b/en/use-dify/publish/partner-template-submission-guide.mdx
@@ -0,0 +1,113 @@
+---
+title: "Partner Template Submission Guide"
+description: "How solution partners collaborate with Dify teams to deliver, validate, and submit marketplace-ready templates"
+icon: "handshake"
+---
+
+This guide defines a standard collaboration workflow between **Dify internal teams** and **solution partners** who co-deliver templates for the Dify Marketplace.
+
+The goal is simple: high-quality templates, faster publication, and predictable review outcomes for everyone.
+
+## Collaboration Model
+
+In this model, both sides contribute:
+
+- **Partner**: contributes domain expertise and template implementation
+- **Dify team**: contributes product alignment, marketplace standards, review, and publication support
+
+A partner deliverable is expected to be a **template-ready Dify app**, not only a plugin, prompt pack, or skill.
+
+## Required Deliverables
+
+Every submission should include two deliverables:
+
+1. **Template implementation package**
+2. **Documentation contribution (PR to docs)**
+
+### 1) Template Implementation Package
+
+Your package must include:
+
+- A runnable Dify app template (any supported app type)
+- English metadata (name, summary, and usage-facing text)
+- A non-generic avatar/icon
+- Template notes that explain:
+  - what this template does
+  - how to use it
+  - what credentials are required and where to obtain them
+
+### 2) Documentation Contribution (PR)
+
+The partner (or sponsoring team) should open a PR in docs to keep collaboration standards transparent and reusable for future partners.
+
+Recommended docs scope:
+
+- Use case and target users
+- Input/output expectations
+- Credential setup requirements
+- Validation evidence
+- Known limitations and support contact
+
+## Validation Requirements Before Submission
+
+Before listing in Marketplace, the template must be validated in **both** environments:
+
+1. **Mega/Beta environment** (for new version capability validation)
+2. **Production environment** (for listing readiness)
+
+Submission is considered incomplete if it only passes in one environment.
+
+<Check>
+Run the template end-to-end at least once in each environment before review.
+</Check>
+
+## Template Notes Standard (What Reviewers Expect)
+
+Use this minimum structure in template notes:
+
+### A. Purpose
+
+- What problem is solved?
+- Who is the target user?
+
+### B. How to Use
+
+- Required inputs
+- Typical execution flow
+- Expected outputs
+
+### C. Credentials
+
+- Which credentials are required
+- Where to obtain each credential
+- Any required permission scopes
+
+### D. Limitations
+
+- Unsupported scenarios
+- Cost/performance caveats
+
+## Suggested Review Checklist
+
+Use this checklist before requesting final review:
+
+- [ ] Template runs successfully in Mega/Beta
+- [ ] Template runs successfully in Production
+- [ ] All user-facing metadata is in English
+- [ ] Notes include purpose, usage, and credentials
+- [ ] Avatar/icon is recognizable and not placeholder-like
+- [ ] No broken nodes, missing variables, or unresolved credentials
+- [ ] README/Docs PR prepared for long-term maintenance
+
+## Why This Process Exists
+
+A shared submission standard helps:
+
+- reduce review cycles
+- prevent environment-specific breakage
+- improve user onboarding quality in Marketplace
+- make partner collaboration scalable across industries
+
+<Tip>
+Treat templates as long-term products, not one-off demos. Good notes and reproducible validation are part of the deliverable.
+</Tip>