Skip to content

Combine multiple sources into one document

The full story of a feature is rarely in one place. The implementation lives in a pull request, the requirements sit in a Jira or Linear ticket, the edge cases surface in a Slack thread, and the original design lives in a Notion or Confluence spec. This guide shows you how to hand all of those sources to Docs Agent in a single prompt so it reconciles them into one document and opens a pull request for review.

You need:

  • An EkLine account with Docs Agent enabled.
  • At least one documentation repository connected to EkLine.
  • The integrations that hold your sources connected under Settings > Organization > Integrations. See Integrations to connect Slack, Notion, Linear, Jira, Confluence, Google Drive, GitLab, and PostHog.
  • Permission to view each source. The agent reads content using your own access, so it can only pull sources you can already open.

When you reference several sources in one prompt, the agent fetches each one, combines what it learns, and writes a single document that draws on all of them:

  1. Fetch — The agent recognizes each URL or ticket ID and pulls the content from the connected integration.
  2. Reconcile — It reads every source together, resolves overlaps, and decides which detail belongs in which section.
  3. Draft — It writes one document grounded in the combined context and places it in your repository.
  4. Review — You check the draft in the editor, iterate in the chat, and open a pull request.

The more each source contributes a distinct piece — requirements, implementation, edge cases, design intent — the more complete the result.

  1. Gather the sources that describe the same topic. For a feature launch, that is often the ticket, the pull request, the Slack thread where the team discussed it, and the original spec.

  2. Open Docs Agent and write one prompt that lists every source and states what to produce. Paste exact URLs or ticket IDs — the agent recognizes the service automatically:

    Write a feature guide for our new rate limiting, drawing on:
    - Linear ticket ENG-1234 for the requirements
    - GitHub pull request #482 for the implementation details
    - This Slack thread for the edge cases the team found:
    https://workspace.slack.com/archives/C01234/p1234567890
    - The original design in Notion:
    https://notion.so/your-workspace/rate-limiting-spec
    Put it in the docs repo under guides/. Cover what rate
    limiting does, the default limits, the response headers,
    and how to handle a 429 error.
  3. Wait while the agent fetches each source and drafts the document. It reports the sources it read as it works.

  4. Review the draft in the editor panel. Confirm that each source contributed the part you expected — requirements from the ticket, behavior from the pull request, edge cases from the thread.

The agent produces a sharper document when your prompt assigns a purpose to each source and names the output.

Instead of…Try…
”Document this feature from ENG-1234 and PR #482""Write a feature guide for rate limiting. Use ENG-1234 for the requirements and PR #482 for the implementation details."
"Combine these links into docs""Create one deployment guide from the runbook in Confluence and the checklist in this Slack thread. Prefer the runbook where they disagree."
"Update the API docs with everything about auth""Update the authentication reference using ENG-1234 (the OAuth change) and PR #501 (the new token endpoint). Keep the existing structure.”

Include in your prompt:

  • Each source as an exact URL or ticket ID.
  • What each source contributes.
  • The document type and where it belongs in your repository.
  • The sections you want, so the agent maps sources onto structure.

Sources drift. A ticket describes the plan, but the pull request ships something slightly different; a spec predates the final design. When sources disagree, tell the agent which one wins:

Where the Notion spec and PR #482 disagree, follow the pull
request — it reflects what actually shipped. Note any
requirement from ENG-1234 that the PR did not implement.

If you don’t set a precedence, the agent flags the conflict in the chat so you can decide. Ask it to reconcile a specific difference, and it revises the affected section.

  1. Enable View All Changes in the toolbar to see a diff of everything the agent wrote. Confirm no source was dropped and no section mixes up details from different sources.

  2. Check that claims trace back to a source. If a detail looks unsupported, ask the agent where it came from — for example, Which source says the default limit is 100 requests per minute?

  3. Click Raise PR in the toolbar. The agent prefills a prompt in the chat panel — press Enter to send it, or edit it first to add instructions.

  4. The agent opens the pull request and replies with a link where you finish the review on GitHub.

The agent validates links and email addresses in the generated content and regenerates any section with a broken reference before you open the pull request.

ProblemCauseFix
A source was skippedThe integration isn’t connected, or you lack access to that sourceConnect the integration under Settings > Organization > Integrations, confirm you can open the source yourself, then reference it again.
The draft leans on one sourceThe prompt didn’t say what each source contributesRestate the prompt and assign a role to each source, such as “use the ticket for requirements, the PR for behavior.”
Details from two sources are mixed upThe sources overlap and no precedence was setTell the agent which source wins for the overlapping topic, then ask it to revise that section.
The agent asks which source to trustTwo sources give conflicting factsReply with the source of truth — for example, “follow the pull request; the spec is outdated.”
A pasted link isn’t recognizedThe URL is malformed, or the service isn’t connectedPaste the exact URL from the source, and confirm the matching integration is connected.