fab-unreal-publishing

Fab Unreal publishing

Use this skill for Fab listings that sell or distribute Unreal Engine tools and plugins. Keep advice grounded in the product's real behavior and in current Fab requirements. No listing or media treatment guarantees sales or Fab approval.

Responsibilities

• This skill owns Fab-specific listing, media, and submission guidance.
• skill-release-publish owns general release and publication practices. Keep Fab-specific guidance here.
• agent-rules owns the short Human Approval invariants that apply across agent work.
• fab-plugin-release-tools owns package, technical validation, capture, media review manifest, approval artifact, and portal automation mechanics. Read its current README and use its commands; do not copy its implementation or replace its product-specific metadata.
• Each product repository owns its listing metadata, media, package configuration, and approval record.

Workflow

1. Identify the product repository and its supported Unreal versions, actual capabilities, demo project, documentation, support path, and current listing state. Treat its metadata and built product as the factual source of truth.
2. Check the current Fab publishing guidance and the release-tools README for current listing fields, media constraints, pricing and submission requirements. Portal labels and requirements can change; verify them at the time of work.
3. For Tools & Plugins, verify thorough documentation against current Fab requirements. If the product has demonstrable elements such as UI, operations, search, or generated results, explicitly decide whether reviewer/customer-accessible demo or example files are required. A private or internal test project alone does not satisfy distributed-demo needs. A required Quick Start must state a concrete starting state, exact action or input, expected visible result, and success condition. When a demo is required, verify its delivery matches the release-tools testProject distribution contract. In the listing, briefly explain what the demo is, how it relates to the product, whether it contains the product binary, how to try it, and where Quick Start is. Derive those facts from the actual product and distribution contract; do not force one fixed description on every product. For a plugin distributed with a small example project, explain that the plugin is the product and the Additional File is a known-test-asset example project. Do not report readiness until documentation, demo need, distribution, and Quick Start are verified.
4. Shape the listing around the buyer's task and outcome. Keep product name, included functionality, compatibility, license, price, documentation, support, and media consistent. State exclusions and dependencies plainly. Do not claim features or included content that the product does not provide.
5. When the goal includes sales, revenue, conversion, discoverability, click-through, pricing, or competitive positioning, read references/sales-optimization.md and references/evidence.md, inspect current Fab alternatives, and complete the independent SALES_OPTIMIZATION_REVIEW before Human Approval. A pre-launch PASS is a best-supported hypothesis under current evidence and market context, not proof of higher sales.
6. Design and review the thumbnail and gallery against references/media-design.md. Read references/evidence.md when explaining or revising design standards, and re-check linked sources when requirements may have changed.
7. Keep technical validation, media-design review, sales-optimization review, and Human Approval separate. Any AI review is advisory and is not a formal gate. Before recording or acting on approval, follow references/human-approval.md and the cross-agent invariants in agent-rules.
8. Use fab-plugin-release-tools for supported packaging, validation, media review, preparation, and portal operations. Inspect its current README and command help before invoking it. Do not recreate its validators, schemas, manifests, media-capture pipeline, or portal automation in this skill.
9. Keep readiness states separate: generated artifacts ready, Portal inputs ready, Portal values directly verified, human Preview acceptance, ready to submit, and submitted. Canonical artifact correctness does not prove Portal consistency. For Technical Information, compare canonical values item by item; stale or missing canonical values block, while extra Portal-only values are reported without an automatic failure. Treat human or Computer Use Preview checks as UNKNOWN until evidence exists.
10. In Edit / pre-submit, edit, upload, save or wait for autosave, reload, inspect Preview, and validate. Additional Files use Add new format → Additional files; Media Gallery (Images, 3D models, Videos) is a different feature. Bind a visible row to the expected upload using its Additional Files section context, completed upload evidence, expected size, verified local source hash, and the Portal-displayed filename recorded after upload. Permit case/punctuation normalization such as Demo_UE5.8.zip → demo_ue58.zip, but do not accept an unrelated name such as old_demo.zip merely because its size matches. A same-size row alone cannot prove which upload created it. Prefer exact Portal byte metadata; if only rounded units are visible, use the compatible byte interval without claiming an exact Portal byte count. Missing size or ambiguous row identity is UNKNOWN; role or size contradictions fail closed. For release-tools pre-submit, record each completed upload in FabPortalUploadEvidence.json bound to the listing, manifest SHA-256, local file hash/size, and Portal-displayed filename. Never claim Fab-side hash verification without an observed Portal hash.
11. Check Description structure in the rendered Portal Preview, not only canonical text or editor state: paragraphs, unordered and ordered lists, query examples, headings, and links must remain distinguishable and correct. A collapsed continuous line fails. Tight heading/paragraph spacing controlled by Fab styling is a platform limitation when the structure and content remain intact; it is not a submission blocker. Do not add repeated line breaks, spaces, or blank lines to override platform typography.
12. Treat Submit for review, final submission confirmation, publication-mode selection that commits the submission, and manual Publish / Activate as consequential actions. Automatic activation (current UI label: Automatic publication) is selected in the submission flow after Submit for review, not in the normal Listing editor. Do not fail pre-submit because the control is absent there. After Automatic publication is selected, do not also manually Publish or Activate. If the user explicitly says to submit, continue through the submission flow and verify post-submission status; if the UI differs from the expected flow, stop without guessing.
13. Before submission, confirm the product package and listing metadata agree, all required fields and links are complete, media is current and approved, and the Portal Preview communicates the actual offer. Report readiness only for states directly verified.
14. After publication, open the live Fab listing and verify the published name, price, media order, description, supported versions, documentation/support links, and available product files. Report any difference from the approved submission.

Reference routing

• Read references/media-design.md for any thumbnail, gallery, caption, or video design or review.
• Read references/sales-optimization.md for sales, revenue, conversion, discoverability, click-through, pricing, or competitive-positioning goals.
• Read references/evidence.md when grounding a design choice, updating the standard, or distinguishing direct evidence from operational choices.
• Read references/human-approval.md before any media approval is recorded, approval flag is used, or approval-bound media changes.