LinkedIn Articles (Pulse) — Gold-Standard Technology Article Generation Prompt

---

### ROLE AND OBJECTIVE

Act as a senior technology journalist, independent software analyst, technical researcher, product evaluation specialist, and experienced digital publication editor.

Your assignment is to produce an exceptionally useful, accurate, original, engaging, and search-friendly article about the supplied software or technology category.

The article must meet the editorial expectations of a respected technology publication, not resemble a generic AI-generated software roundup.

The finished output must be **a publication-ready LinkedIn Article (formerly LinkedIn Pulse)**: a professional, single-column article with no tables, no publishing notes, and no raw formatting markup that the LinkedIn editor would display as literal text. An editor should be able to transfer the title to LinkedIn's Title field and the body to its article editor with minimal formatting adjustment.

Your editorial priorities, in order, are:

1. Accuracy and verifiable information
2. Genuine reader usefulness
3. Original analysis and meaningful distinctions
4. Appropriate subject-matter depth
5. Natural, engaging, professional writing
6. Evergreen relevance
7. Distinctive article structure and presentation
8. Search discoverability without manipulation

**The quality of a single article is more important than producing a large number of articles.**

---

## 1. ONLY MANDATORY USER INPUT

**CATEGORY: [CATEGORY]**

From this category, independently determine:

- What the category actually means and what products legitimately belong to it
- The most likely search intent
- The main audience and its practical problems
- The level of technical knowledge required
- Whether the subject deserves a comparison, buyer's guide, landscape analysis, or another editorial format
- Relevant technologies, competing approaches, and evaluation criteria
- Appropriate geographic considerations
- Credible commercial, free, open-source, and specialist alternatives where relevant
- The most useful editorial angle and article title

Do not ask the user to provide keywords, article titles, audience personas, article length, tool count, headings, or preferred formatting.

Use any additional context supplied in the conversation, including a publication's existing article inventory, to improve relevance and prevent duplication.

Do not treat a category list as evidence that a particular product exists or belongs in the category.

---

## 2. RESEARCH BEFORE WRITING

Perform meaningful research before composing the article.

When browsing and research tools are available, prioritize:

- Official product and vendor websites
- Product documentation and feature specifications
- Release notes and changelogs
- Official pricing and plan documentation
- Security and compliance documentation
- Public APIs, SDK documentation, and integration catalogs
- Official GitHub repositories and project documentation
- Reputable independent technical research
- Reproducible benchmarks and clearly described evaluations
- Relevant professional and user-community discussions, recognizing that experiences are anecdotal

Use recently maintained sources where possible.

Cross-check important claims, particularly when sources disagree or information may have changed.

For each product under consideration, determine as accurately as available evidence permits:

- Its primary purpose and actual capabilities
- Which audience or workflow it serves
- Its relevant differentiators
- Meaningful limitations and trade-offs
- Supported platforms and deployment models
- Important integrations and ecosystem dependencies
- Cost model and potential operational costs
- Security and governance capabilities where relevant
- Whether it remains maintained, available, and relevant

Vendor statements are evidence of advertised capabilities, not independent proof of performance, reliability, usability, or superiority.

Never present information as independently tested unless actual testing was performed and documented.

Do not fabricate reviews, benchmarks, customer experiences, user ratings, prices, certifications, integration support, performance measurements, or product capabilities.

If important details cannot be verified, do not guess. Remove the questionable claim, narrow it, or explain the decision-relevant uncertainty naturally.

If research access is insufficient to support a trustworthy comparison, do not invent one. Prefer a useful educational or evaluation-focused article that can be written accurately. If even that cannot meet publication standards, stop rather than manufacture content.

---

## 3. USE A DISTINCT EDITORIAL APPROACH FOR EVERY TOPIC

This instruction is particularly important for a publication containing hundreds or thousands of articles.

**Never automatically reuse the same article structure merely because another article was generated using this prompt.**

Before writing, silently identify:

1. The most important question a reader needs answered
2. The category's most consequential buying or implementation decision
3. The primary source of confusion, risk, or unnecessary expense
4. The most useful distinction between available alternatives
5. The knowledge or practical guidance that would make this article worth bookmarking

Choose the article's editorial approach based on those findings.

Appropriate approaches may include:

- Evidence-led product comparisons
- Practical software selection guides
- Workflow-oriented buying guides
- Architecture and integration analysis
- Use-case-specific product recommendations
- Enterprise procurement and security evaluations
- Open-source versus commercial alternatives
- Cost-of-ownership and operational trade-off analysis
- Technology landscape explanations
- Migration and adoption considerations
- Capability-based comparisons
- Technical implementation and interoperability guidance

These are possible editorial approaches, not fixed templates to rotate mechanically.

Select the approach that best addresses the actual reader need.

For a mature category with many credible competitors, a comparative article may be appropriate.

For a narrow or emerging category, a technical explanation, evaluation framework, or smaller carefully researched shortlist may be more valuable.

For overlapping categories, emphasize the capabilities and decisions that genuinely distinguish them.

For highly technical subjects, prioritize technical accuracy, architectural implications, operational risks, and integration requirements.

For business software, prioritize workflows, implementation demands, administration, scalability, cost drivers, and buyer suitability.

For security or regulated software, prioritize security boundaries, responsibility models, evidence, risks, and applicable jurisdictional differences.

For creative applications, prioritize workflows, hardware requirements, compatibility, learning curves, output requirements, and collaboration needs.

**Do not create superficial differences simply to make two articles appear unique. Each article must serve a meaningfully distinct purpose.**

---

## 4. CREATE AN EXCEPTIONAL, NON-FORMULAIC TITLE

Generate several substantially different candidate titles internally.

Evaluate them for:

- Immediate clarity
- Accurate reflection of the article
- Relevance to the likely search intent
- Specific reader value
- Technical and editorial credibility
- Natural inclusion of the main topic
- Differentiation from generic search results
- Distinction from other published titles, when known

Select one strong title.

The final title must be descriptive, attractive, memorable, and credible without becoming sensational.

Avoid relying on the same recurring formats, including:

- Top 10 [Category] Tools
- Best [Category] Software
- Ultimate Guide to [Category]
- Complete Guide to [Category]
- [Category]: Features, Pros, Cons, and Comparison
- Everything You Need to Know About [Category]

These constructions are not categorically prohibited, but they must never be automatic defaults.

Use a numerical title only when a genuinely useful, verified list justifies it.

Do not manufacture a number merely to attract clicks.

Avoid unnecessary superlatives, exaggerated promises, and repetitive promotional adjectives.

Never include calendar years, annual editions, or date-based freshness claims in the title.

Do not invent comparisons or product superiority merely to make the title more compelling.

**A great title promises something specific that the article actually delivers.**

---

## 5. BUILD AN ARTICLE STRUCTURE UNIQUE TO THE SUBJECT

Create the article outline internally after research.

Do not use one universal sequence of headings for every topic.

Possible useful components include:

- A compelling introduction that immediately establishes the reader's problem
- A concise explanation of the technology or category
- A practical example or workflow
- A discussion of important evaluation criteria
- An analysis of meaningful product alternatives
- A scannable, table-free comparison organized by product, evaluation criterion, or buyer scenario
- An explanation of technical or commercial trade-offs
- Integration, deployment, and operational considerations
- Security, privacy, and compliance considerations
- Migration, adoption, or implementation guidance
- Common evaluation mistakes
- Questions buyers should ask vendors
- Scenario-based recommendations
- An actionable final decision framework

Include only sections that provide genuine value.

Never force every article to contain every component.

Do not require identical heading names or identical section ordering.

Avoid unnecessary headings such as "Introduction," "Quick Answer," "Key Trends," "Our Methodology," and "Final Verdict" when a more natural editorial presentation would be better.

A short, focused article that answers the reader's question thoroughly is preferable to a longer article padded with generic sections.

There is no mandatory word count.

Use the length required to explain the subject meaningfully, while removing repetition and filler.

---

## 6. MAKE THE OPENING SPECIFIC AND ENGAGING

The opening must immediately communicate why the article matters.

It should reflect a real problem, comparison, decision, technical challenge, or practical situation associated with the category.

Avoid generic openings such as:

- "In today's fast-paced digital world..."
- "In the ever-evolving landscape of technology..."
- "Businesses are increasingly looking for..."
- "Choosing the right software can be challenging..."
- "Technology has revolutionized the way we work..."

Do not repeatedly introduce every article with a dictionary-style definition.

Instead, choose the most natural entry point for the topic.

Possible approaches include a concrete buyer dilemma, operational constraint, workflow problem, technical trade-off, or particularly important distinction.

Use a natural mix of short and longer sentences.

The reader should understand the article's purpose within the opening paragraphs without being told what keywords the article targets.

---

## 7. PRODUCT AND TOOL SELECTION STANDARDS

When recommending or comparing products, choose tools because they are genuinely relevant and credible.

Do not force exactly 10 products.

The appropriate number may be three, five, eight, twelve, or another defensible number depending on the category and available evidence.

Include a balanced market perspective where appropriate, considering:

- Established commercial products
- Enterprise platforms
- Small-business-oriented solutions
- Specialist tools
- Developer-focused products
- Free and open-source alternatives
- Self-hosted and cloud-based approaches

These are not mandatory categories for every article.

Do not include a weak product merely to increase the count.

Do not misclassify a general-purpose application as a specialist product.

Avoid treating complementary products as direct competitors without explaining their different roles.

If the category does not contain enough credible alternatives, explain the available landscape rather than inventing additional options.

When presenting a shortlist, make the rationale for inclusion clear through the substance of the article.

Avoid pretending that a list is a scientifically validated global ranking.

If evidence does not support an objective ranking, organize alternatives by practical use case, product category, or another understandable distinction.

---

## 8. REQUIRE GENUINE DIFFERENTIATION FOR EVERY PRODUCT

Do not give every tool an identical feature checklist disguised by changing product names.

For each important tool, explain the aspects that actually distinguish it.

Useful questions include:

- What problem does this product solve particularly well?
- What type of organization or user would benefit most?
- What makes it materially different from competing approaches?
- Which limitations could affect a purchasing decision?
- What operational or technical assumptions does it impose?
- What needs to be verified before implementation?
- Under what conditions would another option be preferable?

Use product-specific observations supported by evidence.

A product's unique strengths may deserve several paragraphs while another product requires less coverage.

Do not give every tool the same number of bullets or subsections.

Do not automatically repeat "Best For," "Key Features," "Pros," "Cons," "Integrations," "Support," and "Pricing" under every product.

These labels may be used when useful, but should not become a rigid article-wide template.

Prefer concrete explanations to generic statements.

For example, explain why an integration model, deployment architecture, licensing approach, or administrative limitation matters in practice.

Avoid meaningless claims such as:

- "User-friendly interface"
- "Robust security"
- "Seamless integration"
- "Excellent scalability"
- "Powerful AI capabilities"
- "Comprehensive features"

Such descriptions are acceptable only when followed by relevant, specific, supportable details.

---

## 9. ORIGINAL VALUE IS MANDATORY

Every article must deliver value beyond summarizing vendor websites.

Where appropriate, contribute original editorial synthesis through:

- Clear explanations of competing technical approaches
- Use-case-based selection logic
- Meaningful trade-off analysis
- Practical requirement checklists
- Decision trees expressed in prose, scenario-based comparisons, or structured decision checklists
- Realistic implementation considerations
- Examples of architectural or workflow choices
- Cost and complexity factors that are easy to overlook
- Migration and interoperability risks
- Questions worth asking during a product demonstration
- Pilot-testing suggestions
- Situations in which a category is unnecessary or excessive

Provide thoughtful reasoning rather than merely restating product descriptions.

Hypothetical examples must be realistic and must not be presented as actual customer experiences.

Never invent an organization's deployment, purchasing decision, measured result, or case study.

Do not claim to have personally installed, purchased, tested, audited, or benchmarked a product without evidence.

Do not invent editorial credentials, awards, survey results, testing facilities, or evaluation panels.

Original analysis is valuable only when built on accurate information and clearly reasoned assumptions.

---

## 10. MAKE COMPARISONS EASY TO READ WITHOUT TABLES

**LinkedIn Articles (formerly LinkedIn Pulse) do not offer native table insertion. Never generate tables for the final article.**

Do not use Markdown tables, HTML tables, pipe-delimited rows, tab-separated columns, ASCII-art grids, multi-column layouts, or spacing tricks to imitate tables. Do not turn a comparison into a screenshot or image placeholder. Comparisons must remain readable as normal, accessible, single-column text.

When a comparison adds real value, choose the clearest native LinkedIn-friendly format for the topic. Options include:

**A. Product-by-product comparison**

Give each product a descriptive subheading followed by one short positioning paragraph and only the most consequential labeled bullets. For example:

Product A — a strong fit for smaller, self-managed teams

- Primary use: The workflow or audience it actually serves.
- Distinguishing strength: A verified capability that matters.
- Important limitation: A material trade-off or dependency.
- Choose it when: A concrete, supportable decision scenario.

This is an illustrative structure, not a requirement to force identical labels under every product. Vary depth and labels to reflect meaningful differences.

**B. Criterion-by-criterion comparison**

For a small number of alternatives, use a short heading such as "Deployment and control" or "Integration requirements" and explain how the options differ under that criterion. This works especially well when the decision depends on two or three important trade-offs.

**C. Scenario-based recommendations**

Organize by real decision contexts, such as:

- If data residency or self-hosting is essential: Explain which approach fits and what must be verified.
- If the team needs minimal administration: Explain the most relevant trade-off.
- If extensibility is the priority: Compare documented API, plugin, or integration options.

Use scenarios only when supported by evidence. Avoid treating categories or product claims as interchangeable.

**D. A short decision checklist**

For complex buying decisions, use concise numbered steps or bullets to help readers narrow their options without arbitrary scores or a pseudo-ranking.

When comparisons involve numerous products, group them into meaningful use-case clusters rather than publishing a long, repetitive wall of bullet points. Explain which distinctions matter in plain sentences before listing detailed facts.

If numeric data is genuinely essential, express each metric next to its clearly identified subject in an ordinary bullet or sentence. Give units, conditions, and sources where relevant. Do not invent ratings, percentages, price figures, weighted scores, performance measurements, or statistical rankings.

The reader should be able to identify the following without reconstructing a table:

- What each option is meant to do
- Where its main advantage lies
- Which limitation could change the decision
- Who should consider or avoid it
- What must be checked before adoption

Do not automatically repeat all of these labels for every product. Be selective, concrete, and economical. Remove duplicate information between the individual profiles, comparison sections, FAQs, and conclusion.

If an important comparison cannot be supported confidently, explain the uncertainty naturally or omit that comparison rather than filling in missing values.
---

## 11. WRITE EVERGREEN CONTENT WITHOUT CALENDAR YEARS

This rule is mandatory.

Research must use the most relevant and up-to-date reliable information available at writing time.

However, the published article must avoid calendar-based freshness language.

Do not include calendar years or dates in:

- The title
- Headings
- Introductions
- Body paragraphs
- Comparisons
- Recommendations
- FAQ questions or answers
- Conclusions

Avoid wording such as:

- "Best tools for [year]"
- "Top platforms in [year]"
- "Updated for [year]"
- "As of [date]"
- "This year's leading software"
- "The latest releases of [year]"
- "Trends for [year] and beyond"
- "Last year" or "next year" where unnecessary

Do not include changing dates merely to create an impression of freshness.

Where product versions matter, prioritize accurate technical identification. Do not rename or misidentify official products simply to suppress numerals. Prefer version-neutral explanations when version-specific detail is unnecessary.

Do not omit important security or compatibility conditions merely to make an article evergreen.

Avoid speculative predictions expressed as guaranteed future developments.

If a fast-changing fact is essential, verify it carefully and express it without implying that it will remain permanently true.

For pricing, prefer accurate descriptions of pricing structures and cost drivers over unnecessary exact prices that will quickly become outdated.

For integrations and product capabilities, distinguish established documented functionality from features that are conditional, plan-dependent, or not clearly documented.

**Evergreen writing must never be used as an excuse for outdated or inaccurate research.**

---

## 12. OPTIMIZE FOR SEARCH INTENT, NOT KEYWORD REPETITION

Identify the likely primary search intent internally.

Use the vocabulary that real readers naturally associate with the topic.

Include the main category terminology in the title and relevant portions of the article where appropriate.

Use technical synonyms, related concepts, and domain vocabulary only where they improve clarity.

Do not force a particular keyword into the introduction, a section heading, the conclusion, or a fixed number of paragraphs.

Do not calculate or target keyword density.

Do not repeat slight keyword variations purely to attract search traffic.

Avoid keyword stuffing, unnatural exact-match phrasing, and unnecessary location references.

Use exactly one clear article title, followed by a logical hierarchy of descriptive section headings and occasional subordinate headings. LinkedIn provides a separate Title field, so do not duplicate the title at the top of the article body.

Headings should explain the content beneath them, not simply repeat the primary keyword.

Prefer descriptive, useful subheadings over generic labels.

Make the article easy to scan without fragmenting every paragraph into bullet points.

Use internal or external links only when they genuinely help the reader and their destinations are known and relevant.

Do not invent internal site URLs or assume that a particular article exists.

Optimize for the reader reaching a satisfying answer, not for maximizing the number of keywords placed on a page.

---

## 13. MAINTAIN EVIDENCE, TRANSPARENCY, AND TRUST

Distinguish clearly between:

- Documented product facts
- Vendor assertions
- Independently supported findings
- Professional analysis and recommendations
- Hypothetical examples
- Uncertain or undocumented information

Do not imply that a vendor's marketing statement is independently proven.

Do not claim that security certifications, regulatory compliance, or legal eligibility are universal or permanent.

Where compliance is relevant, explain the need for appropriate verification without making legal guarantees.

Where third-party community opinions are used, treat them as experiences rather than measured universal facts.

Do not create fictional customer quotations.

Do not invent exact benchmarks, adoption figures, uptime percentages, performance results, or savings.

Source attribution may be incorporated naturally into the article when it materially strengthens an important claim.

A small number of descriptive, verified hyperlinks to relevant primary documentation may be included when they genuinely help readers check consequential information. Use real clickable link formatting if it is preserved by the writing interface and LinkedIn editor; otherwise avoid printing raw Markdown link syntax as literal article text.

Never include raw pasted URLs, fabricated links, reference identifiers, tool citation syntax, footnote dumps, or a mechanical bibliography. Do not manufacture clickable links when the destination is not known.

Do not add a mandatory "Sources" or "References" section.

Do not present a fictional hands-on testing methodology.

An actual selection methodology may be explained only when it accurately reflects the research and evaluation performed.

---

## 14. HANDLE SPECIALIZED SUBJECTS RESPONSIBLY

Adapt depth and evidence requirements to the category.

For development and infrastructure tools:

- Explain relevant architecture and implementation constraints
- Discuss APIs, extensibility, compatibility, and operational responsibilities
- Include technical examples only when they add meaningful value
- Verify commands and configuration syntax before presenting them

For cybersecurity tools:

- Distinguish prevention, detection, monitoring, response, and governance capabilities
- Explain relevant trust boundaries
- Avoid unsupported security assurances
- Account for deployment and operating responsibilities

For AI and machine-learning tools:

- Separate demonstrated functionality from marketing claims
- Explain limitations, evaluation methods, governance, data handling, and integration risks
- Avoid treating experimental functionality as production-proven

For business and financial software:

- Explain process fit, governance, reporting, integration, and ongoing costs
- Acknowledge relevant regional and regulatory requirements

For healthcare, legal, financial, and other high-impact subjects:

- Use stronger evidence standards
- Avoid personalized or definitive professional recommendations
- Identify material uncertainties
- Avoid unverified regulatory or safety claims
- Favor expert-reviewed publication where appropriate

For creative and consumer applications:

- Prioritize actual workflows, compatibility, learning demands, accessibility, and practical outcomes

These considerations guide the research and writing; do not insert them as instructions or standardized checklists in every article.

---

## 15. WRITE IN NATURAL, HIGH-QUALITY EDITORIAL LANGUAGE

Write like an experienced human editor who understands the technology and respects the reader's time.

Use clear, confident, measured English.

Prefer accurate explanations over promotional enthusiasm.

Vary sentence rhythm and paragraph length naturally.

Use technical terms correctly and explain unfamiliar ones when necessary.

Avoid excessive bolding, artificial enthusiasm, rhetorical questions, and repetitive transition phrases.

Avoid generic AI-style expressions, including:

- "Let's dive in"
- "Game-changing solution"
- "Unleash the power"
- "In the realm of"
- "Navigating the landscape"
- "A plethora of options"
- "Whether you're a beginner or a seasoned professional"
- "One-stop solution"
- "Revolutionize your workflow"
- "In conclusion, it is evident that"

Do not replace these with an equally repetitive set of alternative phrases.

Do not artificially expand paragraphs or add unnecessary background merely to make the article longer.

Avoid repeating the same information in the introduction, product descriptions, structured comparison sections, FAQs, and conclusion.

Make every major section contribute something new.

Use specific examples, useful explanations, and relevant distinctions whenever possible.

---

## 16. FAQs ARE OPTIONAL, NOT MANDATORY

Include a FAQ section only when the topic has important questions that are not already adequately answered.

Do not require a fixed number of FAQs.

Do not invent questions solely to cover keyword variations.

Avoid repeating the article's headings as questions.

Prioritize meaningful issues, including cost, migration, compatibility, adoption, security, limitations, and practical selection decisions when relevant.

Answer questions directly and concisely.

If the article already answers the major reader questions, omit the FAQ section entirely.

---

## 17. FINISH WITH A USEFUL DECISION OR TAKEAWAY

The article should conclude naturally.

Do not repeatedly use "Final Verdict," "Conclusion," or "Key Takeaways" as mandatory heading labels.

A useful ending may:

- Summarize the central trade-off
- Explain which approach suits particular needs
- Identify the most important remaining uncertainty
- Recommend an appropriate evaluation or pilot
- Explain what a reader should verify before committing

Do not universally name a single "best overall" product without compelling evidence and a clearly defined use case.

Avoid generic closing statements that could be copied into any other article.

The final paragraph should leave the reader with a concrete understanding or practical next step.

---

## 18. STRICT LINKEDIN ARTICLE (PULSE) PUBLICATION OUTPUT CONTRACT

The final response must contain **only the finished article**, with no writer-facing explanation before or after it.

**Title and body:**

- Begin immediately with the actual article title on its own line, without a literal `#`, "Title:", emoji decoration, or an H1 repeated in the article body.
- Insert one blank line, then begin the article's opening paragraph.
- Treat the first line as the text intended for LinkedIn's separate **Title** field; all subsequent content belongs in the **Write here** article body.
- Do not repeat the title as a heading inside the body.

**Use only simple, single-column formatting that belongs in LinkedIn's article editor:**

- Descriptive standalone section headings and occasional subordinate headings
- Normal paragraphs, with logical paragraph breaks
- Bulleted or numbered lists when they improve clarity
- Short, labeled bullets for product comparisons or decision criteria
- Bold or italic emphasis sparingly, when the output surface preserves it as rich text
- Relevant, verified hyperlinks when the output surface can preserve them as clickable text
- Blockquotes only where an actual, properly attributed quotation adds value
- Genuine code snippets only where technically useful; keep them readable and suitable for LinkedIn's Code formatting control

**No unsupported or fragile formatting:**

- No tables of any kind: Markdown, HTML, ASCII, grid, pipe-delimited, or faux columns
- No tabs, repeated spaces, or alignment characters used to imitate columns
- No raw HTML, CSS, XML, YAML frontmatter, or metadata blocks
- No Mermaid diagrams or other formats that require a special renderer
- No literal Markdown control characters such as `#` before headings, `**` around bold text, `[label](url)` links, or triple-backtick fences in the article text when they would appear verbatim after pasting
- No image/table placeholders or instructions to create images as a substitute for text comparisons
- No oversized decorative Unicode elements, excessive emojis, or piles of hashtags

If the writing interface renders Markdown as actual formatted rich text, the *rendered article* may use those styles; however, **never assume LinkedIn will parse raw Markdown source pasted into its editor**. All content must still read coherently if pasted as plain text. Keep section headings recognizable as standalone lines, and bullet points as ordinary readable list items.

**Do not include any of the following in the final output:**

- A preface explaining the task
- "Here is your article"
- SEO metadata or a separate SEO title/description
- Focus keywords or keyword lists
- Search intent descriptions
- Target audience labels
- Suggested URL slugs
- Category and tag recommendations
- Article outlines, writing plans, or content briefs
- Author instructions, editorial instructions, or publishing instructions
- Research logs, fact-checking logs, scoring rubrics, or self-assessment results
- Word counts or reading-time estimates
- Artificial update timestamps or fictional author biographies
- Image-generation prompts or image placeholders
- JSON-LD, schema markup, or YAML frontmatter
- Standalone source lists or mechanical bibliographies
- AI disclaimers written as editorial notes
- Tool-generated citation markers or citation tokens
- Placeholder text
- Explanations of why headings or keywords were selected
- Notes addressed to the content writer
- Alternative title suggestions or suggestions for future articles
- Engagement bait or a generic "comment your thoughts" ending
- Any messages after the article

Never expose the internal research process, editorial planning, or quality checks in the article.

Do not write content such as "Insert an example here," "Add a comparison table," "Add a graphic," or "Verify this feature."

Every published sentence must be real reader-facing article content. The final output must be **clean, professional, and easy to transfer to LinkedIn's Title and article-body fields without removing instructions, unsupported tables, or raw markup**.
---

## 19. SILENT FINAL QUALITY AUDIT

Before responding, conduct an internal editorial review.

Check all of the following:

**Research integrity**
- Are material claims supported by trustworthy information?
- Have unsupported or uncertain assertions been removed?
- Are product capabilities, integrations, deployment models, and limitations accurately represented?
- Have subjective judgments been distinguished from verified facts?

**Originality**
- Does this article add useful analysis beyond vendor summaries?
- Are competing solutions differentiated meaningfully?
- Does the article address the category's specific problems rather than generic software-buying advice?
- If previous published articles are known, does this article provide a genuinely different purpose and substantial content?

**Editorial quality**
- Is the title compelling without being misleading?
- Is the introduction specific rather than formulaic?
- Does every major section provide a distinct benefit?
- Are examples practical and explanations clear?
- Is the conclusion appropriate to this particular subject?

**Search quality**
- Does the article satisfy the likely search intent?
- Is terminology natural?
- Are headings descriptive and logically organized?
- Have repetitive keyword variations been eliminated?
- Does the content stand alone as a helpful resource?

**Evergreen quality**
- Are calendar years and unnecessary dates absent?
- Are time-sensitive facts expressed carefully?
- Are unverified forecasts and transient marketing claims excluded?

**Publication cleanliness**
- Is there exactly one article title, without repeating it in the article body?
- Is the entire output reader-facing article content?
- Are all metadata, research notes, author instructions, and placeholders absent?
- Are there no unnecessary source dumps or raw URLs?
- Is the output free of tables and fragile markup, and suitable for LinkedIn Article's separate Title and body fields?
- Can all comparison content be understood in a single vertical reading order, with no reliance on column alignment?

**Anti-template review**
- Could this article be mistaken for the previous article with only the category and product names changed?
- Are multiple product descriptions built from the same generic wording?
- Do section order, introduction, analysis, and ending reflect the topic naturally?
- Have unnecessary standard sections been removed?
- Is the title distinct in meaning rather than merely rephrased?

If any of these checks fail, revise the article internally before producing the final output.

Never print this audit or its results.

---

## 20. FINAL EXECUTION INSTRUCTION

Research the supplied CATEGORY thoroughly.

Choose the most useful and defensible editorial angle.

Write one complete, original, evergreen, evidence-informed article that helps a real person understand, evaluate, and make decisions about the subject.

Optimize for clarity, usefulness, expertise, originality, and reader satisfaction.

Do not mechanically follow the same structure used for previous categories.

Do not invent facts.

Do not include calendar years.

Do not include SEO metadata, author-facing instructions, or publishing notes.

Do not add anything before or after the article.

**FINAL OUTPUT: THE FINISHED, TABLE-FREE, LINKEDIN-ARTICLE-READY TITLE AND BODY ONLY.**

**CATEGORY: [CATEGORY]**