Rename a feature across all your docs

Request access

Docs Agent is available to all plans, but we grant access on request. Contact support@ekline.io to request access.

When you rename a feature, change a product name, or update a price, the old wording lingers in dozens of pages — headings, body text, captions, and example code. Missing a few is how docs end up contradicting the product.

This guide shows you how to make one consistent change across your entire documentation set in a single Docs Agent session. The agent searches the whole repository, updates every occurrence and its variations, shows you the full diff, and opens one pull request for review.

A site-wide rename is more than find-and-replace. Capitalization, plurals, possessives, and link text all shift with the term, and some occurrences — a code identifier, a URL slug, a changelog entry — must stay exactly as they are. The agent handles the difference when you tell it the boundary.

Before you begin

You need:

• An EkLine account with Docs Agent enabled. Don’t have access? Email support@ekline.io with your organization name.
• A documentation repository connected to EkLine. GitLab works too — connect GitLab instead.
• Permission to open pull requests on that repository.

Step 1: Describe the change and its scope

Open the editor and tell the agent three things: the old term, the new term, and where the change applies. Name what to leave alone in the same prompt so the agent doesn’t over-reach.

1. Log in to your EkLine dashboard and click Docs Agent in the left navigation.

2. In the chat panel, describe the rename and its boundary:

   We renamed the "Workspace" feature to "Project" across the product.
   Update every mention in the docs/ folder to use "Project" — headings,
   body text, captions, and prose in code examples. Leave URL slugs, file
   names, and code identifiers like `workspaceId` unchanged.

State what not to change

The boundary matters as much as the change. Call out code identifiers, URL slugs, file names, and historical changelog entries you want preserved, so a broad rename doesn’t rewrite an API field or break a permalink.

Verify: The agent responds in the chat and begins reading your repository.

Step 2: Let the agent find every occurrence

The agent searches your whole connected repository, not only the files you name. It finds occurrences you might miss — a term buried in a troubleshooting page, an image caption, or a comment inside an example.

Verify: The agent reports the files it plans to change and drafts the edits in the editor panel on the left.

Step 3: Cover the variations

A term can appear in multiple forms. Plurals, adjectives, and link text all need to move together, while lookalike words that mean something else must stay. Send a follow-up to catch the variations:

Plurals and forms

Also update the variations: "Workspaces" to "Projects" and
"workspace-level" to "project-level". Keep the sentence grammar
correct after each change.

Link text

Update the anchor text of any link that reads "Workspace" or
"Workspaces" to match the new term. Leave the link URLs unchanged.

Avoid false matches

Don't change the word "workspace" where it refers to a VS Code
workspace — that's a different concept. Only rename our product feature.

The agent updates the same draft rather than starting over, so each follow-up refines the change in place.

Step 4: Review the full diff

A site-wide change touches many files, so review it as a whole before you ship.

1. Enable View All Changes in the toolbar to see a diff of every modification across all files.

2. Scan for the three failure modes of a bulk rename:

   • Over-eager matches — A word that matched the pattern but meant something else.
   • Broken links — Anchor text renamed but a target left stale, or the reverse.
   • Preserved-term drift — A code identifier, URL, or filename changed when you asked to keep it.

Verify: The diff shows the new term throughout your prose, with the identifiers, slugs, and file names you named still intact.

Step 5: Fix misses with a follow-up

Reviewing a large change almost always surfaces a straggler. Point the agent at it instead of editing by hand:

You missed the term in docs/billing.md, and you changed `workspaceId`
in the API example — revert that identifier back. Everything else
looks right.

The agent applies the correction to the current draft. Repeat until the diff is clean.

Step 6: Open a single pull request

Ship the whole rename as one reviewable change.

1. Click Raise PR in the toolbar.

2. The agent prefills a prompt such as Open a pull request. Edit it to add a title or description — for example, Rename Workspace to Project across the docs — then press Enter.

3. The agent creates the pull request and responds in the chat with a link to it.

Verify: The chat shows a link to one pull request that contains every renamed page and nothing unrelated.

Note

If your session spans multiple repositories, the toolbar shows a PRs dropdown in place of the Raise PR button. Open it and raise a pull request for each repository the rename touched.

Troubleshooting

Problem	Cause and fix
The agent changed a code identifier or URL you wanted to keep	The boundary wasn’t explicit. Ask it to revert that specific change and name what to preserve — for example, tell it to restore the original identifier and leave all code identifiers untouched.
The agent missed a file	Name the file or section directly, and confirm the path is inside a connected repository.
Too many changes to review at once	Scope the rename by directory and run it in batches — "Only update docs/api/ for now" — then repeat for the next directory.
The old term still appears in a screenshot	The agent edits text, not pixels. Recapture or edit the image separately with Keep screenshots up to date or Edit documentation images.

Next steps

• Customize for your organization — Record the new term in your custom instructions so the agent uses it in every future draft.
• Manage a knowledge base — Apply the same rename to a connected Confluence or Pylon knowledge base.
• Update and review documentation — Keep docs in sync when the code behind a feature changes, not only its name.
• Combine multiple sources into one document — Pull a ticket, pull request, and spec into a single authoritative page.