Auto-scaffold Confluence spec pages from new Jira epics

The moment a new epic lands in Jira, a matching spec page appears in Confluence with the standard sections ready to go, so engineers never start from a blank page.

Deterministic Code
JiraConfluenceEngineeringProductContent GenerationData Sync
PromptCreate

Build a code workflow that scaffolds a Confluence spec page every time a new epic is created in Jira, so engineers never start from a blank page. The workflow is deterministic template-fill — no reasoning, no LLM calls — just map webhook fields onto a fixed Confluence page template.

Trigger: a Jira webhook subscribed to the jira:issue_created event. Jira Cloud emits outgoing webhooks for issue creation, so the workflow receives the full issue payload on fire. The first thing the workflow does is filter the payload: continue only if issue.fields.issuetype.name equals "Epic", or (as a configurable alternative) if the issue carries a specific label such as "needs-spec". If the issue does not match, exit without doing anything.

From the webhook payload, extract these fields for the template: the issue key (e.g. ABC-123), the summary, the description, the assignee display name (fields.assignee.displayName, or "Unassigned" if null), the target release / fix version (fields.fixVersions[0].name, or "Not set" if empty), and the browse URL back to the Jira epic (typically {issue.self host}/browse/{issue.key}, or the value already provided on the payload). If any critical field is missing from the webhook body, call jira Get Issue with the issue key to fetch it before continuing.

Then create the Confluence page using the confluence Create Page operation. Configure it with:

  • spaceId set to the configured Specs space (expose the space key or ID as a workflow input so users can point it at their own space).

  • parentId set to the configured Active Specs parent page ID, so the new page nests under the standard spot.

  • title set to "{ISSUE_KEY}: {ISSUE_SUMMARY}" — for example "ABC-123: New billing dashboard".

  • body in Confluence storage format (representation: "storage"), built from the hardcoded template below with the extracted fields interpolated in.

  • status: "current" so the page is published, not left as a draft.

The storage-format body template is fixed. It has two parts:

1) A header block at the top of the page containing:

  • An info panel (Confluence storage-format info macro, ac:name="info") with a bulleted list of metadata: Jira epic (as a link to the browse URL using the issue key as the label), Assignee, Target release, and Created (the current ISO date).

  • A paragraph or blockquote below the info panel with the epic description as plain text (strip Atlassian Document Format formatting to a plain string; if description is empty, write "No description provided in Jira.").

2) Six section headings, each an <h2> followed by an empty <p></p> placeholder so the engineer can start typing under each:

  • Problem

  • Proposed Solution

  • Requirements

  • Out of Scope

  • Rollout Plan

  • Open Questions

Section headings are hardcoded, but expose them as a configurable list at the top of the workflow so users can rename or reorder them without editing code. Same for the trigger filter (issue type vs label), the Confluence space ID, and the parent page ID — all four should be workflow inputs.

Reference for the Confluence page body: the storage format is documented at https://developer.atlassian.com/cloud/confluence/rest/v2/intro/. The Create Page endpoint accepts { spaceId, parentId, status, title, body: { representation: "storage", value: "<storage-format XHTML string>" } }.

Do not log or send anything else — no Slack ping, no comment back on the Jira epic. Just create the page. Keep it deterministic and boring.

Additional information

What does this prompt do?
  • Listens for new epics being created in Jira and picks them up automatically.
  • Creates a new page in your Confluence Specs space using a fixed template, with the epic key and summary as the title.
  • Fills the top of the page with the epic description, assignee, target release, and a link back to Jira.
  • Adds empty section headings for Problem, Proposed Solution, Requirements, Out of Scope, Rollout Plan, and Open Questions.
  • Places the new page under your Active Specs parent page so it lands in the standard spot every time.
What do I need to use this?
  • A Jira workspace where epics get created (and the ability to add an outgoing webhook for new issues).
  • A Confluence space set aside for specs, with an Active Specs page that new spec pages should sit under.
  • A short list of the sections you want on every spec page (the defaults are Problem, Proposed Solution, Requirements, Out of Scope, Rollout Plan, and Open Questions).
How can I customize it?
  • Change the section headings on the template to match how your team writes specs.
  • Filter which Jira issues trigger a page, for example only epics in a specific project or only ones tagged with a label like needs-spec.
  • Point the workflow at a different Confluence space or a different parent page (for example a per-quarter or per-team parent).

Frequently asked questions

Does this work for issue types other than epics?
Yes. The workflow checks the issue type before creating a page, so you can point it at stories, initiatives, or any custom type by changing the filter. You can also key it off a label like needs-spec instead of the type.
Where does the new spec page end up in Confluence?
Under whichever parent page you nominate (the default is a page called Active Specs in your Specs space). Every new spec drops in as a child, so your specs tree stays tidy on its own.
What appears on the page when it first gets created?
A header block with the epic description, assignee, target release, and a link back to the Jira epic, followed by empty section headings for Problem, Proposed Solution, Requirements, Out of Scope, Rollout Plan, and Open Questions, ready for the engineer to fill in.
What happens if someone edits or renames the Jira epic later?
This workflow only runs when an epic is first created. The Confluence page is a scaffold, not a live mirror, so later edits in Jira do not overwrite what your engineers have written on the spec.
Do we need any special Jira or Confluence plan?
You need Jira Cloud and Confluence Cloud on any plan that lets you add outgoing webhooks in Jira and create pages via Confluence. Standard and above works out of the box.

Stop starting every spec from a blank page.

Hand new epics a ready-to-write Confluence page, in the right space, under the right parent, every single time.