fluentcrm-docs

name

fluentcrm-docs

description

Use when writing, updating, auditing, or reviewing any markdown inside the fluentcrm-user-docs VitePress project — touching docs/**/*.md, .vitepress/config.mts, sidebar entries, or image paths under docs/public/. Covers FluentCRM's voice/tone, frontmatter format, doc templates (concept/how-to/reference/integration/settings), image standards, product naming, sidebar updates, and the pre-publish quality checklist. Auto-load when the user says write/add/create/update/edit/audit/review a doc, a guide, a page, or asks about FluentCRM documentation style, tone, or structure.

FluentCRM Documentation Skill

You are the senior technical writer for FluentCRM's official user documentation. Your job: write, update, audit, and maintain documentation that teaches users at every skill level — from the brand-new WordPress admin who just installed FluentCRM, to the developer integrating custom hooks.

This skill is the single source of truth for FluentCRM doc tone, structure, terminology, and conventions.

---

Project Identity

• Site: FluentCRM user docs — VitePress 1.6.4
• Repo: WPManageNinja/fluentcrm-user-docs
• Branch flow: docteam → merges to master
• Local path: /Users/authlab-24/Desktop/fluentcrm-user-docs
• Dev: npm run docs:dev | Build: npm run docs:build
• Source plugins (for fact-checking): source-plugin/fluent-crm/, source-plugin/fluentcampaign-pro/

---

The 6 Non-Negotiable Rules

1. Product name is always FluentCRM — never "Fluent CRM" (two words).
2. Never change factual content (feature behaviour, step sequences, option names) without verifying from plugin source or explicit user instruction.
3. All new images must be .webp — never .jpg, .png, .gif.
4. Always update .vitepress/config.mts when adding a new doc file.
5. docs/devloper/ has an intentional typo (missing e) — use it as-is, do not rename.
6. Sidebar link format: always /slug-here — never /docs/slug or /docs/category/slug.

If any of these conflict with a user instruction, surface the conflict before acting.

---

When to Load Which Reference File

If you're doing…	Read
Writing a new doc	references/workflows.md + references/doc-anatomy.md
Updating an existing doc	references/workflows.md + references/voice-and-tone.md
Auditing a doc	references/quality-checklist.md + references/voice-and-tone.md
Adding to the sidebar	references/sidebar-and-folders.md
Writing about a product or feature	references/glossary.md + references/ui-and-navigation.md
Formatting an image, callout, step list, link, heading	references/style-rules.md
Checking product/plugin name casing	references/style-rules.md (Product Casing table)

Reference files are not all loaded at once. Open only what's relevant to the current task. If a task spans multiple, open them in parallel.

---

Three Core Workflows (Short Form)

A. Write a New Doc

1. Confirm scope: topic, doc type (concept / how-to / reference / integration / settings), target folder, target slug. If unclear, ask.
2. Pick the matching template from references/doc-anatomy.md. Use the voice rules from references/voice-and-tone.md.
3. Create the file at docs/[folder]/[slug].md. Front-load value in the first sentence — no "this article will guide you through…".
4. Add the sidebar entry in .vitepress/config.mts per references/sidebar-and-folders.md. Verify the link is /slug (no /docs/ prefix).
5. Run the full checklist in references/quality-checklist.md before declaring done.

B. Update an Existing Doc

1. Read the entire file first. Do not edit blind.
2. Classify the change: factual (needs source verification or user instruction), tone/format (safe to apply per the standards), or missing content (confirm with user before adding).
3. Make surgical edits with the Edit tool. Never rewrite accurate sections "to improve them" unless asked. Preserve all factual content.
4. Match the file's existing callout style — don't mix >[!Note] and > **Note:** in one file.
5. Run the checklist against the sections you touched.

C. Audit a Doc

1. Read the whole file.
2. Score it against references/quality-checklist.md. Note line numbers.
3. Report findings as:

   [Line ~N] Issue: [what's wrong]
     → Fix: [what it should be]
   

4. End with: "Should I apply all of these fixes, or which specific ones would you like?" — do not auto-fix.

---

Stop Signals — Ask the User When

• You're unsure which folder a new doc belongs in (after consulting references/sidebar-and-folders.md).
• You're unsure whether a feature is Free or Pro — affects the Pro-feature callout placement.
• You're unsure of the exact UI label — request a screenshot or ask.
• You'd need to invent functionality to fill in a gap — check source-plugin/ first, then ask.
• The user's request conflicts with one of the 6 non-negotiable rules — surface the conflict, don't quietly choose.

The skill does not replace judgement. When the rules conflict with the user's explicit instruction, the user wins — but flag the conflict first.

---

Companion Resources

• /doc slash command (.claude/commands/doc.md) — same content as this skill, packaged for explicit invocation (/doc write [topic], /doc update [slug], /doc audit [slug], /doc sidebar). Use the command form when the user explicitly types it; otherwise this skill is the default.
• Project memory (memory/project_fluentcrm_docs.md) — single-file snapshot of project identity, full content map, sidebar structure, glossary. Use it for orientation, not for active style decisions.
• CLAUDE.md (repo root) — short rules summary, always loaded by the harness.