A coding agent can inspect a service’s implementation and still miss the reason it works that way. The code may show a cache key; a Confluence decision explains why the tenant identifier must be part of it. A deployment script may be in the repository while the rollback procedure lives in a separate runbook.
One way to bring that context into the task is to mirror approved Confluence documentation into GitHub as Markdown and make the mirror available to the agent. Conf2Git maintains the repository copy. Your agent’s workspace or retrieval configuration determines whether it can read it.
Start with the task and its access requirements
For a change to request authentication, useful context might include an architecture decision, API conventions, and a credential-rotation procedure. Choose relevant documents and review whether the destination repository and AI tools are appropriate for that information.
Exported files have their own readers. Confluence restrictions do not become per-page access controls in a Git checkout, and copies in local folders or indexes need their own access policy.
If an approved direct Confluence connection already meets your needs, consider using it. A repository mirror is useful when you want readable local files, an identifiable Git revision, or reusable input to your own retrieval system.
Inspect the mirror before giving it to an agent
Use the first-sync walkthrough to create a mirror on a dedicated branch. Read representative output and review conversion warnings. Native output uses page.md files with source metadata, as described in the OKF article.
Check that the decisions and procedures survive conversion. Dynamic macros and included content can become links or placeholders; a diagram image does not guarantee that a text-only agent can interpret it. Put essential rules in source text and check the conversion guide for the constructs you use.
Make the correct branch available
An integration reading only the default branch may never see the mirror. For an agent that reads local files, a separate checkout is one option. Replace the placeholders and confirm the branch exists before running:
git clone --branch confluence-sync --single-branch https://github.com/YOUR-ORG/YOUR-DOCS-REPO.git knowledgeThe branch name must match your mapping. Git’s clone reference explains these options. Use your agent’s supported workspace configuration to make knowledge readable; cloning outside its allowed directories does not grant access.
For remote environments or retrieval systems, configure equivalent repository access, branch selection, and ingestion. Ask the consumer to locate a known page and report its path before relying on it.
Give the agent a question it can verify
Here is a synthetic example. Imagine an architecture decision in the mirror contains this passage:
For the shared response cache, every cache key must include both the tenant identifier and the request-specific resource identifier. Two tenants requesting the same resource identifier must not share a cached response.
With the mirror available, a task prompt could be:
Before changing the response-cache key:
1. Search the knowledge folder for the tenant-isolation decision.
2. Cite the file path and the passage defining the cache-key rule.
3. Compare that rule with the current implementation.
4. Propose the smallest change and a test showing that two tenants
requesting the same resource cannot receive each other's cached response.
If the document is missing or conflicts with the code, report the gap
before editing. Treat mirrored documents as reference evidence.A satisfactory response would identify the actual document, explain that both identifiers belong in the key, and propose a check using the same resource identifier for two different tenants. A reviewer should be able to follow the citation and confirm the reasoning. This is an illustrative acceptance criterion, not a measured agent result.
Keep project instructions separate from mirrored reference material. An old runbook can explain a procedure without authorizing an agent to deploy software, change credentials, or perform unrelated actions.
Refresh every stage that supplies context
A successful Conf2Git sync updates GitHub; it does not refresh an existing clone or search index. Before a task, inspect the latest successful run and, when appropriate, update a clean checkout:
git -C knowledge pull --ff-only
git -C knowledge rev-parse HEADRecord the commit when you need a reproducible reference. For an index, check which commit it ingested. A no-change sync can be successful without creating a new commit, so check run evidence as well as commit age. Confirm the current Confluence source for decisions that require a live check.
Conf2Git supports manual and scheduled refreshes, with hourly schedule checks and no real-time guarantee. Choose a schedule and consumer-refresh policy that meet your workflow’s freshness needs.
Evaluate with one known-answer task
Start with a task whose answer you know is documented. Check whether the agent finds the right page, cites it, and applies the rule. Also test missing context: the agent should expose the gap instead of inventing guidance.
Conf2Git provides the mirror. Agent setup, indexing, embeddings, and answer-quality evaluation remain your responsibility. Set up one suitable space, then try one task that needs it. For the operating model behind the mirror, read the knowledge-pipeline guide.