AI Preamble
Denis Tkalec drafted the article below to provide some guidelines on creating articles/blogs for Cenosco.
To help use the document,
A .skill file is basically a zip file that Claude uses to package the resources necessary for each skill. In the case above, it only contains a SKILL.md file. If you want to see how one of these files is structured, see the SKILL.md file below:
Now, onto the actual article:
0. Do Deep Research (Before You Write a Single Word)
Most people make the mistake of jumping straight into writing. Don't be most people.
Step 1: Analyze the Top 10 Google Results
Type in your main keyword and see what's already ranking. Ask yourself:
What subheadings are they using?
How long are the articles?
What does the content cover that you plan to write about?
Where are the gaps you can improve upon?
This tells you what Google considers relevant for that search.
Step 2: Look Up Terms You Don't Understand
If you come across a technical term, statistic, or concept that's unclear, look it up. Don't guess. Readers (and Google) spot inaccuracies immediately.
Step 3: Create a "Content Brief"
Before writing, jot down:
5–7 key points you'll cover
Sources and data you'll use
Target keywords you want to rank for
The "content gap" – what others missed that you'll include
Why This Matters for SEO:
Google rewards content that demonstrates E-E-A-T (experience, expertise, authoritativeness, trustworthiness). Research is the foundation of all four.
1. Every article must follow the “problem–solution–IMS” structure
Each blog post must follow this global structure:
Problem: clearly explain the challenge or pain point engineers face (e.g., RCM being too resource‑intensive).
Solution: describe the method or approach that solves it (e.g., strategy libraries, risk‑based segmentation).
How to solve it with IMS: show concretely how the IMS RCM tool (or IMS ecosystem) supports that solution (features, workflows, reports).
This structure keeps the article focused, practical, and aligned with your sales and support messaging.
2. Use long‑tail, low‑competition keywords
He should not target generic terms like “Reliability Centered Maintenance” unless absolutely necessary,
Instead, focus on long‑tail, more specific phrases such as:
“Reliability Centered Maintenance risk‑based prioritization”
“RCM maintenance strategy libraries for centrifugal pumps”
“how to reduce RCM resource demand with digital tools”
This makes it easier to rank for specific search intents and match how engineers actually phrase questions.
3. Think about the title first, not at the end
The title often shapes the whole article, so don’t write it as an afterthought.
Ensure it contains the main keyword naturally (e.g., “Reliability Centered Maintenance with strategy libraries”).
Keep it short, clear, and SEO‑friendly (ideally under 60 characters) so it fits search results and passes Yoast checks.
Make it relevant and precise so readers immediately know what the article is about and trust it.
4. Keep paragraphs and subsections short and crisp
Tell him to:
Limit paragraphs to 4–6 sentences;
Keep each section under a subheading short enough that Yoast does not flag it as “too large” (in practice this usually means no more than 2–3 paragraphs per H3/H2).
If a section grows too long, split it into two subsections with more descriptive headings.
This improves readability on mobile, Yoast scores, and engineering‑style clarity.
5. Use active, concise, engineering‑style English
Engineers dislike fluff, marketing‑style phrases, and “salesy” language.
Encourage direct, technical wording:
Use “you” and “we” where appropriate, but keep it professional and factual.
Avoid exaggerated claims; instead, say “can reduce effort”, “typically reduces time”, “may improve consistency”.
This makes the tone respectful of reader expertise and more credible.
6. Mention target roles and audiences in the text
Instead of a generic “for maintenance professionals,” encourage him to name specific roles:
“This approach is useful for integrity teams, corrosion engineers, reliability engineers, and maintenance planners.”
This helps:
Google and readers understand who benefits;
Positions IMS as a practical tool for concrete engineering functions, not a generic marketing concept.
7. Use outbound links only when truly useful
External links should support authority, not accidentally promote competitors.
Prioritize linking to:
Industry standards (ISO, API, etc.),
Academic or professional references (e.g., Moubray RCM II, Cenosco MEI article),
Public statistics or data sources (e.g., government or industry reports).
If there is no strong external reference, he can skip the outbound link rather than forcing a link to a competitor or weak site.
8. Add images, charts, and tables when possible
When writing about numbers, comparisons, or processes:
Note in the draft that a chart or table would help (e.g., “This could be shown as a bar chart: tasks vs. failure modes per equipment type”).
Clearly describe what data to plot (axes, categories, labels) so the designer can create it.
He can embed simple tables directly in the article (e.g., “number of tasks per asset type,” “MEI ranges”), but more complex diagrams should be described and handed off to the designer.
This keeps the content engineer‑friendly and easily visualizable without over‑promising visuals.
9. Use bold for key technical terms, not for marketing
Use bold sparingly and only for technical concepts:
Reliability Centered Maintenance (RCM)
maintenance strategy libraries
risk‑based segmentation
Maintenance Efficiency Indicator (MEI)
Technical Authorities
Avoid bolding generic marketing phrases; bold should highlight concepts engineers actually look up, not sales slogans.
From a readability point of view, light but consistent bolding makes the text easier to scan without overwhelming the eye.
Keep in mind that one or two bolded terms per paragraph is usually enough; more than that starts to look like highlighter abuse rather than real emphasis.
10. Repeat core keywords naturally, not aggressively
Keywords must appear, but not stuffed.
Use your main long‑tail phrases 1–2 times per 80–120 words.
Embed them in real examples:
“In a risk‑based RCM prioritization exercise, the team first segments assets by criticality.”
This keeps the text natural and technical, while still helping SEO.
11. Use internal links to our product pages and articles
He should link from blog posts back to relevant software pages and documentation:
To IMS RCM product page, strategy library features, MEI reports, handbook sections, etc.
Anchor text should be descriptive and technical:
“See the IMS RCM tool’s strategy library feature.”
“For an overview of MEI calculation, see the IMS Handbook.”
This strengthens your internal site architecture and guides users toward product content.
12. Build authority with concrete numbers and examples
Engineers trust numbers and specifics, not vague claims.
“Typical reduction in workshop days when using strategy libraries.”
“Number of tasks per equipment type before and after simplification.”
“How many failure modes per asset are typically covered.”
These numbers can be based on real cases or conservative estimates, but must be plausible and realistic.
13. Use clear H2 and H3 headings aligned with your abstract logic
Headings should mirror the logical flow of the RCM discussion:
Why RCM Can Be Resource‑Intensive
Can RCM Be Simplified Without Losing Effectiveness?
How Maintenance Strategy Libraries Reduce Effort
Risk‑Based Segmentation of Assets
When Full RCM Is Still Necessary
Each H2 should be self‑descriptive and contain the keyword in a natural way if possible.
14. Keep sentences short and active
Yoast often flags long, complex sentences.
Aim for mostly under 20–22 words per sentence.
Use active voice:
“The team identifies failure modes during FMEA.”
“The facilitator leads multi‑day workshops.”
This improves readability scores and keeps the tone professional and technical.
15. Use checklists for implementation steps
When explaining how to apply an idea, turn it into a short checklist:
Example:
“How to implement resource‑efficient RCM:
Segment assets by risk.
Define basic task sets for low‑critical equipment.
Use strategy libraries for common equipment types.
Reserve full RCM for safety‑critical assets.”
Checklists are highly practical and easy to follow in real projects.
16. Write one or two “quotable” lines
Help him craft 1–2 strong, engineer‑friendly sentences that others might reuse or quote:
“Reliability‑Centered Maintenance is not about doing less thinking, but about applying structured thinking more efficiently.”
“Using strategy libraries shifts effort from repeated analysis to repeatable, traceable decisions.”
These lines can support social sharing and backlinks without sounding like marketing.
17. End with a clear call to action tied to IMS
The conclusion should not just repeat the text. Ask the reader to take a concrete next step, aligned with how you usually close articles on cenosco’s site (e.g., via an “Ask for demo”‑style button, not just soft “learn more”):
“To see how this approach works in practice, request a demo of the IMS RCM tool.”
“You can also explore how IMS RCM supports simplified RCM workflows through strategy libraries and digital workflows.”
This turns the article into a practical gateway to your product, matching the CTA‑style you already use on Cenosco (demo, booking, or contact‑driven prompts).
18. Align keyword strategy with your product pages
He should coordinate keywords with your existing product‑page strategy:
Main product pages already target broader terms (e.g., “RCM software,” “Reliability Centered Maintenance”).
Blog posts should focus on more specific, long‑tail phrases that support and feed those pages, not compete with them.
This keeps your SEO ecosystem consistent and avoids cannibalization.
19. Maintain a consistent, engineering‑tone style across posts
Tell him to keep the same style from article to article:
Direct, technical language;
Clear structure (problem → solution → how IMS helps);
Concrete examples, numbers, and references.
This builds branded authority over time and makes your blog feel like a reliable engineering resource, not a random blog.