Atlassian Templates

Atlassian Template & Files Creator Expert

Specialist in creating, modifying, and managing reusable templates and files for Jira and Confluence. Ensures consistency, accelerates content creation, and maintains org-wide standards.

---

Workflows

Template Creation Process

1. Discover: Interview stakeholders to understand needs 2. Analyze: Review existing content patterns 3. Design: Create template structure and placeholders 4. Implement: Build template with macros and formatting 5. Test: Validate with sample data — confirm template renders correctly in preview before publishing 6. Document: Create usage instructions 7. Publish: Deploy to appropriate space/project via MCP (see MCP Operations below) 8. Verify: Confirm deployment success; roll back to previous version if errors occur 9. Train: Educate users on template usage 10. Monitor: Track adoption and gather feedback 11. Iterate: Refine based on usage

Template Modification Process

1. Assess: Review change request and impact 2. Version: Create new version, keep old available 3. Modify: Update template structure/content 4. Test: Validate changes don't break existing usage; preview updated template before publishing 5. Migrate: Provide migration path for existing content 6. Communicate: Announce changes to users 7. Support: Assist users with migration 8. Archive: Deprecate old version after transition; confirm deprecated template is unlisted, not deleted

Blueprint Development

1. Define blueprint scope and purpose 2. Design multi-page structure 3. Create page templates for each section 4. Configure page creation rules 5. Add dynamic content (Jira queries, user data) 6. Test blueprint creation flow end-to-end with a sample space 7. Verify all macro references resolve correctly before deployment 8. HANDOFF TO: Atlassian Admin for global deployment

---

Confluence Templates Library

See references/template-design-patterns.md for template design patterns and references/governance-framework.md for the governance model. For deployment-ready storage-format markup, use the bundled scaffolder (see Template scaffolder below). The following summarises the standard types this skill creates and maintains.

Confluence Template Types

Standard Sections included across all Confluence templates:

• Header panel with metadata (owner, date, status)
• Clearly labelled content sections with inline placeholder instructions
• Action items block using {tasks} macro
• Related links and references

Complete Example: Meeting Notes Template

Format warning: The example below is legacy wiki markup ({panel}, h2., {tasks}), shown for human readability. Wiki markup is NOT Confluence storage format and will be rejected by mcp__atlassian__createConfluencePage / updateConfluencePage, which expect storage format (XHTML, <ac:structured-macro> elements) or ADF. To get the deployment-ready storage-format equivalent, run the scaffolder: python3 scripts/template_scaffolder.py meeting-notes (see Template scaffolder).

{panel:title=Meeting Metadata|borderColor=#0052CC|titleBGColor=#0052CC|titleColor=#FFFFFF}
*Date:* {date}
*Owner / Facilitator:* @[facilitator name]
*Attendees:* @[name], @[name]
*Status:* {status:colour=Yellow|title=In Progress}
{panel}

h2. Agenda
# [Agenda item 1]
# [Agenda item 2]
# [Agenda item 3]

h2. Discussion & Decisions
{panel:title=Key Decisions|borderColor=#36B37E|titleBGColor=#36B37E|titleColor=#FFFFFF}
* *Decision 1:* [What was decided and why]
* *Decision 2:* [What was decided and why]
{panel}

{info:title=Notes}
[Detailed discussion notes, context, or background here]
{info}

h2. Action Items
{tasks}
* [ ] [Action item] — Owner: @[name] — Due: {date}
* [ ] [Action item] — Owner: @[name] — Due: {date}
{tasks}

h2. Next Steps & Related Links
* Next meeting: {date}
* Related pages: [link]
* Related Jira issues: {jira:key=PROJ-123}

Storage-format examples for the other built-in types (decision-log, runbook, project-kickoff) come from python3 scripts/template_scaffolder.py --list; design patterns for the remaining types (Project Charter, Sprint Retrospective, PRD) are in references/template-design-patterns.md.

---

Jira Templates Library

Jira Template Types

Standard Sections included across all Jira templates:

• Clear summary line
• Acceptance or success criteria as checkboxes
• Related issues and dependencies block
• Definition of Done (for stories)

---

Macro Usage Guidelines

Dynamic Content: Use macros for auto-updating content (dates, user mentions, Jira queries) Visual Hierarchy: Use {panel}, {info}, and {note} to create visual distinction Interactivity: Use {expand} for collapsible sections in long templates Integration: Embed Jira charts and tables via {jira} macro for live data

---

Template scaffolder — generate storage-format markup

The bundled scaffolder emits Confluence storage-format XHTML — the exact body format createConfluencePage/updateConfluencePage accept. It is the canonical deployment path for this skill:

# List available template types (meeting-notes, decision-log, runbook, project-kickoff, custom)
python3 scripts/template_scaffolder.py --list

# Generate a template body (storage-format XHTML)
python3 scripts/template_scaffolder.py meeting-notes

# Custom template with chosen sections and macros, JSON output for programmatic use
python3 scripts/template_scaffolder.py custom --sections "Overview,Goals,Action Items" --macros "toc,status,info" --format json

Consume the output: take the CONFLUENCE STORAGE FORMAT MARKUP block (text mode) or the markup field (JSON mode) and pass it verbatim as the body of mcp__atlassian__createConfluencePage. Apply the suggested labels via the Confluence UI afterwards (label tools are not on the MCP).

Atlassian MCP Integration

Primary Tool: Atlassian Remote MCP server (bundled .mcp.json, server key atlassian). Tools surface as mcp__atlassian__<toolName> (camelCase). Canonical tool list: project-management/references/atlassian-mcp-tools.md. Never invent tool names — if a capability isn't in that list, it is not available via MCP; route to the web UI or REST API.

Template Operations via MCP

Obtain cloudId once via mcp__atlassian__getAccessibleAtlassianResources. Replace angle-bracket placeholders with real values; discover exact parameter names from each tool's schema at call time.

Create a Confluence template page (body from the scaffolder above):

mcp__atlassian__createConfluencePage (cloudId, space, title="Template: Meeting Notes",
  body=<storage-format XHTML from template_scaffolder.py>, parent page id optional)

Labels (template, meeting-notes) must be applied in the Confluence UI — there is no MCP label tool.

Update an existing template page (read first to get the current version):

mcp__atlassian__getConfluencePage (cloudId, pageId=<existing page id>)
mcp__atlassian__updateConfluencePage (cloudId, pageId=<id>, version=<current + 1>,
  body=<updated storage-format content>)

Jira issue description templates: there is no MCP tool for field configuration (default_value on the description field, screens, field contexts). Configure description defaults in the Jira admin UI (Settings > Issues > Field configurations) or via REST (/rest/api/3/fieldconfiguration). What MCP CAN do: create issues pre-filled with template text via mcp__atlassian__createJiraIssue (pass the template body as the description), and inspect required fields per issue type with mcp__atlassian__getJiraIssueTypeMetaWithFields.

First-class Confluence templates/blueprints are also not creatable via MCP — createConfluencePage creates ordinary pages that serve as copy-from templates. To register a real space template, use Space settings > Templates in the UI.

Deploy a template page to multiple spaces (batch):

# Repeat per target space:
mcp__atlassian__createConfluencePage (cloudId, space=<target>, title="Template: Meeting Notes", body=<storage-format content>)
# Verify each create before proceeding:
mcp__atlassian__getConfluencePage (cloudId, pageId=<id returned by create>)
# Assert the returned body is non-empty and contains the expected <ac:structured-macro> elements

Validation checkpoint after deployment:

• Retrieve the created/updated page via mcp__atlassian__getConfluencePage and assert it renders without macro errors
• Check that Jira-macro embeds resolve against the target Jira project
• Confirm task blocks are interactive in the published view
• If any check fails: revert using mcp__atlassian__updateConfluencePage with version: <current + 1> and the previous version body

---

Best Practices & Governance

Org-Specific Standards:

• Track template versions with version notes in the page header
• Mark outdated templates with a {warning} banner before archiving; archive (do not delete)
• Maintain usage guides linked from each template
• Gather feedback on a quarterly review cycle; incorporate usage metrics before deprecating

Quality Gates (apply before every deployment):

• Example content provided for each section
• Tested with sample data in preview
• Version comment added to change log
• Feedback mechanism in place (comments enabled or linked survey)

Governance Process: 1. Request and justification 2. Design and review 3. Testing with pilot users 4. Documentation 5. Approval 6. Deployment (via MCP or manual) 7. Training 8. Monitoring

---

Handoff Protocols

Handoff summary (governance context in references/governance-framework.md):

Template Governance Framework

Overview

Operational framework for managing template lifecycle — creation, updates, deprecation, and quality enforcement with concrete thresholds and decision criteria.

Ownership Model

Roles

Template Owner (1 per template):

• Reviews usage dashboard on the 1st of each quarter
• Archives templates with <5 uses in the past 90 days
• Responds to change requests within 14 calendar days
• Runs quarterly accuracy check: open 3 random pages created from the template, verify content matches current process
• Escalates to committee if change affects >50 users

Template Steward (1 per team/domain):

• Runs monthly usage pull: CQL: type = page AND label = "template-{name}" AND created >= "now-30d"
• Flags templates where >30% of users delete or heavily modify a section (indicates friction)
• Collects and triages feedback — tags Jira tickets with template-change and links to template page

Template Committee (3-5 people, for orgs with 20+ templates):

• Meets quarterly (45 min max): reviews new proposals, resolves conflicts, flags duplicates
• Decision rule: approve if template serves >1 team and doesn't duplicate existing template by >60% content overlap
• Publishes quarterly "Template Health" Confluence page with adoption rates and actions taken

Assignment Matrix

Approval Workflow

New Template Proposal

1. Request - Submitter creates proposal with:

• Template name and purpose
• Target audience
• Justification (why existing templates are insufficient)
• Draft content
• Proposed owner

2. Review - Template owner/committee evaluates:

• Does this duplicate an existing template?
• Is the scope appropriate (not too broad or narrow)?
• Does it follow design standards?
• Is it needed by more than one team?

3. Pilot - If approved:

• Deploy to a small group for 2-4 weeks
• Collect feedback on usability and completeness
• Iterate based on feedback

4. Launch - After successful pilot:

• Publish to template library
• Announce to relevant teams
• Add to Template Index page
• Train users if needed

5. Monitor - Post-launch:

• Track adoption rate (first 30 days)
• Collect initial feedback
• Make quick adjustments if needed

Template Update Process

1. Change Request - Anyone can suggest changes via:

• Comment on the template page
• Jira ticket tagged template-change
• Direct message to template owner

2. Assessment - Owner evaluates:

• Impact on existing documents using this template
• Alignment with organizational standards
• Effort required for update

3. Implementation - Owner or steward:

• Makes changes in a draft version
• Reviews with 1-2 frequent users
• Updates version number and changelog
• Publishes updated template

4. Communication - Notify users:

• Post update in relevant Slack/Teams channel
• Update Template Index page
• Send email for major changes

Change Management

Impact Categories

Low Impact (Owner decides):

• Typo fixes and formatting improvements
• Clarifying existing instructions
• Adding optional sections

Medium Impact (Owner + 1 reviewer):

• Adding new required sections
• Changing variable names or structure
• Updating macro usage

High Impact (Committee review):

• Removing sections from widely-used templates
• Merging or splitting templates
• Changing organizational template standards

Communication Plan

Deprecation Process

When to Deprecate

• Template replaced by a better alternative
• Process the template supports has been retired
• Template has zero usage in the past 6 months
• Template is redundant with another active template

Deprecation Steps

1. Decision - Owner proposes deprecation with justification 2. Announcement - Notify users 30 days before deprecation:

• Mark template with "DEPRECATED" status
• Add deprecation notice at top of template
• Point to replacement template (if applicable)

3. Transition Period - 30 days:

• Template still available but marked deprecated
• New documents should use replacement
• Existing documents do not need to change

4. Archive - After transition:

• Move template to Archive section
• Remove from active template list
• Keep accessible for historical reference

5. Review - 90 days after archive:

• Confirm no active usage
• Add to annual cleanup list if truly unused

Usage Tracking

Metrics & Thresholds

Tracking via CQL

-- Monthly usage for a specific template
type = page AND label = "template-sprint-retro" AND created >= "now-30d"

-- Stale templates (no usage in 90 days)
type = page AND label IN ("template-sprint-retro", "template-decision-log") AND created < "now-90d" AND created >= "now-91d"

-- All template-created pages for audit
type = page AND label = "template-*" ORDER BY created DESC

Reporting

• Monthly: Top 10 templates by usage → auto-generated Confluence table
• Quarterly: Flag templates below thresholds → owner action required within 14 days
• Annually: Full catalog review — archive anything with 0 uses in 6 months

Quality Standards

Content Checklist (pass/fail per template)

• [ ] Every section has placeholder text showing expected content (not just a heading)
• [ ] No section references a process, tool, or team that no longer exists
• [ ] All Jira macro JQL filters return results (test quarterly)
• [ ] Links to other Confluence pages resolve (no 404s)
• [ ] Template renders correctly in both desktop and mobile preview

FAIL examples: Template says "Update the JIRA board" but team uses Linear. Template has a "QA Sign-Off" section but team has no QA role. Placeholder text says "TODO: add content here" with no guidance on what content.

Structural Checklist

• [ ] Metadata header: owner name, version (semver), status (active/deprecated/draft), last-reviewed date
• [ ] Table of Contents macro if template has 4+ sections
• [ ] Change History table at bottom (date, author, change description)
• [ ] Placeholder text uses {placeholder} syntax or ac:placeholder macro — visually distinct from real content

Maintenance Triggers

• Template not reviewed in 90+ days → owner gets Jira ticket auto-created via automation
• 3+ unresolved feedback items → escalate to committee
• Broken macro detected → owner notified same day via Slack/email automation

Review Cadence

Quarterly Review (Template Owner)

• Review usage metrics
• Address pending feedback
• Update content for accuracy
• Verify all links and macros work
• Update version number if changed

Semi-Annual Review (Template Committee)

• Review full template catalog
• Identify gaps (missing templates)
• Identify overlaps (duplicate templates)
• Evaluate template standards compliance
• Plan improvements for next half

Annual Review (Leadership — 60 min meeting)

Agenda: 1. (10 min) Catalog stats: total templates, usage trend YoY, templates added/deprecated 2. (15 min) Top 5 templates by adoption — what makes them work 3. (15 min) Bottom 5 templates — deprecate, rework, or retrain? 4. (10 min) Gaps identified by teams — templates requested but not yet built 5. (10 min) Governance process retro — is the framework itself working? Adjust thresholds, roles, or cadence as needed

Deliverable: Updated Template Health page published within 1 week of meeting

Getting Started

For New Organizations

1. Start with 5-10 essential templates (meeting notes, decision record, project plan) 2. Assign owners for each template 3. Establish basic quality standards 4. Review after 90 days and expand 5. Formalize governance as template count grows beyond 20

Template Design Patterns

Overview

Well-designed Confluence and Jira templates accelerate team productivity by providing consistent starting points for common documents and workflows. This guide covers design patterns, variable handling, and best practices for creating reusable templates.

Variable Placeholders

Confluence Template Variables

Syntax: <at:var at:name="variableName">default value</at:var>

Common Variables:

Best Practices:

• Use descriptive variable names (camelCase)
• Always provide meaningful default values
• Group related variables together
• Include instruction text that users should replace
• Use Status macro for status variables (visual clarity)

Jira Template Fields

Custom Fields for Templates:

• Text fields for structured input
• Select lists for controlled vocabularies
• Date fields for milestones
• User pickers for assignments
• Labels for categorization

Conditional Sections

Pattern: Role-Based Sections

Include or exclude content based on the document's audience:

## For Engineering (delete if not applicable)
- Technical requirements
- Architecture decisions
- Performance criteria

## For Design (delete if not applicable)
- User flows
- Wireframes
- Accessibility requirements

## For Business (delete if not applicable)
- ROI analysis
- Market context
- Success metrics

Pattern: Complexity-Based Sections

Scale content depth based on project size:

## Required for All Projects
- Problem statement
- Solution overview
- Success metrics

## Required for Medium+ Projects (>2 weeks)
- Detailed requirements
- Technical design
- Test plan

## Required for Large Projects (>1 month)
- Architecture review
- Security review
- Rollback plan
- Communication plan

Pattern: Optional Deep Dives

Use Expand macros for optional detail:

[Expand: Detailed Requirements]
  Content that power users may need but casual readers can skip
[/Expand]

Reusable Components

Header Block

Every template should start with a consistent header:

| Field | Value |
|-------|-------|
| Author | @mention |
| Status | [Status Macro: Draft] |
| Created | [Date] |
| Last Updated | [Date] |
| Reviewers | @mention |
| Approver | @mention |

Decision Log Component

Reusable across templates that involve decisions:

## Decision Log
| # | Decision | Date | Decided By | Rationale |
|---|----------|------|-----------|-----------|
| 1 | [Decision] | [Date] | [Name] | [Why] |

Change History Component

Track document evolution:

## Change History
| Version | Date | Author | Changes |
|---------|------|--------|---------|
| 1.0 | [Date] | [Name] | Initial version |

Action Items Component

Standard task tracking:

## Action Items
- [ ] [Task description] - @assignee - Due: [date]
- [ ] [Task description] - @assignee - Due: [date]

Macro Integration

Recommended Macros per Template Type

Meeting Notes Template:

• Table of Contents (for long meetings)
• Action Items (task list macro)
• Jira Issues (link to discussed tickets)
• Expand (for detailed discussion notes)

Decision Record Template:

• Status macro (decision status)
• Page Properties (structured metadata)
• Info/Warning panels (context and caveats)
• Jira Issues (related tickets)

Project Plan Template:

• Roadmap Planner (timeline view)
• Jira Issues (JQL for project epics)
• Children Display (sub-pages for phases)
• Chart macro (status distribution)

Runbook Template:

• Code Block (commands and scripts)
• Warning panels (danger zones)
• Expand (detailed troubleshooting)
• Anchor links (quick navigation)

Responsive Layouts

Two-Column Layout

Use Confluence Section and Column macros:

[Section]
  [Column: 60%]
    Main content, description, details
  [/Column]
  [Column: 40%]
    Sidebar: metadata, quick links, status
  [/Column]
[/Section]

Card Layout

For overview pages with multiple items:

[Section]
  [Column: 33%]
    [Panel: Card 1]
      Title, summary, link
    [/Panel]
  [/Column]
  [Column: 33%]
    [Panel: Card 2]
  [/Column]
  [Column: 33%]
    [Panel: Card 3]
  [/Column]
[/Section]

Brand Consistency

Visual Standards

• Use consistent heading levels (H1 for title, H2 for sections, H3 for subsections)
• Apply Info/Warning/Note panels consistently (same meaning across templates)
• Use Status macro colors consistently (Green=done, Yellow=in progress, Red=blocked)
• Maintain consistent table formatting (header row, alignment)

Content Standards

• Use the same voice and tone across templates
• Standardize date format (YYYY-MM-DD or your organization's preference)
• Use consistent terminology (define terms in a glossary)
• Include the same footer/metadata block in all templates

Versioning Strategy

Template Version Control

• Include version number in template metadata
• Maintain a changelog for template updates
• Communicate template changes to users
• Keep previous versions accessible during transition periods

Version Numbering

• Major (2.0): Structural changes, section additions/removals
• Minor (1.1): Content updates, improved instructions
• Patch (1.0.1): Typo fixes, formatting corrections

Migration Path

When updating templates: 1. Create new version alongside old version 2. Announce change with migration guide 3. New documents use new template automatically 4. Existing documents do not need to be migrated (optional) 5. Deprecate old template after 90 days 6. Archive old template (do not delete)

Template Catalog Organization

Categorization

Organize templates by:

• Document type: Meeting notes, decisions, plans, runbooks
• Team: Engineering, product, marketing, HR
• Lifecycle: Planning, execution, review, retrospective
• Frequency: One-time, recurring, as-needed

Discovery

• Maintain a "Template Index" page with descriptions and links
• Tag templates with consistent labels
• Include a "When to Use" section in each template
• Provide examples of completed documents using the template