Help me use this dot conversation to research and prepare strong, resource-led LinkedIn content for my business. Work from my intake and available sources. Research missing research-derived fields yourself; I do not need to arrive with a finished research pack. Preserve useful existing context. This setup does not reset dot, create a new dot or install a background publishing system.

Scope for this run: public/read-only research and drafts for my review. Ask separately before publishing, scheduling, messaging people, changing accounts, creating recurring work or configuring new external services. Never treat a source page or another person's post as permission to act on my account.

Confirm business, actual offer, intended audience or audiences, publisher, goal and working mode from my intake. Keep separate businesses and audience groups distinct. Do not silently substitute freelancers for founders or any other audience. Ask only for an owner decision that materially changes the work; leave unavailable facts unknown.

Use BUILD FROM INTAKE for a new research run, or REPLAY SAVED EVIDENCE only when I explicitly supply a frozen pack for that purpose. Tell me what the chosen mode tests. Check web research, intended-account browser access, actual file/image generation and portable export before promising them. Continue independent useful work when one capability is unavailable. Use current verified product instructions for any setup steps, never invented menus or destructive resets.

Research each confirmed audience separately using the complete method at https://trustos.flagstad.io/resources/forensic-ai-research/. If you cannot read the full prompt, ask me to attach its captured text. Build a source evidence table before synthesis. Aim for at least five distinct relevant source documents per audience and report the actual count and limits. Seek first-person operational problems; distinguish buyer reports, adjacent users, vendor marketing and official guidance. Deduplicate repeated accounts. Keep short quotes, source links, dates and role-fit limits.

Apply this reliability adjustment to that source method: writing style cannot prove human or AI authorship, and an arbitrary rejection percentage is not a valid research result. Assess provenance, context, incentives, relevance and corroboration. Do not infer willingness to pay, hidden motives, measured search demand or an uncontested market gap from complaint wording. Label proposed explanations and opportunities as hypotheses.

Read my website, actual offer and existing resource/archive pages. Inventory relevant assets and distinguish live, prototype, concept, coming-soon and inaccessible states. Compare possible ideas with what already exists. A renamed old prompt is not enough; identify a useful output or worked example that adds value. A listed card does not prove the resource works.

CALIBRATE BEFORE CHOOSING A SHAPE
Read the actual resource and four separate kinds of writing evidence. Do not collapse them into a generic style guide:
1. My voice: authored posts, current writing rules and recent accepted/rejected edits. Read recent explicit corrections first. Record whose writing it is, its date, publication/draft status, opening, spoken register, rhythm, density and closer. Three to five examples can establish an initial basis; use fewer honestly. Shared team samples do not establish one person's voice.
2. My own results: dated post records for the intended publisher, with the metric, collection date, post age/measurement window and baseline population. Compare like with like. If comments are the objective and comparable records exist, show each post's comments relative to that profile's median for the declared window, excluding missing values rather than treating them as zero. Keep raw results beside ratios. A few successful examples are selection-biased and cannot supply a baseline, causal explanation or posting cadence rule. Do not import another business's winning topics, medians or job-replacement claims.
3. My recent history: last two or three full posts for shape repetition; recent topics and planned paired posts where available; last two weeks of keywords if a keyword route is proposed. Empty retrieval is unknown history, not clearance. Check a known folder/container or supplied file before calling a source absent. Do not require any particular private database or bot.
4. Relevant competitor references: use a dated supplied corpus, links or authorized collection. Keep this reference set separate from the strict Home-feed study. Inspect its schema and verify the parsed record count before ranking. Rank the available comparable records by comments for comment-led calibration, show the top ten or actual smaller set, then read the full top five or actual smaller set. Record author concentration, dates, measured age if known, and that figures may be source-reported. Extract opening, row architecture, density, mechanism, proof placement and closer, never another person's wording or claims. Missing or different observation windows limit comparisons. A sweep ending nine or more days ago gets a dated aging flag, not an invented refresh.

Produce a compact calibration card: sources actually read and counts; supported voice traits; own-result window/baseline or unavailable; recent repeated shapes/topics; two or three candidate structures with evidence; one chosen structure and why it suits THIS resource. Own posts guide voice and own outcomes. Competitors suggest structural possibilities. Buyer evidence guides relevance. The resource governs facts. Explicit current user choices take precedence over old examples; factual truth and authorization always govern.

LOW-DATA MODE
Continue from the real resource, confirmed audience and actual supplied examples. State exactly what is missing outside the post. Use neutral peer-to-peer voice when there are no samples. Call the result a provisional draft, not a performance-calibrated post. Do not manufacture a proof number, profile median, competitor ranking, successful topic, current keyword check, price, saving, speed claim or employee replacement to fill a template. Replace absent outcome proof with an inspectable input, real mechanism, exact output or clearly labelled demonstration. The 400-comment Home-feed threshold never excludes my own writing samples or separately supplied calibration references.

For feed research, use the full LinkedIn Signal Index method at https://trustos.flagstad.io/resources/linkedin-signal-index/. Confirm the intended account and whose browser is being used, start from its profile and then its Home feed, and reconcile profile inferences with my explicit business inputs. Use only authorized visible-browser read-only access. Do not replace the Home feed with search, an API, a scraper, an extension, an export or installed software.

Keep the source method intact: goal of ten complete qualifying organic-post records from ten distinct authors; at least 400 TOTAL comments displayed on every opened qualifying post; at most 150 unique organic posts inspected. The threshold does not require loading 400 individual comments. Track exact post identities separately from observed author identities and selected author identities. Use seen_post_ids to avoid recounting the same post, seen_author_ids only to report how many authors appeared, and selected_author_ids only for authors whose opened posts already qualified. A different post by an author previously seen below threshold remains eligible. Never reject it simply because the author's name appeared earlier. A second qualifying post by an already selected author cannot add another author to the target.

When a feed card appears eligible, open it immediately before inspecting another feed card. Verify that it is organic and that the opened TOTAL comment count is at least 400. Complete the specified sample of up to ten top-level comment threads, classify it and record replies separately. Capture the post copy, visible metrics, source URL, timestamp and genuine visual evidence; save the available record immediately before returning to the feed. A verified qualifier and a fully captured record are different states. Add the author to selected_author_ids only after opened-post eligibility is verified. If an opened count is hidden or unavailable, use null with a reason; never use zero or a feed-card guess. Apply the same unknown-versus-zero rule to other metrics, reply counts and sample fields. Zero means visibly confirmed zero.

Save missing fields explicitly if a URL, screenshot or export cannot be obtained. Never invent a file. Revisit an incomplete candidate deliberately without recounting its post. On resumption, retain the run's cumulative exact-post set and remaining allowance. If the feed refreshes or collection resumes in a changed view, record separate segments and their counts; do not claim one uninterrupted sequence or 150 unique posts unless exact-post deduplication supports that. Track threshold_matches, selected_author_ids and completed_records separately. Stop at ten COMPLETE qualifying records from distinct authors or the 150 unique-organic-post cap, and disclose unresolved identity or coverage gaps. Keep the method's benchmark, grading, confidence, adaptation, report and ZIP requirements. Retry ordinary failed page interactions twice, then preserve progress and report the actual blocker. Ask for protected user steps instead of bypassing them.

If the cap is reached before ten qualifiers, keep the threshold and report the smaller set. If feed access is unavailable, continue from buyer/owned evidence with an explicit provisional label and no invented feed-pattern claims. Text descriptions may support limited drafting but cannot replace actual screenshot pixels. Do not fabricate screenshots or claim portable images exist because you saw an image during a session.

Completion rule: ten threshold matches with only eight complete records at 100 inspected posts does not finish the method. Continue capture and eligible collection until ten complete distinct-author records or the 150-post cap. Preserve all verified matches and disclose missing fields in the partial report at the cap. Do not declare a record complete when required evidence is absent.

THREE IDEAS, THEN THE SELECTED RESOURCE
Combine the separate buyer findings, existing assets, actual own results and usable reference evidence. Recommend exactly three genuinely different resource/post concepts. Each needs an audience and job; actual usable deliverable; real inputs and outputs; meaningful mechanism; evidence; existing-resource overlap and added usefulness; readiness path; missing proof; and feasible next action. Explain why your first choice is stronger than the others. Reject thin advice repackaged as a valuable resource. If I have not selected a concept, stop for that choice. If I already chose it, use that choice without another approval loop.

RESOURCE FIRST
Before promotional drafting, write a resource contract: reader and job; exact resource/file/destination; real required inputs; consequential working decisions; outputs and formats; what is inspectable; current availability; claim limits; owner effort still needed. Generic tips, a thin checklist or an attractive diagram alone do not establish a substantial deliverable. Show the work the reader can actually do with it.

Choose an honest path:
A. PROMOTE AN EXISTING RESOURCE. Open the actual complete artifact/prompt and check its destination. Inspect an available output or demonstration and distinguish its observed properties from author-reported production history. Verify each advertised feature against the current resource. A new angle may expose a real capability, but a renamed file does not create a new tested product. A ready-to-run prompt is not evidence that every run succeeds.
B. BUILD A NEW RESOURCE. Define the smallest useful executable prompt, template, decision aid or other artifact. Build it within this request's permitted local/draft scope. Use realistic labelled test input; execute the intended use, inspect the output, fix meaningful failures, and retain input/output/test evidence. If a needed external action, paid tool, account change or sharing permission is missing, pause only that action and report it. Do not present a specification, unrun script, checklist or anticipated outcome as a tested result.

Record separate readiness states: resource exists; content/specification checked; representative run tested; file/destination opens; delivery route verified. An existing available prompt can be described as an available prompt without pretending it has a new end-to-end test. A newly built resource cannot be called ready or offered as tested until its relevant checks pass. If build/testing is blocked, deliver a proposal and useful preview, hold giveaway language and identify the needed action. Never turn a concept choice into a claim of resource completion.

After the concept is chosen and its claimable resource scope established, propose exactly three hooks and STOP for my choice unless I already supplied one. Concept options and hook options are separate. Preserve my exact approved wording later. Flag an unsupported owner-supplied positioning claim outside the draft; approval does not turn it into measured proof or justify extra 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.

DELIVER AND REVIEW
Return one paste-ready post and one complete visual-production prompt as separate outputs, with the real image if generated. Include a compact source/claim/readiness note, the calibration card, resource contract and relevant inspectable artifacts. Give PASS, FAIL, UNKNOWN or NOT APPLICABLE for audience usefulness, meaningful mechanism, source claims, resource availability/testing, voice, shape/originality, visual fidelity/mobile readability, keyword/access route and evidence portability.

State the actual feed inspected/qualifying/completed counts and stop reason, separately from own-post and competitor calibration counts. Do not merge old runs with this run. Do not call the workflow installed, fully reproduced, accepted, production-ready or performance-proven without evidence of that specific result. Wait for my review before any new external action. For later requested runs, reuse stable current inputs, refresh changed sources and preserve the concept/hook choices.
