Skip to main content

​
Genow Help Center – Claude Instructions

​
General Rules

  • All articles are written in English
  • Tone is friendly, direct, and non-technical
  • Explain dependencies and terms briefly in simple language
  • Never be overly verbose – keep sections concise and to the point
  • NEVER touch, edit, or generate any content in the /api-reference/ section

​
Article Structure

Every article follows this structure:
  1. Frontmatter (title, description, optional tag)
  2. Short definition – one sentence explaining what this article covers
  3. Short description of the Frontmatter – brief note on what the header fields mean
  4. Sections separated by horizontal rules (---)
  5. Each section starts with an H2 heading (##)
  6. Subsections use H3 (###)

​
Frontmatter Format

---
title: "Article Title"
description: "Short description of what this article covers."
---
Optional tag for updated articles: 
---
title: "Article Title"
tag: "UPDATED"
---

​
Formatting Conventions

​
Horizontal Rules

Use --- before every new H2 section heading to separate content blocks.

​
Highlighting Buttons and UI Elements

Wrap all Genow UI buttons (mostly described with “click on”, “select” etc.) , labels, and interactive elements in Button Name:
  • Click Save to confirm
  • Navigate to Settings → Permissions

​
Callout Components

Use Mintlify callout components to highlight important information. Never overuse them – one per logical block maximum.
ComponentWhen to use
<Note>Important context the user should know
<Warning>Critical information, risk of errors
<Info>Helpful but non-critical additional info
<Check>Benefits, positive outcomes
Example: 
<Note>
  Your questions and data are never used to train AI models. 
  We are GDPR compliant.
</Note>

​
Steps Component

Use for sequential processes: 
<Steps>
  <Step title="Step Title">
    Description of what to do.
  </Step>
</Steps>

<Card title="Related Topic" icon="link" horizontal href="/section/article">
  Click here to learn more about this topic.
</Card>

​
Frames (Screenshots)

<Frame>
  <img src="/images/filename.png" style={{ width:"100%" }} />
</Frame>

​
Tabs

Use when content differs by user type or configuration method: 
<Tabs>
  <Tab title="Option A">
    Content for option A.
  </Tab>
  <Tab title="Option B">
    Content for option B.
  </Tab>
</Tabs>

​
Section-Specific Guidelines

​
Product / User Guides

Audience: End users – employees using Genow day-to-day.
  • Non-technical language
  • Avoid jargon; if a term must be used, explain it briefly
  • Focus on what the user needs to do, not how it works technically
  • Use Steps components for any process with more than two actions
  • Keep explanations short – users want to find answers quickly
Example tone: Instead of: “The system performs a vector similarity search across indexed knowledge sources” Write: “Genow searches through the connected documents to find the most relevant information”

​
Use Case Management (Agents)

Audience: Use Case Administrators / Domain Experts
  • These are team leads or subject-matter experts managing their own Agent
  • An Agent = a dedicated area for an organisational unit (formerly called “Use Case”)
  • Admins select knowledge, configure settings, sync data, and make it available to their team
  • Semi-technical tone – explain what settings do, but no deep technical background needed
  • Briefly explain dependencies between concepts (e.g. knowledge sources → knowledge assets → agent)
Example tone: Instead of: “Configure the retrieval pipeline parameters” Write: “Choose which documents Genow should search through when your team asks questions”

​
Platform Management

Audience: System Administrators / IT Department
  • Technical tone is appropriate here
  • Cover full setup steps that affect the entire platform
  • Include IDs, configuration values, and exact navigation paths
  • Use Warning callouts for steps that could affect all users
  • Tables are appropriate for permissions, roles, and configuration options

​
Git Workflow

Always follow this workflow for every change session:
  1. Create a new branch from docs before making any changes: 
    git checkout docs
git checkout -b <branch-name>
  2. Make all changes on that branch.
  3. At the end of the session, remind the user to push the branch and create a PR — then merge into docs.
Branch naming convention: feature/, fix/, or rename/ prefix followed by a short description (e.g. rename/agent-hub-naming, fix/broken-links).

​
What Claude Must Never Do

  • Never edit, create, or modify any file in /api-reference/
  • Never add an article to mint.json navigation under the api-reference section
  • Never remove existing Mintlify components (Note, Warning, Steps, etc.) without being explicitly asked
  • Never translate articles into German – all content stays in English