Where does a creative-direction brief belong in Jira?

On the Epic. The brief synthesis becomes the Epic description, the four axis positions become custom fields on the Epic, and the rejection list becomes a structured section in the description. Stories link to the Epic via the Epic Link field, which Jira indexes natively, so a single JQL query returns every Story under the Epic answering one brief.

What custom field type works best for axis positions?

Single-select fields, one per axis (Tone, Aesthetic, Relationship, Sensory). Single-select gives you the JQL queryability of structured values without the cardinality problem multi-select introduces. Configure the option list per axis (Professional, Conversational, Playful, Provocative for Tone; the corresponding sets for the other three) and apply the fields to the Epic issue type via the screen scheme.

Can JQL find stories that break the brief's rejection list?

Not directly via JQL alone, since the rejection list is freeform text. Teams handle this with a Single-select Direction-status field on Stories with values like Aligned, Drift, Needs review. A workflow transition or an automation rule sets Direction-status during refinement based on a manual judgment call. JQL then queries that field. The brief is the source of truth; the field is the queryable index of human review against it.

What is the most common Jira-specific failure of this integration?

Custom fields applied to the Epic but not surfaced on the Create Story screen. Stories get filed without axis context, the JQL filters return incomplete results, and the team loses confidence in the integration within a sprint or two. Confirm the screen scheme exposes the axis fields on every relevant create and edit screen, not just on the Epic detail view.

Integration · Jira

RampStack skills in Jira.

The brief is the Epic. The four axes are custom fields. JQL is what makes the brief queryable.

Jira gives the team Epics, custom fields, screen schemes, workflows, and JQL. The integration uses each one for the load-bearing role it already plays. The Epic is where the brief lives. Custom fields are how axis positions become structured data. JQL is how the brief stays queryable across projects. The workflow is where the brief-alignment review step gets enforced before a Story moves to In Progress.

The shape

Brief into Jira primitives.

The Epic carries the brief. Stories link to the Epic via Epic Link. Custom fields hold the axis positions. The workflow gains a Direction review step. JQL pulls cross-project work that answers the brief or breaks it.

The Epic carries the brief and four single-select custom fields. Stories link via Epic Link. JQL surfaces the cross-project view of work under one brief.

The mapping

Brief artifacts to Jira primitives.

Brief artifact	Jira primitive	Notes
Project name and description	Epic title and description	Synthesis paragraph at top
Tone axis position	Custom field: Tone (Single-select)	Options: Professional, Conversational, Playful, Provocative
Aesthetic axis position	Custom field: Aesthetic (Single-select)	Editorial Restrained, Polished Standard, Controlled Maximalist, Expressive Maximalist
Relationship axis position	Custom field: Relationship (Single-select)	Authority, Peer, Companion, Coach
Sensory axis position	Custom field: Sensory (Single-select)	Functional, Considered, Resonant
Rejection list	Description heading: Won't do	Bulleted list inside the Epic body
Direction-status per Story	Custom field: Direction status (Single-select)	Aligned, Drift, Needs review. Set during refinement.
Inspiration references	Web Links section on the Epic	Native Jira link list, no custom field needed

Each axis custom field is a Single-select. Multi-select is tempting but creates cardinality problems for JQL: a Story tagged with two Tone positions cannot be filtered cleanly. Stick with Single-select. If a Story spans multiple axis positions, that is a sign the Story is too big and should be split.

Apply the four custom fields to the Epic issue type and the Story issue type via the screen scheme. The Epic fields capture the brief; the Story fields inherit defaults from the Epic but allow exception cases (a specific Story that intentionally sits at a different position with explicit justification).

Templates

Copy these into the project configuration.

Epic description structure

The Epic body uses a fixed heading structure so every Epic is parseable by humans and by automation rules the team adds later.

# Brief synthesis

[One paragraph in present tense describing what
this combination produces in practice.]

# Axis positions

- Tone: [position] because [one-sentence rationale]
- Aesthetic: [position] because [one-sentence rationale]
- Relationship: [position] because [one-sentence rationale]
- Sensory: [position] because [one-sentence rationale]

(Custom fields above mirror these for queryability.)

# Won't do

- [specific phrasing, structure, or visual move
  this brief excludes]
- [next item]
- [next item]

# Inspiration references

(Use the Web Links section of this Epic for URLs.
Add a one-sentence note per reference about what
specifically resonates.)

# Open questions

- [anything still unresolved that downstream Stories
  will need answered]

JQL filters the team can save

Save these as filters at the team level. Each surfaces a different cut of the work that touches one or more briefs.

# All open Stories under one brief
"Epic Link" = PROJ-123 AND statusCategory != Done
ORDER BY priority DESC, created DESC

# Stories that have not been graded yet
"Epic Link" = PROJ-123
  AND "Direction status" is EMPTY
  AND statusCategory != Done

# Stories that drifted, surfaced for review
"Epic Link" = PROJ-123
  AND "Direction status" = "Drift"

# Cross-project work tagged with one tone position
project in (WEB, APP, MKT)
  AND Tone = "Professional"
  AND statusCategory = "In Progress"

# Stories under the brief that violate the rejection
# list (as flagged by the Direction-status review)
"Epic Link" = PROJ-123
  AND "Direction status" = "Drift"
ORDER BY updated DESC

Workflow with a Direction review step

Insert a Direction review state between Refinement and Ready. The transition out of Direction review requires the Direction-status field to be set to Aligned or Needs review (not Drift). The transition is what makes the gate real instead of decorative.

Story workflow states

Backlog  ->  Refinement  ->  Direction review  ->  Ready
                                    |
                                    +->  Drift  (loop back to
                                                 Refinement)

Transition: Direction review -> Ready
  - Validator: "Direction status" must equal
    "Aligned" OR "Needs review"
  - Post-function: set assignee to the Story owner

Transition: Direction review -> Drift
  - Used when the reviewer judges the Story breaks the
    brief. Story returns to Refinement with a comment
    explaining the gap.

Issue type scheme suggestion

The default Jira scheme works. Add the four axis custom fields to a screen used by the Epic and Story issue types via the screen scheme. Optionally add a Brief-aware Story type if the team wants visual separation in the backlog between brief-bound work and operational work.

Issue types in the scheme

Epic           - carries the brief, axis fields required
Story          - inherits axis defaults from Epic Link
Bug            - axis fields optional (often N/A)
Task           - axis fields optional
Sub-task       - inherits from parent Story

Screen configuration

Create Issue (Story) screen
  - Summary, Description, Epic Link (required)
  - Tone, Aesthetic, Relationship, Sensory
    (defaulted from Epic Link, editable)
  - Direction status (set during refinement)

Edit Issue (Story) screen
  - Same fields as Create
  - Plus Direction status, editable by reviewers

Failure modes

Where the Jira integration goes wrong.

Custom fields applied to the Epic but not surfaced on Story creation. The team configures the four axis fields, applies them to the Epic, then opens the Create Story screen and discovers the fields are missing. Stories get filed without context, JQL filters return holes, and the team loses confidence within a sprint. The fix is the screen scheme: the axis fields have to appear on every Create and Edit screen the team uses.

Epic Link missing on Stories. Someone files a quick Story from a notification, forgets to set Epic Link, and the Story enters the next sprint without ever being graded against the brief. Make Epic Link a required field on the Story create screen, or add an automation rule that surfaces Epic-less Stories to the team channel within fifteen minutes.

The brief is in the Epic description but never read. Refinement opens the Epic, scrolls past the brief, and gets to the Story list. The brief becomes a header the team scrolls over. The fix is the Direction review workflow step: a Story cannot move to Ready without Direction-status being set, which forces the reviewer to compare the Story against the brief.

Direction-status set to Aligned by default. If the field defaults to Aligned, the Direction review step degenerates into a single-click rubber stamp. Default the field to empty so the reviewer has to make an active selection. The friction is the point.

Composition

Which skills feed the Jira integration.

The brief itself comes from creative-direction. Stories that produce voice copy consume the output of brand-voice. Stories that produce identity work consume brand-identity. Conversion-focused work consumes landing-page-copy. The dependency chain is identical to the agile-creative-direction integration; this page just translates it into Jira's vocabulary.

Continue reading.

For Jira platform mechanics (custom field types, screen schemes, JQL syntax, workflow validators), Atlassian's official Jira documentation is the source of truth. The fields and queries above use only built-in Jira features; no marketplace add-on is required.

Frequently asked questions.

Where does a creative-direction brief belong in Jira?: On the Epic. The brief synthesis becomes the Epic description, the four axis positions become custom fields on the Epic, and the rejection list becomes a structured section in the description. Stories link to the Epic via the Epic Link field, which Jira indexes natively, so a single JQL query returns every Story under the Epic answering one brief.
What custom field type works best for axis positions?: Single-select fields, one per axis (Tone, Aesthetic, Relationship, Sensory). Single-select gives you the JQL queryability of structured values without the cardinality problem multi-select introduces. Configure the option list per axis (Professional, Conversational, Playful, Provocative for Tone; the corresponding sets for the other three) and apply the fields to the Epic issue type via the screen scheme.
Can JQL find stories that break the brief's rejection list?: Not directly via JQL alone, since the rejection list is freeform text. Teams handle this with a Single-select Direction-status field on Stories with values like Aligned, Drift, Needs review. A workflow transition or an automation rule sets Direction-status during refinement based on a manual judgment call. JQL then queries that field. The brief is the source of truth; the field is the queryable index of human review against it.
What is the most common Jira-specific failure of this integration?: Custom fields applied to the Epic but not surfaced on the Create Story screen. Stories get filed without axis context, the JQL filters return incomplete results, and the team loses confidence in the integration within a sprint or two. Confirm the screen scheme exposes the axis fields on every relevant create and edit screen, not just on the Epic detail view.