SERIES: AI-POWERED DEV WORKFLOW · POST 5 OF 10
Here is what actually happens to project documentation on most teams: the BRD lives in a Google Doc that three people have edit access to. The FRD is in someone’s Notion. The change requests are in an email thread. The developer who joined two weeks into the project has found none of these and is building from memory of a Slack conversation.
Confluence solves this — but only if someone actually moves the docs there. And moving docs to Confluence manually is tedious enough that it just does not happen. You copy-paste, the formatting breaks, the tables look wrong, and you give up after the first section.
Claude can generate Confluence-ready wiki markup directly from your BRD and FRD. With the Atlassian MCP connected, it can even push the pages to your Confluence space without you touching a browser. This post shows both.
First: Structure Your Confluence Space Properly
Before generating any content, decide on your page hierarchy. A flat list of pages in Confluence is almost as bad as no pages at all — nobody can find anything. Here is the structure I use for every project:
RECOMMENDED CONFLUENCE PAGE HIERARCHY
ClientHub (Project Home)
|
+-- BRD
| +-- Business Goals and Success Metrics
| +-- Scope: In and Out of Scope
| +-- Non-Functional Requirements
| +-- Assumptions and Constraints
|
+-- FRD
| +-- Authentication and Role System
| +-- Project Management
| +-- Deliverable Approval Workflow
| +-- Notification System
| +-- Invoicing and Invoice Dashboard
| +-- Audit Logging
|
+-- Design Decisions
| +-- Change Log
|
+-- Meeting NotesThe key principle: one Confluence page per FRD feature. Not one page for the entire FRD. When a developer needs to check the spec for Deliverable Approval, they should be able to find it directly — not scroll through a 20-page document.
Converting a BRD Section to Confluence Markup
Confluence uses its own wiki markup syntax for headings, tables, info panels, and status macros. Claude knows it. You just have to ask for it explicitly — otherwise Claude defaults to Markdown and you end up pasting something that renders as plain text.
PROMPT 1 - BRD Section to Confluence Markup
Read the Business Goals section from docs/ClientHub-BRD-v1.md.
Convert it into a Confluence wiki markup page.
Include:
- Page title as h1
- An {info} macro at the top with: Status, Owner, Last Reviewed date
- Each business goal as an h2 section
- Success metrics as a two-column table (|| Metric || Target ||)
- A "Related Pages" section at the bottom with links placeholder text
Output only the raw Confluence wiki markup, ready to paste.Here is a condensed version of what Claude produced:
h1. ClientHub -- Business Goals and Success Metrics
{info}
Status: Approved | Owner: Tejas Mehta | Last Reviewed: [date]
{info}
h2. Goal 1: Eliminate email as the primary channel for project updates
|| Success Metric || Target ||
| % of client feedback submitted through the portal | 90% within 3 months |
| Average deliverable approval time | Reduced from 48h to 24h |
h2. Goal 2: Give clients real-time visibility into project progress
|| Success Metric || Target ||
| Client logins per week per active project | 3 or more |
| PM time spent on status communications | Reduced by 40% |
h2. Goal 3: Create an audit trail for all project decisions
|| Success Metric || Target ||
| Deliverable approvals with timestamp and user ID | 100% |
| Change requests formally logged | 100% |
h2. Related Pages
* [ClientHub Project Home|ClientHub]
* [FRD: Deliverable Approval Workflow|ClientHub FRD Deliverable Approval]
* [Change Log|ClientHub Change Log]Paste that directly into Confluence’s wiki markup editor and it renders with proper headings, info panels, and tables. No reformatting needed.
Converting an FRD Feature to Its Own Confluence Page
For FRD pages, the structure is slightly different. Each page is self-contained: the full spec for one feature, with a status badge, section headers, and links to related pages. Use this prompt template for every feature:
PROMPT 2 - FRD Feature to Confluence Sub-Page
Read the Deliverable Approval Workflow entry from docs/ClientHub-FRD-v1.md.
Convert it into a standalone Confluence page in wiki markup.
Structure:
- h1: feature name
- {info} macro: Status | Owner | Last Reviewed | Phase
- h2: Feature Description
- h2: User Stories (use {expand} macro so they are collapsible)
- h2: Acceptance Criteria (numbered list)
- h2: Business Rules (bullet list)
- h2: Edge Cases (bullet list)
- h2: UI/UX Notes
- h2: Dependencies (link text to related Confluence pages)
- {note} macro at the bottom: "This page is generated from the
FRD. For changes, update the source document first."
Output raw Confluence wiki markup only.The {expand} macro for user stories is worth knowing. It collapses the content by default so the page does not look overwhelming when someone first opens it. They expand what they need. Claude uses it automatically when you ask for it.
Adding Metadata Claude Can Fill In Automatically
Every Confluence page should have metadata: who owns it, what its current status is, what labels it carries, and what other pages it relates to. Claude can generate this too — and it saves the page from becoming orphaned and out of date six months later.
PROMPT 3 - Generate Page Metadata
For the Deliverable Approval Workflow Confluence page,
generate the page metadata:
- Suggested page title (specific, searchable)
- Status label: Draft / In Review / Approved
- Page owner (from the BRD/FRD context)
- Confluence labels (comma-separated, lowercase, hyphenated)
- Reviewed-by list (roles, not names)
- Related pages list (link text only)
Format it as a table I can add to the top of the page.Here is the metadata table Claude generated for ClientHub:
| Field | Value |
|---|---|
| Page Title | ClientHub — Deliverable Approval Workflow (FRD) |
| Status | Approved |
| Owner | Tejas Mehta (PM) |
| Labels | frd, clienthub, deliverables, phase-1 |
| Reviewed By | Lead Developer, QA Lead |
| Related Pages | ClientHub BRD, Notification System FRD, Invoicing FRD |
| Last Updated | Auto-filled on save |
Pushing Pages Directly to Confluence with the MCP
If you have the Atlassian MCP connected to Claude, you can skip the copy-paste step entirely. Claude generates the markup and creates the page in your Confluence space in the same session.
What is an MCP?
MCP (Model Context Protocol) is a standard that lets Claude connect directly to external tools and services. When the Atlassian MCP is connected, Claude can read from and write to Confluence and Jira without you leaving the Claude session. You set it up once in Claude’s settings — after that it just works.
PROMPT 4 - Push Page to Confluence via MCP
Using the Atlassian MCP, create the following Confluence page:
Space key: CLIENTHUB
Parent page: "FRD"
Title: "Deliverable Approval Workflow"
Content: [paste the wiki markup output from Prompt 2]
After creating it, return the page URL.Claude creates the page, sets the parent, and returns the URL. The whole thing takes about 10 seconds. Run this for each FRD feature and your entire project knowledge base is in Confluence before the end of the morning.
If you do not have the MCP connected yet, the wiki markup output from Prompts 1 and 2 is still paste-ready. Go to your Confluence page, switch the editor to wiki markup mode, and paste. It will render correctly.
How Long Does This Actually Take?
For ClientHub — one BRD with four sections and an FRD with seven features — the full Confluence build took about 25 minutes. That included: running the prompts, reviewing the markup, creating all pages via the MCP, and setting up the page hierarchy.
Without Claude, doing this manually would have taken most of a morning. The formatting alone — getting tables, info panels, and headings to look right in Confluence — takes forever if you are doing it by hand.
What Is Next
The team now has all the documentation in one place, structured and searchable. The next step is turning those FRD specs into actual Jira tickets — epics, stories, tasks, and acceptance criteria, all generated from the FRD without rewriting anything.
Post 6 covers the full Jira ticket generation workflow: how to extract the right hierarchy from your FRD, how to write acceptance criteria that maps directly to test cases, and how to push tickets to Jira directly via the MCP.
Next in this series: Post 6 — Create Jira Epics, Stories, and Tasks with Claude: Zero Manual Work
Got questions? Drop them in the comments — I read every one.