[JIA-ss]

Plugin Submission

Plugin information

• Author: apixly-ai
• Plugin name: apixly_creative (Apixly Creative Controls)
• Version: 0.1.0
• Source repository: https://github.com/apixly-ai/dify-apixly-creative/tree/2ee886030bdfd47874d31ad885527357ae5a1b17
• Contact: support@apixly.ai

Submission type

• New plugin
• Version update

What changed

Five deterministic tools format viewpoint, lighting and camera-look instructions: three small control cards, Compose prompt and the compatibility formatter. Original Studio presets and eight inline lighting swatches are reused inside Dify's native widgets. Groups default off, preserving the base prompt exactly. Failed/malformed settings stop composition; edit mode adds its preservation instruction once.

This formatter stands alone without any Apixly API/auth dependency and can feed a user's generation tool. The optional Media workflows use a separately installed authenticated plugin. It does not duplicate Media's API/auth behavior. This PR adds only apixly-ai/apixly_creative/apixly_creative-0.1.0.difypkg.

Risk level

• Low risk
• Medium risk
• High risk

Required checks

• I have read and followed the Marketplace submission requirements.
• I have read and comply with the Plugin Marketplace Agreement and current Development/Privacy Guidelines.
• I tested this plugin on Dify Community Edition and Dify Cloud, or documented any limitation below.
• The package contains only files needed at runtime.
• The package does not contain secrets, local credentials, .env files, .git directories, virtual environments, caches, logs, or IDE files.
• The package does not contain executables or bundled binaries.
• The README includes setup, usage, required APIs/credentials, connection requirements and source links.
• The package includes PRIVACY.md, referenced by manifest.yaml.
• User-facing text is primarily English, with a localized Chinese README.

Security and privacy notes

No Apixly account, API key, OAuth client, external API/model request, independent telemetry, credential storage, file write, database action or code evaluation is required. Prompts and settings are processed inside Dify's plugin/workflow runtime; workspace operators control their own retained inputs and outputs. A later connected generation tool has its own credentials, billing and privacy policy. Camera/light directions do not promise physical simulation.

Local validation

• Exact package: 50322 bytes; ZIP SHA256 a012c717b5584c98a5c3238c5a676788a17dfac69735239334aeb5db58d55d04.
• Dify content checksum: ae48835fc3312d9cda51966d1a70e8987df37a82b4934070963ae2657b27e12e.
• Source: 2ee886030bdfd47874d31ad885527357ae5a1b17.
• Official CLI 0.6.11 / SDK 0.10.2 / Toolkit 57a21d1304b1108df3e6b90a15a4f5dd9f0915f9: online package validation passed with no blocking or execution failure. Pinned dependency lookup is not a complete transitive audit.
• Complete 29-test companion suite passed before documentation changes. Final package Python, YAML, dependency, icon and privacy bytes are identical to the qualified five-tool runtime. Shared compiler checks include 169 valid / 24 invalid fixtures and 1,000 source-language differential cases.

Reviewer notes

On unmodified official Community 1.17.1, the five-tool plugin was independently installed without credentials and then coexisted with 5 media tools. Twelve combined example DSLs imported; 53 native editor panels retained parameter types/values and variable bindings. Seven actual workflow-engine controlled-input cases checked canonical composition and failure guards. All eight swatches decoded; a native Lens selection could be cleared to Unspecified. The free preview was actually published and run on desktop and 375px with byte-exact output. The final installed package again passed a whitespace/non-BMP free sanity run without inference.

QA and screenshot provenance separate free formatting, optional authenticated media results and host limits. Screenshots use owned QA content. Public source and README images are provided; no private job IDs, signed URLs or credentials are included.

Dify Cloud installation was not verified because normal login security verification could not be completed. Other versions are unverified. Dify's workflow editor is desktop-oriented at 375px, and its running-page Run button is 32px high. Viewport checks do not establish iOS/touch/soft-keyboard support. Marketplace approval is a separate review.

[JIA-ss]

The blocking PR-body check from run 39984593306 is fixed. I restored the exact template formatting (- **Author**:, - **Plugin name**:, - **Version**:, - **Source repository**:, - **Contact**:); the current official toolkit.checks.pr.body.validate_pr_body now returns zero errors. Only these five label formats changed. The head commit and submitted package bytes are unchanged.

The same official run completed the plugin installation test and packaging check successfully. Its security scan reported zero network domains, zero capability categories and zero dependency vulnerability findings. This remains an independent, deterministic five-tool formatter without account credentials or inference requests. Real Community 1.17.1 workflow results and the Dify Cloud verification limitation are documented in the PR body and QA evidence.

After this correction, one author-owned Draft → Ready transition on this existing PR created the next official pre-check run 40057796069. Its current status is action_required, with zero jobs executed, awaiting a maintainer's approval to run the fork workflow. No commit, package or review approval changed. Could a maintainer approve that workflow and continue the submission review when available? Thank you.

[crazywoola]

Hi @JIA-ss, thanks for submitting apixly-ai/apixly_creative 0.1.0!

I'm closing this PR as part of triage for the failing pre-check-plugin CI run, which reported:

• PR body: "Plugin information" is missing fields: Author, Plugin name, Version, Source repository, Contact

Run: pre-check-plugin #39984593306

Note: you updated the PR description after this run and those fields now look correctly formatted, but the check has not re-run because the head commit is unchanged, so the failing run still stands. If the PR body was the only blocker, you can reopen this PR and ask a maintainer to re-run pre-check-plugin; otherwise push a fix and reopen. See the plugin submission requirements. Thanks for the contribution!

[JIA-ss]

Thanks for the triage guidance. The five PR metadata labels are now correctly formatted, as your note confirms. The submitted package and head 973f4fef87ec6a38b2b96e2238d7e9691680d071 are unchanged.

I attempted to reopen this existing PR using both the normal GitHub REST API and the official gh pr reopen command. GitHub rejected them with 422 Validation Failed (empty error list) and Could not open the pull request (reopenPullRequest). The source branch still exists at the original commit, and the PR is unmerged.

The newer official pre-check run 40057796069 now reports failure with zero jobs; it has not executed plugin validation. Could a maintainer please reopen this PR and rerun pre-check-plugin against the corrected description, approving fork-workflow execution if prompted? Thank you.