A Confluence Documentation Prompt That Keeps Docs Current

Documentation doesn't rot all at once. It drifts. An endpoint changes, a setup step gets an extra flag, an architecture diagram quietly describes last quarter's system, and nobody updates the page because updating it requires context that only existed the week the change shipped. A confluence documentation prompt attacks that drift on a schedule: find the stale pages, tie recent work to the docs it touched, draft the fix, publish it.

The hard part was never writing the update. It's knowing which page needs one, and catching it before a new hire follows a broken setup guide into a wall.

Why the current advice leaves you pasting

The best writing on this admits the constraint. An AI Codex article on keeping Confluence docs from going stale (~1,500 words) lays out four solid workflows, then states the limit plainly: "There's no native Claude-Confluence integration that reads or writes pages automatically." So every workflow it describes is copy-paste. You find the stale page yourself, paste it into a chat, paste the answer back. That's fine for one page and hopeless for a hundred.

The other option ranking for this query is a paid app. Atlassian's Marketplace lists Keep Docs Updated for Confluence, which monitors outdated pages with label and date filters and exports CSVs. It's a monitoring tool, not a prompt, and it doesn't tie a stale page to the specific Jira work that made it stale. It tells you a page is old. It won't draft the fix.

So there's a gap in the middle: a reusable prompt that both finds the drift and drafts the correction, and, with a connected agent, publishes it. That's the job here.

What you can do with this prompt

• Audit a Confluence space for pages past a staleness threshold
• Map recent Jira tickets to the docs they most likely affected
• Draft precise page updates that keep the untouched content intact
• Skip pages you've labeled as intentionally frozen
• Publish the approved draft and close the loop in Jira and Slack
• Run the whole thing on a cadence instead of a heroic quarterly cleanup

Anatomy of the prompt pack

The structure that holds up is an audit prompt, a change-detection prompt, a drafting prompt, and a publication step. Each stage narrows the work so the drafter only sees pages that actually need attention.

Variables → Prompt → Output

{{documentation_scope}}       # which space or pages
{{stale_threshold_days}}      # "old" in days
{{lookback_days}}             # how far back to scan Jira
{{project_key}}               # the Jira project
        │
        ▼
Content Freshness Audit    → stale page list
        │
        ▼
Project Change Detection   → {{related_jira_issues}} per page
        │
        ▼
Documentation Update Draft → drafted change per page
        │
        ▼
Publication Workflow       → publish + Jira/Slack close-out

The change-detection stage is the one that earns its place. Anyone can list old pages. Tying {{triggering_jira_issues}} to the exact page they affected is what turns a scary backlog into a short, reviewable queue.

Step-by-step usage

1. Scope it tight

Set {{documentation_scope}} to one space or a page tree, not the whole instance. A first run across everything returns noise. Start with the space your team owns.

2. Define what "stale" means

{{stale_threshold_days}} is a judgment call. Sixty days for a fast-moving API space, a year for onboarding docs that rarely change. The audit flags anything untouched past that line. Use {{exclude_labels}} to skip pages you've deliberately frozen.

3. Point change detection at recent work

{{lookback_days}} and {{project_key}} tell the detector how far back to scan Jira. It maps recent tickets to the pages they touched and fills {{related_jira_issues}}. Read this mapping before drafting. If it linked a ticket to the wrong page, fix it here.

4. Draft against the real page

The drafting stage rewrites only the parts that changed and leaves the rest alone. Feed it {{update_instructions}} when you want a specific framing. The best pattern: pick a healthy page as a template and have the model match its structure while keeping the technical content intact.

5. Publish and close the loop

Once you approve {{approved_draft_content}}, the publication step writes it back and posts a note to your {{slack_channel}} with the Jira reference. Now the update is traceable, not a silent edit.

Prompt-craft patterns that matter here

Never let the model draft blind. The single biggest failure mode is asking for an update without giving the model the current page. It'll invent plausible-looking content that contradicts what's live. Feed the actual page text; draft against it. This is why the connected-agent version beats the copy-paste one: the agent reads the real {{confluence_page_title}} instead of a summary.

Anchor updates to a trigger. The strongest pattern in this niche comes from incident work: when a post-mortem is written, hand the model the post-mortem and ask it to update the runbook. The change is the context. Tie every draft to {{triggering_jira_issues}} so the update reflects a real change, not a guess about what might've drifted.

Preserve, don't rewrite. Here's the opinionated take: a documentation prompt that rewrites the whole page is worse than useless. It buries the one changed sentence in a wall of reworded prose nobody trusts, and reviewers can't tell what actually changed. Constrain the drafter to surgical edits. A three-line diff a reviewer approves in ten seconds beats a beautiful full rewrite they'll never read.

Role: You maintain an existing Confluence page.
Task: Update only what the linked Jira work changed.
Output contract:
- The exact lines to change, before and after
- Untouched sections left verbatim
- A one-line changelog entry
No full rewrite. No preamble.

Variables you'll set

Getting started

1. Set {{documentation_scope}} to one space you own.
2. Pick a {{stale_threshold_days}} that fits how fast it changes.
3. Set {{lookback_days}} and {{project_key}} for change detection.
4. Run the audit; read the stale list.
5. Review the {{related_jira_issues}} mapping before drafting.
6. Approve surgical drafts only; reject full rewrites.
7. Publish and let the close-out post to {{slack_channel}}.

If your drift is driven by code rather than tickets, the docs-code-sync prompt catches the gap between what shipped and what the README says. And when the trigger is an outage, the runbook authoring prompt pairs with the post-mortem-to-runbook pattern above.

A fair caveat: a model can draft an update, but it can't verify the change is correct against a system it can't run. Keep a human on the approve step, pin which Jira project drives the audit, and treat the draft as a proposal. For the code side of the same problem, the docs-code-sync harness handles README and inline drift, while the incident post-mortem pack feeds the trigger that keeps runbooks honest.