Tutorial: document a release end to end

This tutorial walks you through documenting a release from the tickets your team shipped. You start from a completed milestone and finish with a single pull request. It updates the affected docs, adds user-facing release notes, and confirms that nothing went stale. The pull request is ready to merge before you launch.

By the end, you can:

• Update the documentation a set of shipped tickets affects, without hunting for the right pages yourself.
• Generate structured, user-facing release notes from the same tickets.
• Ask the agent to check the updated docs for anything the release left out of date.
• Ship everything in one pull request and push a follow-up after review.

The whole path takes about 20 minutes. The Getting started tutorial generates a single README, and document a code change follows one change. This tutorial covers the recurring release ritual: making sure the docs reflect everything that shipped before it reaches users.

Request access

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

Before you begin

You need:

• An EkLine account with Docs Agent enabled.
• A repository connected to EkLine that holds your documentation, and permission to open pull requests on it.
• A connected ticket source. Docs Agent reads releases from Linear or Jira. Connect one under Settings > Organization > Integrations; see Integrations.
• A shipped release to document — a Linear project or milestone, a Jira fixVersion, or an explicit range such as ENG-100 through ENG-110.

You don’t write any code during this tutorial. The work already shipped; you bring the documentation up to date to match it.

Step 1: Open a session

1. Log in to your EkLine dashboard.
2. Click Docs Agent in the left navigation.

Verify: The editor opens with a chat panel on the right, an editor panel on the left, and a toolbar across the top.

Step 2: Update the docs your release affects

Instead of opening each page yourself, hand the release to the agent. When you reference the tickets, the agent reads each one and identifies which documentation the change touches.

In the chat panel, name the release and what changed:

We just shipped the v2.1 release — Linear tickets ENG-100 through
ENG-110. Update the documentation each ticket affects. Focus on
user-facing changes: new features, changed behavior, and anything
we deprecated.

Give the agent the shape of the release

Naming what to look for — features, changed behavior, deprecations — helps the agent decide which pages matter. If a ticket only touches internal tooling, tell it to skip that ticket so the release stays focused on what users see.

Verify: The agent reads each ticket, reports the pages it plans to change, and writes the updated documentation to the editor panel on the left.

Step 3: Review the doc updates

Never ship the first draft unread. The agent is accurate, but you know what shipped — confirm each change before going further.

1. Enable View All Changes in the toolbar to see a diff of every page the agent touched.
2. Check three things across the changes:
   • Coverage — Does every user-facing ticket in the release show up somewhere in the docs?
   • Accuracy — Does each update describe the change the way it actually behaves?
   • Scope — Did the agent leave unrelated content alone?
3. Refine anything that reads inaccurately with a follow-up prompt rather than editing by hand — for example, Move the rate-limiting change into the API reference instead of the getting-started guide. The agent keeps the context from your first prompt and updates the same drafts.

Verify: The diff shows the pages your release affected, updated to match what shipped, with no unrelated content removed.

Step 4: Generate release notes from the same tickets

The docs now describe the new behavior. Next, produce the user-facing summary that announces it. The agent reads the same tickets and rewrites the work in plain language.

Send a prompt that names the version, the sections, and the audience:

Generate release notes for v2.1 from the same tickets. Group them
under Features, Improvements, and Bug Fixes. Write for end users,
one sentence per item, and add the new version at the top of
CHANGELOG.md.

The agent summarizes each ticket from the user’s perspective rather than copying the ticket text, so internal shorthand stays out of the published note.

Verify: A new v2.1 entry appears at the top of CHANGELOG.md in the editor, grouped into the sections you named, with one plain-language line per shipped ticket.

Step 5: Check for anything the release left stale

A release often changes behavior that older pages still describe the old way. Before you publish, ask the agent to review its own work against the release.

Review the pages you changed for this release. Flag anything that
still describes the old behavior, any feature we shipped that no
page mentions, and any example that no longer matches the release.

The agent returns a checkpoint covering clarity, completeness, accuracy, and consistency. Treat each flagged item as a to-do: ask the agent to fix the ones that matter, the same way you refined the drafts in Step 3.

Verify: The checkpoint reports no remaining gaps for the release, or you resolve each one it raises with a follow-up prompt.

Step 6: Ship one pull request

When the docs and the release notes both match what shipped, ship them together through your normal review process.

1. Click Raise PR in the toolbar. If your changes span more than one repository, the toolbar shows a PRs dropdown instead — open it and select Raise PR on the repository you want.
2. The agent prefills a prompt such as Open a pull request. Edit it to add a title or description if you want, then press Enter.
3. The agent creates the pull request and replies in the chat with a link to it on GitHub.

Verify: The chat shows a link to a new pull request. Open it — the PR has your doc updates and release notes for the release, and nothing else.

Step 7: Push a follow-up after review

A reviewer often spots a late-arriving ticket or a wording change. You don’t need a new session — push the fix to the same pull request.

1. Back in the editor, ask the agent for the change. For example: A late ticket, ENG-111, also shipped in v2.1. Add it to the release notes under Bug Fixes and update any docs it affects.
2. Click Update PR in the toolbar.
3. The agent prefills a prompt like Update pull request #42 with my latest changes. Press Enter.

Verify: The agent commits to the existing PR branch and confirms in the chat. Refresh the pull request on GitHub — the new commit appears in its history.

Summary

You took a shipped release from a list of tickets to a review-ready pull request. Along the way you:

• Updated the documentation each ticket affected, letting the agent find the right pages.
• Generated user-facing release notes from the same tickets.
• Checked the updated docs for anything the release left stale.
• Shipped the doc updates and the release notes in one pull request, then pushed a follow-up after review.

This is the ritual you repeat every release. The more precisely you name the release and what changed, the closer each draft lands — and the less your docs lag behind what your users already have.

Next steps

• Generate release notes from completed tickets — More ways to structure, group, and template release notes.
• Update and review documentation — Update from tickets, commits, or specific sections, and get feedback on existing content.
• Prevent documentation drift — Catch out-of-date docs automatically with automatic PR review and a scheduled audit.
• Automate release notes — Draft release notes on a recurring cadence with a scheduled agent.