Use the concept and exact hook already approved in this conversation. If either required choice is absent, ask for it. Read the actual resource, current claim ledger, calibration card and portable writing method before drafting. If the resource is unbuilt or unchecked, complete the resource-first gate or deliver a clearly labelled proposal without giveaway claims.

WRITE THE RESOURCE INTO THE POST
Use the exact approved hook. For an unchosen hook, propose exactly three and wait. Match the model/tool plus a job the reader recognises when the facts support it; a useful how-to or demonstrative opening can work too. Do not force a model name into an unrelated business. Avoid a vague problem frame, inventory headline, rubric, metric boast or origin story by default. An explicit user hook wins without importing unsupported follow-on claims.

Line two is one concrete capability payoff. Usually name the model/tool/resource as its subject: what it does to the reader's input and the useful work it produces. Keep line counts, benchmark boasts and disclaimers out of that payoff. Keep the opening short enough to understand before expansion without promising an exact platform fold.

Then make the actual resource tangible, in the order earned by its evidence and the selected shape:
- The work it covers, using recognisable job language. Name relevant roles when helpful; describe tasks rather than claiming measured headcount replacement.
- The input the reader supplies: the real brief, URL, recording, screenshots, data or files.
- Consequential mechanics: selection decisions, thresholds, constraints, a difficult-part preview, evaluation or correction that change the result. Preserve real trade terms and source-backed numbers. Administrative verbs such as researches, analyzes and optimizes do not substitute for these details.
- Concrete outputs, exact formats and asset size only after checking the actual delivered file. Count files/sections/steps from the current artifact; never reuse a historical count blindly. Distinguish source specifications from observed run properties.
- A short reader/use-case line when it adds information, then an access closer that matches the real resource and route.

Keep the model/tool as the subject through the payoff and production sequence where natural. Write in a spoken peer register, with contractions and uneven lengths. For rows, mix a short noun/detail row with a longer decision or verb row. Vary the row count, markers, paragraph lengths and groupings according to the calibration; do not force every post into seven arrow rows or identical label-plus-verb lines. Compare the structure with my last two or three posts if available. For paired posts, swapping the resource name should not turn one into the other.

Keep meaningful specificity. A source-backed 60 fps export or difficult-scene test can carry the post without a price or time-saving claim. Whole-job costs need measured whole-job costs; token input price is not total production price. Dates, model availability, pricing and benchmarks need current primary-source verification if used. No invented personal experience, customer outcome, employee replacement, business metric or universal topic/cadence law.

Normally write 80–250 words, unless I ask otherwise. Default to no body links, comment-gate CTA, rhetorical questions, mechanical section introductions, em dashes, forced metaphors, formulaic antithesis or summary wrap-up. These are editorial defaults, not evidence of platform suppression. Do not claim particular words cause spam filtering. Preserve useful scope and material uncertainty; put review flags outside the paste-ready post wherever possible, rather than filling it with caveats.

If the resource really is free and accessible, establish the give in the body and finish on a short accurate closer such as “The prompt ↴” or “Free access ↴”. “Below” needs an actual planned placement before publishing. If access is not ready, use a complete review-only version without a giveaway promise. A post draft is not publication approval.

DESIGN FROM THIS RESOURCE
Inspect the real resource outputs, current brand assets and the actual pixels of relevant supplied references before choosing a composition. Log what was inspected, where it came from and permitted use. A text description of an image is not visual inspection; when pixels are unavailable, disclose the gap. Borrow broad principles, not another creator's identity, exact artwork or claims.

Propose three genuinely different visual concepts and recommend one by how well it helps the intended reader understand or inspect this resource. They must differ in information structure and focal evidence, not just palette. Possible structures include a large authentic output with one useful annotation, an input-to-output transformation, a production storyboard or a dense usable reference sheet. Use only structures this resource supports. A generic workflow map is not the default. If no visual choice is required from me, develop the recommended concept; keep a review checkpoint before publishing.

Derive colour, typography, density, subject, crop and reading order from the actual brand, resource and approved references. There is no universal four-row ceiling, empty-space quota, required person, focal number, one-accent limit or forced brand palette. Use enough content to explain one strong idea at phone size. Different businesses need different visual structures. Use actual screenshots/logos where authorized; a plain-text name is a permitted fallback. Label illustrative diagrams as illustrations. Charts that claim data need real sourced data. Never fabricate a product interface, screenshot, testimonial or result as evidence.

Write one self-contained production prompt with dimensions/aspect ratio, selected structure, exact text, hierarchy, palette/type, real filenames and what each asset may be used for, crop/preservation instructions, and explicit truth constraints. No unresolved placeholders in a prompt marked paste-ready. If a generation tool cannot preserve a real evidence image, composite the authentic asset through an appropriate authorized route or return a layout needing that placement, not a counterfeit screen.

An image keyword CTA is optional, not a default requirement. It needs the publisher's current keyword history, live destination and working authorized fulfillment route. If any is unknown, omit the keyword CTA and use an accurate resource label or no access line. No automation is set up by writing a CTA.

Generate the actual image when requested and available. Open it at full size and at a 360-pixel-wide phone preview. Check exact text, legibility, crop, source fidelity, hierarchy, contrast, unsupported claims, visual clutter and brand fit. Fix specific defects, re-render and inspect again; keep prompt/image versions matched. Report PASS, FAIL or UNKNOWN for actual checks. A complete prompt, a generated image and an inspected final image are different deliverables.

Return one post, normally 80–250 words, and one self-contained production prompt separately. Include the three visual concept summaries and recommendation outside the post. Add 2–5 short review flags and link the source/claim record. Make the resource's real inputs, working decisions and outputs inspectable; a safe generic summary still fails. Do not publish or schedule.
