EkLine configuration file reference

The EkLine CLI reads its settings from an ekline.config.json file. Store the file in your project to keep review settings consistent across your team and your CI/CD pipelines, instead of repeating flags on every run.

This page documents every supported configuration key, its type, default value, and behavior. For installation and command-line usage, see the CLI integration guide.

File location and discovery

The configuration file must be named ekline.config.json and contain a single JSON object:

{
  "contentDirectory": ["docs"],
  "styleGuide": "google",
  "ignore": ["EK00001", "EK00004"],
  "excludeDirectories": ["node_modules", "dist"]
}

EkLine searches for the file starting from the current working directory and walks up the directory tree to the filesystem root. The first valid file it finds is used. This supports monorepos where the configuration lives at the repository root:

my-monorepo/
├── ekline.config.json    ← Found and used
├── packages/
│   └── docs/
│       └── guide.md       ← Running the CLI here still finds the root config
└── apps/
    └── web/

Caution

Never store your ekToken in ekline.config.json. Pass it with the --ek-token flag instead, and use your platform’s secret management in CI/CD. EkLine warns you if it finds a token in the configuration file.

Configuration precedence

Command-line arguments override values in the configuration file, so you can share one file and customize individual runs:

# Uses the config file, but overrides styleGuide for this run
ekline-cli --ek-token YOUR_TOKEN --style-guide microsoft

Order of precedence, from highest to lowest:

1. Command-line arguments
2. ekline.config.json
3. Default values

Configuration keys

Key	Type	Default	Description
contentDirectory	string[]	["."]	Directories or files to scan for documentation.
ignore	string[]	—	Rule IDs to disable across the whole project.
excludeFiles	string[]	—	Files to exclude from review.
excludeDirectories	string[]	—	Directories to exclude from review.
styleGuide	string	—	Style guide to enforce: google, microsoft, or marketing.
framework	string	—	Documentation framework: mintlify, astro, fern, docusaurus, or gitbook.
openapiSpec	string	—	Path to an OpenAPI spec for API terminology validation.
changedFiles	string[]	—	Restrict the review to a specific list of files.
changedLines	string	—	Path to a JSON file mapping changed files to line numbers.
aiSuggestions	boolean	false	Enable AI-powered suggestions.
suggestion	boolean	true	Include suggestions in file output.
output	string	Terminal	Output file path. The extension selects the format.

Note

EkLine rejects unknown keys, so a misspelled key causes the file to be ignored. Check your key names against this table if your settings don’t take effect.

---

Content selection

contentDirectory

string[] — default ["."]

One or more directories or files to scan, relative to where you run the CLI. Paths that don’t exist are skipped with a warning.

{
  "contentDirectory": ["docs", "guides", "packages/sdk/docs"]
}

changedFiles

string[]

Restrict the review to a specific list of files. This is useful in CI to check only the files touched by a pull request.

{
  "changedFiles": ["docs/guide.md", "docs/api.md"]
}

changedLines

string

Path to a JSON file that maps changed files to their changed line numbers. EkLine reviews only those lines, which speeds up checks on large repositories.

{
  "changedLines": "git-diff-changes.json"
}

---

Ignoring rules

When EkLine flags content you want to keep, you have three options:

Situation	Recommended action
EkLine is right — fix the issue	Edit your content
False positive on specific content	Use an inline ignore comment
Rule doesn’t apply to your project	Disable the rule with ignore

Tip

Before ignoring, consider whether the flag is correct. EkLine catches real issues that are often overlooked.

ignore

string[]

Rule IDs to disable across your entire project. These rules are not checked anywhere.

{
  "contentDirectory": ["docs"],
  "ignore": ["EK00001", "EK00004"]
}

To disable a rule for specific content only, use an inline ignore comment instead.

Finding the rule ID

When EkLine flags an issue in a pull request comment or CLI output, the rule ID appears in brackets:

[EK00300] "responce" should be "response"

The rule ID, such as EK00300, is what you add to ignore or to an inline comment to target a specific rule.

---

Excluding files and directories

Use excludeFiles and excludeDirectories to skip content that shouldn’t be reviewed at all, such as generated files. Use ignore for rules that don’t fit your style, and use inline comments for specific exceptions within otherwise-checked content.

excludeFiles

string[]

Files to exclude from review, relative to your content directories.

{
  "contentDirectory": ["docs"],
  "excludeFiles": ["CHANGELOG.md", "generated/api.md"]
}

excludeDirectories

string[]

Directories to exclude from review. A directory and everything under it is skipped.

{
  "contentDirectory": ["docs"],
  "excludeDirectories": ["node_modules", "api-reference/generated"]
}

---

Style and framework

styleGuide

string — one of google, microsoft, marketing

The public style guide to enforce. An unrecognized value is ignored with a warning.

{
  "styleGuide": "google"
}

For details, see Choose and apply a style guide.

framework

string — one of mintlify, astro, fern, docusaurus, gitbook

The documentation framework, which improves MDX analysis. Set it so EkLine checks prose inside framework components such as <Note> and <Card>. An unrecognized value is ignored with a warning.

{
  "framework": "mintlify"
}

For details, see Framework support.

openapiSpec

string

Path to an OpenAPI spec file. EkLine uses it to validate API terminology in your documentation.

{
  "openapiSpec": "openapi.yaml"
}

---

Suggestions and output

aiSuggestions

boolean — default false

Enable AI-powered documentation suggestions.

{
  "aiSuggestions": true
}

suggestion

boolean — default true

Include suggestions in file output. Suggestions appear in .jsonl and .csv output, not in terminal output.

{
  "suggestion": false
}

output

string — default: terminal

Output file path. The file extension selects the format: .jsonl or .csv. Without this key, results print to the terminal.

{
  "output": "ekline-report.jsonl"
}

---

Inline ignore comments

Inline comments ignore rules for specific content without changing your configuration file. They are the per-content companion to the ignore key.

File format syntax

The comment syntax varies by file type. EkLine detects the format automatically.

Markdown / HTML

<!-- ekline-ignore-file -->
<!-- ekline-ignore-start -->
<!-- ekline-ignore-end -->
<!-- ekline-ignore-next-line EK00001 -->
<!-- ekline-ignore-line -->

File types: .md, .markdown, .html, .htm, .xml, .dita, .ditamap

MDX

JSX comments (preferred):

{/* ekline-ignore-file */}
{/* ekline-ignore-start */}
{/* ekline-ignore-end */}
{/* ekline-ignore-next-line EK00001 */}
{/* ekline-ignore-line */}

HTML comments also work in MDX files.

File types: .mdx

AsciiDoc

// ekline-ignore-file
// ekline-ignore-start
// ekline-ignore-end
// ekline-ignore-next-line EK00001
// ekline-ignore-line

File types: .adoc, .asciidoc

YAML front matter

Inside the leading --- fence, use YAML’s # comment syntax:

---
# ekline-ignore-next-line EK00001
title: Choose your favourite colour
description: A guide # ekline-ignore-line EK00002
---

EkLine analyzes front matter field values (such as title and description), so those fields can raise issues. HTML and JSX comments are not valid inside a YAML front matter block, so ignore comments there use # instead.

File types: .md, .markdown, .mdx (inside the leading --- fence only)

Note

The # syntax is recognized only between the opening --- and its matching closing --- at the top of the file. Elsewhere, # remains a Markdown heading. All command types, rule-specific ignores, and -- reason suffixes work the same as the other formats.

Scope reference

Scope	Syntax
Entire file	<!-- ekline-ignore-file -->
Section	<!-- ekline-ignore-start --> … <!-- ekline-ignore-end -->
Next line	<!-- ekline-ignore-next-line -->
Same line	<!-- ekline-ignore-line -->

Add rule IDs to target specific rules: <!-- ekline-ignore-next-line EK00001 -->

Add a reason after -- to document why: <!-- ekline-ignore-next-line EK00001 -- legacy naming -->

Ignoring the next line

The most common pattern. Place the comment on the line before the content you want to ignore.

<!-- ekline-ignore-next-line -->
This line won't be checked.

This line will be checked normally.

With specific rules:

<!-- ekline-ignore-next-line EK00001, EK00033 -->
Only those rules are ignored. Other rules still apply to this line.

Ignoring the current line

Add the comment at the end of the line you want to ignore.

The `oldParam` field is deprecated. <!-- ekline-ignore-line EK00001 -->

Ignoring a section

Wrap content in start and end comments to ignore a block.

Regular checked content here.

<!-- ekline-ignore-start -->
Everything in this section is ignored.
Multiple lines, code blocks, whatever you need.
<!-- ekline-ignore-end -->

Back to checked content.

With specific rules:

<!-- ekline-ignore-start EK00001, EK00002 -->
Only the specified rules are ignored in this section.
<!-- ekline-ignore-end -->

Ignoring an entire file

Place the comment anywhere in the file. The top is recommended.

<!-- ekline-ignore-file -->

# Auto-generated reference

All content in this file is ignored.

With specific rules:

<!-- ekline-ignore-file EK00001 -->

Adding reasons

Document why you’re ignoring a rule. This helps future maintainers, including yourself, understand the decision.

<!-- ekline-ignore-next-line EK00300 -- intentional for backwards compatibility -->
<!-- ekline-ignore-start EK00031 -- passive voice required by legal -->
<!-- ekline-ignore-file -- generated from OpenAPI spec -->

Inline comment behavior

• Case insensitive: EKLINE-IGNORE-FILE works the same as ekline-ignore-file.
• Flexible whitespace: Extra spaces are tolerated.
• Code blocks excluded: Comments inside fenced code blocks (```) are not processed.
• Unclosed sections: An ekline-ignore-start without an ekline-ignore-end extends to the end of the file.
• Front matter scope: The # comment syntax works only inside the leading --- fence of markdown-family files. A body heading like # ekline-ignore-file is treated as a heading, not an ignore comment.

---

Common scenarios

Quotations you can’t change

Customer quotes, legal text, or historical references often violate style rules intentionally.

<!-- ekline-ignore-next-line EK00300 -- customer testimonial, preserve original spelling -->
"I definately love this product!" - Jane D.

Legacy API naming

Old APIs sometimes have typos baked into their contracts.

<!-- ekline-ignore-next-line EK00300 -- legacy API field name -->
The endpoint returns a `responce` object for backwards compatibility.

Code examples with intentional errors

Documentation showing what not to do, or demonstrating error messages.

<!-- ekline-ignore-start -- example of incorrect usage -->
```js
// DON'T do this - the parameter is misspelled
fetch('/api?qurey=test')
```
<!-- ekline-ignore-end -->

Required passive voice

Legal text and formal contracts sometimes require passive voice.

<!-- ekline-ignore-next-line EK00031 -- passive voice required by legal -->
The agreement must be signed by the customer before activation.

Auto-generated files

For files generated from OpenAPI specs or other sources, use excludeFiles in your configuration rather than an inline comment. That way you don’t need to preserve the comment when regenerating the file.

{
  "excludeFiles": ["api-reference/generated.md"]
}

Project-wide rule decisions

If you find yourself adding the same inline ignore repeatedly, disable the rule in the configuration file instead.

{
  "ignore": ["EK00042"]
}

---

Example configurations

Minimal:

{
  "contentDirectory": ["docs"]
}

Mintlify project:

{
  "contentDirectory": ["."],
  "framework": "mintlify",
  "excludeDirectories": ["node_modules", "api-reference"],
  "styleGuide": "google"
}

Monorepo with many doc sources:

{
  "contentDirectory": ["docs", "packages/sdk/docs", "guides"],
  "excludeFiles": ["CHANGELOG.md"],
  "ignore": ["EK00042"]
}

Full configuration:

{
  "contentDirectory": ["docs"],
  "framework": "astro",
  "styleGuide": "microsoft",
  "ignore": ["EK00001", "EK00004"],
  "excludeDirectories": ["node_modules", "dist", ".astro"],
  "excludeFiles": ["README.md"],
  "output": "ekline-report.jsonl",
  "aiSuggestions": true
}

---

Best practices

Prefer targeted ignores

Instead of ignoring all rules, target the specific rule causing the issue.

// Bad - ignores everything
<!-- ekline-ignore-next-line -->

// Good - only ignores the specific rule
<!-- ekline-ignore-next-line EK00001 -->

Always add reasons

A reason takes seconds to write and saves minutes of confusion later.

// Bad - future you won't remember why
<!-- ekline-ignore-next-line EK00001 -->

// Good - clear intent
<!-- ekline-ignore-next-line EK00001 -- legacy API naming -->

Review ignores periodically

Inline ignores can become stale. When updating documentation:

• Check whether the ignored content still exists.
• Check whether the reason still applies.
• Remove ignores that are no longer needed.

---

Related

• Choose and apply a style guide — Pick and enforce a writing standard for the styleGuide key
• Add words to your dictionary — Accept product names and jargon instead of ignoring the spell-check rule
• CLI integration — Install the CLI and run reviews
• Framework support — MDX component handling for documentation frameworks